tarball signing

[David Faure]

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 <aacid at kde.org> 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, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5