49e2acd927ce9eb806cc10f3a1fd89a9ddd081e2 configure: Improve rationale for WERROR_CFLAGS (Tim Ruffing)
8dc4b03341c85a3be91e559d05771c51e60b0eba ci: Add a C++ job that compiles the public headers without -fpermissive (Tim Ruffing)
51f296a46c0b318b8dd572ef9ac3bb3a4140ae63 ci: Run persistent wineserver to speed up wine (Tim Ruffing)
3fb3269c22c25de3b720ad139dcf4e3cff9eda1a ci: Add 32-bit MinGW64 build (Tim Ruffing)
9efc2e5221560d19dd750e0ba32c03d4ee091227 ci: Add MSVC builds (Tim Ruffing)
2be6ba0fedd0d2d62ba6f346d7ced7abde0d66e4 configure: Convince autotools to work with MSVC's archiver lib.exe (Tim Ruffing)
bd81f4140a4228b1df3a9f631e2d207a197ae614 schnorrsig bench: Suppress a stupid warning in MSVC (Tim Ruffing)
09f3d71c51a9621653d766e2fe7e657534e57bd6 configure: Add a few CFLAGS for MSVC (Tim Ruffing)
3b4f3d0d46dd278fbe4ffa68b1b6e14e3ea3b17f build: Reject C++ compilers in the preprocessor (Tim Ruffing)
1cc09414149d0c0c6a4a500d83efc3bd66f3ebcd configure: Don't abort if the compiler does not define __STDC__ (Tim Ruffing)
cca8cbbac84624fd350efc4086af25a06dcf8090 configure: Output message when checking for valgrind (Tim Ruffing)
1a6be5745fcf9f90e4218b73712b71ea06361792 bench: Make benchmarks compile on MSVC (Tim Ruffing)
Pull request description:
ACKs for top commit:
jonasnick:
ACK 49e2acd927ce9eb806cc10f3a1fd89a9ddd081e2
Tree-SHA512: 986c498fb218231fff3519167d34a92e11dea6a4383788a9723be105c20578cd483c6b06ba5686c6669e3a02cfeebc29b8e5f1428552ebf4ec67fa7a86957548
This commit also raises the TEST_ITERS for wine tasks to the default.
The overhead of wine is negligible, so we can certainly afford the same
number of iterations as for native Linux tests.
This adds MSVC builds built on Linux using wine. This requires some
settings of tools and flags because the autotools support for MSVC is
naturally somewhat limited.
The advantage of this approach is that it is compatible with our
existing CI scripts, so there's no need to write a Windows CI script
(in PowerShell or similar). If we want to test building and running on
Windows native (e.g., as supported by Cirrus CI) we could still do this
in the future.
Another advantage of this approach is that contributors can simply use
the docker image if they need a MSVC installation in a non-Windows
environment.
This commit also improves the Dockerfile by grouping RUN commands
according to Docker docs:
https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#run
6f6cab9989a4d3f4a28e3cdbfacc4e3e1e55c843 abi: Don't export symbols in static Windows libraries (Cory Fields)
Pull request description:
For context, Bitcoin Core has recently merged [libbitcoin-kernel](https://github.com/bitcoin/bitcoin/pull/24322), a small library that intends to eventually minimally encompass Core's validation engine. This kernel lib includes a static libsecp256k1. Without this change, because libsecp256k1.a ends up with exported symbols, we end up with libsecp256k1 symbols exported by our libbitcoin-kernel library (which causes unrelated problems not worth getting into here).
libtool takes care of building both object versions, and it automatically builds objects for shared libs with -DDLL_EXPORT. We just need to opt-in to its functionality.
I can't imagine this having any negative impact on any current statically-linking applications, if anything they'll just be a tiny bit smaller because they can now strip unused symbols.
ACKs for top commit:
real-or-random:
utACK 6f6cab9989a4d3f4a28e3cdbfacc4e3e1e55c843
theuni:
> Not sure what other changes made compilation on CI fail but Concept ACK [6f6cab9](6f6cab9989). This should be entirely harmless.
sipa:
utACK 6f6cab9989a4d3f4a28e3cdbfacc4e3e1e55c843
laanwj:
utACK 6f6cab9989a4d3f4a28e3cdbfacc4e3e1e55c843
Tree-SHA512: 39f240046639738f7a8c01068e728b2f9ceac2754cc4b0a5fa46c28f6f57a8c4124653b56dfbf5c13106b07c11ac599cc41b508e16862d539ce1af6c3365a205
7efc9835a977c6400f0f024f19fda47710151dc1 Fix the false positive of `SECP_64BIT_ASM_CHECK` (Sprite)
Pull request description:
I'm trying to compile this project for RISC-V architecture, and I encountered errors:
```
src/field_5x52_asm_impl.h:28:1: error: unknown register name '%r15' in 'asm'
28 | __asm__ __volatile__(
| ^
src/field_5x52_asm_impl.h:28:1: error: unknown register name '%r14' in 'asm'
src/field_5x52_asm_impl.h:28:1: error: unknown register name '%r13' in 'asm'
src/field_5x52_asm_impl.h:28:1: error: unknown register name '%r12' in 'asm'
src/field_5x52_asm_impl.h:28:1: error: unknown register name '%r11' in 'asm'
src/field_5x52_asm_impl.h:28:1: error: unknown register name '%r10' in 'asm'
src/field_5x52_asm_impl.h:28:1: error: unknown register name '%r9' in 'asm'
src/field_5x52_asm_impl.h:28:1: error: unknown register name '%r8' in 'asm'
src/field_5x52_asm_impl.h:28:1: error: unknown register name '%rdx' in 'asm'
src/field_5x52_asm_impl.h:28:1: error: unknown register name '%rcx' in 'asm'
src/field_5x52_asm_impl.h:28:1: error: unknown register name '%rax' in 'asm'
src/field_5x52_asm_impl.h:28:1: error: output number 0 not directly addressable
src/field_5x52_asm_impl.h: In function 'secp256k1_fe_sqr':
src/field_5x52_asm_impl.h:298:1: error: unknown register name '%r15' in 'asm'
298 | __asm__ __volatile__(
| ^
src/field_5x52_asm_impl.h:298:1: error: unknown register name '%r14' in 'asm'
src/field_5x52_asm_impl.h:298:1: error: unknown register name '%r13' in 'asm'
src/field_5x52_asm_impl.h:298:1: error: unknown register name '%r12' in 'asm'
src/field_5x52_asm_impl.h:298:1: error: unknown register name '%r11' in 'asm'
src/field_5x52_asm_impl.h:298:1: error: unknown register name '%r10' in 'asm'
src/field_5x52_asm_impl.h:298:1: error: unknown register name '%r9' in 'asm'
src/field_5x52_asm_impl.h:298:1: error: unknown register name '%r8' in 'asm'
src/field_5x52_asm_impl.h:298:1: error: unknown register name '%rdx' in 'asm'
src/field_5x52_asm_impl.h:298:1: error: unknown register name '%rcx' in 'asm'
src/field_5x52_asm_impl.h:298:1: error: unknown register name '%rbx' in 'asm'
src/field_5x52_asm_impl.h:298:1: error: unknown register name '%rax' in 'asm'
src/field_5x52_asm_impl.h:298:1: error: output number 0 not directly addressable
```
After further investigation I found that for RISC-V, macro `USE_ASM_X86_64` was defined unexpectedly, and `checking for x86_64 assembly availability... yes` appeared in the compilation log file, which means `SECP_64BIT_ASM_CHECK` was not working as expected.
For unknown reasons, `AC_COMPILE_IFELSE` does not check if `__asm__` can be compiled, and an example can verify this point:
```m4
AC_DEFUN([SECP_64BIT_ASM_CHECK],[
AC_MSG_CHECKING(for x86_64 assembly availability)
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
#include <stdint.h>]],[[
__asm__ __volatile__("this is obviously wrong");
]])],[has_64bit_asm=yes],[has_64bit_asm=no])
AC_MSG_RESULT([$has_64bit_asm])
])
```
It always gives results: `checking for x86_64 assembly availability... yes`
After testing, replacing `AC_COMPILE_IFELSE` with `AC_LINK_IFELSE` can correctly check if `__asm__` can be compiled and make the project able to compile for RISC-V.
ACKs for top commit:
real-or-random:
ACK 7efc9835a977c6400f0f024f19fda47710151dc1
Tree-SHA512: 7318dd42004b2930cfcd6541c5a9ce0aa186e2179a668b76089a908bea8d9f70fcfdb264512f971e395a3ce9dc7f9ca24c8f3d46175cad2972a2d713f518ed85
2f984ffc45eba89faa9e79da3d5d5bd50a6c1c3d Save negations in var-time group addition (Peter Dettman)
Pull request description:
- Updated _gej_add_var, _gej_add_ge_var, _gej_add_zinv_var
- 2 fewer _fe_negate in each method
- Updated operation counts and standardize layout
- Added internal benchmark for _gej_add_zinv_var
benchmark_internal shows about 2% speedup in each method as a result (64bit).
ACKs for top commit:
real-or-random:
ACK 2f984ffc45eba89faa9e79da3d5d5bd50a6c1c3d
jonasnick:
ACK 2f984ffc45eba89faa9e79da3d5d5bd50a6c1c3d
Tree-SHA512: 01366fa23c83a8dd37c9a0a24e0acc53ce38a201607fe4da6672ea5618d82c62d1299f0e0aa50317883821539af739ea52b6561faff230c148e6fdc5bc5af30b
37d36927dff793e61df6d6f6a6c50e8fa2519e33 tests: Add tests for _read_be32 and _write_be32 (Tim Ruffing)
616b43dd3b6949923f0752cd60382153cfd5dda9 util: Remove endianness detection (Tim Ruffing)
8d89b9e6e562000cdb91a70a85fae5e4817cec8a hash: Make code agnostic of endianness (Tim Ruffing)
Pull request description:
Recent compilers compile the two new functions to very efficient code
on various platforms. In particular, already GCC >= 5 and clang >= 5
understand do this for the read function, which is the one critical
for performance (called 16 times per SHA256 transform).
Fixes#1080.
ACKs for top commit:
sipa:
utACK 37d36927dff793e61df6d6f6a6c50e8fa2519e33
robot-dreams:
ACK 37d36927dff793e61df6d6f6a6c50e8fa2519e33
Tree-SHA512: b03cec67756fb3c94ca8e7e06f974136050efd5065f392dba6eed4d0dbe61dbf93dad054627267225bac1bb302bb025f86588612ef7d4beeb834466686c70b8f
55512d30b7921bc46247a78be1da98108f243c1c doc: clean up module help text in configure.ac (Elliott Jin)
d9d94a9969785abbb3e04b2b9f75f1049c7b8936 doc: mention optional modules in README (Elliott Jin)
Pull request description:
ACKs for top commit:
real-or-random:
utACK 55512d30b7921bc46247a78be1da98108f243c1c
jonasnick:
ACK 55512d30b7921bc46247a78be1da98108f243c1c
Tree-SHA512: ae4ec355730983117c5e9a8a8abd17aaf42afe6f8f8f7474a551df6269a62094883e0827d2f3642e3ed6eb26cf71982c20f7ac27498cb4bd7e4aea57ec308d6a
Recent compilers compile the two new functions to very efficient code
on various platforms. In particular, already GCC >= 5 and clang >= 5
understand do this for the read function, which is the one critical
for performance (called 16 times per SHA256 transform).
Fixes#1080.
7f09d0f311117289719b690f91f6a907c2c6f3e2 README: mention that ARM assembly is experimental (Jonas Nick)
80cf4eea5fa0162350614c08f2252a07f9d7804b build: stop treating schnorrsig, extrakeys modules as experimental (Jonas Nick)
Pull request description:
Fixes#992
ACKs for top commit:
real-or-random:
ACK 7f09d0f311117289719b690f91f6a907c2c6f3e2
fanquake:
ACK 7f09d0f311117289719b690f91f6a907c2c6f3e2 - When this is in, I think we'll do a subtree update in Core, and prune some build cruft on our side.
Tree-SHA512: 13deb82dcca88bacb2cd5c1c589a8d4af2277c4d675262337ae4d7e93eb41d43825dda4945ca1c202c36aaa2e6fd42de9c6d711fe8d71bce578368281db698b2
b8f8b99f0fb3a5cd4c6fb1c9c8dfed881839e19e docs: Fix return value for functions that don't have invalid inputs (Tim Ruffing)
f813bb0df3153dc055e0e76101ed9e4607155870 schnorrsig: Adapt example to new API (Tim Ruffing)
99e6568fc6ea2768f5355eb4617283086f756931 schnorrsig: Rename schnorrsig_sign to schnorsig_sign32 and deprecate (Tim Ruffing)
fc94a2da4457325c4be539838ceed21b31c60fbd Use SECP256K1_DEPRECATED for existing deprecated API functions (Tim Ruffing)
3db0560606acb285cc7ef11662ce166ed67e9015 Add SECP256K1_DEPRECATED attribute for marking API parts as deprecated (Tim Ruffing)
Pull request description:
Should be merged before #995 if we want this.
I suspect the only change here which is debatable on a conceptual level is the renaming. I can drop this of course.
ACKs for top commit:
sipa:
utACK b8f8b99f0fb3a5cd4c6fb1c9c8dfed881839e19e
jonasnick:
ACK b8f8b99f0fb3a5cd4c6fb1c9c8dfed881839e19e
Tree-SHA512: 7c5b9715013002eecbf2e649032673204f6eaffe156f20e3ddf51fab938643847d23068f11b127ef3d7fe759e42a20ecaf2ec98718d901ef9eaadbc9853c1dfe
f8d9174357391ab4bf65a2f4d9d9cfb8039dc592 Add SHA256 bit counter tests (Tim Ruffing)
9b514ce1d25f1944c549ead30cc84367d616e0e6 Add test vector for very long SHA256 messages (Tim Ruffing)
8e3dde113741615fcb1aedcacfc54bd3b3d204f1 Simplify struct initializer for SHA256 padding (Tim Ruffing)
eb28464a8bf8652a2b49d2ed765801d7c0aa195d Change SHA256 byte counter from size_t to uint64_t (Tim Ruffing)
Pull request description:
This avoids that the SHA256 implementation would produce wrong paddings
and thus wrong digests for messages of length >= 2^32 bytes on 32-bit
platforms.
This is not exploitable in any way since the SHA256 API is an internal
API and we never call it with that long messages.
This also simplifies the struct initializer for the padding.
Since missing elements are initialized with zeros, this change is
purely syntactical.
ACKs for top commit:
sipa:
utACK f8d9174357391ab4bf65a2f4d9d9cfb8039dc592
jonasnick:
ACK f8d9174357391ab4bf65a2f4d9d9cfb8039dc592
Tree-SHA512: 4fba64b255ef34bb144e4ac6d796798d620d6a7a0f3be409a46b98a8aedb129be19a6816b07caa4d1a3862a01769b42ce70240690fddc6231d591e6c06252750
_tagged_sha256 simply cannot have invalid inputs.
The other functions could in some sense have invalid inputs but only in
violation of the type system. For example, a pubkey could be invalid but
invalid objects of type secp256k1_pubkey either can't be obtained
via the API or will be caught by an ARG_CHECK when calling pubkey_load.
This is consistent with similar functions in the public API, e.g.,
_ec_pubkey_negate or _ec_pubkey_serialize.
This removes a check for $ac_cv_prog_cc_c89 which is set by AC_PROG_CC
if defined(__STDC__) in the preprocessor. (Standard compliant compilers
are supposed to define __STDC__ to 1 but the value is actually not
checked here.)
Unfortunately, MSVC doesn't define it, so configure fails for MSVC.
This check is not very useful in practice. Over 30 years after C89 has
been released, there are no C compilers out there that are not
sufficiently compliant with C89 for the project. The only practically
relevant case was that the check rejected C++ compilers. A different
method to reject C++ compilers will be introduced in a later commit.
21b2ebaf74222017f85123deb6f30a33c7678513 configure: Remove redundant pkg-config code (Tim Ruffing)
Pull request description:
This removes code that detects the pkg-config tool. We used this
back in the days when we had dependencies. ;) It can always be brought
back if we'll need it in the future.
Note that we still deliver a .pc file for this library, and there is
code in Makefile.am to install it. But this does not require the
pkg-config tool; only consumers of the .pc file will need it. This can
be verified by running `make install` (maybe after `mkdir /tmp/pre` and
`./configure --prefix=/tmp/pre` and checking that the .pc file is
installed correctly.
ACKs for top commit:
theuni:
ACK 21b2ebaf74222017f85123deb6f30a33c7678513.
fanquake:
ACK 21b2ebaf74222017f85123deb6f30a33c7678513
Tree-SHA512: 07affcd0e85f59d10479f279c832b1384208bead2fd152e0d1e3d99167dba4e14dbe87b0bc9c367f0f18da3d37f1d51de064689bff329ee5b01cacfe54e5ede7
This removes code that detects the pkg-config tool. We used this
back in the days when we had dependencies. ;) It can always be brought
back if we'll need it in the future.
Note that we still deliver a .pc file for this library, and there is
code in Makefile.am to install it. But this does not require the
pkg-config tool; only consumers of the .pc file will need it. This can
be verified by running `make install` (maybe after `mkdir /tmp/pre` and
`./configure --prefix=/tmp/pre` and checking that the .pc file is
installed correctly.
0d253d52e804a5affb0f1c851ec250071e7345d9 configure: Use modern way to set AR (Tim Ruffing)
Pull request description:
ACKs for top commit:
jb55:
tACK 0d253d52e804a5affb0f1c851ec250071e7345d9
hebasto:
ACK 0d253d52e804a5affb0f1c851ec250071e7345d9
jonasnick:
ACK 0d253d52e804a5affb0f1c851ec250071e7345d9
Tree-SHA512: c85a068b0b6cd0ae59c796d4493d50b1d92394b8620dd65affb5aaac889a41aa625408062f49fbed761217ab2bc35ec10942684a84487cb81becdadf5f2ae2af
This uses AM_PROG_AR to discover ar, which is the recommended way to do
so. Among other advantages, it honors the AR environment variable (as
set from the outside). The macro has been around since automake 1.11.2
(Dec 2011).
This commit also removes code that discovers ranlib and strip. ranlib
has been obsolete for decades (ar does its task now automatically), and
anyway LT_INIT takes care of discovering it. The code we used to set
STRIP was last mentioned in the automake 1.5 manual. Since automake 1.6
(Mar 2002), strip is discovered automatically when necessary (look for
the *private* macro AM_PROG_INSTALL_STRIP in the automake manual).
The vector has been taken from https://www.di-mgt.com.au/sha_testvectors.html.
It can be independently verified using the following Python code.
```
h = hashlib.sha256()
for i in range(1_000_000):
h.update(b'a')
print(h.hexdigest())
```
This avoids that the SHA256 implementation would produce wrong paddings
and thus wrong digests for messages of length >= 2^32 bytes on 32-bit
platforms.
This is not exploitable in any way since the SHA256 API is an internal
API and we never call it with that long messages.
