[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Revival of the signed debs discussion

* Goswin von Brederlow (brederlo@informatik.uni-tuebingen.de) [031203 03:40]:
> Andreas Barth <aba@not.so.argh.org> writes:

> > * Wouter Verhelst (wouter@grep.be) [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?

   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Reply to: