Wouter Verhelst <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED], > 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
