How to trust FOSS players and the security implications

2026-01-27T17:30:00Z

More and more, recent (and not too recent) episodes [1-5] nowadays show a hard truth we already discovered in the Debian project since the end of the 90s. A key security principle in FOSS code development is ensuring the trustworthiness of all parties involved, and that’s unfortunately also the weakest part of the whole chain.

Debian adopted a long time ago a tentative GnuPG-based screening of people involved in the project through the so-called Web of Trust. All developers need to participate in eyeball meetings to sign each other's public keys after verifying personal IDs. The more signatures, the more trustworthy. That is generally mandatory before being granted the privilege of uploading to the main archive without review. Of course, trust is not automatic, and each volunteer must demonstrate they have the required skills and good intentions, and embrace the Debian social contract. This is the annoying, often multi-year process to be accepted as a contributor.

This process is far from perfect and may also be subject to abuse, as Martin Krafft demonstrated at a past DebConf, a long time ago. One of the main issues is that maintainers work on upstream software that generally does not undergo such a process to accept contributors. As the well-known sad case of the xz utils demonstrated [6] a couple of years ago, an initial review of pull requests is not generally enough to ensure that the developer or group does not have evil intentions in the mid- to long-term. Also, with the best intentions of sane upstream developers, evil parties can make very creative efforts to hide their malware code. This is magistrally demonstrated in that episode, which did not cause major security issues, only by casualties.

The sad reality is that none of the main programming language hubs is really trustworthy, because literally anyone can register anonymously to upload code and participate in development teams. Core teams at least review pull requests before accepting them to avoid major abuses. To address this, enforcing a worldwide web of trust for all core projects and possibly all software hubs should be considered a mandatory step to improve security and accountability.

It does not resolve all problems, but it helps. A central authority is not the answer, as it could create more problems than it solves. Instead, enhance trustworthiness by encouraging ongoing cross-review by multiple parties. Establish processes that build developers' trust over time through active participation and transparent peer review. While key hijacking remains a risk, this is a separate issue requiring distinct protective measures.

I've written about this related issue before. The shift from distributions to language and upstream hubs shifts software management onto developers and users, increasing the risk of security incidents from malicious contributions.

That said, like it or not, most FOSS products out there are created/maintained by single individuals and micro-development teams with no warranties and questionable durability. I wonder how billion-dollar companies can seriously consider basing their core business in such conditions, a problem directly connected to the broader sustainability challenges for FOSS projects. The progressive spread of the AGPL license and other similar licenses is a symptom of this type of malaise and should be taken into consideration, as they are different aspects of the same problem. Security concerns are another key point that we, as a community, should try to manage better, but my honest thought is that nowadays, predatory big (and not so big, even) companies (as well as public bodies too) that use community-driven FOSS code in an unfair manner, without returning a cent for development and maintenance, are not more acceptable.

Therefore, FOSS communities are not perfect, but many of the culprits are nowadays on the shoulders of companies and public bodies that are still looking out their windows instead of being active stewards and promoting reciprocal collaboration among all involved parties.

Come on, put the money and effort into the sources of your digital profits.

References

Too many eyes or too few efforts?

2025-12-07T16:00:00Z

I recently read a post by Jack Poller about the end of FOSS optimism in creating software in recent years. His thesis is that the myth that the more eyes that look at a piece of software, the higher its quality, is indeed a myth, and that nowadays it is also a dangerous illusion when we concentrate the analysis on security. Commercial software, on the other hand, has processes and resources dedicated to managing security, which in these times of active AI use could make the difference.

I agree with such a thesis at large, but with some differences in declination and sense. It is absolutely true that security requires special skills that most developers do not have and (above all) are absolutely not interested in having. This is amplified in the FOSS communities, where many programs and libraries are not specifically written with security in mind. On the other hand, currently most AI-generated security reports are fake and pure hallucinations (e.g., ask the Curl maintainer, about the overwhelming number of reports in the last few years that are clearly generated with help of AI and are pure garbage). Therefore, having new AI-based tools for screening does not simplify the problem neither for software creators nor for infosec experts. Basically, they still need to do their time-consuming jobs with resources and efforts: there is not an easy escape for that.

Even, if you like it or not, nowadays FOSS software production is organic to the commercially supported one, and they are strictly connected. If the security (and, more generally, the sustainability) of so many FOSS projects today is a problem, it is also a problem for their commercial counterparts. In other words, FOSS development has been mainstream for at least the last 20 years: that implies that the sustainability (and security) problem extends to the entire supply chain for both FOSS and commercial software.

I already dealt with some of those topics in past posts (e.g., have a look here, or here), not referring to security, but to the sustainability of the FOSS ecosystem of independent-but-interdependent projects. This is a matter of responsability for both FOSS mantainers and companies, and not something that could be avoided as a problem for others.

As already written in the past, I can't see a recipe for success, but I'm quite sure that overcomplication of information systems does not help, but is part of the problem. Too many dependencies, complex frameworks, and architectures are sure highways for disasters. And that's true for both FOSS and commercial software. The shattering of code hubs among multiple sources of binaries, packages, images, and distributions is another sure quarry of problems, because they imply a multiplication of possible origins of issues, as well as the need of sustaining multiple teams and replicating efforts instead of concentrating them.

There is great chaos under heaven; the situation is excellent! (Mao Zedong) .

frankie-tales

How to trust FOSS players and the security implications

References

Too many eyes or too few efforts?