Comment by 2muchcoffeeman
2 months ago
Have we all forgotten the left-pad incident?
This is an eco system that has taken code reuse to the (unreasonable) extreme.
When JS was becoming popular, I’m pretty sure every dev cocked an eyebrow at the dependency system and wondered how it’d be attacked.
> This is an eco system that has taken code reuse to the (unreasonable) extreme.
Not even that actually. Actually the wheel is reinvented over and over again in this exact ecosystem. Many packages are low quality, and not even suitable to be reused much.
The perfect storm of on the one side junior developers who are afraid of writing even trivial code and are glad if there's a package implementing functionality that can be done in a one-liner, and on the other side (often junior) developers who want to prove themselves and think the best way to do that is to publish a successful npm package
The blessing and curse of frontend development is that there basically isn't a barrier to entry given that you can make some basic CSS/JS/HTML and have your browser render it immediately.
There's also the flavor of frontend developer that came from the backend and sneers at actually having to learn frontend because "it's not real development"
30 replies →
People pushing random throwaway packages is not the issue.
A lot of the culture is built by certain people who make a living out of package maximalism.
More packages == more eyballs == more donations.
They have an agenda that small packages are good and made PRs into popular packages to inject their junk into the supply chain.
Not on HN, the land of "you should use a SaaS or PaaS for that (because I might eventually work there and make money)" or "I don't want to maintain that code because it's not strictly related to my CRUD app business! how you dare!"
1.2 million weekly downloads to this day, when we've had builtin padStart since ES2017.
Yes, I remember thinking at the time "how are people not ashamed to install this?"
I found it funny back when people were abandoning Java for JavaScript thinking that was better somehow...(especially in terms of security)
NPM is good for building your own stack but it's a bad idea (usually) to download the Internet. No dep system is 100% safe (including AI, generating new security vulns yay).
I'd like to think that we'll all stop grabbing code we don't understand and thrusting it into places we don't belong, or at least, do it more slowly, however, I also don't have much faith in the average (especially frontend web) dev. They are often the same idiots doing XYZ in the street.
I predict more hilarious (scary even) kerfuffles, probably even major militaries losing control of things ala Terminator style.
It’s not clear to me what this has to do with Java vs JavaScript (unless you’re referring to the lack of a JS standard library which I think will pretty much minimize this issue).
In fact, when we did have Java in the browser it was loaded with security issues primarily because of the much greater complexity of the Java language.
Java has maven, and is far from immune from similar types of attacks. However, it doesn't have the technological monstrosity named NPM. In fact that aforementioned complexity is/was an asset in raising the bar, however slightly, in producing java packages. Crucially, that ecosystem is nowhere near as absurdly complex (note, I'm ignoring the I'll fated cousin that is Gradle, and is also notorious for being a steaming pile of barely-working inscrutable dependencies)
Anyways, I think you are missing the forest for the trees if you think this is a Java vs JavaScript comparison, don't worry it's also possible to produce junk enterprise code too...
Just amusing watching people be irrationally scared of one language/ecosystem vs another without stopping to think why or where the problems are coming from.
It's not the language it's the library that's not designed to isolate untrusted code from the start. Much harder to exit the sandbox if your only I/O mechanism is the DOM, alert() and prompt().
2 replies →
In that era JavaScript was also loaded with security issues. That's why browsers had to invest so much in kernel sandboxing. Securing JavaScript VMs written by hand in C++ is a dead end, although ironically given this post, it's easier when they're written in Java [1]
But the reason Java is more secure than JavaScript in the context of supply chain attacks is fourfold:
1. Maven packages don't have install scripts. "Installing" a package from a Maven repository just means downloading it to a local cache, and that's it.
2. Java code is loaded lazily on demand, class at a time. Even adding classes to a JAR doesn't guarantee they'll run.
3. Java uses fewer, larger, more curated libraries in which upgrades are a more manual affair involving reading the release notes and the like. This does have its downsides: apps can ship with old libraries that have unfixed bugs. Corporate users tend to have scanners looking for such problems. But it also has an upside, in that pushing bad code doesn't immediately affect anything and there's plenty of time for the author to notice.
4. Corporate Java users often run internal mirrors of Maven rather than having every developer fetch from upstream.
The gap isn't huge: Java frameworks sometimes come with build system plugins that could inject malware as they compile the code, and of course if you can modify a JAR you can always inject code into a class that's very likely to be used on any reasonable codepath.
But for all the ragging people like to do on Java security, it was ahead of its time. A reasonable fix for these kind of supply chain attacks looks a lot like the SecurityManager! The SecurityManager didn't get enough adoption to justify its maintenance costs and was removed, partly because of those factors above that mean supply chain attacks haven't had a significant impact on the JVM ecosystem yet, and partly due to its complexity.
It's not clear yet what securing the supply chain in the Java world will look like. In-process sandboxing might come back or it might be better to adopt a Chrome-style microservice architecture; GraalVM has got a coarser-grained form of sandboxing that supports both in-process and out-of-process isolation already. I wrote about the tradeoffs involved in different approaches here:
https://blog.plan99.net/why-not-capability-languages-a8e6cbd...
[1] https://medium.com/graalvm/writing-truly-memory-safe-jit-com...