As someone who can read code, lol.

In a democracy, it is important that the election process is understandable and verifiable by a layman. But how many people actually go to verify their elections? Barely anyone, so how and why should you trust the election??? Omg, the end is coming!!! Back in reality, enough people verify the elections and the fact that anyone can check creates the threat of detection. That makes elections generally safe.

Now with open source, a layman can’t understand it or verify it, but they don’t need to. They have to use software that seems to be heavily controlled by non laymans. Compared to closed source software, this is a huge improvement.

This is strikingly similar to an account on reddit that has been posting variations of some LLM-generated screed about the supposed problem of trust in open source. I wonder what the end goal of this is.

If a soft or service is trustworth or not, only depends on the author and the community behind. Nothing worse and dangerous than a software unattended or abandoned by the author, more so if it is OpenSource, where it is easier than in closed source that an asshole add or modify some lines as a little gift,when there is nobody to control it. FOSS is great in new projects, because allow to an coope developement and the access of needed resources, but it isn’t necessarly sinonym of privacy and security, most APIs included in a huge amount of soft are OpenSourcemade by big companies, like Google, Microsoft, Facebook, Amazon and others and not precisely because privacy. Adding also a huge amount of FOSS made by these companies. The normal user only can relay on the TOS and PP, or audit the product with Blacklight, WebbKoll, DomainDigger and similar.

I think of it like dictatorship vs. democracy. Both will have corruption. But it’s better to have corruption in a democracy where you may be able to find it and in some cases get rid off it than in a dictatorship where you might get punished for bringing it to light.

I don’t code so I can’t possibly audit FOSS software. However, I also can’t audit proprietary software. Lots of people can and do audit FOSS software, though, and can and do share their findings. But no matter how many people “audit” propietary software, it remains propietary - a black box. Untrustable, especially considering corporations’ incentives and historical actions.

I’ll take FOSS over the proprietary software we can be sure will do malicious things to us any day.

Distributions handle this for you. Installing your software through a distro, instead of getting it from each individual software authour, means that you trust one organisation instead of hundreds of individuals.

For instance, Debian has a strict set of guidelines for Debian developers (who have the right to upload packages). They will be familiar with the software they are packaging, are often independent from the upstream authours, and are expected to check the package for various issues, including licensing, security, version incompatibilities etc. In addition, every upload is signed, so you can see who is responsible for everything.

And when something slips through, as almost happened with xz, the analysis and recovery all happens completely in the open. There may not have been enough eyes on xz to prevent the vulnerability in the first place, but once it was discovered, there were at at least hundreds of people dealing with the aftermath, all in the open.

Compare this with proprietary software, where you’d be lucky if such a vulnerability was even disclosed, vs just silently patched.

Hopefully more projects take advantage of vulnerability scanning and monitoring tools like those in this OWASP list https://owasp.org/www-community/Free_for_Open_Source_Application_Security_Tools, have good code quality standards to make their projects easier to understand and evaluate, contribute and respond to CVE reports, and get third party security auditing.

All of that is hard to motivated those throwing their code out to the world only to share how they scratched their itch to perform. I think we need a combination of governments and non-profits providing incentives / grants to projects doing good practices, document and provide trusted a forum to validate vulnerabilities, give some backing to “trusted” frameworks, and provide some vulnerability and auditing themselves.

The recent EU push into more government open source usage will help as they will be more incentivized to secure the pipelines and everyone will benefit the fruits of that firehose of funding.

Take Open Source with a Grain of Salt: The Real Trust Dilemma

In the age of open-source software, there is a growing assumption that transparency inherently guarantees security and integrity. The belief is that anyone can check the code, find vulnerabilities, and fix them, making open-source projects safer and more reliable than their closed-source counterparts. However, this belief is often oversimplified, and it’s crucial to take open-source with a grain of salt. Here’s why.

The Trust Dilemma: Can We Really Trust Open Source Code?

There’s a famous story from the world of open-source development that highlights the complexity of this issue. Linus Torvalds, the creator of Linux, was once allegedly asked by the CIA to insert a backdoor into the Linux kernel. His response? He supposedly said, “No can do, too many eyes on the code.” It seems like a reassuring statement, given the vast number of contributors to open-source projects, but it doesn’t fully account for the subtleties of how code can be manipulated.

Not long after Torvalds’ alleged interaction, a suspicious change was discovered in the Linux kernel—an “if” statement that wasn’t comparing values but instead making an assignment to user ID 0 (root). This change wasn’t a mistake; it was intentional, and yet it slipped through the cracks until it was discovered before going live. The question arises: who had the power to insert such a change into the code, bypassing standard review processes and security protocols? The answer remains elusive, and this event highlights a critical reality: even the open-source community isn’t immune to vulnerabilities, malicious actors, or hidden agendas.

Trusting the Maintainers

