MacOS 10.13 Beta Compile Error (BoringSSL), Phoenix Project

LawJolla · June 6, 2017, 10:05pm

The following error is above my pay grade It appears to be from Phoenix (based on the complier starting Phoenix first) but I’m not sure. If there’s a work around, that’d be great. I’d like to keep using the beta.

Trying Mac 10.13 beta and iex -S mix error:

Assertion failed: (ctx), function digest_update, file /BuildRoot/Library/Caches/com.apple.xbs/Sources/boringssl/boringssl-88.0.0.1.1/apple/crypto/digests.c, line 47.
Abort trap: 6

Not sure how to fix boringssl. Any ideas?

#UPDATE
mix new
iex -S mix
No error

Add any dependency, mix deps.get #same error

MarioFlach · June 7, 2017, 10:40am

Got the same problem here.

Seems to be a problem with Erlang SSL itself and not Elixir in particular:

Eshell V9.0  (abort with ^G)
1> ssl:start().
ok
2> ssl:connect("google.com", 443, []).
Assertion failed: (ctx), function digest_update, file /BuildRoot/Library/Caches/com.apple.xbs/Sources/boringssl/boringssl-88.0.0.1.1/apple/crypto/digests.c, line 47.

I’m currently trying to build Erlang and OTP with different SSL options. Will repost here if it works.

I’m not really sure what mix does at project startup. Seems like it checks Hex for package updates etc.
Maybe you could disable that as a basic workaround (still your BEAM will crash when you make your first SSL request…).

Nicke · June 7, 2017, 12:16pm

Were you able to resolve this? I’m having the same issue.

MarioFlach · June 7, 2017, 12:35pm

Nope, I tried a few things:

Installing via a different “package manager”.
Editing the Erlang Homebrew formula to use BoringSSL (see here) with flags --with-ssl=/usr/local/opt/boringssl and --disable-dynamic-ssl-lib.
Reinstalling OpenSSL, using different version, etc.

I’m not really sure how the problem actually occurs.

Did Apple change their out-of-date OpenSSL with BoringSSL in 10.13?
Why is it even using BoringSSL when I compile Erlang with --with-ssl=/usr/local/opt/openssl?
When I compile Erlang with a different SSL backend , I still get [{<<"OpenSSL">>,9470495,<<"OpenSSL 0.9.8zh 14 Jan 2016">>}] when calling crypto:info_lib().
Is --with-ssl relevant when installing with brew install erlang --HEAD?

MarioFlach · June 7, 2017, 3:32pm

So, I’ve been trying a few different things without success.

I’ve been playing around with kerl to build and install a custom version of Erlang.
I tried to build with different crypto backends openssl, libressl, boringssl in the build options:

--with-ssl=/usr/local/opt/libressl

Make sure that libcrypto has been linked correctly:

$ otool -L kerl/19.3/lib/crypto-3.7.3/priv/lib/crypto.so 
kerl/19.3/lib/crypto-3.7.3/priv/lib/crypto.so:
	/usr/local/opt/libressl/lib/libcrypto.41.dylib (compatibility version 42.0.0, current version 42.1.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)

1> crypto:info_lib().
[{<<"OpenSSL">>,536870912,<<"LibreSSL 2.5.4">>}]

Analyse erl with dtrace and other tools to try to figure out where the crash happens with a simple ssl:connect/3 call:

...
55688/0x1c540c:  stat64("/Users/redrabbit/kerl/19.3/lib/crypto-3.7.3/priv/lib/crypto.so\0", 0xB12B0FC0, 0x20)        = 0 0
55688/0x1c540c:  open("/Users/redrabbit/kerl/19.3/lib/crypto-3.7.3/priv/lib/crypto.so\0", 0x0, 0x0)      = 33 0
...
55688/0x1c540c:  stat64("/usr/local/opt/libressl/lib/libcrypto.41.dylib\0", 0xB12B0DE0, 0x1)         = 0 0
55688/0x1c540c:  open("/usr/local/opt/libressl/lib/libcrypto.41.dylib\0", 0x0, 0x0)      = 33 0
...
55688/0x1c5400:  open("/Users/redrabbit/kerl/19.3/lib/ssl-8.1.1/ebin/ssl_cipher.beam\0", 0x0, 0x1B6)         = 33 0
...
55688/0x1c53fe:  open("/Users/redrabbit/kerl/19.3/lib/ssl-8.1.1/ebin/tls_v1.beam\0", 0x0, 0x1B6)         = 33 0
...
55688/0x1c53fe:  open("/Users/redrabbit/kerl/19.3/lib/ssl-8.1.1/ebin/tls_socket.beam\0", 0x0, 0x1B6)         = 33 0

From my analyse, I cannot tell where the process is actually crashing. It seems it’s in ssl_connection.beam. But can’t say for sure.

The only external libraries being present in the logs being Erlang’s crypto.so and crypto_callback.so and the ssl lib (in my current test case, libcrypto.41.dylib from libressl).

If anybody more experienced wants to help , he/she would be really welcome.

But hey, that’s what happens when you play with the first beta .

johnnyji · June 7, 2017, 8:10pm

I’d like to second @Nicke, this is what happens when I’m too trigger happy on the updates haha

LawJolla · June 8, 2017, 2:46am

Similar messages are appearing on the Apple Developer Forums…

On Xcode 9, iOS 11, swift 4, while debugging on my device I get this erroneous error output:

network_config_register_boringssl_log_debug_updates Failed to register for BoringSSL log debug updates
[BoringSSL] Function boringssl_context_get_peer_npn_data: line 1212 Peer’s advertised NPN data is NULL or empty

Any idea what’s causing this? Does iOS 11 use BoringSSL now?

Thank!

idyll · June 12, 2017, 8:22pm

I had a friend who took this to the labs at WWDC. Here’s the story:
Apple is trying to ditch openSSL in 10.13.
Internally they are using a fork of boringssl
Externally they want everyone to link against LibreSSL.

If you run otool it will report if it’s two level.

otool -hV

FLATNAMESPACE or TWOLEVEL

The Crypto lib is not TWOLEVEL.

idyll · June 12, 2017, 8:24pm

Have you opened a ticket with Erlang?
I would like to add a bunch of info I have collected there.

MarioFlach · June 13, 2017, 9:09am

I did not open a ticket on the Erlang/OTP platform.

However after searching for more BoringSSL errors with the new macOS beta, I found an issue on the elixir-lang Github created by @LawJolla and referenced this thread.

https://github.com/elixir-lang/elixir/issues/6200

I thought it would be wiser to wait if this issue get’s fixed by Apple itself in the next beta update. Not sure if Erlang does anything “special” with the :crypto NIF…

idyll · June 22, 2017, 5:10pm

MacOS 10.13B2 still exhibits this issue.

I have opened https://bugs.erlang.org/browse/ERL-439 with Erlang.

Hopefully I am just using the wrong flags.

outlog · June 22, 2017, 7:22pm

have you tried with asdf? https://github.com/asdf-vm/asdf - believe brew is a binary install but can’t remember - asdf compiles erlang so it might work… or you can tune the ssl compile settings in your installed plugin (in ~/.asdf/plugins/erlang/bin/install)

https://github.com/asdf-vm/asdf-erlang/blob/master/bin/install#L102 - from a quick look it looks like it likes to use a brew installed openssl…

idyll · June 23, 2017, 4:44am

You can force brew to compile, instead of use a binary. I changed the compiler flags to try to force it to be statically linked against openssl 1.0.1 installed by brew. I did this for OTP19 and OTP20. When I tried it OTP 20 didn’t even have an official binary in brew.

outlog · July 4, 2017, 3:07pm

fyi, there is a PR with a fix in otp:

asdf install erlang ref:882c90f72ba4e298aa5a7796661c28053c540a96 will install that commit…

and then a asdf global erlang ref-882c90f72ba4e298aa5a7796661c28053c540a96 to make it the default erlang.

not sure about the brew cmds for the same.

https://github.com/erlang/otp/pull/1501/commits/882c90f72ba4e298aa5a7796661c28053c540a96

NobbZ · September 12, 2017, 7:01pm

8 posts were split to a new topic: Installing phoenix in asdf-elixir