tidy-up: adjust casing of project names

Mostly TLS/SSH project name.

Closes #14160

docs/CIPHERS.md

@@ -171,7 +171,7 @@ When specifying multiple cipher names, separate them with colon (`:`).
 `TLS_AES_128_CCM_8_SHA256`
 `TLS_AES_128_CCM_SHA256`
 
-## WolfSSL
+## wolfSSL
 
 `RC4-SHA`,
 `RC4-MD5`,

docs/CURLDOWN.md

@@ -97,7 +97,7 @@ option. The available TLS backends are:
 - `BearSSL`
 - `GnuTLS`
 - `mbedTLS`
-- `OpenSSL` (also covers BoringSSL, libressl, quictls, AWS-LC and AmiSSL)
+- `OpenSSL` (also covers BoringSSL, LibreSSL, quictls, AWS-LC and AmiSSL)
 - `rustls`
 - `Schannel`
 - `Secure Transport`

docs/ECH.md

@@ -8,7 +8,7 @@ SPDX-License-Identifier: curl
 
 We have added support for ECH to curl. It can use HTTPS RRs published in the
 DNS if curl uses DoH, or else can accept the relevant ECHConfigList values
-from the command line. This works with OpenSSL, WolfSSL or boringssl as the
+from the command line. This works with OpenSSL, wolfSSL or BoringSSL as the
 TLS provider.
 
 This feature is EXPERIMENTAL. DO NOT USE IN PRODUCTION.
@@ -149,7 +149,7 @@ the verbose output, e.g.:
 ```
 
 At that point, you could copy the base64 encoded value above and try again.
-For now, this only works for the OpenSSL and boringssl builds.
+For now, this only works for the OpenSSL and BoringSSL builds.
 
 ## Default settings
 
@@ -306,7 +306,7 @@ To build with cmake, assuming our ECH-enabled OpenSSL is as before:
 The binary produced by the cmake build does not need any ECH-specific
 ``LD_LIBRARY_PATH`` setting.
 
-## boringssl build
+## BoringSSL build
 
 BoringSSL is also supported by curl and also supports ECH, so to build
 with that, instead of our ECH-enabled OpenSSL:
@@ -334,16 +334,16 @@ Then:
     make
 ```
 
-The boringssl APIs are fairly similar to those in our ECH-enabled OpenSSL
+The BoringSSL APIs are fairly similar to those in our ECH-enabled OpenSSL
 fork, so code changes are also in ``lib/vtls/openssl.c``, protected
 via ``#ifdef OPENSSL_IS_BORINGSSL`` and are mostly obvious API variations.
 
-The boringssl APIs however do not support the ``--ech pn:`` command line
+The BoringSSL APIs however do not support the ``--ech pn:`` command line
 variant as of now.
 
-## WolfSSL build
+## wolfSSL build
 
-WolfSSL also supports ECH and can be used by curl, so here's how:
+wolfSSL also supports ECH and can be used by curl, so here's how:
 
 ```bash
     cd $HOME/code
@@ -355,7 +355,7 @@ WolfSSL also supports ECH and can be used by curl, so here's how:
     make install
 ```
 
-The install prefix (``inst``) in the above causes WolfSSL to be installed there
+The install prefix (``inst``) in the above causes wolfSSL to be installed there
 and we seem to need that for the curl configure command to work out. The
 ``--enable-opensslextra`` turns out (after much faffing about;-) to be
 important or else we get build problems with curl below.
@@ -369,7 +369,7 @@ important or else we get build problems with curl below.
     make
 ```
 
-There are some known issues with the ECH implementation in WolfSSL:
+There are some known issues with the ECH implementation in wolfSSL:
 
 - The main issue is that the client currently handles HelloRetryRequest
   incorrectly.  [HRR issue](https://github.com/wolfSSL/wolfssl/issues/6802).)
@@ -379,29 +379,29 @@ There are some known issues with the ECH implementation in WolfSSL:
 - There is also an issue related to so-called middlebox compatibility mode.
   [middlebox compatibility issue](https://github.com/wolfSSL/wolfssl/issues/6774)
 
-### Code changes to support WolfSSL
+### Code changes to support wolfSSL
 
 There are what seem like oddball differences:
 
 - The DoH URL in``$HOME/.curlrc`` can use `1.1.1.1` for OpenSSL but has to be
-  `one.one.one.one` for WolfSSL. The latter works for both, so OK, we us that.
-- There seems to be some difference in CA databases too - the WolfSSL version
+  `one.one.one.one` for wolfSSL. The latter works for both, so OK, we us that.
+- There seems to be some difference in CA databases too - the wolfSSL version
   does not like ``defo.ie``, whereas the system and OpenSSL ones do. We can
   ignore that for our purposes via ``--insecure``/``-k`` but would need to fix
   for a real setup. (Browsers do like those certificates though.)
 
 Then there are some functional code changes:
 
-- tweak to ``configure.ac`` to check if WolfSSL has ECH or not
+- tweak to ``configure.ac`` to check if wolfSSL has ECH or not
 - added code to ``lib/vtls/wolfssl.c`` mirroring what's done in the
   OpenSSL equivalent above.
-- WolfSSL does not support ``--ech false`` or the ``--ech pn:`` command line
+- wolfSSL does not support ``--ech false`` or the ``--ech pn:`` command line
   argument.
 
 The lack of support for ``--ech false`` is because wolfSSL has decided to
 always at least GREASE if built to support ECH. In other words, GREASE is
 a compile time choice for wolfSSL, but a runtime choice for OpenSSL or
-boringssl. (Both are reasonable.)
+BoringSSL. (Both are reasonable.)
 
 ## Additional notes
 
@@ -474,5 +474,5 @@ to get the HTTPS RR and pass the ECHConfigList from that on the command line,
 if needed, or one can access the value from command line output in verbose more
 and then re-use that in another invocation.
 
-Both our OpenSSL fork and boringssl have APIs for both controlling GREASE and
-accessing and logging ``retry_configs``, it seems WolfSSL has neither.
+Both our OpenSSL fork and BoringSSL have APIs for both controlling GREASE and
+accessing and logging ``retry_configs``, it seems wolfSSL has neither.

docs/FAQ

@@ -423,7 +423,7 @@ FAQ
   backends.
 
   curl can be built to use one of the following SSL alternatives: OpenSSL,
-  libressl, BoringSSL, AWS-LC, GnuTLS, wolfSSL, mbedTLS, Secure Transport
+  LibreSSL, BoringSSL, AWS-LC, GnuTLS, wolfSSL, mbedTLS, Secure Transport
   (native iOS/OS X), Schannel (native Windows), BearSSL or Rustls. They all
   have their pros and cons, and we try to maintain a comparison of them here:
   https://curl.se/docs/ssl-compared.html

docs/HISTORY.md

@@ -286,7 +286,7 @@ August:
 
 February: added support for the axTLS backend
 
-April: added the cyassl backend (later renamed to WolfSSL)
+April: added the cyassl backend (later renamed to wolfSSL)
 
 2012
 ----

docs/HTTP2.md

@@ -13,7 +13,7 @@ HTTP/2 with curl
 Build prerequisites
 -------------------
   - nghttp2
-  - OpenSSL, libressl, BoringSSL, GnuTLS, mbedTLS, wolfSSL or Schannel
+  - OpenSSL, LibreSSL, BoringSSL, GnuTLS, mbedTLS, wolfSSL or Schannel
     with a new enough version.
 
 [nghttp2](https://nghttp2.org/)

docs/INSTALL-CMAKE.md

@@ -22,7 +22,7 @@ Missing features in the CMake build:
 
  - Builds libcurl without large file support
  - Does not support all SSL libraries (only OpenSSL, Schannel, Secure
-   Transport, and mbedTLS, WolfSSL)
+   Transport, and mbedTLS, wolfSSL)
  - Does not allow different resolver backends (no c-ares build support)
  - No RTMP support built
  - Does not allow build curl and libcurl debug enabled

docs/INSTALL.md

@@ -140,7 +140,7 @@ These options are provided to select the TLS backend to use.
  - BearSSL: `--with-bearssl`
  - GnuTLS: `--with-gnutls`.
  - mbedTLS: `--with-mbedtls`
- - OpenSSL: `--with-openssl` (also for BoringSSL, AWS-LC, libressl, and quictls)
+ - OpenSSL: `--with-openssl` (also for BoringSSL, AWS-LC, LibreSSL, and quictls)
  - rustls: `--with-rustls`
  - Schannel: `--with-schannel`
  - Secure Transport: `--with-secure-transport`

docs/examples/Makefile.example

@@ -36,7 +36,7 @@ CFLAGS = -c -g
 
 # This should point to a directory that holds libcurl, if it is not
 # in the system's standard lib dir
-# We also set a -L to include the directory where we have the openssl
+# We also set a -L to include the directory where we have the OpenSSL
 # libraries
 LDFLAGS = -L/home/dast/lib -L/usr/local/ssl/lib
 

docs/examples/usercertinmem.c

@@ -157,7 +157,7 @@ static CURLcode sslctx_function(CURL *curl, void *sslctx, void *parm)
     printf("Use Key failed\n");
   }
 
-  /* free resources that have been allocated by openssl functions */
+  /* free resources that have been allocated by OpenSSL functions */
   if(bio)
     BIO_free(bio);
 

docs/libcurl/curl_global_sslset.md

@@ -66,7 +66,7 @@ This does not just mean no other thread that is using libcurl.
 # OpenSSL
 
 The name "OpenSSL" is used for all versions of OpenSSL and its associated
-forks/flavors in this function. OpenSSL, BoringSSL, libressl, quictls and
+forks/flavors in this function. OpenSSL, BoringSSL, LibreSSL, quictls and
 AmiSSL are all supported by libcurl, but in the eyes of
 curl_global_sslset(3) they are all just "OpenSSL". They all mostly
 provide the same API.

docs/libcurl/opts/CURLINFO_SSL_VERIFYRESULT.md

@@ -68,7 +68,7 @@ int main(void)
 
 # AVAILABILITY
 
-Added in 7.5. Only set by the OpenSSL/libressl/boringssl and GnuTLS backends.
+Added in 7.5. Only set by the OpenSSL/LibreSSL/BoringSSL and GnuTLS backends.
 
 # RETURN VALUE
 

docs/libcurl/opts/CURLOPT_PROXY_SSLVERSION.md

@@ -65,7 +65,7 @@ TLSv1.3
 The maximum TLS version can be set by using *one* of the CURL_SSLVERSION_MAX_
 macros below. It is also possible to OR *one* of the CURL_SSLVERSION_ macros
 with *one* of the CURL_SSLVERSION_MAX_ macros. The MAX macros are not
-supported for WolfSSL.
+supported for wolfSSL.
 
 ## CURL_SSLVERSION_MAX_DEFAULT
 

docs/libcurl/opts/CURLOPT_PROXY_SSL_CIPHER_LIST.md

@@ -47,7 +47,7 @@ For OpenSSL and GnuTLS valid examples of cipher lists include **RC4-SHA**,
 **SHA1+DES**, **TLSv1** and **DEFAULT**. The default list is normally
 set when you compile OpenSSL.
 
-For WolfSSL, valid examples of cipher lists include **ECDHE-RSA-RC4-SHA**,
+For wolfSSL, valid examples of cipher lists include **ECDHE-RSA-RC4-SHA**,
 **AES256-SHA:AES256-SHA256**, etc.
 
 For mbedTLS and BearSSL, valid examples of cipher lists include

docs/libcurl/opts/CURLOPT_SSLVERSION.md

@@ -76,7 +76,7 @@ TLS v1.3 or later (Added in 7.52.0)
 The maximum TLS version can be set by using *one* of the
 CURL_SSLVERSION_MAX_ macros below. It is also possible to OR *one* of the
 CURL_SSLVERSION_ macros with *one* of the CURL_SSLVERSION_MAX_ macros.
-The MAX macros are not supported for WolfSSL.
+The MAX macros are not supported for wolfSSL.
 
 ## CURL_SSLVERSION_MAX_DEFAULT
 

docs/libcurl/opts/CURLOPT_SSL_CIPHER_LIST.md

@@ -46,7 +46,7 @@ For OpenSSL and GnuTLS valid examples of cipher lists include **RC4-SHA**,
 **SHA1+DES**, **TLSv1** and **DEFAULT**. The default list is normally set when
 you compile OpenSSL.
 
-For WolfSSL, valid examples of cipher lists include **ECDHE-RSA-RC4-SHA**,
+For wolfSSL, valid examples of cipher lists include **ECDHE-RSA-RC4-SHA**,
 **AES256-SHA:AES256-SHA256**, etc.
 
 For mbedTLS and BearSSL, valid examples of cipher lists include