Scott James Remnant <[EMAIL PROTECTED]> 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 automatically. > 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. MfG Goswin
