also sprach Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> [2005.02.20.1229 +0100]: > The easiest way to handle the archive key would be to include it > inside the deb. The drawback of this method is that apt must be > updated whenever the key is changed for any reason. Since the key > is used to authenticate updates this would require apt to be > updated before the archive key is chnaged (which is obviously > a problem). I would think it's a bad idea to use the same distribution medium for key and protected content. Then again, I cannot think of a way how this could be exploited, given that we manage to get a valid key to the user somehow else first. Or else we cannot establish a trust cycle. > One way around the problem is to allow for an alternate means to > verify a package: signed debs. My first idea would be to allow apt-get > to install deb packages from an untrusted source (key expired) if the > deb in itself can be trusted. The apt deb and depends of it would have > to be signed by at least one key that is still valid (e.g. a still > valid DDs key from the stable keyring). That would provide the means > to savely update at least apt which would update the archive key and > consequently restore the trust system. Fundamentally, package signatures are the way to go (I am thinking dpkg-sig here). They would make the rather complicated archive signatures be unnecessary and protect DEBs, not an abstract package in an archive. However, infrastructure support for dpkg-sig is not there yet. Worse, it looks like we might need a new revision of the DEB format to really make use of it. For APT 0.6, I think we therefore must concentrate on archive signatures, and we'll look into package signatures later. > Well, those are my ideas. Show me the flaws. None really, except we should also work on a policy for the archive keys. E.g. require a new key to be available on 1 Dec and expire on 31 Jan, 14 months later. Keys then overlap for two months, and the dak scripts start using the new key on 1 Jan. The new key should be signed by the old key, and the old key must be revoked on 31 Jan. Also, I would love to see the keys to be available on www.debian.org over HTTPS, ideally with a certificate issued by the SPI CA. I realise this is only a marginal technological security benefit; it surely has a psychological benefit to executives though. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <madduck@debian.org> : :' : proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
Attachment:
signature.asc
Description: Digital signature