These tests are failing when run against OpenSSL 3, and have been
removed upstream, bitcoin-core/secp256k1#983, so
disabled them for now to avoid make check failures.
Note that this will also remove warning output from our build, due to the use of deprecated OpenSSL API functions. See bitcoin#23048.
No objection to updating to the current master branch.
Do be aware that due to bitcoin-core/secp256k1#956 a table that was previously built at runtime, is now precomputed as part of the source code. That's 2.4 MB of C code being added to the repository, and 0.5 MiB added to the binary size.
I don't expect that to be a problem, but if the binary size increase is an issue, it can be reduced with a configure flag (with a mild validation performance reduction).
If you are going to backport a --disable-openssl-tests to 22.x, wouldn't a cleaner first patch be to submit --disable-openssl-tests to master? This would also avoid a successive bump in a short time.
If you are going to backport a --disable-openssl-tests to 22.x
It wasn't going be to a backport, as I would rather make the subtree update here, but we can always include that commit here, and then do a subtree update after.
This would also avoid a successive bump in a short time.
It's not clear how soon that bump would be, and it could well be too late for 23.0.
Is there anything in the bump that we need, assuming the test issue is fixed with a configure flag? Especially, since you are planning another bump after bitcoin-core/secp256k1#988 (soon?).
No objection to updating to the current master branch.
Same here.
Is there anything in the bump that we need, assuming the test issue is fixed with a configure flag?
I don't think so.
Also, there was discussion about a 1.0 release of libsecp256k1, so I am wondering if we should wait for that as well
These tests are failing when run against OpenSSL 3, and have been
removed upstream, https://github.com/bitcoin-core/secp256k1/pull/983, so
disabled them for now to avoid `make check` failures.
Note that this will also remove warning output from our build, due to
the use of deprecated OpenSSL API functions. See #23048.
cr ACK d7524546abf1fa5be8e6317ee50585e966ae6b4c
Didn't test on Alpine or elsewhere.
Code review ACK d7524546abf1fa5be8e6317ee50585e966ae6b4c
Ok. I've changed this to just disable the tests for now,
Concept ACK
Also, there was discussion about a 1.0 release of libsecp256k1, so I am wondering if we should wait for that as well
This would be a nice goal in order to create pressure on us to do a release. But my more pessimistic internal voice tells me that https://github.com/bitcoin-core/secp256k1/pull/988 will be in before we have a release. Anyway, we should seriously do a release!