Rustls transport?

[jsha]

Hi,

I've been looking at the security of the cargo / crates.io ecosystem, and I've noticed that it depends heavily on the security of TLS. The index of crates is downloaded over HTTPS from GitHub, and serves as the root of trust for subsequent crate downloads, because it contains the sha256 hashes of the crates.

Given that, I think it makes sense to use the strongest TLS implementation. Fortunately, rustls is a very high quality implementation, and is in Rust! Besides the memory safety benefits, it has a couple of other benefits: It does not implement older TLS versions (1.0 and 1.1), which have some vulnerabilities. Similarly it does not implement weaker ciphersuites. Also, it ships by default with webpki-certs, which is beneficial because it tends to be more up-to-date than the native root store on Debian-derived operating systems. When there's a CA that's been removed from the Mozilla root program (and others), but not removed yet from a root store, that's a big risk. In that situation there aren't (necessarily) any audits or controls happening any longer to ensure the CA is doing the right thing.

So I was thinking it would be useful to implement a git transport for HTTPS that uses Rustls. Probably the most straightforward way to do that would be to incorporate a Rust HTTP client. I see git2-rs already has a small HTTP client in git2-curl, but that it's considered less battle-tested (and has an issue with pulling a whole repository into memory), so isn't used as the default in cargo, but is only used when there are special HTTP setting, like proxies or custom root stores.

Is that something you think would be useful? Since my goal would be for cargo to (eventually) adopt this as the default instead of libgit's built-in HTTP transport, what quality and testing bar would it need to meet?

Thanks,
Jacob

[alexcrichton]

Seems reasonable to me! There's the git2-curl crate which implements all HTTP crate fetches through the curl crate, so presumably there could be a git2-hyper crate (or something like that) which disables all of libgit2's internal networking and provides it via hyper+rustls?

[gilescope]

Being able to use a pure rust ssl makes using a lot of rust tools a lot easier where finding openssl or building ssl from source is tricky. Building cargo, cargo-audit, cargo-local-registry etc. It would make a big chunk of the ecosystem easier for people to use.

[weihanglo]

Hi. I am wondering about how to integrate an async HTTP backend like hyper into git2. And it seems that spawning threads for hyper in the Read/Write trait is the most feasible solution which I can come up with. If there is other possible approach, please share it here. I am happy to do some experiments.

[kim]

@weihanglo We’re doing something like this. You can also pass around an executor.

[henry40408]

Hi, I just implemented a HTTP back-end and send a pull request.

[brooksmtownsend]

Checking back in on this, is there still a desire to create a feature that will let users of git2 enable rustls instead of openssl?

[jsha]

Yes, I'm still very interested in using git2-rs with a rustls backend. I wrote a couple of starts at this in #624 and #625. What I found was that what's needed is not just a TLS transport but also an HTTP implementation. I think it should be quite possible to dust off one of those PRs and proceed either with the ureq HTTP client or with a hyper HTTP client (or both).

[Shifulor]

Just wanted to add a heavy interest in a rustls usage because openssl crate does not support libressl or modern openssl, while rustls does. Openssl-vendored kinda bloats the binaries so i would greatly appreciate a rustls version

[gilescope]

Two years on and at a different place and I find things still failing to install due to openssl dependencies. Pure rust might be more secure by now as well as work first time. It would help rust's roll out if we could ween ourselves off openssl.