> The socket thing doesn't work (at least as the default mode) because nobody knows how to forward sockets
I suspect that you can do this with SSH configuration (LocalForward ~/.something:~/.something), but I haven't tested it. It mostly depends on whether you're willing to configure this, but perhaps the installer can put that at the top of ~/.ssh/config, so it's global, with a comment saying "If you don't want this globally, delete it or put it after a `Host example.com` line". Even if you trusted all SSH hosts, this would protect you from the git-clone attack.
You could probably also abuse X11 forwarding for this, which has the advantage that trusted X11 forwarding is basically the right security boundary and is just `ssh -Y`, and the disadvantage that now you're relying on X11 (or worse, a custom X11-speaking proxy so you can avoid requiring the server or client) on both sides.
> There are gnarly race conditions there, too. How do you correlate prompts with messages on the socket?
Send a token or hash in-band, and send the actual command out-of-band. If you receive an unknown token, ignore it.
> I do plan to nuke the curl|bash thing. It was a shortcut to ship faster and to make it easy to update scripts in the field quickly when bugs were found. I did imagine everyone on hacker news scowling at me when I wrote that code, FWIW.
:-)
curl https:// | sh is IMO a perfectly reasonable way to install software (at least in a world where ./configure && make install is reasonable; I don't know any humans who can audit the output of GNU autoconf). It just has this one weird problem. I sort of dislike the stigmatization of it precisely because it's hard to talk about how to do it well.
I suspect that you can do this with SSH configuration (LocalForward ~/.something:~/.something), but I haven't tested it. It mostly depends on whether you're willing to configure this, but perhaps the installer can put that at the top of ~/.ssh/config, so it's global, with a comment saying "If you don't want this globally, delete it or put it after a `Host example.com` line". Even if you trusted all SSH hosts, this would protect you from the git-clone attack.
You could probably also abuse X11 forwarding for this, which has the advantage that trusted X11 forwarding is basically the right security boundary and is just `ssh -Y`, and the disadvantage that now you're relying on X11 (or worse, a custom X11-speaking proxy so you can avoid requiring the server or client) on both sides.
> There are gnarly race conditions there, too. How do you correlate prompts with messages on the socket?
Send a token or hash in-band, and send the actual command out-of-band. If you receive an unknown token, ignore it.
> I do plan to nuke the curl|bash thing. It was a shortcut to ship faster and to make it easy to update scripts in the field quickly when bugs were found. I did imagine everyone on hacker news scowling at me when I wrote that code, FWIW.
:-)
curl https:// | sh is IMO a perfectly reasonable way to install software (at least in a world where ./configure && make install is reasonable; I don't know any humans who can audit the output of GNU autoconf). It just has this one weird problem. I sort of dislike the stigmatization of it precisely because it's hard to talk about how to do it well.