4 ms·

It's... almost like pulling random code from the internet is a liability and the people doing so need to eat the costs of doing so safely and not pull code that

It's... almost like pulling random code from the internet is a liability and the people doing so need to eat the costs of doing so safely and not pull code that cannot be pulled safety. Like, for example, evidence that the author actually takes security issues seriously and has a formal way to announce them. The reality here is that just grabbing and running random shit on clients or servers has _always_ been unsafe. The people not pinning and mirroring have gigantic exposure. Pinning and mirroring people have some exposure. None of them should be doing what they are doing now.

worik 5y ago
>The reality here is that just grabbing and running random shit on clients or servers has _always_ been unsafe That is what this whole catastrophic mess has been based on from day one. Do not use NPM for anything new. Let it die a natural death.
- foobiekr 5y ago
  It's not just NPM. It's no better to pull some github python repo into your server side unvetted and run it. The issue is that a broad swath of tech companies have thousands of instances of software that they've never even casually inspected running in user web browsers and in their back end servers, in contexts that are almost never locked down (network controls and segmentation, privilege reduction/separation, CSPs, etc.). We are one malicious party from a broad total disaster.
  - oauea 5y ago
    The difference is that your tooling doesn't suddenly decide to pull in a new version than the one you've tested with.
    - foobiekr 5y ago
      I know people who, in their jenkins jobs, just run git clones from the repos. They're not even managing versions. This is a really broad problem. Focusing on NPM, which I agree is a trashfire, is kind of missing the problem.
      - oauea 5y ago
        Tell them about requirements.txt, pip freeze & virtualenv. You can also curl | bash but that doesn't mean bash is to blame, because it doesn't encourage this bad behavior. NPM is literally built around this broken behavior.
        danenania 5y ago
        "Tell them about requirements.txt, pip freeze & virtualenv" NPM offers the same functionality with lock files.
        oauea 5y ago
        npm install would like to have a word with your lockfile.
        danenania 5y ago
        We're getting into minutiae here. Yes npm install will update the lock file if package.json conflicts. But it certainly does not update every time npm install is run if you use a lock file, which is what your earlier comment (and those of others) mistakenly imply. If you have ~1.0.0 in package.json and 1.0.11 specified in the lock file, but then bump package.json to ~1.0.12, yes npm will upgrade the package and then bump the dep in your lock file to 1.0.12. That seems fine?
        halostatue 5y ago
        This is not my experience with how most people specify their dependencies (and the tools use by default) If you have `^1.0.0` in package.json, the version mark is `^1.0.11` in the lock file, which means that a random `npm i` or `yarn install` will install `^1.0.12` in your lock file. I more or less said this yesterday[1], but the behaviour of `yarn install --frozen-lockfile` and `npm ci` should be the _default_ behaviour. The current behaviour is demonstrably dangerous. A lockfile should remain locked without explicit action by developers. [1]: https://news.ycombinator.com/item?id=29869859 https://news.ycombinator.com/item?id=29869859
    - speedgoose 5y ago
      That’s how you get tons of security vulnerabilities. It’s not a perfect solution but I rather have npm updating versions automatically, because developers are lazy and rarely do it manually.
- Gigachad 5y ago
  NPM is the model that almost all package managers have been based on for a while now. The cat is out of the bag and the benefits of the vast library of convenient packages has won over carefully selected but outdated distro repos.
  - datenarsch 5y ago
    Well other package managers don't automatically update packages like NPM does though but pin the exact version that you installed.
    - bastawhiz 5y ago
      This is absolutely not true at all. Go ahead and pipenv install a package.
      - dathinab 5y ago
        Python has probably the worst most miss designed package manager out there. I mean it doesn't even really have support for proper package versioning, instead it just magically hacks the environment. Which happens to work, but is also kinda a nightmare. I have no idea why python programmers still mostly accept that as a viable solution.
      - kayodelycaon 5y ago
        Python package management is without a doubt, the worst I’ve seen… not used… seen. Short of downloading individual jar files without the original source code.
  - dathinab 5y ago
    Many new package managers (e.g. cargo) have small differences which often have a massive impact for such situations. They are still not perfect, but they tend to know it and work on improving it (almost often slow). The problem tends to be more around missing proper CI setups and workflows(1) and similar. And naturally npm being very easy to use wrongly. (1): Lock versions, (shallow) review diffs of most dependency bumps, test and build in a sandbox, automatically check CSV/audit databases on frequent basis, don't automatically bump versions of release builds, etc., etc. > carefully selected but outdated distro repos. and also: - inconsistent between distros - sometimes long term unfixed security vulnarabilities - (more) incompatibilities between packages and distroes - unofficial patches to fix security vulnerabilities or compatibility, which not seldom cause future subtle problems, including security problems -problems to push important security fixes in time -often not language specific due to the high amount of work needed to properly maintain them - costly to operate - an additional attack-able link in the supply chain - often OS specific A distro based system is quite nice for distributing programs, but in my experience it's a nightmare for software packages. I mean just look at the endless problems distros have with packaging python, npm and shared objects. Instead I think most dependencies should always be bundled with the program (if anyone can rebuild if needed, i.e. open source) and distros should only package programs, not libraries. There are some exception. But like less then 10 on most Linux systems, and many could adept by having a well defined non C-FFI interface + bundled support library.
- jka 5y ago
  Setting a notification for empty GitHub search results on "filename:package.json modified-ago<=1h"...
SolarNet 5y ago
> Like, for example, evidence that the author actually takes security issues seriously and has a formal way to announce them. Personally I think there is a business model in there. "Curated" code releases/versions by a trusted third party you pay to review all the code. It would be a boring job, like being an auditor. Bonus points, you can pay an "ethical" one that then tries to get money to the OSS devs of libraries that their clients demand the most.
- foobiekr 5y ago
  This is hypothetically the redhat/monte vista/canonical business model, or part of it. They don't do deep curation though because they're not spending the money on it either, but at least they do some basic vetting. Which is apparently more than most of the coders out there.
dathinab 5y ago
> almost like pulling random code from the internet I would say blindly pulling _any_ code from _anywhere_ is a liability. No matter of weather it comes from or weather it's open source or a proprietary vendors library.

worik 5y ago

>The reality here is that just grabbing and running random shit on clients or servers has _always_ been unsafe That is what this whole catastrophic mess has been based on from day one. Do not use NPM for anything new. Let it die a natural death.

foobiekr 5y ago
It's not just NPM. It's no better to pull some github python repo into your server side unvetted and run it. The issue is that a broad swath of tech companies have thousands of instances of software that they've never even casually inspected running in user web browsers and in their back end servers, in contexts that are almost never locked down (network controls and segmentation, privilege reduction/separation, CSPs, etc.). We are one malicious party from a broad total disaster.
- oauea 5y ago
  The difference is that your tooling doesn't suddenly decide to pull in a new version than the one you've tested with.
  - foobiekr 5y ago
    I know people who, in their jenkins jobs, just run git clones from the repos. They're not even managing versions. This is a really broad problem. Focusing on NPM, which I agree is a trashfire, is kind of missing the problem.
    - oauea 5y ago
      Tell them about requirements.txt, pip freeze & virtualenv. You can also curl | bash but that doesn't mean bash is to blame, because it doesn't encourage this bad behavior. NPM is literally built around this broken behavior.
      - danenania 5y ago
        "Tell them about requirements.txt, pip freeze & virtualenv" NPM offers the same functionality with lock files.
        oauea 5y ago
        npm install would like to have a word with your lockfile.
        danenania 5y ago
        We're getting into minutiae here. Yes npm install will update the lock file if package.json conflicts. But it certainly does not update every time npm install is run if you use a lock file, which is what your earlier comment (and those of others) mistakenly imply. If you have ~1.0.0 in package.json and 1.0.11 specified in the lock file, but then bump package.json to ~1.0.12, yes npm will upgrade the package and then bump the dep in your lock file to 1.0.12. That seems fine?
        halostatue 5y ago
        This is not my experience with how most people specify their dependencies (and the tools use by default) If you have `^1.0.0` in package.json, the version mark is `^1.0.11` in the lock file, which means that a random `npm i` or `yarn install` will install `^1.0.12` in your lock file. I more or less said this yesterday[1], but the behaviour of `yarn install --frozen-lockfile` and `npm ci` should be the _default_ behaviour. The current behaviour is demonstrably dangerous. A lockfile should remain locked without explicit action by developers. [1]: https://news.ycombinator.com/item?id=29869859 https://news.ycombinator.com/item?id=29869859
  - speedgoose 5y ago
    That’s how you get tons of security vulnerabilities. It’s not a perfect solution but I rather have npm updating versions automatically, because developers are lazy and rarely do it manually.
