Re: rebuilding non_ascii.tar

[Patrice Dumas]

On Sun, Nov 17, 2024 at 07:17:36PM +0000, Gavin Smith wrote:
> > I am wondering if we will have to compare the content of the tarball
> > when there is an attempt to do a new one and there is an existing one.
> > 
> > There is also the issue of reproducible distributed sources.  If we can
> > make sure that the distributed sources can be reproduced, at least with
> > a specified tar that is present on every platform.  And also we may have
> > to allow the user to specify customize the tar program name, be it only
> > to use the same as the maintainers for a reproductible distribution.
> 
> I have untracked the file.
> 
> I am not completely sure what you mean by a "reproducible" distribution.
> If you mean the generation of the .tar.gz or .tar.xz distribution tarball,
> then you are right that the embedded non_ascii.tar archive is dependent
> on the version of tar used on the maintainer's machine.

That is the issue.

>  However, this
> is also the case for the main .tar.gz file itself.

Indeed, but this is much less an issue, as the main .tar.gz file is not
what needs to be reproducible, it is the contents that should be as
reproducible as possible.

> There are other
> dependencies such as the version of autoconf used.

Indeed, this is reproducibility with the same version of the tools
needed for the generation ot the distributed tarball.

>  As far as I know,
> nobody is checking that the distribution archive is bit-for-bit
> reproducible from some specified commit in the git repository.

It seems to me that it could be relevant, to be able to check more
easily that the distribution has not been tampered.

>  I
> understand the main issue of reproducible builds deals with building
> reproducibily from a released distribution archive, not how that
> archive is produced.

If I recall well, the issue with the xz utils was tampering with the
distributed tarball, not reproducible builds.  If it is easier to redo
the distributed tarball independently and compare it should be a win for
security.

-- 
Pat