On Thu, Nov 24, 2005 at 06:28:04PM +0100, Florian Weimer wrote: > 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. Mmm. I'd phrase that differently: "with the current state of technology, there's no way of assuring that "installation of this package will not cause any harm"". Which is fine; we can't assure that yet, so there's no point worrying about it. We can provide a weaker assurance though, namely "to the best of our knowledge, installation of this package will not create any security vulnerabilities", or even "to the best of our knowledge, this package does not have any release critical bugs". Those are issues that users are interested in, and digital signatures provide a reliable way to communicate those assurances to users. The problem is, we can't make the latter assurance meaningfully at build time; and more importantly both assurances are time-dependendant -- more information keeps coming to hand, and users will naturally want the latest possible. So we didn't know foo was exploitable last week, big deal -- do we know it's still not exploitable today? We currently pass on those assurances via the Release-Packages-deb path on our archive; and expecting users to use apt-get to ensure they've got a current assurance. > 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? Yes, jennifer's identical apart from some $Id$ strings. The issue's more that ar members are checked for correctness than that additional metadata's specifically disabled. AIUI, some of the hystrionics on channels I no longer frequent have discouraged folks from doing dpkg-sig advocates any favours. *shrug* > >> 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? Same thing you do if you find a discrepency between the md5sum in the Packages file and a .deb -- investigate where the corruption is and report it? > I don't know > how common this would be; the hashes on buildd.debian.org are not in a > readily extractable format, it seems. If you just want to check hashes, you should just use changes files. If you _actually_ want to check hashes, and this isn't just a thought experiment, working out a usable way to deliver .changes for whatever purpose you've got in mind would be a good idea. (Again though, I don't see a point to them, beyond reverification of the archive in the event of an exploit. Of course, maybe that's what you want to do...) > 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-) I find it amusing that all bar arm and m68k are above the 98% barrier that caused such consternation earlier in the year... > >> 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. As others have pointed out, ddc's for source uploads, binary-only uploads are on the arch-specific lists. AFAIK binNMUs aren't treated specially in that respect. Cheers, aj
Attachment:
signature.asc
Description: Digital signature