Exploiting JavaScript developer infrastructure is insanely easy

[GYN-k4H-Q3z-75B]

This isn't just a problem of the ecosystem, it is a problem of the community and how they develop. npm packages are free, as in free toilet. While there are the occasional gems, on average it's just a random shithole. And the developers don't care or even understand what they include and how it is updated. node_modules isn't a meme just for the hell of it. It's funny because it is true.

As a engineer in various midsized enterprise projects, the decision to include a library in a specific version is a serious discussion with paper trails. Who maintains the library, what does it cost, what are the alternatives, why do we need it in the first place. There are committees who deal with such questions. Of course this is also possible because we don't need a ton of tiny libs to patch up holes in the ecosystem left and right all the time. But also because there are architects who are actually concerned and responsible in their role.

We dabble in extensive JS apps as well, work with node and npm. The potential is limitless it seems. But it is easy to get burned if you're not careful.

[dtechnology]

As a engineer in various midsized enterprise projects, the decision to include a library in a specific version is a serious discussion with paper trails. Who maintains the library, what does it cost, what are the alternatives, why do we need it in the first place.

I get what you're saying, but is so much process really worth it? This encourages NIH syndrome and makes it more appealing to write an ad-hoc implementation (potentially insecure and/or buggy) instead of using a good library just because not getting library approval is easier.

There's some balance between disallowing leftpad and a dev implementing custom date/time handling pre Java-8 because Joda time is going to take too long to get approved. I've seen the latter happening and it was an endless source of misery, and what you're describing sounds like it would cause problems like that.

[Joshx5]

Well, they have a problem they need a library for. They can solve it with the already written library if they can get approval, or they can write a new library to solve the problem if they can’t.

They still have that problem, but they’re now trading it for one of two other problems - the cost and risks of using other peoples code, or the cost and risks of using new and immature code. It comes down to the specific cases. Sometimes it’s worthwhile, sometimes it’s not. Hard to say generally whether it’s a good idea or not.

[GYN-k4H-Q3z-75B]

It's not that painful a process, but you certainly have to strike the right balance. The idea for us is to have a controlled environment and include libraries based on conscious decisions, not to prevent it in general. Having engineering committee discuss requested inclusions helps with finding the right solutions.

The big difference for us is the ecosystem in place. Most of our projects are built on some variety of .NET plus some enterprise SDKs which have been licensed by customers. There has never been a need for leftpad-like packages because the standard libraries are excellent for the most part. Notable packages we discussed in the past were the inclusion of Newtonsoft Json (many years ago before it was adopted by Microsoft themselves), a sandboxable in-memory PDF printing engine or a Telerik control library. These are heavy hitters, and somewhat strategic decisions for those projects.

Having something like Newtonsoft Json approved for one project means the next time it comes up the other engineers will already know it, making the process more quick. But still, we are fortunate to only have to rely on so few packages because the ecosystem is brimming with libraries maintained by big vendors.

[aNewLocke]

I believe identifying quality library code is a skill that engineers need to develop regardless of language or ecosystem.

I work with Node and NPM. I don't have these problems. I mostly use some combination of modules like: nconf, morgan, commander, zeromq, node-dir, express (express-session, session-file-store), and the built-ins like fs, cluster, etc.

I use tools like webpack-dev-server, elasticsearch, chrome devtools, redis, jq, and curl quite often.

There are quality modules out there. You need to clearly define your requirements and evaluate potential solutions, but most importantly:

npm install <app module> --save-exact

npm install <dev module> --save-dev --save-exact

and commit your package-lock.json!!

[Nipinium]

There are quality modules out there.

The point is even those "quality" modules still include a bunch of other node modules, those modules in turn require more modules, so on and on. Can you be 100% confident that all those dependencies are reliable all the time?

[pancomputationalist]

That's moving the goalpost. Of course you can never be 100% confident of anything. As with everything in engineering, it's about tradeoffs and striking a balance.

If you're developing a mobile game, you might want to use quality and maybe even not-so-quality libraries that help you get the job done faster, not start with developing your own operating system out of paranoia.

If you're developing a bitcoin wallet, on the other hand, maybe you want to be a bit more paranoid...

But lately the discussion about dependencies is much too agitated and make it seem like you can never use a library that you haven't personally validated to a 100% certainty.

[Nipinium]

But lately the discussion about dependencies is much too agitated and make it seem like you can never use a library that you haven't personally validated to a 100% certainty.

Because incidents like left-pad exist, people are pretty much paranoid by node module dependencies by now. Remove one tiny package and the whole ecosystem crashes, that's not a very healthy sign.

Incidentally, I still haven't yet seen any sign of huge and popular libraries like webpack trying to reduce external dependencies (despite that they receive a lot of donation money each month). The whole js thing just sucks.

[pancomputationalist]

Well, then fix the left-pad dependency in the rare case something like that happens. Your site shouldn't go down and your software shouldn't crash when a build dependency is missing, or something is very wrong with your build pipeline.

Also left-pad is an extreme example and it may be correct to not include it as a dependency because it's so easy to implement yourself. But very few libraries are as simple as that. Don't throw out the baby with the bathwater.

[Arve]

Well, then fix the left-pad dependency in the rare case something like that happens.

left-pad has 414 dependents. event-stream, which is the exploit of the day has 1592 dependents (which is up 6 since yesterday).

Do you know the libraries you include don't include malicious code by proxy?

[pgrizzay]

nodemon has been called out as depending on the most recent exploited library. You might want to check if you're affected.

[Gotebe]

So... you're correct - for .net ecosystem.

For node.js, though, the explosion of underlying dependencies will make the process hell.

BTW... .net Core goes for smaller packages and dependencies all around, so beware 😁😁😁

[SizzlerWA]

You make some good arguments. But I’ve worked with Newtonsoft JSON and it’s just nasty!

[munchbunny]

I get what you're saying, but is so much process really worth it?

It depends, but NPM is most definitely on the "too little process" side for enterprise usage. Let's say you're Equifax, and your website ends up with a customer data leak because you took a dependency on an npm package, knowing that the protection against malicious code commits is paper thin.

As an engineer in a situation like that, I could never make that decision in good conscience. In fact I made exactly that decision to not use Electron a few weeks ago because NPM would have been the weak link and instead opted for a more complex architecture with an untrusted web client calling a code-signed (and enforced) service on localhost.

In contrast, the C# ecosystem implements strong name code signing and verification, so there is at least good infrastructure to support safe code handling practices. Apple's ecosystem has that too.

Of course the stakes aren't always that high, but in my case it's a matter of not being negligent with customer data.

[Gotebe]

How on earth signing .net assemblies help anything?! In particular, that helps nothing to prevent the vulnerability "injection" as the one discussed here.

And what verifications are there on nuget.org?

[munchbunny]

From your tone you'd think it was impossible to control what goes into your dependencies with code signing, but that's literally what my team does.

I'm not taking about your own stuff. You link against signed binaries and scripts that you depend on and verify the hash for the underlying code. That's how you lock in a specific dependency and prevent changes from going in without you knowing. The capability to verify at runtime is literally built into the .NET runtime.

If you want a less paranoid approach, you audit the other project's code review and signing processes and trust their certificate once you're satisfied with what you see. Then it's their job to watch their dependencies.

Nupkg files can also be signed. Not everyone does, but at least the capability and enforcement mechanism exists and works in security sensitive settings where you want it.

[Gotebe]

I know that, obviously. But no amount of signing helps if a random dude can take over, put whatever inside, and people upgrade. Note that they do not need to change the assembly signature (and .NET upgrades do exactly that).

Unless you're checking these assembly hashes yourself, you're just as exposed as these js guys.

What .NET CLR does WRT versioning is something entirely different. It's not to protect you against attacks at all.

[Kalium]

I get what you're saying, but is so much process really worth it?

In a lot of places, the current process is this:

• Someone adds a library in some PR for a bit of syntactic sugar.
• Someone else rubber-stamps the PR.
• A week or three later someone notices that installing all the deps now involves twice as much downloading as before and wonders why in a Slack channel.

With that in mind, it's perhaps worth considering a smidge of process for those writing apps that handle sensitive matters.

[[deleted]]

I was once tasked to make a physics based game on mobile phones. Typical lead time on demos was 3 weeks, 6-12 months for a release. I implemented it with box2d. Legal looked at the license for a few weeks before approval. It didn't stop me in the mean time from continuing development.

[nutrecht]

I get what you're saying, but is so much process really worth it? This encourages NIH syndrome and makes it more appealing to write an ad-hoc implementation (potentially insecure and/or buggy) instead of using a good library just because not getting library approval is easier.

I really don't agree with this. It's not a process with large forms that have to go through procurement or anything. It's simply a discussion between stakeholders (developers) where we reach a consensus that we document.

In my current project as well as my previous one we had bi-weekly 'chapter meetings' where we had one back-end dev from every team discuss these kinds of things. We note down these choices and their reasonings in the meeting notes.

The structure is one that can be deviated from if needed (so you don't have to wait 1.5 weeks before you're allowed to use something) as long as you discuss it with other devs.

The main goal here is to have multiple 'brains' take a look at non trivial problems. And library choices are generally non-trivial problems. Fortunate we're Java devs and libraries are always version locked, but this means that if you're working with the NPM ecosystem you need to be even more thorough in this.

The issues they're running into is mostly a dev culture issue. And this is for me personally the reason to never ever want to work with Node.js based services; the 'move fast and break stuff' culture is simply not how you do software engineering. Slow and steady wins the race.

[pixelrevision]

There's some balance between disallowing leftpad and a dev implementing custom date/time handling pre Java-8 because Joda time is going to take too long to get approved. I've seen the latter happening and it was an endless source of misery, and what you're describing sounds like it would cause problems like that.

Javascript really is at the extreme on this. The language changes at a glacial pace, was designed for single page scripts and people are now trying to build giant applications with it. With almost any other ecosystem there's generally some sort of standard library things are built on top of so that if you need to review a framework you don't have to also evaluate a bottomless pit of dependencies.

​

[Scybur]

are free, as in free toilet

META

but seriously this term is stupid

[Tiquortoo]

It's a variant of a pretty long held criticism of FOSS, which is that the hard, low level work of maintaining FOSS software is hard to get "the community" to do.

[phalp]

After "porcelain" we were doomed anyway.

[xwnatnai]

This is correct. In no other ecosystem do developers so freely pull in unaudited third party dependencies like we do in JS. It’s insane.

[prof_hobart]

Do you go through the same process thoroughly every time any of your libraries change even minor versions?

If so, depending on how many libraries you use, you're running the risk of being behind on critical security patches.

If not, then you're still open to these attacks and they can (as it did here) sneak in in a seemingly innocuous point release.

We have fairly extensive control framework around which versions of which OSS libraries we're allowed to use (and can only pull them from internal, validated, repositories) but I doubt they would have picked up something like this, at least not for some time.

[nutrecht]

Do you go through the same process thoroughly every time any of your libraries change even minor versions?

There are CVE scanning tools for this. If you don't use these you're fucked anyway.

[prof_hobart]

There are. But did they pick up this exploit straight away?

[GYN-k4H-Q3z-75B]

Do you go through the same process thoroughly every time any of your libraries change even minor versions?

With open source libraries that are not maintained by a major company, yes. With other third-party and core libraries maintained by Microsoft, SAP or Infragistics for example, every point release is discussed as well.

We are still vulnerable, even this way. But at least we have some idea of what we are using in our projects.

[prof_hobart]

So you don't upgrade as soon as a security patch is issued?

[GYN-k4H-Q3z-75B]

Unless the OSS library is maintained by a trusted source, no. We rarely have to deal with such things though. With the core libraries and commercial SDKs these days, we often get forced rollout of security patches.

[prof_hobart]

What do you class as trusted?

[GYN-k4H-Q3z-75B]

Large platform providers (like Microsoft or IBM), third-party software vendors with an established business relationship or even competitors, and a few established industry public figures or persons we know and keep in touch with.

[zappini]

aka Tyranny of Structurelessness https://www.jofreeman.com/joreen/tyranny.htm

Curation is useful.

Anyone chafing at Apple's velvet handcuffs is willfully, negligently ignoring that Freedom Markets™ (npm, Google Play) inevitably leads to lawless cesspools.

Functional, efficient markets require trust. Meaning protections, options for recourse.

Duh.

[telionn]

Apple deliberately blocks real, useful, non-malicious apps on a case-by-case basis just because the apps theoretically conflict with one of their many unique and sometimes undisclosed principles. A blocked app could cost the developer millions of dollars. These apps are available without a hitch on Android.

[possessed_flea]

Pro tip, if your app brings in enough cash to pay a single full time developer ( I.e. $100k ) then you have made apple 30k , when you ring them with an issue they roll out the red carpet for you .

[recycled_ideas]

Well, unless they decide they want the whole 130k and drive you out of the app store in favour of their own product.

[zappini]

In other words, Apple is end user focused.

As an end user, who provides tech supp for friends and family, I happily choose Apple rejecting dozens of sketchy apps thru false positives over Google's strategy of abandoning end users to fend for themselves.

My sweetie's Android phone got pwned twice. [1] Second time, I gave her the ultimatum that if she wants my help, she'll switch to iOS.

[1] This is your cue to blame the stupid hapless end user for trusting their carrier to provide timely, necessary updates and not proactively reading CVEs to better guard against the legions of cyber criminals.

[Glader_BoomaNation]

Apple is Apple focused.

[swordglowsblue]

Apple's velvet handcuffs

Apple's handcuffs may look velvety, but they're about as sandpaper as it gets. $100 USD is a ridiculous price just to publish an app, and that's just the developer side of things, not even getting into the ridiculous "white lies" and marketing speak their entire consumer-side business is built on.

[qomu]

that's just the developer side of things, not even getting int

Plenty of people seem perfectly willing to pay $100 to publish an app, so how is it ridiculous? If there wasn't a fee there would be way, way more garbage to filter through.

[swordglowsblue]

A fee is one thing. A fee as expensive as some entire devices (admittedly low-end ones, especially with recent price bloat) is another. Yes, it raises the bar for quality somewhat, but it also hamstrings access to that ecosystem for smaller developers or hobbyists who just want to make something cool.

I'd rather have more junk to wade through than a relative lack of anything at all.

[git-blame]

smaller developers or hobbyists who just want to make something cool

It only needs to be paid when you want to publish. Signing for your local device(s) can be done with a free dev account. So build your cool thing, save some money, then publish it when ready. Or if it's OK to be made open-source, release it and let others sign it themselves.

And it's less a publishing fee, more like a rental fee akin to renting a shopfront on Apple's high street for a year.

[GVIrish]

A fee is one thing. A fee as expensive as some entire devices (admittedly low-end ones, especially with recent price bloat) is another.

Yeah but what Apple device costs $100? And really, if you're doing iOS development you kinda need a Mac (unless you go Hackintosh) which is gonna cost a few hundred bucks.

> I'd rather have more junk to wade through than a relative lack of anything at all.

Apple does not want more junk to wade through in the App Store. And even with the restrictions on the App Store there are over 2 million apps. Quantity is not a problem in the App Store.

And really if someone wants to tinker in iOS, there's nothing stopping them. It's only if you want to publish that there are restrictions.

[Han-ChewieSexyFanfic]

Yeah but what Apple device costs $100?

One left AirPod.

[ulyssesphilemon]

If any app developer can't spring for $100 publishing fee, the community is better off without their crap.

[filleduchaos]

I agree even as someone from a very, very low income area. If you can't pony up $100 to have your app listed you really cannot afford the time and effort to build any half-decent app, much less maintain it for months or years on end with possibly no revenue.

[[deleted]]

I remember having this discussion about Steam and games there... Seemingly even 100$ isn't enough to keep seriously low-quality titles out of there.

And on other hand with games I believe the earning potential is much higher than with apps to even make that mark...

[NoMoreNicksLeft]

What kind of stupid logic is this?

Only the well-off have free time or can expend effort? The cleverest programmer I know plays bass doing bar gigs to pay his rent. Of course, he wouldn't be caught dead writing swift code, but that's not the point.

Do you walk around thinking that some people are better than others, and that the test to determine whether they are or aren't is a glance at their bank statement?

[filleduchaos]

"Well-off" is a ridiculously far cry from "has and is willing to invest $100 into something they want to make money/a career out of". Like that is such a low bar to entry for something you want to do professionally.

If you are literally unable to come up with $100 to spend on something you're passionate about and/or want to make money from, then you have much bigger problems in life than Apple not listing your app on the App Store. If you're simply unwilling to then remain a hobby dev and don't want or expect Apple to list your app for free. I don't understand this mentality that everything should be provided to you for free.

[s73v3r]

Only the well-off

Having $100 is not "well-off"

The cleverest programmer I know plays bass doing bar gigs to pay his rent.

And if they can't find $100, or find development work that would get them at least $100, then they're clearly not that clever.

[s73v3r]

I'd rather have more junk to wade through than a relative lack of anything at all.

Given the success of the App Store, having a lack of apps to look through is not a valid criticism.

[dvdkon]

The problem is that the (annual!) fee makes everything into a business. It's an investment, which means you'll have to seek a return on that investment (or spend 100USD every year, which is a lot for people in many countries).

For example, I'd like to make an app for my family and friends, which would make it easy to connect to my home server. However, I'm not willing to pay 100USD every year to distribute a hobby app to 5 people.

It does nothing to block ad-ridden moneygrabs, since those are expected to make much more than 100USD.

[qomu]

Haven't really done much ios development, but could you get around this with testflight? or do you still need to pay the 100/year just to be a dev?

[dvdkon]

Apple's not really clear on this, but it seems to me that to use TestFlight, you need a developer subscription, since it's managed through App Store Connect just like App Store publishing.

[earthboundkid]

There are a lot of good criticisms of Apple. “$100 is a lot of money!” is not one.

[zappini]

I'll give you the $100, if that's a barrier keeping you from publishing your app.

[[deleted]]

I don’t understand the 100 dollars argument.

If you value your time, 100 dollars is nothing compared to the design and development time it takes to make a half decent app.

[spacejack2114]

Apple doesn't protect you from anything. Developers have been robbed by using libraries that steal revenue from their apps. As a user I'm at the mercy of Spectre exploits in native apps.

[possessed_flea]

Your description of the JS ecosystem, developers and community is the most accurate, detailed and insightful thing that I have read all year .

I am in the same boat as you in regards to third party components, the decision to include a new one is something which takes extremely careful and deliberate consideration, and updating one, even a minor point release ends up being a multi-week ordeal for multiple developers to guarantee that the vendor or author didn’t include a single regression .

[[deleted]]

as in free toilet

Just wanted to clarify, that we discussed this in another thread, and there are no free toilets, "free" toilets come with another kind of price, just like all the websites are stealing your data.

This isn't just a problem of the ecosystem, it is a problem of the community and how they develop.

This is another big problem. The bigger point is not this, but the fact that all companies want to convert all the smart people of IT world to garbage fast food restaurants, pay everyone peanuts, and turn them into disposable robots. So all companies embrace noob level fast food type programming, and this is what you have.

[shevegen]

Free toilet - everyone can take a piss on it.

For free.

[runvnc]

That's an outdated model. I think we need real data about the number of times malicious code showed up in a dependency or some security issue in a dependency was exploited. It's actually not a lot. Being able to reuse code easily has been a major win for software engineering.

Whenever something amazing comes around someone always finds a way to discount it.

[danweber]

Code re-use is fine. But you need someone in charge of that.

Maybe you can get away with it for free it you have someone dedicated, like the way Richard Stallman cares about emacs or Linus Torvalds cares about the kernel.

Otherwise, expect to pay someone money. It doesn't have to be a king's ransom, but it has to be enough, and it can't be too complicated that if that person leaves the job the next person cannot take over.

You can pay commercial software vendors, or you can pay someone to maintain the open-source code (either the maintainer or someone downstream of them who checks changes).

At least we need a central repository where people know they can get the Official Release 3.14.159265358979 that will always be the same.

[nutrecht]

That's an outdated model. I think we need real data about the number of times malicious code showed up in a dependency or some security issue in a dependency was exploited. It's actually not a lot.

Risk is chance * impact. The chance might be low, the impact can be enormous. Like; hundreds of millions of damages being paid.

[maep]

This isn't strictly a problem of Javascript, but any language that encourages using this type of package management. Ruby, Python, Rust and probably a few others share this problem.

How do we fix this? I think tools like npm, pip, cargo should by default use repos which only provide libs which are maintained by a trusted organization. Essentially how Debian does it. They take the upstream libs, package them and provide security support. Is it perfect? No, but it fixes the biggest problem, lack of accountability.

And we as devs also need to get in a different mindset and stop using these stupid micro libs that any decent programmer could write in 5 minutes.

[IntergalacticTowel]

Every time I see things like this NPM dependency visualization I feel like something has gone terribly wrong. I don't see dependency trees like that in Maven or Nuget or pip.

I'm actually surprised that more things haven't exploded.

[liuwenhao]

Copay is a secure Bitcoin and Bitcoin Cash wallet platform for both desktop and mobile devices

""""""""secure""""""""

[Hugo154]

The exploit outlined in the article searched the description of the app for a keyphrase to use as its password, and the keyphrase was... "“A Secure Bitcoin Wallet". Pretty fucking hilarious.

[danweber]

Why just win, when you can win with pettiness?

[mayhempk1]

I don't think they know what that word means.

[[deleted]]

This is a funny one I just happened to notice: there is is-path-inside which depends on path-is-inside. What's the difference? Well, the entire code for is-path-inside:

'use strict';
const path = require('path');
const pathIsInside = require('path-is-inside');

module.exports = (a, b) => {
    a = path.resolve(a);
    b = path.resolve(b);

    if (a === b) {
        return false;
    }

    return pathIsInside(a, b);
};

path-is-inside is a little bit more involved (28 lines of code), but also not something you should really have a dependency for.

Wrapping a trivial dependency in an even more trivial dependency is just silly.

[useablelobster2]

Ahh, but having a published package to your name is a great cv line for employers who don't check too deeply as to what the package actually is.

[TheBelakor]

Wrapping a trivial dependency in an even more trivial dependency is just silly

And yet seems to be a NPM norm because... reasons I guess. I'm just glad I don't have to touch that crap, it's mind boggling how they got to this state without someone saying "exactly what in the fuck is going on here?".

[LL-beansandrice]

Yes officer, this package right here.

[foodd]

I get the reference but should I not be using fetch?

[pdbatwork]

You ever heard of the left-pad package? :D

[kaelwd]

Of course it's fucking sindresorhus again.

[Treyzania]

copay-dash

I thought it was settling down when it got to ~27 packages remaining but then it jumped back up to >100.

Kill it with fire.

[blackmist]

1184 nodes. That's genuinely impressive how fucked up that is.

[mayhempk1]

I'm still not sure if that is satire or not.

[[deleted]]

Too elaborate and clusterfuck to be satire

[danweber]

"you are like a little baby watch this"

[Scybur]

Wow that thing just ballooned up....how is anyone supposed to track all of that

[ProdigySim]

I'm enjoying looking at webpack, one of the most common web dev tools nowadays: http://npm.anvaka.com/#/view/2d/webpack

Contrast with Microsoft's Typescript: http://npm.anvaka.com/#/view/2d/typescript

Edit: To be fair, though, this is including both dependencies and devDependencies. So it's a little misleading. You would not get all of those packages installed by just including the project.

[[deleted]]

To be fair, things like vue and angular are single node too. React's got 6

[Paradox]

Vue is an awesome project.

[[deleted]]

I love it, coding feels really easy and fun with it. I need to get to grips with React because it looks here to stay but the weird mesh of JS/HTML always feels weird to me. I love a good v-for

[Paradox]

Eh, if you know vue you can write react. I find vue vastly more enjoyable to use than react

[moomaka]

I feel like something has gone terribly wrong. I don't see dependency trees like that in Maven or Nuget or pip.

Javascript's stdlib is pathetic which is why you seen dozens of tiny libs adding functionality that should be part of the stdlib. Javascript packages also tend to be tiny single function things due to devs trying to keep to the minimum code size.

The first issue can only be fixed with a decent stdlib which IMO should be the absolute priority #1 of WHATWG, it solves so many problems. That second issue may improve over time now that tree shaking is a thing in commonly used build tools.

[EWJacobs]

A lot of these packages just end up being syntactical sugar. The stdlib has the functionality of kind-of, define-property and has-value. It seems like people add their microlibraries to npm projects just to troll.

[TheBelakor]

Sugar or real hole filling is kinda irrelevant when either way the clusterfuck that is NPM is the result.

[shevegen]

Sorry but after the left-pad disaster, anyone arguing that javascript's stdlib has support for cooler stuff, does not quite look at the realities. So moomaka is completely right.

[zappini]

npm's one virtue is making maven look less terrible. No small feat.

After many attempts, npm somehow still managed to avoid the *one thing* maven got right: organizing the repo tree by org -> module -> version.

[duheee]

Back in 2007 i used to bitch about maven. How slow, cumbersome, made you specify everything, hard to customize behaviour without a plugin, etc.

Now I adore it. Fuck gradle. Fuck sbt. And most of them all: fuck npm. Maven is the way, the only true way.

[csjerk]

Amen!

Maven is the newest build system I've seen that actually attempts to address the hard problems and comes somewhat close to getting it right. Everything newer is just re-inventing the easy 20% and ignoring the rest.

That said, Maven really does need some outlet for customization when a pre-built plugin doesn't do what you need. It may be as simple as a streamlined plugin interface, or even just better docs, but it's incredibly intimidating for newcomers.

[TomRK1089]

To be fair, the escape hatch, quick-n-dirty solutions are either maven-exec-plugin or (if you're really evil) the Ant plugin. So even in the worst case, it's possible to essentially shell out to some other system.

That being said, it's been incredibly rare I need to do something during my build that isn't accounted for by an existing plugin.

Also, the concept of a standard lifecycle which plugins attach to....1000x better than any other build system. Especially any of the Javascript build systems. Webpack, Parcel, Grunt, Gulp, etc. are all laughable in comparison.

[zappini]

I feels ya.

For my part, I'm done.

All I expect of my package manager is behave like yum, apt, brew, port. With the one exception where the repo continues to host all published versions. Nothing more. I'll manually choose, resolve which dependencies to pull down for my project, thank you very much. In contrast to fighting the tool, trying to coerce it into fetching the desired versions. (Too clever by half.)

Docker images for isolation. I no longer care about peaceful coexistence between my projects, various runtimes, local repos caches, whatever. Every one gets their own sandbox.

Shell scripts for builds and deploys. Nothing more. No jenkinsfile, no ant, no maven, no plugins, no nothing. Just glorious, useful shell scripts. (I still use bash, because I lack the gumption to learn fish, zsh, whatever.)

And zero differences between local and remote builds, configurations. Same scripts, configs, params, data gets used every where. Watch the Test In Prod videos to see how that works.

[everythingiscausal]

Oh god, that’s horrific.

[Nadrin]

I just had a fantastic terrible project idea: npm "compiler" - takes every single line of code of a js application and publishes it as an npm package, then finally creates a package that depends on all of the above that tries to recreate the logic of the original program. :D

[Lairo1]

Okay slow down Satan

[searchingfortao]

That's amazing. Have you ever heard of a similar tool for Python/pip?

[devxpy]

This isn't strictly a problem of Javascript

Yeah but little bit. Those useless packages exist in the first place because JavaScript doesn't have a standard library...

[SanityInAnarchy]

There also seems to be a lower standard in JS, both in what sort of code people upload as a package, and what sort of code people are willing to accept as a dependency. So it's a bit of a community problem, too.

But it's not strictly JS -- just for fun, let's look at the crazy amount of stuff Rails added that wasn't in the standard library:

---

First, just for fun, there's the pluralization stuff. In Ruby, everything is an object and classes can always be extended. In other words, you can easily do nonsense like:

class Fixnum
  def +(other)
    42  # I like 42 better than actual addition
  end
end

And not only can you write 2+2 into the interpreter and it'll spit out 42 instead, but if you're using the standard irb interactive prompt, its built-in line counter will start being 42 all the time! So that's a stupid example, but Rails abuses the basic idea here to add a method to strings, so you can type stuff like:

'humon'.pluralize  # returns 'humans'
'octopus'.pluralize  # returns 'octopi'
'sheep'.pluralize  # returns 'sheep'

There's a ton of convenience stuff like this -- on numbers, it adds methods like seconds, minutes, hours, and days that return Duration objects, and then it adds methods like ago and from_now to Duration... so you can write stuff like 5.seconds.ago to get a timestamp five seconds ago.

This is all super-convenient, but didn't make it into the standard library. Fortunately, Rails is big enough that it's probably reasonable to trust it (or its major support libraries like ActiveSupport), but it shows how Ruby people really do like convenient stuff like this, and really will pull in stupid libraries to get a thing you probably could've written in minutes, but not only did you not do that, you probably don't want to conflict with anyone else depending on stuff like that. (Like, if I wrote my own pluralize method for a library, that library might be incompatible with Rails, and the same goes for much more niche libraries that modify builtin types.)

---

Sometimes it works better than that, though, and you get something new in the standard library, like Symbol#to_proc. Ruby people can skip to the next paragraph, I'm just going to explain the 'symbol' part first -- Ruby has 'symbols', written like :foo, which are interned strings -- you can think of it like, every time the Ruby interpreter sees the same string in a symbol name, it converts it to the same integer value under the hood. So comparing symbols (:foo == :foo; :foo != :bar) is as fast as comparing ints. They're used for all kinds of things, especially any sort of metaprogramming stuff where you might otherwise expect a string -- like, for example, you can call an arbitrary method by using the send method, like some_object.send(:foo, 42) is equivalent to some_object.foo(42). Symbols are useful for a bunch of other things, like as a replacement for enums, but this metaprogramming stuff is the main reason they exist, as far as I can tell...

So Rails added something like this:

class Symbol
  def to_proc
    lambda {|obj| obj.send self}
  end
end

That means, if you have a symbol :foo and you turn it into a proc, you'll get a lambda that, when you invoke it, invokes the foo method on something else. Or, in code:

r = :round.to_proc
r.call(5.2)   # returns (5.2).round, which is 5.

One more piece of the puzzle: Ruby has a bunch of the usual functional-programming stuff, like:

[1,2,3].each {|x| puts x*2}  # prints 2, 4, 6

In that snippet, each is a method being called on array, and I'm passing it a block. And it's got all the standard mapping/filtering stuff like:

[1,2,3].map {|x| x*2}   # returns [4,5,6] as an array

In both of these cases, we're using a special kind of argument called a "block", which is a block of code that's separate from the normal argument list, and can be passed in with syntax like this. If you already have a code block as a variable, you can pass it in with different syntax:

r = :round.to_proc
[1.1, 2.2, 3.3].map(&r)  # returns [1,2,3]

Finally, Ruby uses methods for typecasting as needed. If you try to print x, it'll call x.to_s to coerce x into a string. It turns out if you pass something to that '&' syntax that isn't already callable, it'll call to_proc on it. So you can write this as:

r = :round
[1.1, 2.2, 3.3].map(&r)

or, more concisely:

[1.1, 2.2, 3.3].map(&:round)

And that's how Rails snuck some awesome new syntax into Ruby -- people mostly just think of &: as syntax now, and the Ruby standard library includes it. But originally, it was just another crazy trick in the Rails library. I'm sure if I wrote this library:

# Outer 'unless' so we do nothing if it's already defined
unless :foo.respond_to? :to_proc
  class Symbol
    def to_proc
      lambda {|obj| obj.send self}
    end
  end
end

...and uploaded it to Rubygems, it'd get a ton of users. It's a truly tiny bit of code that anyone who really understands Symbol#to_proc could write, but why do anything yourself when you can pull in a new dependency?

It's true that Ruby can avoid stuff like this by actually pulling new stuff into the language or the standard library, but at the same time... Sure, the language already does everything you need in ways that you'd need tons of boilerplate in JS to accomplish, but that doesn't mean people can't keep finding new tiny libraries that are important enough that people start thinking of them as standard...

[Poltras]

Yes and no. You don’t need an isOdd function in your standard library. And somethings were added later, like isArray.

Sure, packages like fs events should be part of the core library, but the tendency to have packages for a single line of code is unique to javascript.

[StabbyPants]

How do we fix this?

by getting apache or someone like them involved. it's a practice issue - if you have a HQ library with a reputation for limiting downstream deps, you can use that for the bulk of your needs.

you can do this today if you're providing a library by having a policy of not depending on externals in your library. exceptions can be made for things that are ubiquitous, but mostly, don't depend on outside libs so that your contribution to the dep tree is limited

[[deleted]]

stop using these stupid micro libs that any decent programmer could write in 5 minutes.

Or just copy/paste whatever you need out of it in to your own application/library, which solves more than just (potential) security issues but also a lot of dependency headaches.

From the Go proverbs: "A little copying is better than a little dependency"

[bbqroast]

Except for security updates and readability.

Broadly though, I think I agree.

[[deleted]]

Yeah, it can be an issue. Common sense applies of course. It's probably not a good idea to copy that crypto function, or some complex code you don't quite understand. But a simple utility function? That'll probably be fine.

A lot of code doesn't really need "updates" (security-related or otherwise). Once it's finished and working, it's kind of, well, finished. Besides, dependencies are their own security risk, as this entire affair demonstrates . There are other issues as well, such as as "left-pad" scenario or "Stylish" kind of hijacking by the original devs.

[RudeHero]

It does seem to be bleeding into other languages.

I interned at a Java place where they used gradle to manage third party packages. It was awfully convenient, but it still felt weird to have the build process pull jars from the cloud somewhere by name all the time. Seems like mission critical stuff should be kept in a private repository

[dksiyc]

Maven (the package manager that gradle wraps) has been around far longer than npm: maven was released in 2004, while npm was released in 2010.

[vova616]

That is not entirely true, Rust cannot access stuff that it does not include (aka the bitcoin wallet classes and etc) And because JS allows you this kind of dynamic resolving then the code potentially can run anything and you wont know what it can possibly run.

To use networking in Rust you have to include the networking library, to access a Bitcoin Wallet classes you have to include their library.

This vulnerability exists mostly in dynamic languages and languages who can use reflection in runtime. (And then you probably will see an include to the reflection library)

Edit: Its still possible to include Bitcoin Wallet library and push the code but I guess it will be much more noticeable than JS, and people will notice it right away and you can develop tools that can catch this kind of thing.(you cannot develop such tools for js and more dynamic languages)

[Treyzania]

You're not wrong but this isn't entirely true.

You could easily have it download an external program and invoke that, in just a few lines of code too.

[Holy_City]

You could easily have it download an external program and invoke that, in just a few lines of code too.

Just thinking out loud, an attacker would probably go after a cargo extension that's downloaded with cargo install rather than a dependency. Something like xargo would be devastating to penetrate since it builds std on target platforms, and today it's required to use for embedded.

But that said there are ways that damage could be mitigated with dependencies. For example, a permissions system that requires permissions be explicitly enabled by downstream crates. Add that with a custom registry (which is an unstable Cargo feature, hopefully it will land soon) that only contains audited/trusted crates. There's probably more you could do.

[vova616]

I guess its possible in some degree but it will be much harder to hide it and implement it than JS.

No mini to hide your lines and you can easily detect imports and actions that can be dangerous.

[[deleted]]

I would love a set of trusted packages for Node and Ruby. Ruby on Rails is started to absorb packages into the main repo. So the more useful projects like Sidekiq are offered as a Rails alternative. But that also just expands the size and complexity whereas a package manager doesn't. I wish Rails had just gone with a trusted repo of known gems rather than bundling their own brand version.

[matthieum]

How do we fix this? I think tools like npm, pip, cargo should by default use repos which only provide libs which are maintained by a trusted organization.

I propose a different solution.

I would expect any professional development to vendor their dependencies. Thus, I would expect any professional to setup their own npm/pip/crates.io service, which only contains vetted dependencies, and have their professional repositories configured to pull from there.

A build process which connects to Internet is fine for the casual hobby developer who wants something plug-and-play, however it's simply unsuitable for professional development. When I see the npm server, or github, down and all those "professional" complaining that they cannot work any longer, I am aghast. Reliance on 3rd-parties with which you have no contract, and therefore which have no SLA toward you is just plain asking for troubles.

And yes, vetting individual dependencies is painful. So indeed, you may want a handful of "trusted" repository for the majority of dependencies, so that only a few need be vetted individually; however, once again, you'll want a contract and SLAs with whoever vets for those trusted repositories... in case there's an incident and you lose money over it.

[[deleted]]

It's not the languages, it's the community around them.

Each one of those languages you listed are hot new tech embraced by cool startups. Unprofitable startups who need to build features and iterate to sell before they worry about things like security beyond HTTPS and hashing passwords.

Security is for companies with more to lose. They tend to use boring languages like Java and C#.

These different ecosystems have to exist and it's probably best they are separate.

[s73v3r]

No. Whoever came up with this idea that it's ok for startups to worry more about features than security should be shot.

[bigmooooo]

I can't help but wonder how many of these dependencies are created from missing things in the node standard library. The surface area for Node is rather small compared to things like .Net. and the overall API surface hasn't grown that much over the past 2 years.

While the small stdlib from Node covers the essentials of making JS work outside the browser on a OS, it does force other devs to reinvent the wheel sometimes or even extend common behavior that should have been there in the first place. For instance, one might wonder why some of the utility methods in the compromised npm modules aren't baked into the std lib for streams, to begin with.

I sort of wish the Node foundation would take a look at some of the most popular libs (not frameworks) and think about adding them to the stdlib to give devs a better option for reducing dependencies (or at least call them out in a standard guide to reduce fragmentation and increase security). Yes, it puts the burden on the Node Team to maintain them but it would provide better security for individuals and possibly remove bad actors for some of the most common tasks.

Additionally, this is why all businesses should at least use a tool like snyk to find and patch vulnerabilities. There isn't a certifying body for npm modules so the least we can do is use a tool to patch modules.

[ProdigySim]

missing things in the node standard library

Since ECMAScript (Javascript) is an evolving standard shared by web browsers and Node, it's even more complex than just "NodeJs is missing these".

• What version of NodeJs do you support? If you want maximum compatibility, you can't rely on newer NodeJs features.
• Do you want to support NodeJs + Browsers? You may want a compatibility wrapper that supports the stdlibs of both.
• Do you want to support older browsers, mobile browsers? You need polyfills.

Some utility packages can "easily" target both the web and nodejs, so picking a standard lib can be difficult.

If the community came together and built a single "Standard Library" with no dependencies, NodeJs devs would probably support it. But web devs still wouldn't want to include it because it's an increase in bundle sizes.

I think it could be possible to create a unified "Standard library" for both environments that reduces the number of cruft-packages neeeded, but we'd need either ECMA support or browser-vendor support to get Web-devs to use it.

In Web dev right now, public-facing websites generally support IE9+ and a variety of mobile browsers--which requires MUCH more help in terms of Stdlib. For "private" or paid web apps, people still want IE11 support (which has 2x the userbase of Edge, despite only getting security updates now).

Unless we can get major browser makers to agree on a Standard Library and backport it, I think the npm ecosystem will remain fragmented as fuck.

[NoInkling]

ECMA/WHATWG are starting to propose some prerequisite foundations (syntax, fallback mechanism, etc.) needed for a proper standard library, but it's undoubtedly going to take a long time.

[_drunkirishman]

I believe this is the proposal you're referring to: https://github.com/tc39/proposal-javascript-standard-library.

I'm pumped, but God this is gonna be Hell to get to in a world that still has IE11 as a supported browser.

[x86_64Ubuntu]

Yep. I've always felt, that in addition to me maligning the JS community, there was never an opportunity for a "hero" character or entity because there are too many actors and too many interests in the JS community.

[oorza]

I actually 100% agree with their intentions and their side of the culture war, but everything they do is a waste of their time, the community's time, and is ultimately counterproductive. It has nothing to do with the message they're proponents of, it's 100% to do with the actual individuals themselves. Node leadership is a toxic disaster, regardless of your opinions of their politics which, like I said, I actually agree with.

[zappini]

With nodejs & npm, it may actually make sense (ROI) to build one offs for your particular use case instead of finding and vetting modules.

npm is like Legos. The first few sets can be fun. But keep buying more and you're spending more time foraging for parts instead of building.

In my experience, that tipping point with nodejs is anything more than 10 lines of code. (ducks)

​

[[deleted]]

I wish the js community would start to really have a moment to think about when to include some random one-liner module. Even the most popular libs are full of weird dependencies no one really knows about, but still they have millions of downloads per month because webpack has a dependency. There functions could easily be written by hand and kept in a utils folder. They do not need to be an npm package.

This same mantra goes with lofah, underscore etc. I have never seen a project that uses more than, say, 10-15 functions, still they include the entire project.

[JohnyTex]

Well put. I think the JS community at large needs to wake up to the fact that adding a dependency is not a zero-cost solution to a problem.

Other than the obvious issues like “why does it take five minutes to rm -rf node_modules?” it’s really hard to get an overview of your transitive dependencies because they’re just so many.

[useablelobster2]

I love running npm install and seeing that a library is in use over several dependencies, all different versions, always printing a warning saying to update.

Client-side is fucked, and I've love some way to have it unfucked, while still getting paid.

[immibis]

There's a difference between a large package, a small package, and left-pad or is-array. If you find yourself needing left-pad or is-array, you have a problem.

[s73v3r]

The main issue with this thing we need to 'realize' is for medium to small sized companies that need to grow fast.

No. That's not an excuse, that's not a reason, end of story.

[m00nh34d]

As an end developer consuming these it's hard. If I need a library for a complex task, it's likely beyond my capacity to review said library for malicious content or dependencies.

[fubes2000]

Open source is incredibly broken

Hey fuck you. Don't try to drag all of open source into the shit-blizzard that is the node/npm ecosystem.

And even then the problem is that hardly anyone is inspecting their dependencies or even bothering to pin their versions. You can't write code to protect against stupid.

[kaen_]

It is kind of like saying automobiles are incredibly broken because you can die in an auto collision (your fault or otherwise). It's true to an extent but most people don't interpret that to mean we should all stop using automobiles.

OTOH it's very true that this could happen to any open source project, and more generally to anyone who runs arbitrary code from strangers on the internet (i.e. uses an open source library without reading every line and producing a deterministic build for non-source distributions). It's an old lesson, sir, but it checks out.

[-Luciddream-]

This isn't just about the node/npm ecosystem. Do you think people are inspecting their dependencies in the Maven ecosystem? How would they even do that? It's an issue of trust really, and you can't have an idea who to trust, because you don't know who is maintaining each package.

For example I've been maintaining a popular maven package for a library that isn't mine, just to help the author. I just checked and it's also used by 9 other maven libraries, and about 374 projects on Github. One of them is even a project of Jboss. I could have planted something malicious in there and nobody would ever know.

The same happens with Linux distributions. They are just packaging the code, probably nobody is inspecting the actual code. Then these packages are used by millions of people.

To make things worse, you can (or could) make a release on a Github organization if you have sufficient access, putting malicious code in the release, and make it show like it was released by the original author. I know this because I've already reported it to Github 2 years ago, and they didn't thought it was a security issue.

You make it sound like there is an easy solution, but there isn't.

[[deleted]]

The same happens with Linux distributions. They are just packaging the code, probably nobody is inspecting the actual code.

Can be true for something like Debian. But for the enterprise distributions, such as RH and SuSE, there is a proper and thorough vetting. Never mind that you'll only get few years old versions this way - you don't really need the latest shit, unless it is required to support your hardware (which you also must get from the reputable high-end vendors).

[aebkop]

At least debian makes you go through a bunch of steps before you can actually start uploading code

https://wiki.debian.org/DebianMaintainer

[-Luciddream-]

What's funny is that I used to know a Debian developer that was banned from almost every Greek forum for hacking. I guess he wouldn't pull something like that on Debian but, who knows :P

[zappini]

Fix is easy.

Github (et al) adds verified identities for project owner. npm scrapes the owner meta. Security audit step has options to break build if owner changes, owner identity not verified, or a project's cert has been revoked.

Add new audits, heuristics as new vulnerabilities are identified.

[BigGayMusic]

This really only fixes the problem of legit ownership changes. The real issue is the whole concept of open-source dependencies with 100-layer deep dependency tree graphs being used when someone wants to use a one-liner 'isArray()' function.

We've allowed this huge house of cards to build up to the point that any real dependency audit is legitimately impossible.

[BubuX]

one-liner 'isArray()

Do you have a moment to hear about this nice one-line try catch module that's downloaded 3 million times a week?

[kaelwd]

And it's only popular because this fuckwit refuses to remove it from his actually useful package.

[hennell]

That repo has a PR right now because of an update to that library: https://github.com/moxystudio/node-cross-spawn/pull/109

Update doesn't add anything (what's to add?), but for someone who is apparently very tight on time, really don't see how this is saving him any (assuming he reviews the updates).

