9 ms·

URL-based imports aren't less secure. They just make an existing attack vector more obvious. Is NPM really keeping you safe? What happens if a package maintaine

URL-based imports aren't less secure. They just make an existing attack vector more obvious. Is NPM really keeping you safe? What happens if a package maintainer is compromised and the attacker adds malicious code? The fact that URL-based imports make you uncomfortable is good. Let that discomfort guide you to adopt some extra security measures to protect yourself from third-party dependency exploits

Normal_gaussian 6y ago
a note for many: yarn v2 provides '0-config' fully cachable dependencies (zips in lfs). This makes it possible to fully vet dependencies and enforce change approval and analysis in CI/CD.
- mkranjec 6y ago
  Exactly. Not to mention installs being insanely fast.
- gervwyk 6y ago
  I must chime in here. Yarn 2 is a fantastic experience!
- xrd 6y ago
  I didn't know about that regarding yarn 2. Is there a good link to read about this? I did a search for yarn 2 and didn't find that immediately.
  - Normal_gaussian 6y ago
    https://yarnpkg.com/ https://yarnpkg.com/ They don't do a great job of advertising the changes; take a look under features/zero-installs. The common practice is to still use yarnv1 as your global yarn, just do "yarn set version berry" inside your project to use v2. 0-config can be a breaking change - though I haven't had problems in a long time.
ivan888 6y ago
I would argue that NPM and other centralized package managers have the ability to add security: if npm made 2FA a requirement (or publicized the status of a package maintainer having 2FA enabled like GitHub does, which is perhaps a security concern itself), there would be some assurance that a maintainer is not compromised. If we are using URL-based imports, the scope of security assurances are much broader: an SSL certificate doesn't say anything about whether the current owner of a domain was the owner at the time of a dependency being safe. There is no one authority who we can expect to take swift (or even slow) action to remove malicious packages from being available on the myriad hosting protocols that are accessible through an environment like Deno
- ericlewis 6y ago
  don't get tricked into a slightly wrong URL
- goodoldneon 6y ago
  You can pick where you import from. Use github.com instead of nohackershere.ru
- mnahkies 6y ago
  I thought this was exposed by npm in package metadata? At the least it can be made a requirement for packages in the case of multiple people with publishing access that everyone uses 2fa
- WorldMaker 6y ago
  Every time you fetch a package from NPM you are accessing that code from a URL (at npmjs.com) and then caching that locally. Deno is just eliminating the middleman. If you still trust npmjs.com for source code delivery you could continue to do that. What it isn't eliminating is the ability to define "local" caches. Just because you are importing everything from URLs doesn't mean that they can't all be URLs that you directly control. You don't have to use CDN-like URLs in Production, you can entirely copy and paste all the modules you need onto a server you control and URL scheme that you maintain. There will still possibly be good uses of caching automation in Deno (once people get bored with xcopy/robocopy/cp -r/rsync scripts), but it will likely seem a return to more bower-like tools rather than necessarily full blown packager npm-like tools. (ETA: Or proxy services like GitHub Artifacts that pull an upstream source for you and rehost it on controlled URLs with some additional security checks.)
dmitryminkovsky 6y ago
> Is NPM really keeping you safe? I wish there was something like Docker Hub's automated builds in the Node world because the way NPM works right now, what comes from NPM is an unknown. The only thing you know is if you download a specific version once, you'll always get that same version again, unless it's invalidated. Otherwise, whatever the package author wants to upload and include, that's what you get and you can't know that what you're seeing in some Git commit is what's running in your application. I wish that was the state of the art.
- gervwyk 6y ago
  THIS! I cannot believe that these is still no auto hash validator thing between git and npm. Feels like npm should force a commit containing hash for the current version on every publish or something. How can we make this happen?
  - dmitryminkovsky 6y ago
    It would have to be some kind of integrated CI build system thing that builds the product in a container. Seems like they have no incentive to offer that given that they totally own JS packages.

Normal_gaussian 6y ago

a note for many: yarn v2 provides '0-config' fully cachable dependencies (zips in lfs). This makes it possible to fully vet dependencies and enforce change approval and analysis in CI/CD.

mkranjec 6y ago
Exactly. Not to mention installs being insanely fast.
gervwyk 6y ago
I must chime in here. Yarn 2 is a fantastic experience!
xrd 6y ago
I didn't know about that regarding yarn 2. Is there a good link to read about this? I did a search for yarn 2 and didn't find that immediately.
- Normal_gaussian 6y ago
  https://yarnpkg.com/ https://yarnpkg.com/ They don't do a great job of advertising the changes; take a look under features/zero-installs. The common practice is to still use yarnv1 as your global yarn, just do "yarn set version berry" inside your project to use v2. 0-config can be a breaking change - though I haven't had problems in a long time.

ivan888 6y ago

I would argue that NPM and other centralized package managers have the ability to add security: if npm made 2FA a requirement (or publicized the status of a package maintainer having 2FA enabled like GitHub does, which is perhaps a security concern itself), there would be some assurance that a maintainer is not compromised. If we are using URL-based imports, the scope of security assurances are much broader: an SSL certificate doesn't say anything about whether the current owner of a domain was the owner at the time of a dependency being safe. There is no one authority who we can expect to take swift (or even slow) action to remove malicious packages from being available on the myriad hosting protocols that are accessible through an environment like Deno

ericlewis 6y ago
don't get tricked into a slightly wrong URL
goodoldneon 6y ago
You can pick where you import from. Use github.com instead of nohackershere.ru
mnahkies 6y ago
I thought this was exposed by npm in package metadata? At the least it can be made a requirement for packages in the case of multiple people with publishing access that everyone uses 2fa
WorldMaker 6y ago
Every time you fetch a package from NPM you are accessing that code from a URL (at npmjs.com) and then caching that locally. Deno is just eliminating the middleman. If you still trust npmjs.com for source code delivery you could continue to do that. What it isn't eliminating is the ability to define "local" caches. Just because you are importing everything from URLs doesn't mean that they can't all be URLs that you directly control. You don't have to use CDN-like URLs in Production, you can entirely copy and paste all the modules you need onto a server you control and URL scheme that you maintain. There will still possibly be good uses of caching automation in Deno (once people get bored with xcopy/robocopy/cp -r/rsync scripts), but it will likely seem a return to more bower-like tools rather than necessarily full blown packager npm-like tools. (ETA: Or proxy services like GitHub Artifacts that pull an upstream source for you and rehost it on controlled URLs with some additional security checks.)

dmitryminkovsky 6y ago

> Is NPM really keeping you safe? I wish there was something like Docker Hub's automated builds in the Node world because the way NPM works right now, what comes from NPM is an unknown. The only thing you know is if you download a specific version once, you'll always get that same version again, unless it's invalidated. Otherwise, whatever the package author wants to upload and include, that's what you get and you can't know that what you're seeing in some Git commit is what's running in your application. I wish that was the state of the art.

gervwyk 6y ago
THIS! I cannot believe that these is still no auto hash validator thing between git and npm. Feels like npm should force a commit containing hash for the current version on every publish or something. How can we make this happen?
- dmitryminkovsky 6y ago
  It would have to be some kind of integrated CI build system thing that builds the product in a container. Seems like they have no incentive to offer that given that they totally own JS packages.