[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: apt-key has inadvisable behavior



On Sat, Nov 07, 2015 at 06:54:36PM -0800, Kevin Gallagher wrote:
> Just wanted to draw your attention to this issue. The apt-key utility
> should be updated to work with full fingerprints IMO.

This is fixed for a while now (git ba72845c , so 1.1~exp4), it just
isn't in a release (expect experimental) just yet.

Note that while the commit itself looks simple enough it depends on the
previously happened rewrite of apt-key to deal with gpg2 (and beyond),
so that isn't going to be backported – it didn't even get a freeze
exception back then (yes, that is how old the commit is by now).

Also, apt-key is supporting longid, not shortid-only in jessie as your
bugreport suggests. Not that it makes not a whole lot of a difference in
practice as we are talking about your trusted keyset here. That is going
to be really small and if you have keys in there which you do not trust
you have bigger problems than 'del' …

And lastly: -keyring packages should use 'apt-key del' ONLY FOR
TRANSITION purposes: apt supports for many releases (squeeze!) now the
use of fragment keyrings, so the right thing to do is shipping key(s) in
/etc/apt/trusted.gpg.d/foobar-archive.gpg (or in /usr/share and ship
a link to it in /etc). The point is that we don't need the whole gpg
stack for key-management anymore as its then (conf) file based and we
can use gpgv only. You need to call apt-key only to transition away from
keys you had previously added via 'apt-key add'.
See e.g. debian-archive-keyring for an example.


Best regards

David Kalnischkies

P.S.: The 'OK' is a bit strange, but we can't change that a) for
backward compatibility reasons and b) getting gpg to tell you what you
want to know isn't as easy as it seems/should be - especially if you
need to have the same interface for 1.x and 2.x. apt-key is ~600 lines
of shell code "proofing" this…

Attachment: signature.asc
Description: PGP signature


Reply to: