News for hackers. Stuff that matters.
Re:Deno 1.0 by danShumway on Thursday May 14, 2020 @01:24AM (#23175634)
> That combined with the 'download random code from any url

What protection does NPM actually give you?

Sure, they'll remove malware as they find it, but it is so trivially easy to publish packages and updates to NPM, there effectively is no security difference between an NPM module and a random URL. If you wouldn't feel comfortable cloning and executing random Github projects, then you shouldn't feel comfortable installing random NPM modules.

> and run it immediately

NPM packages also do this -- they can have install scripts that run as the current user, and have network access that can allows them to fetch, compile, and execute random binaries off the Internet.

From a security point of view, Deno is just making it clear up-front that you are downloading random code snippets, so that programmers are less likely to make the mistake of trusting a largely unmoderated package repository to protect themselves from malware.

I lean towards calling that a reasonably big security win on its own, even without the other sandboxing features.

Re:Deno 1.0 by yoz-y on Thursday May 14, 2020 @04:29AM (#23176953)
> What protection does NPM actually give you?

Dependency version pinning comes to mind. The main difference between this and a random URL is that at least you know that if the module gets bought by a third party, your services or build system won't auto update to some rando's version of the package. IIRC there have been cases when a version was replaced as well.

I think this could be fixed quite easily if one could add a hash and a size after the url, to force a check.

Re:Deno 1.0 by catears on Thursday May 14, 2020 @06:58AM (#23177987)
I was curious about this so I looked into it. Seems like deno allows for lock files (similar to package-lock.json for NPM) https://deno.land/manual/linking_to_external_code/integrity_...
Re:Deno 1.0 by another-dave on Thursday May 14, 2020 @05:23AM (#23177341)
Yeah, basically sounds like they could implement it à la Content Security Policy in the browser and it would be well understood right off the bat.

Or similar to node_modules, have some way to pull your dependency graph & host locally — At least for enterprise-y adoption I imagine that people will want to have _their_ copy of the code and choose when to update it even if in theory the remote code is locked down.

Re:Deno 1.0 by mgolawala on Thursday May 14, 2020 @02:02PM (#23183064)
That is what I figured too. People are rightly concerned about the security implications of this new paradigm of including package dependencies.

These concerns and the conversation around them are good and healthy. Give it some time. People will experiment with what works and over time best practices will emerge for the set of trade offs that people are willing to make.

Re:Deno 1.0 by virgilp on Thursday May 14, 2020 @05:15AM (#23177296)
Arguably you can get (even more reliable) version pinning by copying typescript from that random URL & storing it in your own S3 bucket. Sure, you have _some_ work to do, but it's not that much and you 100% control the code from there on.
Re:Deno 1.0 by yoz-y on Thursday May 14, 2020 @05:52AM (#23177529)
Well, I suppose they do (or will) provide a self hosted version of the registry. Like npm does.
Re:Deno 1.0 by philholden on Thursday May 14, 2020 @06:57AM (#23177979)
If you publish your module versions on IPFS that would provide a guarantee to your users the module versions do not change once published. But hashes are not very memorable as module names.
Re:Deno 1.0 by ignoramous on Thursday May 14, 2020 @09:40AM (#23179337)
> If you publish your module versions on IPFS...

Well, using message digests, NPM or Yarn can pretty much guarantee content addressable versions, too. Do not have to use IPFS or blockchains, just because...

Re:Deno 1.0 by BiteCode_dev on Thursday May 14, 2020 @08:32AM (#23178650)
A single source of trust for the dependancy transport.