git_deploy: OpenSSH multiplexing issues

[vain]

The problems we've discussed here apply to git_deploy, too, if the clone is done via ssh:

bundlewrap/bundlewrap#235 (comment)

Master/mux process forks but keeps stderr open, so it doesn't quit until timeout elapsed. That's why it hangs.

[vain]

And, IIUC, nothing keeps bw from launching two git processes almost simultaneously which will then result in the same errors we've seen in core bw. See this comment: https://github.com/bundlewrap/bundlewrap/blob/4a92b1b50034a929e49829cbb8b640e4398d4419/bundlewrap/node.py#L571

[trehn]

I may be confused, but isn't this a problem git itself should handle, just like we did?

(not saying we shouldn't do something here)

[vain]

Well, if you ask me, OpenSSH itself should be improved to not create these problems in the first place.

I'm a bit stumped why nobody cares to address this in OpenSSH. For example:

• https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-January/031975.html
• https://lists.mindrot.org/pipermail/openssh-unix-dev/2015-October/034416.html

No replies.

I can't find the original bug report anymore where the authors claimed to have fixed one of the issues by closing stderr. Do still have a link to that one?

– edit: There you go: https://bugzilla.mindrot.org/show_bug.cgi?id=1988

Anyway, even if this gets fixed in OpenSSH, it'll still take a long time until users get the fix. The same goes for Git. Maybe we can at least try to avoid the stderr issue in git_deploy.

If we decide not to create a workaround on our part, we should advise users not to use multiplexing for Git transports.

[vain]

Oh, now look at that! That last comment in https://bugzilla.mindrot.org/show_bug.cgi?id=1988 says that this will be fixed in OpenSSH 7.3.

Remaining issue: Simultaneous launches and possible race condition.