From kde-devel  Wed May 26 13:19:24 2010
From: Joanna Rutkowska <joanna () invisiblethingslab ! com>
Date: Wed, 26 May 2010 13:19:24 +0000
To: kde-devel
Subject: Re: Proposal: Implementing signing process for official tarballs
Message-Id: <4BFD1FDC.7010209 () invisiblethingslab ! com>
X-MARC-Message: https://marc.info/?l=kde-devel&m=127487995314465
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--===============1139200021=="

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============1139200021==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig1C206EEAA9509CBFF21EB819"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig1C206EEAA9509CBFF21EB819
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 05/26/2010 02:55 PM, Tobias Ellinghaus wrote:
> Am Mittwoch, 26. Mai 2010 schrub Joanna Rutkowska:
>=20
> [...]
>=20
>> 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 releas=
e
>> manager), and that its contents has not been tampered since then.
>=20
> No, it only proves that a specific key has been used to sign the file=20
> (provided that it's hard to forge the signature). It does not prove whe=
ther=20
> the user or a virus, someone who stole/found the key, =85 signed it.
>=20

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).

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

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.


--------------enig1C206EEAA9509CBFF21EB819
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkv9H9wACgkQORdkotfEW85JLQCfVkR3Ldny8RG0n6g/6qJzsvws
8ZUAni2DHy3BFJtalMPGCDFNwt8Hc6C5
=bSgF
-----END PGP SIGNATURE-----

--------------enig1C206EEAA9509CBFF21EB819--

--===============1139200021==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

--===============1139200021==--