TLS handshake timeout for hub clone

[ruihangdu]

I am trying to set hub up with github enterprise and my setup is as follows:

.zshrc:

export GITHUB_HOST=[github enterprise hostname]
export HUB_CONFIG=~/.config/hub
export HUB_VERBOSE=true

(the GHE hostname is coherent with the output of

git config --get-all hub.host

)

.config/hub:

[GHE hostname]
- user: [my user name]
- oauth_token: [my_oath_token]
- protocol: https

The output of

hub clone [org]/[name]

was

> POST https://[GHE hostname]/api/v3/authorizations
> Authorization: Basic [REDACTED]
> Accept: application/vnd.github.v3+json;charset=utf-8
{"note":"hub for ......","note_url":"https://hub.github.com/","scopes":["repo"]}
Post https://[GHE hostname]/api/v3/authorizations: net/http: TLS handshake timeout

Could you please shed some light on what might be the cause of this? Thanks.

[mislav]

Thank you for sharing. Does your Enterprise instance require a custom SSL certificate to access? See #852 for more info. You can check this by navigating to https://[GHE hostname] in your web browser, clicking the security icon in the address bar, and opening the info about the certificate.

The error message comes from Go, not hub, and basically says that something went wrong performing the TLS handshake for https://[GHE hostname], but it's hard for me to tell what exactly went wrong.

[ruihangdu]

I opened the certificate detail but how do you tell if it is a custom certificate?

[mislav]

@larry0123du It's not really exact science, but you can look at its parent certificates to determine whether they are a CA (certificate authority)

[ruihangdu]

It looks pretty much the same as yours, except for that the CA is DigiCert Global Root CA

[mislav]

Then I guess the certificate is not the problem.

Can you access your GHE via curl? curl -v https://[GHE hostname]/api/v3/user
It should respond with HTTP 401 Unauthorized, but it should at least get past the TLS handshake.

I don't really know what else to suggest or how to fix this. Hub doesn't handle connectivity; it's up to the underlying Go implementation.

[mislav]

@larry0123du The current TLS handshake timeout is 10s: https://github.com/github/hub/blob/d492aba0de0c6d0d45ba252ca7ac8868c2e4604c/github/http.go#L174

You can try to edit this value, compile hub on your machine and check if that helped.

[ruihangdu]

Will try this when I get the chance

[JLLeitschuh]

I'm running into the same issue when trying to run multiple (5) hub clone commands in parallel.

I'm working on a python script that automatically creates security PR's and I'm trying to parallelize the script.

When I ran everything sequentially, everything worked fine, but running in parallel, now it fails.

I'm trying to run my script against gradle.com.

Is there any way to manually configure the TLSHandshakeTimeout with a flag or does it require a recompile?

[mislav]

Is there any way to manually configure the TLSHandshakeTimeout with a flag or does it require a recompile?

It requires a recompile for now. Try building hub yourself with changed configuration and if it fixes it, we can consider making this configurable.

[mislav]

This was likely caused by a known Go issue that was patched just yesterday golang/go#19561 (comment)

It would affect macOS users who 1) had many extra certificates with custom trust settings in their Keychain and 2) would try to run a Go program that was compiled with CGO disabled (e.g. cross-compiled for macOS on Linux).

Until the next Go release, you might work around it by either cleaning up unnecessary custom certificates from your Keychan or by compiling hub from source on your own machine.