I am not a supplier
softwaremaxims.com
softwaremaxims.com
When I say “software supply chain security”, I am reducing a complex concept to jargon, and am using terms that will evoke specific concepts in the people I work with. I’m not really talking to you; I’m talking to my leaders who are extremely business savvy but may not have the software development chops to understand how code we didn’t write got mixed in with code that we did write.
I am NOT implying nor assuming that the original creator or maintainer of said software has any obligation to me.
The 90% case for me, when I bring up this term in a software security discussion, is that I’m trying to impress upon an engineering manager that if they choose to use software that they didn’t write, that THEY own it from a security perspective. Depending on risk we might discuss monitoring for notifications of vulnerabilities in the code, or we might discuss first-party or third-party security code reviews, and/or forking depending on the security support level of the maintainer, and/or contributing back security patches that we develop in house. Or I might try to convince them not to take the dependency and write the code they need themselves. Or I might propose mitigations like isolation. Or all of the above. “Software we use but didn’t write ourselves” just doesn’t look professional or compelling in reports and documents and doesn’t lend itself to being reduced to an acronym like SSCS.
As a security engineer, I depend a lot on the goodwill of folks like you who write and maintain open source software, and I most definitely do not take your work for granted.
Best regards and Happy New Year!
Perhaps looking into the analogy the term “software supply chain” is intended to evoke is more helpful. One possibility, which is what most engineering users of it (among others) intend, is, indeed, that your open-source dependencies are your liability the same way as your traditional supply chain is, and that’s true. Another, which is what the article objects to, is that you are therefore entitled to ask anything of them, and that’s false. Given that the liability and the entitlement are two equally important and mutually supporting sides of the standard supplier relationship, there is reason to dislike the an analogy that is only correct in half of its implications.
Of course you, or anyone, is entitled to ask anything of anyone, just as they are entitled to ignore or engage with you. There are no legal ramifications either way.
The article only makes sense if the requester _expects_ the maintainers to donate time and resources. In 15 years, I've not run into any manager/exec/dev that hits a transitive dependency issue in open source and then expects the maintainers to drop things to fix it. Everyone knows you either fork, patch or pay.
Obv. there will be maintainers who experience people expecting free work. The article is long-winded in saying: read the license, no warranty, if you want to pay, let's talk more.
Also all the thought leadership post out there.
"Log4j has to release better patch" and "how could they write this when obviously wrong" or "how could it stays this way so long" are regular problems.
Ask any open source maintainer. There is a reason we burn out so much.
Or talk of people describing leftpad or the anti Russian patches as "malicious actors".
I get where you come from, but the reality of the environment out there is that this behaviour is everywhere.
Software that deliberately deletes the user’s data for no reason related to its immediate purpose, when the user in no way expects that to happen, is malware, open-source or not. And deploying it is an attack. Those are completely orthogonal. (Surely if I put an open-source Metasploit shell on your laptop you’ll have every reason to complain.) The Russian-desktop-file-creating changes are much milder but still on the PUA spectrum, somewhere around the ad-toolbar checkbox in the installer. (Better because not ads, worse because no checkbox.)
Should we object to an open-source maintainer abruptly making their program into malware? In court, per the license terms, no. In general? Probably. At least I can’t find a logical justification to simultaneously object to the Stylish sellout[1] and not object to the surprise anti-Russian changes. (Browser-extension distribution terms of service notwithstanding—I’m sure the NPM terms of service prohibit malware distribution somewhere.)
(Let’s agree not to talk about this as warfare, because acts of war by private, non-military actors—from countries other than those directly participating in the conflict—against a population that is certain to include civilian targets to an extent serving no direct military purpose... I could see that, but obviously it’s a huge can of worms, and besides that’s not the argument the “protestware” authors made.)
Should we object to an open-source maintainer sabotaging their own software, like in the left-pad case? Presumably we shouldn’t to them just giving up or abandoning their website, so this becomes a bit trickier. I still lean towards “yes”. If I am a jerk, I don’t cease being one even if I stick a note with MAY SCREAM OBSCENITIES AT YOU FOR NO REASON on my forehead, at all, let alone in a world where most people walk around with those. But I can imagine being convinced otherwise.
(I want such a note now.)
[1] https://robertheaton.com/2018/08/16/stylish-is-back-and-you-...
In the first case the problem is “I have subpar suppliers with poor security and I need to work around that”, in the latter case it’s “I build upon works that were voluntarily made available, often by craftspeople with limited resources”.
It’s not a secret that words we use have associated baggage that colours our understanding of an issue even on unconscious level. Different connotations of the latter call for different, more humane attitude and perhaps provide an incentive to contribute, sponsor or donate—and vice-versa, using terminology from a world with transactional relationships to level with business types may in fact gradually infect our own outlook.
Sure, a different language might sound less familiar to them, but perhaps there is a good reason for that—the dynamics are different, so the feeling of familiarity is false anyway.
But I don’t think it would help the business either, since it’s a false abstraction.
A supplier is expected to be holding themselves to certain standards—including literally, by way of ISO 31000 and similar. Your suppliers’ compliance with, say, risk management practices is what your risk management practices build upon: this is why you have procedures for choosing your suppliers.
Furthermore, there’s an important reason for transaction relationship and contracts in some form or shape to exist—of course, ultimately you are responsible to your customers; but if something really bad happens, it is quite handy to be able to legally demonstrate that (1) you have done your work picking a reliable partner (if they actually comply with certain standards, they at least must have managed to convince relevant auditors—and are probably liable to them for lying) and (2) there is a paper trail that codifies your relationship with that partner, who may not have upheld their part of the deal.
(Naturally, your compliance with risk management standards, having relevant contracts signed with your suppliers, etc. plays an important role in downstream partners’ willingness to work with you as a supplier: it’s turtles all the way down.)
With OSS, no one owes you anything and your business is the final supplier in the chain; and if there’s no chain in any meaningful sense, the phrase is actively misleading to business decision makers.
Using the terms software supply chain security to point out that no supplier exist to work with or blame, seems fair enough.
So you're aware the FOSS developers are not suppliers but feel comfortable to explain it to management in a way that clearly makes them responsible so they're able to understand what exactly? That their developers outsourced the hard to implement libraries to unpaid volunteers and only handle the mostly trivial business logic?
The term was most definitely coined to offload responsibility in big enterprise. The uncomfortable reality is that productivity would take a nosedive without using these FOSS libraries/tools, but nobody wants to admit that this comes with risks (even though they're way smaller then implementing it yourself, probably). I'd agree that it's a complicated issue, but maybe using terms management is comfortable with isn't a good idea either if their meaning didn't actually apply at all.
Even in the situations where there is a supplier-buyer relationship there is the maxim of caveat emptor, subject to terms of an explicit commercial contract.
It is 100% the responsibility of the user of a library or FOSS artefact to do their due diligence before adding it as a dependency in their project.
It is bonkers to demand the developer of an open source library to dance to my tune just because I am using their library gratis. It is open source! Create a pull request, fix the bug (or add the enhancement), compile, test and write to the devs with your solution, if you really care. People sitting on their pedestal and whining solves nothing (for themselves or the community).
I am just thankful there are so many people who work for providing high quality FOSS software. Donate (or support those projects in other ways) if you are able to do so. Don't just be an entitled jerk.
On the oft cited example of the FOSS developer who decided to delete their library/introduce a deliberate bug, the teams that were impacted had missed the step of validating and testing every minor version in their integration test environment.
They should have also checked in the sources of all their dependencies to ensure a reproducible reliable build. If it was a commercial 3rd party library, it was quite common some decades ago for the customer to pay additional to secure the source code in software escrow, to protect against the smaller supplier shutting down/going out of business. FOSS gave a better alternative by sharing sourcecode freely so that this mechanism of paid software escrow becomes redundant and the user can directly use the source for any purpose they see fit.
Failing to adopt these basics and complaining about what an independent developer should/shouldn't do sounds lazy.
Fundamentally, this boils down to trust in the underlying assets and degradation of serious engineering practices. There are no easy shortcuts.
* Signing releases (requested by linux distributions)
* Signing commits (actually I don't think anyone actually asked me to do that)
* Authenticating myself with a physical security key. (requested by PyPI)
I found these things easy to automate and they seemed worthwhile to do, and so I don't resent doing them. My sense is that these things are being gradually built in to tools and will become the default without any effort on the part of library maintainers.
So hopefully you'll allow me to sneak in another point! Open source licences create relationships that in political theory would be called anarchism. In software anarchy, anyone's allowed to do anything (or not do anything) they like with their copy of the code. Software is what economists call a non-rivalrous good (ie, multiple people can enjoy it without affecting each other). Anarchy works well with non-rivalrous goods. In contrast, businesses are built around rivalrous goods (ie if you have it, I can't have it), and in this world anarchy doesn't work, and you have to view things through contracts and money.
I think I'll stop there :-)
Is that only for some packages? I publish a few obscure ones (not widely used) and get away with just a password.
I can see the package indexes becoming much more involved in supply chain issues. A bit like the app stores, where a considerable amount of vetting goes on.
A "vetted" package index that charges subscription and splits the revenue with package maintainers. In return, maintainers agree to jump through all the extra hoops and index maintainers do extra verification (but still no warranty except that the standard procedure is followed).
The same package can then be uploaded to the normal index (as it is now), but without these extra steps, and no vetting.
You do realise that the main source of dangerous vulnerability is low level infrastructure that do not come from these package managers ? The purity and capabilities sadly solve nothing when the source of the problem is the fact that NTP, OpenSSL, OpenSSH, the BGP daemon, the libc you run on, etc are all maintained and "fixed" and evolved by people that can barely pay for their food, even less for basic tests ?
Like i love capabilities and i would love to have more, but the basic problem here is that the low level that you totally depend on for the capabilities to work cannot even be funded to work.
Hell you do realise that Autoconf has not had a maintainer since 2012? If it was pwned and had injected backdoor in your software since then, we would have noone to fix it.
autoconf didn't have a core developer. But it had many distro package managers.
there's nobody adding code/fixing bugs, but there are plenty people reading and looking at diffs before packaging it in distros.
then the js libs have neither core maintainers nor anybody at npm corp that cares about security or reading anything.
the top comment is correct to care about those before system libraries.
When there's a vulnerability or malware found in a python or npm package, 75% of the tech world does a quick audit (or not), shrugs, and goes on with their day.
Weak words seem appropriate.
I've hacked together a couple of packages for personal use but didn't even go so far at to look what language the code was in. I'm assuming a lot of packages from ppa-s are produced in an automated way with no code review, and depending on your distro that might also be true of some principal libraries.
I think those used to be national or telco lab projects in 60s-80s. The values created are hard to exploit and to capitalize. Perhaps it's a policy problem.
This could either be grants to maintainers, grants to software nonprofits like linux foundation, or some kind of national software lab that employs people to maintain and audit open source software (or ideally, all of the above)
My take: I suspect that (perhaps a majority) of us here have a distant and abstract understanding of long-term poverty (eg:hunger on the table for years at a stretch). I'd offer that even the memory of real poverty doesn't equate with presently living in a long state of active poverty.
Translating across that gap is hard.
note: I'm not socially critiquing HN here. I am opining that survivor bias may be in play, however.
I suspect many people working on OSS are getting paid, if not handsomely, then enough to survive.
As of today, the reality is not at all. As I mentioned elsewhere there are zero maintainer of autoconf since 2012, even less one well paid.
Log4j devs took unpaid time off to fix it.
OpenSSL dev lived for years with less than 10k per year.
Paul's work doesn't count?
E.G, every version of every dependency you use (either directly or transitivly) needs to be audited and approved by a trusted supplier. This isn't nearly as bad as it sounds. You only need 1 trusted organization across the entire industry to certify a baseline of trusted software. Maybe a second organization to cover people who don't trust the first.
The NSA, some other part of US cyber command, or a comparable agency from a different government are all natural choices; as they have a vested interest in protecting critical domestic infrastructure but no commercial interest in keeping their work proprietary. Since that infrastructure all runs the same software as the rest of industry, we all benefit.
NSA is not a natural choice, since they are an active threat that has a history of abusing trust in their defensive mandate to insert vulnerabilities into systems in pursuit of their offensive mission.
I hope your brave new world includes a requirement for orgs to disclose their software auditor, so my org can avoid trusting orgs like yours.
So it's not just bad, but impossible. Got it.
More to the point, software "auditing" does not work reliably against deliberately malicious code written by competent actors, never has, and never will. It's too easy to slip in subtle back doors that reviewers won't notice, and at the same time too hard to keep up with the review workload.
One of the biggest cluster of cyber attacks ever, WannaCry, is attributed to NSA directly. They developed and sat on the exploit for 5 years, until it leaked, because even the NSA can be compromised. Government lives in a “we need good guys to have the biggest guns” Cold War-like mindset and are terrible role models for championing cyber security.
Auditing in general is primarily used as a tool to shift liability, or “ass-covering”, and sell a false sense of security by abusing information asymmetry. That said, there’s nothing wrong with auditing when deployed within a more informed and aligned incentive structure.
Seriously? As soon as the NSA certifies a piece of code it'll be dropped like a hot potato by everyone outside of the US, and probably by a large percentage of the people inside it.
If such a body exists, which seems like a reasonable idea, it has to be nongovernmental and not controlled by large corporations either.
I'm not against the NSA, FSB, 3PLA, GCHQ or any other letter based agency certifying things. I'm saying they can't become the main official certifying body for FOSS because it simply won't be accepted by the FOSS community or by other world governments.
I mean, I'm in Canada, friendly as it gets, and still - is NSA certifying a piece of software a good thing, from my perspective? From my company's perspective? From my Canadian sovereign government's perspective? There may be second order effects at play here.
Governments across the world have large gaps in their understanding of software and its relation to the world.
Software engineers are all blacksmiths, and software products equates to artisan made weapons. A food poisoning traced to a chef's knife from a workshop affects all users of the knife, but the impact is often localized to the shop and lessons learned are shared less as a scientific theory but more or less as an epic(see how "postmortems" are requested or written).
I predict that software supply chain concept will start working when software become a field of engineering, as in a single bit of error stops being the direct cause of a catastrophic failure(e.g. a web server bootloop), parts become replaceable(e.g. universal SATA host driver compiled against musl libc running just fine with glibc or proprietary Unix libc), so on and forth, maybe once anyone will be able to code or AI would start taking over us, or something - but at this moment where everyone touching software must be all manager-architect-manufacturer-user that knows where to put a chalk mark, even the idea of software "components" only barely work.
check how it works with FIPS for USA government. Out of date and you can't use a regular distribution because it doesn't use it, because it's expensive to get certified.
I don't follow your point about purity. A dependency in a side-effect free language can't suddenly open a socket or access the file system. The attack surface is much smaller.
As an example of an "impure language" with security in the form you envision, Deno allows you to specify access controls on a per-script or per-dependency basis. You can specify imports that prevent dependencies from opening sockets or writing files or reading files.
Many years ago npm inc treated download and package counts as KPI. They pushed back against sensible measures like code signing, instead centralizing the ecosystem and encouraging cross-dependencies within their registry. A more security-oriented package manager would have focused on code signing and vendoring strategies.
From your description it sounds like Deno is using object capabilities -- that's a great step forward.
> Many years ago npm inc treated download and package counts as KPI.
That's bonkers. I had no idea.
import safe MyDependency
A dependency can exploit your system deliberately, not just with side effects. If you're not strictly pinning all of your dependency versions, one malicious update that makes it to the package manager can ruin your whole world.
Our package managers operate entirely on trust. Nobody is guaranteed to be checking to make sure some random package's maintainer isn't submitting malicious updates.
As a community we're all lazy and basically hope that somebody else is invested enough to check everyone else's work. In the case of OpenSSL, we've found that some projects become so complex that almost nobody does for long periods of time.
In an impure language, it can do any random thing to any random part of the whole system and you won't even get the chance to know what it is doing.
Are there any truly pure package management systems out there, though?
Haskell has Safe Haskell, which more or less guarantees that the actual Haskell code compiled through the normal path is pure (but not that the code is total, and total under resource constraints, which you also need). The build system itself is not pure, though, so you have no guarantee that a dependency's build scripts don't put Evil Things into your program outside of the actual language framework.
Any others?
[0]: https://discourse.haskell.org/t/deprecating-safe-haskell-or-...
I think you're using "side effects" in a colloquial sense while I'm using it in a PL sense.
Pure code is deterministic, operating only on its params. Impure code—code with side effects—is something that depends on state outside of its parameters.
Cannot agree with this oversimplification.
Exists community. Yes, every human have his own motives, but many live in countries with effective law enforcement, and many people obey Western Values.
Also important, software is a chain with many parts, some parts of one chain could make really large disruptions, some are less significant.
So overall, real formula includes trust, humanity values, laws, government effectiveness and inertia of this chain.
Sandboxing modules is what you want, and that can be done with impure languages too. Sure, pure functional programming might make it easier, but as others pointed out, Safe Haskell and friends are very very far from mainstream.
Meanwhile, Firefox compiles some C/C++ dependencies into wasm, and runs them in sandboxes.
Also, if a dependency actually needs IO (either a networking library, or a DB library, or just for logging purposes), the guarantees you're talking about again go out the window.
And, moving to the more extreme scale, you can never be 100% sure that some dependency hasn't found a way to trick the compiler or runtime system into doing something it's not supposed to be possible to do, even if it consists of (ostensibly) pure code only.
BPF and eBPF, though this feels unsatisfying.
Supported software is a purebred dog that you paid an American Kennel Club-registered dog breeder thousands of dollars for. You got pedigreed papers, a warranty against early development of problems such as hip dysplasia, and bragging rights about all the blue ribbons in your dog's family tree. But in the end, there is no guarantee that the dog will actually work out well as your family pet.
FOSS is a mutt that you got for free from the American Humane Society. The AHS promised that it's spay/neutered, up-to-date on its shots, and that their under-resourced veterinarian didn't notice any major problems in a real quick once-over. The mutt may actually have a better chance of working out as your family pet. But if you expect a purebred warranty, for a free mutt from the AHS, then people who know anything about dogs may start wondering about you.
FOSS had to be up to date? It’s not a good analogy.
Often it's scenarios like their unqualified boss who is the ceo's uncle's son may throw a fit somebody is challenging them.
Or there's some checklist nazis in charge.
Fortunately, we need not pull the lever all the way in that direction. As with so many aspects of the open source ecosystem, the real most valuable element is trust.
The difference is that FOSS is not a business model. It is far closer to infrastructure, which is usually supported by other means than business models. Things like community structures for common goods (regularly called government but not always).
There is a different problem here, which I have chosen to not talk about here, but that is the problem of funding profitable software products. We simply... do not do that. We do not have the tools for that. But that is a different rant.
FOSS can be part of a business model, but only if there are contracting parties who agree on the mutual obligations. If someone simply develops open source software and this is used by arbitrary people, essential prerequisites are missing for a contract to come into being. Instead, there are no obligations to the developer.
Perhaps it's a distinction without a difference. But if it happens a lot, you'd stop using that path.
Typical example. Last year was the first time the curl project could pay for their website hosting vs the author paying it from his own pocket.
Curl.
If that happens too much, corporations re-evaluate rush and costs and start developing things in isolation and in-house. But I expect leftpad will be a rare event.
If we follow the rules, the people that went malicious are all the trusted users and package repository that broke his intent. He was totally in the limits of his rights and the social contract of the licencing for FOSS.
The fact we present these maintainers as "going malicious" is exactly what i am ranting against in this post.
I'd argue that he very much did break the social contract. Not the letter of the actual contract, but it's generally assumed FOSS developers aren't in it to screw consumers of their offerings actively. That's the social contract that's the lifeblood of the movement, and if it breaks in the general case, the movement dies.
(There's a lot of things people can do that they're perfectly entitled to that would destroy ecosystems because they shatter expectations. Linus could sneak a very clever backdoor into Linux [hypothetically, perhaps not without collusion with multiple actors and a lot of prep work], and he wouldn't break the license but he would severely injure the project's reputation).
Well, yes.
There must always be someone you can drag onto the carpet (i.e., sue if it fails or goes rogue). Proprietary software gave you that, at least at the enterprise level. When Microsoft, IBM, et al. sold you software they were staking their professional reputation on that software and the associated support.
So yes, let's go back to proprietary -- when developers got paid and businesses got some assurance from the vendor that their stack wouldn't go rogue on them.
Good luck with that… your company has the skills to reimplement node?
> but it's generally assumed FOSS developers aren't in it to screw consumers of their offerings actively
It's generally assumed they are in it to get screwed actively… but often that isn't the case.
> Linus could sneak a very clever backdoor into Linux
You are aware of a difference between writing a malware and deleting a project you own right?
You are quite correct; the npm ecosystem may be a special cade since it has been built on a huge amount of trust-assumption, and the real issue there was that trust model, not FOSS in general. Still, in that ecosystem, unpublishing a module unilaterally that so many systems relied upon was, at besst, negligent (morally not legally), showing a disregard for the concerns of those outside the fight with npm operators. In that context, the unpublish was more malicious than an adherence to the old "user beware" rule. Indeed, it would be hard for Linus to unpublish Linux, given the distributed nature of its hosting; unpublishing leftpad looks more like taking advantage of a mis-design in npm's package model to screw over thousands of third-parties.
The leftpad stunt hurt everyone in that ecosystem. It was dropping a stink bomb at a party because the host had offended him, but everyone in the room got to suffer the consequences.
Noone built it as trust-assumption
We all chose to trust because it allows us to look at ourselves in the mirror every morning and forget the free work we are exploiting. The problem is us. Not npm.
That's good! It's also necessary to operate at this scale, where any of us (not just corporations, but every hacker using a package manager) can operate with some minimum level of expectation that while packages might break from time to time, the breakage isn't malicious and everyone's incentives are aligned to minimize it and correct issues as quickly as found. Imagine what the ecosystem would look like if we couldn't make that assumption? The legal warranty allows for, say, Debian to start sneaking keyboard harvesters into the binary blobs that they publish alongside the source... What would happen to Debian users if they did? What would happen to the entire GNU/Linux desktop ecosystem if every package manager chose to do that?
If that trust were to break at scale (i.e. if stunts like leftpad's removal breaking everyone became common, or FOSS developers were to begin doing even more malicious things that the "as-is" legal providing technically allows)... We'd all do fewer cool and useful things, and companies with money would do more of them out of sight.
I don't think that's an improvement over what we have now.
So yes, the buck has always stopped with the last mile developer putting other people's software together into a solution. That is a necessary requirement to have an open source ecosystem at all in a legal environment that demands that blame be assignable somewhere. But if we all start acting like that legal constraint is the only behavioral constraint that matters, we don't actually get to have an open source ecosystem.
Which is why I only use licenses from FSF: I want cool stuff I can use… I don't want my cool stuff to be used in cool stuff I can't use, or is used against me.
Anyway not inserting malware is not the same as "this is no longer maintained so I remove it to not be bugged about issues"
Which only works for products, not component libraries.
This software is provided 'as is'
You could consider this a weakness in npm's design... Most package managers don't have the decentralization of authority that npm does. But if it is weakness in the design, it's a weakness that the leftpad author chose to exploit.
If the FOSS ecosystem can't be safely built upon, companies have to build their own. If they have to build their own, they'll want to own it.
k8s and such tip the scales a bit, but there is still 10x more value locked up in proprietary software than with us software freedom zealots.
I will continue to release every piece of code I write into the public domain. I recognize however that the majority of people making valuable software do not share my ideology about the illegitimacy of the fiction that is "intellectual property".
The fact that you don’t have a business relationship changes the nature of your obligations to others - they are voluntary - and that in fact is at the heart of why software supply-chain is a problem. You have much more control over suppliers that you do have a business relationship with. As a community we have grown accustomed to moving at a pace that would not be supportable were it not for a network of volunteers around the globe maintaining and developing all manner of software and making it available as open source. It would be an enormous cost and reduce velocity significantly were that not the case, so I’m very greatful that they do this. During my career I have also made some small open source contributions myself. But that doesn’t make those people not suppliers.
The point, as I read it, is that the your relationship's with an open-source maintainer as their downstream is very much unlike your relationship with any of your suppliers (or other suppliers, if you want to insist), because you haven’t negotiated a business relationship with them (and they may not necessarily even want one in the traditional sense). Thus it is, in fact, unhelpful to refer to them as “suppliers” in order to draw an analogy with your normal suppliers, because they can and will tell you to go take a hike if you treat them like one of those. And given the nature of open-source software and the amount of business leverage you have over them (none, if you go about it the way most commercial consumers of open-source code do), it’s not unreasonable of them to do so. (Distro maintainers, for example, need a very special set of social skills for handling ornery upstreams, even though they both receive more understanding for their demands, being volunteers themselves, and do actually have some leverage in the form of being the main form of getting your software in front of users.)
(This is the part where I disagree with the article: the important part is not that, legally, the usual license terms mean they can refuse to provide support; it’s that, socially, it’s not unreasonable of them to do so. Google and Facebook also have license terms like that, but people do argue it’s still bad of them.)
Perhaps looking into the analogy the term “software supply chain” is intended to evoke is more helpful. One possibility, which is what most engineering users of it (among others) intend, is, indeed, that your open-source dependencies are your liability the same way as your traditional supply chain is, and that’s true. Another, which is what the article objects to, is that you are therefore entitled to ask anything of them, and that’s false. Given that the liability and the entitlement are two equally important and mutually supporting sides of the standard supplier relationship, there is reason to dislike the an analogy that is only correct in half of its implications.
You’re free to disagree with any of this, to be clear, it’s just that you’ve said the article is only playing word games, while on my reading it does seem to have a point, as above.
Hum... It's almost equal. For a start, you can demand anything that you have negotiated on, and can kick sand or try to pay outside if you want something else.
That's the point he author wants to talk about, but I don't think he has a good grasp of supplier - consumer relations.
I guess a more precise phrasing would be: the relationship is indeed almost the same as far as the rules of engagement are concerned, but the default starting point is very different: with a conventional supplier you don’t (get to) start using their product in yours until after basic terms have been negotiated, almost necessarily including some kind of right to have the supplier fix their stuff if it’s broken in an obviously stupid way.
Open-source things, though, individual devs can and do just pick off the floor. (Not necessarily good from a security standpoint, but hinder that process too much and work slows down to an extent most businesses won’t be able to afford, much like with installing outside software.) Which means that if you find some in your codebase and treat the author as you would any baseline supplier[1], just because there’s no way you wouldn’t negotiated the corresponding terms, you rightly get called an arsehole. This pattern of problematic behaviour predates the “software supply chain” meme, I think, but the fact that the meme seems to justify it in the minds of some people is a reason to dislike this analogy. Even if, as I said before, the other, liability half of it is entirely true.
[1] https://daniel.haxx.se/blog/2022/01/24/logj4-security-inquir..., https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644#c8, and I’m sure I’ve seen more of those
That if it breaks I get to keep both pieces. Or I can fix it if I’m able.
What I don’t expect is for them to intentionally break things and/or just pull the rug out from underneath everyone because “they’re well within their rights”. Sometimes being a dick is just being a dick.
Too many people seem to think they have some right to make money by giving away their labor for free because people take them up on their offer of free labor. Don’t want to work for free then don’t work for free. Don’t want the richest corporations in the world using your software without contributing back then don’t offer it to them under a license where they can do this. Easy peasy.
Can you point to some specific examples?
Like TFA.
When you look at something like SLSA (slsa.dev) it's more about internal build systems. You are pulling code and dependencies from somewhere, that is cool. Now that it is in your environment how do you validate it matches what the upstream provider has? How do you secure your build environment? How do you prevent the outputs of builds, stored internally, from being tampered with? The most popular strategy to date has been "hope" as in "hope is not a plan".
Where it sucks for OSS maintainers is you have companies coming in and continuing to try and apply hope internally and send prodding emails upstream to not rely on hope. That's bad and is not something worth OSS maintainers dealing with. Unless, you know, the company is offering money to do so.
Version Controlled: On the maintainer side
Verified History: On the maintainer side
Retained Indefinitely: Can be both
Two Person Reviewed: On the maintainer side
Scripted Build: On the maintainer side, could be both but not the current model
Build Service: Both i suppose
Build as code: On the maintainer side
Ephemeral env: User side
Isolated: Both
Parameterless: Both
Hermetic: Both but mostly maintainer
Reproducible: Maintainer side
Available: Could be discussed but maintainer
Authenticated: Maintainer
Service Generated: Both
Non-Falsifiable: both
Dependencies complete: Both
Security: Maintainer side
Access: Not applicable
Superusers: Both
It's not possible for someone to completely trace upstream dependencies in a SLSA compliant manner. No company can sanely expect that. What can be done is to say "we have some code from outside. How can we attribute it to upstream and make sure it has not been altered?" You can use signatures from the maintainers, version it, even reference a git commit. I don't think that anything additional from maintainers should be required, it's on the company to figure out how best to do so.
The reality of opensource are totally absent in these discussions. Noone say the things you just said.
I understand why you think it should be obvious and how it is done, but that is simply not the reality out there.
We did pivot the business model in ~ 2019 to open core, and I've tried to apply that to future endeavours like inlets, with the latest "actuated" - self-hosted CI in microVMs - it's a SaaS, with no open source components.
The common retort from users is "when we're in production, we'll pay for support / sponsor the project" - this literally never happens.
I applaud the author for laying it out how it is - there is no business relationship, open source maintainers are not suppliers, but if you want us to become your suppliers, have procurement reach out. Because we may well be able to offer you a relationship that would be mutually beneficial.
And "So-and-so Corp. couldn't do it without us" often proves a high standard of being taken seriously.
Examples of that (I think I saw a few earlier today) are all over the place, even here on HN.
The messaging idea is interesting but I wonder how wording like "may vanish at any time" would play into these software community goals of gaining qualitative legitimacy in the face of de facto intra-FOSS-world competition. It seems like a more creative method might be ideal.
But this is mostly true if commercial adoption is seen as a goal, and many projects make it clear that they 1) don't gaf about that and 2) are ready to negotiate a higher standard if the negotiated outcome suits their yet-to-be-communicated needs.
That's also not a very inviting model and it perpetuates a sort of harsh dichotomy around the issue of reliability and support in those cases.
It's really unfortunate because this dichotomy also makes FOSS seem less reliable from the business perspective on the outside, which isn't necessarily desired either.
This got a genuine LOL from me. Bravo.
I'm going to repeat my principle on the software supply chain issue: the responsibility for software security and other maintenance rests on those who deploy it. Deployments are the loci of harm from bad software, not projects. Secondarily, the weight of that responsibility should depend on the level of harm resulting and the level of benefit its owner receives. Whatever rules and conventions emerge from this fiasco, it needs to allow people to write software for fun, and even deploy it for fun as long as the damage is contained. And the people paying for maintenance need to be the ones making money from it.
Yeah a friend quipped that when i explained to them i was writing this post, and i asked them if i could shamelessly steal it and use it. They agreed. So i ran away with it.
I think Free code is quite unlike garbage, in that most Free software devs do somewhat hope their code will be useful or enjoyable to somebody, right?
Garbage is explicitly refuse, you don’t expect anyone will find it useful at all. The raccoons are a nuisance — we actually go to great lengths in some cases to make sure they can’t check out the garbage! People sifting through your garbage are probably up to no good.
I think is hard to make an analogy between Free software and a physical thing because most physical things are finite and can’t be copied for free.
Maybe Free software is more like a dance — you do your dance to for yourself, and to impress your friends maybe (or maybe as exercise, or some other motivation). You don’t mind if someone copies your dance. You might even help your friends learn it. But you clearly have no obligation to help strangers learn it, and no responsibility if they get hurt trying to do it.
> "There’s no free lunch in this world unless you’re willing to run around to different dumpsters to get it."
-Stay SaaSy
There is zero reason why the build process needs to access any external domain.
And if there is a new lib version or a problem/bug (depending on severity) then the product is retested with the new version before going out the door.
Of course, I dont have to do web front end. That stuff just seems wrong
As members of the tech community, we need to be careful of overwork and manipulation. I hold in high regard the numerous developers that maintain the libraries and packages that make my work possible. Unpaid labor is a huge problem in FOSS, people need to get paid.
Get paid, don’t work for free.
Yes, in freedom world, one have freedoms and rights, to choose irresponsibility, coding just for fun, etc.
But right solution here, not to just think all same level of responsibility (or irresponsibility) but to consider right to irresponsibility, and just avoid to use code/data from irresponsible authors, if important.
So I think, nearest time will appear some responsible's list (or irresponsible, read more).
This is not easy, but, unfortunately, ALL MODERN WORLD built on reuse of ready made pieces of knowledge and technology. Share of reused pieces is huge. So we MUST make some database (accurate and actual), from which people could get info if some piece of software (data) is supported, or find supported alternatives.
Who will pay for such database is hard question, from my exp, looks like this will slowly evolve from local (private) initiatives, to once country level or EU/OON wide db(s).
Because, with current unknown state, risks extremely high. And other people also have rights and freedoms, and many of them making significant free contribution to overall wealth, so it is not honest to leave them without support at all.
The other comment is right, vut tidelift is limited. There are foundations that cover whole ecosystems that may be of use.
Other than that, no not really. It is infrastructure we have not built because it is easier to not pay than to think about it
Is it more convenient to find commercial/proprietary vendors instead?
Or to use warranty-less software and pay for your own staff to track changes and be ready to maintain the software yourself?
For example, if I make neat-thing library and give it an MIT license, maybe I should not necessarily care about publishing it to a package registry (or in extreme cases, even versioning it).
Let someone else become the supplier and productize it / support it / semantically version it. This sort of reminds me of how Linux distros operate (minus maybe the versioning part?).
In this case authors can minimize their sight line to work only directly with those packaging their software instead of a million different companies. And even in that case, they can easily tell the supplier they can submit a patch or fork it.
Presumably, the supplier/packager would be more of an organized entity and capable of creating a business model and having contracts with companies on one hand and authors on the other.
This is an interesting idea to me. I think if every author moved to source dumping instead it would greatly change the dynamic. If I want to use it, I have to package it myself or pay some third party to do it. That is fair, not crazy onerous in at least some cases, and gets me - as a consumer of that code - closer to it and more responsible for its use.
The supplier is then the first contact for security issues since they are delivering the software. They can fix it directly, upstream a patch, or try to convince the author to fix it.
The most successful suppliers will be the ones that submit the most patches because authors will find them easier to work with.
So my wild theory here is, if you have a super popular package, continue publishing the source and just totally stop publishing the artifact and see what happens. If it forks, I still see your package as being the upstream that everyone follows since it's actively being worked on. It will create an interesting situation where the delivery is split from the development.
What if I don't want to do full time open source ? Simple, pass these "form-filling" responsibilities to another friendly open source maintainer. No need to change licenses, ownership, etc.
I love clever puns.
> The fact you made your product depend on it is your responsibility. Not mine.
Yup.
Successful open source providers need to morph themselves into vendors, that is clear. The process needs to be low friction for all parties (subscription model). The article hints that the success of that transformation to vendor is governed by the supplyee being able to continuously drive change/quality requests down to the supplier to get what they need out of the code.
At first blush, I think: "to a package manager, attach: a credit card/subscription system, ticket tracker/change request system and the supplier's email/contact info". A system like that would mean, if you are a big megacorp, whenever one of your devs adds a package to their dependencies, and that package is from someone that wants to form a supplier relationship, the subscription request is automatically submitted to the accounting department for approval. Upon approval, money flows, and yucky details like seats and corporate rates can be negotiated by the accountants or legal. That would be an amazing improvement over the "labor of love" buy-me-a-coffee model we have today.
I think the grumbling begins in such a system where a package was free/unencumbered and it suddenly become a paid one. Kind of feels like a rugpull especially for supplyees that ARE poor and ARE only raccoons rummaging through trash. Perhaps there are rules of how to appropriately rugpull that need to be in-effect.
What I do not glean from the article is how money would necessarily transform an OSS developer into a supplier. Maybe the developer is an amateur supplier and will never get their shit together enough to truly meet the needs of the suppliee. Maybe they are a solo developer and die and leave the supplyee hanging.
The license and copyright I think necessarily need to preserve the AS-IS nature of the software itself due to the power imbalance between supplier and supplyee. But then how do we handle issues of negligence and impropriety on the part of a supplier?
In my mind it comes down to copyright. There has to be a socially acceptable weakening of copyright when a supplier turns bad or goes missing. Some arbiter (the package manager itself) can sever the subscription and give the supplier's copyright away so that it can find a new home.
Such a system ultimately becomes corrupt and the suppliers will get screwed out of their labor though. I can't see how such a system can be made to work in the long term and AS-IS is the best we can do. Le sigh.
I'm just spitballing, I'm skeptical this would work, but if it were attempted, something critical would be it being a partnership and not that the supplier becomes the boss of the open source projects.
I personally think that the solution is more in line of something like https://sovereigntechfund.de/, where taxes pay for support of what is fundamentally infrastructure
> Thanks for contacting us. To get help with this issue, please reach out to Curl: https://curl.se/gethelp.html
The original tweet was deleted. If this were a bug report related to the system distribution of curl on M1 macOS (apple's proprietary platform), it seems somewhat entitled that Apple would pass the support burden to the curl author without providing resources to debug on their proprietary platform
It's hard to tell, but it sounds like the user had a question about how to use the `-E` flag.
Directing them to https://curl.se/gethelp.html seems... reasonable? The first link on that URL is to the curl-users mailing list, which seems like a reasonable venue for such a question.
Sure, Apple ships curl, and maybe doesn’t support it (are you sure? Don’t they build and test it from source on their own servers? Isn’t that a form of support?).
But Apple also ships and supports WebKit, which - as the original basis for Chromium - has arguably had a bigger impact on the world than curl has. And I suspect that Apple also contributed to some of the standards that curl relies on. Of course, Apple built WebKit as a fork of KHTML… but if memory serves, they didn’t have to make the fork open source.
I’m not trying to defend Apple in any way, I just think that the conversation can be a bit more sophisticated than just “big company ships free software and gives nothing back”. Apple has shipped some really cool open source software in the past, and I think it’s disingenuous to suggest that they owe something to every package that they ship. That is not really in the spirit of free software.
The gist of what rubs me the wrong way is that Apple is following curl’s license precisely and people are still unhappy.
I view Apple's behavior the same as I do people who leave their shopping carts loose in the parking lot instead of returning them to the corrals. Sure, they aren't legally required to provide any form of support to curl, but they would anyway if they had any decency.
I really like your blog theme though so I cut+pasted it into my own blog but there's some kind of css issue. I msg'd you details. Take a look when you can, hopefully soon, I have a big post going live tomorrow.
Where did you message me ? I know i have all kind of problems with it but never had time to deal with it :D
Also the TL;DR is the title :)
Thank you for the explanation
I agree with the fundamental points here. Expecting things like they describe out of open source volunteers is absurd.
But screaming “I am not a supplier” in this context is like yelling “I am not a driver” while driving a car.
If you take the sofa i left on the side of the curb to bring it home, i am not your supplier.
You found something for free in my trash. That does not make me your supplier. Me being your supplier mean we have a relationship that does not exist here.
And yes, you literally are a supplier if you are putting things out there for free, with no strings and no support, and others are taking them.
(The article is very nice otherwise and I agree with your points, just not the language)
I mean, the analogy sucks. But it’s worth considering that you’re doing more than just putting it into the ether.
Analogy doesn’t suck, looking through “I’m entitled” lenses distorts the picture for you.
It’s when the code is maintained, bugs are fixed, releases are put together, etc. that people start acting entitled.
A better analogy would be someone who opens a sofa depo, starts giving away “as-is” sofas, then starts building new sofas and improving them. Some people take those sofas and use them in rental homes. Then it turns out that someone planted listening devices in some of the sofas, so the landlords start showing up at the depo and asking questions about supply chain security…
Yes, you are. That you do so completely passively doesn't erase the fact that you are supplying something and that some kind of a relationship exists.
The law(s) generally also recognize it like that, and the license you are quoting does so as well ('_provided_ "AS IS"').
Sure, your relationship can be a completely passive non-business no-strings relationship, but the relationship is still there.
See, it works perfectly fine.
In your new example, the phrase "your driver" does not refer to a business relationship, so I guess saying "I'm not your driver" to someone because you don't want to ferry them around is now also poor use of language? Just stop dude.
If you use those replacements in the analogy, then the analogy will work much better.
Except driving is active. You must take acts to drive, it is a continuous commitment. There’s an expectation that if you’re on the highway driving someone they won’t jump out the window and let you crash. Ideally even they’ll get you where you wanna go.
Sharing some software for free is passive. You can share something and walk away. They can even die and the software is still shared. It’s a single action. Push publish, walk away. There may be an expectation of continued support, but it’s based on historic behavior not on actual commitments.
Entering a business relationship is active, and there should be an expectation of support (based on contracts of course).
Selecting a specific open source license and issuing releases and bug fixes is pretty far from “passive.”
Passive would be not putting the code software online and not inviting others to use it.
Its a one-time action. Its "set and forget". That's pretty passive. Yes, you took a direct action, but its not an ongoing action.
> issuing releases and bug fixes
Again, after each fix, you're done. And to the original point, you're never committing to anything.
To repeat my original point, a maintainer could die and the software would still be shared, and the companies that use it would have the exact same relationship they had prior.
What obligation do I, a person developing FOSS in my free time without compensation, have to a consumer of that software (and especially to a consumer who is likely making money in part due to their use of the software I wrote)?
But so what? That does not change the fact that a person developing FOSS supplies something—in fact in most cases they supply a ton of value.
Your supply chain involves everything you use and rely upon, no matter if its provided by a business relationship, taken out of the ground, provided by the government, made in-house, or found in outer space.
The point of supply chain management is to manage the inputs to production. Analysing this process using tools from other industries is, at least, a defensible approach. It doesn’t, in itself, imply any obligation on the suppliers. It’s just a way of thinking about the world.
If you write code and make the conscious decision to assign a liberal license and build it and test it and update it and make it available, it’s really hard for me to accept that you are not a supplier of that code. Your license specifically excludes any obligation to users of your software. But the whole essay just felt like semantic tricks to protest against the idea that software can be modelled as if it is some kind of industrial process.
Like I said, your (presumed) license specifically excludes any obligation to users of your software. I’ve written free software and proprietary software, and one thing I’ve learned is that the world is full of entitled jerks. Entitlement has zero meaningful intersection with software supply chain management.
By most reasonable understandings I would say no. We have no relation at all.
This is not right analogy, cad drawings are not the code. It is relatively easy and near instant, to change license (for cad drawings), and prohibit make materialized copies without written permission.
But I must admit, in freedom world, You have rights and freedoms, to be irresponsible, we just need to figure out, how this could co-exist with real life issues, like supply chain safety.
See the last sentence.
> We are volunteers, writing code and putting it online under these Licences. And yes, we put it online for people to use them. But we do not get anything from it.
Some people publish their code on npm or as crates or whatever. These packaging systems are designed to allow people to download and use your code without reading it.
Worse, they can end up using the code indirectly, without reading it. Do you think they see your repo or the README or the license?
So what I'm saying is that if you take no responsibility (which I support), you should stop doing that (if you are), because it confuses your message. Although there's no money involved, these packaging systems encourage consumer-like behavior.
Sounds to me like a perversion of the intent of FOSS infrastructure.
Because I was taught that sharing is a moral good. Are you suggesting that anyone who shares their source online is obligated to also provide free support to any and all users?
Similarly, publishing your code in a store-like repository so people download and use it without reading it, or even knowing that it's a dependency, encourages people to treat it like a hidden part of a product.
Or is not actually a store?
There are people who give away software, support it (at least making security patches), and are fine with other people relying on it. If that's you then publishing it as a package makes sense.
But a lot of us are not really prepared to do that with the software we write, and we should be wary of the implicit promises we make with how we publish it. Publishing example code or a notebook is safer since no library is going to add a dependency on that code.