CTI - Making a decision for glibc.

[Arsen Arsenović]

Alexandre Oliva <oliva@gnu.org> writes:

> On Feb  1, 2026, Arsen Arsenović <arsen@aarsen.me> wrote:
>
>> LF seems to be okay with respecting the requirements we do have).
>
> That's not surprising.  AFAICT, the requirements those who have been
> pushing for this solution do not encompass keeping the infrastructure
> under our control, but rather handing it to LF's control.  That's the
> model they understand and operate in.
>
> But that's not the model the Free Software aims for, in which users and
> communities control their own computing.

Community is a very nebulous term.  This so-called CTI may fall under
such a definition.

> The requirements they've put forth to the LF are not representative of
> Free Software needs, they're representative of something else, with at
> best a limited overlap with the notions of software freedom.

Sorry, I don't see it.  They offered dedication to the glibc project and
agreed to run fully Free Software in line with what we expect.

I don't even particularly support the CTI move (because I know the
Sourceware folk better, which is a reflection of my position as an
infrequent visitor to libc), but this doesn't seem correct to me.

To clarify: is hiring a sysadmin relinquishing control and ergo makes
all software ran on hardware managed by them SaaSS?

>> I, frankly, support offloading (substituting, if you will) work of
>> maintainers onto (with) Sourceware infrastructure.
>
> I am also favorable to offloading manual labor to automation, provided
> that the automation is under control of those who rely on it, rather
> than of third parties..

That appears to be the case here?  I'm confused.

>> The infrastructure need be Free, of course
>
> The term freedom-respecting is probably clearer.  It must encompass the
> avoidance of control by third parties to be free as in freedom-respecting.
>
>> We only lose by forcing maintainers to perform work that could be done
>> automatically.
>
> Agreed.
>
>> Compiler Explorer is an example of such a service.  It is immensely
>> useful to us compiler hackers as it allows sharing and comparing with a
>> variety of compilers.
>
> I can see it is useful.  I also see how it can be harmful and dangerous.
>
> I'd much rather be able to install that variety of compilers on a
> machine under my control.  That would have the upsides without any of
> the downsides.

That's simply incorrect.  Most of the upsides are gone.  I can't very
easily share a block of code with a particular compiler, flags, and
output if I only have local compilers.

> Or under control of the community that is going to use it.  That
> wouldn't remove entirely some of the potential harms and dangers, mainly
> related with privacy, but it would be acceptable freedom-wise.

Here I agree.  It'd be neat to have a local CE instance.  But, the
people working on CE are also in the GCC community.

> Now, a server for anyone to submit any program for compilation by a
> large collection of compilers would be training people to submit private
> information to unknown third parties, ...

We know them.  But, that aside, the same argument applies to pastebins.
I'm not convinced.

> ... would be a constant risk of DoS and possibly security issues for
> the server operator, ...

This is correct.  It is a massive load on the CE hackers.  But, not one
that's impossible to overcome.  The Linux family of kernels has decent
namespacing support, which goes a long way in the security department.
DoS is manageable with rate limiting (which is also part of what makes
it not viable to substitute a compiler with CE)

> ... and could (hopefully; I'm allowed to dream, ain't I?) raise
> concerns about how much logging the server operator does, ...

These details are covered on the site:

