[FFe] Please merge openssl 1.0.1 from Debian unstable

Upstream NEWS file:

  Major changes between OpenSSL 1.0.0h and OpenSSL 1.0.1:

      o TLS/DTLS heartbeat support.
      o SCTP support.
      o RFC 5705 TLS key material exporter.
      o RFC 5764 DTLS-SRTP negotiation.
      o Next Protocol Negotiation.
      o PSS signatures in certificates, requests and CRLs.
      o Support for password based recipient info for CMS.
      o Support TLS v1.2 and TLS v1.1.
      o Preliminary FIPS capability for unvalidated 2.0 FIPS module.
      o SRP support.

  Major changes between OpenSSL 1.0.0g and OpenSSL 1.0.0h:

      o Fix for CMS/PKCS#7 MMA CVE-2012-0884
      o Corrected fix for CVE-2011-4619
      o Various DTLS fixes.

Debian changelog:

openssl (1.0.1-2) unstable; urgency=low

  * Properly quote the new cflags in Configure

 -- Kurt Roeckx <email address hidden> Mon, 19 Mar 2012 19:56:05 +0100

openssl (1.0.1-1) unstable; urgency=low

  * New upstream version
    - Remove kfreebsd-pipe.patch, fixed upstream
    - Update pic.patch, openssl-pod-misspell.patch and make-targets.patch
    - Add OPENSSL_1.0.1 to version-script.patch and libssl1.0.0.symbols for
      the new functions.
    - AES-NI support (Closes: #644743)
  * pic.patch: upstream made OPENSSL_ia32cap_P and OPENSSL_cpuid_setup
    hidden on amd64, no need to access it PIC anymore.
  * pic.patch: Make OPENSSL_ia32cap_P hidden on i386 too (Closes: #663977)
  * Enable hardening using dpkg-buildflags (Closes: #653495)
  * s_client and s_server were forcing SSLv3 only connection when SSLv2 was
    disabled instead of the SSLv2 with upgrade method. (Closes: #664454)
  * Add Beaks on openssh < 1:5.9p1-4, it has a too strict version check.

 -- Kurt Roeckx <email address hidden> Mon, 19 Mar 2012 18:23:32 +0100

openssl (1.0.0h-1) unstable; urgency=high

  * New upstream version
    - Fixes CVE-2012-0884
    - Fixes CVE-2012-1165
    - Properly fix CVE-2011-4619
    - pkg-config.patch applied upstream, remove it.
  * Enable assembler for all i386 arches. The assembler does proper
    detection of CPU support, including cpuid support.
    This should fix a problem with AES 192 and 256 with the padlock
    engine because of the difference in NO_ASM between the between
    the i686 optimized library and the engine.

 -- Kurt Roeckx <email address hidden> Tue, 13 Mar 2012 21:08:17 +0100

I've done some performance testing, which is in bug 796456 (private, sorry). I can quote my own numbers from that:

  for x in sha1 rc4 aes-{128,256}-cbc md5; do openssl speed -evp $x 2>/dev/null | grep -A1 ^type; done | sed '2,${/type/d}'

Core 2 Duo T7100 (my laptop, getting on a bit):

amd64 1.0.0g-1ubuntu1:
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
sha1 32959.34k 85644.07k 174930.39k 243954.98k 266935.33k
rc4 90403.67k 98901.49k 101289.27k 102313.50k 103083.61k
aes-128-cbc 51210.81k 58557.04k 60279.01k 126155.41k 129400.50k
aes-256-cbc 38099.06k 41632.22k 44081.90k 42170.87k 43401.11k
md5 36105.68k 103355.47k 215324.51k 296345.24k 334079.66k

amd64 1.0.1-2ubuntu1 (unreleased):
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
sha1 35898.84k 97968.17k 201869.01k 280300.41k 314556.36k
rc4 148796.23k 248179.50k 299200.47k 317167.51k 315630.36k
aes-128-c...

While I know a number of people are interested in support for newer versions of TLS, my motivation for this FFe is that we've had commercial requests to backport performance work for newer Intel processors from the 1.0.1 branch. I attempted this a while back. The result was an improvement for most algorithms, but a 36% regression for RC4. At this point I have run out of my comfort zone for backporting OpenSSL patches: it's not at all obvious how they're intertwined, and I am concerned that an amateur backport attempt could easily introduce security problems. I'm a lot more comfortable with the idea of just using 1.0.1, especially since it's in Debian unstable now.

I have a merge prepared and ready to go. Preview temporarily here:

  http://people.canonical.com/~cjwatson/tmp/openssl/

Moving back to New so that the release team will see that this isn't an approved FFe yet.

Testing: OpenSSL has extensive tests of its own. I've had several people do speed testing on various hardware and done some myself, including Nehalem, Sandy Bridge, and Ivy Bridge (full results in the linked private bug).

qa-regression-testing's test-openssl.py has one failure which I think is spurious (there are just new ciphers):

FAIL: test_ciphers (__main__.OpenSSLTest)
Test cipher suite list
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./test-openssl.py", line 505, in test_ciphers
    self.assertTrue(self.ciphers == report.rstrip(), "Could not find '%s' in report:\n%s" % (self.ciphers, report))
AssertionError: Could not find 'ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:ECDH-RSA-DES-CBC3-SHA:ECDH-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA:PSK-3DES-EDE-CBC-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES128-SHA:SEED-SHA:CAMELLIA128-SHA:PSK-AES128-CBC-SHA:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:PSK-RC4-SHA:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC4-MD5' in report:
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:SRP-DSS-3DES-EDE-CBC-SHA:SRP-RSA-3DES-EDE-CBC-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:ECDH-RSA-DES-CBC3-SHA:ECDH-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA:PSK-3DES-EDE-CBC-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:SEED-SHA:CAMELLIA128-SHA:PSK-AES128-CBC-SHA:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:PSK-RC4-SHA:EDH-RS...

Yes, that is a spurious failure; as you noted elsewhere, the testcase already contains version specific cases. It's intent is to make sure we don't accidentally disable a cipher when doing an update. Given that and that the list of different ciphers is strictly additive, so this test failure (such as it is) looks okay to me.

I'm comfortable with the (public and private) testing showing both that this is a nearly-universal performance improvement, and that it's regression-tested across a suitable range of hardware such that we shouldn't be seeing any SIGILL regressions here. FFe approved.

This bug was fixed in the package openssl - 1.0.1-2ubuntu1

---------------
openssl (1.0.1-2ubuntu1) precise; urgency=low

  * Resynchronise with Debian (LP: #958430). Remaining changes:
    - debian/libssl1.0.0.postinst:
      + Display a system restart required notification on libssl1.0.0
        upgrade on servers.
      + Use a different priority for libssl1.0.0/restart-services depending
        on whether a desktop, or server dist-upgrade is being performed.
    - debian/{libssl1.0.0-udeb.dirs, control, rules}: Create
      libssl1.0.0-udeb, for the benefit of wget-udeb (no wget-udeb package
      in Debian).
    - debian/{libcrypto1.0.0-udeb.dirs, libssl1.0.0.dirs, libssl1.0.0.files,
      rules}: Move runtime libraries to /lib, for the benefit of
      wpasupplicant.
    - debian/patches/perlpath-quilt.patch: Don't change perl #! paths under
      .pc.
    - debian/rules:
      + Don't run 'make test' when cross-building.
      + Use host compiler when cross-building. Patch from Neil Williams.
      + Don't build for processors no longer supported: i586 (on i386)
      + Fix Makefile to properly clean up libs/ dirs in clean target.
      + Replace duplicate files in the doc directory with symlinks.
    - Unapply patch c_rehash-multi and comment it out in the series as it
      breaks parsing of certificates with CRLF line endings and other cases
      (see Debian #642314 for discussion), it also changes the semantics of
      c_rehash directories by requiring applications to parse hash link
      targets as files containing potentially *multiple* certificates rather
      than exactly one.
  * Drop aesni.patch, applied upstream.
  * Drop Bsymbolic-functions.patch, now handled using dpkg-buildflags.

openssl (1.0.1-2) unstable; urgency=low

  * Properly quote the new cflags in Configure

openssl (1.0.1-1) unstable; urgency=low

  * New upstream version
    - Remove kfreebsd-pipe.patch, fixed upstream
    - Update pic.patch, openssl-pod-misspell.patch and make-targets.patch
    - Add OPENSSL_1.0.1 to version-script.patch and libssl1.0.0.symbols for
      the new functions.
    - AES-NI support (Closes: #644743)
  * pic.patch: upstream made OPENSSL_ia32cap_P and OPENSSL_cpuid_setup
    hidden on amd64, no need to access it PIC anymore.
  * pic.patch: Make OPENSSL_ia32cap_P hidden on i386 too (Closes: #663977)
  * Enable hardening using dpkg-buildflags (Closes: #653495)
  * s_client and s_server were forcing SSLv3 only connection when SSLv2 was
    disabled instead of the SSLv2 with upgrade method. (Closes: #664454)
  * Add Beaks on openssh < 1:5.9p1-4, it has a too strict version check.

openssl (1.0.0h-1) unstable; urgency=high

  * New upstream version
    - Fixes CVE-2012-0884
    - Fixes CVE-2012-1165
    - Properly fix CVE-2011-4619
    - pkg-config.patch applied upstream, remove it.
  * Enable assembler for all i386 arches. The assembler does proper
    detection of CPU support, including cpuid support.
    This should fix a problem with AES 192 and 256 with the padlock
    engine because of the difference in NO_ASM between the between
    the i686 optimized library and the engine.
 -- Colin Watson <email address hidden> Thu, ...