Re: Revival of the signed debs discussion
Scott James Remnant <firstname.lastname@example.org> 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.