Hacker News new | ask | show | jobs
by BeefWellington 1508 days ago
It is disappointing to see this message as the basics of what the software is on their site (https://deno.land/):

    Deno is a simple, modern and secure runtime for JavaScript, TypeScript, and WebAssembly that uses V8 and is built in Rust.
Only to have that immediately followed by really poor practice of suggesting this as the installation method:

       curl -fsSL https://deno.land/install.sh | sh
This is not strictly related to Deno -- lots of software does this -- but if you're going to suggest your thing is more secure than the other guys' thing (which is implied by calling your thing secure), you shouldn't then be immediately throwing that credibility away.

Yes, the page offers a link to the "Releases" page at their github repository. However, anyone familiar with any kind of UX will understand immediately that this is effectively burying the link and subtly makes the statement that you don't really want to bother with that other way of doing things. They also don't provide a gzipped/bzipped tarball for the linux install but a zip file instead, adding an additional barrier/dependency.

I understand this is an area where security is losing the tug of war to ease of distribution/access but it pains me to see it on any project, let alone the potentially good ones.

3 comments

You're about to run their software on your computer-- what's the difference with that and running their install script?
How do you guarantee that their install script is non-malicous and was actually provided by them?

There's a reason why code signing exists as a security measure.

While signing does improve security, it's still something of a turtles-all-the-way-down problem because how do you verify the public key is valid? An additional factor is added, which helps, but it's not a silver bullet. And the complexity tradeoffs of requiring cross-platform installation of a signing lib like gpg/minisign (which plenty won't already have installed) and a much larger install snippet are significant.
For the Mac at least, signed dmg files and apps are normal, so they should have done it that way.
Most people trust that the script is not malicious, including me. There is wrong with this approach, it is extremely convienient to try something out that has good reputation.

For these people, running the script or downloading a signed GitHub release is equivilent, in both cases they do not read the source code of the software that they are running.

There is nothing stopping you from 1) reading the script before running it 2) reading the source code of Deno and any dependencies 3) compiling from source yourself. For most people, this is a waste of time. Trust has to start somewhere to build something great.

https://deno.land/install.sh is a redirect to https://deno.land/x/install.sh, which is treated as any /x/ (community) module. These modules are immutable clones of github tags (in this case, https://github.com/denoland/deno_install/). If someone would manage to breach the AWS S3 buckets that we use for module storage, it wouldn't be just a problem for installation of the deno CLI, but a problem for any module on the registry.
It's using SSL, what's the real world concern here? Other than someone might get copy-paste happy and someday install something they don't want.
There's quite a bit wrong with this idea that "It's using SSL [therefore it's safe]", assuming your meaning there.

The most obvious case: someone compromises the installation script on the actual real deno server. Right now the webserver there is returning an HTTP/307 to an HTTP/302 to the "current" installation script file. Any compromise of the webserver makes this very dangerous.

Contrast that with proper signed packages, code signed sources, etc. There it requires compromise of the developer's systems and signing keys, which at least can be a far harder thing to attack if they're doing things securely.

I think this is a fair criticism and deserves attention. Whenever anything shiny comes around, we are too enamored by it to not allow any criticism.

Is there a reason Deno is not packaged as a repo in official apt, deb, yum, etc repositories?

And in this hypothetical scenario, how does that protect against the aforementioned attack? If one of deno's hosting sites can be attacked to upload a malicious script, one of the package registries can also be attacked and upload a malicious package.
This makes sense. But how do I as a basic user make sure the signature is correct and definitely from Deno? Couldn’t a hacker sign it with their own signature?
1. the file is replaced with a malicious version on their server and not checksummed

2. copy/pasting includes invisible characters that aren't seen until executed

both of these things happen regularly

orthogonally, curl|sh (usually) circumvents the package manager and makes uninstallation difficult