Anthony Towns <aj@azure.humbug.org.au> writes:
> On Wed, Nov 23, 2005 at 11:33:47AM +0100, Florian Weimer wrote:
>> * Marc Brockschmidt:
>> > Today (or last night, whatever), the dak installation on ftp-master was
>> > changed to not accept packages that include more than 3 parts, which are
>> > usually the binary version and the compressed control and data
>> > tarballs. This means that signed binary packages are rejected.
>> This is a pity. I think dpkg-sig is an important step into the right
>> direction: providing more assurances about package integrity to our
>> users.
>
> Personally, I think it's cryptographic snake oil, at least in so far
> as it relates to Debian. I remain interested in seeing any realistic
> demonstration of how a Debian user could reasonably rely on them for
> any practical assurance.
Use 1: I have this deb in my apt-move mirror and I want to know if it
was compromised on yesterdays breakin
Boot a clean system with debian keyring and check all deb
signatures.
Use 2: I have this Ubuntu CD and want to know which debs are from
debian and which got recompiled
Look for all debs that have a deb signature of the debian archive
(to be added to dinstall at some point).
Use 3: The debian servers were compromised and the security team takes
too long to check the archive for my taste
Being a normal user I obviously have no mail archive of all the
old changes files laying around so that road is closed. But everyone
has a Debian stable CD with keyring. See Use 1.
Use 4: The Debian Archive Key has expired yet again, like every year
or the Release.gpg file is out of sync as so often on some
mirrors and I still want to verify debs.
Check deb signatures against the keyring instead of the Release.gpg
check in apt.
Use 1, 3 and 4 rely on a manual signature of each deb. One suggestion
is to add this to debsign so the only change for developers is that
gpg asks for the passphrase more often. Use 2 would require an
automatic signature by the archive.
>> since May 31. The diff at
>> <http://cvs.debian.org/dak/jennifer?root=dak&r1=1.56&r2=1.57> shows
>> that the additional check was *removed*, not *added* more than a week
>> ago.
>
> Yes; CVS was corrupted in May and hadn't been updated 'til the other
> week. http://azure.humbug.org.au/~aj/blog/2005/11/16#2005-11-16-dak
>
>> Since there is no way for Debian Developers to review the way Debian
>> packages are created (and it's totally out of question for end users),
>
> buildd.debian.org gives full logs, to developers or users.
While the log contains the md5sum of each build deb it does not
contain any signature against tampering. Same goes for the mail
exchange between the buildd and admin for all the admins that sign by
mail.
Tampered debs can be uploaded by sending a fake mail to the admin and
filtering out his responce. A deb signature of the buildd and a
subsequent dak check would prevent this.
>> something that provides DD-to-user package signatures at least in some
>> cases is very desirable indeed.
>
> debian-devel-changes provides this.
That covers only the sourcefull uploads and the arch specific -changes
lists are not archived and therefore useless for non constant
monitoring.
> Cheers,
> aj
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
