`apt` repository `https://apt.fury.io/netdevops/` seems to be incomplete

[maxkratz]

(This is a heads up of my issue at the nala repository.)

It seems to me that the apt repository (https://apt.fury.io/netdevops/) lacks a few files.

To reproduce:

1. Start a new Docker container, e.g., with the Debian OS: $ docker run --rm -it debian:12 /bin/bash
2. Install ca-certificates within the container: $$ apt-get update && apt-get install -y ca-certificates
3. Use the steps provided in the Containerlab install documentation to add the Containerlab apt repository
4. Run $$ apt-get update to see the error

Hit:1 http://deb.debian.org/debian bookworm InRelease
Hit:2 http://deb.debian.org/debian bookworm-updates InRelease
Hit:3 http://deb.debian.org/debian-security bookworm-security InRelease
Ign:4 https://apt.fury.io/netdevops  InRelease
Ign:5 https://apt.fury.io/netdevops  Release 
Err:6 https://apt.fury.io/netdevops  Packages
  404  Not Found [IP: 54.204.238.15 443]
Get:6 https://apt.fury.io/netdevops  Packages
Fetched 21.6 kB in 1s (20.4 kB/s)
Reading package lists... Done

If I'm not mistaken, the standard configuration of apt/apt-get tries to reach the InRelease/Release(/Packages) file and the webserver hosting the Containerlab repository returns a 404.

[hellt]

Hi @maxkratz
this is an expected behavior, I was also triggered by that, but as per gemfury team, this is how it works:

Q: I just got confused that apt update reports 404 Not Found and it doesn't quite look alright?
Though the package is installed after all. Is this intended behavior?

A: This is somewhat intentional — this is an effect of optional GPG repo signing. Your repository doesn't have GPG enabled, so we don't generate signature-related files including the "InRelease" file. This can result in 404 errors when those files are requested, however, with "trusted=yes" configuration flag, those errors are ignored.

[maxkratz]

Hi @maxkratz this is an expected behavior, I was also triggered by that, but as per gemfury team, this is how it works:

Q: I just got confused that apt update reports 404 Not Found and it doesn't quite look alright?
Though the package is installed after all. Is this intended behavior?

A: This is somewhat intentional — this is an effect of optional GPG repo signing. Your repository doesn't have GPG enabled, so we don't generate signature-related files including the "InRelease" file. This can result in 404 errors when those files are requested, however, with "trusted=yes" configuration flag, those errors are ignored.

Thank you for your very fast answer and thank you again for the explanation that this behavior is intentional.

I have two more questions regarding your answer:

1. Why did you (or srl-labs, ...) choose to not use GPG-signed packages in the apt repository? Wouldn't this increase the
   security in a possible attack with spoofed packages etc.?
2. Why does my minimal apt example within the Debian:12 Docker container not ignore the 404 returned for one of the Packages files? As I stated above, I have the trusted=yes config in the repository configuration.

[hellt]

1. I think when I first created the repo the gpg signing was not offered (at least not on the plan we were using)

2. It is ignored when you try to download the package. This means you can successfully download the package and update the repo, it is just that you will see that 404 when you do apt update