Bug#558784: Isn't this a security problem?
David Kalnischkies <email@example.com> writes:
> 2010/6/12 Torsten Landschoff <firstname.lastname@example.org>:
>> I would consider this to be a critical issue as it could become a security
>> Let's assume an archive key is compromised. As an admin reading this on
>> some information channel (irc, twitter, lwn.net, whatever) I would just
>> remove the key as shown by Tollef.
>> Only by reading this bug report I do know now that this plainly would not
>> work. Instead apt-key will reenable this key given any chance.
> Not at any chance and for any key:
> It will do so only for the debian-archive-keyring AND
> only on update for the package apt and/or debian-archive-keyring.
> (with complete gpg import output in the log btw)
> If the debian-archive-keyring is ever compromised the attacker has
> the possibility to provide different apt/debian-archive-keyring packages
> anyway so you better not upgrade as long as the archive doesn't
> have a new key (which you have validated and installed manually) --
> and in this event the debian-archive-keyring package will be one
> of the first packages updated in the archive (removing the old,
> installing the new key - just to be sure and for all the users which
> haven't done it manually?).
> Other keyring packages normally add themselves to the database
> on an install/upgrade of these packages automatically - if you don't
> want that what is the point of installing these keyring packages?
>> So, does this bug still apply?
> Still applies as the fragments file infrastructure is not used so far.
> As said earlier i intend to promote that a bit after squeeze release
> to have a smoother transition (keyrings are normally without a problem
> backportable between different releases - breaking that feels a bit ugly.)
> The difference is not big through. Instead of calling apt-key or doing some
> manual gpg calling a package drops a file into /etc/apt/trusted.gpg.d/
> The file is still binary so manual editing is not a good idea (TM)
> but at least someone who really wants to remove keys from a keyring file
> will get the benefits of dpkgs conffile handling - in terms of that he will
> notice that you have changed something, not so much that you can easily
> see what was changed?
> But, and that is what should help in this regard a bit is, that most keyrings
> are actually just one key, so the action can be broken down to a removed
> config file instead? This just need support by the maintainer of the keyring,
> so the debian-archive-keyring could e.g. be split into debian-lenny.gpg,
> debian-squeeze.gpg, debian-next-big-thing.gpg and so on.
> You might ask "why binary?" now, but APT internally uses gpgv for the
> validation which only understands binaries and not the ascii-amored stuff.
> (gpg is only used to import keyrings into the trusted keyring by the
> keyrings - if we switch to fragment files the gpg is no longer needed?)
> Best regards,
> David Kalnischkies
That would complicate things when using
deb [keyring=debian-lenny.gpg] http://ftp.debian.org/debian stable main
The idea of specifying a specific keyring is so that one compromised key
will not endanger all sources.list entries to attacks.
But I guess having to change the keyring name from debian-lenny.gpg to
debian-squeeze.gpg when upgrading to a new major release would be
acceptable. Just don't have it change name at will or for point/security
releases. There could also be a debian-stable.gpg -> debian-lenny.gpg
Since I'm quite opposed to non human readable conffiles: Why is the
keyring a conffile? Why not have the packages keyring in
/usr/lib/apt/trusted.gpg.d/ and user keyrings in
/etc/apt/trusted.gpg.d/ or /usr/local/apt/trusted.gpg.d/? But I don't
know how one would go about removing a key then.