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: Diogo Sant'Anna via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 16 Feb 2023 16:33:40 -0300
>
> 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.
Sorry about that. I'll focus here more on the direct changes and benefits
to curl.
> 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.
Thanks for the explanation. You’re right—in this case an automated release
wouldn't really ease the release process, since it's already so
straightforward.
However, an automated release would still bring security advantages by
making it possible to link the tarball to the source it came from. This
would be done by the creation of a provenance attestation, which is a
metadata file that tells people exactly how, when, and where the tarball
was created.
I see that you already sign your releases (which is great), but provenance
offers additional guarantees: not only that the tarball came from a trusted
builder, but that it also came from the expected commit in the expected
repository and was released following the expected procedure. This would be
builded and signed along the release process, so the users would be able to
verify it and have additional security on the integrity of the released
package.
One way to achieve this would be:
1.
Moving your release process (i.e., the packaging of the tarball) to an
automated script in GitHub Actions (GHA). I suggest this because I see you
already have some processes as GHAs and you could still reuse part of the
script you currently use in docs/RELEASE-PROCEDURE.md
2.
Adding a step on the automated process to generate a non-forgeable
provenance to the tarball, using the unique identifier of the GitHub
workflow that generated the tarball.
With this setting, the release could not be hijacked even if the signing
key gets compromised, because the attacker would not be able to forge a
provenance with a valid curl's GitHub Workflow identifier.
Here is a link with a bit more of the benefits of the provenance and a code
example on how it would be generated:
https://github.com/slsa-framework/slsa-github-generator/blob/main/internal/builders/generic/README.md#benefits-of-provenance
I'll be happy to hear what you think about this solution. I'm also
available to raise a PR showing the changes described.
Thanks!
Date: Thu, 16 Feb 2023 16:33:40 -0300
>
> 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.
Sorry about that. I'll focus here more on the direct changes and benefits
to curl.
> 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.
Thanks for the explanation. You’re right—in this case an automated release
wouldn't really ease the release process, since it's already so
straightforward.
However, an automated release would still bring security advantages by
making it possible to link the tarball to the source it came from. This
would be done by the creation of a provenance attestation, which is a
metadata file that tells people exactly how, when, and where the tarball
was created.
I see that you already sign your releases (which is great), but provenance
offers additional guarantees: not only that the tarball came from a trusted
builder, but that it also came from the expected commit in the expected
repository and was released following the expected procedure. This would be
builded and signed along the release process, so the users would be able to
verify it and have additional security on the integrity of the released
package.
One way to achieve this would be:
1.
Moving your release process (i.e., the packaging of the tarball) to an
automated script in GitHub Actions (GHA). I suggest this because I see you
already have some processes as GHAs and you could still reuse part of the
script you currently use in docs/RELEASE-PROCEDURE.md
2.
Adding a step on the automated process to generate a non-forgeable
provenance to the tarball, using the unique identifier of the GitHub
workflow that generated the tarball.
With this setting, the release could not be hijacked even if the signing
key gets compromised, because the attacker would not be able to forge a
provenance with a valid curl's GitHub Workflow identifier.
Here is a link with a bit more of the benefits of the provenance and a code
example on how it would be generated:
https://github.com/slsa-framework/slsa-github-generator/blob/main/internal/builders/generic/README.md#benefits-of-provenance
I'll be happy to hear what you think about this solution. I'm also
available to raise a PR showing the changes described.
Thanks!
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-02-16