tarball signing

[Harald Sitter]

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.

HS