In the world of open-source, you ultimately have to trust the maintainers. While the system allows for community reviews, there’s no guarantee that every change is thoroughly vetted or that the maintainers themselves are vigilant and trustworthy. In fact, history has shown us that incidents like the XZ Utils supply-chain attack can go unnoticed for extended periods, even with a large user base. In the case of XZ, the malware was caught by accident, revealing a stark reality: while open-source software offers the potential for detection, it doesn’t guarantee comprehensive oversight.

It’s easy to forget that the very same trust issues apply to both open-source and closed-source software. Both models are prone to hidden vulnerabilities and backdoors, but in the case of open-source, there’s often an assumption that it’s inherently safer simply because it’s transparent. This assumption can lead users into a false sense of security, which can be just as dangerous as the opacity of closed-source systems.

The Challenge of Constant Auditing

Let’s be clear: open-source code isn’t guaranteed to be safe just because it’s open. Just as proprietary software can hide malicious code, so too can open-source. Consider how quickly vulnerabilities can slip through the cracks without active, ongoing auditing. When you’re dealing with software that’s updated frequently, like Signal or any other open-source project, it’s not enough to have a single audit—it needs to be audited constantly by developers with deep technical knowledge with every update

Here’s the catch: most users, particularly those lacking a deep understanding of coding, can’t assess the integrity of the software they’re using. Imagine someone without medical expertise trying to verify their doctor’s competence. It’s a similar situation in the tech world: unless you have the skills to inspect the code yourself, you’re relying on others to do so. In this case, the “others” are the project’s contributors, who might be few in number or lack the necessary resources for a comprehensive security audit.

Moreover, open-source projects don’t always have the manpower to conduct ongoing audits, and this becomes especially problematic with the shift toward software-as-a-service (SaaS). As more and more software shifts its critical functionality to the cloud, users lose direct control over the environment where the software runs. Even if the code is open-source, there’s no way to verify that the code running on the server matches the open code posted publicly.

The Reproducibility Issue

One of the most critical issues with open-source software lies in ensuring that the code you see matches the code you run. While reproducible builds are a step in the right direction, they only help ensure that the built binaries match the source code. But that doesn’t guarantee the source code itself hasn’t been altered. In fact, one of the lessons from the XZ Utils supply-chain attack is that the attack wasn’t in the code itself but in the build process. The attacker inserted a change into a build script, which was then used to generate the malicious binaries, all without altering the actual source code.

This highlights a crucial issue: even with open-source software, the integrity of the built artifacts—what you actually run on your machine—can’t always be guaranteed, and without constant scrutiny, this risk remains. It’s easy to assume that open-source software is free from these risks, but unless you’re carefully monitoring every update, you might be opening the door to hidden vulnerabilities.

A False Sense of Security

The allure of open-source software lies in its transparency, but transparency alone doesn’t ensure security. Much like closed-source software, open-source software can be compromised by malicious contributors, dependencies, or flaws that aren’t immediately visible. As the XZ incident demonstrated, even well-established open-source projects can be vulnerable if they lack active, engaged contributors who are constantly checking the code. Just because something is open-source doesn’t make it inherently secure.

Moreover, relying solely on the open-source nature of a project without understanding its review and maintenance processes is a risky approach. While many open-source projects have a strong track record of security, others are more vulnerable due to lack of scrutiny, poor contributor vetting, or simply not enough people actively reviewing the code. Trusting open-source code, therefore, requires more than just faith in its transparency—it demands a keen awareness of the process, contributors, and the ongoing review that goes into each update.

Conclusion: Take Open Source with a Grain of Salt

At the end of the day, the key takeaway is that just because software is open-source doesn’t mean it’s inherently safe. Whether it’s the potential for hidden backdoors, the inability to constantly audit every update, or the complexities of ensuring code integrity in production environments, there are many factors that can undermine the security of open-source projects. The fact is, no system—open or closed—is perfect, and both models come with their own set of risks.

So, take open source with a grain of salt. Recognize its potential, but don’t assume it’s free from flaws or vulnerabilities. Trusting open-source software requires a level of vigilance, scrutiny, and often, deep technical expertise. If you lack the resources or knowledge to properly vet code, it’s crucial to rely on established, well-maintained projects with a strong community of contributors. But remember, no matter how transparent the code may seem, the responsibility for verification often rests on individual users—and that’s a responsibility that’s not always feasible to bear.

In the world of software, the real question is not whether the code is open, but whether it’s actively maintained, thoroughly audited, and transparently reviewed

AFTER

EVERY

SINGLE

UPDATE.

Until we can guarantee that, open-source software should be used with caution, not blind trust.

You might be interested in reproducible-builds.org or f-droid.org/en/docs/Reproducible_Builds

tldr

no often today we don’t know what the code is actually doing

yes this is an important problem

no nobody really seems to take it as serious as it should be taken today

no i’m not gonna change that over night