Re: Secure APT Key Management
martin f krafft <madduck@debian.org> writes:
> also sprach Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> [2006.07.26.1601 +0100]:
>> If you can get ftp-master to put the key in that place then I'm
>> willing to patch apt to use it for key updates with enough checking
>> and interactivity to make it save.
>
> I am much in disfavour of any method that automatically makes APT
> trust keys downloaded over the network. If the key came from media
> we distribute, this is fine, but there's just too much danger of
> MITM or DNS-poisoning attacks for automatic upgrades, unless we
> finally start using SSL.
That is why you don't trust the download but check the data. gpg keys
do have signatures exactly for that reason so one can establish a
level of trust for a key from any source.
And don't forget that currently you do trust an unverifyable (since
you don't have the key yet) debian-keyring package to supply the key
for apt-key update with wich the debian archive is signed in the first
place. Or you download the key from a magic url or keyserver.
> The way I envision key management is that every Debian machine
> trusts the SPI CA. Then we provide a page to download and verify
> keys, protected by SSL/TLS. Finally, we give the user easy-to-use
> tools to install these keys, and proper error messages from APT that
> will make it obvious what to do.
So instead of having one simple and secure trust mechanism (gpg) with
a simple upgrade mechanism you want to add a second trust mechanism
(CA) with it's own upgrade problems on top of it?
Talk about twice the trouble.
> I don't think it's asking too much of our users to manually declare
> trust for a new release. But we should definitely get rid of the
> one-year-long archive keys, which make no sense. Instead, have a key
> for etch, one for sid, one for etch+1, one for security, and so on.
> The user can then pick which ones s/he wants to trust.
The one-year-long key protects from someone stealing the key and then
waiting for a good moment to exploit it to some degree.
MfG
Goswin
Reply to: