Working together and gaining trust

[Alexandre Oliva]

On Feb 13, 2026, Claudio Bantaloukas <claudio.bantaloukas@arm.com> wrote:

> I think that it's a similar situation to the "If you rent a server
> (real or virtual), whose software load you have control over"
> situation.

[...]
> then freedom is maintained for all entities involved.

*nod*

>>> Hopefully this shows that a forgejo instance is inherently not SaaSSy.
>> These are no doubt interesting design elements.
>> I'm still worried about the computing that goes into patch
>> merging/rebasing.  (Incidentally, on a related concern that has nothing
>> whatsoever to do with SaaSS, I don't see how requiring originator-signed
>> commits could even possibly work with server-side rebases)

> I believe you're talking about commit hooks that impede commits based
> on quality controls etc.

At that point I wasn't.  These are important bits of computing as well.
But I was really thinking of the computing that goes into running patch
or git am or git rebase to apply a patch onto a different tree (or
detect conflicts that need manual resolution).


> In the native way of using forgejo, each project defines workflows
[...]
> Control is with the project, it's just that the way it's applied is
> unfamiliar to some people.

Are you familiar with Github Actions?  I can't be used by Github myself,
but I've loooked into this feature's documentation very briefly
recently, for something I'm writing about Github for GNU, and one could
come out of your description with the notion that projects have about as
much control about the computing performed as part of the defined
workflows in both cases.  Would you agree with that assessment?

Now, that, along with enabling runners on project-controlled machines,
could make it seem like none of this is SaaSS.

But ISTM that the orchestration (I don't think it uses this term) of
actions (their triggering, sequencing, parallelization, conditional
execution, loops and whatnot), and the interpretation of the language in
which these concepts are expressed by the project to the workflow
engine, are also important project's computing, and AFAICT there are
fundamental barriers for projects to take control of these computing
activities in Github.

E.g., if you wanted to extend the orchestration language or the workflow
engine, Github wouldn't allow you.  That's IMHO a freedom bug, a case of
SaaSS.

Doesn't this apply to Forĝejo as well?

> The documentation of forgejo's signing feature is here
> https://forgejo.org/docs/latest/admin/advanced/signing/

Thanks.

> When it comes to originator-signed commits, server side rebases lose
> the original signature.

Yeah, that was the concern.  I figured it would be a problem if the
server could make a new signature as if it had been made by myself.  But
if it is a project's rebase signature, that makes sense from a security
standpoint, and if it refers back to the contributor-signed commit
somehow, even the provenance can be tracked.  OTOH, this would be
project's computing (so SaaSS if done under other's control), and this
would be security sensitive, so keeping keys under control of third
parties would be very questionable IMHO.

> When it comes to rebasing or having merges performed using a merge
> queue mechanism, I understand your worry. But I think these should be 
> classified as "not any single party's computing".

I'm afraid I don't see it as anything but the project's own computing.
Who else might be involved ot the point of having a claim over it?

> Specifically, the rebasing mechanism in the forges is not there merely
> to perform git rebase on behalf of the developer.
> It's there to avoid having to do a full check of a change once the
> rebase succeeds. It's there for the project (that doesn't want to run 
> the full testsuite every time a rebase occurs), the reviewer (who
> doesn't want to have to do a review again), the developer (who doesn't 
> want to wait for the reviewer).

These all seem important reasons to me.  So important that, to bypass
confidently each of these (presumably) self-imposed project
requirements, the project needs to place plenty of trust on the rebasing
engine.  Which brings us back to the importance of the project's having
control over that simple but very critical computing detail.



>>> When it comes to the service that Carlos is proposing that openssf
>>> provide, things are even clearer. gitolite is so barebones it squarely
>>> fits the "Use of simple software repositories is not SaaSS" rule.
>> I don't know a lot about gitolite, but if all it does is publish the
>> code and selectively accept pushes from authorized git users, it's not
>> even doing anyone's computing.  Server-side commit checkers, however,
>> could be SaaSS depending on who controls them.

> Funny that, I'd classify authorization as computing myself.

Me too.  But is it gitolite itself that performs it?  I figured (from
the bit about delegating user and group management in your email) that
it would be a different component, that presumably also does
authentication, though even these two processes may be detached.

>> SaaSS) that would make it a poor idea to delegate such key piece of
>> self-control infrastructure to a third party?

> In both cases the service provider controls the infrastructure,
> notably for blocking abuse. The projects then have authority over who
> can do things on the project.
> The only reason not to delegate such control is if you think the third
> party won't do the job fairly and neutrally on behalf of the project.

I can think of at least another reason that's kind of important to me:
project's freedom/autonomy/self-control.  Not having security from the
provider/supplier is typical of SaaSS/nonfree arrangements.

> That's because web servers are programs. They transform data on its
> way to the intended recipient and thus are computing.
> And they can make very important choices on the way:
> - who gets access, who gets to push
> - whether the format is accessible or not by (categories)
> - whether to allow discourse and under what terms

It looks like you've broadened "publishing" to "web serving".

The way I understand and mean it, publishing makes very little room for
servers to make decisions.  They take what's given them to publish, and
make it available to anyone who requests it.  Think uploading a
formatted PDF for publishing, so that then anyone can download it from
that server.


Now, publishing a git repository is a little more involved than that.
There is server-side computing to figure out what blobs and deltas to
send based on what the other end already has, but the ultimate goal is
to deliver the bits in the requested commits/refs to the other party.
That's publishing.  Computing the pack to send efficiently is
legitimately the server operator's computing, involving some
communication with the other party.


Likewise, some of the web server scenarios you mentioned may also
qualify as legitimate server operator's computing.


It is not infrequent for something that we often think of as a single
bundle involves various different computing activities, and in some
cases, they don't all pertain to the same party.  Self-hosting makes it
easier to figure out because host and guest collapse into a single
party, but third-party hosting requires figuring out who deserves to
control each piece.

> I can't find a coherent argument as to why publishing and mediation of
> communication is "no single party's computing".

The arguments are different.  I went through publishing above.

Communication is easier, because it necessarily involves more than one
party, and it very often involves mediation.  When I hit send in my MUA
I might conceive of it as my own computing, but it will take various
other parties' computing for it to reach you.  From my MTA, it will go
to GNU's MTA, then on to Sourceware and to your employer's MTA, and
eventually you'll do your own computing and open your inbox to read
this.  Even if we were holding a private conversation and only used our
own private MTAs, the communication would still necessarily involve two
different parties who each lays a legitimate claim to the part of the
required computing that occurs on their own MTA and MUA.  It wouldn't
make sense for the entirety of the computing necessary for the
communication to be under control of either one of us: it takes two
(presumed autonomous) parties for communication to take place.

As for mediation...  even if my MTA talked "directly" to yours, that
would go through network interfaces, routers, and other network
components that do computing that implements lower-layer networking.
Routing and delivering network packets in lower layers is not very
conceptually or ethically different from routing and delivering
networked application (higher level) packets.  This mediation
legitimately belongs with the mediators, and control over our
communicating agents legitimately belongs with each of us.

But none of the three or more parties could legitimately lay a claim for
all the computing encompassed by this communication, so it's "no single
party's computing".


Now, if we were talking about internal communication between
parties/agents within a single organization, then it might make sense to
insist that the organization should have control over both ends, and
even over the network they use to communicate.  But even if it resorts
to third-party transport of packets, say between different buildings or
even different countries (planets anyone? ;-) that wouldn't amount to
SaaSS, because the routing, transport and delivery are not the
organization's own computing.


> Like saying that a system applying git rebase neutrally for all that
> ask and reporting the result is ok because it involves three parties: 
> developer, infrastructure provider and project.

That seems a stretch.  The rebasing could be each of the three parties'
computing if done for each one's own sake.  But when it's done by the
project's forge to integrate a commit into a project's branch, it's hard
for me to conceive of it as anything but the project's computing.

> Or a system that applies a specific logic on whether to authorize a
> user because it involves the same three parties.

Authorization is not computing that involves the possibly-authorized
party, it's the project's computing to figure out whether the project
wishes to authorize the party to do something.  Authentication is
similar in most respects (the project wishes to verify the party's
identity), though it may also involve some computing on the requesting
party's end to prove the claimed identity (and that could be the
autonomous party's computing, or the organization's computing).

>> Not the sort of analysis that could
>> be done in a battlefield, for sure.

> I'm glad we're debating in good spirit :)

Oh, the two of us absolutely are.  Some others are, too.  But the
initial hostility I got from others is surely not gone; if they're even
paying attention, it's presumably dormant.

>> Another important consideration, that I realized after posting my
>> earlier message to you, is what recourse the project has if a service
>> provider refuses.

> Yours is a valid concern on a concrete risk.
> But it must be weighed agains other risks, the most important being
> the inability to find these helpers for a self-hosted infrastructure.

That's a concern even when it comes to free software running on one's
own computer, it doesn't render the software nonfree.

Giving up control over your computing to a third party who discourages
you from controlling your own computing whether through self-hosting or
by giving you enough control to the third party's infrastructure that
would do your computing, doesn't sound like a great idea.  Do you see
how threatening and manipulative that would sound? :-)

> That risk is the reason why shared infrastructure projects like
> sourceware, savannah, gitlab and github are such successes.

I don't think so.

I've seen enough replication of anti-patterns made popular by
exploitative providers, wherein the patterns become prevalent and
familiar because they serve the provider's exploitative business not
becuase they serve users, and they're pushed into popularity not by
their own merits or user preference, but by sheer market power of the
provider.  I'm thinking of things like doom infinite scrolling, user
tracking for ad placement, instant messaging expectations of zero-rating
and message presentation, imposition of LLMs, ...

The list is huge, and I know that pushing businesses and users to rely
on the so-called cloud (somebody else's computer) was largely driven by
claims of cost savings that match perfectly the early days of services
that eventually lock users in and then change the deal towards
enshittification so that the provider can finally reallocate the value
that previously attracted users to itself.

That Free Software projects often imitate these anti-patterns is
sometimes an unfortunate consequence of pursuing familiarity, but other
times it seems to be mindless imitation without understanding the
purpose behind design decisions that, in the original, are meant to
benefit the provider despite the harm brought upon the users, which
doesn't belong in user freedom-respecting projects.

When it comes to community hosting and forges, there are far superior
designs that don't enable the centralization and transfer of power over
the project to third parties, without loss of convenience to users.  GIT
is a great example of the sort of decentralization and avoidance of
power-over-others, but instead of going for something like peer-to-peer
hosting with client-side operations (as in git-ssb, gittorrent,
radicle), with issues and whatnot replicated along with the project's
code (as in pagure IIRC), we got Github with recentralization and tons
of plugs for lock in.

That's driven by market power, and lock in motivations, not by superior
user-driven design.

It's not a model to be mindlessly imitated, but to be questioned and
avoided, for our own sake.  Projects should aim to graduate to
autonomous self hosting, and good hosts, like good parents, should
encourage and facilitate that, rather than foment dependencies.

> - People who historically agreed with the four freedoms may disagree
>   with subsequent philosophical additions like SaaSS.

They may fail to realize that SaaSS brings about the same denial of
freedoms, but if they actually agree with the four essential freedoms
for users to control their computing, once they realize that SaaSS
denies them, and does so for the same reasons, either they embrace that,
or they didn't agree with the four freedoms to begin with.

> - People can disagree over details of what is and isn't SaaSS.

That's undeniable, but it's not as important as whether the disagreement
is well founded on Free Software philosophy and values, or based on a
reckless or ignorant disregard for our freedoms, for our control over
our computing.

> - People who are aware of the notion of SaaSS can disagree over what
>   the risk is and what to do about it.

That is true, and the same goes for programs that are widely recognized
as nonfree software.  When people deal with their own personal
computing, their risk assessments are up to themselves.  When we speak
of the GNU project, or a key part thereof, GNU values are paramount, and
GNU maintainers ought to uphold them, even if in their personal digital
lives they might be willing to be more reckless and less concerned about
their own freedom.

> - Most importantly, people mey be using a different thought framework

People in general may; GNU maintainers shouldn't.  Especially while
claiming to be aligned with GNU and Free Software values.

> I doubt that Carlos, David and Joseph are unaware or uncaring of FSF's
> position on this matter.

Their obligations towards the FSF are governed by the Working Together
fiscal sponsorship, but I guess that's not what you're speaking of.

I think you mean GNU.

They have responsibilities towards GNU as appointed GNU maintainers.

Their actions as maintainers have to be in line with that.

I have no evidence (I) that they understood SaaSS and why everyone
should avoid it just like nonfree software, and GNU packages more so; or
(ii) that they as much as care about what GNU leadership thinks about
the proposal at hand.

GNU maintainership is a delegated responsibility, and it's not
unbounded.  It doesn't look like they care about that either.
Unfortunately, getting money flowing from one of LF's hands to the other
to corrupt key pieces of GNU into giving up their own software freedom
is notably a lot higher in their priorities than caring about GNU values
and leadership structure.

> The whole point of that setup is to make 
> funding available for the projects that the sponsors depend on.

The funding is not available for the project, alas.  From all I've
heard, it can't be used by the project except to pay back that who
offers us the funds.

It's a divisive maneuver that offers "help" we haven't wanted, saught or
needed, to drive us to betray our values.

The proper term for that is corruption.


It also "buys" control of critical infrastructure, and for nothing,
because the money all necessarily goes back to the buyer.

>> That's valuable, but it's no substitute to being able to make changes
>> autonomously, without having to walk away from our own infrastructure.

> Indeed, but the glibc project doesn't have infrastructure where it can
> make autonomous changes today. Or this thread would not have been a
> thing.

We're on infrastructure that appears to care about enabling our
autonomy, even at its own inconvenience.

Whereas the proposed infrastructure seems to be attempting to mislead us
by insisting that everything would be implemented with free software,
without disclosing that it would mostly be SaaSS; heck, without even
understanding what SaaSS is, and that it renders otherwise-free software
nonfree, to the point of *attacking* and *dismissing* objections to
SaaSS.

It doesn't look good at all.

> To bring this to a more technical argument, I would love it if you
> could volunteer some of your time. The deployment of the sourceware
> forge could use some code review, in particular this change where I
> move the forgejo process to a container based deployment is open for
> debate:
> https://forge.sourceware.org/forge/forge/pulls/16

I've managed to find the patch in that web page.  It's pretty hard to
find.  The page looks like a nightmare to me; it doesn't seem to be at
all interested in cooperating with users who wish to keep control over
what software runs on their browsers.  On my personal computers, I don't
allow third parties to install and run arbitrary programs under their
control, because they would be nonfree for me even if they're free
software for the server operator.

As for the patch proper, I don't think I'm the person you're looking for
to review this, for it goes way over the top of my head.  I'm not at all
familiar with the technologies you're using there, so my review wouldn't
be of much use; I certainly wouldn't be comfortable approving this
because I can't tell what the implications are of the changes.

I do have one point of concern, though: I followed a URL in public
archives, I didn't have to authenticate, and yet I could see a patch
that changes a secrets file, including the addition of a private key.
That feels disturbing.

-- 
Alexandre Oliva, happy hacker            https://blog.lx.oliva.nom.br/
Free Software Activist     FSFLA co-founder     GNU Toolchain Engineer
Learn the truth about Richard Stallman at https://stallmansupport.org/