* Anthony Towns: > 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.
The assurance doesn't come from the signature, but from the procedures that create it and leave a cryptographically secured audit trail on the binary package. The approach chosen by dpkg-sig makes it possible to add further signatures while the package is propagated through Debian's infrastructure (unless there are some instances of compare-by-hash hard-wired into it, but there aren't AFAIK). Of course, with current state of technology, there can't be a digital signature that directly says that "installation of this package will not cause any harm". But this doesn't mean that we should give up completely. >> 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 So, just to be clear, revision 1.58 (which has been committed in the meantime) is equivalent (if not identical) to the production version, and adding metadata in the way dpkg-sig does is no longer possible? >> 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. But what do you do if there is a discrepancy between the hash in those logs and the package which is actually in the archive? I don't know how common this would be; the hashes on buildd.debian.org are not in a readily extractable format, it seems. Oh, and I looked again at the buildd stats after some time. Good to see that m68k is not lagging behind as dramatically as it used to. Debian is not doomed after all. 8-) >> something that provides DD-to-user package signatures at least in some >> cases is very desirable indeed. > > debian-devel-changes provides this. AFAIK, binary NMus aren't announced on debian-devel-changes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]