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

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 

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

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: