RStudio can't access Package Manager URL but I can with a browser

We recently started using renv, which automatically switched our package repo to Package Manager. This created an issue because for some reason RStudio can't access it when trying to install packages:

Warning: unable to access index for repository https://packagemanager.posit.co/cran/latest/src/contrib:
  cannot open URL 'https://packagemanager.posit.co/cran/latest/src/contrib/PACKAGES

I can open this URL via a browser with no problem as well as with httr2:

<httr2_response>
GET https://packagemanager.posit.co/cran/latest/src/contrib/PACKAGES
Status: 200 OK
Content-Type: text/plain
Body: In memory (4533467 bytes)

I don't have a problem downloading packages through CRAN, just with Package Manager. Would we expect it to fail using httr2 if it's failing to access the URL when downloading a package? Any thoughts on how I can troubleshoot this issue?

1 Like

Hi @jonbry, the difference here might be the download method used by renv vs. httr. So a couple questions to try and troubleshoot this:

  • Do you have a proxy in this environment where access to https://packagemanager.posit.co would fail if the proxy was not being used?
  • What is the download method configured as in R, which is what renv would be using? In R, what is the output of:
options("download.file.method", "download.file.extra")
  • If you haven't customized the download method in R, what do you get when you enable verbose debug logging and try to access that same URL with R's default download method:
options(internet.info = 1)
curlGetHeaders("https://packagemanager.posit.co/cran/latest/src/contrib/PACKAGES")

Hi Greg,

Thanks for the reply, sorry I didn't see this until now. I can access the URL from the browser, but not from RStudio, which is interesting. Here's the outputs:

$download.file.method
[1] "libcurl"

$download.file.extra
NULL

verbose:

* Host packagemanager.posit.co:443 was resolved.
* IPv6: (none)
* IPv4: 3.13.84.66, 18.221.97.138, 3.21.7.156
*   Trying 3.13.84.66:443...
* Connected to packagemanager.posit.co (3.13.84.66) port 443
* schannel: disabled automatic use of client certificate
* schannel: next InitializeSecurityContext failed: CRYPT_E_NO_REVOCATION_CHECK (0x80092012) - The revocation function was unable to check revocation for the certificate.
* Closing connection
* schannel: shutting down SSL/TLS connection with packagemanager.posit.co port 443
Error in curlGetHeaders("https://packagemanager.posit.co/cran/latest/src/contrib/PACKAGES") : 
  libcurl error code 35:
	schannel: next InitializeSecurityContext failed: CRYPT_E_NO_REVOCATION_CHECK (0x80092012) - The revocation function was unable to check revocation for the certificate.

Could this be a firewall issue? When I run the same code with cloud.r-project.org, it seems to recover after disabled automatic use of client certificate:

* schannel: renegotiating SSL/TLS connection
* schannel: SSL/TLS connection renegotiated
< HTTP/1.1 200 OK

Let me know if you have any questions.

Thank you!

Is this a Windows machine? We've seen similar errors before on Windows, specifically in corporate environments where a MITM proxy is being used: Workaround Found for "libcurl SSL errors on Windows"

There's an explanation of the issue here in the R manual, under Secure URLs: R: Download File from the Internet

On Windows with method = "libcurl", the CA root certificates are provided by the OS when R was linked with libcurl with Schannel enabled, which is the current default in Rtools. This can be verified by checking that libcurlVersion() returns a version string containing ‘⁠"Schannel"⁠’. If it does not, for verification to be on the environment variable CURL_CA_BUNDLE must be set to a path to a certificate bundle file, usually named ‘ca-bundle.crt’ or ‘curl-ca-bundle.crt’. (This is normally done automatically for a binary installation of R, which installs ‘R_HOME/etc/curl-ca-bundle.crt’ and sets CURL_CA_BUNDLE to point to it if that environment variable is not already set.) For an updated certificate bundle, see curl - SSL CA Certificates. Currently one can download a copy from https://raw.githubusercontent.com/bagder/ca-bundle/master/ca-bundle.crt and set CURL_CA_BUNDLE to the full path to the downloaded file.

On Windows with method = "libcurl", when R was linked with libcurl with Schannel enabled, the connection fails if it cannot be established that the certificate has not been revoked. Some MITM proxies present particularly in corporate environments do not work with this behavior. It can be changed by setting environment variable R_LIBCURL_SSL_REVOKE_BEST_EFFORT to TRUE, with the consequence of reducing security.

One workaround would be to set the environment variable mentioned, R_LIBCURL_SSL_REVOKE_BEST_EFFORT to TRUE, with the drawback of reduced security.

Another option that might work is to change the default download method from libcurl to curl using options(download.file.method = "curl"). That would shell out to curl if available on the system, and might bypass the issue with R's version of libcurl.

1 Like

Yep, this is a both a Windows and a corporate environment, which likely does TLS inspection. It's interesting that the default repo for install.packages() doesn't have this same problem.

I'll work on resolving this with our network team. In the meantime, I'll test the other methods to see if it works.

Thanks for all your help!

1 Like

I don't understand why it works for https://cloud.r-project.org either. I feel like the issue would be affecting all sites equally :thinking:

If you find out the reason why, maybe from talking with the network team, that would be really useful to know. Also could be interesting to try other CRAN mirror URLs like https://cran.rstudio.com or https://cran.r-project.org.