I notice that if i have an ASCII-armored OpenPGP certificate (a.k.a. RFC
4880 "Transferable Public Key") in a file named /srv/foo.asc, and i have
a sources.list line with a "[signed-by=/srv/foo.asc]" option, apt can
happily use it just fine.

but if the same file is named "/srv/foo.gpg" then apt fails to verify
the InRelease file, with error messages like:

   W: An error occurred during the signature verification. The
   repository is not updated and the previous index files will be
   used. GPG error: … InRelease: The following signatures couldn't be
   verified because the public key is not available: NO_PUBKEY …

   W: Failed to fetch …  The following signatures couldn't be verified
   because the public key is not available: NO_PUBKEY …

If apt fails in this way, it might be nice to just peek at the first
handful of bytes of /srv/foo.gpg to see whether it begins with:
-----BEGIN PGP PUBLIC KEY BLOCK-----

and if it does, then treat it the same way it treats an *.asc file.

That would certainly be more user-friendly.

Thanks for your work on apt!

is_supported_keyring in cmdline/apt-key.in – which incidently does a bit
of peeking already for gpg files to detect binary keyring formats, so
what could be done is removing the gpg/asc filename detection here and
just handle all files the same (+ detecting asc properly here).
See also dearmor_keyring and dearmor_filename which deal with massaging
files enough to make them usable for further processing by apt-key and
do asc detection for things like import via stdin.
It might make sense to use the same code for all these cases.


The usual caveat applies: What is working in a new enough apt version has
a strange error case in all older ones, which is especially sad for
simple data packages like keyring packages admins and users alike
relatively reasonably assume to be able to backport into oblivion.

Personally I don't see much problem in naming a file correctly given
that it isn't a very common or much repeated task and the extension is
only a very tiny part of it all, but oh well.


Best regards

David Kalnischkies

this seems reasonable to me.

i agree that code reuse would be good :)

sure, but this is a good reason to make the change earlier rather than
later, right?  to avoid having a longer transition period.

so perhaps the thing to do is to emit a warning in the newer versions if
the suffix doesn't match the content, so that when the author of such a
package tests in a modern installation, they can see the warning and
know to fix it before they backport.

fwiw, this happens without a package, anyway.  i reported the problem
because a colleague was trying to add an external apt repository
manually, and they'd fetched and stored the repo's key by hand.  it
should have Just Worked for them, because the data was all there.  Even
a warning would have been fine in this case, as long as apt would have
accepted the key.