Generate SLSA Build L3 provenance

[ianlewis]

Generate SLSA Build L3 provenance

[isaacs]

Hi, Ian.

I currently have no motivation or intention to do any of that. "Supply chain security" is a concern for giant corporations that use the products of my labor to make billions of dollars without paying me a penny.

I don't begrudge the megacorps of the world for using the OSS I produce; I produce it to be used. But what you're asking for here is not fun or rewarding. It's work, and I am not going to work for one of the richest companies in the world as a charity.

It's not a "supply chain" without a "supplier" relationship, which I do not have with Google. If they are interested in engaging in such a relationship with me, I'm very much open to it. Otherwise, they can establish the provenance of my code in all the traditional ways, by inspecting commit shas, package signatures, public keys, and so forth.

[ianlewis]

Hey Issac,

I appreciate the feedback. I think most OSS consumers could benefit from improved provenance of packages though perhaps you're right that larger organizations care about it more due to being bigger targets for attacks.

Regarding your comments on a "supplier" relationship. What did you have in mind? I'm not sure I can speak to this specific project but I think we do try to apply resources where we can.

[isaacs]

I think most OSS consumers could benefit from improved provenance of packages though perhaps you're right that larger organizations care about it more due to being bigger targets for attacks.

Yes, I "could benefit" from the OSS I use having verifiable provenance. But there's a whole world between "could benefit from" and "will do work to make happen". The benefit I would expect to gain from the activity is significantly less than the cost of spending any time at all on it.

The only way to get there from here with stuff like SLSA, in my estimation, is through a cultural push starting from the highest visibility developers, like you're doing here. However, the only fast or reliable way to make that cultural shift is to buy it. An expert lawyer who's been practicing for 20 years can expect to be paid anywhere from $650 to $1000 per hour for their time and attention in service of a client. However, the expectations of OSS are that we will do everything for free "for the good of the project" or "for the community", even when the richest companies in the world are the primary beneficiaries.

Until then, I expect we'll keep seeing what we're seeing. The projects and devs funded by large corporations, or by foundations with those companies on their boards, will get set up with the all the supply chain security stuff, and everyone else will keep giving zero fucks about it.

Regarding your comments on a "supplier" relationship. What did you have in mind? I'm not sure I can speak to this specific project but I think we do try to apply resources where we can.

In the broadest sense, we are not "suppliers", because there is no commercial relationship. If you dig leftovers out of the dumpster behind a restaurant, they're not your "food supplier".

I can wrap my code in SBOMs and signatures and verify that the build happened on known-good architecture, but Google et al are still picking software out of that dumpster. It's good software, most of it! If you go to a 5 star restaurant, their dumpster probably has some good stuff in it. But at the end of the day, that's about the level of relationship that exists between producers and (corporate) consumers in OSS. It is anathema to most companies to pay more than the price tag for something, and the price tag on OSS is usually $0.

I've kicked around a few ideas about businesses to start that would let me and hopefully others to do OSS full time and capture a more reasonable share of the value created (ie, more than "none of it"). There are fairly simple approaches that I think could work and would put OSS on much more stable footing while, incidentally, doing more for OSS security than initiatives like SLSA or SBOM, by aligning incentives.

My long term plan is to eventually move everything to a licensing model where my OSS is free for individual/noncommercial/educational use, and free for commercial entities below a certain size, but charge a flat monthly rate based on employee count (or some other reasonable proxy for "size", assuming most large private companies would not be willing to share their revenue numbers), up to a cap. For that price, you get a license to all software in the catalog. Out of compliance, license reverts to "all rights reserved". Then the more devs that decide to get on board, the more compelling the value proposition to subscribe.

There'd then be clear incentives for any dev participating to ensure that their projects are well documented, tracking provenance, responding to support issues, etc. Hell, for that matter, it'd be a good idea for the collective to invest in innovating on new and better ways to ensure that the dependency deployment chain is as secure as possible. And if a subscribing company were to need some extra work done related to an OSS project, they'd have an established commercial relationship with the group best equipped to handle it, and it'd be rolled up into a single license fee that they pay each month, rather than needing to justify sponsoring thousands of individual projects.

I don't see any "OSS sustainability" projects ever being successful without both the carrot of improved stability, support, and reputation, and the stick of withheld labor. Corporate funding for marketing/devrel objectives, or to apply resources to projects at risk, is far too unreliable to base an actual lifestyle on. ("Successful" here means: "reasonable expectation that a top 1% OSS dev can expect to make a living in a major metropolitan area", so an expected gross revenue of at minimum around $150k-250k.)

In the immediate term, just speaking for myself as a solo agent, for a few thousand dollars a month, I'd make myself available for up to 4 hours of arbitrary busywork per month that a customer needs done. Designing a new CI system and using it for all my projects is a much bigger hassle though. I'm not interested in doing it for just one or two of them, since inconsistency makes this hobby way less fun, but of course would be happy to prioritize first doing the ones that are higher value. But I'd take it on if someone wanted to pay for it.

A big part of the challenge here is, the reason no reasonable company would pay more than the price tag, is the freeloader problem. Why would Google pay for OSS when Apple, Microsoft, Netflix, Facebook, Cisco, Akamai, Vanguard, ..., don't? That's why I'm imagining a system based on object metrics of company size, if you have >X employees, this license costs you $Y/month plain and simple; 30 days to make good with the sales team or else you meet the legal team.

And as an individual, there's no reason to expect a "noncommercial or paid" license to be successful, since there's many options for each thing that exists. If I said "you have to pay $ to use node-tap", ok, just use Jest instead. Without collective action, the "stick" is just a deterrent rather than a source of leverage.

Anyway, just some thoughts on the subject kicking around. For now, it's all status quo, so I'll keep making OSS like I like to do and y'all can use it or not, software provided "as is", no warrantees expressed or implied including merchantability or fitness for a specific purpose etc etc.