New Ticket     Tickets     Wiki     Browse Source     Timeline     Roadmap     Ticket Reports     Search

Ticket #38015 (closed defect: fixed)

Opened 19 months ago

Last modified 18 months ago

openssl 1.0.1d Broken

Reported by: dylanryan@… Owned by: mww@…
Priority: Normal Milestone:
Component: ports Version: 2.1.3
Keywords: Cc: cal@…, ram@…, david@…, leo@…, blair@…, ruben+macports@…, ryandesign@…, aaron@…, elventear@…, egall@…
Port: openssl

Description

As of the most recent openssl update installed via sudo port upgrade outdated, it seems that using curl or wget (and presumably anything else using openssl) to fetch a https page fails.

For example:

$ curl https://google.com
curl: (35) error:1006706B:elliptic curve routines:ec_GFp_simple_oct2point:point is not on curve

$wget https://google.com
--2013-02-10 17:05:19--  https://google.com/
Resolving google.com (google.com)... 74.125.224.36, 74.125.224.39, 74.125.224.41, ...
Connecting to google.com (google.com)|74.125.224.36|:443... connected.
ERROR: The certificate of ‘google.com’ is not trusted.
ERROR: The certificate of ‘google.com’ hasn't got a known issuer.

Similar problems on similar pages (dropbox, etc. I can't find any https page that actually _works_)

Specs and such: Macports: v 2.1.3

Ports:

  openssl @1.0.1d_0 (active)
  curl @7.29.0_0+ssl (active)
  curl-ca-bundle @7.29.0_0 (active)
  wget @1.14_2+ssl (active)

System: 10.8.2, on a early 2011 MBP i7

Attachments

openssl-1.0.1e-test.log (346.9 KB) - added by david@… 19 months ago.
openssh-6.1p1-test.log (8.4 KB) - added by david@… 19 months ago.
lion-openssl-no-asm.log (368.2 KB) - added by leo@… 19 months ago.
lion-openssl.log (942.6 KB) - added by leo@… 19 months ago.

Change History

comment:1 Changed 19 months ago by cal@…

  • Owner changed from macports-tickets@… to mww@…
  • Cc cal@… added

If you didn't uninstall openssl 1.0.1c yet, you might want to run

sudo port -f deactivate openssl
sudo port activate openssl @1.0.1c_0

meanwhile.

comment:2 Changed 19 months ago by dylanryan@…

Thanks. Unfortunately, I didn't notice the issue immediately, so I did uninstall it. Not a huge issue for me at the moment, I can work around it by downloading things with a browser instead for the time being.

That said, if there's a way to re-download the older version via macports (I'm fine replacing portfiles if that is what is needed), that might be helpful.

comment:3 Changed 19 months ago by cal@…

As a temporary fix, force-uninstalling openssl, then reverting the Portfile to the old version and running port install in the directory where the Portfile is should work. Also see wiki:howto/InstallingOlderPort.

You can get the old version of the Portfile from source:trunk/dports/devel/openssl/.

comment:4 Changed 19 months ago by dylanryan@…

Thanks, that worked (sort of). Of course, after it installed, the broken port scanner (rev-upgrade) indicated that python27 is broken, and proceeded to start downloading it's dependencies... including the new openssl. Fun times.

I killed that, and things seem to work for now, and I can switch back and forth between the various OpenSSLs depending on what ports I need to work at any given time, though it is likely to be a little unstable I suspect (that's fine with me, though).

comment:5 Changed 19 months ago by ram@…

  • Cc ram@… added

Cc Me!

comment:6 follow-ups: ↓ 8 ↓ 18 Changed 19 months ago by jmr@…

Upstream ticket with link to fix in upstream git: http://rt.openssl.org/Ticket/Display.html?id=2975

Please apply the fix rather than reverting to 1.0.1c, as 1.0.1d also fixes some CVEs.

comment:7 Changed 19 months ago by ryandesign@…

#38017 might be a duplicate.

comment:8 in reply to: ↑ 6 Changed 19 months ago by cal@…

Replying to jmr@…:

Please apply the fix rather than reverting to 1.0.1c, as 1.0.1d also fixes some CVEs.

The commit that broke compatibility in the first place was the one fixing two out of three of these CVEs. I haven't found any comment by upstream on whether they claim their fix for the issue also closes these. The third CVE left over is only a DoS. Debian is holding off the update, and so should we, unless somebody of you knows his way around the crypto code at hand (people have previously failed at patching openssl…).

comment:9 Changed 19 months ago by david@…

Definitely best to roll back to openssl-1.0.1c as openssl-1.0.1d breaks many versions of ssh + scp making it impossible to login to external machines or copy files between them. Very ugly.

comment:10 Changed 19 months ago by david@…

browser:trunk/dports/devel/openssl/Portfile?rev=92914 is the link to the openssl-1.0.1c portfile so you can downgrade.

Last edited 19 months ago by ryandesign@… (previous) (diff)

comment:11 Changed 19 months ago by ryandesign@…

As reported on our mailing list, 1.0.1e is out now.

comment:12 Changed 19 months ago by ryandesign@…

mww updated the port to 1.0.1e in r103006. Does that fix the problem?

comment:13 Changed 19 months ago by ryandesign@…

  • Cc david@… added

comment:14 Changed 19 months ago by dylanryan@…

Yes and no. the +universal variant appears to be broken still, but -universal works.

~/Desktop $ port installed openssl
The following ports are currently installed:
  openssl @1.0.1e_0
  openssl @1.0.1e_0+universal (active)
~/Desktop $ curl https://google.com
curl: (35) error:1006706B:elliptic curve routines:ec_GFp_simple_oct2point:point is not on curve
~/Desktop $ sudo port activate  openssl @1.0.1e_0
--->  Computing dependencies for openssl
--->  Deactivating openssl @1.0.1e_0+universal
--->  Cleaning openssl
--->  Activating openssl @1.0.1e_0
--->  Cleaning openssl
~/Desktop $ curl https://google.com
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://www.google.com/">here</A>.
</BODY></HTML>
~/Desktop $ sudo port activate  openssl @1.0.1e_0+universal
--->  Computing dependencies for openssl
--->  Deactivating openssl @1.0.1e_0
--->  Cleaning openssl
--->  Activating openssl @1.0.1e_0+universal
--->  Cleaning openssl
~/Desktop $ curl https://google.com
curl: (35) error:1006706B:elliptic curve routines:ec_GFp_simple_oct2point:point is not on curve
~/Desktop $ 

Edit: Note that I did NOT use the +universal variant of curl. python27+universal requests the universal variant of openssl, and appears broken without it, and curl appears broken with it. Unsure why I have python27 installed +universal honestly, I try never to use that unless I NEED it, so my solution is just going to be to follow dependencies back rebuilding -universal until I either find something that I did specifically want universal, or else make macports happy. But that probably isn't a good solution for others.

Edit x2: Ah, boost requires python27, and I do want boost +universal. That explains why it was built universal in the first place.

Last edited 19 months ago by dylanryan@… (previous) (diff)

comment:15 Changed 19 months ago by leo@…

  • Cc leo@… added

Cc Me!

comment:16 in reply to: ↑ description Changed 19 months ago by leo@…

Replying to dylanryan@…: For

$ openssl version
OpenSSL 1.0.1e 11 Feb 2013

wget workaround: add root certificate "OU = Equifax Secure Certificate Authority, O = Equifax, C = US", for example from /opt/local/share/curl/curl-ca-bundle.crt

$ wget --ca-certificate=/opt/local/share/curl/curl-ca-bundle.crt https://google.com/
$ arch -x86_64 wget --ca-certificate=/opt/local/share/curl/curl-ca-bundle.crt https://google.com/
$ arch -i386 wget --ca-certificate=/opt/local/share/curl/curl-ca-bundle.crt https://google.com/

Both 32-bit & 64-bit version `wget' work fine.

curl & "openssl s_client" workaround: use 32-bit or use RC4-SHA cipher

$ arch -i386 curl https://google.com/
$ arch -x86_64 curl --ciphers $( openssl ciphers | sed 's/ECDH[^:]*://g' ) https://google.com/
$ arch -i386 openssl s_client -connect www.google.com:443 -CAfile /opt/local/share/curl/curl-ca-bundle.crt -debug
$ arch -x86_64 openssl s_client -connect www.google.com:443 -CAfile Equifax\ Secure\ Certificate\ Authority.pem -cipher $( openssl ciphers | sed 's/ECDH[^:]*://g' )

comment:17 Changed 19 months ago by elventear@…

OpenSSL 1.0.1e still exhibits the problems described in #38017. Only downgrading to 1.0.1c has resolved the issue.

comment:18 in reply to: ↑ 6 Changed 19 months ago by leo@…

Replying to jmr@…:

Upstream ticket with link to fix in upstream git: http://rt.openssl.org/Ticket/Display.html?id=2975

Probably, this is macports bug, not openssl. "Original" OpenSSL 1.0.1e with default configure work fine with "https://www.google.com".

$ cd openssl-1.0.1e.test
$ ./Configure darwin64-x86_64-cc
$ make
$ sh -x util/opensslwrap.sh s_client -connect www.google.com:443 -CAfile ~/Temp/Equifax\ Secure\ Certificate\ Authority.pem
...OK 64-bit
$ make clean
$ ./config
$ make 
$ sh -x util/opensslwrap.sh s_client -connect www.google.com:443 -CAfile ~/Temp/Equifax\ Secure\ Certificate\ Authority.pem
...OK 32-bit

comment:19 follow-up: ↓ 20 Changed 19 months ago by leo@…

Complete workaround for OpenSSL-1.0.1e port:

sudo port edit openssl

Remove "no-asm" from

configure.args      -L${prefix}/lib --openssldir=${prefix}/etc/openssl zlib no-krb5 shared no-asm

to

configure.args      -L${prefix}/lib --openssldir=${prefix}/etc/openssl zlib no-krb5 shared

Rebuild openssl port

sudo port upgrade --force openssl

32-bit & 64-bit version of wget, curl and "openssl s_client" work fine

Last edited 19 months ago by leo@… (previous) (diff)

comment:20 in reply to: ↑ 19 Changed 19 months ago by dylanryan@…

Replying to leo@…:

Complete workaround for OpenSSL-1.0.1e port:

sudo port edit openssl

Remove "no-asm" from

configure.args      -L${prefix}/lib --openssldir=${prefix}/etc/openssl zlib no-krb5 shared no-asm

...

Works for me. Thanks!

comment:21 Changed 19 months ago by elventear@…

Work around from leo works for me too. Not experiencing #38017 anymore with 1.0.1e

comment:22 Changed 19 months ago by blair@…

  • Cc blair@… added

Cc Me!

comment:23 Changed 19 months ago by blair@…

I just rebuilt openssl on my 5 year old iMac running 10.7 and removing the "no-asm" flag got ssh to successfully connect to my linux box.

comment:24 follow-up: ↓ 25 Changed 19 months ago by blair@…

On my ancient PowerBook running 10.5.8 openssl 1.0.1d and 1.0.1e work with no modifications to the Portfile.

comment:25 in reply to: ↑ 24 Changed 19 months ago by leo@…

Replying to blair@…:

On my ancient PowerBook running 10.5.8 openssl 1.0.1d and 1.0.1e work with no modifications to the Portfile.

Probably this "strict aliasing" optimization bug for "crypto/bn/bn_nist.c", see [openssl.org #2981] http://rt.openssl.org/Ticket/Display.html?id=2981

Mac OSX x86_64 compiler fail test/ectest: cc [Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn)] gcc-mp-4.3 gcc-mp-4.4 gcc-mp-4.5 gcc-mp-4.6 clang-mp-3.0 clang-mp-3.1 clang-mp-3.2

Mac OSX x86_64 compiler test/ectest OK: gcc-apple-4.2 gcc-mp-4.7 gcc-mp-4.8 [gcc-mp-4.8 (MacPorts gcc48 4.8-20130203_0+universal) 4.8.0 20130203 (experimental)] clang-mp-2.9 clang-mp-3.3 [clang version 3.3 (trunk 173279)]

Use `sudo port test openssl' for test openssl port on your system&compiler

Last edited 19 months ago by leo@… (previous) (diff)

comment:26 Changed 19 months ago by david@…

port test openssl throws this error for me...

:info:test testing internal curves: ...........
:info:test EC_GROUP_check() failed with curve secp384r1
:info:test .
:info:test EC_GROUP_check() failed with curve prime192v1
:info:test 
:info:test EC_GROUP_check() failed with curve prime192v2
:info:test 
:info:test EC_GROUP_check() failed with curve prime192v3
:info:test ...
:info:test EC_GROUP_check() failed with curve prime256v1
:info:test ............................................... failed

Changed 19 months ago by david@…

comment:27 Changed 19 months ago by david@…

Ran a the complete test suite via 'make -i' to show all errors.

Attached test log.

Tried to send this to upstream openssl by emailing rt@… (per openssl Website) and my email was rejected.

Unsure how to report this to openssl.

If someone knows, pass along the attached test log to the developers.

comment:28 Changed 19 months ago by david@…

Looks like this has already been reported (http://www.mail-archive.com/openssl-dev@openssl.org/msg32077.html) even though a search of the openssl bug tracker fails to mention this bug.

comment:29 follow-up: ↓ 31 Changed 19 months ago by leo@…

Replying to david@…:

port test openssl throws this error for me...

After workaround (port edit openssl, see above) must OK Warring, You need `port edit' after every port selfupdate etc.

About, OpenSSL, most instillation OpenSSL not use "no-asm" configure flag, this default (!). But macports use this flag

Changed 19 months ago by david@…

comment:30 Changed 19 months ago by david@…

Attached is a copy of the openssh-6.1p1 test log which shows a failure.

Version of openssl installed is... OpenSSH_6.1p1, OpenSSL 1.0.1c 10 May 2012 which should have been working for a long time.

So there are two test failures, one in openssl-1.0.1e + one in openssh-6.1p1 (using openssl-1.0.1c) which suggests, best to run test suites before deploying port updates.

Guess the correct action is to wait until openssl fixes their test suite failure, then try retesting openssh.

comment:31 in reply to: ↑ 29 ; follow-up: ↓ 32 Changed 19 months ago by ryandesign@…

Replying to leo@…:

About, OpenSSL, most instillation OpenSSL not use "no-asm" configure flag, this default (!). But macports use this flag

Yes. We started using this flag in r92126, apparently to fix a built failure on Lion x86_64. If Lion x86_64 no longer fails when we remove that flag, then we should remove that flag. Removing that flag did also fix the problems mentioned in this ticket for me, on Mountain Lion.

Changed 19 months ago by leo@…

Changed 19 months ago by leo@…

comment:32 in reply to: ↑ 31 Changed 19 months ago by leo@…

Replying to ryandesign@…:

Replying to leo@…:

About, OpenSSL, most instillation OpenSSL not use "no-asm" configure flag, this default (!). But macports use this flag

Yes. We started using this flag in r92126, apparently to fix a built failure on Lion x86_64. If Lion x86_64 no longer fails when we remove that flag, then we should remove that flag...

I test Lion with last Xcode:

MacBook-Pro-lvadmin:~ lvadmin$ uname -a
Darwin MacBook-Pro-lvadmin.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64
MacBook-Pro-lvadmin:~ lvadmin$ xcodebuild -version
Xcode 4.6
Build version 4H127

OK, workaround work fine. Because, Xcode version identical, results identical. See attachment: lion-openssl-no-asm.log and lion-openssl.log.

comment:33 Changed 19 months ago by david@…

Looks like openssl upstream has opened a bug about openssl-1.0.1e test suite failure.

http://rt.openssl.org/Ticket/History.html?id=2989 is the upstream ticket history.

comment:34 follow-up: ↓ 36 Changed 19 months ago by david@…

Looking through this bug, I removed no-asm in the Portfile + ran the test suite again.

Without no-asm the test suite runs with 100% passes.

Suggest releasing a new Portfile removing no-asm for Mountain Lion. From the above comments, looks like this is already in the works.

comment:35 Changed 19 months ago by ruben+macports@…

  • Cc ruben+macports@… added

Cc Me!

comment:36 in reply to: ↑ 34 ; follow-up: ↓ 37 Changed 19 months ago by leo@…

Replying to david@…:

Suggest releasing a new Portfile removing no-asm for Mountain Lion. From the above comments, looks like this is already in the works.

Lion with Xcode 4.6 (OS X 10.7.4 or later) also failed with "no-asm" flag, see attachment lion-openssl-no-asm.log​.

May be, remove "no-asm" and create variant "+no-asm" for old Xcode users?

comment:37 in reply to: ↑ 36 Changed 19 months ago by ryandesign@…

  • Cc ryandesign@… added
  • Port changed from OpenSSL to openssl
  • Summary changed from OpenSSL 1.0.1d Broken to openssl 1.0.1d Broken

Has duplicate #38041.

Replying to leo@…:

May be, remove "no-asm" and create variant "+no-asm" for old Xcode users?

I would prefer no variants be added. Can anyone confirm that old Xcode version (or rather: old clang or possibly llvm-gcc-4.2 versions) require no-asm? If so, what versions?

comment:38 Changed 18 months ago by aaron@…

  • Cc aaron@… added

Cc Me!

comment:39 Changed 18 months ago by aaron@…

Hi, what are we waiting for regarding the removal of the 'no-asm' option? Every person who has updated MacPorts in the last two weeks has broken their OpenSSL in this way. It's somewhat urgent to resolve.

comment:40 Changed 18 months ago by ryandesign@…

  • Cc elventear@… added
  • Status changed from new to closed
  • Resolution set to fixed

The no-asm build option in openssl has a bit of a history in MacPorts which is worth recounting:

  • r2140: the openssl 0.9.7a port is created, with the no-asm option in place; no explanation is given, but it could be that OS X was still so new that the project's assembly code did not work on OS X.
  • r90928: with openssl now at 1.0.1, no-asm is removed (i.e. asm is enabled) because "all tests pass on 10.7/x64".
  • r91166: no-asm is reinstated (i.e. asm is disabled again) for OS X 10.5 and 10.6 only, because "'asm' only is tested on 10.7/x64"; asm remains enabled for 10.4, presumably erroneously. It's not clear whether Markus specifically knew of problems with asm on Leopard or Snow Leopard or whether he was just being cautious.
  • r92126: openssl is updated to 1.0.1a and no-asm is reinstated globally "to make compile on 10.7/x64". I backdated my openssl port to r92126 and verified it built fine on Lion x86_64; then I edited the portfile and removed no-asm and verified that it did in fact fail to build.
  • r92138: the platform darwin 9 and darwin 10 blocks that were added in r91166 are removed again since they are now redundant with the reinstated global no-asm option.

So asm has been off for most of the openssl port's life, and it was only briefly enabled for openssl version 1.0.1 only, and only for Lion, and then disabled when the next version of openssl didn't build with that option anymore. So if we want to enable asm now, we should do some thorough testing. Which is what I did, with the current version, 1.0.1e:

CPU OS X Xcode Compiler Compiler Version Archs Tests Pass curl https://google.com works
Before (no-asm) After (asm) Before (no-asm) After (asm)
PowerPC G4 10.4.11 2.5 gcc-4.0 gcc version 4.0.1 (Apple Computer, Inc. build 5370) ppc yes yes yes yes
10.5.8 3.1.2 gcc-4.0 gcc version 4.0.1 (Apple Inc. build 5493) ppc yes yes yes yes
Intel 10.5.8 3.1.2 gcc-4.0 gcc version 4.0.1 (Apple Inc. build 5493) i386 yes yes yes yes
x86_64 yes yes yes yes
Core 2 Duo 10.6.8 3.2.6 gcc-4.2 i386 yes yes yes yes
x86_64 yes yes yes yes
10.7.5 4.3.3 clang Apple clang version 3.1 (tags/Apple/clang-318.0.61) (based on LLVM 3.1svn) i386 yes yes yes yes
x86_64 yes yes yes yes
10.8.2 4.5.2 clang Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn) i386 yes yes yes yes
x86_64 yes yes yes yes
Core i7 10.8.2 4.6 clang Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn) i386 yes yes yes yes
x86_64 no yes no yes

Given these results I think it's safe to remove no-asm globally. Committed in r103461.

comment:41 Changed 18 months ago by aaron@…

Thank you for the thorough tests and recounting of history!

Last edited 18 months ago by aaron@… (previous) (diff)

comment:42 Changed 18 months ago by blair@…

Nice work Ryan!

comment:43 Changed 18 months ago by egall@…

  • Cc egall@… added

Cc Me!

Note: See TracTickets for help on using tickets.