[Tor-BSD] Having issues forcing Tor release 0.2.6.9 to build with update libssl.so.32.0 library

teor teor2345 at gmail.com
Tue Jun 30 11:20:12 EDT 2015


Hi Seth,

Apologies for the super-long email, but I think we're finally getting to the bottom of this.

As a quick shortcut, does
./configure --with-openssl-dir=/usr/local …
get you linkage to libcrypto and libssl in /usr/local/lib?
(You were using --with-openssl-dir=/usr/local/lib, apologies for not picking this up sooner.)

> On 30 Jun 2015, at 08:19 , Seth <list at sysfu.com> wrote:
> 
> On Mon, 15 Jun 2015 01:51:30 -0700, teor <teor2345 at gmail.com> wrote:
>> Can you please provide any configure or make output containing ssl or crypto?
>> What is the entire output in config.log for openssl configuration?
> 
> Sorry for the delay, your email response got buried.

No worries.

> Please see attached files for complete log and one with only ssl and crypto strings.

Thanks, these are really helpful.

>> I am aware of issues in previous releases (0.2.5?) on OS X where tor would ./configure openssl based on the location of the first openssl binary in the $PATH, and not the location of the libraries or the SSL directory. I thought these had been fixed, but we might have a regression.
>> 
>> Is there an openssl binary in /usr/bin?
> 
> $ ls -l /usr/bin/open*
> lrwxr-xr-x  1 root  wheel      22 Jun 15 11:49 /usr/bin/openssl -> /usr/local/bin/openssl
> -r-xr-xr-x  1 root  bin    498904 Mar  9 03:52 /usr/bin/openssl2.1
> 
>> In /usr/local/bin?
> 
> $ ls -l /usr/local/bin/open*
> -rwxr-xr-x  1 root  wheel  1461810 Jun 15 11:47 /usr/local/bin/openssl
> 
>> What is your $PATH when ./configure is called?
> 
> /home/<username>/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games:.

Thanks, this helps me understand what's going on.

You have an openssl binary in both /usr/bin and /usr/local/bin, and your path has /usr/bin first.
This is the situation which triggers the openssl $PATH bug I referred to.

It looks like the openssl binary is being located based on the first openssl in your path:

configure:5972: checking for openssl
configure:5990: found /usr/bin/openssl
configure:6003: result: /usr/bin/openssl

But the discovered openssl directory is /usr/local/lib:

configure:7793: checking for openssl directory
configure:7846: gcc -std=gnu99 -o conftest -g -O2 -I/usr/local/lib  -I${top_srcdir}/src/common -L/usr/local/lib  conftest.c -lpthread  -lssl -lcrypto  >&5
conftest.c: In function 'main':
conftest.c:62: warning: implicit declaration of function 'exit'
conftest.c:62: warning: incompatible implicit declaration of built-in function 'exit'
configure:7846: $? = 0
configure:7868: gcc -std=gnu99 -c -g -O2 -I/usr/local/lib  -I${top_srcdir}/src/common conftest.c >&5
configure:7868: $? = 0
configure:7961: result: /usr/local/lib

And ldd's output shows that libcrypto is being linked based on the path passed to ./configure --with-openssl-dir=/usr/local/lib

This looks like either:
* a regression to the 0.2.5 behaviour I discovered on OS X, or
* that the bug was only fixed in 0.2.7.1-alpha, or
* that the --with-openssl-dir= path should be /usr/local rather than /usr/local/lib. (I'm really sorry I didn't pick this up in my first email.)

My suggested solutions below will help me work out which one of these is happening.

>> What is the $PATH used in the openssl configure step? (This may require grepping logs or modifying ./configure)
> 
> Not sure I understand. Do you when ./configure was run to build LibreSLL 2.2.0? If so, it would be the same as above.

I was looking for the path that Tor's ./configure uses to try to find an openssl binary.

Based on the logs above, either:
* ./configure is using the $PATH that's passed to it, or
* any modifications ./configure makes to the path are having no effect, or
* ./configure's search for an openssl binary in /usr/local/lib/bin is failing (for obvious reasons).

Again, my suggested solutions below will help me work out which one of these is happening.

>> There may also be an issue with the linker command generated by ./configure:
>> 
>> What is $LDFLAGS when ./configure is called?
> 
> Same as the ./configure command I posted in  beginning of thread: LDFLAGS=-L/usr/local/lib
> 
>> What is $CC when ./configure is called?
> 
> $ sudo echo $CC
> 
> (No value set)

./configure discovers /usr/bin/gcc, which is gcc 4.2.1:

configure:4177: checking for gcc
configure:4193: found /usr/bin/gcc
configure:4204: result: gcc
configure:4433: checking for C compiler version
configure:4442: gcc --version >&5
gcc (GCC) 4.2.1 20070719
…

This is useful for me to know, because I had some concerns this was a clang-specific issue. (It's not.)

> 
>> Can you please provide the exact command-line used for linking tor, particularly any -L or -l directives? (This may require grepping logs or modifying a Makefile)
> 
> Not sure I understand the question, as I didn't do any manual linking. Only introduced CFLAGS and LDFLAGS when running ./configure

When the tor binary is linked, the order of any -L and -l directives determines exactly which libraries are linked.
From the ldd output, I'm guessing that the command-line looks something like this:

<linker> -L /usr/local/lib -lcrypto -L /usr/lib -lssl

But I can't see how ./configure produces that outcome from the logs your provided. Something really strange is happening.

If you can run a verbose build that shows the linker command used to link the tor binary, that would be helpful.

Can you try:
CC="/usr/bin/gcc -v" ./configure --with-openssl-dir=/usr/local/lib …

If this works, can you please provide the output of make, after the line:
  CCLD     src/or/tor

This will help me see what arguments are actually being passed to the linker.

For example, on my OS X system, with the latest tor git sources, I see:
(Note that the system OpenSSL on OS X is 0.9.8, which is unsupported by Tor 0.2.7, so I'm using OpenSSL 1.0.2c via MacPorts.)

CC="/opt/local/bin/gcc -v" ./configure --with-libevent-dir=/opt/local --with-openssl-dir=/opt/local
…
make
…
  CCLD     src/or/tor
…
LIBRARY_PATH=/opt/local/lib/gcc5/gcc/x86_64-apple-darwin14/5.1.0/:/opt/local/lib/gcc5/gcc/x86_64-apple-darwin14/5.1.0/../../../:/usr/lib/
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.10.3' '-v' '-g' '-O2' '-D' '_FORTIFY_SOURCE=2' '-fstack-protector-all' '-Wstack-protector' '-fwrapv' '--param' 'ssp-buffer-size=1' '-fPIE' '-fasynchronous-unwind-tables' '-Wall' '-fno-strict-aliasing' '-Wno-deprecated-declarations' '-L/opt/local/lib' '-L/opt/local/lib' '-pie' '-Zdead_strip' '-o' 'src/or/tor' '-mtune=core2'
 /opt/local/libexec/gcc/x86_64-apple-darwin14/5.1.0/collect2 -dynamic -arch x86_64 -dead_strip -macosx_version_min 10.10.3 -pie -weak_reference_mismatches non-weak -o src/or/tor -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib/gcc5/gcc/x86_64-apple-darwin14/5.1.0 -L/opt/local/lib/gcc5/gcc/x86_64-apple-darwin14/5.1.0/../../.. 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/common/libor-event.a src/trunnel/libor-trunnel.a -lz -levent -lssl -lcrypto -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v -idsym
collect2 version 5.1.0
/opt/local/bin/ld -dynamic -arch x86_64 -dead_strip -macosx_version_min 10.10.3 -pie -weak_reference_mismatches non-weak -o src/or/tor -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib/gcc5/gcc/x86_64-apple-darwin14/5.1.0 -L/opt/local/lib/gcc5/gcc/x86_64-apple-darwin14/5.1.0/../../.. 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/common/libor-event.a src/trunnel/libor-trunnel.a -lz -levent -lssl -lcrypto -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v
…
Library search paths:
	/opt/local/lib
	/opt/local/lib
	/opt/local/lib/gcc5/gcc/x86_64-apple-darwin14/5.1.0
	/opt/local/lib/gcc5
	/usr/lib
	/usr/local/lib
Framework search paths:
	/Library/Frameworks/
	/System/Library/Frameworks/
…


>> And a quick sanity check:
>> 
>> Does tor link entirely to /usr/lib when ./configure --with-openssl-dir=/usr is used?
> 
> Yes.
> 
> $ ldd /usr/local/bin/tor
> /usr/local/bin/tor:
>        Start            End              Type Open Ref GrpRef Name
>        00000c1110200000 00000c11107c3000 exe  1    0   0      /usr/local/bin/tor
>        00000c138730b000 00000c1387720000 rlib 0    1   0      /usr/lib/libz.so.5.0
>        00000c13a42bf000 00000c13a46e7000 rlib 0    1   0      /usr/lib/libm.so.9.0
>        00000c139fbb1000 00000c139ffbd000 rlib 0    1   0      /usr/lib/libevent.so.4.1
>        00000c13c83cc000 00000c13c882b000 rlib 0    1   0      /usr/lib/libssl.so.32.0
>        00000c131e761000 00000c131ed36000 rlib 0    1   0      /usr/lib/libcrypto.so.32.0
>        00000c13a8db0000 00000c13a91c2000 rlib 0    2   0      /usr/lib/libpthread.so.18.1
>        00000c137dbb8000 00000c137e0a4000 rlib 0    1   0      /usr/lib/libc.so.78.1
>        00000c137f900000 00000c137f900000 rtld 0    1   0      /usr/libexec/ld.so
> 
>> What about ./configure without an --with-openssl-dir argument?
> 
> $ sudo ./configure --disable-asciidoc --disable-gcc-hardening --sysconfdir=/etc; sudo make check; sudo make install
> 
> $ ldd /usr/local/bin/tor
> /usr/local/bin/tor:
>        Start            End              Type Open Ref GrpRef Name
>        0000158897500000 0000158897ac3000 exe  1    0   0      /usr/local/bin/tor
>        0000158ad2d31000 0000158ad3146000 rlib 0    1   0      /usr/lib/libz.so.5.0
>        0000158aa4f01000 0000158aa5329000 rlib 0    1   0      /usr/lib/libm.so.9.0
>        0000158ab7aeb000 0000158ab7ef7000 rlib 0    1   0      /usr/lib/libevent.so.4.1
>        0000158aaf91f000 0000158aafd7e000 rlib 0    1   0      /usr/lib/libssl.so.32.0
>        0000158ab910e000 0000158ab96e3000 rlib 0    1   0      /usr/lib/libcrypto.so.32.0
>        0000158ac1459000 0000158ac186b000 rlib 0    2   0      /usr/lib/libpthread.so.18.1
>        0000158b5cdee000 0000158b5d2da000 rlib 0    1   0      /usr/lib/libc.so.78.1
>        0000158b64600000 0000158b64600000 rtld 0    1   0      /usr/libexec/ld.so<tor-2.6.9-openbsd-5.7-libressl-2.2.0-config.log><tor-2.6.9-openbsd-5.7-libressl-2.2.0-config-ssl-crypto-only.log>

One of the following methods should give you a tor binary that's linked with /usr/local/lib/libssl.so and /usr/local/lib/libcrypto.so. Once I know which method produces a correctly linked tor binary, I'll have enough information to log a bug with the Tor Trac system.

If you do these in order, please feel free to stop at the first successful method. I only need to know how to get correct tor linkage, with the earliest Tor version, and the fewest extra arguments to ./configure.

Using the sources for Tor 0.2.6.9:

1. Using --with-openssl-dir=/usr/local
./configure --with-openssl-dir=/usr/local
(You used /usr/local/lib previously. This could be the issue.)

2. Using --with-openssl-dir=/usr/local with /usr/local/bin first in the path
PATH=/usr/local/bin:$PATH ./configure --with-openssl-dir=/usr/local

Using the latest git sources for Tor 0.2.7.?-alpha:

3. Using --with-openssl-dir=/usr/local with the latest version of tor
./configure --with-openssl-dir=/usr/local

4. Using --with-openssl-dir=/usr/local with the latest version of tor and /usr/local/bin first in the path
PATH=/usr/local/bin:$PATH ./configure --with-openssl-dir=/usr/local

Thanks for bearing with me during this process.

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
pgp 0xABFED1AC
https://gist.github.com/teor2345/d033b8ce0a99adbc89c5

teor at blah dot im
OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.nycbug.org/pipermail/tor-bsd/attachments/20150701/bd97c6d5/attachment.bin>


More information about the Tor-BSD mailing list