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

List:       kde-devel
Subject:    Re: digital signatures for kde sources?
From:       Scott Kitterman <kde () kitterman ! com>
Date:       2010-05-26 1:49:16
Message-ID: fa46df79-8140-4f47-910a-d9f557ea7ca1 () email ! android ! com
[Download RAW message or body]



"Joanna Rutkowska" <joanna@invisiblethingslab.com> wrote:

> 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.
> 
Speaking as an Ubuntu packager, we maintain in transit assurance of package integrity \
by retrieving the tarballs via sftp.  If someone can MITM my SSH session,  then \
there's a lot better things they can do with it than modify KDE tarballs in transit. 

Scott K

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


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