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

Re: Bug#540215: Introduce dh_checksums

Russ Allbery <rra@debian.org> writes:

> Goswin von Brederlow <goswin-v-b@web.de> writes:
>> The changes files are signed by a human and therefor have a strong trust
>> level. The "was XYZ is now UVW" file would have to be automatically
>> signed and much less trustworthy.
> This objection makes no sense to me.  The archive key is *much* more
> trusted in practice than the individual DD keys.  Haven't you been
> advocating using the Packages file for this purpose, which is signed by
> exactly the same key that would be doing this signature?

There are different keys signing the Packages files. I trust a DDs key
over the Debian Archive Automatic Signing Key, esspecially when it has
expired or was potentially compromised. On the other hand the XYZ Stable
Release Key is probably more trustworthy than $RANDOM DDs. They are kept
offline, right?

Also users would download the Packages when the key is still valid or
get it freshly signed by the new key after a compromise.

On the other hand the "was XYZ is now UVW" file would be essential in
verifying that the master archive on ftp-master was not altered after a
compromise. And if ftp-master was compomised then the automatic signing
key is compromised and all the "was XYZ is now UVW" files are useless.

The difference is that the "was XYZ is now UVW" file would be on the
same system as the key. You might as well not sign them as the
availability of the key make the signature pointless once the system is

>> Esspecially if you suspect someone broke into ftp-master and modified
>> some debs.
> Which they can do just as easily if you rely only on Packages.  Even more
> easily, in fact.

After a compromise the Packages files are only suspect untill the
archive has been verified to be pristine and signed by a new key. So it
is only a short term problem for users. The "was XYZ is now UVW" file on
the other hand would permanently sever the trust chain in case of a

> The problems that you are citing here are problems that we already have;
> that, in fact, are much worse now than they would be under that proposed
> scheme.  (However, I will note that your *.changes idea does offer some
> additional protection there over the scheme that I was considering.)

Lets hope they will be made more public.


Reply to: