Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
SLSA and HOWTO (not) backdoor curl
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Mark Lodato via curl-library <curl-library_at_cool.haxx.se>
Date: Wed, 7 Apr 2021 13:00:41 -0400
[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: https://curl.se/mail/etiquette.html
Received on 2021-04-07
Date: Wed, 7 Apr 2021 13:00:41 -0400
[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: https://curl.se/mail/etiquette.html
Received on 2021-04-07