SLSA and HOWTO (not) backdoor curl

[Mark Lodato via curl-library]

[In response to: https://daniel.haxx.se/blog/2021/03/30/howto-backdoor-curl/]

Hi curl maintainers,

I'd like to gauge your interest in hardening curl's software supply
chain against compromise by following the nascent SLSA Framework:
Supply-chain Levels for Software Artifacts. The high-level proposal
can be found at https://github.com/slsa-framework/slsa/. The gist is
that the SLSA levels outline a path for increasing a software supply
chain's security is relative to two principles: auditability and
two-person control. Built software is traced back to source through
signed metadata called provenance, and policies restrict not just
_who_ can release software but also _what_ they can release. At higher
SLSA levels, we have higher confidence that the provenance is accurate
and cannot be forged.

For curl, this might look something like the following:
- Start generating and publishing provenance for each build step
(maketgz plus all of the different releases).
- Make curl's build steps reproducible. (Not strictly required, but it
makes everything easier. It also avoids you having to trust one
particular vendor.)
- Start performing automated builds on GitHub Actions or similar. (If
the build is reproducible, this can be in addition to whatever you do
now.)
- Enable security controls on GitHub, such as two-factor
authentication and two-party review.

I'd love to hear your thoughts and can write a more detailed proposal
if there is interest. I also welcome comments on SLSA itself.

Best,
Mark
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:

[Daniel Stenberg via curl-library]

On Wed, 7 Apr 2021, Mark Lodato via curl-library wrote:

Hi Mark,

Thanks for taking in interest and for suggesting ways we can improve curl and
how we do things in the project.

I don't want to speak for anyone else, but I can certainly say that I am
always keen on tightening the bolts in the project to make sure we reduce risk
wherever we can. But it is also a balance. Nailing everything to the floor
also limits our ability to move around freely.

Post by Mark Lodato via curl-library
- Start generating and publishing provenance for each build step
(maketgz plus all of the different releases).

What does this mean? What are such provenance? You mean like exact versions of
the involved components?

Post by Mark Lodato via curl-library
- Make curl's build steps reproducible. (Not strictly required, but it
makes everything easier. It also avoids you having to trust one
particular vendor.)

Is there anything particular in the current build process that *isn't*
reproducible? I can't think of anything particular off the top of my head, but
if there is, I can't imagine it should be too hard to fix?

Post by Mark Lodato via curl-library
- Start performing automated builds on GitHub Actions or similar. (If
the build is reproducible, this can be in addition to whatever you do
now.)

We do automated builds on GitHub Actions already as part of our CI setup. It
makes me suspect you think of some particular builds? Remember that we don't
ship binaries on most platforms (exceptions being Windows and docker).

Post by Mark Lodato via curl-library
- Enable security controls on GitHub, such as two-factor authentication

We already do. Without that, we can't get a gold badge on CII best practices:

https://bestpractices.coreinfrastructure.org/en/projects/63

Post by Mark Lodato via curl-library
and two-party review.

I'm afraid we can't *require* this for everything at this point. We want to
have all PRs reviewed - by several people ideally - but in reality there are
merges being done on a regular basis that are only reviewed by its author. I
deem it a necessary trade-off for keeping the development pace.