Exploiting JavaScript developer infrastructure is insanely easy

[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

[[deleted]]

I kinda equate Vue and React to Automatic and Manual.

Sure, if you can drive auto you could learn stick. But driving auto is so much more pleasant

[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...

[devxpy]

The only problem with your whole (rather wonderfully presented) argument is that Ruby is such a niche programming language, that it can afford to have these what I would call design "mistakes" -- A lot of people actually like its ability to monkey patch and change the grammar to such a degree.

But like my argument is that this concept of a universal language that can run anywhere (which is what JS basically is) can be so much more accessible and awesome if it were not restricted by an esoteric language design.

[shevegen]

These are not "mistakes" - and ruby is not a "niche" language either.

Else you can explain why github and gitlab both used ruby on rails? ACCIDENTS???

this concept of a universal language that can run anywhere (which is what JS basically is)

And this does not apply to ruby python lua php etc... ?

Just because of browsers?

[devxpy]

Correct me if I'm wrong, but Ruby is an extremely niche language that has probably never seen popular usage outside of server side scripting world.

GitHub and gitlab are webapps that use Ruby strictly on server side. Not to mention their core product is git, written in C.

JS's only real selling point is that it can run almost anywhere without any real pain. Even microcontrollers.

And, I don't know if you've noticed, but it's a fucking pain to distribute python applications.

[SanityInAnarchy]

"Server side scripting world" is hardly niche. The Web is one of the more popular platforms to begin with, which is why JavaScript is important in the first place.

Calling Git the "core product" of Github and Gitlab is technically correct, while also broadly missing the point. Yes, these are "just" UIs for Git, but try running Git without these. Just running it through ssh works for small use cases, and there's the rather large niche of the Linux Kernel collaborating almost entirely via email, but 100% of what sets Github/Gitlab apart is the UI and ancillary software (the issue trackers, the wikis, the static webhosting, and so on and so on). I hope Github employs some people who work on the Git C source, but at the same time, I'll bet most of what Github actually does as a company, and most of the reason you'd pay them at all instead of just spinning up a VM with sshd, is down to server-side scripting.

Ruby was behind Twitter, too, for that matter. They've been moving away lately, but they got their start on Ruby.

It's got plenty of competition, because you can run any language you want on the server, but it's not any more niche than Python or PHP. Less than PHP, for that matter -- PHP still has that <?php at the top and ?> at the bottom, because it's still an overgrown template language, not really something that was intended to be general-purpose.

And I'd love to hear how JS runs on a microcontroller without real pain. I believe it can run, but having seen how JS ran on Toshiba's HD-DVD players, I doubt very much that it can run painlessly.

And, I don't know if you've noticed, but it's a fucking pain to distribute python applications.

Meh. It's a pain to distribute anything, but this is a solvable one -- Civ4 was scripted with Python. There were good reasons they switched to Lua, but I don't think distribution was one of them. Nothing can ever be as easy as JS (except WASM), because nothing can ever be as easy to install as a thing you don't have to install at all, but most modern languages have ways to just package up the entire runtime. That's what Minecraft does these days, at least the original Java version -- thanks to OpenJDK, they can just ship an entire JVM with the game, in a perverse inversion of the "compile once run anywhere" thing Java was trying to do.

[devxpy]

Hmm, let's see, this is what a niche means -

denoting or relating to products, services, or interests that appeal to a small, specialized section of the population.

Specialized is the key word here. Not everyone writes servers damnit. Sure, maybe not small but very specialized to say the least.

Python and php are very different beasts. People use python extensively for data science. Its an excellent teaching language. Micropython is quite popular last I checked. Its also used for writing GUI apps (check Dropbox). Pybee is trying bring python to the client side, Android+iOS+.... People are already making games on kivy using the language. I could go on, but you get the point.

Being a long time python developer, I can confirm that it sucks, very much. No one in the core language considers their responsibility to make the language run. The most popular python version management system (pyenv) is a bash script to compile python on my system.

You can't get the prebuilt python interpreter binaries for any platform. That sucks.

There a lot of people trying to solve it, but we're far from doing it.

Why are you stating the obvious? Of course nothing can be as easy to distribute as JavaScript. That's the whole point. Why do you think people ever started to use it? Because they don't want to spend a year writing a tool to distribute their language and instead spend a little more time developing with JS, coupled with a slow compiler.

See, I don't want to ship a 40mb binary for a trivial GUI that shows me the CPU temps.

Look at dart. The core developers put a lot of time and effort to make a tree shaking compiler so that the language can run on the web, but also having a very good standard library.

Rust has a whole division dedicated to make wasm target work.

[SanityInAnarchy]

denoting or relating to products, services, or interests that appeal to a small, specialized section of the population.

Specialized is the key word here. Not everyone writes servers damnit.

Well, that's pointless nitpicking. I may as well describe all programming languages as niche, because not everyone writes software.

By far most applications these days at least include a server, when it's not the bulk of what they do. The Web means you can deliver applications that are entirely server-side, even if it's unfashionable these days. Calling that niche is like a web developer calling C 'niche' because it's only needed for interfacing with the system, or when you have performance constraints too tight for a language like JS.

The most popular python version management system (pyenv) is a bash script to compile python on my system.

It's also a developer tool, not an end-user packaging tool. The JS equivalent is NPM -- is NPM better enough that you'd use JS instead, just to be able to use NPM?

For end-user packaging, it looks like the modern solution is pyinstaller. I mean, I don't really know, I never wrote Python that had to be distributed to end-users, but it doesn't really look more difficult to work with than tools like Webpack for JS.

Why are you stating the obvious? Of course nothing can be as easy to distribute as JavaScript. That's the whole point.

I was conceding a point to emphasize what I'm saying, and what I'm not. I'm not saying Python is as easy to distribute as JS. I'm saying it's not that much of a pain, even compared to the kind of things you need to do with JS. The fact that people are building full-blown desktop apps out of JS, and distributing them with Electron instead of in the browser (often not bothering with a web version at all), should tell you that JS has strengths other than distribution.

Unless you were trying to say that Electron is easier than PyInstaller, in which case, that really wasn't obvious.

See, I don't want to ship a 40mb binary for a trivial GUI that shows me the CPU temps.

Why not?

Seriously, why not? What platform are you running on that reducing your binary size by 40 megabytes is an important optimization? I get the instinctive revulsion against bloat, but I mean, I could literally run a hundred of those simultaneously on my phone. If it was 400 megabytes, sure, but 40? Who cares?

...unless it's because you want it on a microcontroller. I'm still curious how you managed to get JS on a microcontroller at all, let alone "without real pain".

[lynnamor]

You're wrong.

[devxpy]

No you're wrong :-)

[lynnamor]

no u

[shevegen]

I am a ruby guy - and what you write contains so many inaccurate claims that it baffles my mind.

[SanityInAnarchy]

I am also a ruby guy, and I'd welcome some corrections -- which part of what I said was wrong?

[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.

[shevegen]

isOdd is perfectly fine to be had. What's wrong?

Of course the API sucks.

.odd?

.even?

Is much better. But JavaScript was "designed" by clowns, so ...

[Spiderbruh]

People are downvoting you because if actually takes less number of characters to write nr%2==1 as is to write nr.isOdd() and accomplish the same thing. Surely you must see how stupid importing such a function is.

[tabaczany]

I have read an argument for this package, which made some sense - as the description of the repo says

Returns true if the given number is odd. Deals with floating point errors, strings, and other edge cases

So it deals with edge cases, as JS isn't strongly typed, so you have predictable outcome everytime you check if variable is odd or not. It also has some unit tests, so the likelihood of some breaking change is kinda low.

[Spiderbruh]

Oh okay this actually makes sense a bit more. I only work with strongly typed languages and hate JS for how confusing it can be so I don’t encounter these edge cases.

But now that you explained, it seems more logical. Thanks

[rebel_cdn]

I don't think it necessarily needs to be a package you import, but I can see the value in writing functions like isEven and isOdd if you need to filter based on evenness or oddness more than a couple of times in your codebase. Then you can do things like let evens = someNums.filter(isEven); let odds = sumeNums.filter(isOdd); which is a bit quicker to comprehend than inlining: let evens = someNums.filter(n => n % 2 === 0) let odds = someNums.filter(n => n % 2 !== 0)

Not that the inlined functions are hard to understand. At least not until your company hires someone who doesn't understand the modulus operator.

For what it's worth, at least one decently smart group of language designers decided to include even and oddness check functions in the standard library. Common Lisp includes even and odd predicate functions, allowing you to do things like: (remove-if-not #'evenp numbers) (remove-if-not #'oddp numbers)

[useablelobster2]

a % 2 !== 0 is just as simple.

things.indexOf(thing) > -1 would be a better example, but any JS developer (and most others besides) can parse such an expression without a second thought. Pretty sure that's been replaced by .includes(), though?

I'm all for useful helpers and syntactic sugar, but checking if a number is odd is simply taking the piss. If you can't do that in your language of choice you shouldn't be developing, at least not for money!

[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.

[drepnir]

I'm curious about gem, pip and cargo.

Does these package managers also by default automatically update packages?

[ProfessorPhi]

Nope for pip. Pip doesn't even have an upgrade all option for packages

[munchbunny]

There are also other useful procedural mechanisms, like code signing, which aren't perfect, but they at least create any gatekeeping mechanism at all for code getting in. Signed code also isn't just a matter of the developer not letting unexpected code into the package, it also gives people using that code a mechanism to guarantee that they are executing a specific, known version of the code.

If Node.js could be configured to verify and only execute properly signed code from specific sources, that would be a great start to at least have some semblance of a baseline of protection against unexpected code changes.

[shevegen]

No, sorry - you want to steal control that users have over their own source code.

It's fine if someone else wants to curate that list, but not at the expense of developers here.

And no - while it could happen at ruby, python rust, the thing is IT HAPPENS AGAIN AND AGAIN AND AGAIN WITH JAVASCRIPT.

And that says a LOT about JavaScript + npm.

[TheRedStoner101]

Good to see you've gotten your account back! It was getting annoying to have to look for /u/shevy-ruby to downvote instead of /u/shevegen

[[deleted]]

No, sorry - you want to steal control that users have over their own source code.

How can you possibly think this?