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

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.

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

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