Publish PGP signed tarball without generated content?

Damien Miller djm at
Thu Apr 18 10:06:43 AEST 2024

I think we're going to check in the autoconf-generated files on the
release branches instead. 

On Wed, 17 Apr 2024, Simon Josefsson wrote:

> Hi
> What do you think about publishing PGP signed tarballs without the
> generated files such as the ./configure script?
> What I'm looking for is for some private key holder of the OpenSSH
> portable release key to run
> git checkout V_9_7_P1
> git archive --prefix=openssh-portable-V_9_7_P1/ -o openssh-9.7p1-src.tar.gz HEAD
> gpg --detach-sign --armor openssh-9.7p1-src.tar.gz
> and then publish the resulting openssh-9.7p1-src.tar.gz and
> openssh-9.7p1-src.tar.gz.asc files, preferably using a version of git
> that leads to archives that are identical to what GitHub currently
> publish.
> The tarball would then be identical to what can (currently) be
> downloaded from the GitHub release page, thereby also allowing easy
> auditing of both GitHub download links.
> git clone openssh-github
> cd openssh-github
> git checkout V_9_7_P1
> git archive --prefix=openssh-portable-V_9_7_P1/ -o openssh-9.7p1-src.tar.gz HEAD
> wget -nv
> sha256sum openssh-9.7p1-src.tar.gz V_9_7_P1.tar.gz
> =>
> f0c22a08eeaa7dfbae3ba553031a8c7d5322e498216d99ad8074a076b28c6f90  openssh-9.7p1-src.tar.gz
> f0c22a08eeaa7dfbae3ba553031a8c7d5322e498216d99ad8074a076b28c6f90  V_9_7_P1.tar.gz
> The advantage with all this is that people can then build from a tarball
> that corresponds to what's in the git repository, and not have to audit
> the generated ./configure script and other files, or have to manually
> figure out which files needs to be removed from the official release
> tarball to get something that corresponds to the git repository.
> Building from a 'git clone' after verifying PGP signature of the
> V_9_7_P1 git tag does not lead to the same level of assurance: 1) the
> git tag can be moved and re-signed at any time but tarballs are forever,
> 2) git tags covers a SHA1 commit identity and SHA1 is broken so this
> verification does not necessarily prove that the file content correspond
> to what was intended to be released.  Any SHA-256 checksums of the git
> tree is not part of the release announcements either, so it is not
> possible to trace things back to the release information.  For more
> discussion of rationale, see also:
> /Simon

More information about the openssh-unix-dev mailing list