* Andreas Barth ([EMAIL PROTECTED]) [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. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C