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

List:       kde-release-team
Subject:    Re: tarball signing
From:       Andre Heinecke <aheinecke () intevation ! de>
Date:       2016-06-07 13:58:41
Message-ID: 2825288.Insc2avl8b () esus
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Hi,

Thanks for working on this. Signed tarballs would also help me when updating 
KDE Packages in Gpg4win :-).

On Tuesday 07 June 2016 14:09:44 Albert Astals Cid wrote:
> El dilluns, 6 de juny de 2016, a les 11:39:25 CEST, Sandro Knauß va 
escriure:
> > > Well, Albert and I use (the same user on) the same server to make
> > > releases.
> > > So the private key will have to be on that server, otherwise it will
> > > become
> > > very inconvenient (download, sign, upload).
> > > 
> > > But if that's good enough, and if we can tell gpg2 which private key to
> > > use
> > > (so he and I don't use the same), then we can proceed with the idea.
> > 
> > you don't need to have the privatekey on the server - We have gpg-agent
> > and
> > ssh - so you can forward the gpg-agent to the server when doing a release.
> > That way the private keymatierial stays safe at your place:
> > 
> > https://www.isi.edu/~calvin/gpgagent.htm

I agree that agent forwarding would be the appropiate setup for this usecase. 
Even better practice would be to keep the release keys on smartcards so they 
are not even on your system but that might be overkill here. ;-) 
 
> I agree a single gpg key makes more sense, but it also creates the problem
> with "to how many people do we give it so that bus factor is not a problem
> and trust factor of the key being stolen/misused is not either".

I'm not in favor of a single Key setup because of the Problem you are raising. 
If at some point someone drops out of the release team you would have to 
revoke the signing key. And if, worst case, someone created a malicous 
signature with that key you could not be sure who it was.

GnuPG itself handles the Bus problem by defining a set of keys / people where a 
release is signed by at least one of these keys / people.

https://gnupg.org/signature_key.html

Imo this is a good solution. You don't have to share the key material and 
there is still redundancy which people may sign releases.

Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
["signature.asc" (application/pgp-signature)]
[Attachment #6 (text/plain)]

_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


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