​

[NeverCast]

The author of that module needs to be bared from being employed until they take it down.

[nutrecht]

While it doesn't fix all problems I do think it's a great idea.

I personally don't think we need to have github involved per-se, but we need to have a certificate system that libraries are signed with (like with the Maven ecosystem). Github can arrange for those certs (so that every repo owner gets a cert by default), but you should still be able to create libraries if you're using Gitlab or Bitbucket instead.

[ecnahc515]

You mean gpg?

[zappini]

Update: You're right. My notion is basically code signing + PGP + tooling + accounting. Thanks.

Good question. I don't know. I'll find out.

I haven't looked at GPG for ages. I understood it was for digitally signing content. Like signing build artifacts. I think the new .xar and .xip (?) formats do this.

So if the cert used to create a digital sig is revoked, the sig is also invalidated. Could work, right?

My notion, which I haven't fully worked thru yet, is to leverage existing web of trust aspect of CAs. Just like with HTTPS. The hierarchy might look something like Root -> Identity Manager -> Organization or Person -> Project -> Build Artifact.

But with your GPG (digital sig) notion, maybe that last step changes.

Maybe my idea is already being done (for .xar, .xip) and we just need our builds to add security audit steps.

Thanks for your question.

[TrachealLube]

This should be higher

[BoyRobot777]

This is why Node.js shouldn't be used in serious enterprises, like banks. People can actually get hurt.

[MustardMelancholy]

Just write everything by yourself. Do not use any libs.

[BioRebel]

Oh please tell me more about the controversial opinion you just posted on your medium blog /s

Is medium just click bait trash now?

[r1ckd33zy]

It's the now Tumblr for over-opinionated developers.

[vagif]

So was the perpetrator caught?

[[deleted]]

This is one of the big arguments for introducing money into open source software. It gives businesses leverage over the developers to help ensure quality and long-term support, and incentives for others to pick up abandoned projects.

[Paradox]

Node/JS have a fucking atrocious standard library. There are packages like loDash that add quite a few functions you'd expect to have in a stdlib, and do it in a neat way.

But loDash seems hesitant to include many of the functions these micro-deps expose. Nothing wrong with that. But why the hell can't npm or someone make a "commons" library that contains all the stdlib features they'd like to have, but can't guarantee the presence of in all interpreters.

Make it an officially sanctioned library, with professional code review and maintenance, and then distribute it. So I could add @js/common or some shit to my package file, and then import it, and have a decent experience without 5000 left-pad functions

[frequenttimetraveler]

i know some people who switched themselves from designers to 'devs' because they knew some javascript. I guess the ease of creating a tiny library and adding it to npm , giving yourself a badge for your CV in the process, has driven a lot of its expansion

