Signing stuff (.debs, Package files, and so on)
Some things I could envision ...
(1) There is a "Project Key History Key-ring". It contains all public
keys ever used for the project as such (as opposed to individual
developer keys), all revocation certificates ever issued for those
keys or for anything signed by those keys, and so on. A small set of
core developers controls this key-ring, and the master copy is on
their private machines somewhere - master has only a copy. (Yes, this
can get large. You might want to split it into more than one file by
date, for example.)
(2) Keys in there are only used in an official capacity after those
same core developers have got hold of a functioning revocation
certificate (that is, they are only entered into the key-ring after
this has happened). All those core people share all the revocation
certificates, just in case. (You can test that revocation works by
importing both key and certificate into a test key-ring, of course.)
(3) Project keys are clearly labelled as to their functions. Project
keys only ever have one user id, so there cannot be any confusion.
(4) At least Project keys that are used to sign anything but other
project keys always either are only valid for a limited time, or else
are only used for a single event. For example, a key signing a stable
distribution might have the user id "Debian 2.1 potato 2000-06-12"
and only be used to sign stuff in that exact distribution. Or a key
might have the user id "Debian developer in 2000" and would be used
to sign developer keys only during 2000.
(5) All such "temporary" keys are signed by project-internal keys
(that are not used to sign anything but other project keys, and are
never put on any well-known machine like master), and those keys
might in turn be signed by various user keys (thus linking Debian
into the web of trust).
(6) In case of something like the discussed dinstall key, this key
should probably be changed at least once a month, offline by some
core developer (see above), and signed by a project key this
developer controls. "Debian dinstall key May 2000".
(7) You don't need every older key to sign the newest version; the
history key-ring gives the complete history, which presumably
contains an unbroken chain of signings.
All of this is possible to do *today* without a single line of shell
script programmed by someone - only use GPG.
What we actually do with those project keys is, of course, a
different matter.
For example, dinstall signing Package files has already been
mentioned.
Another option would be dinstall signing individual .debs the moment
it has verified the md5sums and the signature on the .changes file.
Regards - Kai Henningsen
--
http://www.cats.ms
Spuentrup CTI Fon: +49 700 CALL CATS (=22 55 22 87)
Windbreede 12 Fax: +49 251 322312 99
D-48157 Muenster Mob: +49 161 322312 1
Germany GSM: +49 171 7755060
Reply to: