[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: