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

[Mark Wielaard]

Hi Yuri,

On Thu, 2025-11-13 at 09:25 +0000, Yury Khrustalev wrote:
> On Wed, Nov 12, 2025 at 03:53:08PM -0500, Carlos O'Donell wrote:
> > On 11/12/25 2:08 PM, Joseph Myers wrote:
> > > On Wed, 12 Nov 2025, Carlos O'Donell wrote:
> > > 
> > > > I don't object, but I'm just calling out that what we would really like
> > > > in this scenario is a mechanism for attesting that these downloaded
> > > > tarballs are actually what we expect e.g. sigstore etc.
> > > > 
> > > > I wonder if we can't get a light-weight cross check?
> > > > 
> > > > (1) Download the 310 byte signature from ftp.gnu.org.
> > > > (2) Cross check the signature validates for ftpmirror.gnu.org
> > > > 
> > > > Thoughts?
> > > 
> > > How about hardcoding an SHA256 (for example) checksum alongside the
> > > version number for everything where we use a tarball, and making the
> > > script check that?  That seems a fairly common approach for systems that
> > > download a tarball and expect it to have particular contents.  (We'd need
> > > to work out what to do when a user overrides the version number for such a
> > > component on the command line.)
> > 
> > That works for me.
> 
> I like the idea of hard-coding checksums, however updating logic around
> overriding versions via command line goes beyond what I can do right
> now, so I'll have to keep this change downstream.

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/

Cheers,

Mark