Re: [ann] Blog post on Luvit without Luvit

On Thu, May 5, 2016 at 6:38 AM, Peter Aronoff <telemachus@arpinum.org> wrote:

On Wednesday, May 04, 2016 at 10:51PM, Tim Caswell wrote:
> Peter, I don't see how piping a shell script to sh is any worse than
> downloading unsigned binaries and running them. If anything this is
> safer because anyone who is paranoid can simply do the curl and sh in two
> steps and read the script in between to verify what it's doing. With
> binaries this is considerably more difficult. (Also this is just
> bootstrap to download the right binaries anyway)

If you read the article I linked last time (and which I'll link again
below), you'll see that you cannot "simply do the curl and sh in two steps"
in order to prove everything is safe. A clever attacker can in fact detect
whether or not curl is being piped to the shell directly and alter the
delivered content accordingly.

Although this latest example is recent, similar exploits have been known
for sometime (the earliest article I can find about switching payloads is
from 2012—I'll post that below too).

https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/

https://jordaneldredge.com/blog/one-way-curl-pipe-sh-install-scripts-can-be-dangerous/

My larger question to you is this: What advantage is there to `curl
installer | sh` over telling people to download a repo and running `make`
or even `./installer`? The only advantage I see is that it's a one-liner
and maybe it feels cooler. It's a lot less secure.

The advantage is lower barrier to entry. This is very important. If I had time I'd maintain

All this talk of security and one method being safer than another is silly. First of all, there is nothing stopping someone from curling to a file, reading the file, and then running it through bash. If I were to bother to go through the effort to detect direct piping and only serve bad code in that case, people doing it in two steps would be immune.

In the second article you linked to (and yes I read them both):

> Of course, the whole point is pretty much moot because the install script is probably installing lots of other code that you haven’t reviewed, so you are wouldn’t be running this code unless you already trusted the author.

It all comes down to trust. From a security standpoint there is little difference between a tiny shell script that automatically chooses the correct binary for your platform and making a user manually choose the correct binary for their platform. In either case, they have to trust me and my server to be safe.

Building from source is a little safer if you really have the time to read all the code or you trust the fact that all code is public on github and has other users. Git's sha1sum based storage model and the GPG signed tags I use for releases helps some as well.

I'm using HTTPS to serve the script and github is using it as well for https clones, technically any CA that is trusted by your client has the ability to man-in-the-middle the connection (again this is where git hashes and gpg signatures help).

But really, let's be honest. Do you really verify all this for every package you run on your system? What about backdoors in your compiler? Is GCC or clang really safe? You can't built from source easilly without bootstrapping with some pre-built binary. Even if you could, reviewing all of such a large compiler in impossible for a single human. How do you trust your hardware to not have backdoors embedded in it?

Everything is somewhere on the range between convenience and security. I offer two good points on this range. They are curl-pipe-bash for maximum convenience and build from source using GPG signed git tags (over ssh or https).

I don't see added value for anyone in making the convenient option less convenient, but no more secure. What you proposed isn't actually any safer really, it just provided a false sense of security.

I do see value in perceived security though. If you can convince me that luvit adoption will increase if I make it appear less scary (even though it's not) and only be slightly harder to bootstrap, then I'll do it. The goal is to make things as smooth as possible for people who already trust me.

My two cents, Peter

Thanks for your two cents. I'm sorry if I come off as combative and I can see you have genuine concern. I simply disagree that changing things will actually improve anything.

-Tim