

Show HN: Inspect questionable scripts before piping them to sh or bash - mplewis
https://github.com/mplewis/shed

======
dotdi
I am sorry, but I fail to see how this would be of any help.

It is known that piping unknown scripts to bash is a bad thing. So when
somebody decides to pipe into bash, they are either (1) sure of the source or
(2) completely clueless about what the hell they are doing. In case (1) there
is no need for the tool, and in case (2) asking "do you really want to run
this?" will not make any difference since they just typed 'curl <whatever> |
sh' into their shell.

~~~
draz
This. What if OP inspected the script and highlighted potential harmful
commands? Changes in security configurations, manipulation in critical
libraries, start-up scripts, and so forth. Not sure how much _that_ would help
to the novice, but it's at least actionable (user can look the commands up and
understand the implications.

~~~
dotdi
"What if OP inspected the script and highlighted potential harmful commands?"
OP doesn't. Look at the code.

~~~
dewey
That's exactly what he says, he agrees with you and just offers a suggestion
on how to improve the script.

------
joepvd
vipe[0] from moreutils is a bit more general purpose command than this. It
does not dictate the receiving end. So you can quickly check and correct data
between pipes. Nifty stuff...

[0]:
[https://joeyh.name/blog/entry/moreutils/](https://joeyh.name/blog/entry/moreutils/)

------
Xavi
Just brain storming... could another possible solution be to create a public
list of hashes of well known scripts, and then write a small `sh` wrapper that
verifies that hash of the script it's about to execute?

~~~
sean-duffy
You mean like... a package manager?

~~~
Xavi
Well a package manager does much more than verify downloads, but sure you can
think of it as a single featured package manager.

------
spb
Interesting. I wrote a similar script, in Bash, for my meta.sh project:
[http://meta.sh/index.sh](http://meta.sh/index.sh)

~~~
danieltillett
There is a nice simple version here too
[https://gist.github.com/sunaku/f5f79e20b6f92ab1e524](https://gist.github.com/sunaku/f5f79e20b6f92ab1e524)

------
hawski
I can't wait for a time when simple and universal sandboxing will be available
with no need for root.

Just: $ sandbox 'curl [http://whatever](http://whatever) | sh'

With predefined permission profiles or interactive permission system.

~~~
seanp2k2
What would it do which can't already be done with normal nix permissions
and/or ACLs? The solution is to create a user account, like www-run or redis
or Postgres or any of the other tons of things which already do this.

An even better idea is jails, or something like Docker.

~~~
hawski
What you present is not simple or universal. Nix permissions and ACLs are for
file system access and sadly in Linux "everything is a file" is a lie.

Jails or Docker are practically heavyweight sandboxes and they need root
access.

------
ams6110
Why not just:

    
    
      curl ... | less

~~~
thrownaway122
I'm not sure that this is as safe as you may think.

EDIT More info. Yes this is better than curl ... | sh. But less has a lot of
functionality (more than you'd expect) and a carefully written script could
exploit some of this.

~~~
SmirkingRevenge
Would that really be any different that downloading the script, then opening
it with less/vim/whatever locally, which is typically going to be pretty safe,
unless the script is accidentally executed somehow.

~~~
thrownaway122
Well it is exactly the same.

------
jordanpg
I like the sentiment, but I kinda doubt that the group of folks who would
inspect the script before running if only it wasn't so inconvenient to do so
has many members.

We live in an era of unsigned images and arbitrary code. This is about time
and money, and I don't think any amount of astonishment from the larger
community is going to reverse that trend.

