* Goswin von Brederlow ([EMAIL PROTECTED]) [031203 03:40]: > Andreas Barth <[EMAIL PROTECTED]> writes:
> > * Wouter Verhelst ([EMAIL PROTECTED]) [031202 19:40]: > > > So unless you have a suggestion that would solve this particular issue, > > > I'm afraid this idea won't work in practice. > > Two suggestions come to my mind. However, I can't judge how useful > > they are in reality. > > > > Signing by the buildd: > > The buildd could sign the debs by a buildd-key (one key for each > > buildd and each year). They could sign e.g. after they get the changes > Must be signed before the chnages files since the szec and checksum > change by signing. Not necessarily because of the options: 1. Accept a buildd-signature on the changes-file 2. Remove the signature out of the deb for the changes-verification if the signature is by a buildd 3. Make a preliminary signature on the deb for creation of the changes-file, but keep that secret and add it only after receiving of the changes-file. > > file back signed by the build admin. The debian archive scripts > > accepts packages signed by a buildd-key only if it is a binary package > > for this architecture, the key is valid (i.e. in the right year), and > > this package has been handed out to this autobuilder for building. > > Valid for the autobuilder the package has been handed to and that send > it in and if the changes file is correct. > > But what if the buildd failed and someone manually build the deb, > signes it and uploads? The debian archive scripts would need a way to > distinguish between autobuild packages and manually build binary-only > uploads. The archive script would of course continue to accept any deb by any DD under the same conditions as today. The question to the buildd-admins is: How often does this happen? Does this need special handling, or is it ok for them if they sign in these rare cases with their normal key? Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