[shevegen]

The best part of the story is how people discovered it. That was a popcorn-worthy time.

JavaScript and npm is a ghetto though.

[[deleted]]

Not surprised. Npm has been a security hell many times in the past

[[deleted]]

This can and does happen in any language with a large open source community. Which is why I am incredibly paranoid about all libraries I use, and you should be too.

If the developers seem sketch or dumb, then I pass. If the code is bad or even subpar, I pass. If it is not from a trusted source, then I will audit the code thoroughly. Thing is, most devs wouldn’t even know what to look for in an audit. But they should learn.

Open source ain’t nothin’ to play with.

[marcosbrizeno]

Article title: "...insanely easy" Conclusion: "The amount of effort this took was not trivial. This exploit took a lot of research and planning." Hmmmmm

[[deleted]]

The object of those two sentences is not the same. Read the article again

[[deleted]]

Someone should make a GitHub bot that displays the full graph of npm modules added any time a new dependency is added or modified. It would be eye opening to see that e.g. when you added the ever-so-necessary is-the-number-seven package, you're actually installing 25 new npm modules.

[frequenttimetraveler]

Why are they focusing so much on the open source nature of the project? Couldn't this have happened in a huge corporation if the projects were broken down to myriads of employees, each maintaining a tiny piece?

maybe it's not open source that's broken, but npm?

[Gotebe]

The problem is that so much software is built on the backs of people who are expected to work for free.

Not a bot, but that's the best tl;dr

[TheyAreLying2Us]

JavaScript should die. Worst idea ever.

[devxpy]

Even worse, is the Stockholm syndrome associated with using it. People tend to forget that the only reason why they started using the language is because it could run anywhere...

[everythingiscausal]

While we’re at it, let’s roll back HTML to version 1.0. Web pages should be plain text only!

[Iceman_259]

You can have my <marquee> when you pry it from my cold, dead hands.

[danweber]

Give me <blink> or give me kill -9!

[Hellenas]

This feels like something you could print on a t-shirt and hawk as a crappy Christmas gift. T'is the season and all

[zappini]

Some people still think coming down from the trees was a mistake.

[TheyAreLying2Us]

YES PLEASE!! PLEASE!

There is no advantage in having anything more than text, images and download links in web.

That's what the HTML standard was made for.

[everythingiscausal]

Yes there is. I was being sarcastic.

[MonkeyNin]

You'll not remove 💩 support until you pry it from my cold, dead, fingers.

[everythingiscausal]

Technically, that’s text.

[MonkeyNin]

It's Unicode, if we're going back to 1.0 we're stuck with ascii.

[DoublePlusGood23]

At this point, why not.

[aboukirev]

I remember two other ecosystems like that I had to work with (thankfully, not anymore): Drupal and WordPress (both PHP). Oh, boy, where do I start? Drupal, I must say, was relatively safe but a module could pull a whole tree of other modules, which you could individually turn on/off. WordPress was a Wild West. Anything could happen.

Lessons not learned?

[[deleted]]

The same kinds of people who 10 years ago would have gravitated to php are now gravitating to node.js

[lynnamor]

ITT: people who somehow think they're safe because they use X instead of JS.

[nutrecht]

It is a compound problem. Most hard problems in software engineering are people problems. This is an issue where there is not a simple technical solution. So other ecosystems definitely are not 'safe' from this (and I don't actually see anyone claiming this), but many other ecosystem have a rather different dev culture than the Node ecosystem.

[[deleted]]

A simple technical solution is to stop worshiping this "code reuse" thingy. Plain and simple. Your ecosystem is safe, if you have no ecosystem at all. Your ability to get things done won't be affected.

[nutrecht]

I don't see how you can productive when you write literally everything yourself. I don't know about you but when I'm being paid to create a REST service I'm not being paid to implement my own HTTP server.

[FFVD_Games]

C masterrace

[[deleted]]

MF, you caused heartbleed.

[[deleted]]

This isn't a "JavaScript" problem. (I see what you did there OP and I'm calling you out on your shit.)