forge vs gitolite (Re: CTI - Making a decision for glibc.)

[Zack Weinberg]

On Mon, Feb 2, 2026, at 10:18 PM, Alexandre Oliva wrote:
> On Feb  1, 2026, Gabriel Ravier <gabravier@gmail.com> wrote:
>
>> I don't get what the issue with patch merging is, exactly.
>
> The issue is precisely that it's your computing, so you should do it
> under your control.  If you do that under someone else's control,
> that's the definition of SaaSS.
>
> We can consider it the community's computing, at which point it should
> run under the community's control.  If the Forge runs under the
> community's control, that would be fine, it wouldn't be SaaSS.  But if
> the Forge is controlled by a third party, then we have a freedom
> problem, because it would be SaaSS.

This aspect of the argument is sufficiently esoteric to me that I need
to ask for clarification.

The thrust of the _rationale_ presented for avoiding SaaSS is that we're
giving up control over what software is used on the service provider's
machines and how it's configured, but this is a problem for services
provided by the community as well.  Savannah, for instance, is
unambiguously a service provided by the community.  Its Git server is
running an old version of sshd that doesn't understand SSH keys stored
on a hardware security module.  This forces me to keep an old, short,
RSA-based ssh key around on my personal computer, which is a security
issue for the entire community -- it would be significantly easier for
someone who cracked my PC to use that weak key to compromise Savannah
git repositories, than any other git repo I have push access to. I asked
the Savannah maintainers when sshd would be updated and was told that
there was no schedule for this.

Also, consider the Compile Farm.  It is run by people who I don't know
well, and who actively refused to update sshd on Farm machines, when I
made the same request to them.  They are probably within the "community"
if that is defined in a broad sense, but I do not see a good way to
define the boundary of "the community" such that it includes the Compile
Farm's maintainers but does not include the Linux Foundation.

So I don't currently see how insisting on avoiding use of services
provided by organizations who are more on the "open source" side of the
large "FLOSS" umbrella actually gains us much of anything in practical
terms, assuming Andrew Pinski's concerns re synchronous support are
addressed.

I'd appreciate any clarifications Alexandre, or anyone else taking the
same position, can provide.

zw