Re: publish PGP-signed git bundles of gnulib?

[Bruno Haible]

Simon Josefsson wrote:
> >> 1) If savannah is offline or compromised, having widely mirrored
> >> known-good offline copies of the entire gnulib repository is nice.
> >> 
> >> 2) Output of 'git clone' is not serialized or use a stable format, so a
> >> 'tar cfz gnulib-20241210.tar.gz gnulib/' works poorly.
> >> 
> >> 3) It would add PGP-style authentication and integrity checking of the
> >> repository.  Currently we only offer HTTPS only against Savannah and the
> >> WebPKI is not as strong as trusting a PGP signature directly.
> >
> > These three arguments apply to all packages that are hosted on savannah,
> > from emacs to coreutils, and from libidn to gnutls.
> >
> > Do you plan to propose the same thing for essentially all GNU packages?
> >
> > Or is there a specific reason why you propose it for Gnulib?
> 
> All those other already ship source code on ftp.gnu.org that achieve the
> goal of having a stable archival copy of a project.  Gnulib doesn't fit
> into that model, but not fitting into that model also means we are doing
> away with all the advantages of release tarballs, including the ability
> to have offline copies with a PGP signature on.  This makes the Savannah
> gnulib git repository a more attractive target.  People are relying on
> it to build projects, instead of using release tarballs.

I see, and I agree regarding Gnulib.

Note that some Debian packages are based on git checkouts as well (e.g. [1]),
for example when there hasn't been a release for a long time. I guess that
your proposal is supposed to improve the situation for such packages as well?

> There are other git-only technologies to achieve some of these goals
> (PGP authentication) that we could consider -- for example
> https://archive.fosdem.org/2023/schedule/event/security_where_does_that_code_come_from/
> -- but it doesn't solve 1) above.

Your proposal with published bundles also has the advantages of
  - not getting in the way of how developers work,
  - not preventing commits from developers in countries with authoritarian
    governments (like Türkiye or Iran).

> We could start to do proper versioned releases of gnulib.  Is that
> better?  We are already fairly close to this, with the v1.0 git tag and
> the stable branches.  Maybe that is the closest we want go towards
> making proper releases though, and we don't actually want a
> ftp://ftp.gnu.org/gnu/gnulib/gnulib-1.1.tar.gz.

No, I don't think versioned releases of gnulib are useful. And the stable
branches, while being used by a few packages, have mostly psychological
impact. The most important packages that use gnulib, namely coreutils and
gettext, often rely on very new contents of gnulib, that is not yet in a
stable branch.

> My primary goal is to have something stronger than a HTTPS URL to
> Savannah as a trust anchor for how to retrieve gnulib.  PGP signatures
> on a serialized file, like a tarball or git bundle, is stronger.

Fine with me.

> Going
> towards release tarballs doesn't fully solve this: people aren't using a
> particular gnulib release, they use wildly different git commits of
> gnulib.  I suspect we don't want to release them all as different gnulib
> releases.

Correct. The way gnulib is used by some important packages does not map
to the classical release model.

Bruno

[1] https://packages.debian.org/bookworm/clisp