Hacker News Reader

Comment by reagency | Hacker News Reader

What's wrong with that? It is SSL secured.

Once you agree to install software, it had local access with your accounts privileges.

piping random shit into sh is wrong because domains go away, yet installation instructions might be repeated in countless other tutorials. easy to snap up domains and host malware.

and SSL has nothing to do with it. packages are not cryptographically signed either and once on the system can easily become root.

Once you've installed it you've given local privileges (or even root) to the app, so you're hosed anyway.

I think the bigger danger is that since you're instructing a direct pipe-to-sh over the network without regard to exit status, you're running the risk of executing truncated code that could trash your system state.

The author addresses this issue by wrapping the script [1] in {} braces:

    { # Prevent execution if this script was only partially downloaded
    # installation code here
    } # End of wrapping

I'm not sure if this is a bulletproof solution.

[1] https://asciinema.org/install

That's correct. In case bash doesn't see closing braces it will error out with "syntax error" and won't execute anything.

It's pretty rare for an app to need root privileges. You typically need root to write to the system dirs (/usr/* /bin etc). And in this particular case, the app has access (by design) to your terminal, so yeah, you need to trust the app a bit. But why would you need to demand all users of your system (even if that's just system users) also trust it?

Put it in ~/opt with xstow, and add ~/opt/bin to your path, ~/opt/man to your man-path, ~/opt/include, ~/opt/lib... to the various paths.

In this case, it seems like a lot of effort to get a tgz-archive just to download a single executable. I gather it's distributed as an archive in order for the Changelog, Readme and License to be available -- but as it's all downloaded from github anyway, it's hard to see why that really matters (rather than just have -h spit out a link or two).

As, if you're using a normal, full-featured web browser, there's no way of knowing if what you select, is what you copy and then paste -- it would probably be better to just link directly to the latest binary release for the various platforms (linux32, linux64, linux-arm, OSX 32bit, OSX 64bit) -- and let the user save the binary somewhere.

Limit the "command line instructions" to:

  go get github.com/asciinema/asciinema

rather than fighting idiomatic go practices.

If you really want to be clever, why not just use 0install?

http://0install.net/

Would this be better if the pasted command included some checksum which was checked before piping into the `sh`? Can anyone who's better at bash than me give an example of how this could work in a relatively cross-platform way?

You would need to have a GPG signature with a well-known public key that is verified before executing the code.

Sorry, can you explain why? If the checksum is provided (as part of the sh snippet) by the website with the SSL certificate, isn't that enough reassurance?

If the snippet and the download are on the same site, then whoever controls that site at the moment can provide an accurate checksum of whatever malware they want to host. A signature is an improvement because it can give you some confidence that the current controller is the same as the original controller.

> Would this be better if the pasted command included some checksum which was checked before piping into the `sh`?

hashpipe does exactly that:

https://github.com/jbenet/hashpipe

If you are doing a terminal video, I'm pretty sure you are smart enough to break down that pipe and first download, and then run it.

So why not make that the way the instructions tell you to do it?

Because as other commenters have said, anyone interested in doing that will do it anyways.

But isn't that the behavior we want to encourage everyone to have? Most people will do the default: if the default is wrong, they don't care. If the default is right, they still don't care, but at least they're doing it right.

> packages are not cryptographically signed either

Eh? Both debs and rpms can be signed with GPG keys.

You won't be so happy when your https connection drops after "/" as you are piping into /bin/sh:

  rm -rf /$INSTALLER_TEMP_DIR

See here: https://news.ycombinator.com/item?id=9754681

We evolved packaging systems for a reason - they provide a standardized way to manage dependencies, provide clean uninstalls, etc... Having a shellscript pooping files arbitrarily into the filesystem is so 90's.

Seriously - you pretty much just have to make a .dep and a .rpm and you're covered. Is that so hard?

> you pretty much just have to make a .dep and a .rpm and you're covered

Author already did that [1] and has both .deb and .rpm:

https://asciinema.org/docs/installation

Reply on news.ycombinator.com