Bug#946686: apt should accept ASCII-armored OpenPGP certificates for signed-by: entries, even if the file name has a .gpg suffix

[Daniel Kahn Gillmor <dkg@fifthhorseman.net>]

On Fri 2019-12-13 22:32:17 +0100, David Kalnischkies wrote:
> Something like that needs to be implemented in shell, specifically in
> 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).

this seems reasonable to me.

> 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.

i agree that code reuse would be good :)

> The usual caveat applies: What is working in a new enough apt version has
> a strange error case in all older ones,

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

> 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.

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.

       --dkg