Buy commercial curl support. 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 Daniel himself.
Verifying reproducible curl builds
- 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: Sat, 3 Aug 2024 23:19:30 +0200 (CEST)
Hello,
We recently made sure that our release tarballs are created completely
reproducible. "Anyone" can recreate our release tarballs and verify that the
ones we provide are not "spiced up" with any extra content that should not be
there.
But does anyone? Probably not. I decided to make it easier to do so.
Starting now, it should be possible for people to do this:
$ ./scripts/verify-release [tarball]
This script recreates the tarball and verifies that it ends up identical.
Meaning that it could be made entirely with contents from the tarball and the
system the associated docker image runs.
My hope is that perhaps one or two people out there will add this step in
their (automated) build procedures. This will grealy increase the chances of
us detecting any future malicously altered release tarballs. Like if my system
gets infected so that releases I do on my machine without my knowledge include
something undesireable.
I have been thinking about some kind of more automated verification of the
releases, but in order for that to work best, such extra verification steps
need to be done by others than me. On machines I don't have access to, running
on networks not associated with me. Because if my account and systems are
breached, chances are such an attacker could affect all systems I can access.
Verification of curl releases are best done "airgapped" from me.
Note: this script unfortunately does not work with existing curl releases
because of missing files in the past tarballs. I have addressed those problems
now and going forward this is verified in CI jobs to make sure this
verification process continues to work.
Note2: release tarballs are also signed by me, which is a separate
verification that I and nobody else created the tarballs. That's also a good
check to do, but is a slightly separate check that does not remove the need
for verifying the tarball contents.
Date: Sat, 3 Aug 2024 23:19:30 +0200 (CEST)
Hello,
We recently made sure that our release tarballs are created completely
reproducible. "Anyone" can recreate our release tarballs and verify that the
ones we provide are not "spiced up" with any extra content that should not be
there.
But does anyone? Probably not. I decided to make it easier to do so.
Starting now, it should be possible for people to do this:
$ ./scripts/verify-release [tarball]
This script recreates the tarball and verifies that it ends up identical.
Meaning that it could be made entirely with contents from the tarball and the
system the associated docker image runs.
My hope is that perhaps one or two people out there will add this step in
their (automated) build procedures. This will grealy increase the chances of
us detecting any future malicously altered release tarballs. Like if my system
gets infected so that releases I do on my machine without my knowledge include
something undesireable.
I have been thinking about some kind of more automated verification of the
releases, but in order for that to work best, such extra verification steps
need to be done by others than me. On machines I don't have access to, running
on networks not associated with me. Because if my account and systems are
breached, chances are such an attacker could affect all systems I can access.
Verification of curl releases are best done "airgapped" from me.
Note: this script unfortunately does not work with existing curl releases
because of missing files in the past tarballs. I have addressed those problems
now and going forward this is verified in CI jobs to make sure this
verification process continues to work.
Note2: release tarballs are also signed by me, which is a separate
verification that I and nobody else created the tarballs. That's also a good
check to do, but is a slightly separate check that does not remove the need
for verifying the tarball contents.
-- / 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/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-08-03