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 > _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
