Hi, Quoting Dima Kogan (2023-02-24 06:31:03) > > I also think I found the source of your problem. I reproduced your issue > > locally like this: > > > > sq key generate --userid "<jul...@example.org>" --export juliet.key.pgp > > sq key extract-cert --output juliet.cert.pgp juliet.key.pgp > > apt-ftparchive release . > Release > > sq sign --signer-key juliet.key.pgp --cleartext-signature > > --output=InRelease Release > > mmdebstrap --keyring=/home/josch/repo/ --variant=apt unstable /dev/null > > http://deb.debian.org/debian "deb copy:///home/josch/repo ./" > > [...] > > I: running apt-get update... > > done > > Get:1 copy:/home/josch/repo ./ InRelease [1190 B] > > Get:2 http://deb.debian.org/debian unstable InRelease [180 kB] > > Err:1 copy:/home/josch/repo ./ InRelease > > The following signatures couldn't be verified because the public key is > > not available: NO_PUBKEY FC8F3FACCD368D66 > > Get:3 http://deb.debian.org/debian unstable/main arm64 Packages [9282 kB] > > Reading package lists... > > W: GPG error: copy:/home/josch/repo ./ InRelease: The following signatures > > couldn't be verified because the public key is not available: NO_PUBKEY > > FC8F3FACCD368D66 > > E: The repository 'copy:/home/josch/repo ./ InRelease' is not signed. > > > > > > This is your problem, right? > > This looks exactly like my problem, yes. > > > > mv juliet.cert.pgp juliet.cert.asc > > > > The clue can be found in the man page of apt-key: > > > > Alternatively, if all systems which should be using the created > > keyring > > have at least apt version >= 1.4 installed, you can use the ASCII > > armored format with the "asc" extension instead which can be created > > with gpg --armor --export. > > > > Can you confirm that you also had a ASCII armored key stored with the .gpg > > extension instead of .asc and that changing the extension makes apt happy? > > Doesn't work for me. I exported the public key both in binary and ascii > formats, put them both in the keys/ directory (given to --keyring), and > I get the same error as before. The keys are there: > > $ file keys/KEY.{asc,gpg} > > keys/KEY.asc: PGP public key block Public-Key (old) > keys/KEY.gpg: OpenPGP Public Key Version 4, Created Wed Feb 22 22:07:13 > 2023, RSA (Encrypt or Sign, 4096 bits); User ID; Signature; OpenPGP > Certificate > > And once again, I can confirm that the keys are right because copying > them (or just one) to /etc/apt/trusted.gpg.d/ makes it happy. Is there > no way to ask apt for diagnostics? Should I reassign this bug report to apt?
There may be some apt debugging options for this but one usually has to read the apt sources to find the name of those options. Since you are able to reproduce your problem without mmdebstrap but with apt only using the script above, this problem is definitely not due to mmdebstrap but is either an apt problem or a problem of how you try using apt. Either way, I think it's best to get the apt maintainers involved. The weirdest thing about your bug is that copying your key to /etc/apt/trusted.gpg.d/ makes it work for you because when you changed the location of Dir::Etc::TrustedParts it just pointed to a different directory. Apt should not treat keys differently just because the path to them looks different... Thanks! cheers, josch
