Opened 4 years ago

Closed 4 years ago

#16901 closed defect (fixed)

tor 0.2.7 configures OS X system OpenSSL, even though it's too old to work

Reported by: teor Owned by:
Priority: Very High Milestone: Tor: 0.2.7.x-final
Component: Core Tor/Tor Version: Tor: 0.2.7.2-alpha
Severity: Keywords: TorCoreTeam201509 Post027Freeze
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Since we've deprecated OpenSSL 0.9.8, it's important that OpenSSL autodetection works on platforms that only ship old OpenSSL versions (this includes OS X and OpenBSD at least).

Currently, OpenSSL autodetection fails on OS X when the following typical setup steps are taken:

  1. Install MacPorts OpenSSL/Libevent
  2. Build tor with ./configure --with-libevent-dir=/opt/local

Tor appears to detect and accept the system OpenSSL at configure, then fail late in the build process. It should fail at configure, say that OpenSSL is too old, and ask the user to specify --with-openssl-dir.

Using --with-openssl-dir works as expected.

I don't know if I (teor) can fix this, but it's important it works on release.

Relevant versions and logs are as follows:

$ gcc -v
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.5.0
Thread model: posix
$ echo $PATH
/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:...

Note that using the standard path /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin makes no difference - configure still fails.

checking build system type... x86_64-apple-darwin14.5.0
checking host system type... x86_64-apple-darwin14.5.0
checking for gcc... gcc
...
checking for openssl directory... (system)
checking whether we need extra options to link openssl... (none)
checking for struct ssl_method_st.get_cipher_by_char... yes
checking for SSL_SESSION_get_master_key... no
checking for SSL_get_server_random... no
checking for SSL_get_client_ciphers... no
checking for SSL_get_client_random... no
checking for SSL_CIPHER_find... no
checking for TLS_method... no
checking for EVP_PBE_scrypt... no
...
  CCLD     src/tools/tor-gencert
