4 ms·

The people in the Github thread advocating for this feature seem to be pushing really hard on the point that this isn't any more insecure than NPM already is. B

The people in the Github thread advocating for this feature seem to be pushing really hard on the point that this isn't any more insecure than NPM already is. But that's myopic. That's like saying that the lock is broken on the second floor window of your house, so you may as well unlock all the other windows. If a junior developer working for me proposed something like this I would pull them away from the computer and have a long coffee chat with them about basic architecture principles. Yes, we know there are problems with NPM. But why broaden the possible attack surface area by introducing another kind-of-sort-of-equivalent means of remote module loading? Now you're just going to have to spend time hardening two systems instead of one. At the end of the day this just feels like a misguided attempt to try and recapture some sense of dynamism from Deno. But if I wanted dynamism, I'd use Deno, with all of its pubescent awkwardness. I'm using Node.js stable for a reason. I spend a lot of cycles trying to defend Node from its many (often reasonable) detractors, and things like this make me feel like I'm wasting my breath...

encryptluks2 5y ago
- junon 5y ago
  Lul what? First of all, this tone is completely against the HN guidelines, so take your flag. Second of all, centralization is not often a part of a security model. Usually in such cases where availability is a concern you have a mirror set up, which is ridiculously easy to do with CouchDB and completely nullifies your arrogant point. Get off your high horse.
  - encryptluks2 5y ago
- notpachet 5y ago
  My comment wasn't really about the merits of central authorities vs multiple authorities (although I would fall on the side of preferring a single package repository than having to worry about many of them). It was about having two equivalent mechanisms for solving the remote-code-loading problem, regardless of where you're actually loading it from.
wperron 5y ago
Hi, I'm one of those people in the PR advocating for this change :) I think you may have missed the point of comparing the security aspects to NPM. By saying "it's no less secure" it's not saying "well it's just as bad, so what's the point?", but rather "given that it doesn't introduce any more vulnerabilities, what does this model unlock for us?" HN comments probably aren't the best place to go in-depth on this topic, but just off the top of my head, HTTPS imports allow a greater detachment from a centralized registry, something we're seeing used a lot in the Go ecosystem, and we're moving server-side JavaScript closer to how browser JavaScript works, which is a good thing for anyone using the language, as it reduces friction across the board. This might not be something obvious for people working mostly/only on the backend, in which case those frictions aren't as apparent, but they are there nonetheless.
- danShumway 5y ago
  > HTTPS imports allow a greater detachment from a centralized registry, I know that the people advocating for this are smart, I know you're being thoughtful about this, so forgive the simplistic question, but every package manager I'm aware of for NodeJS already supports this. Can't people already import npm dependencies from arbitrary URLs without signing or attaching anything to the npm repository? And the other thought that jumps into my mind is, if people aren't doing that with npm that even though it's well-supported, that might be a signal that there are problems with the model of using arbitrary URLs for dependencies that make it less attractive overall to developers -- and I'm not sure how ES Imports using URLs would change or fix any of that.
- notpachet 5y ago
  > given that it doesn't introduce any more vulnerabilities I think this is where we are in disagreement. You're adding code to Node core in order to support this, which opens the door to new vulnerabilities (bugs) by definition, because people make mistakes. Now you will have two code systems to scrutinize and maintain that are doing essentially the same thing. I don't think the arguably-slightly-better ergonomics of HTTPS imports justifies the increased risk.

encryptluks2 5y ago

junon 5y ago
Lul what? First of all, this tone is completely against the HN guidelines, so take your flag. Second of all, centralization is not often a part of a security model. Usually in such cases where availability is a concern you have a mirror set up, which is ridiculously easy to do with CouchDB and completely nullifies your arrogant point. Get off your high horse.
- encryptluks2 5y ago
notpachet 5y ago
My comment wasn't really about the merits of central authorities vs multiple authorities (although I would fall on the side of preferring a single package repository than having to worry about many of them). It was about having two equivalent mechanisms for solving the remote-code-loading problem, regardless of where you're actually loading it from.

wperron 5y ago

Hi, I'm one of those people in the PR advocating for this change :) I think you may have missed the point of comparing the security aspects to NPM. By saying "it's no less secure" it's not saying "well it's just as bad, so what's the point?", but rather "given that it doesn't introduce any more vulnerabilities, what does this model unlock for us?" HN comments probably aren't the best place to go in-depth on this topic, but just off the top of my head, HTTPS imports allow a greater detachment from a centralized registry, something we're seeing used a lot in the Go ecosystem, and we're moving server-side JavaScript closer to how browser JavaScript works, which is a good thing for anyone using the language, as it reduces friction across the board. This might not be something obvious for people working mostly/only on the backend, in which case those frictions aren't as apparent, but they are there nonetheless.

danShumway 5y ago
> HTTPS imports allow a greater detachment from a centralized registry, I know that the people advocating for this are smart, I know you're being thoughtful about this, so forgive the simplistic question, but every package manager I'm aware of for NodeJS already supports this. Can't people already import npm dependencies from arbitrary URLs without signing or attaching anything to the npm repository? And the other thought that jumps into my mind is, if people aren't doing that with npm that even though it's well-supported, that might be a signal that there are problems with the model of using arbitrary URLs for dependencies that make it less attractive overall to developers -- and I'm not sure how ES Imports using URLs would change or fix any of that.
notpachet 5y ago
> given that it doesn't introduce any more vulnerabilities I think this is where we are in disagreement. You're adding code to Node core in order to support this, which opens the door to new vulnerabilities (bugs) by definition, because people make mistakes. Now you will have two code systems to scrutinize and maintain that are doing essentially the same thing. I don't think the arguably-slightly-better ergonomics of HTTPS imports justifies the increased risk.