Gigachad 5y ago
NPM is the model that almost all package managers have been based on for a while now. The cat is out of the bag and the benefits of the vast library of convenient packages has won over carefully selected but outdated distro repos.
- datenarsch 5y ago
  Well other package managers don't automatically update packages like NPM does though but pin the exact version that you installed.
  - bastawhiz 5y ago
    This is absolutely not true at all. Go ahead and pipenv install a package.
    - dathinab 5y ago
      Python has probably the worst most miss designed package manager out there. I mean it doesn't even really have support for proper package versioning, instead it just magically hacks the environment. Which happens to work, but is also kinda a nightmare. I have no idea why python programmers still mostly accept that as a viable solution.
    - kayodelycaon 5y ago
      Python package management is without a doubt, the worst I’ve seen… not used… seen. Short of downloading individual jar files without the original source code.
- dathinab 5y ago
  Many new package managers (e.g. cargo) have small differences which often have a massive impact for such situations. They are still not perfect, but they tend to know it and work on improving it (almost often slow). The problem tends to be more around missing proper CI setups and workflows(1) and similar. And naturally npm being very easy to use wrongly. (1): Lock versions, (shallow) review diffs of most dependency bumps, test and build in a sandbox, automatically check CSV/audit databases on frequent basis, don't automatically bump versions of release builds, etc., etc. > carefully selected but outdated distro repos. and also: - inconsistent between distros - sometimes long term unfixed security vulnarabilities - (more) incompatibilities between packages and distroes - unofficial patches to fix security vulnerabilities or compatibility, which not seldom cause future subtle problems, including security problems -problems to push important security fixes in time -often not language specific due to the high amount of work needed to properly maintain them - costly to operate - an additional attack-able link in the supply chain - often OS specific A distro based system is quite nice for distributing programs, but in my experience it's a nightmare for software packages. I mean just look at the endless problems distros have with packaging python, npm and shared objects. Instead I think most dependencies should always be bundled with the program (if anyone can rebuild if needed, i.e. open source) and distros should only package programs, not libraries. There are some exception. But like less then 10 on most Linux systems, and many could adept by having a well defined non C-FFI interface + bundled support library.
jka 5y ago
Setting a notification for empty GitHub search results on "filename:package.json modified-ago<=1h"...

SolarNet 5y ago

> Like, for example, evidence that the author actually takes security issues seriously and has a formal way to announce them. Personally I think there is a business model in there. "Curated" code releases/versions by a trusted third party you pay to review all the code. It would be a boring job, like being an auditor. Bonus points, you can pay an "ethical" one that then tries to get money to the OSS devs of libraries that their clients demand the most.

foobiekr 5y ago
This is hypothetically the redhat/monte vista/canonical business model, or part of it. They don't do deep curation though because they're not spending the money on it either, but at least they do some basic vetting. Which is apparently more than most of the coders out there.

dathinab 5y ago

> almost like pulling random code from the internet I would say blindly pulling _any_ code from _anywhere_ is a liability. No matter of weather it comes from or weather it's open source or a proprietary vendors library.