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.
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
Reply to: