[lldb-dev] [Release-testers] RFC: Automated signing of release files

[Michał Górny via lldb-dev]

On Tue, 2021-01-12 at 21:13 -0800, Tom Stellard via Release-testers
wrote:
> Hi,
> 
> I would like to automate the signing of some of the release files we 
> upload to the release page, starting with the source tarballs.  My 
> initial goal is to have a CI job that automatically creates, signs, and 
> uploads the source tarballs, whenever a new release is tagged.  I would 
> also like the key used for signing to be a 'project' key and not 
> someone's personal key.
> 
> Once this is done, I would like to implement something similar for the 
> release binaries, so that testers could upload the binaries and have 
> them automatically signed.  This will be more difficult than the source 
> tarballs, because the binaries are built by individual testers, so we 
> would need to prove that they come from a trust-worthy source.
> 
> Implementing these changes, will help streamline the release process and 
> let release managers avoid doing a lot of manual mistake-prone tasks.
> 
> The questions I have for the community are:
> 
> Is this a good idea?
> 
> How can I implement this securely?

I have mixed feelings about automatic signing.  Since releases are done
by humans anyway, I don't see much gain by avoiding humans in the
signing process.  Of course, there are some factors to consider.

First of all, it is quite clear that LLVM currently relies on GitHub
for the repo.  No offense meant but I honestly doubt that anyone
actively monitors whether the repo has not been tampered with -- how
would you go about that anyway?  So I suppose it matters little whether
you sign release tarballs automatically or manually because whatever you
sign might be forged at this point already.

Not saying this couldn't be improved.  For example, in Gentoo we sign
all commits (but I don't think GH supports rejecting unsigned commits).
Then you could at least verify that every commit corresponds to the repo
state signed by someone you somewhat trust enough to give push access.

Secondly, I would presume any key stored outside your own trusted Infra
as compromised.  Now, if we were talking about signing the artifacts of
automated builds (e.g. nightlies), then I'd suggest using a separate key
for automated signatures (that's kept on the server) and manual
signatures (that's kept on you).  But if we're talking about final semi-
manual releases, then I think you should keep the key on yourself.

If you're planning to use PGP, please remember not to upload the secret
portion of the primary key to the server and keep that on you only. 
This will make it possible to easily replace the signing subkey
if the server is compromised.

Thirdly, this also requires a trusted release process.  You need to
verify that the binaries weren't tampered with before signing them,
so I guess they need to be signed too.  It might be just simpler to let
release testers upload binaries along with their signatures, and just
provide an explicit list of who signed what rather than a single signing
key.

-- 
Best regards,
Michał Górny