Cargo doesn't respect git's http.sslverify

[alexcrichton]

This used to be supported in libgit2, but it was removed. We should probably add back in explicit support somewhere.

cc #636, this has come up once or twice there.

[alexcrichton]

This will likely be done by binding the certificate_check callback in remote_callbacks.rs of git2-rs and then using that in Cargo itself

[yug]

It seems a little bit complicated.

We are behind the R&D proxy, the company classifies the connection zones, we are unfortunately in a zone we can git clone the outside code, no write access to outside.

Cargo should get work by hacked locally, however, the process is that it firstly download a pre-built binary, that init binary couldn't work, so, all things blocked. I am not sure Cargo support cross-compile, if it does not we had to find a linux 64bit box without proxy access problem, build a hacked cargo, substitute the pre-built with that hacked, then get whole things work.

BTW, there should be configuration item to tell cargo to ignore the SSL_certificate_check, rather than people to hack an ad-hoc version

The problem is not solved, I will try it and update feedback here

[the-shank]

@yug any updates on this one? I am behind a http proxy and am unable to use cargo

[thebitllc]

I hardcoded the hostnames on my windows box and it worked with tinyproxy/proxifier:

c:\windows\system32\drivers\etc\hosts

174.129.244.175 www.crates.io crates.io s3-us-west-1-r-w.amazonaws.com

[alexcrichton]

@thebitllc hm that's interesting, if you don't have that hardcoding, does crates.io resolve to a different IP than it normally does?

[chrisxue815]

I managed to bypass this problem by setting up a crates.io proxy and a local index repo. See detailed description in chrisxue815/crates.io-proxy.

[guillon]

Related issue on my side, actually my company has a HTTP/HTTPS proxy service which fakes SSL certificates for doing HTTPS session monitoring (i.e. decrypts https on the fly). To achieve this the proxy provider fakes https certificates by returning its own certificate to the client.
This is quite unfortunate and forces us to always do HTTPS fetches with no server certificate checks.

Hence it would be great to have a cargo option similar to the --no-check-certificate flag of wget (or --insecure flag of curl, or as mentionned, sslVerify=false configuration of git) when downloading from crates.io.
Whatever the implementation in the background, I guess it would be better to have the flag honored independently of the actual git config as the problem is not specific to git fetches, but also to bare downloads.

[alexcrichton]

One question here is how Cargo may want to export this. It'd undeniably pretty questionable security practice to ignore certificate checks, but the use cases brought up here are indeed legitimate. We may want to do something beyond http.sslVerify or the GIT_SSL_NO_VERIFY environment variable (e.g. also require cargo build --insecure), but if git itself has this sort of configuration then we arguably should just go ahead and respect it as well

[the-shank]

My case is the exact same as @guillon ... Behind a company wide proxy which fakes SSL certificates and am unable to use (and to ask others to use) cargo. Will give the crates.io-proxy thing a go but still, it would be so much better if this is resolved.

[guillon]

@alexcrichton, I guess that if one provides a --insecure (or --no-check-certificate) flag, it would be natural for the user to expect that cargo will force the skip of certificate check for all transport connection initiated (git, curl or whatever application level client used by cargo to get artifacts from the network).
Hence I guess that if this flag is provided it should force this setting for file download and git fetches initiated as part of the cargo command.
Thus, actually overriding the defauly git setting if any or download client setting if any.

If, independently of this flag, cargo uses a git client which honors the git configuration, no issue with this, i.e. the user may expect that if he sets a git configuration a git client may honor it. It is not cargo responsibility in this case.
Same for instance if cargo would explicitly mention that the download client is curl (I don't know actually), in this case the ~/.curlrc configuration could be also used by the user.

In summary, it would be good if cargo uses git/download libraries that honor "standard" git/download configurations.
But in any case it seems to me that providing a flag and thus forcing the behavior in anycase is a must have and more maintainable solution (i.e. it becomes a feature of cargo itself and thus gives a guarantee of reliability).

[aldanor]

@the-shank @guillon Ditto, same case here, our company-wide proxy fakes SSL certificates, so we are basically forced to use wget --no-check-certificate, curl --insecure, etc, and sslVerify = false for git. And then of course it's a major PITA when a library/package/build systen doesn't comply with the configuration of standard tools like git.

I would, too, expect cargo to use whatever's listed in git configuration by default (if the user configured it in some specific way, that's the ground truth?), but maybe also provide a way to manually override this setting (--insecure) explicitly.