"Joanna Rutkowska" 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 <<