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?
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:
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:
* 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:
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.
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.
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
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.
Apologies for the delay in getting back to you on this. It's a TLS inspection/pinning issue, which is fixable. Funny enough, cloud.project.org stopped working shortly after I got packagemanager.posit.co up running. It's probably a combination of both sides updating their requirements. I verified that cran.rstudio.com worked but cran.r-project.org failed.
Does Posit have a list of all the domains/subdomains used by packages/apps that is under the Posit umbrella? It's possible to wildcard the domains, but every network administrator seems to caution that wildcards may not always work.
It would be great if this could be extended out to affiliated software because I ran into a bunch of issues with Rig (love Rig btw). I think Rig checks r-hub.io to get R installation information and then uses r-project.org to install R.
I have a feeling that it would make our IT team much happier with me if I could provide them with a list rather than opening up tickets each time. Let me know if you have any questions.
I'm not sure but I can ask around. At least I know of *.rstudio.com, *.posit.co, cloud.r-project.org, and https://www.wyday.com if you're activating a Posit product with an online license key.
I'm less familiar with Rig and other packages, but that could also be a good question for the Rig repo if there's no existing documentation on internet connectivity requirements.
Thanks for adding this to the FAQ! I passed this along to our network team and will let you know if I run into any issues. Rig has been an absolute life changer!
