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
