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

Requirements on signatures on debs (was: Revival of the signed debs discussion)

First: There is now a version of debsigs that creats debs that the
apt-utils could cope with, see http://debsigs.turmzimmer.net/ (I tried
it with the unmodified apt-utils of woody).

* Goswin von Brederlow (brederlo@informatik.uni-tuebingen.de) [031202 04:55]:
> I agree with you that every instance along the way to the archive
> should sign the package:
> 1. maintainer
> 2. sponsor
> 3. buildd
> 4. buildd admin
> 5. dinstall

I've tried to write down a list of requirements for the signature
names (and what should be signed). I'll update the web version of this
on http://debsigs.turmzimmer.net/policy.html

                              policy for debsigs

What are the technical conditions

   Current, signatures are created with debsigs and each is stored in an
   extra file in the deb. One (due to policy unchangeable) condition is
   that non-standard filesnames in the deb start with _ and that all
   filenames are not longer than 14 characters. debsigs uses as prefix
   the characters "_gpg", which is quite usefull. So, there are (at
   maximum) 10 characters left for usage of signature names.

What should signature reflect?

   There are quite different people and roles who handle a package during
   it's lifetime. These are (among others):
     * Maintainer as part of the build process
     * non-Maintainer as part of the build process (NMUs)
     * sponsor
     * buildd
     * buildd-Admin (or is this aequivalent to the non-Maintainer?)
     * dinstall for installing

   There are a few key differences: Some roles are bound to scripts that
   do their action independing on any human action, some are bound more
   or more less to human interaction.

   One other key question is: Should each signature stand for it's own
   (means: one could delete one signature from inbetween a deb), or
   should they depend on each other)? The former has the advantage that
   this is the current approach, and technically easier. The later has
   the advantage that this enforces identification in which order which
   persons and roles did handle the deb.

I'm open for additions, suggestions, comments or (due I hope not) errors.
Please tell me.

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

Reply to: