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

[Tom Stellard via llvm-dev]

On 4/22/21 3:11 PM, David Blaikie wrote:
> can we put stronger permissions on the specific repository? (or create
> a separate repository to have those stronger permissions, if the
> current one has it lumped in with other stuff we don't want the same
> permissions on)
> 

We can't put stronger permissions on the llvm/llvm-project repository,
so we would have to create a new one in order to limit access to specific
people.

One thing we could do in the llvm/llvm-project repository is to have a GitHub
action that is run after each upload to verify that the uploader is an
'approved uploader' and then delete any uploads from unapproved people.
However, anyone with commit access would be able to make changes to the
action, so I'm not sure if we gain anything from this.

-Tom

> On Thu, Apr 22, 2021 at 2:46 PM Tom Stellard via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>>
>> On 4/22/21 4:56 AM, David Chisnall via llvm-dev wrote:
>>>
>>> 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.
>>>
>>
>> The easiest option would be to have testers upload binaries directly to the
>> GitHub release page.  Is this really any worse from a security perspective
>> than what we are doing now?
>>
>> The main difference is that anyone with commit access can upload releases
>> to GitHub whereas with the current sftp uploads, we have to explicitly
>> grant people access.
>>
>> -Tom
>>
>>> 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.
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>