openssh unix dev - Apr 2024 - Publish PGP signed tarball without generated content?

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
>

Damien Miller <djm at mindrot.org> writes:
> I think we're going to check in the autoconf-generated files on the
> release branches instead.
Ok that may also achieve the same goal of reproducible release tarballs
built from source code.

With that approach, the tarball depends on which autoconf version was
used by the release manager, and perhaps other things from the
environment.

Could you document how to re-generate the release tarball including
mentioning which autoconf version that you used?

That would probably be sufficient to allow people to reproduce the
release tarballs, and to allow people to audit that all generated files
in the tarball were generated from the corresponding source code.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20240418/d11604ea/attachment.asc>

On 2024/04/18 10:06, Damien Miller wrote:
> I think we're going to check in the autoconf-generated files on the
> release branches instead. 
That seems a sane approach. 
> On Wed, 17 Apr 2024, Simon Josefsson wrote:
> > 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.
More than git is involved in this - it also depends on versions of
things like tar and gzip. And github don't guarantee that these files
won't change.