7 ms·

> URL-based imports (no need for NPM) What happens when there is the next Codehaus-like shutdown, and so much source code just won't work? Or when a bad actor

> URL-based imports (no need for NPM) What happens when there is the next Codehaus-like shutdown, and so much source code just won't work? Or when a bad actor takes control of a domain that commonly hosted packages (perhaps through completely legitimate means, such as registration expiration), can get a completely legitimate SSL certificate for it, and responds to requests for packages with malicious code? I think the abstraction, and to some degree the centralization, of package management is generally a good thing

pknopf 6y ago
There will likely be some kind of npm at some point.
- jhgb 6y ago
  If the goal is to get rid of NPM, why would you add another one in the future?
  - afiori 6y ago
    The goal is not to eliminate npm, but to decouple it from the runtime itself
- forty 6y ago
  Yes, i think recreating an npm kind of central place for your project dependencies seems almost required if you want to avoid depending on a different version of a lib in each file of your project. I cannot understand the benefit of this scheme honestly. I would have preferred they fix something npm is lacking, like adding the ability to sign packages
searchableguy 6y ago
deno has a lock file like other package managers. If you use a lock file, deno will refuse to run if the file has been modified. Deno caches everything offline and only reloads if you use --reload flag. I would recommend going through the manual to learn more about deno workflow. https://deno.land/manual https://deno.land/manual
jansommer 6y ago
"Deno can store and check subresource integrity for modules using a small JSON file." - https://deno.land/manual/linking_to_external_code/integrity_checking https://deno.land/manual/linking_to_external_code/integrity_...
- ivan888 6y ago
  Unfortunately this won't help those who add dependencies based on shared snippets, without the context of a project. Or the innocent mistake (or choice?) of not checking the lock file into version control. But yes good point, existing projects that have checked in the integrity file will be safe against future malicious modifications of the resource
  - searchableguy 6y ago
    > Unfortunately this won't help those who add dependencies based on shared snippets, without the context of a project Could you expand on this? Any examples would be appreciated.
    - ivan888 6y ago
      Code examples abound on Stack Overflow, GitHub Gist, blog posts, etc. These may contain direct URL dependencies. Example guiding users to include a Maven dependency: https://www.baeldung.com/guava-mapmaker#map-maker https://www.baeldung.com/guava-mapmaker#map-maker There is some degree of assurance that this dependency won't last long in the Maven central repo, or any other user configured repository, if it contained malicious code. Obviously it is not foolproof and incidents happen, but without a centralized authority for package management, there is much less assurance that a package is not malicious
      - searchableguy 6y ago
        I find your concern valid. Deno makes it easy to import from temporary places. However, this wouldn't be solved by having a centralized registry or a package manager like npm. Npm can install from git repos and registries other than npmjs. Having a package on npm by its own doesn't make it any less malicious. A solution would be to enforce registries you can import from and fail if it's outside that.
sod 6y ago
Answered in https://deno.land/manual@v1.8.2/linking_to_external_code#but-what-if-the-host-of-the-url-goes-down-the-source-won#39t-be-available https://deno.land/manual@v1.8.2/linking_to_external_code#but... Also: Nobody prevents you from using a package manager anyway. Just because you can use urls in imports doesn't mean you have to. But it is very convenient that deno downloads exactly the code that is imported. A package manager will always just throw everything at you. Some packages in node.js try to fix this by splitting the project into submodules like @babel/core, @babel/env, .... But that made installing dependencies worse. Just let deno figure out what is required is way more elegant IMO.
- nawgz 6y ago
  Not sure I understand, are you implying Deno does automatic tree-shaking on package imports? If not, how does "deno download exactly the code that is imported" and not just a whole package? Also, from your link: "In Node this is done by checking node_modules into source control. In Deno this is done by pointing $DENO_DIR to some project-local directory at runtime, and similarly checking that into source control:" I disagree with this. In my opinion, this is done by using a pull-through cache that caches every package developers request and so inherently has a cache of the packages that will go to production. Is it possible to do this in deno today? I don't really get that sense.
  - WorldMaker 6y ago
    > Not sure I understand, are you implying Deno does automatic tree-shaking on package imports? If not, how does "deno download exactly the code that is imported" and not just a whole package? npm install copies in to your node_modules an entire zip/tarball package. Deno uses ES2015+ module syntax and it's only going to grab the JS files that are imported (or imported by imports). So it "naturally" tree shakes at the file level, and doesn't have a concept of a "package" in the same way. It's not directly going to tree shake inside of single file boundaries in the way that a major bundler/packager might (though the V8 JIT should still sort of indirectly compensate). So yeah, if the package is published as just a single (M)JS file it will still get entirely downloaded by Deno, but if the modules are split across multiple files, Deno will only download the ones that are directly or indirectly imported (and will have no idea of the remainder of the files in the "package"). > I disagree with this. In my opinion, this is done by using a pull-through cache that caches every package developers request and so inherently has a cache of the packages that will go to production. > Is it possible to do this in deno today? I don't really get that sense. Yes, because URLs are just URLs, you could always have a Proxy service running at a URL that knows how to request the packages from upstream. https://jsproxy.mydomain.example.com/lodash/v1.1/module.js https://jsproxy.mydomain.example.com/lodash/v1.1/module.js could be simple caching proxy that knows how to get lodash from upstream if it doesn't have the requested version cached (or sends a 404 error if it isn't allowed to cache a specific version or whatever).
goodoldneon 6y ago
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

pknopf 6y ago

There will likely be some kind of npm at some point.

jhgb 6y ago
If the goal is to get rid of NPM, why would you add another one in the future?
- afiori 6y ago
  The goal is not to eliminate npm, but to decouple it from the runtime itself
forty 6y ago
Yes, i think recreating an npm kind of central place for your project dependencies seems almost required if you want to avoid depending on a different version of a lib in each file of your project. I cannot understand the benefit of this scheme honestly. I would have preferred they fix something npm is lacking, like adding the ability to sign packages

searchableguy 6y ago

deno has a lock file like other package managers. If you use a lock file, deno will refuse to run if the file has been modified. Deno caches everything offline and only reloads if you use --reload flag. I would recommend going through the manual to learn more about deno workflow. https://deno.land/manual https://deno.land/manual

jansommer 6y ago

"Deno can store and check subresource integrity for modules using a small JSON file." - https://deno.land/manual/linking_to_external_code/integrity_checking https://deno.land/manual/linking_to_external_code/integrity_...

ivan888 6y ago
Unfortunately this won't help those who add dependencies based on shared snippets, without the context of a project. Or the innocent mistake (or choice?) of not checking the lock file into version control. But yes good point, existing projects that have checked in the integrity file will be safe against future malicious modifications of the resource
- searchableguy 6y ago
  > Unfortunately this won't help those who add dependencies based on shared snippets, without the context of a project Could you expand on this? Any examples would be appreciated.
  - ivan888 6y ago
    Code examples abound on Stack Overflow, GitHub Gist, blog posts, etc. These may contain direct URL dependencies. Example guiding users to include a Maven dependency: https://www.baeldung.com/guava-mapmaker#map-maker https://www.baeldung.com/guava-mapmaker#map-maker There is some degree of assurance that this dependency won't last long in the Maven central repo, or any other user configured repository, if it contained malicious code. Obviously it is not foolproof and incidents happen, but without a centralized authority for package management, there is much less assurance that a package is not malicious
    - searchableguy 6y ago
      I find your concern valid. Deno makes it easy to import from temporary places. However, this wouldn't be solved by having a centralized registry or a package manager like npm. Npm can install from git repos and registries other than npmjs. Having a package on npm by its own doesn't make it any less malicious. A solution would be to enforce registries you can import from and fail if it's outside that.

sod 6y ago

Answered in https://deno.land/manual@v1.8.2/linking_to_external_code#but-what-if-the-host-of-the-url-goes-down-the-source-won#39t-be-available https://deno.land/manual@v1.8.2/linking_to_external_code#but... Also: Nobody prevents you from using a package manager anyway. Just because you can use urls in imports doesn't mean you have to. But it is very convenient that deno downloads exactly the code that is imported. A package manager will always just throw everything at you. Some packages in node.js try to fix this by splitting the project into submodules like @babel/core, @babel/env, .... But that made installing dependencies worse. Just let deno figure out what is required is way more elegant IMO.

nawgz 6y ago
Not sure I understand, are you implying Deno does automatic tree-shaking on package imports? If not, how does "deno download exactly the code that is imported" and not just a whole package? Also, from your link: "In Node this is done by checking node_modules into source control. In Deno this is done by pointing $DENO_DIR to some project-local directory at runtime, and similarly checking that into source control:" I disagree with this. In my opinion, this is done by using a pull-through cache that caches every package developers request and so inherently has a cache of the packages that will go to production. Is it possible to do this in deno today? I don't really get that sense.
- WorldMaker 6y ago
  > Not sure I understand, are you implying Deno does automatic tree-shaking on package imports? If not, how does "deno download exactly the code that is imported" and not just a whole package? npm install copies in to your node_modules an entire zip/tarball package. Deno uses ES2015+ module syntax and it's only going to grab the JS files that are imported (or imported by imports). So it "naturally" tree shakes at the file level, and doesn't have a concept of a "package" in the same way. It's not directly going to tree shake inside of single file boundaries in the way that a major bundler/packager might (though the V8 JIT should still sort of indirectly compensate). So yeah, if the package is published as just a single (M)JS file it will still get entirely downloaded by Deno, but if the modules are split across multiple files, Deno will only download the ones that are directly or indirectly imported (and will have no idea of the remainder of the files in the "package"). > I disagree with this. In my opinion, this is done by using a pull-through cache that caches every package developers request and so inherently has a cache of the packages that will go to production. > Is it possible to do this in deno today? I don't really get that sense. Yes, because URLs are just URLs, you could always have a Proxy service running at a URL that knows how to request the packages from upstream. https://jsproxy.mydomain.example.com/lodash/v1.1/module.js https://jsproxy.mydomain.example.com/lodash/v1.1/module.js could be simple caching proxy that knows how to get lodash from upstream if it doesn't have the requested version cached (or sends a 404 error if it isn't allowed to cache a specific version or whatever).

goodoldneon 6y ago

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