> Web access logs contain semi-anonymised IP addresses (we remove parts
> of the IP address to make them less identifying) but no other personal
> information. When you visit a long Compiler Explorer URL (the ones
> with # in them), your code stays in your browser and isn't logged. If
> you visit a short URL we created (like godbolt.org/z/abc123), then we
> can potentially retrieve your code from our logs.
> 
> Compilation logs are separate analytics logs that record which
> compilers and settings people use. These analytics help us understand
> usage patterns and plan improvements. We store a fingerprint (hash) of
> your source code along with compiler options, filters, and libraries
> used, but we can't reverse this to see your actual code. These
> analytics are kept for up to 1 year. We may share aggregate statistics
> about compiler usage publicly, but these never include individual
> usage patterns or any way to identify specific users.
> 
> Amazon infrastructure logs: We use Amazon's servers to run Compiler
> Explorer. Their logs (which help us debug issues and block attacks)
> contain full IP addresses and are kept for up to 32 days, then
> permanently deleted.
> 
> For error reporting: If something goes wrong in your browser, we use
> Sentry to help us fix it. This keeps your IP address and browser
> information for up to 90 days.
>
> If we need to share data with new third-party services in the future,
> we'll update this privacy policy accordingly.

There's more details, but this paste is already quite long.  You can
read the rest on https://godbolt.org/#privacy (requires JS due to the
nature of the service.  Let's agree skip the JS discussion).

> ... how the submitted programs end up being used, ...

They get compiled.  Compilation results and side effects are sent back.
Then they're deleted.

If shared, they're stored for longer, as detailed in the policy.

> ... how the results are twisted to favor one compiler or another.

What?  What could be twisted here?

Sorry, but this is undue paranoia towards people who are part of the
toolchain community.

>> And, it is not practical to replace a compiler with Compiler Explorer,
>> so if one of the ess-es in SaaSS is "substitute", then CE cannot qualify
>> for it.
>
>> CE is, of course, free software.
>
> It's important to distinguish between the software and the service.
>
> When you install it on a computer under your control, you're installing
> software, and then you may possibly be using it in freedom, if the
> software is self-contained (as opposed to being a frontend to a remote
> service) and freedom-respecting.
>
> When you use it as a service provided by a third party, you have no
> control over it, even if the operator installed free software to provide
> the service.  So that deployment is not free for you.  It's a service.
> Services aren't free or nonfree, they are SaaSS or not.

I'm aware.  You can locally run CE just fine.  And, as I went over, you
can't reasonably substitute compilers with CE.

>>> But performing server-side GIT merges, for example, is SaaSS if the
>>> server is operated by a third party.
>
>> ... and here we have a perfect example.  Merging patches requires
>> tonnes of drudgery, specifically the drudgery of testing (and sometimes
>> testing twice and comparing as for GCC for instance unfortunately) on a
>> variety of machines.
>
> Hmm, I hear you, but ISTM we miscommunicate.
>
> By "merging patches", I meant:
>
> - taking as inputs (a) a patch (or patchset, but let's make it singular for
>   simplicity), (b) the commit it's based on, and (c) the commit at the
>   top of the tree
>
> - computing and producing as output (d) a corresponding patch based on
>   commit (c).
>
> Although that's deterministic and relatively simple, that is computing
> that could be done under one's (the community's) own control, so doing
> that under someone else's control qualifies as SaaSS as long as we
> understand that it's one's (the comunity's) own computing.  It's pretty
> hard for me to find how it couldn't be.
>
> Now, perhaps I should have more accurately phrased it as "rebasing".
> Apologies for the confusion.  Terminology over multiple VCSs, Forges and
> whatnot isn't exactly consistent, and that's why it's useful for us to
> detail what we mean in terms of requirements, features and expectations.
> It's far too easy to find out too late that we've had misunderstandings
> because different terms mean different things to different parties.

The point of contention was not what exactly 'merge' meant.  I
understood it as 'patch application.  So that's fine.

> Automating testing is something that doesn't require SaaSS,
> fortunately.  I can easily envision contributors who (voluntarily and
> automatically) fetch proposed changes, or batches of changes, test
> them on their favorite targets, and add notes to the proposals about
> success, or regressions.

Running a forge on Sourceware achieves precisely that.

> I can also envision Forge support to aggregate such results, to make
> it easy for reviewers to decide whether it makes sense to review a
> proposed change.
>
> ISTM it would be quite easy to automate rebasing on the community side,
> even using a third-party repository host.  You already have your patch
> on your end, you probably have a program (git itself?) to upload your
> proposed changes to the server, and to fetch the top of the tree at the
> server, so there could easily be something running under your control
> that rebases your pending changes and uploads them to the repository.
> Community contributors could run a very lightweight program on old
> single-board computers behind low bandwidth to do such things under
> community control.  Others could run programs to flag when unexpected
> differences arise in rebases.
>
> These are ways that come to mind to make up for a server's running under
> someone else's control.

I don't see how Forgejo running on Sourceware hardware is problematic
here.  Ditto for Patchwork running on Sourceware hardware (all the
problems with Patchwork are technical).

Ergo, I do not understand what the issue is.

That is computing in our community hands, is it not?

You're describing a Forgejo runner here, by the way.  It does precisely
what you say.  It pulls code from the remote server onto, say, an SBC,
executes the scripts configured in the repository, and sends back
results.

>> If the above is not SaaSS, then no SaaSS was proposed.  If it is, then
>> it's not a useful category, as it's in clear conflict with something
>> actually useful.
>
> Avoiding SaaSS doesn't rule out useful computing, it rules out
> relinquishing control over your computing.

What SaaSS is there on Sourceware then?  Is it not the case that
Sourceware, as part of our community, running software, cannot be SaaSS?
Would the same not go for CTI(? is that the name of the actual entity
running computing or some advisory..?  I didn't follow the discussion,
so assume I mean the former) if they are part of the libc community?
-- 
Arsen Arsenović
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 418 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20260208/da31e7c2/attachment.sig>