--===============0625098538==
Content-Type: multipart/signed;
  boundary="nextPart2308406.XdGXRqTAci";
  protocol="application/pgp-signature";
  micalg=pgp-sha256
Content-Transfer-Encoding: 7bit

--nextPart2308406.XdGXRqTAci
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable

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?
> >>>=20
> >>> That doesn't even make any sense at all.
> >>=20
> >> Interesting opinion -- can you elaborate? Many (most?) version control
> >> systems allow to sign commits, e.g. git, mercurial, perhaps also SVN.
> >>=20
> >> Look at the Linux kernel -- every "release" commit is tagged and signed
> >=20
> >> 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.
> >=20
> > 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.
> >=20
> > 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.
>=20
> 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=
=20
made would still be non-authoritative.

As far as those who *do* package KDE (the Release Team) they have their own=
=20
mailing list where this idea would be better brought up (release-
team@kde.org). From what I remember of Gnu PG it shouldn't be too hard to a=
dd=20
this step to the release checklist, essentially we'd just need to make a ke=
y=20
and publish it and have a bunch of KDE devs and packagers sign it to start =
the=20
web of trust.

The hard part would be ensuring that the private key is kept safe and only=
=20
given to the persons who strictly need it. On the other hand ideally this=20
would be more than one person. ;)

Regards,
 - Michael Pyne

--nextPart2308406.XdGXRqTAci
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iQIcBAABCAAGBQJL/GvRAAoJEAuvDJx7auny0l4P/AtVHRUyvTrjNQTp1cyOj3QT
4T82WWK40cSD9BGa2Is6PB5YJQWZFVgtDInkQqRCngkY/KGYCiyYVMYJg7NZBFfN
/XQG4pjZqgjwE9OKyu536kKaur7+MWL3lMqevy2Bcc3HJy4cSvKzP5RPsxWYkVNu
c2zR39fLEzbwMBebL+YM3PIzqcO0te+eY4rBPQdy1q53HtvwSND8TJ6PrivAeinF
zh3uPopYXTuw/gD8COUNYwzdPLJbiP1j1cdcTJ8tqu9xQuiratdk5k4v1o1YZ5q8
zxCdgOd+b5x80BEpBTDBao1PDIN5763PD+Qq6Z/LkJNcfNMSwZ3yZ8VT+boibl24
IwBBtdymEJ1o567d8WPmQ6CTllF5Bpw+PmI8Ql5JA5sWxwYFz8HTY0ortp8o6D5K
cskrKhlsmokUO1ZM3rJQJdpimuFJU06pf6ipF9nWvz72SKGUKgX7uC3sr2KT4nJ7
1uNJRBKtNnBRiAreZ9R5kHWv7wWKSIv4hw0lkK8h+yRwV8GyHMUSntHXgN4558PP
o7it0WI6Vd/bOzNbuwCkdOQHxzJKB/3ZNF27AD5XTRlvUg+hgDv7loQeSp6y1Rlh
NivnSCdl2lzNOsqMdN8i9GBmAy/qqT0PlmOAYZfcBlobdVxaPwxad3Q1/DsXVYwI
rTku3OWpTQyICBpU5Svu
=ixrY
-----END PGP SIGNATURE-----

--nextPart2308406.XdGXRqTAci--

--===============0625098538==
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 <<

--===============0625098538==--