On Thu, Nov 24, 2005 at 11:13:45AM -0200, Henrique de Moraes Holschuh wrote:
> While the point about "you can no longer just use md5sum" is useless (you
> need gpg, other "special" tools won't make it any more difficult, especially
> since they are gzip and ar),
The problem is that using gzip and ar is complicated, which adds
possibilities for errors. You might find yourself not putting the deb
together again and getting false signature mismatches, or worse, you
might find yourself only verifying part of the .deb, and having dpkg
actually use parts of the .deb that haven't been authenticated under the
false conviction that you're actually safe. With "md5sum foo.deb" you
know you've authenticated everything.
(I'm amazed the security "crisis" we're having is about deb sigs
*again*, when we're still relying on md5sum which has a public exploit
available now...)
> IF this means we can switch the effort to a detached signature that is more
> powerful than a .changes file (or we are allowed to have multiple signatures
> in a .changes file),
Huh? Why do you want multiple signatures of a .changes file?
> and also that the .changes file will be stored in the
> archives along with the .debs,
As it turns out, that's probably not feasible per se -- it likely implies
too much inode usage, and slack space.
> and that .debs with wrong/incomplete/missing
> Source: fields will be rejected (such as all automated bin-NMUed .debs made
> until about a week ago, or any made by a maintainer right now),
Huh? I don't think #62529 is fixed yet. If you think you'll have better
luck at doing so, be my guest. That's not a prerequisite for verifying
packages from changes files though.
> > My objection is that it's *useless* for *Debian*. Debian has too many
> > sources for packages for key management to be plausible, and keeps
> This applies to .changes files too, with the aggravating addition that those
> are a bitch to find right now.
Uh, no, .changes files are not remotely useless for Debian right now.
Where would you get that idea?
> ONLY if we change the way .changes files are stored. It would be best to
> have them stored in the archive itself along the .debs, really, if we're
> going to use them for anything other than initial acceptance through DAK.
>
> However, integrating this on the tools will be far more difficult than an
> in-deb signature (still doable, of course),
The tools are the least concern; what's a few dozen lines of code here
and there matter? If you insist every package only be uploaded once, and
do the maximum packages per day, and stop all other development just to
get deb sigs done, it's roughly half a year before that's finished. New
packages, bug fixes, new upstream versions will make it take longer.
> where dpkg would simply refuse
> per user-set policy any non-signed deb or any deb without a specific
> signature...
I'm sorry, but you're back to the snakeoil use for deb sigs. Expecting
a signature by a random Debian developer to mean something is not
reasonable.
Would it help you see the point if I signed a version of dpkg that
installed a suid shell somewhere, and put that up on people.debian.org?
I'm tempted to do something like that anyway to see if the md5sum
exploit can be used to create fire and ice .debs. Without signed debs,
you'll have no reason to trust it, which is exactly right; with signed
debs, you'll have reason to know I built it, but you won't have reason
to know I was never going to upload it to Debian because I was just
experimenting with some possible security vectors. The question is, will
you make the unwarranted assumption that because it's been built by me,
that it's usable my you?
(changes have the advantage that they include the changelog ("Added suid
shell" might stand out) and the suite for it to be uploaded to
("aj-experimental" perhaps), but that only helps if you actually look at
it, rather than just having dpkg check the signature)
> > 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.
> Only if we can sign it multiple times, which is one of the capabilities of
> the "simple signature on the .deb" we are talking about.
The explanation you need is "...which is useful because _____". Again, I
can't see any need for multiple signatures for Debian; for non-Debian,
if deb sigs are convenient, use them.
Cheers,
aj
Attachment:
signature.asc
Description: Digital signature