Undefined symbols for architecture x86_64:
  "_EVP_aes_128_ctr", referenced from:
      _aes_new_cipher in libor-crypto.a(aes.o)
  "_CRYPTO_THREADID_set_numeric", referenced from:
      _tor_set_openssl_thread_id in libor-crypto.a(crypto.o)
  "_CRYPTO_THREADID_set_callback", referenced from:
      _crypto_early_init in libor-crypto.a(crypto.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [src/tools/tor-gencert] Error 1
make: *** [all] Error 2

Child Tickets

Change History (10)

comment:1 Changed 4 years ago by teor

Summary: tor 0.2.7 configures OS X system OpenSSL, even though it's to old to worktor 0.2.7 configures OS X system OpenSSL, even though it's too old to work

Speling

comment:2 Changed 4 years ago by nickm

Status: newneeds_review

ticket16901 has a patch here; please test and review?

Also, there should have been a failure much earlier, in crypto.c:

#if OPENSSL_VERSION_NUMBER < OPENSSL_V_SERIES(1,0,0)
#error "We require OpenSSL >= 1.0.0"
#endif

Did that not happen?

comment:3 in reply to:  2 Changed 4 years ago by teor

Replying to nickm:

Also, there should have been a failure much earlier, in crypto.c:

#if OPENSSL_VERSION_NUMBER < OPENSSL_V_SERIES(1,0,0)
#error "We require OpenSSL >= 1.0.0"
#endif

Did that not happen?

When tor is built, it requires libevent:

checking for libevent directory... configure: WARNING: Could not find a linkable libevent.  If you have it installed somewhere unusual, you can specify an explicit path using --with-libevent-dir

When libevent is installed via MacPorts, it installs openssl (currently 1.0.2d) as a dependency.

When openssl 1.0.2d is installed via MacPorts, and I run:
CC="gcc -v" ./configure --with-libevent-dir=/opt/local; make
I see:

  CCLD     src/tools/tor-gencert
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.5.0
Thread model: posix
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -export_dynamic -dynamic -arch x86_64 -dead_strip -macosx_version_min 10.10.0 -pie -o src/tools/tor-gencert src/tools/tor-gencert.o src/common/libor.a src/common/libor-crypto.a src/common/libcurve25519_donna.a src/ext/ed25519/ref10/libed25519_ref10.a src/ext/ed25519/donna/libed25519_donna.a -lz -lssl -lcrypto -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.1.0/lib/darwin/libclang_rt.osx.a
Undefined symbols for architecture x86_64:
  "_EVP_aes_128_ctr", referenced from:
      _aes_new_cipher in libor-crypto.a(aes.o)
  "_CRYPTO_THREADID_set_numeric", referenced from:
      _tor_set_openssl_thread_id in libor-crypto.a(crypto.o)
  "_CRYPTO_THREADID_set_callback", referenced from:
      _crypto_early_init in libor-crypto.a(crypto.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [src/tools/tor-gencert] Error 1

when linking tor-gencert.

But tor has already linked successfully earlier in the build process, with the output:

  CCLD     src/or/tor
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.5.0
Thread model: posix
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -export_dynamic -dynamic -arch x86_64 -dead_strip -macosx_version_min 10.10.0 -pie -o src/or/tor -L/opt/local/lib src/or/tor_main.o src/or/libtor.a src/common/libor.a src/common/libor-crypto.a src/common/libcurve25519_donna.a src/ext/ed25519/ref10/libed25519_ref10.a src/ext/ed25519/donna/libed25519_donna.a src/common/libor-event.a src/trunnel/libor-trunnel.a -lz -levent -lssl -lcrypto -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.1.0/lib/darwin/libclang_rt.osx.a

The difference is that tor's linker command includes -L/opt/local/lib for -levent, which also gets applied to -lssl -lcrypto, pulling in openssl 1.0.2d. (Also, -L/opt/local/lib gets applied to -lz, but that's unlikely to matter much). tor-gencert doesn't use libevent, so it doesn't get -L/opt/local/lib.

It's also worth noting that libevent's -I/opt/local/include is being applied to all the openssl headers as well, pulling in the openssl 1.0.2d headers, which is why the preprocessor warning isn't triggered.

Now I'll move on to testing your branch.

comment:4 Changed 4 years ago by teor

The branch works as expected. Let's get it merged!

A new user on OS X can follow a typical build workflow and get a working tor install by responding to ./configure error messages:

  1. git clone https://git.torproject.org/tor/tor.git
  2. ./configure
    checking for libevent directory... configure: WARNING: Could not find a linkable libevent.  If you have it installed somewhere unusual, you can specify an explicit path using --with-libevent-dir
    configure: error: Missing libraries; unable to proceed.
    
  3. port install libevent (which also installs openssl)
  4. ./configure --with-libevent-dir=/opt/local
    checking whether we need extra options to link openssl... (none)
    configure: error: OpenSSL is too old. We require 1.0.0 or later. You can specify a path to a newer one with --with-openssl-dir.
    
  5. ./configure --with-libevent-dir=/opt/local --with-openssl-dir=/opt/local
  6. make
  7. make test

Notes on other configurations:

HomeBrew is an alternative OS X package manager. It shouldn't suffer from this issue due to its cask system, which places every package in its own directory.

Users on any platform may also install OpenSSL and libevent themselves. If they are installed in the in the same parent directory (e.g. /usr/local/{include,lib}), this issue could occur. This patch will fix the issue in this configuration, too.

OpenBSD users have complained of similar issues since tor 0.2.7.2-alpha. Although it shouldn't happen on the default configuration (as their distro has libevent), this patch should avoid similar issues if a newer OpenSSL and libevent are installed together.

comment:5 Changed 4 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

Thanks! Merged!

comment:6 Changed 4 years ago by teor

Resolution: implemented
Status: closedreopened

This patch uses /bin/true which doesn't exist on some systems (like OS X, where it's /usr/bin/true).
Can we simply use true instead?

comment:7 Changed 4 years ago by nickm

Can we use : ?

comment:8 Changed 4 years ago by teor

Status: reopenedneeds_review

Yes, replacing both instances of /bin/true in configure.ac with : works for me.
(The other instance is in PC/UCONTEXT related code.)

comment:9 Changed 4 years ago by teor

See my branch configure-use-colon on ​https://github.com/teor2345/tor.git

comment:10 Changed 4 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

Merging!

Note: See TracTickets for help on using tickets.