This repository was archived by the owner on Sep 11, 2020. It is now read-only.
ssh: leverage proxy from environment #1090
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I was working on a little git-cli drop-in that creates an orphan branch for tracking (per-branch) versioning information when I realized that it did not work for clone/pull/push with SSH URLs in a proxied environment (good ole SOCKS5). I made a small change in
ssh.command#connect()
to replace the invocation ofssh.Dial()
to a copy of that function that usesgolang.org/x/net/proxy.FromEnvironment()
to get a dialer and then hands off the dialed connection tossh.NewClientConn
. This breaks the connection timeout facility becauseproxy.FromEnvironment()
returns aproxy.Dialer
which is a single-method interface type (that doesn't support a timeout or context arg).The cool thing about
proxy.FromEnvironment()
is that it returns a workingDialer
(i.e. directly connecting) if no proxy details are found or the setup for recognized proxy details fails for any reason.There are some existing issues tracking some sort of
proxy.DialContext
implementation:I am not confident that the Go folks will be tackling this lack of a timeout-capable dialer in
x/net/proxy
anytime soon so I understand if the behavioral breakage in this proposed change is not acceptable.Signed-off-by: Jacob Blain Christen [email protected]