3 ms·

I have mixed feelings here. On one hand do what you want, on the other hand you can already add https imports via package.json. Why in God's name would you no

I have mixed feelings here. On one hand do what you want, on the other hand you can already add https imports via package.json. Why in God's name would you not have a package.json. I think this would be awesome for hacking out prototypes, but if I saw this in production code I'd ether work to get it fixed or find a new job. Being reckless is fine in your spare time. It's not ok at work. My fear is this is going to push junior devs into sloppy practices.

sneak 5y ago
I have the distinct impression that whether you put the imports in package.json or in the source file itself, ~100% of the industry is engaging in sloppy practices now. I am terrified when trying to write secure es6. AIUI, when you add a module in go, the specific and exact version of the module is cryptographically locked in your project metadata. npm/yarn store the hashes in the lockfile but the package.json still uses those (usually) fuzzy matchers, and I'm not sure whether "npm i"/"yarn install" uses the lockfile exclusively by default. "npm help install" suggests that it uses package.json (which does not cryptographically secure the deps so that they match what you originally added) by default. (Additionally, tons of people install and deploy docker images by tag name alone, which is not cryptographically secure - different environment, same problem.) My mixed feelings about it are that we are slowly blurring the line between local and remote software, and pretty soon it will be nearly impossible to use most modern software in an offline environment (which is a hard requirement for certain security circumstances). Basically every single js developer in the world has granted Microsoft (owners of GitHub and NPM domains) the ability to remotely execute code on their machine at will. It's a lot of tooling and infrastructure to update and change in the event that the threat landscape changes significantly (e.g. war, national security mandates, etc).
- rectang 5y ago
  Manually auditing an update of potentially hundreds of packages when package-lock.json gets regenerated is so challenging that many projects won't do it — and for those projects, the cryptographic hashes offer limited value. To make industry-wide improvements, we need to share resources for auditing of packages. There are many such endeavors underway at various stages of maturity. But this feature doesn't move that ball forwards. From the comments: https://github.com/nodejs/node/pull/36328#issuecomment-736034792 https://github.com/nodejs/node/pull/36328#issuecomment-73603... > It is insecure because there is no signature of the original file. Anybody that can take control of a domain name can take control of a server. Downloaded arbitrary code can't be added to a pool of pre-validated packages, except insofar as you control the server and only make pre-validated packages available on it exclusively to your own services.
- 999900000999 5y ago
  You can use NPM offline. Setting up a enterprise mirror isn't hard. NPM, as far I can tell was not designed to have you run npm install every single time you deploy. People decided to do it anyway, I still remember the day NPM's SSL certs went down ( 2013 or 2014). It's like the internet broke overnight. It's a real catch 22. When you look for a magic npm package to save some time, you have no idea what's really in it unless you inspect all of it's code, and it's entire dependency tree. I guess you could build an solution to check for any vulnerabilities, but then you just move the problem elsewhere. Said ML tool would never be perfect
no_wizard 5y ago
Its also possible that this enables you to deploy all your assets prebuilt and optimized to a CDN? For Node apps running on services like fly.io this may be useful, since they're regionally distributed and their claim of running closest to the customers using it is at least partially true. This makes your deployed images (and therefore disk size needed) much smaller I agree that not having SRI as a requirement is a miss, however I see legitimate use cases here.

sneak 5y ago

I have the distinct impression that whether you put the imports in package.json or in the source file itself, ~100% of the industry is engaging in sloppy practices now. I am terrified when trying to write secure es6. AIUI, when you add a module in go, the specific and exact version of the module is cryptographically locked in your project metadata. npm/yarn store the hashes in the lockfile but the package.json still uses those (usually) fuzzy matchers, and I'm not sure whether "npm i"/"yarn install" uses the lockfile exclusively by default. "npm help install" suggests that it uses package.json (which does not cryptographically secure the deps so that they match what you originally added) by default. (Additionally, tons of people install and deploy docker images by tag name alone, which is not cryptographically secure - different environment, same problem.) My mixed feelings about it are that we are slowly blurring the line between local and remote software, and pretty soon it will be nearly impossible to use most modern software in an offline environment (which is a hard requirement for certain security circumstances). Basically every single js developer in the world has granted Microsoft (owners of GitHub and NPM domains) the ability to remotely execute code on their machine at will. It's a lot of tooling and infrastructure to update and change in the event that the threat landscape changes significantly (e.g. war, national security mandates, etc).

rectang 5y ago
Manually auditing an update of potentially hundreds of packages when package-lock.json gets regenerated is so challenging that many projects won't do it — and for those projects, the cryptographic hashes offer limited value. To make industry-wide improvements, we need to share resources for auditing of packages. There are many such endeavors underway at various stages of maturity. But this feature doesn't move that ball forwards. From the comments: https://github.com/nodejs/node/pull/36328#issuecomment-736034792 https://github.com/nodejs/node/pull/36328#issuecomment-73603... > It is insecure because there is no signature of the original file. Anybody that can take control of a domain name can take control of a server. Downloaded arbitrary code can't be added to a pool of pre-validated packages, except insofar as you control the server and only make pre-validated packages available on it exclusively to your own services.
999900000999 5y ago
You can use NPM offline. Setting up a enterprise mirror isn't hard. NPM, as far I can tell was not designed to have you run npm install every single time you deploy. People decided to do it anyway, I still remember the day NPM's SSL certs went down ( 2013 or 2014). It's like the internet broke overnight. It's a real catch 22. When you look for a magic npm package to save some time, you have no idea what's really in it unless you inspect all of it's code, and it's entire dependency tree. I guess you could build an solution to check for any vulnerabilities, but then you just move the problem elsewhere. Said ML tool would never be perfect

no_wizard 5y ago

Its also possible that this enables you to deploy all your assets prebuilt and optimized to a CDN? For Node apps running on services like fly.io this may be useful, since they're regionally distributed and their claim of running closest to the customers using it is at least partially true. This makes your deployed images (and therefore disk size needed) much smaller I agree that not having SRI as a requirement is a miss, however I see legitimate use cases here.