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

Re: Revival of the signed debs discussion

Scott James Remnant <scott@netsplit.com> writes:

> On Mon, 2003-12-01 at 13:34, Goswin von Brederlow wrote:
> > We have no continous trust chain going from the maintainer (also
> > meaning buildd + admin), ftp-master.d.o, mirrors to the user. A
> > compromised dinstall on master could replace binary uploads with
> > trojan versions without any user being able to detect it.
> > 
> A compromised dinstall on ftp-master could also replace the keyring
> package with a new one containing an extra key, used to sign the new
> package and any other package they felt like.

You don't check the signatur of a debian-keyring update against a
known good keyring? Maybe the debian-keyring package could add some
magic to its pre/postrm to check the new keyring on updates to do this

> Assuming that level of compromise, there's no recent to suspect that
> they couldn't have free reign adding anything to the archive they
> wanted.  Signed .debs gain you nothing here.

You can detect such a compromised keyring easily if you realy care. So
for people who care the debian-keyring can't be compromised this
way. And then signed debs gain security (in the problem we face now
tih the archive).

> Anyway, I digress from this, I'm replying to point out that we have
> exactly the chain of trust you want:
> Download the source package components, verify their MD5 signatures
> against the Sources file, verify the MD5 signature of the Sources file
> against the Release file and verify that file's GPG signature.  This
> proves that the package has successfully passed through the ftp-master
> process and entered the archive.

This ensures no mirror-in-the-middle attack was performed as already
stated in the original mail.

> To verify this was uploaded by a Debian developer, go to
> http://lists.debian.org/debian-devel-changes/ and find the Accepted
> message, verify that message's GPG signature and verify the MD5
> signatures of the files in that against the real files (this contains
> uploaded .deb signatures too).

Thats possible as long as lists.debian.org is up and running. Also an
attacker to lists.debian.org could erase the archive or the archive
gets lost in a harddisk crash. What then? Rebuild every deb in stable,
testing and unstable?

The point of the excercise was that the changes files are not
available to the general public in a crisis situation like now and are
not easily available at normal times.


Reply to: