Live data from Hacker News

To secure the supply chain, you must properly fund it

ariadne.space

51–59 of 59 posts

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

#51

Earlier quoted context omitted.

> 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 simpl…

Yes, but most dependencies are generally from different authors so the chance of malicious actors goes up with dependencies.

Kinda, but also depends on the language a lot.

E.g. in rust it's not uncommon to sometimes split libraries, e.g. -derive libraries (proc macros/derives), -sys (C-bindings without any logic/abstraction, most times auto-generated), and internal components. So counting just the number of "dependencies" can easily get you results, which are way off. Like actix-web has over 10 internal dependencies. (through I should note that they are in the same physical package/uploaded archive, i.e. they are treated as separate packages by rust, but are a single upload, have a single version number etc.).

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

#52

Earlier quoted context omitted.

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.

That's why I wrote "funding", not "controlling"

Many people believe these things are nearly inexorably linked.

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

#53
post #39

NFTs are an ideal way for corporations to fund open source projects. When used as a fundraising tool by non-profit projects, they are a portable proof of contribution that confers status to the contributor, and thus incentivizes contributions. Recently, they were used to raise millions for Ross Ulbricht's campaign for a sentence reduction.

Why is a portable proof of contribution more valuable for a corporate donor than just having the corporate logo in the sponsors area of the website? If anyone bothers to verify that someone isn't lying about their donation they can go check.

It makes it more versatile. For instance, if they wanted to transfer it to another company, say one they were being bought by or merged into, they could.

NFTization specifically, as opposed to portability, also makes it more interoperable. For example a corporation could show off its contributor NFTs on OpenSea, just by signing in with the account that holds the NFTs using MetaMask, and adding their corporate name to profile that OpenSea keeps for that account.

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

#54
post #39

Earlier quoted context omitted.

Why is a portable proof of contribution more valuable for a corporate donor than just having the corporate logo in the sponsors area of the website? If anyone bothers to verify that someone isn't lying about their donation they can go check.

It makes it more versatile. For instance, if they wanted to transfer it to another company, say one they were being bought by or merged into, they could. NFTization specifically, as opposed to portability, also makes it more interoperable. For example a corporation could show off its contributor NFTs on OpenSea, just by signing in with the account that holds the NFTs using MetaMask, and adding their corporate name to…

How's this better than just sending an email to the maintainer?

Plus, you could sell the nft, at no benefit to the open source project

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

#55
post #54

Earlier quoted context omitted.

It makes it more versatile. For instance, if they wanted to transfer it to another company, say one they were being bought by or merged into, they could. NFTization specifically, as opposed to portability, also makes it more interoperable. For example a corporation could show off its contributor NFTs on OpenSea, just by signing in with the account that holds the NFTs using MetaMask, and adding their corporate name to…

How's this better than just sending an email to the maintainer? Plus, you could sell the nft, at no benefit to the open source project

Well it doesn't require the maintainer's cooperation/response to effect the change.

>>Plus, you could sell the nft, at no benefit to the open source project

A secondary market that generates demand for such assets, allows more money to be raised in the primary market where these assets are initially sold.

Also, not sure if you saw my edit to the previous comment that added the last paragraph. The paragraph adds some elaboration.

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

#57
post #43

Earlier quoted context omitted.

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

Keeping donors happy to get more donations isn't related to morality. It is completely acceptable morally speaking to accept donations and then later decide to stop working on a project. Whether people will keep donating is entirely a pragmatic question

If you, as a hypothetical FOSS leader, end up losing a major donor, you've failed as a leader.

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

#58

Earlier quoted context omitted.

> 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 simpl…

Yes, but most dependencies are generally from different authors so the chance of malicious actors goes up with dependencies.

Just look here: https://github.com/dtolnay?tab=repositories

David Tolnay have 89 repos and if you are doing any Rust work at all the chances are high that you would have dozen of them in your dependency chain.

Would merging of them help security? I don't think so: most of these crates are useful but they are quite diverse and it doesn't make much sense to put them into one package.

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

#59

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…

I agree with you, but at the same time I am also a little worry that this log4j2 exploit may inadvertently push us to the other extreme. Now every time I want some essential features to be added to a library, the log4j2 exploit will be brought up as a knee-jerk reaction.

At least we already got https://github.com/mattermost/logr, otherwise there could be years before we get to have a golang logging library with async logger.

Post reply on HN