On Thu, Nov 24, 2005 at 09:09:21AM +1100, Matthew Palmer wrote: > 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. You can already use release signatures for this. Further, changing the deb after upload would make it much more difficult to check the deb was what was uploaded -- you can no longer just use md5sum, you've instead got to use special tools. > 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. Sure; but why do that inside the .deb? You can verify a detached signature just as easily as an inline one (gpgv sig file // gpgv file), and you can verify a signature of a hash just as easily as a signature of a file. If you're worried you might lose the detached, signed information, either keep it with the data it's authenticating (pool/main/f/foo/foo.origin, eg), or keep good backups, or both. > 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. That's easy: you trust the Packages file to be correct when using apt, and it's not verified at all by per-package signatures. > 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). My objection is that it's *useless* for *Debian*. Debian has too many sources for packages for key management to be plausible, and keeps packages unchanged over too long a period for the keys to be guaranteed secure for the lifetime of a package. Additionally, packages can be authenticated both via Packages.gz files and .changes files, which already exist and are usable. > 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. This is what .changes files are for, and it's useful both for recovering from compromises and in a "cvs blame" sort of sense. Note that they also give more information than a simple signature on the .deb. Hrm, I see queue/done (which contains .changes files going back to the dark ages) isn't even being mirrored to merkel properly at the moment. That's not so constructive. Cheers, aj
Attachment:
signature.asc
Description: Digital signature