David Kalnischkies <kalnischkies+deb...@gmail.com> writes: > 2010/6/12 Torsten Landschoff <t.landsch...@gmx.net>: >> I would consider this to be a critical issue as it could become a security >> problem. >> >> 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 symlink. 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. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
