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.
> 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.
Or every deb needs do be signed by a key. If that key is a buildd key
then the signature on the changes file may/must differ from the deb
signature, must belong to the buildds admin and the deb must be signed
by the right buildd.
> Creating special helper scripts:
> It could be possible to extract a small file (more or less like the
> current changes file) out of each deb. So you could just sign this
> file, and sent it back to the buildd. The buildd would then extract
> the signature, and include it into the deb before upload. This would
> however need to change the way debsign works: Currently debsign makes
> a simple binary stream out of the members of the ar. Instead of this,
> debsign should create e.g. a md5sum-file (like the current changes,
> but "one level lower") out of the binaries, and then sign this file.
> It is possible to write a verify-script that could accept the old and
> the new verifying-method.
I'm thinking about writing a little application that will log into the
buildd, create a digest of the deb and download that, sign it locally,
send it back und add the signature to the deb, generate a new changes
file, download that too, sign it and reupload to initiate the upload.
Same app could be used to browse the build logs and classify them into
failed, dep-wait, success (sign and upload go here), retry, send FTBFS
bug, ... in a comfortable manner. FTBFS bugs would automatically get
the build log (or url for it) added and the buildd system informations
instead of the admins systems. and so on...
The app could be made usable for any DD intrested so they can sign and
upload their packages themself. The app should then have a "contact
buildd admin" option for cases where the maintainer is unclear about
the status of the build, i.e. if the buildd goes mad as it happens
sometimes. If thats wanted is another matter though.
MfG
Goswin
