5 ms·

This is off by default due to security concerns but can be turned on with a flag. It's mainly in the community feedback phase so if there is anything you want t

by inglor 5y ago

This is off by default due to security concerns but can be turned on with a flag. It's mainly in the community feedback phase so if there is anything you want to tell Node (be it "I want this!" or "This is a bad idea" - please do)

Andrex 5y ago
My layman's take is that it seems very similar to Log4j's vulnerability, but I don't really know for sure.
- oauea 5y ago
  Please explain why you think that, because it seems completely unrelated and off-topic.
  - moritonal 5y ago
    Bit harsh? Log4j was caused by a URL leading to bad code being imported. This let's you import code via a URL, seems quite similar?
    - sodality2 5y ago
      Log4j was caused when arbitrary log strings were interpreted as code imports. In this case the flag has to be manually set and the code manually added as a dependency.
    - anamexis 5y ago
      The Log4j vulnerability allowed unsafe user input to trigger loading of arbitrary code. Basically every dependency manager out there will allow you to load "bad code" from a URL.
      - tobyhinloopen 5y ago
        Log4j is no dependency manager
        anamexis 5y ago
        No, it's not, but this new Node.js feature is for loading dependencies
mitchellst 5y ago
Longtime node.js developer... I don't think we need this, and I don't think it's a good idea to add. The feature is _strange._ Which we know because it's behind a flag, i.e., it will have low utilization. It defies conventions—because the convention is to use a registry for packages. And it presents significant security concerns. (Which I don't really have to explain, as they're already cited as the reason to put it behind a flag.) Use of this feature seems like something you might see once in a career. (Indeed, I've seen a similar thing in another language employed only once... AND THERE WERE OTHER WAYS for that developer to have designed that system that would not have been so vulnerable.) When you see it, do you recognize what it is, understand and evaluate the risks it poses? Do you validate that the library sitting on the other side hasn't been taken over by a malicious actor? Do you validate that the library on the other side has up-to-date dependencies? If so, on what cadence do you do this, realistically? All the security tooling progress we've made (npm audit, etc.) seems shot in the foot by this. And I get that these concerns aren't dispositive on their own. I just don't see the argument on the other side that clearly. Is there some class of application that people really want to write in node that can't be written for lacking this? Do we really think this is a pattern that would be employed in well-made, secure codebases? I don't see the argument. Like I said, I've seen a feature like this used in another language. But I haven't seen it needed for any real application. I love me some good node ugly hacks. Still, the language features should be nudging us to write good software.
- encryptluks2 5y ago
  Central authority != Good software. You are essentially advocating to provide a single point of failure that can and will be abused by nation-state hackers who just have to find one popular package and compromise the developer.
  - mitchellst 5y ago
    The argument is less about central authority than standard process. You don't have to use the official NPM registry. The point is that having a pipeline for modules with established conventions and automated means of audits and visibility on the dependency is a net good. Yes, there is such a thing as a supply chain attack. But even when that happens, the community puts out the call to patch immediately and points a finger at the offending package. Your HTTPS import from a random URL could fail silently. While NPM is a big target for supply chain attack, they know they are, so there are a lot of eyes on it. Not so with your HTTPS import.
pimterry 5y ago
In terms of feedback, there's an issue thread here covering some points already: https://github.com/nodejs/node/issues/41920 https://github.com/nodejs/node/issues/41920
sdflhasjd 5y ago
I recall when I was a completely PHP n00b (babbys first programming language), I might encounter an issue and search for the error on expertsexchange. Some of the answers would be really complicated, but there'd be that one answer: Just edit your php.ini and change `dangerous_option_you_will_die=true` - wow, such an easy fix. I'd know better later, but I'd still find horrendous options like these enabled in real software I would come accross in my professional career.
forty 5y ago
I have been doing nodejs backend developpement for the past 10 years. I'm not sure why we would need that honestly. Looks like it could create some mess if packages on npm all start importing files from random servers. Suddenly your CI relies on many servers to be up. And I don't know what's the problem with declaring things in package.json.
danShumway 5y ago
All of the things that make this enticing as a feature are large security risks, and the less risky version that people are pitching me doesn't have any of the enticing features. What people are pitching me on is the idea that these wouldn't be dynamic imports. They're saying they wouldn't be fetched during runtime, they'd be fetched before. They're saying they would be pinned. Well, you're describing a package system like npm. And for those purposes, as a way of defining static packages that get installed before runtime and can't be dynamically swapped out by the application -- npm is better than the system being proposed. The only way this would actually be interesting is if they were actually dynamic imports, but having them be dynamic imports would be very insecure. And for declarative imports that can be statically analyzed, this is inferior syntax to what we already have and encourages worse developer habits. Some problems: 1. Updating dependencies is harder, because imports across multiple files have to be synced. If a junior developer imports `https://lodash.com/v4 https://lodash.com/v4` in two files and later someone changes that to be `http://lodash.com/v5 http://lodash.com/v5` in one file, now I have dependency mismatches. The existing system doesn't have this problem because my dependencies are in one place. 2. Finding out which dependencies I'm using is harder. Maybe there's another tool that lists out all of the imports, that would be handy. But also, maybe the dependencies are all in one file with the requested version numbers right next to them. That seems a lot more convenient. 3. This forces me to actually run the Node program to install the dependencies, and it forces me to actually import them in a file before they'll be fetched. This is cumbersome, it would be good to be able to list out dependencies before they ever get imported, say for boilerplate imports that are used in lots of projects. 4. People have pointed out the lack of pinning. All of this is inferior to having all of the imports in one file that you can specify, maintain, and update without running the program or using an analyzer. I don't understand what the benefit is or why I should care about an import system that is just as inflexible as the current npm/Yarn package manager setup, but that also has what seems to be worse syntax and makes it harder for me to know what packages are being imported. I wish I understood more what problem this proposed syntax was actually trying to solve. I've read through the entire thread and I still don't understand why people want this. People in the Github thread are reassuring readers that this could work exactly the same way as node_modules. That's great, but if that's the case, what is the problem with node_modules that is prompting us to build a second system that is less organized and less explicit about what gets imported? We can already import URLs with both npm and Yarn. That's not a new feature, the only new feature is that now the URLs are spread across the entire codebase.

by inglor 5y ago

Andrex 5y ago

My layman's take is that it seems very similar to Log4j's vulnerability, but I don't really know for sure.

oauea 5y ago
Please explain why you think that, because it seems completely unrelated and off-topic.
- moritonal 5y ago
  Bit harsh? Log4j was caused by a URL leading to bad code being imported. This let's you import code via a URL, seems quite similar?
  - sodality2 5y ago
    Log4j was caused when arbitrary log strings were interpreted as code imports. In this case the flag has to be manually set and the code manually added as a dependency.
  - anamexis 5y ago
    The Log4j vulnerability allowed unsafe user input to trigger loading of arbitrary code. Basically every dependency manager out there will allow you to load "bad code" from a URL.
    - tobyhinloopen 5y ago
      Log4j is no dependency manager
      - anamexis 5y ago
        No, it's not, but this new Node.js feature is for loading dependencies

mitchellst 5y ago

Longtime node.js developer... I don't think we need this, and I don't think it's a good idea to add. The feature is _strange._ Which we know because it's behind a flag, i.e., it will have low utilization. It defies conventions—because the convention is to use a registry for packages. And it presents significant security concerns. (Which I don't really have to explain, as they're already cited as the reason to put it behind a flag.) Use of this feature seems like something you might see once in a career. (Indeed, I've seen a similar thing in another language employed only once... AND THERE WERE OTHER WAYS for that developer to have designed that system that would not have been so vulnerable.) When you see it, do you recognize what it is, understand and evaluate the risks it poses? Do you validate that the library sitting on the other side hasn't been taken over by a malicious actor? Do you validate that the library on the other side has up-to-date dependencies? If so, on what cadence do you do this, realistically? All the security tooling progress we've made (npm audit, etc.) seems shot in the foot by this. And I get that these concerns aren't dispositive on their own. I just don't see the argument on the other side that clearly. Is there some class of application that people really want to write in node that can't be written for lacking this? Do we really think this is a pattern that would be employed in well-made, secure codebases? I don't see the argument. Like I said, I've seen a feature like this used in another language. But I haven't seen it needed for any real application. I love me some good node ugly hacks. Still, the language features should be nudging us to write good software.

encryptluks2 5y ago
Central authority != Good software. You are essentially advocating to provide a single point of failure that can and will be abused by nation-state hackers who just have to find one popular package and compromise the developer.
- mitchellst 5y ago
  The argument is less about central authority than standard process. You don't have to use the official NPM registry. The point is that having a pipeline for modules with established conventions and automated means of audits and visibility on the dependency is a net good. Yes, there is such a thing as a supply chain attack. But even when that happens, the community puts out the call to patch immediately and points a finger at the offending package. Your HTTPS import from a random URL could fail silently. While NPM is a big target for supply chain attack, they know they are, so there are a lot of eyes on it. Not so with your HTTPS import.

pimterry 5y ago

In terms of feedback, there's an issue thread here covering some points already: https://github.com/nodejs/node/issues/41920 https://github.com/nodejs/node/issues/41920

sdflhasjd 5y ago

I recall when I was a completely PHP n00b (babbys first programming language), I might encounter an issue and search for the error on expertsexchange. Some of the answers would be really complicated, but there'd be that one answer: Just edit your php.ini and change `dangerous_option_you_will_die=true` - wow, such an easy fix. I'd know better later, but I'd still find horrendous options like these enabled in real software I would come accross in my professional career.

forty 5y ago

I have been doing nodejs backend developpement for the past 10 years. I'm not sure why we would need that honestly. Looks like it could create some mess if packages on npm all start importing files from random servers. Suddenly your CI relies on many servers to be up. And I don't know what's the problem with declaring things in package.json.

danShumway 5y ago

All of the things that make this enticing as a feature are large security risks, and the less risky version that people are pitching me doesn't have any of the enticing features. What people are pitching me on is the idea that these wouldn't be dynamic imports. They're saying they wouldn't be fetched during runtime, they'd be fetched before. They're saying they would be pinned. Well, you're describing a package system like npm. And for those purposes, as a way of defining static packages that get installed before runtime and can't be dynamically swapped out by the application -- npm is better than the system being proposed. The only way this would actually be interesting is if they were actually dynamic imports, but having them be dynamic imports would be very insecure. And for declarative imports that can be statically analyzed, this is inferior syntax to what we already have and encourages worse developer habits. Some problems: 1. Updating dependencies is harder, because imports across multiple files have to be synced. If a junior developer imports `https://lodash.com/v4 https://lodash.com/v4` in two files and later someone changes that to be `http://lodash.com/v5 http://lodash.com/v5` in one file, now I have dependency mismatches. The existing system doesn't have this problem because my dependencies are in one place. 2. Finding out which dependencies I'm using is harder. Maybe there's another tool that lists out all of the imports, that would be handy. But also, maybe the dependencies are all in one file with the requested version numbers right next to them. That seems a lot more convenient. 3. This forces me to actually run the Node program to install the dependencies, and it forces me to actually import them in a file before they'll be fetched. This is cumbersome, it would be good to be able to list out dependencies before they ever get imported, say for boilerplate imports that are used in lots of projects. 4. People have pointed out the lack of pinning. All of this is inferior to having all of the imports in one file that you can specify, maintain, and update without running the program or using an analyzer. I don't understand what the benefit is or why I should care about an import system that is just as inflexible as the current npm/Yarn package manager setup, but that also has what seems to be worse syntax and makes it harder for me to know what packages are being imported. I wish I understood more what problem this proposed syntax was actually trying to solve. I've read through the entire thread and I still don't understand why people want this. People in the Github thread are reassuring readers that this could work exactly the same way as node_modules. That's great, but if that's the case, what is the problem with node_modules that is prompting us to build a second system that is less organized and less explicit about what gets imported? We can already import URLs with both npm and Yarn. That's not a new feature, the only new feature is that now the URLs are spread across the entire codebase.