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

Re: dpkg-sig support wanted?

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.


Attachment: signature.asc
Description: Digital signature

Reply to: