bug#32855: sshuttle /usr/bin/env

[Tobias Geerinckx-Rice]

Hullo,

Nam Nguyen wrote:
> Hi Tobias,
>
> After testing, I think the /bin/sh substitution introduced a 
> regression.
>
> Lines in question:
> (substitute* "sshuttle/ssh.py"
>   ;; Perhaps this is unreachable, but don't let's take risks.

Oh, the irony.

>   (("/bin/sh") (which "sh")))

This is just wrong: it calls the client's /gnu/store/.../sh on the 
server.

> $ sshuttle -r user <at> server.com 0/0 -x server.com
> ksh: /gnu/store/rb...-bash-minimal-4.4.19/bin/sh: not found
> client: fatal: server died with error code 127
>
> The server I am sshing to is not running GuixSD. It is trying to 
> find
> /gnu/store/.../bin/sh but it doesn't exst.

That's a good point (all my remotes run GuixSD, hiding the bug).

> The only requirements on the server side should be Python.

It's all well & good for upstream to say that (they do), but if 
they explicitly call /bin/sh on the server then it's just not 
true. A POSIX-compliant 'sh' was always an unstated server-side 
dependency, and Guix happens to be very good at finding (and 
breaking :-) those.

The hard-coded '/bin/' kluge was accepted later¹. Can't fathom 
why. If brianmay's last comment is still true they'll accept the 
correct 'exec sh' solution too.

Could you check whether replacing '(which "sh")' with '"sh"' 
works? It does for me.

> Should those lines should be removed? I tested without, and it 
> seems to work okay,
> at least for my particular setup: GuixSD client --> non-GuixSD 
> server.

Wouldn't that break [any client -> vanilla GuixSD server] cases?

No denying that this regression needs to be fixed, 
though. Apologies for breaking your 'flow.

> I suppose we have to state the assumptions of whether the client 
> and
> server are running Guix or not, and arrive at good defaults.

I'd like to avoid such assumptions in general, and entirely on the 
Internet.

Kind regards,

T G-R

1. https://github.com/sshuttle/sshuttle/pull/77