5 ms·

The only part of the article I disagree with is this line: > But in general, it’s a good idea not to install NPM packages blindly. If you know what to look fo

by gortok 2y ago

The only part of the article I disagree with is this line: > But in general, it’s a good idea not to install NPM packages blindly. If you know what to look for, there are definite signals that these packages are dodgy. All of these packages have just two files: package.json and index.js (or main.js). This is one of several flags that you can use to determine if a package is legit or not. This works -- maybe OK for top-level packages. But for transitive dependencies it's nearly impossible to vet every transitive dependency. If you're pulling in a package that has 400 dependencies, how the heck would you even competently check 10% of that surface area? https://gist.github.com/anvaka/8e8fa57c7ee1350e3491#top-1000-packages-with-most-dependencies https://gist.github.com/anvaka/8e8fa57c7ee1350e3491#top-1000...

ziddoap 2y ago
>If you're pulling in a package that has 400 dependencies, how the heck would you even competently check 10% of that surface area? This would be where different security advice would apply: don't pull in a package that has 400 dependencies.
- krainboltgreene 2y ago
  Given the nature of software development and software developers, especially given American companies decide to value shareholder profits over programmer productivity, this might as well be effectively "You don't need to get vaccines, simply don't get sick from other people."
  - nightpool 2y ago
    Out of curiosity, I've always meant to ask, are you related to the famous Geoguesser content creator in any way? It's a pretty distinctive last name.
    - krainboltgreene 2y ago
      I believe he might be a distant cousin. I've done some family tree searching myself and haven't found many things, since the Rainbolt side has mostly been scoundrels and vagabonds there aren't many details, but we do have a mountain that we named after ourselves after we stole it from natives.
  - wyldberry 2y ago
    Things like this are suppose to be provenance of an organizations security engineering teams. Helping to ensure you don't ship something like this. It's also hard for them too because no one wants to force developers to re-implement already solved functionality.
    - krainboltgreene 2y ago
      I also have never met a security engineer that was eager to do that.
      - finnthehuman 2y ago
        > never met a security engineer that was eager to do that Of course not. We do the fun parts, and write tickets to make the dev team do the boring parts that we will later complain are not implemented to the quality standard we would have reached, had we done the work. That's the deal.
      - wyldberry 2y ago
        Late to reply, but yeah no one is eager to do it. Unfortunately being good at security means being really good at work that is boring, tedious, and not glamorous, which also measures poorly into OKRs and other facets of shipping culture. Unless the team has really strong leadership that can get the security engineer ladders divested from the SWE/SRE ladders. I literally just finished up writing up something that does supply chain provenance checking across 9 languages and still have a lot of edge cases to handle. It's not fun, but it's honest work.
chamomeal 2y ago
Wait how in the world does a React carousel component have over 400 deps…
- KuhlMensch 2y ago
  /giphy "first time?" meme
- Sohcahtoa82 2y ago
  Did you think the meme about node_modules having more gravity than a star was just a meme? It's very much based on reality. The npm ecosystem is just absolutely fucked.
- tristor 2y ago
  Because Javascript is a drug that makes developers stupid. It's almost trite at this point to comment on the obsession that Node has created with developers to reduce functionality to the smallest possible reusable parts, even trivial things, and publish them as packages, then to import and use those dependencies. The idea, in and of itself, is not terrible, but it's been taken to a logical extreme which is very much the definition of terrible.
  - zero_shift 2y ago
    Nearly all of these look like demo projects. You're making inferences about an entire group of developers based on a meme plus a search over the very 'worst' offenders.
- cloverich 2y ago
  History of "micro dependencies" where many flexible utilities are split up into separate packages, such that many npm dependencies are a single function (ie rather than a package exporting ten methods, its ten separate dependencies). Then because there is no standard library, many reinventions of similar but incompatible utilities. etc.
- zero_shift 2y ago
  Do you mean https://www.npmjs.com/package/carousel-react https://www.npmjs.com/package/carousel-react? By the looks of it, this was published by someone 7 years ago as part of a personal project. Nothing uses it. Going through that list... they all look like personal projects, with no dependents, and a single release by a single person.
