On 13. 1. 2022, at 2:56, Kasper Daniel Hansen <kasperdanielhansen at gmail.com> wrote:
I am not an expert, but it seems to me that switching the backend is a
runtime setting. Couldn't we detect which version of OS X we're running and
then select the backend conditionally on that test?
Best,
Kasper
On Wed, Jan 12, 2022 at 5:12 PM Jeroen Ooms <jeroenooms at gmail.com> wrote:
On Wed, Jan 12, 2022 at 10:05 PM Simon Urbanek
<simon.urbanek at r-project.org> wrote:
Yes, but if you are using an old version of R on a new system, you have
a lot of other worries - you can't expect new technologies to work with old
software. CURL itself has fewer evolution issues than SSL libraries. As I
said, I am a big proponent of re-using system libraries as much as
possible, but, for example, High Sierra doesn't ship with ST back-end
support, so using a static version that does is better there as Apple
doesn't not maintain the curl CAs but it does the system ones so it's
arguably better. The current issue is quite curious since breaking on the
latest system is quite unusual, just preferring ST works only because it is
the latest system that breaks and it has the ST option.
As Brian pointed out static curl has its own issues since its pkg-config
flags are broken - that's why I have not activated the add-on recipes by
default, I have seen those issues before.
For R itself there are thee options:
a) add CURL_SSL_BACKEND=${CURL_SSL_BACKEND-'SecureTransport'} to
$R_HOME/etc/Renviron of the distribution
b) add something like your
c) build against static libcurl
The big advantage of the first one is that it applies to all processes,
so even command line curl will then work and so will all packages.
The drawback of the second one is that it only applies the R itself. The
third one could be done both for R and packages, but causes headaches resp.
requires slight patching of libcurl.pc. The advantage is that it can bring
more recent curl to all older systems.
I don't have a strong opinion. I am not thrilled with option b) because
that is a hack just to react to something which is never a good idea from
maintenance point of view (we would require all curl-based code to use it).
So I think a) and c) are more palatable with a) having the benefit of
handling non-R cases. A slight benefit of c) is that some dependencies
require more recent curl version than provided by older systems, so that
would cover it at the cost of maintaining the curl binaries. Finally, the
real benefit of c) is that if Apple screws things up even more we don't
care - we may not be at that point yet, though.
I don't think apple screwed up per se; they probably tested several
configurations and picked this one to be the safest default. TLS is a
complex protocol with many versions and implementations; if some weird
server uses some non-standard cipher or unusual response, it may just
depend on the TLS library if it can handle that. I'm sure you'll be
able to find counter examples where libre/openssl works and
SecureTransport does not. For example, a case that we often encounter
on Windows are corporate networks which require connecting via
authenticated proxy servers or using a TLS client cert, which only
works on certain back-ends, see the table in:
https://cran.r-project.org/web/packages/curl/vignettes/windows.html
So I much favor of option A. This introduces the least complexity, and
keeps the ability for users to undo our change and switch back to
CURL_SSL_BACKEND=openssl in their .Renviron. Also it is a big benefit
in practice that curl in R behaves the same as command line curl on
that same machine, in order to narrow down if a connection problem is
a bug in our R code, or if it also exists outside of R.