Useless error when ca-certificates are missing

[glandium]

I was trying to cargo build something in a newly created chroot and got the following output:

    Updating registry `https://github.com/rust-lang/crates.io-index`
warning: spurious network error (2 tries remaining): curl error: 
; class=Net (12)
warning: spurious network error (1 tries remaining): curl error: 
; class=Net (12)
error: failed to fetch `https://github.com/rust-lang/crates.io-index`           

Caused by:
  curl error: 
; class=Net (12)

Even with colors, this is not a great error message.
Strace hinted me that /etc/ssl/certs/ca-certificates.crt was missing, and sure enough, it worked after installing the ca-certificates package. But that wasn't thanks to cargo's error message.

[Arnavion]

This happens on Windows as well, where ca-certificates.crt is not the solution.

[tDo]

Ahh okay, thought it was just me. Yesterday it was working fine and today also got this same error (Win7 x64). Also tried meddling around in the cert-store without any success.

[retep998]

Might this be due to https://github.com/blog/2507-weak-cryptographic-standards-removed ?

If so, this might have just broken all Rust users on Windows 7...

[Arnavion]

I am on Windows 7, and @retep998 pointed me to this Windows update's docs. I can confirm that applying the reg key mentioned there fixed it for me immediately.

New-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp' -Name DefaultSecureProtocols -PropertyType DWORD -Value 0x00000800

[retep998]

We need to put out a huge announcement for this on the rust blog alerting all Windows 7 users to apply that fix, and also make it a prominent entry in any sort of FAQ or troubleshooting guide we have, along with alerts on all social media including twitter and reddit. There also needs to be a note on wherever we claim Rust supports Windows 7 about this.

[retep998]

An additional thing we should do to reduce the impact of this in the future, whenever Cargo fails in this manner, it should check if it is on Windows 7, and if so check for those registry keys and their values. If the registry keys aren't set appropriately, it should give the user a really LOUD warning about how they need to fix their Windows 7 and provide detailed instructions on how to fix it.

We could also implement this check in rustup itself, so even if someone is using an old version of Rust, as long as they used a recent rustup to get that old version of Rust, they would be alerted to this issue.

[retep998]

Because this issue is technically supposed to be about poor error messages when ca-certificates.cert is missing on nix systems, all discussion of the Windows 7 specific issue is being moved to a new issue.

#5066

[alexcrichton]

@glandium where'd you acquire Cargo from and what Linux distribution were you using? Using the officially shipped binaries and Ubuntu I get:

$ docker run -v `rustc +nightly --print sysroot`:/rust:ro -it ubuntu:16.04 /rust/bin/cargo install ripgrep
    Updating registry `https://github.com/rust-lang/crates.io-index`
error: failed to fetch `https://github.com/rust-lang/crates.io-index`

Caused by:
  the SSL certificate is invalid; class=Ssl (16); code=Certificate (-17)

so I'm not sure how to reproduce this :(

[glandium]

I was using the debian packages. Arguably, the cargo package should depend on ca-certificates, and I might file a bug for that.
Anyways, I tried again on another platform, and it turns out I do get the same error as you do. So I tried again on the original platform I tried, and I can confirm it happens there. So I went around, and this is the result: this happens on s390x, arm64, armhf, i386, ppc64el, but not on amd64.

[alexcrichton]

@glandium you mention this reproduces with i386 but I was also unable to reproduce? Are these official builds or debian builds?

[glandium]

Debian packages.

[alexcrichton]

Perhaps this is a misconfiguration in the debian build? Maybe a bug in the libgit2/openssl bindings? Sorry I'm not really sure how to go from this to a more narrow cause which can be fixed.

[glandium]

I was able to reproduce with a fresh build of cargo from master by building with LIBGIT2_SYS_USE_PKG_CONFIG=1 and having libgit2-dev installed.

[alexcrichton]

If that option isn't used does it work? If so then libgit2 version is probably mismatched as the crate is only compatible with one at a time

[glandium]

If that option isn't used does it work?

It does.

If so then libgit2 version is probably mismatched as the crate is only compatible with one at a time

If that's really the case, then it should fail to build if the wrong version is used. However, I'll note that I while I am reproducing when building with LIBGIT2_SYS_USE_PKG_CONFIG=1 on amd64, the Debian cargo package on amd64 does not have the problem, even though it's built against the libgit2 system package, with the same version. Which is puzzling. Plus the fact that it does happen with the Debian cargo package on all other platforms, with the same libgit2 version too.

[alexcrichton]

git2-rs by default doesn't use pkg-config and opting in is allowed for packages who have verified that the version works, but it looks like that hasn't been done here?

In any case sounds like this is https://github.com/alexcrichton/git2-rs/issues/304, so I'm going to close in favor of that.