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

Re: Requirements on signatures on debs

* Andreas Barth (aba@not.so.argh.org) [031206 18:10]:
> 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

After some discussions, I updated my proposal (and also the website).

| Names of the signature files
|    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
|    These persons fall into three main categories:
|      * someone building a binary deb, e.g. a maintainer, a buildd, ...
|      * someone providing this deb as a part of the archive, e.g. dinstall
|      * someone approving a binary for a given situation, e.g. the
|        security team for security.debian.org
|    Overall, _gpg is used as a general prefix. For the first category, the
|    signature is named _gpgbuilder. For the second, a usefull name would
|    be _gpgorigin (as "origin" is commonly used for such things, e.g. at
|    apt pinning). For the third, this is a bit more complex, and so we
|    leave it open. A commonly used name could be _gpgapproval, but
|    everyone could use what he sees as usefull.
|    Sometimes (especially with the last one), there could be clashes. In
|    the case of a clash, the new signature is created as
|    <signame>[0-9A-Z], with the lowest free one. (That means, if
|    _gpgapproval is used, the next one would be _gpgapproval0, and then
|    _gpgapproval1, and so on.)
|    Some signatures are done by scripts, and some by human. This
|    distinction can (and should) be made by the used key, not by anything
|    else.
| What the signature provides
|    Each signature signs:
|      * control and data information
|      * all previous signatures
|      * the time information that is embedded in the tar-files and inside
|        the previous signatures
|    It should be possible to make signatures remote, without downloading
|    the whole deb. For this, the signature is done over the md5sums (as
|    provided by the md5sums-utility) of all ar members, in the order in
|    which they are present in the archive. After doing the signature, the
|    new archive member is appended to the deb file. No other way of
|    altering the deb except appending a new signature is allowed;
|    otherwise, the previous signatures could be broken.
| Signature verification
|    If a signature is due to be verified, the md5sum of the previous
|    archive members is made. The signature itself, and the following
|    archive members are supressed for that. The signature is then verified
|    on that md5sum. This has the bonus that signature verification could
|    also be done by hand, for debugging or in special situations.

If there are any questions on this, I'm happy to answer them. If not,
I'll provide a debsigs-ng on my website that generates and verifies
conforming signatures.

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

Reply to: