I am not a supplier

https://www.softwaremaxims.com/blog/not-a-supplier

by di4na • 4 years ago

389 234 4 years ago

steve_gh• 4 years ago

Needed saying. Chapeau!

bhickey5• 4 years ago

Some months ago after recoiling in horror from a vulnerability in rust I arrived at the grim realization that the "supply chain attack" problem is intractable in impure languages. When a transitive dependency can do anything it will inevitably do something. I don't expect to convert everyone (or anyone) to object capabilities and purity, but I do hope the experiences of the past year have put the fear of God into developers. We should aspire to build systems where a suddenly malicious or busted dependency can't knock over the whole tower.

TAForObvReasons4• 4 years ago

the current fragility of the "software supply chain" stems from package managers and their perverse economic incentives, and this is just as true for "pure languages". Vendoring and auditing dependencies greatly reduces the attack surface area.

bhickey5• 4 years ago

Can you elaborate on the incentives of package managers? The problem I see with Rust is that it's just really easy to add dependebcies in a way that is difficult in C++.

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.

gizmo686• 4 years ago

Its not intractable. You just need to take the concept of a software supply chain seriously.

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.

dragonwriter• 4 years ago

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

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.

Hizonner4• 4 years ago

You only need 1 trusted organization across the entire industry to certify a baseline of trusted software.

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.

mnw21cam• 4 years ago

I would suggest the Debian Project and similar distributions as a fairly good scaffold on which to build such a system. All it needs is a notarisation mechanism, so certify that a person has had eyes on the code and says that it is ok. Plus, I'd trust them more than the US government. Though there's no harm in having multiple bodies all certify a code-base.

klabb3• 4 years ago

The NSA, […has] a vested interest in protecting critical domestic infrastructure

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.

esperent2• 4 years ago

The NSA

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.

cortesoft2• 4 years ago

Ok, even if we could all agree on a single trusted auditor, that would still put us in a very bad position. You would be limited to only use that baseline trusted set of software, which I guarantee won’t be sufficient for all the things you need as software grows and develops.

numpad02• 4 years ago

You would be right if we were all running properly engineered hardware and software, but software engineering stopped being a subcategory of engineering 30+ years ago.

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.

NikolaNovak• 4 years ago

Software exists outside of USA.

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.

bombolo6• 4 years ago

to certify a baseline of trusted software.

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.

di4na21• 4 years ago

Author here.

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.

asdfghjhgfderty• 4 years ago

nonsense.

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.

WarOnPrivacy• 4 years ago

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 ?

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.

numpad02• 4 years ago

NTP, OpenSSL, OpenSSH, the BGP daemon, the libc ... by people that can barely pay for their food

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.

csomar• 4 years ago

are all maintained and "fixed" and evolved by people that can barely pay for their food, even less for basic tests ?

I suspect many people working on OSS are getting paid, if not handsomely, then enough to survive.

tsimionescu• 4 years ago

Can you give some examples of such a pure language? Haskell is definitely not it, since you can always call unsafePerformIO anywhere to do anything. I would guess Idris has something similar, but maybe I'm wrong.

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.

bhickey5• 4 years ago

Can you give some examples of such a pure language?

BPF and eBPF, though this feels unsatisfying.

sethammons2• 4 years ago

Hence why I check in vendor dependencies. It is wild to me that people pull fresh their dependencies on builds, trusting patch versions that really should have been major versions.

lucasyvas2• 4 years ago

Vendoring is an option, but if you place some trust in your registry a lockfile is totally fine.

yencabulator• 4 years ago

Functional purity is the wrong abstraction to ask for, and doesn't protect you as such (consider a Haskell library that, very purely, asks to write to ~/.bashrc).

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.

roxgib• 4 years ago

Hard to believe this even needed to be said, yet the FOSS entitlement continues unabated to this day. The post a few days ago from the developer of curl was pointed example of how bad this has become. https://daniel.haxx.se/blog/2022/12/30/an-m1-for-curl/

Waterluvian3• 4 years ago

Probably gonna be unpopular but I feel like I got the opposite message: Apple is using FOSS in a completely normal, completely legal way. But some people in the comments were upset that Apple wasn’t voluntarily donating to the project. That feels like entitlement.

TAForObvReasons4• 4 years ago

https://twitter.com/AppleSupport/status/1461330383425970180

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

chamwislothe2nd• 4 years ago

Yeah, they're the richest computer company in the world. It would be cool if they were more generous. That's all.

maxbond2• 4 years ago

Perhaps something that's needed is suppliers you can pay to provide a warranty for open source, who share revenue with the relevant projects (with a corporate structure that guarantees this, some flavor of B corp). So I pay Foo, Foo pays Daniel, and Foo stays on top of curl's releases & makes sure that Daniel is getting the support he needs (putting out bounties or buying him a MacBook if he isn't) and that malicious code hasn't slipped into circulation.

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.

hotpotamus• 4 years ago

That sounds more or less like Red Hat (I suppose now IBM). I don't entirely know the ecosystem, but I believe they give some money to the Keycloak project (which my company uses). I'm sure they sponsor others, but I assume the main contribution is developers - if you look at commits on the average project github, there's a good chance Red Hat will be well represented, and for core Linux components, they'll probably be at the top. Intel will also have a significant presence. Sun was big on this back in the day as well.

zokier2• 4 years ago

While support contracts with RedHat/SuSE/etc do not go as far as take full liability, it is essentially their business model to take money from corps and funnel it into maintenance

di4na21• 4 years ago

This is basically what Tidelift does.

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

indymike2• 4 years ago

Warranty on software? I’m trying to say something profound but I keep uncontrollably laughing.

zokier2• 4 years ago

Isn't offering hardware donations for devs the opposite of entitlement?

D13Fd11• 4 years ago

“I am not a supplier,” they say, while supplying things.

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.

jFriedensreich• 4 years ago

no its not. its saying i am not an uber driver to the pretentious guy entering his car on wallstreet.

ipsum2• 4 years ago

It's pretty clear from the article that the author defines supplier as being in a business relationship, using "supply chain" as the context.

D13Fd11• 4 years ago

Why even go the route of narrowly defining the term just to say “I’m not that”? It just makes the argument literally untrue even though the underlying points are correct and important.

PeterisP• 4 years ago

For an analogy, if one of inputs of your business uses trash of others (e.g. for recycling), then the people throwing out this trash are effectively your suppliers and the ones you must consider in your supply chain, because no matter if you have a business relationship with them or not, they do matter in your supply chain, so you have to treat them (and risks related to them) the same as all other suppliers.

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.

SuperNinKenDo3• 4 years ago

To run with your analogy: It's like offering a near complete strange a lift because you're headed close to where they're headed. Then they start calling you asking for rides. And you say "I am not your driver."

See, it works perfectly fine.

D13Fd11• 4 years ago

Sure if the author had said “I’m not your supplier” rather than “I’m not a supplier.” Big difference.

di4na21• 4 years ago

Author here. As pointed out in the end, in a different paraphrase.

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.

D13Fd11• 4 years ago

The title of your article is “I am not a supplier,” not “I am not your supplier.”

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)

bumbledraven• 4 years ago

More to the point, if you leave free sofas in a place where there is ~always one for someone to take if they want, you are a supplier.

hobofan• 4 years ago

If you take the sofa i left on the side of the curb to bring it home, i am not your supplier.

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.

vineyardmike2• 4 years ago

But screaming “I am not a supplier” in this context is like yelling “I am not a driver” while driving a car.

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

D13Fd11• 4 years ago

Sharing some software for free is passive.

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.

quickthrower22• 4 years ago

I am not a driver, while creating free car blueprints that car manufacturers use to build cars?

doctor_eval3• 4 years ago

I am completely with you on this. It feels like it’s just tricky semantics.

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.

xena• 4 years ago

If you want me to treat my hobby projects seriously, where is the money to pay for the time for me to treat them seriously?

Rochus2• 4 years ago

That's a fallacy. Assuming that an open source developer is a "supplier" just because there are users is a hasty generalization. Important elements are missing for it to actually be a customer-supplier relationship. From a legal perspective, for example, the contractual intent is missing.

Ekaros3• 4 years ago

I make cad drawings of some product, release them with permissive licence on Internet. Some company or you comes and copies them and starts making the product? Am I the supplier of the design? Do you have right to ask for changes?

By most reasonable understandings I would say no. We have no relation at all.

simne4• 4 years ago

I make cad drawings of some product, release them with permissive licence on Internet

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.

andrewflnr2• 4 years ago

So all your Software Supply Chain ideas? You are not buying from a supplier, you are a raccoon digging through dumpsters for free code.

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.

di4na21• 4 years ago

Author here.

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.

bee_rider• 4 years ago

It is a nice quip, but is it true?

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.

ChrisMarshallNY2• 4 years ago

Reminds me of this quote:

"There’s no free lunch in this world unless you’re willing to run around to different dumpsters to get it."

-Stay SaaSy

andrewflnr2• 4 years ago

It's good they included the running around. It's easy to forget that you're not only eating garbage, you're working really hard for it.

resonious• 4 years ago

Yeah I always found it pretty funny how easily we add libraries at work. We do a lot of code review and ensure near-100% line coverage, and yet we don't hold libraries to any standard at all. You can just add libraries and nobody will bat an eyelash. I've peeked into the source code of many of these libraries to find that they're often questionably architected, untested, or otherwise just not up to the standard to which we hold our own code.

chasd00• 4 years ago

NPM needs a msg displayed in bold on every command that says “these packages may vanish at any time and may not even be what you’re expecting”. I think package managers presenting all packages as equally supported and vetted is part of the problem.

themodelplumber• 4 years ago

There is an unseen alignment of incentives. The typical FOSS dev community wants its project to be taken seriously. They anticipate competition with other FOSS projects which are commercially backed in many cases.

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.

quickthrower22• 4 years ago

Remove node_modules from .gitignore (and make git handle doing that more graceful!)

mesozoic2• 4 years ago

And the maintainer may change what the functions do randomly for any reason including they found it funny.

bitwize2• 4 years ago

Most places I know that did node shit pulled their dependencies from an in-house Artifactory instance. Means no exotic libs -- or upgrades -- until you can get the new library or latest version vetted, at least in principle.

rboyd• 4 years ago

tl;dr

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.

di4na21• 4 years ago

Author here

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

xwowsersx2• 4 years ago

lol I think they were giving a tl;dr by giving an analog to someone ripping off your css and expecting help from you. It's an example of how people who use your freely available software for their project behave. They come along, as you say, like a "raccoon digging through dumpsters for free code." But then they think they're entitled to think of you as a supplier and that you should provide support. That was the joke in "I have a big blog post going live tomorrow."

rossta• 4 years ago

LOL this was my favorite comment

shadowgovt9• 4 years ago

I like the position of this author and think it's quite correct, but FWIW the logical conclusion if we pull the lever all the way over to this line of thinking is that in the modern era, the FOSS ecosystem has failed as a business model and companies will be better off developing their cores in-house (with all the opacity and lock-in that implies), and the pendulum swings again.

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.

di4na21• 4 years ago

Author here.

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.

shadowgovt9• 4 years ago

Agreed. What I'm thinking of specifically is the leftpad attack vector, where a trusted actor suddenly went malicious and broke the software many people were lying upon who didn't realize they were relying upon it (and weren't really in a position to be aware of the issues the author had encountered).

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.

Rochus2• 4 years ago

The difference is that FOSS is not a business model

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.

D13Fd11• 4 years ago

"FOSS is infrastructure" and "FOSS maintainers are not suppliers" seem pretty at odds. It can't be both "infrastructure" and akin to a couch you dump in the trash (as in the example in your comment below).

cortesoft2• 4 years ago

I am curious… what percentage of FOSS work for the most critical systems is done by people working for free verse people on a company payroll? I feel like most big FOSS projects have corporate sponsors.

sneak• 4 years ago

Most of the most valuable software in the world (iOS, Play Services, Google Workspace, all the Nvidia libs enabling the AI revolution, Windows, Excel, GitHub, etc) is proprietary. It's easy to see the huge successes of f/oss and forget that it's only the tip of the value iceberg.

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

D13Fd11• 4 years ago

I strongly disagree. FOSS software is king when it comes to value provided (but not, obviously, revenue generated). All of those things you list incorporate free software (e.g., MIT licensed software, public domain software) or at a minimum rely on servers servers and infrastructure that do.

LamaOfRuin• 4 years ago

5 of the 7 things you listed would not exist in any recognizable form without having been built on top of open source software.

josephcsible2• 4 years ago

I don't see how this position means FOSS would fail as a business model. It's not like anyone would be saying "we won't ever provide these guarantees." It's instead "if you just want to use my software without paying, go for it. But if you want any supply chain guarantees, then pay me for them."

shadowgovt9• 4 years ago

Agreed; "as a business model" was a bad phrasing. I meant to say "as an alternative to the traditional closed-source business model."

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.

mesozoic2• 4 years ago

Seems better we keep pretending it's ok. Let big stupid business build big stupid generally pointless stuff and hope they contribute back to the foundational open source stuff before they go out of business.

massysett• 4 years ago

Doesn’t paid support to middlemen mitigate this problem? If Bigcorp pays Red Hat, Red Hat should fix the software and work with upstream to do so, thus making the fix Red Hat’s problem. Red Hat knows how to work with upstream to get fixes merged long-term.

ChrisMarshallNY2• 4 years ago

TL;DR:

The fact you made your product depend on it is your responsibility. Not mine.

Yup.

er4hn2• 4 years ago

I completely agree with the primary point of the author, which i summarize as: don't ask me to meet your companies arbitrary requirements for code when we don't have a business relationship. Completely fair. However I don't think that is what software supply chain security is about.

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.

di4na21• 4 years ago

So I went to check SLSA

  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

So SLSA mostly demand work from the maintainers, not the users.

er4hn2• 4 years ago

Thank you for reading through it and summarizing. I disagree with your conclusion however.

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.

skybrian5• 4 years ago

It's fine not to be a supplier! I'm usually not. But in that case, why publish your code so that people will think you are a supplier? Better to publish it as a gist, a notebook, or some other way of sharing example code, not as a package where people who want to reuse code without adopting it will expect to find such things.

di4na21• 4 years ago

But i did write in big, capital letter that i am not a supplier in the licence, in the repo.

See the last sentence.

skybrian5• 4 years ago

I don't know where you publish your code. You did imply at some point that you're not just talking about yourself, though:

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.

TheCleric2• 4 years ago

why publish your code so that people will think you are a supplier?

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?

skybrian5• 4 years ago

The only obligation I think you have is to avoid misleading people by sending mixed messages. If the code is really provided without support, it's not enough to just say that in the license. You also want to make sure that the way you present your code to strangers online doesn't encourage them to think of it as a supported product. For example, creating a slick website with a marketing message about how great your software is (so try it now) would undermine the message that it's just provided as-is and any bugs it has are yours to fix.

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.

jxcole• 4 years ago

"everyone depends on their particular bolt, and we are all screwed."

I love clever puns.

itqwertz• 4 years ago

Kudos to the author, really needed to be said. I really liked the bolts and “screwed” play on words. Great article.

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.

sweetjuly• 4 years ago

My (least) favorite instance of this is in the response to the Log4j vulnerability. Evidently some companies tasked people with ensuring that ""all of their suppliers"" had patched the issue and were in compliance. This lead to random open source projects, many of which could not possibly be vulnerable, being inundated with form letters demanding that the project meet ABC Corp's new security requirements. Most maintainers told them to kick dirt, but it was truly bizarre seeing people think they were in any position to make demands over a project that they aren't paying for.

wildrhythms• 4 years ago

Makes me wonder who the hell is in a position to write such a letter, and how the hell they got to that position obviously being clueless about security and their relationship with open-source projects like that.

delfinom• 4 years ago

Plenty of people in the world simply comply with handed down corporate directives rather than start discussions internally.

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.

efitz• 4 years ago

I’m a security engineer at a big technology company. I’ve been a security engineer at several of these. I’m speaking for myself here, not for current or previous employers.

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!

whatshisface• 4 years ago

If a good acronym is what we need, why not Outsourced For Free, or OFF-ware? ;)

strogonoff2• 4 years ago

Using other terms than “software supply chain security”—for example, “open-source ecosystem security”—could benefit status quo, even if (or especially if?) the recipient of the language is internal management.

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.

SAI_Peregrinus• 4 years ago

But "software supply chain security" also encompasses proprietary dependencies. A game dev using a third-party engine still has to care about the security of that engine. Likewise for proprietary plugins to various programs. Likewise for all proprietary software used by the company (MS Office, etc). They're all part of that company's "software supply chain", even though they're not open-source.

411111111111111• 4 years ago

will evoke specific concepts in the people I work with

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.

Linosaurus• 4 years ago

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.

Using the terms software supply chain security to point out that no supplier exist to work with or blame, seems fair enough.

mananaysiempre4• 4 years ago

As I said in a sibling comment[1]:

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.

[1] https://news.ycombinator.com/item?id=34205659

sethammons2• 4 years ago

Another, which is what the article objects to, is that you are therefore entitled to ask anything of them, and that’s false.

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.

waynesonfire• 4 years ago

You are a huge part of the problem the author is trying to articulate. Re read the authors last paragraph. Your answer are your bs security monitoring tools. Let me guess, the chart is all red and riddled with exemptions? Nice work.

vivegi2• 4 years ago

Agree completely with the author.

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.

foobiekr• 4 years ago

The problem everyone who cares is wrestling with is that software teams in practice do no diligence at all.

vivegi2• 4 years ago

I agree. What used to be called Build vs. Buy decision usually involved a calculation of costs. There are lifetime costs involved in both choices. If a dev team chose to use a FOSS library/product (pr even a commercial 3rd party library), that analysis isnt complete without an assessment of practices needed for maintaining it over the entire lifecycle of the product they are building.

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.

marsupialtail_2• 4 years ago

I sponsor OSS software I depend on and you should too!

mickael-kerjean• 4 years ago

That's great but unfortunately you're the minority. 0.004% of users ends up giving something in my OSS project

cc101• 4 years ago

Putting the key idea last after building up the essentials is a common geek failure mode. It's a bad idea because it discourages readers from finishing. It leads directly to TL;DR.

di4na21• 4 years ago

I put the tl;dr in the title. I can hardly lead harder with the conclusion

dgudkov• 4 years ago

It's a very correct article. But here is a question: I run a software company and we're ready to pay for the FOSS we use in our product. Is there a convenient standard way to pay all the 50+ maintainers without having to spend years drafting individual contracts with each of them from a clean slate?

eesmith• 4 years ago

Depending on the FOSS you use, yes. Eg, https://tidelift.com/ .

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?

di4na21• 4 years ago

I did mention it was hard to do isn't it.

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

alexellisuk• 4 years ago

As the founder of OpenFaaS, the author doesn't know how true this rings - given all the myriad enterprise users of the community edition/OSS code. Even with smaller projects like K3sup, where I've seen defence contractors have k3sup references in their codebases and issue comments, go on to ask for changes, yet publicly stating they've never used it.

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.

simne4• 4 years ago

Do You really want make money with OpenFaaS?

tlocke2• 4 years ago

As a maintainer of open source libraries, the steps I've been asked to take to secure the supply chain are:

* 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 :-)

_nalply2• 4 years ago

I agree with the term "anarchy" as long as other people don't take my human rights away.

senko3• 4 years ago

Authenticating myself with a physical security key. (requested by PyPI)

Is that only for some packages? I publish a few obscure ones (not widely used) and get away with just a password.

Semaphor• 4 years ago

Top 1% get them for free and have to use them from my undrstanding: https://portswigger.net/daily-swig/pypi-repo-to-distribute-4...

daitangio• 4 years ago

Interesting point indeed. It remembers me the Raymond’s “The Cathedral and the Bazaar” book. As a consultant my work is ro take care of the software I produce and use.

jimjimjim• 4 years ago

Where ever possible if I use an open source lib in a product I download it and store it locally (inside corp) for build servers to grab or bundle it in with the code in the product repo.

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

seanhunter• 4 years ago

I don’t follow the author’s logic at all. Just because you don’t have a business relationship with the end user doesn’t make you not a supplier. If you make software available to others to use, you are supplying the software to them. You are therefore very clearly a supplier. Pretending words don’t have any meaning doesn’t help to resolve the problem.

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.

_nalply2• 4 years ago

What do you expect from FOSS "suppliers"?

UncleEntity2• 4 years ago

What do you expect from FOSS "suppliers"?

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.

mananaysiempre4• 4 years ago

I wanted to say that the title is being a bit too slick in using “supplier” instead of “member of your supply chain”, but then I realized while that’s true, it’s not really the point.

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

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.

marcosdumay• 4 years ago

the your relationship's with an open-source maintainer as their downstream is very much unlike your relationship with any of your suppliers

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.

Juliate• 4 years ago

« provenance » would be a more accurate name than « supply », as it englobes both software that’s actually supplied, and software available « as is » that’s being picked up.

fxtentacle• 4 years ago

"you are a raccoon digging through dumpsters for free code" sounds like a great metaphor for inexperienced people using Copilot.

bell-cot2• 4 years ago

One analogy I've used a few times, with the suits:

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.

hartator2• 4 years ago

up-to-date on its shots

FOSS had to be up to date? It’s not a good analogy.

bell-cot2• 4 years ago

Talk to somebody who has had a dog with serious ongoing health issues. "Up to date on its shots" is a very, very low bar for actually knowing that a dog is healthy.

EdSharkey• 4 years ago

This is one of those important articles that Will have me thinking years down the line. This article is howling into the void for change. Can we change now? Please??

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.

lebaux• 4 years ago

and I am not a rapper

lucasyvas2• 4 years ago

An interesting thought I had - maybe part of the problem is that certain project maintainers should not be packaging their software and simply release licensed source.

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.

di4na21• 4 years ago

The reality has not shown that though. There are a lot of packaging mechanisms and all of them have even more problems getting paid.

Aissen• 4 years ago

I don't understand, this paperwork machine should be the inflection point we need to finally pay open source maintainers: want supply chain security ? Pay $Xk per year per form you want me to fill. Multiply this by every company and no open source maintainer that wants to go full time should need another day job.

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.

simne4• 4 years ago

I'm disagree with author, but must say, he talking about really important things.

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.

I am not a supplier

Related Stories