Failed to get source from registry

[hh9527]

I use cargo fetch --verbose and got:

Downloading bitflags v0.1.1
unable to get packages from source


Caused by:
  Failed to download package `bitflags v0.1.1` from https://crates.io/api/v1/crates/bitflags/0.1.1/download

Caused by:
  Failed to verify the checksum of `bitflags v0.1.1`

And use curl -v https://crates.io/api/v1/crates/bitflags/0.1.1/download, and got following result:

* Hostname was NOT found in DNS cache
*   Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 8880 (#0)
* Establish HTTP proxy tunnel to crates.io:443
> CONNECT crates.io:443 HTTP/1.1
> Host: crates.io:443
> User-Agent: curl/7.35.0
> Proxy-Connection: Keep-Alive
> 
< HTTP/1.0 200 Connection established
< Connection: close
< 
* Proxy replied OK to CONNECT request
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using ECDHE-RSA-AES128-GCM-SHA256
* Server certificate:
*    subject: OU=GT87339749; OU=See www.rapidssl.com/resources/cps (c)14; OU=Domain Control Validated - RapidSSL(R); CN=crates.io
*    start date: 2014-11-06 11:11:23 GMT
*    expire date: 2015-11-09 14:30:14 GMT
*    subjectAltName: crates.io matched
*    issuer: C=US; O=GeoTrust Inc.; CN=RapidSSL SHA256 CA - G3
*    SSL certificate verify ok.
> GET /api/v1/crates/bitflags/0.1.1/download HTTP/1.1
> User-Agent: curl/7.35.0
> Host: crates.io
> Accept: */*
> 
< HTTP/1.1 302 Found
< Connection: keep-alive
* Server nginx is not blacklisted
< Server: nginx
< Date: Tue, 10 Mar 2015 12:48:03 GMT
< Transfer-Encoding: chunked
< Location: https://crates-io.s3-us-west-1.amazonaws.com/crates/bitflags/bitflags-0.1.1.crate
< Set-Cookie: cargo_session=--3c156d7a3629aa08a1a0d538832f99ea30835cc8; HttpOnly; Secure; Path=/
< Strict-Transport-Security: max-age=31536000
< Via: 1.1 vegur
< 
* Connection #0 to host 127.0.0.1 left intact

[hh9527]

Additional information: I use cntlm at localhost to bridge to my company's windows proxy.

cat ~/.cargo/config

[http]
proxy = "http://127.0.0.1:8880/"

[https]
proxy = "http://127.0.0.1:8880/"

And curl/git works well.

[alexcrichton]

Hm, this could be a legitimate download error or some form of corruption. If you download manually and then check the file in ~/.cargo/registry are they actually the same file?

[hh9527]

@alexcrichton
It seemed that no file existed in ~/.cargo/registry/cache.
I use ls -R ~/.cargo/registry/cache and got

.cargo/registry/cache:
github.com-1ecc6299db9ec823

.cargo/registry/cache/github.1485827954.workers.dev-1ecc6299db9ec823:

And I use curl -k https://crates.io/api/v1/crates/bitflags/0.1.1/download got nothing.
But if I use wget https://crates.io/api/v1/crates/bitflags/0.1.1/download, it seemed got a corrected tar file.

[alexcrichton]

Oh right we don't actually write out the file until we've verified the contents. Alas :(

[hh9527]

@alexcrichton

More, after I curl -v https://crates.io/api/v1/crates/bitflags/0.1.1/download, I got

...
HTTP/1.1 302 Found
...
Location: https://crates-io.s3-us-west-1.amazonaws.com/crates/bitflags/bitflags-0.1.1.crate
...

And then, I use curl https://crates-io.s3-us-west-1.amazonaws.com/crates/bitflags/bitflags-0.1.1.crate, It seemed got the right file either.

So, what information can I show you to locate the issue?

[alexcrichton]

Unfortunately I think debugging this issue would require modifications to Cargo itself and a reliable way to reproduce :(

[hh9527]

@alexcrichton
I tried to compile cargo by myself, I thought that would help to locate the issue. But the compiling process also needs to fetch sources from the registry, and of course, this failed.

Can you tell me how the sources fetched from registry organized int ~/.cargo/ ? I think i could manual download the files and rename them as cargo expect. And then I can compile cargo, and do some hack on its source to help locating the issue.

[alexcrichton]

Right now it would be pretty difficult to set it up manually as there's lots of hashes in filenames here and there. Is this error specific to your machine or perhaps a particular network?

[yonkeltron]

I can confirm this issue on my Mac. Running OSX Mavericks 10.9.5:

$ uname -a
Darwin REDACTED.local 13.4.0 Darwin Kernel Version 13.4.0: Wed Mar 18 16:20:14 PDT 2015; root:xnu-2422.115.14~1/RELEASE_X86_64 x86_64

The error I get:

$ cargo build --verbose
 Downloading libc v0.1.8
Unable to get packages from source

Caused by:
  Failed to download package `libc v0.1.8` from https://crates.io/api/v1/crates/libc/0.1.8/download

Caused by:
  Failed to verify the checksum of `libc v0.1.8`

Also connected via VPN (Cisco AnyConnect) and behind a proxy/firewall. Please let me know if I can provide any additional information.

[alexcrichton]

@yonkeltron that looks like the Cargo may not be playing well with the proxy, are you sure it's configured correctly?

[yonkeltron]

@alexcrichton yes, the VPN/Firewall is configured just fine and I don't have any issues with other traffic or sites. I can browse crates.io without issue, it's only cargo build that fails. I am on a corporate network and my concern is that if cargo can't deal with setups like this, it could hamper enterprise adoption.

[alexcrichton]

@yonkeltron well let's not jump to conclusions! Cargo most certainly wants to accommodate all forms of network environments, this is just perhaps a bug in Cargo itself. Unfortunately this is going to be very difficult to fix as I can't reproduce this.

[yonkeltron]

@alexcrichton no conclusions yet, got it. So what can we do to debug this issue? There's a limit to how much information I'm permitted to share regarding the corporate network but I am willing to try as much as I can on my end. Is there anything I can do to enable additional diagnostic output from cargo? Is there a log file somewhere?

[alexcrichton]

Is it possible for you to recompile Cargo? Currently these transient errors are intentionally never written to disk, but if you can move this line above this line then you should be be able to see what Cargo downloaded (which may be corrupted).

[southerngs]

@alexcrichton I'm having a similar problem (also behind a firewall). But when I try to build Cargo I'm getting an error when the build process uses the snapshot version of cargo itself during the build process. Rerunning with the cargo build command with --verbose shows the same error that I'm trying to debug in the first place.

 target/snapshot/cargo/bin/cargo build --target x86_64-unknown-linux-gnu --verbose
 Downloading bufstream v0.1.1
Unable to get packages from source

Caused by:
  Failed to download package `bufstream v0.1.1` from https://crates.io/api/v1/crates/bufstream/0.1.1/download

Caused by:
  Failed to verify the checksum of `bufstream v0.1.1`

I was wondering if you had any suggestions for other steps to try.