5 ms·

HTTPS doesn't magically protect you from the content of the package changing. They are different security mechanisms designed to defend against different threa

HTTPS doesn't magically protect you from the content of the package changing. They are different security mechanisms designed to defend against different threats. One answers the question: Was this the correct server I got this package from? The other answers the question: Does the package's hash match what I expect in my code? As to why you would want this, I've worked on several projects that take advantage of some things that pulling dependencies only from a local repository can give you. Take the recent Log4J vuln as an example. Immediately on seeing that vulnerability, I disable the JAR file, causing builds to fail wherever that dependency exists until the updated one is added as a dependency and used. From experience having to do dependency analysis on an old toothy codebase, it's sometimes simpler and more accurate to just let everything break and fix the breaking spots.

jeroenhd 5y ago
I understand that HTTPS doesn't protect you, and that's the reason why you'd normally add a hash. If your goal is to make the build fail for vulnerable applications, you can run a local repository with upstream proxying functionality like Nexus Repository and kill the package there. This won't let you kill production (but why would you want to kill it this way?) but it'll give you the same benefit without risking remote code execution.
- BeefWellington 5y ago
  If you understand HTTPS doesn't protect you, I'm unclear on your initial point. Any chance you can elaborate on precisely what you meant when you said: But what would be the point? Why would you load code over HTTPS if you're going to make it static anyway? If the code can't change dynamically, then you might as well put it next to the JS file on the filesystem. I think this is a terrible idea that can only end in misery but I can understand why they don't add integrity validation by default. I provided an example of why you would want to still load it remotely (specific situations where it's beneficial) rather than simply copying the code into the source repo, which you have also echoed, though seemingly suggesting that the example means you can do away with integrity checks? If my read on that is correct, then point then is to worry about the repository - wherever it lives - being poisoned, but still wanting some of the benefits of having a remote repository (such as centralized dependency management and control).
  - giaour 5y ago
    > I provided an example of why you would want to still load it remotely (specific situations where it's beneficial) rather than simply copying the code into the source repo Doesn't Node cache imports, though? I think this approach would protect you if you were running a script on a timer (thus triggering a fresh load at a regular interval) but not if you were running an Express server (which would only verify the hash of the remote library at application startup).

jeroenhd 5y ago

I understand that HTTPS doesn't protect you, and that's the reason why you'd normally add a hash. If your goal is to make the build fail for vulnerable applications, you can run a local repository with upstream proxying functionality like Nexus Repository and kill the package there. This won't let you kill production (but why would you want to kill it this way?) but it'll give you the same benefit without risking remote code execution.

BeefWellington 5y ago
If you understand HTTPS doesn't protect you, I'm unclear on your initial point. Any chance you can elaborate on precisely what you meant when you said: But what would be the point? Why would you load code over HTTPS if you're going to make it static anyway? If the code can't change dynamically, then you might as well put it next to the JS file on the filesystem. I think this is a terrible idea that can only end in misery but I can understand why they don't add integrity validation by default. I provided an example of why you would want to still load it remotely (specific situations where it's beneficial) rather than simply copying the code into the source repo, which you have also echoed, though seemingly suggesting that the example means you can do away with integrity checks? If my read on that is correct, then point then is to worry about the repository - wherever it lives - being poisoned, but still wanting some of the benefits of having a remote repository (such as centralized dependency management and control).
- giaour 5y ago
  > I provided an example of why you would want to still load it remotely (specific situations where it's beneficial) rather than simply copying the code into the source repo Doesn't Node cache imports, though? I think this approach would protect you if you were running a script on a timer (thus triggering a fresh load at a regular interval) but not if you were running an Express server (which would only verify the hash of the remote library at application startup).