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: Dan Fandrich via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 9 Feb 2023 08:51:13 -0800
On Thu, Feb 09, 2023 at 05:14:12PM +0100, Daniel Stenberg via curl-library wrote:
> 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.
The other point to consider is that a "curl release" is not much more than
packaging the source code that's in git into a tar ball. It doesn't involve
gathering multiple library dependencies, compiling against them, then building
an installer that includes all the above, so there is not a lot that can go
wrong. Fully automating the signing step is especially tricky in order to to
maintain an adequate level of security. You can read about the release
procedure in docs/RELEASE-PROCEDURE.md
That said, there is these days a Windows binary that's released in parallel
with the source code that does involve at least some of those steps, and I
don't know the details of how it's generated. It's certainly not done manually,
even if it might be triggered manually.
Dan
Date: Thu, 9 Feb 2023 08:51:13 -0800
On Thu, Feb 09, 2023 at 05:14:12PM +0100, Daniel Stenberg via curl-library wrote:
> 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.
The other point to consider is that a "curl release" is not much more than
packaging the source code that's in git into a tar ball. It doesn't involve
gathering multiple library dependencies, compiling against them, then building
an installer that includes all the above, so there is not a lot that can go
wrong. Fully automating the signing step is especially tricky in order to to
maintain an adequate level of security. You can read about the release
procedure in docs/RELEASE-PROCEDURE.md
That said, there is these days a Windows binary that's released in parallel
with the source code that does involve at least some of those steps, and I
don't know the details of how it's generated. It's certainly not done manually,
even if it might be triggered manually.
Dan
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-02-09