For a couple of months, I've had some ideas floating through my head about how to improve the upload process for Debian and address the following problems:

• require developers to run lintian, linda, piuparts against their packages prior to an upload.

• allow for the upload to pull from a version control system directly.

• require developers to build the package locally but do not require them to upload potentially large packages over slow uplinks.

• add the ability for certain packages to require more than a single DD signature to be accepted for upload.

• possibly others...

Here's the scheme I am envisioning, which has its shortcomings, but which seems like an interesting approach worth more thought, at least IMHO:

• A developer team maintains a package in a repository. When it's time to make a release, one developer checks out the package. Alternatively, conventional (non-versioned) packaging may be done (urks!).

• S/he builds it, tests it, and runs the various checkers against the result. Each checker outputs a certificate.

• When the developer deems the package ready, s/he sends a control email to some dak script, with the following info:

  • the hash sums of the source package files
  • the certificates of all the checkers s/he ran against the package
  • information on how to obtain the source package (svn co, baz get, wget, etc.) (think: plugin architecture)
  • his/her digital signature covering all these data

• On the side of dak, the script would

  • check whether the signature was made by a DD.
  • check whether the DD is a member of the maintainer team. If not, the script may impose additional requirements (more below)
  • verify the presence of the various required certificates (configurable per project, maybe)
  • check whether a single DDs signature + certificates are enough; some critical packages like login or similar may require more DDs to check the package and sign it off.
  • if there are enough signatures and certificates according to the package's policy, the dak script would go and obtain the source package from the source listed (e.g. a HEAD-checkout from the etch branch, or a simple wget)
  • if from a repository, it would build the source package according to a standard method (to be defined).
  • it then verifies the hash sums on the source package files. Here there's an expected problem with stuff like dates in the diff.gz and tar.gz files, which would cause the hashsums to be different. Maybe instead have the dak script pull the source package off at the point in time the signature was made?
  • if that passes, send the source package off to the buildds.

I am not sure how to do certificates by tools like linda and lintian. I don't see an obvious cryptographic solution to those challenges. In fact, it seems impossible without DRM (yeah, let's DRM lintian and linda & Co.!). But I suppose the question should be: build a system that no DD can crack (why?), or build one that's easy to use so that noone would think about going out of his/her way to subvert it? I tend towards the second... we can always tar-and-feather those that actively subvert the process.

This is all an initial braindump and I am looking forward for your input (on IRC, preferably).

PS: previously I would have sent this off to -devel. Now that I blog, this seems a better place. At least it won't drag with it endless discussions. I really just want to get the idea out right now since I don't have much time to do more anyway.

Site content are copyright © Martin F. Krafft. Please see the imprint.
I shall not be held liable for offending content in pages linking to or linked from site, nor do I endorse their content unless I stated otherwise.