Live data from Hacker News

To secure the supply chain, you must properly fund it

ariadne.space

21–30 of 59 posts

Re: To secure the supply chain, you must properly fund it

#21

> When corporations sponsor the maintenance of the FOSS projects they use, they are effectively buying an insurance policy that guarantees a prompt, well-coordinated response to security problems. Unless there's a contract explicitly stating so, this is not true whatsoever. If you want an "insurance policy" of this kind, hire the maintainer or pay for an actual support contract from them. Donations are exactly that,…

They are under moral obligation in the sense that they need to make the donators happy to keep getting donations.

They may choose to oblige but they are under no obligation, moral or not.

You can’t sue a maintainer for not fixing a security issue if it’s not part of a contract, and the license is explicit about being As Is No Warranty.

If you don’t like it, fix it yourself in a fork.

Re: To secure the supply chain, you must properly fund it

#22

> When corporations sponsor the maintenance of the FOSS projects they use, they are effectively buying an insurance policy that guarantees a prompt, well-coordinated response to security problems. Unless there's a contract explicitly stating so, this is not true whatsoever. If you want an "insurance policy" of this kind, hire the maintainer or pay for an actual support contract from them. Donations are exactly that,…

While contracts matter,relationships are also a thing - if you are donating and they are developing, you are funding development.

As a volunteer maintainer, if you want to donate money to one of my projects it’s because you find enough value in my work then you are free to do so to help continue development. If you want to donate money in order to exert some kind of control over how I spend my time, please keep your money.

Re: To secure the supply chain, you must properly fund it

#24
post #17

>[...] Incidentally, one of the Log4j maintainers’ GitHub sponsors profile is here, if you would like to contribute some money to his cause. [...] these companies should ponder which is more expensive: $100k/year salary for a maintainer of a project they are heavily dependent upon, I don't understand the logic of cause & effect the author laid out. Commercial software with well-paid programmer employees also have lon…

> Commercial software with well-paid programmer employees also have long lists of CVE/RCE including MS Windows, Azure, AWS, Adobe PDF reader, Oracle database, etc.

Exactly that.

What paying some dev for open source work does is give you more ways to influence the direction of the projects.

It can help you to put priority on fixing bugs which affect you.

But it can't magically make disclosure work better.

Also I would be surprised if some bad actors haven't already known this vulnerability for a while, and hence any more delay before disclosure would have been irresponsible. In general a full disclosure shortly after finding and fixing it is often the most responsible thing to do.

Re: To secure the supply chain, you must properly fund it

#26
post #8

It should be noted up front that paying money for this stuff doesn't secure it either. There are frequent security bugs from well maintained projects too. It does help though. The best defence against this sort of catastrophic bug creeping up into a project is an aggressively simplified dependency tree. It isn't easy, and in some (most?) cases it might be most sensible to take on the risk and wait to fix bugs found i…

> simplified dependency tree.

Which doesn't necessary help.

Like eight "simple/small" dependencies from the same author might be a better choice then two huge dependencies from two different authors.

What matters is not the number of dependencies but the amount of code/complexity you depend one and the number of sources/authors/author-groups.

Also in this case you probably would have keep this dependency in you simplified dependency tree...

Re: To secure the supply chain, you must properly fund it

#27
This presents sponsorship of OSS in strictly economic terms as a trade-of. That’s unlikely to be a successful argument for more sponsorship, because it puts it squarely in tragedy-of-the-commons territory: unless you’re the largest consumer of some upstream project, it’s better to hope for others to support it.

It’s also descriptively wrong when it frames sponsorship decisions in such supposedly-rational economic terms: while corporations are in theory seeking only shareholder value, corporations happen to be (made up of) people, who are capable of altruism, and should be encouraged to do so. Just because US capitalism has managed to build a not-entirely-failing system on unadulterated selfishness does not turn that mindset into a virtue, or anything close to the far more complex set of motivations driving individual action.

Practically speaking, many corporations sponsor OSS, and the whole reasoning behind it is often that some person with a bit of authority likes the idea. They may consider it good for marketing, or recruitment, or to secure their supply chain, or just morally called for, or they want to be the fat cat at this years TINYTEC-CON. If you asked them, they’ll give you a reason that totally makes sense for a business and has little to do with reality. And, no, nobody ever got sued or fired for these decisions. So go ahead, do it! You got all the left-padding you needed, it’s right to pad their wallet in return.

Re: To secure the supply chain, you must properly fund it

#29
There is no reason to believe that money would actually solve the issue, and maybe even exacerbate it.

The log4j issue is product debt, similar to the sqlite fts tokenizer exploit, and a lot of the openssl exploits, features that are rarely used, and are in the codebase for "no good reason" (from the majority of user's standpoint)

I think the way to make for those things to happen less, is in fact, to code less, and make more small things rather than one giant bloat of features. Paid or not paid, security becomes near impossible after certain amounts of interconnected components.

Post reply on HN