Cannot get sources from https://crates.io as curl fails the certificate check #976
Comments
|
Interesting! It's always a fun time linking openssl :) The code in question for this sort of probe is in the openssl-sys crate which we then leverage in curl-rust by default. So, in light of this information, I have a few questions:
Thanks for opening an issue! |
So opening
Here it opens |
|
I cannot reproduce the issue on CentOS 7 nor on Fedora 20, so this is an Arch Linux specific issue. Here is the relevant strace output for CentOS 7 (Fedora 20 is similar): |
|
Is Rust recursively following symbolic links? Here we have: |
|
Would you be able to build cargo from source to test out a change? I would be curious if this diff applied to openssl-sys would work for you: diff --git a/openssl-sys/src/probe.rs b/openssl-sys/src/probe.rs
index fc16202..10ad899 100644
--- a/openssl-sys/src/probe.rs
+++ b/openssl-sys/src/probe.rs
@@ -66,7 +66,7 @@ pub fn probe() -> ProbeResult {
}
fn try(dst: &mut Option<Path>, val: Path) {
- if dst.is_none() && val.exists() {
+ if val.exists() {
*dst = Some(val);
}
} You could build cargo with that patch via: |
|
Unfortunately, I followed your instructions and I ran into the same error while trying to build cargo :(. So this is really strange and looks like an Arch Linux bug. I'll report this asap and will report back here. I'm now hitting another bug (which still prevents me from trying your patch) but I'll make another bug report tomorrow. |
|
I'll note that we're doing somewhat sketchy things with openssl (we're linking it statically in the nightly distribution) which may not be kosher on all platforms, so it may not necessarily be a bug with Arch. I also just realized, can you try running |
|
Well, I've tried every combination I could think of and the only one working is: |
|
My other bug is rust-lang/rust#16402, which is unrelated. |
|
Hm interesting! We may just be missing some option to libcurl, do you know if that |
|
It does not seem that email-ca-bundle.pem is linked from somewhere else. Anyway, the issue is now resolved for me as the updated ca-certificates-utils-20140923-7.1 package from Arch Linux creates all the symlinks expected by openssl/curl in cargo, and thus fixes this bug. |
|
Ok, thanks for looking into this @Siosm! |
|
I would like to reopen this issue because I think that I have found the underlying issue. It looks like cargo is affected by this openssl bug: https://bugzilla.redhat.com/show_bug.cgi?id=1144808, which has only been recently been fixed in openssl 1.0.2b (see discussions and similar issues at https://gist.github.com/grawity/15eabf67191e17080241, https://bugs.archlinux.org/task/42921). Both the stable (OpenSSL 1.0.1i 6 Aug 2014) and latest nightly (OpenSSL 1.0.2a 19 Mar 2015) cargo builds are affected by this. As the openssl issue has been fixed in Arch Linux, the old certificates were removed (https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/nss&id=d0ccc2d596f2414eb277aead14233a5cf06cbef5) thus I had this issue again using cargo. The issue #1689 might also be a duplicate of this one. A "simple" fix would be to rebuild cargo against openssl 1.0.2b or superior. In the mean time, manually re-adding the old certificates to the trust store will work as a workaround. Another way to fix this would be to remove the old certificate from the certificate list sent by the server hosting crates.io, but this may prevent some clients on old systems without the updated certificate from connecting to it. |
|
Note: the ca-certificate-mozilla package update is currently in the testing repository on Arch Linux. Workaround example on Arch Linux:
|
|
Wow, thanks for the thorough investigation @Siosm! I'll try to update OpenSSL on the bots soon. |
|
Deployed! The next nightlies should have the updated version of OpenSSL. |
|
NixOS (nixos.org) is also affected by this issue. Shall wait for the update or do it myself, @Siosm great job on the recon. |
|
@sjmackenzie using the cargoSnapshot binary works if you patch it to a newer version: If you find a real fix please give a notice. I can't seem to fix it by building cargo with the newest openssl. |
|
@globin Thanks for the info! If you couldn't get it solved after trying the newest openssl, I've very curious to see if this issue is solved in other distros. btw I'm using it w.r.t. building It throws this error: |
|
It fails for any crate because of certificate failure with Amazon S3, curl does, too: |
|
I'm experiencing the same problem with a Ubuntu 14.04.1 system. I'm trying to figure out if there's a problem with my local configuration or if the problem is with Amazon S3 (or somewhere else). |
|
Just to add, working for me now on Arch Linux x86_64 (4 hours fresh install): Version below did not work: |
|
I tried on two other systems this evening (one Ubuntu 12.04 and one Arch Linux) and was not able to reproduce the problem. The system that I have the problem with is behind a firewall and requires use of a proxy server (the ones that work are not). I thought I would add this information in case anyone else sees this issue. Also in all cases I'm testing with the release 1.0 version of Rust and included Cargo ( |
|
I am also on Arch Linux and I have the same issue on stable that uses But it's gone on the beta version that uses So I guess I will have to stick to the beta version for the next couple of weeks until it moves to stable |
|
On Archlinux as well, I didn't use Rust for about a month when it was working and i am now running into the issue, same after running a rustup to get 1.1: I'll try @Siosm workaround when I have time |
|
Just to note cargo Binaries are available here: |
|
As far as I'm concerned, this issue is only affecting the stable 1.0 and 1.1 releases. The 1.2 beta and nightly releases are working for me. |
|
Same here (works on 1.2 beta and 1.3 nightly; breaks on stable 1.1). |
|
So the NixOS community have updated rust and it's without problem. I'm running |
|
It seems to now work for me, only did a pacman -Syu, nothing related to rust |
Update snapshot to avoid rust-lang/cargo#976, which otherwise breaks the build. Also move the `cargoSnapshot` derivation inside a set in pkgs/top-level/all-packages.nix in order to hide the `cargo-snapshot` packages from `nix-env -qa`, since it's only used to build the `cargo` package.
Update snapshot to avoid rust-lang/cargo#976, which otherwise breaks the build. Also move the `cargoSnapshot` derivation inside a set in pkgs/top-level/all-packages.nix in order to hide the `cargo-snapshot` packages from `nix-env -qa`, since it's only used to build the `cargo` package.
|
I get this error trying to work through the guessing game toy program in the docs: I'm only using a nightly because I had the problem initially with Rust 1.1 and I switched to a nightly, thinking it might be fixed there... Fetching libc by hand with curl seems fine: |
Update snapshot to avoid rust-lang/cargo#976, which otherwise breaks the build. Also move the `cargoSnapshot` derivation inside a set in pkgs/top-level/all-packages.nix in order to hide the `cargo-snapshot` packages from `nix-env -qa`, since it's only used to build the `cargo` package.
Building any project with dependencies on crates.io, with the latest nightly, on Arch Linux, ends with this error:
Sample Cargo.toml reproducing the issue:
And version info:
Using curl manually gives the following output:
And tracing cargo build with strace gives:
So it looks like the curl module is not looking at the correct place for certificate checking and so far my attempts to use environment variables such as
CURL_CA_BUNDLEhave been unsuccessful with cargo.This may be a rust-curl bug but I can't confirm this because trying to build a minimal example with the curl-rust crate using cargo fails with the same error :(.
The text was updated successfully, but these errors were encountered: