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: Roadmap 2023 ? -- Enhance security of curl's release
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 9 Feb 2023 17:14:12 +0100 (CET)
On Thu, 9 Feb 2023, Diogo Sant'Anna via curl-library wrote:
> Checking https://curl.se/dev/release-procedure.html, it seems the project's
> release is still managed manually. Have you considered migrating it to an
> automated release — e.g., through GitHub Actions, Google Cloud Build, or any
> other hosted build environment? This would protect against human error and
> potentially building with incorrect dependencies.
Not the strongest argument. I have made 212 curl releases to date. Not once
have I made a mistake like that in a release. Probably because I make releases
with the same machine and environment I use to build and develop curl on.
> There’s also the Open Source Security Foundation’s SLSA framework
> <https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html>,
> which can offer progressive steps to harden your release process and build
> artifacts. Happy to discuss the benefits of both options, if it's helpful.
Honestly, I don't know what of all those words that are helpful or not. To me,
most of those things and suggestions seem to address and aid projects that are
in other positions than we are.
If we can improve processes without making things complicated, I think that is
good.
> I'm available to develop or contribute these changes if you’re interested.
If you could outline what those proposed changes are with some more detail, I
think we would get a better idea wether we want them or not.
Date: Thu, 9 Feb 2023 17:14:12 +0100 (CET)
On Thu, 9 Feb 2023, Diogo Sant'Anna via curl-library wrote:
> Checking https://curl.se/dev/release-procedure.html, it seems the project's
> release is still managed manually. Have you considered migrating it to an
> automated release — e.g., through GitHub Actions, Google Cloud Build, or any
> other hosted build environment? This would protect against human error and
> potentially building with incorrect dependencies.
Not the strongest argument. I have made 212 curl releases to date. Not once
have I made a mistake like that in a release. Probably because I make releases
with the same machine and environment I use to build and develop curl on.
> There’s also the Open Source Security Foundation’s SLSA framework
> <https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html>,
> which can offer progressive steps to harden your release process and build
> artifacts. Happy to discuss the benefits of both options, if it's helpful.
Honestly, I don't know what of all those words that are helpful or not. To me,
most of those things and suggestions seem to address and aid projects that are
in other positions than we are.
If we can improve processes without making things complicated, I think that is
good.
> I'm available to develop or contribute these changes if you’re interested.
If you could outline what those proposed changes are with some more detail, I
think we would get a better idea wether we want them or not.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-02-09