Securing open source software: Whose job is it, anyway?

The US government and some of the largest open source foundations and package repositories have announced a series of initiatives intended to improve software supply-chain security, while also repeating calls for developers to increase support for such efforts. On the government side of things, this includes a voluntary threat …

[ldo]

Contributing Back

That’s the name of the game.

Too often in these reader comments, we see people complaining about how Open Source doesn’t quite fill their needs, and how it needs to be fixed to work better.

Remember, folks, the code doesn’t write itself. It was written by somebody to fulfil a need, and it was adopted by others because they felt the same need. Open Source lives or dies, not by the number of users, but by the health of the community that contributes to its development.

In short, if you are just a passive user, not a contributor, then your existence doesn’t really make that much difference.

Regarding the revenue value, I remember a Red Hat executive saying, a decade or two ago, that for every $1 that they got in income, they were sucking $10 out of the income of their proprietary competitors. In other words, Open Source has a massively deflationary effect on the software marketplace.

[Roland6]

Re: Contributing Back

Probably need a foundation to sit on top of the secure open source supply chain, so they can charge a usage fee that can go to maintaining secure open source development. Yes, you are free to buy from elsewhere, but caveat emptor…

[Charlie Clark]

Re: Contributing Back

I'm not so keen on foundations. They can quickly become bureaucratic ends in themselves that tag on additional and irrelevant goals.

[Roland6]

Re: Contributing Back

Understand the problem, however, we need to break the idea that Open Source is free to all.

A “foundation” needs to be not for profit, although it will need to be commercial so as to generate the revenue’s necessary to maintain the quality of Open Source people are demanding.

[doublelayer]

Re: Contributing Back

If you intend commercial to mean that it has the right to require users to pay, it will run into all the problems that other licenses that intend to require payment have. I understand the desire to get revenue, but it does make a large, and in my mind important, change to what open source and free software have meant which has its downsides as well as upsides.

[Roland6]

Re: Contributing Back

GPLis satisfied by open source being freely available to customers/service subscribers, you want a secure supply chain then pay the subscription to be a user of that service.

> but it does make a large, and in my mind important, change to what open source and free software have meant which has its downsides as well as upsides.

Yes, having a source of secure open source and an improved software supply-chain security are important changes to what has gone before. You want it then there is a price, you can have open source from other places, but without the security guarantees…

I think we need to get away from the free beer which many are acustomed to….

[doublelayer]

Re: Contributing Back

"GPLis satisfied by open source being freely available to customers/service subscribers, you want a secure supply chain then pay the subscription to be a user of that service."

This sounds a lot like the Red Hat case, which you're probably aware isn't making them or IBM very popular these days. If it's only the supply chain that you're paying for, that will easily work with the specifics of open source licenses, but I don't think you'll get enough people. If you also intend to keep the source available only to those who are paying, you'll need extra measures, like those Red Hat used, to keep that happening. I don't like that. You are free to disagree.

"I think we need to get away from the free beer which many are acustomed to…."

I think most of the methods used to try to get away from it are harmful to the free speech aspect as well. There is a reason why a lot of licenses are not open source, even though I can see the source. If we end up splitting into open source and commercial source-available branches, I will stay on the open source one.

[Lurko]

Re: Contributing Back

A “foundation” needs to be not for profit,

Doesn't seem to have worked so well for Mozilla/Firefox.

Actually I'll caveat that, it doesn't seem to have worked out well for the core FOSS product. It's worked out amazingly well for those at the top of the foundation.

[Roland6]

Re: Contributing Back

Agree we have some major problems with current business culture and executive sense of entitlement…

[Charlie Clark]

Re: Contributing Back

No, we don't need to break the idea: open source is free without any kind of qualification.

But software development and maintenance isn't free and we might need to look at what kind of models we need to maintain a particular software ecosystem. Specifically if, as is long overdue, software liability becomes a real thing, how do we deal with this? If companies are selling products or services (using open source software) and can be held liable for problems arising with them, then they will be interested in ensuring the software is maintained and documented. I'd argue that the commercial pressure itself is likely to provide solutions.

[Roland6]

Re: Contributing Back

> No, we don't need to break the idea: open source is free without any kind of qualification.

Err no!

Stallman has always maintained “free” means libre, not free as in free beer. There are plenty of reputable sources that discuss this in detail.

Remember if you want quality software, software developers need to be paid at rates above subsistence…

> I'd argue that the commercial pressure itself is likely to provide solutions.

I suggest the need for improved security is a commercial pressure, so either we can start thinking about solutions and lead the market, or let “the market” ie. Others with a vested interest in minimising (development) costs, to define the solution, which will probably result in something akin to a consortium owned BSD fork (ie. Closed sourced based on open source that does not credit the original developers)..

[Charlie Clark]

Re: Contributing Back

I'm not alone in disagreeing with Stallman: his position is political rather than philosophical. No strings attached is how I like my open source.

[Roland6]

Re: Contributing Back

> I'm not alone in disagreeing with Stallman

I also disagree with some of the things he has said.

> his position is political rather than philosophical.

It’s both, remember he is an academic who has never had to earn a living from being a software developer, this combined with a hippie mindset has poisoned open source and our ability to charge anything for it, hence why we have all the open source funding problems we currently have.

> No strings attached is how I like my open source.

That’s BSD then :)

There was an ElReg article in the last year or so about “open source”, where we noted what is generally regarded as open source, is more akin to public source and development, where development is readily visible to all on say Github, at no cost (*).

(*) I am expecting at some point services such as Microsoft’s GitHub will start charging: want to use our platform, buy a developer’s subscription; want to view a project, buy a user subscription. Obviously these would be tiered on the number of projects you wished to be able to access. As this is Microsoft, don’t expect any of those revenues to actually go to the individual projects, but the subscription will allow the projects to be harvested by CoPilot.

[doublelayer]

Re: Contributing Back

"remember he is an academic who has never had to earn a living from being a software developer, this combined with a hippie mindset has poisoned open source and our ability to charge anything for it, hence why we have all the open source funding problems we currently have."

I see the problem, but not the solution. Most of the ways that you can mandate payment have an unavoidable effect on some of the other freedoms that I value highly. If, for example, how much you have to pay depends on what kind of user you are, then it's no longer free to use by anyone, anywhere, the way that open source tends to require. It also restricts the freedom to modify and distribute, since the version I changed and distributed still contains most of the work that went into it before, so presumably I have to collect payment and redirect most of it to those authors.

A lot of the suggestions I've seen are, to the user, little different than proprietary except that they can modify the code on their own computers, and there are some proprietary licenses that also permit that. If that's the intent, then, from my perspective, you might as well be proprietary. At least the proprietary authors aren't pretending to be something they're not. I'm open to hearing ideas about how this could be done differently, but so far, I haven't seen one that works, preserves freedoms, and fixes any of the problems with funding.

[Roland6]

Re: Contributing Back

Agree it’s a tricky one, as the solution is a bit “hippy”/counter-culture, in that it expects people to be honest and fair and voluntarily put their hand in their pocket, rather than explotative.

[Anonymous Coward]

Off Topic......But Somewhat Relevant....

When SolarWinds was hacked, the hackers inserted malware into the software development libraries at Solarwinds......and then waited for the results to turn up in the delivered application.

(1) Did SolarWinds ever keep copies of open source materials in their libraries?

(2) More interesting, did SolarWinds ever "contribute back"?

Quote: "We need companies to be both responsible consumers of and sustainable contributors to the open software they use...."

[Version 1.0]

Open Source cliff climbing

This whole "problem" is just like learning to climb the cliff on a Welsh Beach when I was a kid, I climbed about 20 feet up and saw some issues so I climbed down the same path and sat on the beach to look at everything. A few days later I started climbing all the way up to the top. No problems after working it out myself.

[Michael Wojcik]

Public code repositories are toxic

... and until developers and organizations learn that lesson, we're going to continue to have widespread issues with them.

Rust's Cargo.io will have code signing? Yeah, that's super useful, because that one dev in Nebraska will no doubt have excellent private-key hygiene. Code signing has always worked out great so far.

PyPI (which I think lags only GitHub and Node.js as a popular vacation spot for malicious packages) will use OIDC. Excellent choice. A bafflingly complex, over-engineered authentication mechanism based on one of the truly idiotic security technologies (JWT), which certainly no one ever has trouble implementing securely. What could go wrong?

Maven ... wow, people still use Maven? Huh. Good for them, I suppose.

I mean, sure, let's MFA the MFers. Couldn't hurt; these repos are such a disaster that almost any move is an improvement. But we're unlikely to see significant improvement in the problems of malicious packages and malware inserted into legitimate packages from any of this.

There have been proposals which might make some difference, such as CHAINIAC, though whether they'd be workable in practice is another question. More automated scanning, including both static and dynamic analysis (in sandboxes), might help a bit. Random audits might help a bit, if you could staff them. At least the repos might catch some of the easy stuff. But the whole idea of "fetch a package of unknown provenance from this repository and run it" (which in its modern form goes back at least to CPAN, and obviously has roots in public FTP sites, BBSes, contrib tapes, and the like) is fundamentally flawed.

Organizations need to at least perform due diligence. Download packages to a secure internal repository. Check signatures; check diffs; check for online buzz about the package. Run static analysis. Test in a sandbox with dynamic analysis, including program behavioral analysis. Don't let any devs use the package until it's been vetted, and then every part of the chain, from developers through production builds, must fetch from the internal repository only.

And, of course, reduce your external dependencies. No, your application almost certainly does not need a thousand Javascript packages.

[Anonymous Coward]

Re: Public code repositories are toxic

> Rust's Cargo.io will have code signing? Yeah, that's super useful, because that one dev in Nebraska

Crates.io team

[4n6x]

The tea protocol - a good start.

The tea protocol (tea.xyz) from the creator of Homebrew, sounds like a good starting point to address many of the issues raised.

There’s a good OSS analogy here:

https://www.linkedin.com/pulse/open-source-public-parks-transformative-potential-tea-dipert-bytye?utm_source=share&utm_medium=member_ios&utm_campaign=share_via

[Andrew Williams]

Weird

The proposal that OSS should do better (will be held to account for not doing better?) with regard to security...

Well, there's a whole lot of quiet about this being expected/demanded of proprietary software.