[llvm-dev] Automating the releases a bit better.

[David Chisnall via llvm-dev]

On 22/04/2021 11:08, Tobias Hieta via llvm-dev wrote:
 > * We could have the release testers upload a .sha256 file together
 > with the distribution that contains a single line with the expected
 > hash. We could then write a script that takes the sha, compares it and
 > if it's correct signs it with the release key and uploads to github.
 > This can either be automated to run on a cron schedule or something
 > that Tom runs manually on his machine. The downside to this method is
 > that we remove the separate channel for the sha256 transmission. So if
 > someone would want to upload a malicious build he would "only" need to
 > gain access to the sftp. I am not that worried about that at this
 > moment, but something to consider.
 >
 > * The other more secure option is that the release testers actually
 > sign the binaries with their own key. These key identities could be
 > then be send async to Tom and now the script would check the signature
 > against the list of known testers. This would solve any point of
 > origin problems. But it would require a bit more on the release
 > testers side. For my part I think it might be worth doing this, we
 > could even write a script that could automate this on the testers side
 > as well.
 >
 > I direct this question to the testers and the community at whole, what
 > do you guys think about the extra work and the security tradeoffs
 > here?

I have the same question I had when the last discussion of pointer 
signing came up: what is the threat model?

The first doesn't seem to gain any benefit at all from the hash.  This 
could easily be computed on the server because anyone with the ability 
to tamper with the distribution can also tamper with the hash.

The second still doesn't really answer the question about what the 
signature is for.  A cryptographic signature is an attestation of some 
identity, coupled with a set of claims.  I think that the *most* that 
we're able to claim with the current and proposed infrastructure is that 
the LLVM project is able to identify the person[1] who tampered with the 
builds, if someone later identifies that the builds do not come from the 
source tree that they claim.  As a user, that doesn't seem like it's 
particularly valuable.

Given that LLVM is intrinsically a cross-compiler and can self-host for 
all of the platforms that we care about, if we want to improve this 
process *and* be able to make some useful claims, I'd propose that we 
move away from individuals building things on their own hardware and 
towards individuals (or groups) maintaining sysroots (or, ideally, 
scripts for fetching everything that goes into a sysroot from upstream) 
and we do all of the builds on a pristine VM.  We can then automate the 
signing process as the next step in a pipeline that consumes the build 
artefacts.  We may need to do Windows and macOS builds on those systems, 
but *BSD, Solaris, Linux, and so on, for any architecture, should all be 
able to build on any platform because all of the headers and libraries 
are available and free to redistribute.

David

[1] Using the term 'person' in the loosest possible sense of the word. 
We don't check ID or anything and on the Internet no one knows that 
you're a dog.  I have a reasonable amount of confidence that I know who 
Dim is when he produces the FreeBSD builds, but I don't think the 
project as a whole - and Tom in particular - have any evidence that they 
could present about whether he is really who he claims to be.  The most 
that we can really claim is that we can map from a binary to an email 
address and that's such a weak claim that I'm not really convinced that 
it merits the effort in cryptographic signing.