[pkg-gnupg-maint] How (not) to detect if a keyring file is a keybox in apt-key

[Daniel Kahn Gillmor]

On Fri 2017-07-28 14:36:54 +0200, David Kalnischkies wrote:

> the apt team currently receives bugreports with (for users) strange apt
> errors which turn out to be caused by keybox files in trusted.gpg{,.d}
> as apt-key can't deal with them for plenty of reasons (including that
> gpgv2 couldn't for a while, we need/want to support gpgv1 & gpgv2, 40
> keyrings limit, …).
>
> Internally apt-key cats all the files it assumes would be 'old-style'
> keyrings together to a big single keyring as suggested by dkg a while
> ago. That fails hard of course if a keybox is somewhere in that mix.
> This is documented in the manpage, but of course old setups which
> suddenly produce keybox (as it is the default in gnupg) don't read new
> manpage sections…

Can we identify what code is dropping keybox files in that location?
That seems like the origin of the problem, and we should make sure it
gets fixed.

I don't think apt has ever claimed that keyboxes should go there.
apt-key(8) clearly says (as far back as jessie at least):

           /etc/apt/trusted.gpg.d/
           File fragments for the trusted keys, additional keyrings can be
           stored here (by other packages or the administrator). Configuration
           Item Dir::Etc::TrustedParts.

so anything storing other kinds of data there is a bug.

> Then I informally brought that up in a only slightly related discussion
> a while back I got also informally the advice to whitelist old-style
> assuming that false-positives are not very likely:
>
> | You can do this by inspecting the first octet of the ostensible binary
> | keyring for one of these three values:
> |
> |  * 0x98 -- old-format OpenPGP public key packet, up to 255 octets
> |  * 0x99 -- old-format OpenPGP public key packet, 256-65535 octets
> |  * 0xc6 -- new-format OpenPGP public key packet, any length
>
> That sounds better in my ears than blacklisting keyboxes, but risks
> false-negatives if that isn't catching all which would be sad, so
> before I go about implementing this I would like to ask more formally
> (& public) if this is the best option we have & keeps us in the
> "reasonably supportable" set in the opinion of the gnupg maintainers.

I don't have a problem with apt using the whitelist approach described
above, and it'll *certainly* skip over kbx files.  If apt wants to start
supporting keyrings that are other than OpenPGP public key packets, we
can add to the whitelist then.

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20170731/de534468/attachment-0001.sig>