diff options
author | Johannes Schindelin <johannes.schindelin@gmx.de> | 2017-06-14 16:56:00 +0200 |
---|---|---|
committer | Daniel Stenberg <daniel@haxx.se> | 2017-08-28 14:56:58 +0200 |
commit | b0989cd3abaff4f9a0717b4875022fa79e33b481 (patch) | |
tree | e4b167c7695c675b788ea32704cdfd3e1b2f2468 /docs/libcurl/opts/CURLOPT_REQUEST_TARGET.3 | |
parent | a53bda35e9a2acf4f2432b2d1b2d44497d68971e (diff) |
vtls: allow selecting which SSL backend to use at runtime
When building software for the masses, it is sometimes not possible to
decide for all users which SSL backend is appropriate.
Git for Windows, for example, uses cURL to perform clones, fetches and
pushes via HTTPS, and some users strongly prefer OpenSSL, while other
users really need to use Secure Channel because it offers
enterprise-ready tools to manage credentials via Windows' Credential
Store.
The current Git for Windows versions use the ugly work-around of
building libcurl once with OpenSSL support and once with Secure Channel
support, and switching out the binaries in the installer depending on
the user's choice.
Needless to say, this is a super ugly workaround that actually only
works in some cases: Git for Windows also comes in a portable form, and
in a form intended for third-party applications requiring Git
functionality, in which cases this "swap out libcurl-4.dll" simply is
not an option.
Therefore, the Git for Windows project has a vested interest in teaching
cURL to make the SSL backend a *runtime* option.
This patch makes that possible.
By running ./configure with multiple --with-<backend> options, cURL will
be built with multiple backends.
For the moment, the backend can be configured using the environment
variable CURL_SSL_BACKEND (valid values are e.g. "openssl" and
"schannel").
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Diffstat (limited to 'docs/libcurl/opts/CURLOPT_REQUEST_TARGET.3')
0 files changed, 0 insertions, 0 deletions