Re: dpkg-sig support wanted?
On Thu, Nov 24, 2005 at 02:08:17AM +1000, Anthony Towns wrote:
> On Wed, Nov 23, 2005 at 11:33:47AM +0100, Florian Weimer wrote:
> > * Marc Brockschmidt:
> > > Today (or last night, whatever), the dak installation on ftp-master was
> > > changed to not accept packages that include more than 3 parts, which are
> > > usually the binary version and the compressed control and data
> > > tarballs. This means that signed binary packages are rejected.
> > This is a pity. I think dpkg-sig is an important step into the right
> > direction: providing more assurances about package integrity to our
> > users.
>
> Personally, I think it's cryptographic snake oil, at least in so far
> as it relates to Debian. I remain interested in seeing any realistic
> demonstration of how a Debian user could reasonably rely on them for
> any practical assurance.
Are you, perchance, interpreting "user" in Florian's message a little too
strictly? I consider myself a user of Debian, as well as a contributor, and
I can see a couple of uses for signed binary packages for my own purposes
(as well as uses for Debian itself).
Maybe I'm raising a too-long-ago-for-my-recollection flamewar, but I can
think of the following scenarios (not all of them strictly-Debian, though).
I'd be interested in explanations (or pointers to previous discussions)
discrediting them, so I can be properly enlightened.
1) A signature added by the "originator" of a particular binary package (the
buildds, typically, within Debian) could provide some identification of the
true origin of a binary package. If a buildd were to be deemed to be
compromised, all packages signed with that buildd's key could be turfed and
rebuilt. (Note that I'm not suggesting using buildd keys as a "this package
is OK for the archive" check, see my comments below).
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.
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.
Maybe that's the snake-oil you speak of, aj -- it gives me the warm fuzzies
to be able to look at a long list of signatures and say "hmm, that looks
secure" when it shouldn't making me anywhere near as fuzzy.
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. 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).
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. The benefit suggested there is that offline signing
is more secure than leaving the Release.gpg private key somewhere it can
theoretically be stolen and used to sign bogus release files. The problem
is that, in general, no automatic signing key is any more secure than any
other. In addition, if (for eg) every buildd had it's own automatic key,
and that was sufficient for admission to the archive and for checking
archive integrity, that you've got less security because there's N keys,
spread across a range of machines, any of which can do the job of letting a
package into the archive.
- Matt
Reply to: