4 ms·

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

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.
- ericlewis 6y ago
  if you can magically copy and paste in code that also includes a dependency then you might have just screwed yourself if you didn't read the code of said dep (or even if you did, maybe you missed something) if it just looks like a comment then maybe your team missed it in review. its harder to reason about deps that live in deep modules.
  - a2800276 6y ago
    But if you just paste and execute code you found on the internet willy nilly, you're in trouble no matter what the plattform.

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.
ericlewis 6y ago
if you can magically copy and paste in code that also includes a dependency then you might have just screwed yourself if you didn't read the code of said dep (or even if you did, maybe you missed something) if it just looks like a comment then maybe your team missed it in review. its harder to reason about deps that live in deep modules.
- a2800276 6y ago
  But if you just paste and execute code you found on the internet willy nilly, you're in trouble no matter what the plattform.