policy for debsigs

This page contains a draft for a possible policy for debsigs. Debsigs are signatures on individual Debian Archive files. There is also an overall overview. On this page, the requirements how it should work are listed. This page is also set up for discussion. If you have enhancements or notice mistakes, please say so.

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 filenames 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.

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:

• The name of the signature (without the possible suffix 0-9A-Z)
• control and data information
• all previous signatures
• the time information that is embedded in the tar-files and inside the previous signatures
• inside the signature also the signing key and the time of signing

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.

Previous versions

This document describes version 3 signatures. Version 2 signatures didn't have the name of the signature in the first line. Version 1 signatures were just done over that concatenated control.tar.gz and data.tar.gz