On Thu, Nov 24, 2005 at 02:08:17AM +1000, Anthony Towns wrote: > 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.
Are you, perchance, interpreting "user" in Florian's message a little too strictly? I consider myself a user of Debian, as well as a contributor, and I can see a couple of uses for signed binary packages for my own purposes (as well as uses for Debian itself). Maybe I'm raising a too-long-ago-for-my-recollection flamewar, but I can think of the following scenarios (not all of them strictly-Debian, though). I'd be interested in explanations (or pointers to previous discussions) discrediting them, so I can be properly enlightened. 1) A signature added by the "originator" of a particular binary package (the buildds, typically, within Debian) could provide some identification of the true origin of a binary package. If a buildd were to be deemed to be compromised, all packages signed with that buildd's key could be turfed and rebuilt. (Note that I'm not suggesting using buildd keys as a "this package is OK for the archive" check, see my comments below). 2) A signature from dinstall saying "this package was installed in the Debian archive" would provide a means of automatic "assurance" of the source of a binary package, when I'm putting together custom CDs or package repos. 3) I can verify the provenance of a particular package in my own custom repos at any time (did that come from Debian? Did someone build it internally? What's going on?) I can kinda-sorta do that if I manually sign each binary package I download & verify against the Packages->Release chain with a special "came from Debian" key, and I can verify the source of the source (heh) package via the dsc signature, but having a complete "chain of custody" on a binary package seems like a "nice" thing to have. Maybe that's the snake-oil you speak of, aj -- it gives me the warm fuzzies to be able to look at a long list of signatures and say "hmm, that looks secure" when it shouldn't making me anywhere near as fuzzy. At the very least, though, I can't find a hole which makes binary package signatures, done properly, any less secure than per-archive signing. Is your objection to binary-package signing that it is "no better" than archive signing, or that it is actively *worse* than per-archive signing (again, if both are done "properly", whatever we may define that to mean). One scenario, which initially seems compelling, but which I've since rejected, is that of "offline signing" of binary packages -- the idea that the archive can be authenticated via signatures applied to packages before they hit the archive. The benefit suggested there is that offline signing is more secure than leaving the Release.gpg private key somewhere it can theoretically be stolen and used to sign bogus release files. The problem is that, in general, no automatic signing key is any more secure than any other. In addition, if (for eg) every buildd had it's own automatic key, and that was sufficient for admission to the archive and for checking archive integrity, that you've got less security because there's N keys, spread across a range of machines, any of which can do the job of letting a package into the archive. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]