Proposal: Implementing signing process for official tarballs (try #1)

[Joanna Rutkowska]

On 05/26/2010 02:55 PM, Tobias Ellinghaus wrote:
> Am Mittwoch, 26. Mai 2010 schrub Joanna Rutkowska:
> 
> [...]
> 
>> Digital Signatures can prove that a given file is authentic, i.e. that
>> is has been indeed created by a person that signed it (e.g. KDE release
>> manager), and that its contents has not been tampered since then.
> 
> No, it only proves that a specific key has been used to sign the file 
> (provided that it's hard to forge the signature). It does not prove whether 
> the user or a virus, someone who stole/found the key, … signed it.
> 

That's absolutely true. That's why security of the desktop OS is so
important. But I made a (silent) assumption that any serious
developer/package manager, would be using a dedicated machine for
development/packaging/signing. Specifically would not be using the same
machine for also browsing the Web, etc.

(In fact this is what Qubes OS is all about: to create this level of
isolation between VMs and let the user use one psychical machine for
many different activities).

> [...]
> 
> I also miss a few words about revocation of compromised keys. That could be 
> user keys which got lost or (worst case) the master key.
> 

There is no automatic key signature revocation mechanism for PGP/GPG
keys AFAIK. PGP/GPG is different than X509 certificates where special
revocation protocols exist.

But, the audience in this case is compromised of very technical users
(mostly distribution builders/packagers), so I think it would be
reasonable to implement the simplest possible revocation scheme: create
a dedicated page (or just a text file) hosted at kde.org with the list
of revoked GPG keys ids, signed with the master signing key. The users
would be consulting this file before building a package. Additionally,
every time a developer's key would be revoked, this might also be
signaled by sending a message to the release-team list.

The above applies to revoking the developers keys, not the master
signing key. In the unlikely event of the master key compromise, some
other, extraordinary means should be applied, e.g. releasing a press
release and distributing it to the mainstream press. Well, obviously the
compromise the master signing key would be a big disaster...

One idea to make the compromise of the master key somehow less painful,
might be to have, say 5, master keys (each "master key admin" would
generate their own key), and require each developer's keys to be signed
by all of them (or e.g. at least 3 of them). That would make it somehow
more complex for people to verify the keys though, so I'm not sure if
it's worth the effort.

joanna.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 226 bytes
Desc: OpenPGP digital signature
Url : http://mail.kde.org/pipermail/release-team/attachments/20100526/877f1f3e/attachment.sig