Bruno Haible via "Patches for the config.guess and config.sub scripts" <[email protected]> writes:
> Simon Josefsson wrote: >> > So, I still don't understand what you mean by "access [to] those files is >> > fairly obscure". What else could be done? Do you want to see them regularly >> > uploaded to ftp.gnu.org, like texinfo.tex is (at >> > https://ftp.gnu.org/gnu/texinfo/texinfo.tex) ? What would be the benefit of >> > having yet another, alternative way of obtaining these files? >> >> Yes, by "fairly obscure" I meant not using the normal tarball-centric >> distribution model, and lack of a strong cryptographic distribution >> mechanism for the files. Having them on ftp.gnu.org would fix that. > > I see. Two possible ways of distributing them on ftp.gnu.org come to mind: > > - Dmitry could just upload these two files to ftp.gnu.org/gnu/config, > whenever they change. > > - Dmitry could upload a tarball config-<DATE>.tar.gz to > ftp.gnu.org/gnu/config, whenever they change, together with a 'LATEST' > symlink (gnupload option --symlink or --symlink-regex). > >> Maybe the GNU config project could publish PGP signed git bundles just >> like gnulib does? Once in a while. > > The problem with the git bundles is the "once in a while": They are > out-of-date by 6 months on average. > > For gnulib, we chose this approach because due to the size of the git > repository, it would be inappropriate to upload a new version every > month or even more frequently. This consideration does not apply to 'config': > The total size of config.{guess,sub} being less than 100 KB, it would be > perfectly fine to upload a new copy every day (-> less than 40 MB per year). > > Therefore I don't think the git bundle approach is the best for 'config'. Indeed, I now agree that git bundles are a bad idea for 'config' -- the difference is that 'config' is intended to be backwards compatible, but for gnulib the earlier git commits are needed to reproduce things. Always having the latest config.sub and config.guess, possibly in a tarball, on ftp.gnu.org would be nice! Uploading the files directly may be better since then the PGP signature would apply to the files directly, rather than indirectly through some tarball which may or may not be reproducible. >> Distributions are moving towards not building from *.tar.gz but to >> directly build from git source, see for example the recent Guix >> announcement: >> >> https://lists.gnu.org/archive/html/guix-devel/2026-03/msg00043.html > > How will this work out in practice? We all know that git.savannah.gnu.org > is occasionally unresponsive, whereas ftp.gnu.org (and its mirrors) > are the more reliable way of handling the download load. Guix uses mirrors for both git and ftp, and some maintainers seems to prefer to rely code from non-primary sites like SWH directly that supports git. I'm not sure if this is a strong required policy though, but it seems reasonable. > And if it _does_ work out in practice, i.e. if the distros are going > to use > $ git clone https://git.savannah.gnu.org/git/config.git > are the proposed copies on ftp.gnu.org actually needed? They will always be useful as a long-term archival comparison, in case of compromised git repository. Git commits are rarely signed, so the PGP signature on ftp.gnu.org would also provide some benefit, even if files are taken from git. /Simon
signature.asc
Description: PGP signature
