svn commit: r407484 - head/security/vuxml

Fri Jan 29 16:36:39 UTC 2016

Author: feld
Date: Fri Jan 29 16:36:38 2016
New Revision: 407484
URL: https://svnweb.freebsd.org/changeset/ports/407484

Log:
  vuxml: Fix openssl entry so `make validate` doesn't throw errors

Modified:
  head/security/vuxml/vuln.xml

Modified: head/security/vuxml/vuln.xml
==============================================================================

--- head/security/vuxml/vuln.xml	Fri Jan 29 16:35:58 2016	(r407483)
+++ head/security/vuxml/vuln.xml	Fri Jan 29 16:36:38 2016	(r407484)
@@ -455,42 +455,42 @@ Notes:
     <topic>openssl -- multiple vulnerabilities</topic>
     <affects>
       <package>
-        <name>openssl</name>
-        <range><lt>1.0.2_7</lt></range>
+	<name>openssl</name>
+	<range><lt>1.0.2_7</lt></range>
       </package>
       <package>
-        <name>mingw32-openssl</name>
-        <range><ge>1.0.1</ge><lt>1.0.2f</lt></range>
+	<name>mingw32-openssl</name>
+	<range><ge>1.0.1</ge><lt>1.0.2f</lt></range>
       </package>
     </affects>
     <description>
       <body xmlns="http://www.w3.org/1999/xhtml">
-        <p>OpenSSL project reports:</p>
-        <blockquote cite="https://www.openssl.org/news/secadv/20160128.txt">
-          <ol>
-            <li>Historically OpenSSL only ever generated DH parameters based on "safe"
-              primes. More recently (in version 1.0.2) support was provided for
-              generating X9.42 style parameter files such as those required for RFC 5114
-              support. The primes used in such files may not be "safe". Where an
-              application is using DH configured with parameters based on primes that are
-              not "safe" then an attacker could use this fact to find a peer's private
-              DH exponent. This attack requires that the attacker complete multiple
-              handshakes in which the peer uses the same private DH exponent. For example
-              this could be used to discover a TLS server's private DH exponent if it's
-              reusing the private DH exponent or it's using a static DH ciphersuite.
-              OpenSSL provides the option SSL_OP_SINGLE_DH_USE for ephemeral DH (DHE) in
-              TLS. It is not on by default. If the option is not set then the server
-              reuses the same private DH exponent for the life of the server process and
-              would be vulnerable to this attack. It is believed that many popular
-              applications do set this option and would therefore not be at risk.
-              (CVE-2016-0701)</li>
-            <li>A malicious client can negotiate SSLv2 ciphers that have been disabled on
-              the server and complete SSLv2 handshakes even if all SSLv2 ciphers have
-              been disabled, provided that the SSLv2 protocol was not also disabled via
-              SSL_OP_NO_SSLv2.
-              (CVE-2015-3197)</li>
-          </ol>
-        </blockquote>
+	<p>OpenSSL project reports:</p>
+	<blockquote cite="https://www.openssl.org/news/secadv/20160128.txt">
+	  <ol>
+	    <li>Historically OpenSSL only ever generated DH parameters based on "safe"
+	      primes. More recently (in version 1.0.2) support was provided for
+	      generating X9.42 style parameter files such as those required for RFC 5114
+	      support. The primes used in such files may not be "safe". Where an
+	      application is using DH configured with parameters based on primes that are
+	      not "safe" then an attacker could use this fact to find a peer's private
+	      DH exponent. This attack requires that the attacker complete multiple
+	      handshakes in which the peer uses the same private DH exponent. For example
+	      this could be used to discover a TLS server's private DH exponent if it's
+	      reusing the private DH exponent or it's using a static DH ciphersuite.
+	      OpenSSL provides the option SSL_OP_SINGLE_DH_USE for ephemeral DH (DHE) in
+	      TLS. It is not on by default. If the option is not set then the server
+	      reuses the same private DH exponent for the life of the server process and
+	      would be vulnerable to this attack. It is believed that many popular
+	      applications do set this option and would therefore not be at risk.
+	      (CVE-2016-0701)</li>
+	    <li>A malicious client can negotiate SSLv2 ciphers that have been disabled on
+	      the server and complete SSLv2 handshakes even if all SSLv2 ciphers have
+	      been disabled, provided that the SSLv2 protocol was not also disabled via
+	      SSL_OP_NO_SSLv2.
+	      (CVE-2015-3197)</li>
+	  </ol>
+	</blockquote>
       </body>
     </description>
     <references>