XorNot 2y ago
This is really where SELinux had the right idea overall: preclassifying files with data about their sensitivity, and denying access based on that, does adequately solve this problem (i.e. keeping npm installations away from id_rsa).
- beardedwizard 2y ago
  The issue with SElinux is usability. A company called intrinsic tried a similar "allowlist" approach to javascript based on the assumption that you could never control this sprawl and had to assume every package was malicious. I never saw the technology take off because generating the allowlist was of course error prone. im not sure what has to change in UX to make these approaches more palatable, but if you have to frequently allow 'good' behaviors, my experience is it never takes off.
  - __MatrixMan__ 2y ago
    I think we need to to focus on empirical consensus rather than taking as authoritative some file which makes claims about what a particular piece of software will or won't do. So before running any code you'd hash it and ask your peers: "what do we think this does?" If it does something surprising, you roll back its effects (or maybe it was in a sandbox in the first place) and you update your peers so that next time they're not surprised. I keep saying "you" but this would just be part of calling a function, handled by a tool and only surfaced to the user when they ask or when the surprising thing happens. It could be a useful dataset both for maintainers and for people who want to better understand how to use the thing.
    - XorNot 2y ago
      This both is and isn't what SELinux does though: the point of SELinux is when you execute a binary, it runs with whatever context is assigned to it and is bounded by that context (or allowed transitions). This is super powerful to implement exactly that, but for whatever reason IMO it's constantly been half-assed on the UI front, because the best version of it isn't "detailed policy confinements for system software" but detailed confinements for user data (which was the original idea that conceived it at the NSA - the data model ultimately looks a lot like how classified data works). AFAIK the biggest problem is that you can't really do an ACL like configuration for it though - i.e. if I categorize all my SSH keys as type ssh_private_key_t, I'm not able to add an additional tag on that to grant targeted access to a specific program (which both does, and does not make sense - i.e. if I'm handing a program one private key but I think it might leak it...why am I doing that? Conversely in the real world we're bounding risk, so I should be able to do that - I don't think Multi-Category Security fixes this?). Basically "empirical consensus" is an SELinux policy, in fact you can generate one that way - run in permissive mode for an application type, collect the actions as policy, publish for that specific hash...you know I'm honestly wondering if this is just something we need to start doing as an open source service?
loaph 2y ago
> If you're pulling in a package that has 400 dependencies, how the heck would you even competently check 10% of that surface area? At my place of work we use this great security too called Snyk. Definitely check it out /s

by gortok 2y ago

ziddoap 2y ago

>If you're pulling in a package that has 400 dependencies, how the heck would you even competently check 10% of that surface area? This would be where different security advice would apply: don't pull in a package that has 400 dependencies.

krainboltgreene 2y ago
Given the nature of software development and software developers, especially given American companies decide to value shareholder profits over programmer productivity, this might as well be effectively "You don't need to get vaccines, simply don't get sick from other people."
- nightpool 2y ago
  Out of curiosity, I've always meant to ask, are you related to the famous Geoguesser content creator in any way? It's a pretty distinctive last name.
  - krainboltgreene 2y ago
    I believe he might be a distant cousin. I've done some family tree searching myself and haven't found many things, since the Rainbolt side has mostly been scoundrels and vagabonds there aren't many details, but we do have a mountain that we named after ourselves after we stole it from natives.
- wyldberry 2y ago
  Things like this are suppose to be provenance of an organizations security engineering teams. Helping to ensure you don't ship something like this. It's also hard for them too because no one wants to force developers to re-implement already solved functionality.
  - krainboltgreene 2y ago
    I also have never met a security engineer that was eager to do that.
    - finnthehuman 2y ago
      > never met a security engineer that was eager to do that Of course not. We do the fun parts, and write tickets to make the dev team do the boring parts that we will later complain are not implemented to the quality standard we would have reached, had we done the work. That's the deal.
    - wyldberry 2y ago
      Late to reply, but yeah no one is eager to do it. Unfortunately being good at security means being really good at work that is boring, tedious, and not glamorous, which also measures poorly into OKRs and other facets of shipping culture. Unless the team has really strong leadership that can get the security engineer ladders divested from the SWE/SRE ladders. I literally just finished up writing up something that does supply chain provenance checking across 9 languages and still have a lot of edge cases to handle. It's not fun, but it's honest work.

