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

[Tobias Hieta via llvm-dev]

Hello David,

> 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 benefits here are not so much security, but it's more that it's a
correct upload of the binary from the testers side. It's slightly
worse than what we have today in terms of security, but a massive step
forward in convenience.

> 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.

I agree with all of these points. We can't 100% know who is
identifying as that person currently. When we can meet physically
again a signing party could work for that, but that would potentially
exclude people that could not travel etc.

Now, I wrote this email to try to solve the problem of manual having
to upload releases, not so much trying to solve the security issue. I
am hoping that a solution can be found that can solve both problems.

> 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.

Yeah this would be a good solution. The downside I see with this is
that the current model with testers uploading their own builds is that
they hopefully have some better control on the failing tests and that
the actual binaries that are uploaded is the ones that we are testing.
Having a CI do all of that requires a pretty big change in the
workflow - where the release manager would trigger the builds and then
the testers would download these and give them the good old testing
after that.

I think that solution would be ideal, but the question is how much
work that would be (quite a bit) and if this is a workflow that we
want to change to instead of just making the current workflow a bit
better and easier to automate.

Very much valid questions though.

Thanks,
Tobias