Clarifications Re: CTI - Making a decision for glibc.

[Frank Ch. Eigler]

Hi -


I need to clarify several of the claims about sourceware.

>  [sourceware] just cannot implement some things, like turning off
>  From: rewriting on mailing lists that are used for patch
>  distribution.

This is incorrect in several ways.  First, Sourceware literally gives
the power over From: rewriting to each mailman2 list administrator.
You can already turn it on or off as you like.  If you turn it off,
your list traffic will be vulnerable to certain configurations of
modern email hygiene enforcement by others.  This is a fact of
cryptography and RFCs, not a sign of slacking at sourceware.

Second, ironically, the LF "subspace" server offered by kernel.org
folks suffers precisely the same vulnerabilities [1], and further,
doesn't give you the From:-rewriting option to fix them ("not an
acceptable...").  It's also a downgrade in terms of missing ARC.

[1] https://people.kernel.org/monsieuricon/subspace-mailing-list-server
    search for "and hopefully" and "nearly all cases"


> Didn't Sourceware disable https:// Git service at various points as
> part of this (first full disablement, then just the smart
> transport)?

There was a ~six-day period over the christmas holidays where
unusually intense git-protocol scraping hit sourceware.  We
experimented with several options to provide partial service during
the worst of it.  Full normal service was restored weeks ago.

The DDoS had characteristics of many concurrent "git clone"
operations, which unfortunately no OSS git server infrastructure I am
aware of can stand up to, due to the incredible compute-intensity of
the server-side of the git smart protocols. [0] (gitolite is
irrelevant to the topic, it does not affect transport.  ditto
forgejo.)

[0] https://lobste.rs/s/dythih

Ironically, the git dumb transport fares better, because it requires
no server-side compute, just more network traffic.  The last DDoS did
not last long enough for us to require perfecting its configuration.


> We don't want people to direct to git:// as a stable replacement.

That is up to you, but vague claims of "insecurity" don't hold much
water without a relevant threat model.  LF / kernel.org still serves
git:// throughout.  Signed commits/tags make git:// content
verifiable.  git:// and ssh:// remained stable throughout the DDoS
time, and everyone who wanted to work during the holidays could
continue doing so.


> AI scraping is not the motivation for the switch anyway

And yet it's mentioned over and over.


- FChE