download.file strict certificate revocation check

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>