Follow

“Should I pipe it?”

So, fellow developers, you know how we’re all told not to pipe installation scripts into our shells and yet we all do it anyway? I just rolled a little something that might help with that…

Here’s an example of the nvm install script, verified by yours truly:

should-i-pipe.it/https://raw.g

What do you think?

Anyone with a GitHub account can help verify installation scripts (would be good to have two more for nvm).

Instructions: github.com/small-tech/should-i

Thoughts? :)

@aral can this all be done through the terminal?

@brad Hey Bradley, about to hit the sack as it’s past 1AM here but let me know what you had in mind. Do you mean something that returns a very basic version that you can curl/wget? Would like to understand your use case :) (Will check back tomorrow.)

@aral Yes, that is basically what I had in mind. Something with curl to at least show that bit that says "It looks fine to us..." (or the opposite if it doesn't look fine). Since you're typically doing the piping in the shell, you could make some way to easily check it in the shell as well.

@aral I wish Debian and most popular distro would ship a CLI tool that does that kind of thing (like checking signature or whatever is deemed good enough)

There might be tools that people can install on their machine for this - or this webpage you made is pretty useful, but in the end of the day, people like curl|bash because it's a copypastable CLI one-liner that has basically zero dependencies (well, curl..)

@aral

Also to me it's never clear to me why curl|bash is so controversed in the first place ... Like what's the threat model ? Each time I see people arguing about it on the internet, it's always a confused discussion between authenticity, integrity, trust in the authors, trust in the transport protocols, and "what !? you don't read every line of code that runs on your computer !?" ... And ultimately people don't scream that much when it's about "double-clicking on obscure .exe found on google" or "apt install foobar"

I suppose curl|bash for some reason just shows how in everyday life we rely on trust when we run software and it makes us afraid that we can run random code so easily. Ultimately there are very few contexts in which there are clear information about how code is (or not) audited and peer-reviewed before we run it on our machines. Typically it's not clear for me if and how much code is audited in Debian before being available in repos...

(sry I'm thinking out loud at this stage)

@aleks @aral One article I read was where they were able to change the script that was served depending on wither it was downloaded or piped through bash. I'm not sure how they detected the difference, but they somehow could apparently. So the idea is that the code can't really be verified because when you download you get different code than when you pipe. And, of course, it's not about whether you personally verify, but rather if it's possible to verify so that maybe someone else may do it.
But yeah, I do it too, and even if people don't want to pipe through bash, it's trivial to download first and run that if they really want.

@ilja @aleks Yeah, that’s definitely possible.

Will have a think.

Adding a pipe to the pipe is the only way to really solve that.

But could also mark scripts hosted on well-known sites like GitHub and GitLab more trusted as that wouldn’t be an attack vector (unless they’ve been backdoored by government actors).

@aral it’s reallly cool. I always thought something like a sandbox a script could run in, and report all the changes a script actually does. wouldn’t replace human verifiers, and a report would be just as easy to hide malicious trickery in as a script. something satisfying about the idea of a “dry run” though. maybe a script like nvm mucks up my path in ways i don’t want and i’d like to know about it.

@mplammers Wow, what are they doing in that script, seriously? Will take a look when I have some time. I thought I was being generous with the 100K limit (it’s there to stop the site getting overwhelmed by maliciously large content.)

@aral @mplammers LOL, uf, do you plan to raise that limit?

Also, they use a space in their URL uff…

@aral It honestly doesn't look like something malicious is going on in that script, and it's very well commented. Don't feel obliged to look into it for me, just wanted to share the result. I think "should-i-pipe-it" is a splendid idea.

@aral This seems fundamentally vulnerable to TOCTOU attacks

@jookia It doesn’t cache the script but there is of course the possibility that the site could serve one thing to Should I pipe it? and something else to everyone else. Will have a think about that.

The only way to fully mitigate any attack would be to have Should I pipe it? included in the pipe itself but I’m hesitant to include a centralised single point of failure into install scripts. It would make that site the focus of attacks. This is meant as guidance / better than nothing / awareness.

@aral Having people just check hashes would be a start.

@aral gives me a HTTPS error on firefox if I type two "https://"

@oreolek It’s odd, I’ve run into it randomly a couple of times. Looks like a bug in Firefox. If you press return a couple of times/refresh it finally works.

@aral I feel like this would be really great as some kind of add-on to your terminal that somehow detects piping to shells and runs the script through a text-based version of this site, displaying the results in the terminal with a prompt to ask the user if they want to continue based on the results.

Then you could promote it as a way to automatically ensure that anything you pipe to shell is safe.

although, it would need to be installable in some way other than piping to shell

@aral
One thought on the security: Do you fake a real client?

- Use a curl/wget User-Agent
- Use changing (unpredictable) dial-up IPs and no data center / proxy / tor IPs.

Otherwise I could serve the site a harmless script and send the users an evil script.

An even better option could be to check the script and then offer a button to download the checked script. This would mitigate the problem and even in the case of an attacker who serves different scripts, the user gets the harmless one.

@aral Nice idea! IMHO the best answer is always a strict "no" (especially b/c bash doesn't exhaust input before executing: thomask.sdf.org/blog/2019/11/0) but the pattern is probably here to stay, so it's nice that we now have a tool to verify these scripts.

If it were me I'd make the banner yellow instead of green (which implies complete safety) and add sth to the effect of "Hey, whatever this page says, piping to shell is bad practice, so we suggest you download, read, and run the script manually."

@cadadr Yeah, I hear you on the yellow/green. Actually went back/forth on that and I’m not convinced either. Will consider it.

Sign in to participate in the conversation
Aral’s Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!