Re: Revival of the signed debs discussion
Wouter Verhelst <wouter@grep.be> writes:
> Op ma 01-12-2003, om 14:34 schreef Goswin von Brederlow:
> [...]
> > Deb signatures method C:
> >
> > And now for something completly different. A man with 3 noses. :)
> >
> > Instead of keeping extra files with the signature of the deb the
> > information could be stored inside the deb itself.
> [...]
>
> As much as I like this idea in principle, storing signatures inside
> .debs has a serious problem: it won't work for us buildd maintainers.
Noone seems to like methods A or B so I'm focusing on C alone.
> As I explain in my document on wanna-build (usually at
> http://people.debian.org/~wouter/wanna-build-states, but due to some
> problems with that machine temporarily currently at
> http://www.grep.be/wanna-build-states.html too), buildd maintainers do
> not manually log in to their autobuilder to sign each and every .changes
> on its hard disk; instead, they extract the .changes file from the mails
> of successful messages sent to them (and to logs@buildd.debian.org,
> which processes them into what people can look up on
> http://buildd.debian.org), sign that, and send it back. In reply, the
> buildd will move all files mentioned in the .changes to an upload
> directory for them to be uploaded. This results in quite a few mails
> daily for me, being "just" the admin of 2 (out of 11) m68k autobuilders;
> it must be a hell of a lot more for those such as Ryan Murray and James
> Troup, who are and/or have been the sole autobuilder maintainers for
> multiple architectures.
I was wondering about that. I saw the remote signing option in debsign
but aparently thats not used.
> Requiring us to log in to the autobuilder to sign the .deb remotely is
> not acceptable, for two reasons:
> * it's way too much work for most of us
> * it requires copying the secret key over, which is, uh, a bad idea.
Yes, out of the question. Each buildd should have its own gpg key
thats renewed regulary and used by the buildd itself to sign packages
just like ftp-master signes Release.gpg.
> An alternative would be to copy over the .debs, sign them on the local
> hard disk, and upload them from there. That won't work either; it only
> solves the second problem (as you don't have to copy the secret key
> over), not the first, and it adds a bandwidth-related (if I have to
> download all packages arrakis successfully builds, have to sign them
> locally, and upload them again, I might exceed the download quota my ISP
> has implemented; requesting a higher quota involves paying for it)
>
> So unless you have a suggestion that would solve this particular issue,
> I'm afraid this idea won't work in practice.
Buildds should sign debs automatically, then the admin and as third
signature dinstall would confirm that the package went through the
debian upload queue as I suggested before.
As to signing the debs by the buildd admin I'm sure the digest can be
computed remotely, transmitted, signed locally and send back for
inclusion into the deb. I will look at the code and think about
something. I'm sure its possible to find something that does not make
the job of buildd admins harder.
The use of a manual signature by the buildd admin could be moved from
can to should to must as we find a solution to the signing problems on
buildds. Alternatively to the debsigs signature the actual changes
file could also be included in the deb (by dinstall) and verification
tools could be made to strip it out before verify if a solution eludes
us. Or signatures by the buildd and dinstall could be used without a
signature by the admin.
For now I would like to get debsigs _allowed_ in official debs. A
draft for debian-binary version 2.1 for signed debs should be made and
discussed (I will type up a proposal to policy tonight). Automatic
signatures by the buildd and dinstall alone would prevent a
compromised ftp-master from compromising debs. Also downloaded debs
that are no longer in the archive could still be verified. It would
replace the searching for changes files in the list archives that had
to be done with the recent compromise.
Given that debsigs work since potato with dpkg, dselect and apt and
I wrote a patch for apt-utils for sid to support debsigs too
(preconfiguring of debs fails with debsigs but its not fatal) and that
dpkg has all the code already in place and in working condition to
support debsigs signed packages they should be supported for
sarge. If all ftp mirrors are forwarned to rsync all sarge packages
could even be signed with a sarge release key prior to the release.
MfG
Goswin
Reply to: