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.
Re: SLSA and HOWTO (not) backdoor curl
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_cool.haxx.se>
Date: Wed, 7 Apr 2021 23:18:50 +0200 (CEST)
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.
> 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).
What does this mean? What are such provenance? You mean like exact versions of
the involved components?
> - 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?
> - 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).
> - 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
> 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.
Date: Wed, 7 Apr 2021 23:18:50 +0200 (CEST)
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.
> 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).
What does this mean? What are such provenance? You mean like exact versions of
the involved components?
> - 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?
> - 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).
> - 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
> 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.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/ ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2021-04-07