frankie-tales

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) .

FOSS toxicity, burnout and governance (again)

2025-03-23T15:40:00Z

I recently read with interest the post where Hector Martin resigned as Asahi Linux leader. As possibly well-known, Asahi Linux is the very first Fedora-based distribution where all the hard work to support the Apple ARM M* chip series in the Linux world found its way.

Dismissing the whole thing as another episode of burning out for a FOSS developer would be ungenerous. Some elements are typical in such cases, such as the excessive users pressure on the project. That caused a lot of pain and over-reactions in other contexts, but a big part of the Hector experience is related to issues with the upstream Linux kernel within the more general Rust-in-Linux saga.

Of course, harsh behaviours and bad relations with other people are common patterns in all human activities and often require a very thick skin and big diplomatic capabilities to get positive results. This is not specifically true for FOSS developers only (even if I say that a lot of developers are quite peculiar on the side of human relations, often in a semi-pathological way).

In my life, I have had the opportunity to deal with another very peculiar human category, such as cavers. Even when no money is involved, human beings can create bad relations, internal wars, and unhealthy atmospheres for their fellows. So, I guess it is a standard part of all human-to-human interactions, not a FOSS ecosystem peculiarity. A lot of people are strongly opinionated, and when also passionate, they tend to become intractable.

That said, I will concentrate on a specific part of Hector's post.

[...]
Back in 2011, Con Kolivas left the Linux kernel community. An anaesthetist by
day, he was arguably the last great Linux kernel hobbyist hacker. In the years
since it seems things have, if anything, only gotten worse. Today, it is
practically impossible to survive being a significant Linux maintainer or
cross-subsystem contributor if you’re not employed to do it by a corporation.
Linux started out as a hobbyist project, but it has well and truly lost its
hobbyist roots.
[...]

This is indisputable, IMHO, and it is likely the root of many problems that afflict the Linux kernel community and others. When people start working side-by-side with others who are motivated and sustained by different goals, it could be the seed of big social issues. Linux is not more just for fun for years, and that can create friction among developers. That includes perception about what should be considered acceptable for project sustainability and what should not.

These days, all that includes the use of profiling features for projects that are directly exposed to end-users and definitively the acquisition of personal habits and/or information about the users. This is not the case of Linux kernel, but it is a concrete issue for organizations such as the Mozilla Foundation and its products, and could become a divisive issue for OS distribution projects, as already happened in the immediate past.

Another problem is the wrong perception that a FOSS project should always accept contributions and enhancement proposals, while often it is not due or obvious. Like it or not, no acceptance of contribution is due, and I would add that FOSS projects could (or should) be very conservative in those regards, i.e. answering thanks-but-no-thanks more often than I have seen in recent years. IMHO, this gives evidence to what, for me, is an urgency for too many projects to list here, including, in practice, all programming languages out there.

Adding features over features on a piece of software is almost never a good policy because it increases the entropy of any software product and decreases its usability. The original spirit and goals of the software that possibly decreed its success should always be preserved, and that has been the basis of the original success of the Unix operating system approach, as an ensemble of compact and independent tools that solve single problems in the most general, simple and elegant ways, tools which are able to glue together to solve complex tasks. Now, this simple vision is already a source of friction among developers because maintainers are so often obliged to answer negatively to pull requests and patches for either respecting quality levels or opportunity.

This is a delicate trade-off that should be translated for every minimally articulated project in a written Social Contract to state and explain the goals and rules to respect for both users and developers. In a word, the governance principia of the project need to be defined ex-ante and not ex-post, to avoid misunderstandings and inner fights, as well as avoidable pressures during time. Unfortunately, many FOSS projects tend to delay ad libitum the definition of an explicit Social Contract or introduce that - more often, only a Code of Conduct for contributors is contemplated - when it is too late. Many big projects do not even have such explicit statements, and it is a pity. Users and developers should always be aware of such rules and goals in the life of any FOSS project.

One of the biggest problem nowadays is having such governance clearly established for life, but another is also ensuring that users and developers know its existnce and respect it, the two side of the same problem.

FOSS governance and sustainability in the third millennium

2024-10-11T17:45:00Z

I have long participated in the FOSS community. My first public contribution was the YardRadius project in 1995, a consolidation of the old Livingston Radius daemon and a series of add-ons written by Christian Gafton (RIP) and me. That was some years before the more significant FreeRadius project. At that time, I ran for a period an ISP just before the dotcom bubble exploded, but that's another story...

That was when most of the code was written in C (sometimes C++) and a handful of parvenu scripting languages such as Tcl, Perl (version 5 would be released one year later), or the still fresher Python.

At that time, the GNU project had already been active for more than ten years, the Linux kernel was less than five years old, and the whole FOSS thing was in its infancy for most of the world, but for a group of hackers and visionaries. Indeed, it was still seen with suspicion and fear in the business area, if not explicitly fought.

Being a FOSS company was an exception, not a viable opportunity. In those years, the only credible company was probably RedHat Inc. in the USA, while other companies (such as MySQL AB in Sweden) still had to gain momentum. To my memory, almost no FOSS company was probably located in the EU at the time. Sourceforge or Freshmeat still had to appear, and FOSS tarballs had to be merely searched via Google search through rigorously indie websites.

Fast-forward almost thirty years. FOSS development has become mainstream, including for the same companies that used FUD at the time to fight it (Microsoft, yes, I'm talking about you). Every developer proudly creates their FOSS portfolio of tiny or more considerable project contributions through Github to collect gadgets and show their own skills. There are more FOSS projects than single developers, and so on.

Apparently, all has gone well, but for a couple of details, now, like then. Those details are the governance and sustainability of FOSS projects, which are strictly connected to their credibility. There are very few (maybe no one) articulated projects that are conducted by a handful of developers for a significant duration, and even fewer just for free (like beer).

In those regards, I can consider SQLite and its well-known geospatial extension Spatialite, as well as a few other projects in the past, such as OpenSSL. They all survived a pretty long time, with quite regular releases, but not without sustainability problems from time to time. See, for instance, the issues of Spatialite. That could be specifically grave when security is involved, and the software is a reverse dependency for many others (as happened to OpenSSL).

The hard truth is that any complex software requires years of work to solve issues and add rock-solid features. Proper architectural choices and automation tools can make the whole effort more manageable and light, but there is no silver bullet to change this fact of life.

If you belong to a tiny pool of developers or a single small company, there is a good probability that you can't simply maintain the same level of effort for long enough. Even in most cases, proper software maintenance is simply a tedious activity. Let me call that with its correct name: it is a grunt work that merely needs to be done. The genuinely creative part is often overwhelmed by tons of boring issues fixing, communication activities, documentation writing, etc.

Of course, the only decent solution is an excellent modular architecture with many people working on independent parts in a decentralized way. But for that, you need excellent organization and tooling, with project governance that ensures the right level of involvement and satisfaction for people. The developers could be paid or not, but in the second case, they must enjoy participating in the project; otherwise, they will leave for others. Paid people at least are paid to work on demand (not based on their goodwill), but they need to enjoy their work equally. Otherwise, the sh*t load will rise to high peaks. That's the reason for having excellent governance, and it is also the reason why I rarely saw a single company FOSS project that was durable.

It is under the eyes of anyone that the most durable FOSS projects are conducted by a multi-actor foundation with a well-defined set of rules (without exceeding bureaucracy) that include some democratic process to make fundamental decisions. Unfortunately, such governance cannot be stated from night to day. The project requires a critical mass of developers/companies and years to accomplish such a result. Most of the FOSS projects are simply not relevant enough to that and should find an umbrella foundation and a more general community that could be helpful for sustainability (let's say FSF, Linux Foundation, or OSGEO for the geospatial world). This type of organization will attract funding and ensure mid to long-term sustainability. This is what I would call a condition sine qua non to ensure the success of a FOSS project.

To be clear, most FOSS projects are doomed to fail and close after a few years because not enough developers, users, or companies are interested in either working on them or sponsoring them to cover their expenses and development time. The alternative for the most conservative and stable is a de facto freezing in the state they are in with only minimal maintenance. Indeed, the Debian archive is full of such programs, which are good enough for use but miss any future evolution plan, if not sporadically. Fortunately, multiple software programs would become obsolete enough to be ignored and replaced by new, more flexible ones. This can be especially true for tooling and languages, but even in general.

Let me now concentrate on the elephant in the room. Who does what in the FOSS world?

Pure FOSS products companies

I will be clear. Most of the companies whose core business is concentrated on creating and maintaining FOSS tools and products have not had an easy life, and that will not change in the future. They have had a bumping road since the very beginning because the sources of returns are very limited: sponsorships, public funding, customer contracts on side extra modules, etc. In the last fifteen years, all this has become even more complicated due to complex relationships with major cloud providers. This is evident if one considers the latest known cases of RedHat (acquisition by IBM), Hashicorp (changes of licensing models and successive acquisition by IBM), Elasticsearch (again, changes of licensing models), MySQL AB (acquisition by Sun and then Oracle), and MariaDB (acquisition by K1 private equity), which reveal constant financial issues with this type of model, in a way or another.

I'm pretty pessimistic about the sustainability of such a single-holder FOSS project model. I even consider it neither ethical nor convenient for independent developers to sign copyright transfers and other side agreements whose purpose is maintaining complete control of the source code by the copyright holding company. That continuously exposes the possibility of the project or license hijacking.

Companies that also work on FOSS products

That is the easy way, followed by the big companies, that have plenty of incoming sources that are not directly dependent on FOSS products. The FOSS projects are not their core business, but they can be heavily dependent on several of them. They participate in large projects and can even be influential on the goals and directions of the projects because those products are heavily integrated within their workflows. They can sustain internal teams that work on multiple FOSS projects and pay for costs, meetings, sponsorship, and so on. They can even tolerate working with other companies and a community of independent developers for common goals and even with concurrents sometimes. This is the stablest situation and probably optimal, at least until company goals do not change, which could possibly upset the project (ask ex-Google Python core contributors for comments, but there is a long list of examples).

Companies that work with FOSS products

Most companies and users are merely passive users of multiple FOSS projects, with little skills and will to participate in development and costs. In those regards, things are slowly changing, but the level of awareness of the whole FOSS ethic and development process is still low. Many companies still have an evident predatory (let me simplify, sorry) approach to FOSS software use, too: they like the free as beer part, to say briefly. Their role in the sustainability of the project is not relevant, but they are part of the users community and globally determine its success. They are inevitable and part of life and could be more fair from time to time, thanks to micro-sponsorships and minor contributions (even bug reports).

Large FOSS projects with an ample community, a tiny minority

Of course, the Linux kernel is an immediate example of this kind of project, which includes a large set of contributors, a large group of companies, and independent developers. Unfortunately, it is a tiny minority of the entire FOSS project family. Often (always?) governed by a foundation but also with ample and diversified funding because the users community and interests are both broad. If all projects were of such kind, the rise of FOSS projects would be delightful. Unfortunately, this is not the general case. The result is that participating in a FOSS project is generally a choice for life. If you are the initial owner, it is a big responsibility. There could be a steep rise in these years of mainstream FOSS development because there are tons of open-source (more or less) projects out there, often conducted by big companies, too. Gaining interest and funding are challenging tasks. For the average developer team, finding a solid umbrella foundation is the easiest choice, or thinking twice before starting. For sure, as a developer, I would never sign any additional/conditional agreement about copyright holding and contribution rules with a single company (a small or a big one, that's not the point) because the future of such a project is always uncertain. Sure, any FOSS project can always be forked, but forking governance is never an easy task.

So what? In the short run, FOSS projects sustainability is a voting machine; in the long run, it is a weighing machine: don't feed the hype. Concentrating efforts on solid and well-conducted projects is a must, even more than considering their immediate technical merits or popularity. That's true for developers as for users. If your preferred FOSS project is a single-company show, it is probably doomed. You are warned, these are my elementary 2 cents suggestions to navigate the magic FOSS ocean.