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
Attachment:
signature.asc
Description: PGP signature