Isn't the complete lack of accountability the death of open source, Like why would any enterprise sign up for this? "Sure lets go open source, it doesn't save money, and we increase our attack surface by adding a bunch of dependencies we have no control over while the creators tell us they don't owe us security".
Like I don't think open source has thought this message through, they are just desperate not to get sued.
Imagine, you choose to develop an in-house alternative to some open-source library. Say, you have a developer that implements it, and another developer that reviews the code, because of course you have code reviews. Why not just make that second developer audit the open-source library instead? That way, you do save money on that first developer.
Well I don't disagree in general but at the same time against your point I do think people often include big dependencies (and their entire dependency trees) but end up needing/using only a tiny fraction of the functionality provided. Sometimes this is to the point that keeping up with changes and putting in work to mitigate supply chain risks is a bigger effort long term than rolling your own implementation for a specific non generic use case (or even copy&pasting a specific slice of an existing library).
But I'm not entirely sure what OPs point was in not using open source. Ordering everything from some vendor/consultant armies? Who in turn use open source which means you just attempted to hide the problem which still exists.
Fair point about building a smaller, more focused alternative. That's why modularity is so important. Ideally, we should have small libraries that compose into flexible dependency trees that fit your use case. Rust does that very well, actually. For example, it has great support for optional dependencies, and an ecosystem that actually utilizes it. But then non-Rust people complain about pulling in 500 crates or whatever, even though that's actually less lines of code than in other ecosystems.
Some people tried to solve this. There’s an open issue for build.rs sandboxing, and there were some experiments about compiling procedural macros to WebAssembly.
But this is hardly workable. While cargo build can become safe, you usually run cargo test or cargo run immediately afterwards, which is impossible to sandbox. Making Rust development secure involves more than build time and requires powerful system-level isolation that cargo alone cannot be responsible for.
Yes, this is the one that annoys me the most. You can't sandbox a dependency in any meaningful way. If you sandbox the build dependency you still need to run the code at some point. You could have sandboxed dev environments, and probably should, that would limit the damage however.
But webassembly build dependencies is just a smokescreen.
Ultimately all you can do is whitelist specific versions after auditing them (or trusting someone else's audit), and even that's not perfect. Everything else is just superstition (at worst) and damage limitation (at best).
One thing that isn't mentioned, but I suspect will be more popular as time goes on. Projects will just use fewer dependencies, a small number of trusted community-audited projects maybe. Smaller dependencies will be removed entirely replaced with functionally identical custom implementations generated by the technology that shall not be named, known by a two-letter acronym comprising of the first and eighth letter of the alphabet.
I tend to agree. One thing I have found myself being annoyed by though is how package signing isn't a big thing in programming language package managers. Getting alerted to a changed package signer would be such an easy signal to inspect whats up.
But I guess people prefer to use commonly compromised CI jobs to publish their software so such manual steps have no room in the ecosystem and it's hard to automate.
verified publishing is getting some traction. if you haven't tried it yet, worth looking into. npm v11 has the npm trust command and then you can publish via ci easily
From what I read it seems like it mostly validates the CI provider, pipeline file name, environment and repository name? Which sure is something.
I'd personally argue that such a publishing token should be instantly revoked by at least the following actions (but I doubt npm could monitor these easily):
changes to the build image
changes to the workflow contents
changes to repository CI settings
changes to users with permission to publish using the job
probably a thing or two I'm forgetting
even that would fall short of something like having to use a hardware key to sign a release, but could be enough assuming the workflow itself had git commit signature verification written into it.
it validates that the built artifacts exactly match what is on github essentially. those other things would likely be worth while things that could be flagged and surfaced for anyone wanting to assess any particular dependency update
matthra@reddit
Isn't the complete lack of accountability the death of open source, Like why would any enterprise sign up for this? "Sure lets go open source, it doesn't save money, and we increase our attack surface by adding a bunch of dependencies we have no control over while the creators tell us they don't owe us security".
Like I don't think open source has thought this message through, they are just desperate not to get sued.
Dragdu@reddit
Oh no, not enterprise not using my code.
cdb_11@reddit
Unless they are contributing back to the project, why should I care what enterprises do?
Expurple@reddit (OP)
How so?
Imagine, you choose to develop an in-house alternative to some open-source library. Say, you have a developer that implements it, and another developer that reviews the code, because of course you have code reviews. Why not just make that second developer audit the open-source library instead? That way, you do save money on that first developer.
SoilMassive6850@reddit
Well I don't disagree in general but at the same time against your point I do think people often include big dependencies (and their entire dependency trees) but end up needing/using only a tiny fraction of the functionality provided. Sometimes this is to the point that keeping up with changes and putting in work to mitigate supply chain risks is a bigger effort long term than rolling your own implementation for a specific non generic use case (or even copy&pasting a specific slice of an existing library).
But I'm not entirely sure what OPs point was in not using open source. Ordering everything from some vendor/consultant armies? Who in turn use open source which means you just attempted to hide the problem which still exists.
Expurple@reddit (OP)
Fair point about building a smaller, more focused alternative. That's why modularity is so important. Ideally, we should have small libraries that compose into flexible dependency trees that fit your use case. Rust does that very well, actually. For example, it has great support for optional dependencies, and an ecosystem that actually utilizes it. But then non-Rust people complain about pulling in 500 crates or whatever, even though that's actually less lines of code than in other ecosystems.
hu6Bi5To@reddit
Yes, this is the one that annoys me the most. You can't sandbox a dependency in any meaningful way. If you sandbox the build dependency you still need to run the code at some point. You could have sandboxed dev environments, and probably should, that would limit the damage however.
But webassembly build dependencies is just a smokescreen.
Ultimately all you can do is whitelist specific versions after auditing them (or trusting someone else's audit), and even that's not perfect. Everything else is just superstition (at worst) and damage limitation (at best).
One thing that isn't mentioned, but I suspect will be more popular as time goes on. Projects will just use fewer dependencies, a small number of trusted community-audited projects maybe. Smaller dependencies will be removed entirely replaced with functionally identical custom implementations generated by the technology that shall not be named, known by a two-letter acronym comprising of the first and eighth letter of the alphabet.
SoilMassive6850@reddit
I tend to agree. One thing I have found myself being annoyed by though is how package signing isn't a big thing in programming language package managers. Getting alerted to a changed package signer would be such an easy signal to inspect whats up.
But I guess people prefer to use commonly compromised CI jobs to publish their software so such manual steps have no room in the ecosystem and it's hard to automate.
bzbub2@reddit
verified publishing is getting some traction. if you haven't tried it yet, worth looking into. npm v11 has the npm trust command and then you can publish via ci easily
SoilMassive6850@reddit
From what I read it seems like it mostly validates the CI provider, pipeline file name, environment and repository name? Which sure is something.
I'd personally argue that such a publishing token should be instantly revoked by at least the following actions (but I doubt npm could monitor these easily):
even that would fall short of something like having to use a hardware key to sign a release, but could be enough assuming the workflow itself had git commit signature verification written into it.
bzbub2@reddit
it validates that the built artifacts exactly match what is on github essentially. those other things would likely be worth while things that could be flagged and surfaced for anyone wanting to assess any particular dependency update
chucker23n@reddit
That’s true, but it’s also just a restatement of the problem.