[PATCH 2/3] scripts: Use ftpmirror in build-many-glibcs.py

[Joseph Myers]

On Fri, 14 Nov 2025, Carlos O'Donell wrote:

> > We used (are) using hardcoded sha256 checksums in the glibc container
> > autobuilders too. See
> > https://sourceware.org/cgit/builder/tree/builder/containers/Containerfile-autogen-glibc
> > 
> > But Sam proposed to use gpg signature checking instead. Which makes
> > version updates easier. You might want to take a peek at the discussion
> > how to use the gnu-keyring.gpg for that.
> > 
> > See
> > https://inbox.sourceware.org/buildbot/168d47063b5286251d749a350b38939d23b77794.1763093965.git.sam@gentoo.org/
> 
> Looks good too. You would detect an invalid signature and it protects
> against tampering. If the attacker has they to sign that then we've
> already lost and they can upload compromised versions at will.

gpg works better as an interactive tool than as something for automated 
verification in a script (where you'd also need to disable any interaction 
with the user's default gpg configuration in their account and instead 
only use a separate keyring and configuration set up purely for these 
downloads).

The basic design principles for how the downloads currently use 
ftp.gnu.org are:

* Trust TLS to ftp.gnu.org as authenticating the downloaded files (this 
does *not* mean trusting arbitrary third-party servers such as 
ftpmirror.gnu.org might redirect to).

* If build-many-glibcs.py is used with persistent state, as is typically 
expected given how expensive each compilers build is, then it only 
downloads tarballs when you set it up on a new system or when the versions 
change, so keeping the load on systems serving the tarballs down.  Even if 
you use it without persistent state, a full build takes a long time and 
you shouldn't be downloading the tarballs more than once for such a build, 
which itself should serve to limit the load on ftp.gnu.org from these 
downloads.

-- 
Joseph S. Myers
josmyers@redhat.com