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: Reproducing the release tarballs
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Howard Chu via curl-library <curl-library_at_lists.haxx.se>
Date: Sat, 30 Mar 2024 18:20:48 +0000
Daniel Stenberg via curl-library wrote:
> Hello,
>
> In the light of the xz attack, I would like to mention that in order to reproduce the tarballs I upload for curl release, this is necessary:
>
> - Clone the repo and checkout the release tag
>
> - Install the same set of tools + versions I use
>
> - run "./maketgz [version]"
>
> For the most recent curl release, my toolset that I believe might affect the results include:
>
> - autoconf (GNU Autoconf) 2.71
> - automake (GNU automake) 1.16.5
> - libtoolize (GNU libtool) 2.4.7
> - GNU Make 4.3
> - perl v5.38.2
> - git version 2.43.0
>
> (make, perl and git most probably have very little effect but I figure including them in the list could be worth it since they are invoked in the release process)
>
> Any proposals for how to document the exact set of tools+versions I use for each release in case someone in the future wants to reproduce an ancient release
> tarball?
>
IMO only project developers should ever be touching the autotools. Source code tarballs should have a correctly
generated configure script included, and of course those scripts list the version number of the autoconf script
that generated them. This is how it works in OpenLDAP, anyway. Only our release engineer ever generates the
configure script, and it's committed to the repo along with everything else.
Date: Sat, 30 Mar 2024 18:20:48 +0000
Daniel Stenberg via curl-library wrote:
> Hello,
>
> In the light of the xz attack, I would like to mention that in order to reproduce the tarballs I upload for curl release, this is necessary:
>
> - Clone the repo and checkout the release tag
>
> - Install the same set of tools + versions I use
>
> - run "./maketgz [version]"
>
> For the most recent curl release, my toolset that I believe might affect the results include:
>
> - autoconf (GNU Autoconf) 2.71
> - automake (GNU automake) 1.16.5
> - libtoolize (GNU libtool) 2.4.7
> - GNU Make 4.3
> - perl v5.38.2
> - git version 2.43.0
>
> (make, perl and git most probably have very little effect but I figure including them in the list could be worth it since they are invoked in the release process)
>
> Any proposals for how to document the exact set of tools+versions I use for each release in case someone in the future wants to reproduce an ancient release
> tarball?
>
IMO only project developers should ever be touching the autotools. Source code tarballs should have a correctly
generated configure script included, and of course those scripts list the version number of the autoconf script
that generated them. This is how it works in OpenLDAP, anyway. Only our release engineer ever generates the
configure script, and it's committed to the repo along with everything else.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-03-30