summaryrefslogtreecommitdiffstats
path: root/package/sslh/0001-secure-version-while-building-sslh-in-a-larger-git-t.patch
diff options
context:
space:
mode:
authorPeter Korsgaard <peter@korsgaard.com>2017-02-22 08:25:05 +0100
committerPeter Korsgaard <peter@korsgaard.com>2017-02-23 21:35:11 +0100
commitc5f5d9fa4e378f3b81f51284e32ee1c23ab2a575 (patch)
treeb141ad9cd0c68124bec66f7d28e055c80d727132 /package/sslh/0001-secure-version-while-building-sslh-in-a-larger-git-t.patch
parent8a9b9a48539c6984f898f137555308210c5d2cd5 (diff)
downloadbuildroot-c5f5d9fa4e378f3b81f51284e32ee1c23ab2a575.tar.gz
buildroot-c5f5d9fa4e378f3b81f51284e32ee1c23ab2a575.zip
libcurl: security bump to version 7.53.0
Fixes CVE-2017-2629 - curl SSL_VERIFYSTATUS ignored >From the advisory (http://www.openwall.com/lists/oss-security/2017/02/21/6): Curl and libcurl support "OCSP stapling", also known as the TLS Certificate Status Request extension (using the `CURLOPT_SSL_VERIFYSTATUS` option). When telling curl to use this feature, it uses that TLS extension to ask for a fresh proof of the server's certificate's validity. If the server doesn't support the extension, or fails to provide said proof, curl is expected to return an error. Due to a coding mistake, the code that checks for a test success or failure, ends up always thinking there's valid proof, even when there is none or if the server doesn't support the TLS extension in question. Contrary to how it used to function and contrary to how this feature is documented to work. This could lead to users not detecting when a server's certificate goes invalid or otherwise be mislead that the server is in a better shape than it is in reality. Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Diffstat (limited to 'package/sslh/0001-secure-version-while-building-sslh-in-a-larger-git-t.patch')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud