Re: Requirements on signatures on debs (was: Revival of the signed debs discussion)
Andreas Barth <email@example.com> writes:
> 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 (firstname.lastname@example.org) [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
Please update my bug for policy about this if you have some spare time.
> 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.