Fix parsing of received environment variables from SSH clients

[cybe]

The inbuilt SSH server supports setting environment variable received from SSH clients. However, parsing of those variables was completely broken and ignored the actual SSH protocol wire format, thus was only successful by chance.

This new implementation uses standard operations from the crypto/ssh module to parse the SSH wire format.

[lunny]

@cybe maybe you could add some tests for this PR? it's difficult to review.

[cybe]

@lunny: I'll look into it.

[hlandau]

@cybe @lunny

How did this code even work in the first place? I don't see how executing env FOO=BAR changes the environment of any subsequent exec, like the subsequent execution of gitea serv. env runs a new program with a modified environment, or, if no command is specified, just prints the resulting environment (but with the current code, anything output by env is ignored.) env has no power to modify the environment of its invoker.

In order to make this work correctly, you'd need to unmarshal the environment variables properly (as in this PR) and add them to a map, then pass them along when gitea serv is executed. But if things have apparently been working fine up until now without environment variables being passed, it may just be better to remove this functionality outright, as it only increases attack service in a delicate area (program invocation).

[techknowlogick]

can you add copyright for Gitea to header

[cybe]

@hlandau
I'm totally fine with removing the variable parsing code completely. Do you know if the git ssh wire format depends on those variables in any way?

[hlandau]

@cybe I've looked at the RFCs and there shouldn't be a problem. This code currently isn't doing anything and there's a no-op default: case in the switch, so there's basically no change.

I've made a PR here: #4266

[techknowlogick]

Closing this in favour of #4266