llvm dev - Apr 2021 - Automating the releases a bit better.

Hello,

Me and Tom was talking yesterday about a way to automate and reduce
the manual work that goes into getting the release testers builds into
github.

Currently the release testers build the distribution, uploads it to
the sftp and then sends a email with the SHA-256 to Tom. Tom then
verifies the files against the sha, signs them with pgp and uploads
them to github.

This is a pretty labor intensive procedure and makes it so that
release artifacts can lag quite a bit, depending on how much time Tom
has available.

I have two ideas on how to make this less annoying:

* 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?

Thanks,
Tobias

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.

No problem here.

Neil Nelson

On 4/22/21 4:08 AM, Tobias Hieta via llvm-dev wrote:
> Hello,
>
> Me and Tom was talking yesterday about a way to automate and reduce
> the manual work that goes into getting the release testers builds into
> github.
>
> Currently the release testers build the distribution, uploads it to
> the sftp and then sends a email with the SHA-256 to Tom. Tom then
> verifies the files against the sha, signs them with pgp and uploads
> them to github.
>
> This is a pretty labor intensive procedure and makes it so that
> release artifacts can lag quite a bit, depending on how much time Tom
> has available.
>
> I have two ideas on how to make this less annoying:
>
> * 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?
>
> Thanks,
> Tobias
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210422/93d81a3f/attachment.html>