Re: dpkg-sig support wanted?
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
Reply to: