R help - Oct 2023 - download.file strict certificate revocation check

? Wed, 4 Oct 2023 13:09:47 +0000
John Neset <John.Neset at noridian.com> ?????:
> Trying to do this, reference FAQ-
> 2.18 The Internet download functions fail.
> (c) A MITM proxy (typically in enterprise environments) makes it
> impossible to validate that certificates haven't been revoked. One
> can switch to only best effort revocation checks via an environment
> variable: see ?download.file.
Here's what help(download.file) has to say:
>>     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.
Does it help to Sys.setenv(...) this environment variable before
downloading? If not, please provide your sessionInfo() and the full
error message.

-- 
Best regards,
Ivan

Ivan,
SSL connect error & we definitely have MITM doing certificate interference.
No change with True or False with R_LIBCURL_SSL_REVOKE_BEST_EFFORT
Environment variable results should be attached.

-----Original Message-----
From: Ivan Krylov <krylov.r00t at gmail.com>
Sent: Wednesday, October 4, 2023 8:52 AM
To: John Neset <John.Neset at noridian.com>
Cc: r-help at R-project.org
Subject: Re: [R] download.file strict certificate revocation check

WARNING: This is an external email.
Do not click links or open attachments unless you recognize the sender and know
the content is safe.



? Wed, 4 Oct 2023 13:09:47 +0000
John Neset <John.Neset at noridian.com> ?????:
> Trying to do this, reference FAQ-
> 2.18 The Internet download functions fail.
> (c) A MITM proxy (typically in enterprise environments) makes it
> impossible to validate that certificates haven't been revoked. One can
> switch to only best effort revocation checks via an environment
> variable: see ?download.file.
Here's what help(download.file) has to say:
>>     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.
Does it help to Sys.setenv(...) this environment variable before downloading? If
not, please provide your sessionInfo() and the full error message.

--
Best regards,
Ivan
Confidentiality Notice - This communication and any attachments are for the sole
use of the intended recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure, distribution or copying
is prohibited. If you are not the intended recipient(s), please contact the
sender by replying to this e-mail and destroy/delete all copies of this e-mail
message.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2023-10-04_09-30-52.png
Type: image/png
Size: 88749 bytes
Desc: 2023-10-04_09-30-52.png
URL:
<https://stat.ethz.ch/pipermail/r-help/attachments/20231004/bd523cf2/attachment.png>

? Wed, 4 Oct 2023 14:32:49 +0000
John Neset <John.Neset at noridian.com> ?????:
> No change with True or False with R_LIBCURL_SSL_REVOKE_BEST_EFFORT
Judging by the screenshot, it looks like you've set an R variable
R_LIBCURL_SSL_REVOKE_BEST_EFFORT instead of setting an environment
variable using Sys.setenv:

 Sys.setenv('R_LIBCURL_SSL_REVOKE_BEST_EFFORT' = 'TRUE')

(Use Sys.getenv to verify the result.)

For the next time, most people on the R-help mailing list would
probably appreciate it if you copied and pasted the text from the R
console instead of attaching screenshots.

-- 
Best regards,
Ivan