Publish PGP signed tarball without generated content?

[Damien Miller]

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 https://github.com/openssh/openssh-portable.git 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 https://github.com/openssh/openssh-portable/archive/refs/tags/V_9_7_P1.tar.gz
> 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:
> 
> https://blog.josefsson.org/2024/04/13/reproducible-and-minimal-source-only-tarballs/
> 
> /Simon
>