docs: correct language according to badwords

Closes #353

docs/CVE-2005-0490.md

@@ -25,7 +25,7 @@ CWE-121: Stack-based Buffer Overflow
 Severity: High
 
 (This flaw was originally treated as two separate ones by the curl project,
-but due to it using a single CVE number we've reconsidered.)
+but due to it using a single CVE number we have reconsidered.)
 
 AFFECTED VERSIONS
 -----------------

docs/CVE-2005-3185.md

@@ -8,14 +8,14 @@ VULNERABILITY
 -------------
 
 libcurl's NTLM function can overflow a stack-based buffer if given a too long
-user name or domain name. This would happen if you enable NTLM authentication
+username or domain name. This would happen if you enable NTLM authentication
 and either:
 
- A - pass in a user name and domain name to libcurl that together are longer
+ A - pass in a username and domain name to libcurl that together are longer
      than 192 bytes
 
  B - allow (lib)curl to follow HTTP "redirects" (Location: and the appropriate
-     HTTP 30x response code) and the new URL contains a URL with a user name
+     HTTP 30x response code) and the new URL contains a URL with a username
      and domain name that together are longer than 192 bytes
 
 INFO

docs/CVE-2006-1061.md

@@ -63,7 +63,7 @@ TIMELINE
 We were notified March 10, 2006. The notification email contained a valid
 patch.
 
-Daniel didn't read the mail until the 12th due to vacations.
+Daniel did not read the mail until the 12th due to vacations.
 
 curl 7.15.3 was released on March 20 2006, just before this flaw was
 publicly disclosed.

docs/CVE-2007-3564.md

@@ -8,8 +8,8 @@ VULNERABILITY
 -------------
 
 libcurl (when built to use GnuTLS) fails to verify that a peer's certificate
-hasn't already expired or hasn't yet become valid. This allows malicious
-servers to present certificates to libcurl that won't be rejected properly.
+has not already expired or has not yet become valid. This allows malicious
+servers to present certificates to libcurl that were not rejected properly.
 
 Notably, the CA certificate and common name checks are still in place which
 reduces the risk for random servers to take advantage of this flaw.

docs/CVE-2009-0037.md

@@ -7,10 +7,10 @@ Project curl Security Advisory, March 3rd 2009
 VULNERABILITY
 -------------
 
-When told to follow a "redirect" automatically, libcurl does not question
-the new target URL but will follow to any new URL that it understands. As
-libcurl supports FILE:// URLs, a rogue server can thus "trick" a
-libcurl-using application to read a local file instead of the remote one.
+When told to follow a "redirect" automatically, libcurl does not question the
+new target URL but follows it to any new URL that it understands. As libcurl
+supports FILE:// URLs, a rogue server can thus "trick" a libcurl-using
+application to read a local file instead of the remote one.
 
 This is a problem, for example, when the application is running on a server
 and is written to upload or to otherwise provide the transferred data to a
@@ -56,7 +56,7 @@ SOLUTION
 
 libcurl 7.19.4 introduces a new option called `CURLOPT_REDIR_PROTOCOLS`, which
 applications can use to tell libcurl what target protocols automatic redirect
-followings are allowed to use. This will by default exclude FILE and SCP URLs.
+followings are allowed to use. By default this excludes FILE and SCP URLs.
 
 - Fixed-in: https://github.com/curl/curl/commit/042cc1f69ec0878f542667cb6843
 

docs/CVE-2010-0734.md

@@ -8,10 +8,9 @@ VULNERABILITY
 -------------
 
 When downloading data, libcurl hands it over to the application using a
-callback that is registered by the client software. libcurl will then call
-that function repeatedly with data until the transfer is complete. The
-callback is documented to receive a maximum data size of 16K
-(`CURL_MAX_WRITE_SIZE`).
+callback that is registered by the client software. libcurl then calls that
+function repeatedly with data until the transfer is complete. The callback is
+documented to receive a maximum data size of 16K (`CURL_MAX_WRITE_SIZE`).
 
 Using the affected libcurl version to download compressed content over HTTP,
 an application can ask libcurl to automatically uncompress data. When doing

docs/CVE-2010-3842.md

@@ -8,17 +8,17 @@ VULNERABILITY
 -------------
 
 curl offers a command line option --remote-header-name (also usable as -J)
-which will use the file name of the Content-disposition: header when it
-saves the downloaded data locally.
+which uses the filename of the Content-disposition: header when it saves the
+downloaded data locally.
 
-curl attempts to cut off the directory parts from any given file name in the
-header to only store files in the current directory. It will overwrite a
+curl attempts to cut off the directory parts from any given filename in the
+header to only store files in the current directory. It might overwrite a
 local file using the same name as the header specifies.
 
 The stripping of the directory did not take backslashes into account. On
 some operating systems, backslashes are used to separate directories and
-file names. This allows a rogue server to send back a response that
-overwrites a file name in the local machine that the user is allowed to
+filenames. This allows a rogue server to send back a response that
+overwrites a filename in the local machine that the user is allowed to
 write, potentially a system file, a command or a known executable.
 
 Operating systems affected include Windows, Netware, MSDOS, OS/2 and
@@ -50,7 +50,7 @@ such.
 SOLUTION
 --------
 
-libcurl 7.21.2 makes sure that it will also strip off paths specified using
+libcurl 7.21.2 makes sure that it also strips off paths specified using
 backslashes as path separator.
 
 - Fixed-in: https://github.com/curl/curl/commit/81f151c912105ded480c3c88a1

docs/CVE-2011-2192.md

@@ -15,7 +15,7 @@ operation, which should only be done when the user explicitly so directs.
 
 The GSS/Negotiate feature is only used by libcurl for HTTP authentication if
 told to, and only if libcurl was built with a library that provides the
-GSSAPI. Many builds of libcurl don't have GSS enabled.
+GSSAPI. Many builds of libcurl do not have GSS enabled.
 
 INFO
 ----

docs/CVE-2011-3389.md

@@ -7,20 +7,20 @@ Project curl Security Advisory, January 24th 2012
 VULNERABILITY
 -------------
 
-  curl is vulnerable to a SSL CBC IV vulnerability when built to use OpenSSL
-  for the SSL/TLS layer.
+curl is vulnerable to a SSL CBC IV vulnerability when built to use OpenSSL for
+the SSL/TLS layer.
 
-  This vulnerability has been identified (CVE-2011-3389 aka the "BEAST"
-  attack) and is addressed by OpenSSL already as they have made a work-around
-  to mitigate the problem.  When doing so, they figured out that some servers
-  didn't work with the work-around and offered a way to disable it.
+This vulnerability has been identified (CVE-2011-3389 aka the "BEAST" attack)
+and is addressed by OpenSSL already as they have made a work-around to
+mitigate the problem. When doing so, they figured out that some servers did
+not work with the work-around and offered a way to disable it.
 
-  The bit used to disable the workaround was then added to the generic
-  `SSL_OP_ALL` bitmask that SSL clients may use to enable workarounds for
-  better compatibility with servers. libcurl uses the SSL_OP_ALL bitmask.
+The bit used to disable the workaround was then added to the generic
+`SSL_OP_ALL` bitmask that SSL clients may use to enable workarounds for better
+compatibility with servers. libcurl uses the SSL_OP_ALL bitmask.
 
-  While `SSL_OP_ALL` is documented to enable "rather harmless" workarounds, it
-  does in this case effectively enable this security vulnerability again.
+While `SSL_OP_ALL` is documented to enable "rather harmless" workarounds, it
+does in this case effectively enable this security vulnerability again.
 
 INFO
 ----

docs/CVE-2012-0036.md

@@ -14,10 +14,10 @@ When parsing URLs, libcurl's parser is liberal and only parses as little as
 possible and lets as much as possible through as long as it can figure out
 what to do.
 
-In the specific process when libcurl extracts the file path part from a
-given URL, it didn't always verify the data or escape control characters
-properly before it passed the file path on to the protocol-specific code
-that then would use it for its protocol business.
+In the specific process when libcurl extracts the file path part from a given
+URL, it did not always verify the data or escape control characters properly
+before it passed the file path on to the protocol-specific code that then
+would use it for its protocol business.
 
 This passing through of control characters could be exploited by someone who
 would be able to pass in a handcrafted URL to libcurl. Lots of libcurl
@@ -77,7 +77,7 @@ RECOMMENDATIONS
   C - Rebuild curl with support for vulnerable protocols IMAP, POP3 and SMTP
       disabled.
 
-  D - Disable the vulnerable protocols IMAP, POP3 and SMTP at run-time to
+  D - Disable the vulnerable protocols IMAP, POP3 and SMTP at runtime to
       forbid libcurl from using them. You can do this with the
       CURLOPT_PROTOCOLS option.
 

docs/CVE-2013-0249.md

@@ -50,7 +50,7 @@ AFFECTED VERSIONS
 SOLUTION
 --------
 
-  libcurl 7.29.0 implements proper bounds checking and will not overflow any
+  libcurl 7.29.0 implements proper bounds checking and does not overflow any
   buffers even if unrealistically long data chunks are received.
 
 - Fixed-in: https://github.com/curl/curl/commit/f206d6c055d1008f0edb6d5d
@@ -68,7 +68,7 @@ RECOMMENDATIONS
   C - Rebuild curl with support for vulnerable protocols IMAP, POP3 and SMTP
       disabled.
 
-  D - Disable the vulnerable protocols IMAP, POP3 and SMTP at run-time to
+  D - Disable the vulnerable protocols IMAP, POP3 and SMTP at runtime to
       forbid libcurl from using them. You can do this with the
       CURLOPT_PROTOCOLS option.
 

docs/CVE-2013-1944.md

@@ -11,8 +11,8 @@ VULNERABILITY
   across domains with matching tails.
 
   When communicating over HTTP(S) and having libcurl's cookie engine enabled,
-  libcurl will store and hold cookies for use when subsequent requests are
-  done to hosts and paths that match those kept cookies. Due to a bug in the
+  libcurl stores and holds cookies for use when subsequent requests are done
+  to hosts and paths that match those kept cookies. Due to a bug in the
   tailmatching function, libcurl could wrongly send cookies meant for the
   domain 'ample.com' when communicating with 'example.com'.
 
@@ -44,8 +44,8 @@ AFFECTED VERSIONS
 SOLUTION
 --------
 
-  libcurl 7.30.0 implements the function properly and will not send cookies to
-  sites just because the host names use the same tail.
+  libcurl 7.30.0 implements the function properly and does not send cookies to
+  sites just because the hostnames use the same tail.
 
 - Fixed-in: https://github.com/curl/curl/commit/2eb8dcf26cb37f09cffe2
 

docs/CVE-2013-2174.md

@@ -16,8 +16,8 @@ VULNERABILITY
   memory area that the function returns to the caller.
 
   The function takes a source string and a length parameter, and if the length
-  provided is 0 the function will instead use strlen() to figure out how much
-  data to parse.
+  provided is 0 the function instead uses strlen() to figure out how much data
+  to parse.
 
   The "%HH" parser wrongly only considered the case where a zero byte would
   terminate the input. If a length-limited buffer was passed in which ended
@@ -34,8 +34,8 @@ VULNERABILITY
   for specific circumstances but we consider the general risk for this to be
   low.
 
-  The curl command line tool is not affected by this problem as it doesn't use
-  this function.
+  The curl command line tool is not affected by this problem as it does not
+  use this function.
 
 INFO
 ----

docs/CVE-2013-4545.md

@@ -40,7 +40,7 @@ AFFECTED VERSIONS
 -----------------
 
   This flaw only exists in the TLS backend that uses OpenSSL. If libcurl is
-  built with another TLS backend, it isn't affected.
+  built with another TLS backend, it is not affected.
 
 - Affected versions: from libcurl 7.18.0 to and including 7.32.0
 - Not affected versions: libcurl < 7.18.0 and >= 7.33.0
@@ -50,7 +50,7 @@ AFFECTED VERSIONS
 SOLUTION
 --------
 
-  libcurl 7.33.0 makes sure that both options independently will cause the
+  libcurl 7.33.0 makes sure that both options independently causes the
   operation to fail unless the criteria is fulfilled.
 
   The fix was committed, pushed and released without the full security

docs/CVE-2013-6422.md

@@ -44,7 +44,7 @@ AFFECTED VERSIONS
 -----------------
 
 This flaw only exists in the TLS backend that uses GnuTLS. If libcurl is built
-with another TLS backend, it isn't affected.
+with another TLS backend, it is not affected.
 
 - Affected versions: from libcurl 7.21.4 to and including 7.33.0
 - Not affected versions: libcurl < 7.21.4 and >= 7.34.0
@@ -54,7 +54,7 @@ libcurl is used by many applications, but not always advertised as such!
 SOLUTION
 --------
 
-  libcurl 7.34.0 makes sure that both options independently will cause the
+  libcurl 7.34.0 makes sure that both options independently cause the
   operation to fail unless the criteria is fulfilled.
 
 - Fixed-in: https://github.com/curl/curl/commit/1dc43de0dccc2ea7da6dddb7b98

docs/CVE-2014-0015.md

@@ -20,14 +20,14 @@ authenticated using different credentials. One underlying reason being that
 NTLM authenticates connections and not requests, contrary to how HTTP is
 designed to work and how other authentication methods work.
 
-An application that allows NTLM and another auth method (the bug only
-triggers if more than one auth method is asked for) to a server (that
-responds wanting NTLM) with user1:password1 and then does another operation
-to the same server with user2:password2 (when the previous connection was
-left alive) - the second request will re-use the same connection and since
-it'll then see that the NTLM negotiation is already made, it will just send
-the request over that connection thinking it uses 'user2' credentials when
-it is in fact still using the connection authenticated for user1...
+An application that allows NTLM and another auth method (the bug only triggers
+if more than one auth method is asked for) to a server (that responds wanting
+NTLM) with user1:password1 and then does another operation to the same server
+with user2:password2 (when the previous connection was left alive) - the
+second request re-uses the same connection and since it then sees that the
+NTLM negotiation is already made, it just sends the request over that
+connection thinking it uses the user2 credentials when it is in fact still
+using the connection authenticated for user1...
 
 The set of auth methods to use is set with `CURLOPT_HTTPAUTH`.
 
@@ -37,7 +37,7 @@ problem.
 
 Applications can disable libcurl's re-use of connections and thus mitigate
 this problem, by using one of the following libcurl options to alter how
-connections are or aren't re-used: `CURLOPT_FRESH_CONNECT`,
+connections are or are not re-used: `CURLOPT_FRESH_CONNECT`,
 `CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using the
 curl_multi API).
 
@@ -73,7 +73,7 @@ another NTLM-using connection unless the credentials match.
 - Fixed-in: https://github.com/curl/curl/commit/8ae35102c43d8d
 
 This fix is already committed to the public source code repository because the
-full security impact wasn't properly realized until after the fact.
+full security impact was not properly realized until after the fact.
 
 RECOMMENDATIONS
 ---------------

docs/CVE-2014-0138.md

@@ -27,7 +27,7 @@ LDAP(S).
 
 Applications can disable libcurl's re-use of connections and thus mitigate
 this problem, by using one of the following libcurl options to alter how
-connections are or aren't re-used: `CURLOPT_FRESH_CONNECT`,
+connections are or are not re-used: `CURLOPT_FRESH_CONNECT`,
 `CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using the
 curl_multi API).
 

docs/CVE-2014-0139.md

@@ -25,9 +25,9 @@ man-in-the-middle attacks). Unfortunately libcurl fails to adhere to this
 rule under certain conditions, and subsequently it would allow and use a
 wildcard match specified in the CN field.
 
-Exploiting this flaw, a malicious server could participate in a MITM attack
-or just easier fool users that it is a legitimate site for whatever purpose,
-when it actually isn't.
+Exploiting this flaw, a malicious server could participate in a MITM attack or
+just easier fool users that it is a legitimate site for whatever purpose, when
+it actually is not.
 
 A good CA should refuse to issue a certificate with the CN as indicated,
 however there only need be one CA to issue one in error for this issue to
@@ -63,8 +63,8 @@ libcurl is used by many applications, but not always advertised as such!
 SOLUTION
 --------
 
-libcurl 7.36.0 has an improved host name verification function that rejects
-wild card matching against IP addresses.
+libcurl 7.36.0 has an improved hostname verification function that rejects
+wildcard matching against IP addresses.
 
 - Fixed-in: https://github.com/curl/curl/commit/5019c780958c3a8dbe64123aa9
 

docs/CVE-2014-1263.md

@@ -16,8 +16,8 @@ lifetime and it was not revoked) verification was still performed.
 This is a problem in libcurl built to use the Secure Transport backend. Secure
 Transport is the TLS library present and used on Mac OS X and iOS.
 
-Only users on Mac OS X or iOS can be affected by this. And only if libcurl
-was built to use the native TLS backend library.
+Only users on Mac OS X or iOS can be affected by this, and only if libcurl was
+built to use the native TLS backend library.
 
 This problem was initially used as an example of the Apple SSL bug that hit
 [the news in late February
@@ -49,8 +49,8 @@ libcurl is used by many applications, but not always advertised as such!
 SOLUTION
 ------------
 
-libcurl 7.36.0 makes sure that all TLS using requests verify the host name
-even if specified as an IP address in the URL.
+libcurl 7.36.0 makes sure that all TLS using requests verify the hostname even
+if specified as an IP address in the URL.
 
 - Fixed-in: https://github.com/curl/curl/commit/afc6e5004fabee
 
@@ -82,7 +82,7 @@ CREDITS
 - Help-by: Nick Zitzmann
 
 This was indirectly reported by numerous people and it was also clarified by
-*Adam Langley* that it wasn't the problem Apple themselves fixed. *Roland
+*Adam Langley* that it was not the problem Apple themselves fixed. *Roland
 Moriz* is credited [in Apple's security
 note](https://support.apple.com/en-us/HT202932).