On Thu, Nov 24, 2005 at 12:30:37PM +1000, Anthony Towns wrote: > On Thu, Nov 24, 2005 at 09:09:21AM +1100, Matthew Palmer wrote: > > 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.
Then there's the opposite argument about "why not do that inside the .deb?". On the one hand, if I copy a detached-signed .deb around, I need to remember to copy the .origin file around with it. Conversely, if I use in-file sigs, I can no longer rely on the md5sum of the .deb as originally provided to verify original provenance. I think the final judgment in this issue is going to come down to personal taste and needs more than anything else. > > 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. That's a good point. However, what damage can be done with a bodgy Packages file, if only well-signed .debs are actually accepted for installation on the system? The only thing that comes to mind is wasting some time and bandwidth on downloading dodgy debs (or their equally-dodgy dependencies), but if the system checks the signatures before installing anything, can anything actually be damaged? > > 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. Don't the same arguments about key longevity apply to checking the signatures on .changes files, too? > > 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. Is there a publically accessable form of queue/done somewhere that people can download the .changes files from? That would be quite handy for people to use to verify binary packages (and would be a darn sight easier to use than trolling d-d-c archives). - Matt