aboutsummaryrefslogtreecommitdiff
path: root/docs/libcurl/libcurl-errors.3
diff options
context:
space:
mode:
authorJohannes Schindelin <johannes.schindelin@gmx.de>2017-06-14 16:56:00 +0200
committerDaniel Stenberg <daniel@haxx.se>2017-08-28 14:56:58 +0200
commitb0989cd3abaff4f9a0717b4875022fa79e33b481 (patch)
treee4b167c7695c675b788ea32704cdfd3e1b2f2468 /docs/libcurl/libcurl-errors.3
parenta53bda35e9a2acf4f2432b2d1b2d44497d68971e (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/libcurl-errors.3')
0 files changed, 0 insertions, 0 deletions