[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: digital signatures for kde sources?
From:       Joanna Rutkowska <joanna () invisiblethingslab ! com>
Date:       2010-05-26 0:50:18
Message-ID: 4BFC704A.7000405 () invisiblethingslab ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On 05/26/2010 02:31 AM, Michael Pyne wrote:
> On Tuesday, May 25, 2010 20:23:25 Joanna Rutkowska wrote:
>> On 05/26/2010 02:11 AM, Michael Pyne wrote:
>>> On Tuesday, May 25, 2010 19:45:01 Joanna Rutkowska wrote:
>>>>>> or for the stable revisions in the SVN's stable/ branches?
>>>>>
>>>>> That doesn't even make any sense at all.
>>>>
>>>> Interesting opinion -- can you elaborate? Many (most?) version control
>>>> systems allow to sign commits, e.g. git, mercurial, perhaps also SVN.
>>>>
>>>> Look at the Linux kernel -- every "release" commit is tagged and signed
>>>
>>>> by Linus -- see e.g. this:
>>> No, it's not an opinion, he's giving a technical fact regarding the
>>> source control system we currently use, Subversion. AFAIK git was
>>> actually the first popular source control system to allow
>>> cryptographic-strength code signing so it's still a relatively new
>>> feature. git gets it almost for free just based on the way Linus
>>> Torvalds designed the filesystem.
>>>
>>> I'm not going to say that it *can't* be done efficiently in Subversion,
>>> but I'm pretty sure it would be very difficult and as it stands
>>> Subversion doesn't support code signing.
>>>
>>> It would be possible to sign tagged branches or what not by doing svn
>>> export and signing the tarball but as you've already noted we don't go
>>> that far.
>>
>> If you could sign the tarballs you publish, it would be just enough. Why
>> are you saying that you don't plan to do that?
> 
> Well I don't package KDE releases at this point anyways so any signatures I 
> made would still be non-authoritative.
> 

Sure, for the end-user it would be the signature on *my* rpm package
that would matter. But for me it is the signature on the tarball that
matters. The user decides to trust me (or Fedora packaging team, or
Ubuntu, etc), because the user assumes I'm a reasonable person to trust
(e.g. I might be a well known, legally registered company, etc). This
assumes that I would follow reasonable security practices, which, among
many other things, include that I would be verifying software I package
and distribute (e.g. I would establish that KDE project is worth
trusting, I would verify the software has really been released by the
KDE people and not somebody pretending them).

> As far as those who *do* package KDE (the Release Team) they have their own 
> mailing list where this idea would be better brought up (release-
> team@kde.org).

But I need the signature from the original authors
(commiters/release-managers).

> From what I remember of Gnu PG it shouldn't be too hard to add 
> this step to the release checklist, essentially we'd just need to make a key 
> and publish it and have a bunch of KDE devs and packagers sign it to start the 
> web of trust.
> 
> The hard part would be ensuring that the private key is kept safe and only 
> given to the persons who strictly need it. On the other hand ideally this 
> would be more than one person. ;)
> 

Instead of having just one private key, it would be much better for
every commiter/release-manager or whoever is responsible for building
the stable tarballs, to generate their own private key and use it for
signing. Then, there should be one "master signing key" that would be
kept on some safe machine (perhaps used just for the purpose of
generating and using this key) and which would be used to sign all the
"authorized" developers keys. This key (the public portion) would be
published on kde.org website, and you can also send it to kde-devel
list, to make it possible for people to obtain it from 2 different
sources (I guess kde-devel is widely mirrored over internet, so it would
not be feasible for the attacker to subvert this public key in all the
places). Perhaps only the top 2 or 3 most trusted KDE developers (I'm
sorry I don't know the management structure of the project) should have
access to the master signing key.

joanna.


["signature.asc" (application/pgp-signature)]

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


[prev in list] [next in list] [prev in thread] [next in thread]