Re: Validating tarballs against git repositories
On Mon, Apr 01, 2024 at 05:24:45PM +0200, Simon Josefsson wrote:
> Colin Watson <cjwatson@debian.org> writes:
> > On Mon, Apr 01, 2024 at 11:33:06AM +0200, Simon Josefsson wrote:
> >> Running ./bootstrap in a tarball may lead to different results than the
> >> maintainer running ./bootstrap in pristine git. It is the same problem
> >> as running 'autoreconf -fvi' in a tarball does not necessarily lead to
> >> the same result as the maintainer running 'autoreconf -fvi' from
> >> pristine git. The different is what is pulled in from the system
> >> environment. Neither tool was designed to be run from within a tarball,
> >> so this is just bad practice that never worked reliable and without a
> >> lot of complexity it will likely not become reliable either.
> >
> > The practice of running "autoreconf -fi" or similar via dh-autoreconf
> > has worked extremely well at scale in Debian. I'm sure there are
> > complex edge cases where it's caused problems, but it's far from being a
> > disaster area.
>
> Agreed. I'm saying it doesn't fix the problem that I perceive that some
> people appear to believe, i.e., that running 'autoreconf -fi' solves the
> re-bootrapping problem.
Indeed - I've been pointing this out to people pretty much since the
xz-utils backdoor was discovered.
> >> I have suggested before that upstream's (myself included) should publish
> >> PGP-signed *-src.tar.gz tarballs that contain the entire pristine git
> >> checkout including submodules,
> >
> > A while back I contributed support to Gnulib's bootstrap script to allow
> > pinning particular commits without using submodules. I would recommend
> > this mode; submodules have very strange UI.
>
> I never liked git submodules generally, so I would be happy to work on
> getting that to be supported -- do you have pointers for earlier works
> here?
https://lists.gnu.org/archive/html/bug-gnulib/2018-04/msg00029.html and
thread - it's been in gnulib for some years. (I think you may have
misread me as saying that I'd tried to contribute this and that it never
made it, or something like that?)
> What is necessary, I think, is having something like this in
> bootstrap.conf:
>
> gnulib_commit_id = 123abc567...
This is what I implemented, except I spelled it GNULIB_REVISION. Then
see e.g.
https://gitlab.com/libpipeline/libpipeline/-/blob/main/bootstrap.conf.
> > As I noted in a comment on your blog, I think there is a case to be made
> > for .po files being committed to upstream git, and I'm not fond of the
> > practice of pulling them in only at bootstrap time (although I can
> > understand why that's come to be popular as a result of limited
> > maintainer time). I have several reasons to believe this:
>
> Those are all good arguments, but it still feels backwards to put these
> files into git. It felt so good to externalize all the translation
> churn outside of my git (or then, CVS...) repositories many years ago.
>
> I would prefer to maintain a po/SHA256SUMS in git and continue to
> download translations but have some mechanism to refuse to continue if
> the hashes differ.
I wonder if a middle ground would be automated commits of translations.
I don't think that's as robust, but a number of projects do it (e.g.
d-i) and at least it's amenable to having translations go through CI
rather than just being YOLOed straight into release tarballs.
--
Colin Watson (he/him) [cjwatson@debian.org]
Reply to: