Trust in FOSS Ecosystem: Maintaining What’s Harder to Build
What is Trust?
to believe that someone is good and honest and will not harm you, or that something is safe and reliable - Cambridge Dictionary
A belief that may not necessarily have a strong backing to it. Because in computer science, a concrete proof is structurally impossible past a certain point.
Ken Thompson, who co-created Unix at Bell Labs, in his 1984 Turing Award Lecture, presented what he titled “Reflections on Trusting Trust”. The lecture is available as a 3 page PDF and is a very interesting read, especially for those from the computer science background or anyone interested in compilers. But to quickly tell you the part that I wish for you to grasp at this moment, is that you cannot trust any piece of code you didn’t write yourself.
flowchart LR A[CODE] --> B((COMPILER)) --> C[BINARY]
You likely trust the code and have audited it to the best of your standards. But who guarantees that your compiler isn’t injecting a trojan before spitting out the binary?
The audit of source code can never fully close the trusts gap, because audit happens at a layer very different than the layer where it finally gets executed. A compromise that happens on a lower level is invisible from the higher layer.
In the case of Ken Thomson, he demonstrated how an evil compiler could recognize when its compiling itself and inject the backdoor into the new compiler binary too, thereby propagating itself. Backdoor survives even if no longer exists in the source code. Vulnerability becomes self perpetuating and invisible at the source level.
If we read the abstract of this lecture, I think Ken Thompson gave us a very important piece of advice:
Perhaps it is more important to trust the people who wrote the software.
We’ll come back to this later.
The older trust model in open source
We as end users or enthusiasts usually see a couple of things before building trust in a project we see online. The factors we check usually falls somewhere in here:
- code is open source
- actively developed / maintained
- no serious CVE
- developer responds to issues
- releases are signed
- forums, wiki pages are correct
- I trust my distribution package maintainers
The problem is, we didn’t know that establishing trust is HARD. Because none of the above can truly guarantee if a project is supposed to be trusted. And going further, if you have any kind of half serious threat perception, the above points are actually a very bad way to judge usability of a software.
We’ll see just that.
XZ-Utils backdoor
- The release was prepared by a maintainer
- Release tarball was signed
These are usually meant to induce trust in end users. But this very trust was sabotaged, when the said maintainer, Jia Tan turned out to be a malicious intruder who had spent a 2 years building reputation and getting access to the codebase and release cycle.
build-to-host.m4 file was added to release tarball, but never to the repo itself. There was poor transparency in the build process. The malicious step lived in the build step, not the source itself - which is the layer that Ken Thompson talked about way back in 1984. Commits were clean, tarball signature was valid, but there was a gap between the two which became the attack surface.
What really got compromised was our trust in the persons pushing out releases.
To quickly explain what how this worked, during configure step, the poisoned build-to-host.m4 file decodes a test file thats disguised as a broken compression test sample. That decodes into a script which decodes another disguised test file into a pre-built object file. This gets linked into liblzma during make step. Eventually, at the user’s end, an attacker holding a specific private key could smuggle a command through SSH authentication step and have an successful RCE.
Quite similar to what Ken Thompson warned us about - the malicious code was injected at build step, not at the source.
The attack also brought to attention the fact that trust is transitive. You better be careful before trusting someone else because there are people out there banking on your judgement.
Shai Hulud - A Quick Glance
A self propagating supply chain worm, targeting NPM ecosystem that was harvesting sensitive data and exfiltrating it, while also publishing malicious NPM packages through stolen token to propagate itself. And if it found a GitHub token which it later detected to be revoked, it’ll just wipe your home directory.
It attacked not one, but multiple points of failure, all of which were running on some parts trust and that trust is the new attack surface.
Importantly, Shai Hulud targeted the identity and credentials layer. The code itself was fine and the systems meant to ensure identity were also going what it was supposed to. Little could the systems figure out that tokens were in fact, stolen.
What could’ve been done better?
- phishing resistant hardware keys, like FIDO; MFA
- short lived tokens, use OIDC for that, isolate your CI runners, protect your development environments
- of course, following the principle of least privilege for any account you create
- the dependents should have better version pinning so they’re not automatically making users download newer versions
- have phased package adoption: worst case - you delay the inevitable; best case - you protect yourself from another attack
- reduce dependency sprawl: there’s no need to add dependencies that reduce maybe twenty lines of hardwork
The important point is, this is a layered control, trying to improve upon every step of the process. This defence in depth approach is a precursor to better trust in the ecosystem.
Beyond just large scale supply chain attacks
As I initially said, the attack surface will increase dramatically, to exploit the processes which were based largely on trust.
Take for example, the Arch User Repository. Any user can make an account and start publishing package build scripts in a few minutes. You can also adopt orphan packages so maintain them.
I believe every Arch user in the room has had enough warnings about considering AUR packages as unsafe by default and vetting all PKGBUILDs. Despite all, we didn’t have trust issues with this. Until June 2026.
 |  |
|---|
Orphan packages on AUR were being mass adopted by new users who updated it to install rogue NPM packages in the post install step. Not a new attack vector per se, but newly exploited for sure.
The malicious post install hook made its way into over fifteen hundred packages and it was meant to scrape developer secrets, browser data and passwords. It even came with remote access trojans and persistent systemd services to allow persistence.
What layer was compromised this time? The public trust based package adoption layer. We trusted the package adopters to do good for community. Turns out, attackers took advantage. Notice how the 3 examples we took had a similar pattern of public code being okay while a trust based mechanism failing to do its job. The artifact you audited wasn’t the artifact you were running.
Its not just the supply chain
Supply chain doesn’t mean only your packages. It encapsulates every piece of knowledge that results in the product you run. Next time you trust the Arch Wiki (which is user contributed), you better hope you’re not doing anything problematic.
For the ricers out here, I hope you don’t download random dotfiles repos and run whatever scripts they bundle. And if you’ve installed enough applications on a Linux system, you’ve likely seen the official install process requiring you to curl a shady script and pipe it into bash. Not very confident of that being safe.
 |  |
|---|
The trust you have in practices that are supposedly common will be exploited. The tools you’ve used to traditionally gain trust will be exploited.
A “good” example - Flathub
In light of whatever we’ve discussed up until now, let’s take a look at a better (not perfect) platform for distributing packages.
Most of you have likely heard of Flatpaks, if not used it first hand.
Flathub, which is one of the repositories from where you can fetch Flatpaks, has a completely open build system.
If you head over to builds.flathub.org you can see a log of all the builds that have taken place for each application published on their repository. You can see running builds, past builds, their status, logs, the commit which triggered that specific build.
Each and every manifest is open source, so you can go and inspect it and even build it yourself locally.
While not perfect, this certainly brings in more trust in the source code to package process.
There’s of course more that can be done to bring in more trust into this process; nonetheless, I find this is a good step forward and wish for more package ecosystems to adopt such an approach that puts transparency as an important value.
Another example - Nix
While Flathub makes the process transparent, Nix takes this idea further by making the build process deterministic.
Package build process is defined in a declarative build expression, wherein every dependency, patch, source, and even environment variables are an explicit input to the final artifact. The resulting package path itself has a cryptographic hash derived from these inputs.
A single change in these inputs, say, the compiler version, will completely change the final artifact. This, combined with reproducible builds, allows independent parties to rebuild pa package. You and I can open our laptops and build a package that’s published and we both will end up with the same output that’s distributed in the repository.
Note that simply by using Nix, you’re not eliminating the chance of getting a back-doored source or a malicious patch. What Nix is ensuring for us is to reduce the gaps between source and binary. It makes trusts claims auditable and minimize hidden steps, so that independent parties like you and I can verify the chain.
Why trust needs to be re-evaluated?
Back to the original question - why am I talking about trust so much? Are the processes not enough?
We need to care about trust because FOSS is the only thing capable of earning trust. Proprietary software with their “trust me bro” model aren’t cutting it for long. FOSS, done right, lets you trust a mechanism that’s verifiable with an audit trail. And thats already way better than trusting a proprietary vendor claim.
So its beneficial for us to work on ensuring how that trust is ensured and how even smaller projects can adopt practices that fill the trust vacuum.
FOSS is gaining prominence. More users, more attacks. Simple. This requires that the open source trust model come up with better and verifiable means to establish itself.
Whenever you ship anything, add a deliverable: trust. We are shipping more than just software.
What should we be doing, moving forward?
A paradigm shift that is required - and in fact already being done - is that trust is based in things beyond just the availability of source code.
- reproducible builds - let anyone verify that binary indeed matches the provided source, without trusting builder
- Sigstore/in-toto - automated, keyless code signing
- Rekor transparency logs - tamper evident public record, so that you don’t have to blindly trust private claims
- publicly available build logs - like how Flathub does it
- automated & transparent release process to let users do their due scrutiny
However, like all software we’ve seen up until now, vulnerabilities and gaps will be discovered in these new age systems too. And when your systems are in a limbo, its important to go back to what Ken Thomson said:
Perhaps it is more important to trust the people who wrote the software.
A big thanks to all the maintainers who build amazing open source software and let me find more trust in my day to day interactions with technology.