201–210 of 230 posts
Earlier quoted context omitted.
To be honest Rust has the exact same supply chain attack pattern - it's just newer and more maintained at the moment. Give it a decade.
Programs in Rust (or almost every other language) normally have fewer dependencies by 2 or 3 orders of magnitude. And that number tends to reduce even more when the ecosystem matures.
Earlier quoted context omitted.
Programs in Rust (or almost every other language) normally have fewer dependencies by 2 or 3 orders of magnitude. And that number tends to reduce even more when the ecosystem matures.
It may be fewer but it still doesn't feel good when cargo pulls in hundreds of deps for a seemingly simple application. But maybe it seems simple because of all the deps...
Earlier quoted context omitted.
It is 100% up to the package manager's steward to control how ownership of packages and namespaces are granted. Maven Central exists for decades the amount of incidents of people stealing namespaces is minimal. One can't simply publish a package under the groupId "com.ycombinator" without having some way to verify that they own the domain ycombinator.com. Then, once a package is published, it is 100% immutable, even…
Also.... Maven doesn't have "preinstall, install, post install", or " build.rs" for rust, executing arbitrary code during the installation. The code that's executing with Maven is in your pom.xml, not some hidden code from a transient dependency. That alone is a major design flaw in both npm and cargo. Java is boring, because it works. People don't like boring stuff. It's more exciting to play the Russian roulette on…
Earlier quoted context omitted.
That is another important layer. Maven Central is not immune to credential theft. If a publisher token is stolen, an attacker may still be able to publish a malicious new version until the token is revoked or the account is suspended after reporting the problem to Sonatype. But in the Maven/Gradle ecosystem, most projects pin exact dependency versions. Support for version ranges and dynamic versions exist, but they a…
Dependency versions are also locked for npm projects via package-lock.json, and this has been the default behaviour for years. The version ranges specified in package.json don't mean you just pick up the latest whenever you run npm install. Unless you delete package-lock.json or run "npm update", you and everyone else gets the exact same dependency tree each time. So it is just as reproducible as a Maven build in tha…
This link is clearly an AI laundered version of the long running joke from Xe Iaso. Shame. https://xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2024... https://news.ycombinator.com/item?id=40438408
Earlier quoted context omitted.
They feel the need to compete given that jokes about "backend" devs write themselves
Frontend has lower barrier of entry and more appeal for beginners, so its bell curve might have its left edge is thicker. It impacts the avg of problems and culture of dealing with them
Earlier quoted context omitted.
Trivial relative to which perspective? The distinction matters enough to care. Just because your father might give away their phone pin over the phone doesn't mean we should allow this granting remote access to his phone.
Trivial in the sense that in 99.9% of situations, "npm install" is immediately followed by "npm run", "npm test", or some form of execution. Any execution that imports a dependency is enough for a transitive dependency to execute its malicious payload immediately. Post-install scripts have a slight edge over executing malicious code on import, i.e. they work 99.95% of the time instead of 99.9% of the time, but removi…
The "instead of" depends very much on the exploit and where it's wedged in the code. I doubt it's anywhere near 99%. Plus, getting the exploit to execute on the developer's machine is difficult to manage even in the best cases.
> because everyone who thought that disabling post-install scripts was a "good enough" standalone security strategy will get caught with their pants down as attackers modify their payloads.
Saying "well there are stupid people in the world" seems like a pretty bad justification to leave a hole open.
Earlier quoted context omitted.
More akin to letting astronauts stay in quarantine for a day in case they caught space bugs. If every other week I would notice the FDA recalls a popular brand that would have taken over my brain and transmit my bank password and SSN to a stranger, I might prefer drinking week old milk. Edit: not dismissing your analogy, it’s pretty much it.
If nobody drinks the milk until it’s a week old, that won’t help. I do think cooldowns help, it’s more that this analogy doesn’t help. The cow has to wake up and look at what milk she’s been putting out, and ideally the milk machine would use an early release channel so that some people will get the brain virus first.
The early release channel is sensible, but if you're a bad actor who's compromised a package you're not going to early release are you, you get it straight out there.
Earlier quoted context omitted.
Programs in Rust (or almost every other language) normally have fewer dependencies by 2 or 3 orders of magnitude. And that number tends to reduce even more when the ecosystem matures.
It may be fewer but it still doesn't feel good when cargo pulls in hundreds of deps for a seemingly simple application. But maybe it seems simple because of all the deps...
But also, almost all of those deps on all simple apps are the same in Rust. They are the same for a large part in JS too, but it's for a smaller part than on most languages.