On Tuesday, June 7, 2016 6:16:04 PM CEST Harald Sitter wrote: > On Tue, Jun 7, 2016 at 2:09 PM, Albert Astals Cid <[email protected]> wrote: > > El dilluns, 6 de juny de 2016, a les 11:39:25 CEST, Sandro Knauß va escriure: > >> Hey, > >> > >> > 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 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". > > Single key on server means single well known target for attack, which > Riddell and I found not quite as exciting. > > That said, there is no bus factor to be had. If a release is done by a > release manager who is not known as such (i.e. has not previously done > a release) we want the signature to be different, we want verification > to fail on account of the now different signature, we want a vigilant > downstream to go inspect what is going on. > Ideally downstream would then find information as to why the signature > is different and that the new signature is within the release manager > web of trust (e.g. signed by at least one other well known release > manager). > They can then make the call on whether to trust this release or wait > for the return of the usual release manager to verify the authenticity > of the release. Or perhaps the usual release manager already sent a > signed mail explaining that key 0x112355 will be used to sign the > upcoming release etc. > > Andre's mail outlines pretty well why Jonathan and I are favoring a > pool of per-person keys rather than a central one. > Ultimately one person ought to be responsible for the trustworthiness > for their key and the trustworthiness of the system they generate the > tarballs on and thus the trustworthiness of the resulting tarballs > themselves.
Per-person key and agent-forwarding sounds good to me. I'll give it a try before the next KF5 release. -- David Faure, [email protected], http://www.davidfaure.fr Working on KDE Frameworks 5 _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
