Test failure when building against OpenSSL 3 on macOS

fanquake commented at 0:47 am on September 30, 2021: member

Building 2a3a97c665475bc00d5d60f2f04830202983a631:

 0./autogen.sh
 1./configure
 2Build Options:
 3  with ecmult precomp     = yes
 4  with external callbacks = no
 5  with benchmarks         = yes
 6  with tests              = yes
 7  with openssl tests      = yes
 8  with coverage           = no
 9  module ecdh             = no
10  module recovery         = no
11  module extrakeys        = no
12  module schnorrsig       = no
13
14  asm                     = x86_64
15  ecmult window size      = 15
16  ecmult gen prec. bits   = 4
17
18  valgrind                = no
19  CC                      = gcc
20  CPPFLAGS                = -I/usr/local/opt/valgrind/include 
21  SECP_CFLAGS             = -O2  -std=c89 -pedantic -Wno-long-long -Wnested-externs -Wshadow -Wstrict-prototypes -Wundef -Wno-overlength-strings -Wall -Wno-unused-function -Wextra -Wcast-align -Wconditional-uninitialized -fvisibility=hidden 
22  CFLAGS                  = -g -O2
23  LDFLAGS                 = 
24
25  CC_FOR_BUILD            = gcc
26  CPPFLAGS_FOR_BUILD      = -I/usr/local/opt/valgrind/include 
27  SECP_CFLAGS_FOR_BUILD   = -O2  -std=c89 -pedantic -Wno-long-long -Wnested-externs -Wshadow -Wstrict-prototypes -Wundef -Wno-overlength-strings -Wall -Wno-unused-function -Wextra -Wcast-align -Wconditional-uninitialized -fvisibility=hidden 
28  CFLAGS_FOR_BUILD        = -g -O2
29  LDFLAGS_FOR_BUILD       = 
30...
31gmake check -j9
32...
33  CCLD     bench_internal
34  CCLD     bench_ecmult
35  CCLD     libsecp256k1.la
36  CCLD     bench_verify
37  CCLD     bench_sign
386 warnings generated.
39  CCLD     tests
40gmake  check-TESTS
41gmake[1]: Entering directory '/Users/michael/github/secp256k1'
42gmake[2]: Entering directory '/Users/michael/github/secp256k1'
43PASS: exhaustive_tests
44./build-aux/test-driver: line 112: 88313 Abort trap: 6           "$@" >> "$log_file" 2>&1
45FAIL: tests
46============================================================================
47Testsuite summary for libsecp256k1 0.1
48============================================================================
49# TOTAL: 2
50# PASS:  1
51# SKIP:  0
52# XFAIL: 0
53# FAIL:  1
54# XPASS: 0
55# ERROR: 0
56============================================================================
57See ./test-suite.log
58============================================================================
59gmake[2]: *** [Makefile:1307: test-suite.log] Error 1

test-suite.log:

 0========================================
 1   libsecp256k1 0.1: ./test-suite.log
 2========================================
 3
 4# TOTAL: 2
 5# PASS:  1
 6# SKIP:  0
 7# XFAIL: 0
 8# FAIL:  1
 9# XPASS: 0
10# ERROR: 0
11
12.. contents:: :depth: 2
13
14FAIL: tests
15===========
16
17test count = 64
18random seed = 59e74cf6fdde17e225a9ade47f72f707
19Failure 10 on 30 24 02 06 b1 c3 87 ff 07 00 02 1a 45 00 00 08 00 00 00 00 00 00 00 10 00 00 00 02 00 00 00 00 00 00 80 ff 07 80 
20src/tests.c:6015: test condition failed: ret == 0
21FAIL tests (exit status: 134)

config.log

If I build against an older version of OpenSSL, i.e 1.1, I don’t see any issues:

 0./autogen.sh
 1CRYPTO_LIBS="-L/usr/local/opt/openssl@1.1/lib" CRYPTO_CFLAGS="-I/usr/local/opt/openssl@1.1/include" ./configure
 2gmake check -j9
 3....
 4gmake  check-TESTS
 5gmake[1]: Entering directory '/Users/michael/github/secp256k1'
 6gmake[2]: Entering directory '/Users/michael/github/secp256k1'
 7PASS: exhaustive_tests
 8PASS: tests
 9============================================================================
10Testsuite summary for libsecp256k1 0.1
11============================================================================
12# TOTAL: 2
13# PASS:  2
14# SKIP:  0
15# XFAIL: 0
16# FAIL:  0
17# XPASS: 0
18# ERROR: 0
19============================================================================

real-or-random commented at 1:42 pm on October 3, 2021: contributor

This does mean that any non-bitcoin libsecp256k1 users that need to interoperate with openssl may now experience inconsistencies. … and maybe it suggests that libsecp256k1 should increase the strictness of its standard ecdsa parser to match the bitcoin strictder, which should also make it consistent with openssl 3. (legacy signatures in the blockchain are supported by the ’lax’ parser in contrib in any case).

This would be a breaking change, so I don’t think we should do it. I’d prefer API stability over compatibility with OpenSSL 3. There are some (blockchain/encoding-critical) projects out there that rely on libsecp256k1 (without the lax parser).

real-or-random commented at 5:58 pm on October 3, 2021: contributor

As far as breaking, the obvious thing to do would be to just introduce the stricter parser under a different name and recommend it, and mark the old one as deprecated (and potentially move it to contrib with the other lax parsers).

Ok sure, we could do this but it’s work and I don’t think Bitcoin Core would benefit from this, so we should not spend time on this. And new applications shouldn’t use ECDSA at all.

andypost commented at 10:14 pm on October 5, 2021: none

The related issue https://github.com/bitcoin/bitcoin/issues/23048

real-or-random closed this on Oct 16, 2021

daira cross-referenced this on Sep 26, 2022 from issue secp256k1 test failure on machines with OpenSSL 3.0.x installed by daira

Test failure when building against OpenSSL 3 on macOS #984