chamomeal 2y ago

Wait how in the world does a React carousel component have over 400 deps…

KuhlMensch 2y ago
/giphy "first time?" meme
Sohcahtoa82 2y ago
Did you think the meme about node_modules having more gravity than a star was just a meme? It's very much based on reality. The npm ecosystem is just absolutely fucked.
tristor 2y ago
Because Javascript is a drug that makes developers stupid. It's almost trite at this point to comment on the obsession that Node has created with developers to reduce functionality to the smallest possible reusable parts, even trivial things, and publish them as packages, then to import and use those dependencies. The idea, in and of itself, is not terrible, but it's been taken to a logical extreme which is very much the definition of terrible.
- zero_shift 2y ago
  Nearly all of these look like demo projects. You're making inferences about an entire group of developers based on a meme plus a search over the very 'worst' offenders.
cloverich 2y ago
History of "micro dependencies" where many flexible utilities are split up into separate packages, such that many npm dependencies are a single function (ie rather than a package exporting ten methods, its ten separate dependencies). Then because there is no standard library, many reinventions of similar but incompatible utilities. etc.
zero_shift 2y ago
Do you mean https://www.npmjs.com/package/carousel-react https://www.npmjs.com/package/carousel-react? By the looks of it, this was published by someone 7 years ago as part of a personal project. Nothing uses it. Going through that list... they all look like personal projects, with no dependents, and a single release by a single person.

XorNot 2y ago

This is really where SELinux had the right idea overall: preclassifying files with data about their sensitivity, and denying access based on that, does adequately solve this problem (i.e. keeping npm installations away from id_rsa).

beardedwizard 2y ago
The issue with SElinux is usability. A company called intrinsic tried a similar "allowlist" approach to javascript based on the assumption that you could never control this sprawl and had to assume every package was malicious. I never saw the technology take off because generating the allowlist was of course error prone. im not sure what has to change in UX to make these approaches more palatable, but if you have to frequently allow 'good' behaviors, my experience is it never takes off.
- __MatrixMan__ 2y ago
  I think we need to to focus on empirical consensus rather than taking as authoritative some file which makes claims about what a particular piece of software will or won't do. So before running any code you'd hash it and ask your peers: "what do we think this does?" If it does something surprising, you roll back its effects (or maybe it was in a sandbox in the first place) and you update your peers so that next time they're not surprised. I keep saying "you" but this would just be part of calling a function, handled by a tool and only surfaced to the user when they ask or when the surprising thing happens. It could be a useful dataset both for maintainers and for people who want to better understand how to use the thing.
  - XorNot 2y ago
    This both is and isn't what SELinux does though: the point of SELinux is when you execute a binary, it runs with whatever context is assigned to it and is bounded by that context (or allowed transitions). This is super powerful to implement exactly that, but for whatever reason IMO it's constantly been half-assed on the UI front, because the best version of it isn't "detailed policy confinements for system software" but detailed confinements for user data (which was the original idea that conceived it at the NSA - the data model ultimately looks a lot like how classified data works). AFAIK the biggest problem is that you can't really do an ACL like configuration for it though - i.e. if I categorize all my SSH keys as type ssh_private_key_t, I'm not able to add an additional tag on that to grant targeted access to a specific program (which both does, and does not make sense - i.e. if I'm handing a program one private key but I think it might leak it...why am I doing that? Conversely in the real world we're bounding risk, so I should be able to do that - I don't think Multi-Category Security fixes this?). Basically "empirical consensus" is an SELinux policy, in fact you can generate one that way - run in permissive mode for an application type, collect the actions as policy, publish for that specific hash...you know I'm honestly wondering if this is just something we need to start doing as an open source service?

loaph 2y ago

> If you're pulling in a package that has 400 dependencies, how the heck would you even competently check 10% of that surface area? At my place of work we use this great security too called Snyk. Definitely check it out /s