0make
1[...]
2In file included from src/secp256k1.c:839:
3src/modules/frost/main_impl.h:878:58: warning: variable 'rho_i' may be uninitialized when used here [-Wconditional-uninitialized]
4878| secp256k1_gej_mul_scalar(&partial, &binding_cmt, rho_i);
5|^~~~~ 6src/modules/frost/main_impl.h:855:32: note: initialize the variable 'rho_i' to silence this warning
7855| secp256k1_scalar *rho_i;
8|^ 9|= NULL
10src/modules/frost/main_impl.h:1308:54: warning: variable 'matching_rho_i' may be uninitialized when used here [-Wconditional-uninitialized]
111308| secp256k1_gej_mul_scalar(&partial, &binding_cmt, matching_rho_i);
12|^~~~~~~~~~~~~~13src/modules/frost/main_impl.h:1252:37: note: initialize the variable 'matching_rho_i' to silence this warning
141252| secp256k1_scalar *matching_rho_i;
15|^16|= NULL
172 warnings generated.18[...more errors...]
frost: first release of the secp256k1-frost implementation by Bank of Italyc31b9c193c
doc: remove trailing newlines53237240df
frost: add copyright headers42ca3cf661
doc: add reference to the original authors and a link to the itcoin projectc52279b8bc
frost: reformat code baseb4c4479e23
frost: add secp256k1_frost_pubkey_save() and secp256k1_frost_pubkey_load()ddc7c41362
Merge secp256k1 44c2452fd387 (bitcoin v24.x) into secp256k1-frost
Secp256k1 version 44c2452fd387 is the one that got into bitcoin v24.0 and v24.1.
It got there via https://github.com/bitcoin/bitcoin/commit/913b1f2a5eb2ee5cd02113791764b23ded4c1c94
304c5a80f4
build: port to the current syntax the configure.ac snippet that enables frost
Between secp256k1 0559fc6e41b6 and 44c2452fd387 the code that enabled the
various submodules got slightly changed.
This commit ports those changes to the frost module, too.
aae5337ce4
frost: missing error check in deserialize_frost_signature() could lead to UB in secp256k1_frost_verify()
The upstream function secp256k1_ge_set_xo_var() in src/group_impl.h returns an
int signalling an error condition, but it is not marked with
SECP256K1_WARN_UNUSED_RESULT.
Thus, when compiling the Frost module, no warning was generated when
deserialize_frost_signature() had no check covering the case that
secp256k1_ge_set_xo_var() could fail.
The GCC static analyzer found two potential execution paths in
secp256k1_frost_verify() that would lead to undefined behaviour. For brevity,
the issues are not reported here, but only in the Github PR associated with
this commit (https://github.com/bancaditalia/secp256k1-frost/pull/5).
As of today (2023-05-29), in bitcoin-core secp256k1, secp256k1_ge_set_xo_var()
is still not marked SECP256K1_WARN_UNUSED_RESULT, see:
https://github.com/bitcoin-core/secp256k1/blob/908e02d596b66203788e8945b1f9c93ff28a4536/src/group_impl.h#L280
It may make sense to propose upstream to add that annotation.
In order to replicate the issues fixed by this commit, compile with:
./configure SECP_CFLAGS="-fanalyzer -fanalyzer-transitivity" --disable-tests --disable-exhaustive-tests --disable-benchmark --enable-experimental --enable-module-frost
18b40628c9
frost: remove potential memory leak in secp256k1_frost_aggregate()
The leak presented if compute_binding_factors() failed. In that case the error
reporting path would not deallocate the binding factor that were allocated just
above.
Found with gcc 13.1 via:
./configure SECP_CFLAGS="-fanalyzer -fanalyzer-transitivity" --disable-tests --disable-exhaustive-tests --disable-benchmark --enable-experimental --enable-module-frost
The analyzer found 3 leaks at main_impl.h:1403, all of them solved by this
change. The branch analysis of the first leak was:
```
In file included from src/secp256k1.c:767:
src/modules/frost/main_impl.h: In function 'secp256k1_frost_aggregate':
src/modules/frost/main_impl.h:1454:1: warning: leak of 'binding_factors.binding_factors' [CWE-401] [-Wanalyzer-malloc-leak]
1454 | }
| ^
'secp256k1_frost_aggregate': events 1-2
|
| 1365 | SECP256K1_API int secp256k1_frost_aggregate(const secp256k1_context *ctx,
| | ^~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (1) entry to 'secp256k1_frost_aggregate'
[...]
| 1394 | binding_factors.binding_factors = (secp256k1_scalar *)
| 1395 | checked_malloc(&default_error_callback, num_signers * sizeof(secp256k1_scalar));
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (10) calling 'checked_malloc' from 'secp256k1_frost_aggregate'
|
+--> 'checked_malloc': events 11-15
|
|src/util.h:118:31:
| 118 | static SECP256K1_INLINE void *checked_malloc(const secp256k1_callback* cb, size_t size) {
| | ^~~~~~~~~~~~~~
| | |
| | (11) entry to 'checked_malloc'
| 119 | void *ret = malloc(size);
| | ~~~~~~~~~~~~
| | |
| | (12) allocated here
[...]
'secp256k1_frost_aggregate': events 29-30
|
| 1403 | if (compute_binding_factors(&binding_factors, msg32, 32, num_signers, commitments) == 0) {
| | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (29) ...to here
|......
| 1454 | }
| | ~
| | |
| | (30) 'binding_factors.binding_factors' leaks here; was allocated at (12)
|
```
49749cd0c2
frost: move free_binding_factors() to the top
In the next commit, this will allow us to call it from inside
secp256k1_frost_sign().
No functional changes.
a98dd0caca
frost: use free_binding_factors() in secp256k1_frost_sign()
In this way we have a single way of clearing binding factors across the code
base. Before this change, secp256k1_frost_sign() was the only function that
rolled its own code.
eb3858dcf8
frost: rename "_identityPoint" -> "_invalidPoint" in tests
No functional changes.
b5b7935830
frost: gej_mul_scalar does not call ecmult with an infinity pointd2b0b7ba02
frost: initialize points as infinite instead of invalid5e1370f3fd
build: mention frost in the pkg-config description of the library. Link to Bank of Italy's github fork
A reference per the pkg-config sytax can be found in "man 5 pc", or online at
https://man.freebsd.org/cgi/man.cgi?query=pc&sektion=5&n=1
EXAMPLES
An example .pc file:
# This is a comment
prefix=/home/kaniini/pkg # this defines a variable
exec_prefix=${prefix} # defining another variable with a substitution
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: libfoo # human-readable name
Description: an example library called libfoo # human-readable description
Version: 1.0
URL: http://www.pkgconf.org
Requires: libbar > 2.0.0
Conflicts: libbaz <= 3.0.0
Libs: -L${libdir} -lfoo
Libs.private: -lm
Cflags: -I${includedir}/libfoo
e02b3f8235
build: replace links with those of Bank of Italy's fork79fb781b04
frost: add FROST usage example43cdbb722e
frost: use parentheses around argument of sizeof()
As per C89 standard (https://www.open-std.org/JTC1/sc22/wg14/www/docs/n1256.pdf,
section 6.5.3 "Unary operators") we are only required to parenthesize a sizeof()
call if the argument is a type name, which is not the case here.
However, it is less surprising to err on the side of caution, and uniformly
enclose in parentheses every sizeof() invocation across the code base.
No functional changes.
684142b0d9
frost: in compute_binding_factor(), free encoded_group_commitments as soon as no longer needed
Given that - at least for now - we are allocating memory dynamically, let's free
it as soon as it is no longer needed.
Valgrind shows no regressions.
2080f19a8a
frost: fix typos in comments944aeda771
frost: remove potential free on null pointer when using custom error_handler340769d427
frost: remove rho_input parameter from compute_binding_factor()
Remove rho_input as output variable of compute_binding_factor.
Currently, rho_input is not used outside compute_binding_factor, so we avoid
keeping unuseful data on the stack.
Note: the official test vectors of FROST by IETF include tests on rho_input.
Eventually, rho_input will be introduced again.
doc: wrap function names in backticks (``) in frost/README.md80591bb405
doc: remove ";" from lists in frost/README.md95a0fe3ec7
ci: run functional tests on frost module
Two test runs are performed:
1. Build with coverage enabled and no -Werror; run tests; generate summary of
code coverage
2. Build with coverage disabled and using -Werror; run tests
Enabling converage translates in compiling additional code; the different
build configurations aim at checking that code changes do not introduce
regressions.
In order to save time on dependency installation the tests are performed
sequentially in a single job.
9e77eafa45
ci: we have a frost example, let's build it96ccaa13e3
build: added _PKG_VERSION_FROST_BUILD. Now this release is 0.1.0-frost-1
This mimics what has been done in itcoin-core at
https://github.com/bancaditalia/itcoin-core/commit/a6d27e63c8ed22694df293163e51a8e3e8748a13
ca2d49086b
Update secp256k1 from bitcoin v23 to v24
Update official secp256k1 library taking bitcoin changes (from v23 to v24) and accordingly update the frost module integration. Pull request #3 introduced this merge commit.
1c6750fdf4
ci: rename the functional-tests.yml workflow
The previous name was a leftover from a previous version. Now a single workflow
performs both:
- tests with -Werror and no coverage
- tests with coverage and no -Werror
As of current secp version, enabling coverage spits out some warnings, and
prevents us to use -Werror everywhere.
c80109b1b8
doc: add badge with the status of the last CI run on frost branch1eeda9e6d6
ci: run Frost tests and example under Valgrind
This CI workflow builds the minimum code necessary to run the Frost test suite
and the Frost example, and runs them under Valgrind, exiting if it detects any
problems.
The example is run first because it takes way less time.
f312afe033
Merge v0.2.0 in FROST
Closes #19
da0b187889
Merge v0.3.0 in FROST
Closes #20
b701c4abaf
ci: add github workflow to also build with CMake
In v0.3.0, secp256k1 also added support for building via CMake. Let's add a CI
workflow to exercise it.
Co-authored-by: Antonio Muci <antonio.muci@bancaditalia.it>
f25094b4e2
ci: ensure that the version numbers contained in configure.ac and CMakeLists.txt are consistent to each other62315f2812
Merge v0.3.1 in FROST
Closes #21
e65d8d90e9
Merge commit '4258c54f4ebfc09390168e8a43306c46b315134b' in FROST
Closes #23
Closes #18
a22b83ab7a
frost: add error checking to secp256k1_fe_set_b32() in deserialize_frost_signature()a39bd42c54
Workflow verify-version-consistency was the last one written, and already used
checkout@v4.
Let's align all the remaining workflows to use the most recent action version.
No functional changes.
872a25c492
ci: update base image "fedora:38" -> "fedora:39"838792f9bd
ci: fix language "consistent to each other" -> "consistent with each other"3e1f881fed
ci: update the runner images: ubuntu 22.04 -> 24.04
This should be a very low risk change, since the only CI job that directly uses
the base image is .github/workflows/verify-version-consistency.yml, which only
depends on bash.
All the other workflows run in containers and should be unaffected; we will
update the base image in the next commit.
Installed software on the two platforms:
- https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2204-Readme.md
- https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md
087c469959
ci: update base image "fedora:39" -> "fedora:41"cb2ac2f77c
build: add back configure.ac change that was left out when integrating v0.3.0
v0.3.0 slightly modified the way modules are enabled in `configure.ac`.
We integrated v0.3.0 into frost on 2023-11-21, with b701c4abaf0e, but we forgot
to make our `FROST_SPECIFIC` code in `configure.ac` conformant to the new
convention.
We do it now.
This is not a breaking change: both old and new version should still be correct.
7e62a4b3a4
frost: use secp256k1_scalar_one when multiplying for a constant
inspired by:
- 654246c63585 refactor: take use of `secp256k1_scalar_{zero,one}` constants
- a1bd4971d6c6 refactor: take use of `secp256k1_scalar_{zero,one}` constants (part 2)
621d266afc
frost: in secp256k1_frost_keygen_dkg_finalize() use secp256k1_scalar_one instead of allocating on the stack
This gets rid of the local variable scalar_unit that was used only for that
purpose.
inspired by:
- 654246c63585 refactor: take use of `secp256k1_scalar_{zero,one}` constants
- a1bd4971d6c6 refactor: take use of `secp256k1_scalar_{zero,one}` constants (part 2)
5221767b64
frost: in compute_group_commitment() use secp256k1_scalar_one instead of allocating on the stack
This gets rid of the local variable scalar_unit that was used only for that
purpose.
inspired by:
- 654246c63585 refactor: take use of `secp256k1_scalar_{zero,one}` constants
- a1bd4971d6c6 refactor: take use of `secp256k1_scalar_{zero,one}` constants (part 2)
c7bf698b6d
frost: use secp256k1_scalar_clear() in secp256k1_frost_keygen_dkg_begin()
Before returning, secp256k1_frost_keygen_dkg_begin() clears private data in
order to reduce the risk of leaks.
This PR replaces secp256k1_scalar_set_int() with secp256k1_scalar_clear(). The
effect is almost identical, but we use a centralized function, with a clear
intent, and no additional free parameters.
Note for validating the change: the current implementation is in
src/scalar_low_impl.h and is the following:
SECP256K1_INLINE static void secp256k1_scalar_clear(secp256k1_scalar *r) { *r = 0; }
In that same file, immediately below, there is the implementation of
secp256k1_scalar_set_int():
SECP256K1_INLINE static void secp256k1_scalar_set_int(secp256k1_scalar *r, unsigned int v) { *r = v; }
The performance-optimized overloads are in src/scalar_4x64_impl.h and
src/scalar_8x32_impl.h. Their effect is the same, except for operating on 32 or
64 bits chunks.
For an analogous usage of secp256k1_scalar_clear(), see for example
secp256k1_schnorrsig_sign_internal() in src/modules/schnorrsig/main_impl.h.
6407b63aa7
frost: remove redundant secp256k1_gej_mul_scalar() when the first factor is infinity
The opportunity for this change is more evident now, that multiple variables are
multiplied by the "special" value secp256k1_scalar_one. Observing the calls, we
notice that the variables were previously initialized to infinity via a call to
secp256k1_gej_set_infinity().
secp256k1_gej_mul_scalar() handles the special case of infinity by also setting
infinity in the result. This would happen every time, hence we can remove the
calls.
ac12c5b908
coverage: work around two bugs in gcovr
Either gcovr 8.3 or gcc 14.2 cause an, which is also reproducible locally, when
running the job "Functional tests with code coverage, no -Werror" (see later).
This PR is an attempt at mitigating it: we transform the gcovr error in a
warning following an advice by gcovr itself.
Other (and better) strategies, such as adding `-fprofile-update=atomic` as
suggested in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68080#c4 and
documented in https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#index-fprofile-update
did not help solve the problem.
In order to be as strict as possible, we then require that a fixed, hard coded
set of warnings must be generated, because we want to be aware of every possible
variation in the coverage analysis.
In the process, we have to counter-hack gcovr, that diabolically behaves
differently when it detects that it is running in a GitHub worker
(https://github.com/gcovr/gcovr/blob/0a426ca4baae56607f7cff2188569b3dbfc9af13/src/gcovr/logging.py#L79-L83).
The following is the error that gcovr generates unless we use
`--gcov-ignore-parse-errors=suspicious_hits.warn`:
```
[...] a bug in gcov tool, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68080. Use option
--gcov-ignore-parse-errors with a value of suspicious_hits.warn, or
suspicious_hits.warn_once_per_file or change the threshold for the detection
with option --gcov-suspicious-hits-threshold.
(ERROR) Error occurred while reading reports:
Traceback (most recent call last):
File "/usr/lib/python3.13/site-packages/gcovr/__main__.py", line 384, in main
covdata = gcovr_formats.read_reports(options)
File "/usr/lib/python3.13/site-packages/gcovr/formats/__init__.py", line 99, in read_reports
covdata = GcovHandler(options).read_report()
File "/usr/lib/python3.13/site-packages/gcovr/formats/gcov/__init__.py", line 233, in read_report
return read_report(self.options)
File "/usr/lib/python3.13/site-packages/gcovr/formats/gcov/read.py", line 96, in read_report
contexts = pool.wait()
File "/usr/lib/python3.13/site-packages/gcovr/formats/gcov/workers.py", line 181, in wait
raise RuntimeError(
"Worker thread raised exception, workers canceled."
) from None
RuntimeError: Worker thread raised exception, workers canceled.
```
8fb354ed26
ci: build for Windows, and show that Windows builds are currently not supported
This commit adds a `tests-for-windows` workflow that builds a win64 version of
the library with both autotools and CMake, and then attempts to run the frost
example and the functional tests via wine.
In its current state, the builds fail because getrandom() does not exist under
Windows.
The new workflow verifies that the Windows builds are failing, in order to offer
a way of flipping the check when the Windows binaries will be working.
cc4db92479
frost: fix build on Windows. Replace <sys/random.h> with fill_random.h. Use bcrypt when compiling under Windows (MinGW)
Under Windows, there is no getrandom(). We can use BCryptGenRandom() from
bcrypt.
We have to modify the build scripts so that bcrypt is linked in only if Frost is
enabled, and the build targets Windows.
- Automake has no boolean operators, hence we have to use nested ifs.
- For CMake, we use generator expressions.
- the fill_random() function is an excerpt from examples/examples_util.h in the
upstream secp256k1 repository.
5e82fd8aac
frost: show that the frost header fails to be precompiled
This commit introduces a simple script that triggers the current failure to
precompile the frost header, due to a missing `uint32_t` symbol, and introduces
a CI workflow that verifies the failure (in order to fix it afterwards).
The script uses a convoluted syntax (taken from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108732#c2) to trigger the header
precompilation without actually writing anything to disk. The reason is that for
header precompilation gcc 14.2 (2025-04-07), does not support `-o /dev/null`,
because it wants to mmap the output file.
In order to be as strict as possible, we compile in both C and C++, because the
headers for fixed length integers have different names in the two languages.
EVIDENCE OF THE ERROR (C):
```
$ scripts/ensure-frost-header-is-precompilable.sh c
INFO: Tryng to compile <BASE>/include/secp256k1_frost.h with c
In file included from <command-line>:
<BASE>/include/secp256k1_frost.h:19:5: error: unknown type name ‘uint32_t’
19 | uint32_t generator_index;
| ^~~~~~~~
<BASE>/include/secp256k1_frost.h:12:1: note: ‘uint32_t’ is defined in header ‘<stdint.h>’; this is probably fixable by adding ‘#include <stdint.h>’
11 | #include "secp256k1_extrakeys.h"
+++ |+#include <stdint.h>
12 |
```
EVIDENCE OF THE ERROR (C++):
```
$ scripts/ensure-frost-header-is-precompilable.sh c++
INFO: Tryng to compile <BASE>/include/secp256k1_frost.h with c++
In file included from <command-line>:
<BASE>/include/secp256k1_frost.h:19:5: error: ‘uint32_t’ does not name a type
19 | uint32_t generator_index;
| ^~~~~~~~
<BASE>/include/secp256k1_frost.h:12:1: note: ‘uint32_t’ is defined in header ‘<cstdint>’; this is probably fixable by adding ‘#include <cstdint>’
11 | #include "secp256k1_extrakeys.h"
+++ |+#include <cstdint>
12 |
```
5b2ae33158
frost: fix the impossibility of precompiling the frost headere5c57ec06a
frost: typos in the documentation
Fixing some documentation oversights.
No functional changes.
5f3ec64d3f
ci: enable FROST in the official CI pipeline
We enable Frost everywhere the official CI is enabling some optional modules. In
order to do this, we also have to set EXPERIMENTAL to true.
This change gives us the benefit of the extended coverage by the CI pipeline
introduced in 0.4.0 (ARM, s390, Windows, MacOS, MinGW). On the other side, the
duration for a complete CI run will increase significantly.
Closes #35.
5df55ea667
frost: release v0.3.2-frost-2
The version that need to go into itcoin-v25 is v0.3.2-frost-1, and is not based
on the final version of secp256k1 (because bitcoin v25 did so).
This proposed version (v0.3.2-frost-2), instead, incorporates the final
secp256k1 v0.3.2, and includes our recent changes: simplifications in the math
performed in the frost module, multiplatform support and better CI checks.
These changes originated from the upgrading effort to v0.4.0 (#35), that we
decided to apply to 0.3.2 before upgrading the secp256k1 version.
ba29c38de4
Merge secp256k1 v0.4.0 in frost80d70f4142
refactor: Use array initialization for unterminated strings
muxator: grafted from fa67b6752d8b ("refactor: Use array initialization for unterminated strings")
The previous code is correct and harmless to initialize an array with a
non-terminated character sequence using a string literal.
However, it requires exactly specifying the array size, which can be
cumbersome.
Also, GCC-15 may issue the -Wunterminated-string-initialization warning.
[1]
Fix both issues by using array initialization. This refactoring commit
does not change behavior.
[1] Example warning:
src/modules/schnorrsig/main_impl.h:48:46: error: initializer-string for array of 'unsigned char' is too long [-Werror=unterminated-string-initialization]
48 | static const unsigned char bip340_algo[13] = "BIP0340/nonce";
| ^~~~~~~~~~~~~~~
a9ace1a83e
frost: fix compilation of frost module on gcc 15
In order to be a bit more strict, we keep the information about the array size,
i.e:
unsigned char msg[12] = {'H', 'e', 'l', 'l', 'o', ' ', 'W', 'o', 'r', 'l', 'd', '!'};
instead of:
unsigned char msg[] = {'H', 'e', 'l', 'l', 'o', ' ', 'W', 'o', 'r', 'l', 'd', '!'};
0b7a27f4cc
ci: prefix with "frost-" all workflows not coming from upstreamf593d73958
ci: move the frost toolchain to gcc 15.1, Fedora 42
Moreover, before this change tests-for-windows.yml had to dance around a bug in
coreutils 9.5 (the support for cp --update=none-fail is broken there).
Fedora 42 moves to coreutils 9.6 and we can revert back the hack.
4a8b9e64a8
Merge secp256k1 v0.4.1 in frost8cc79e83e1
Update functinoal test workflow to ignore suspicious hits in secp256k13c0817f28a
Merge secp256k1 v0.5.0 in frost4eb0fbefed
Replace signing_commitment_sort with secp256k1_hsort
Remove the sorting function implemented in FROST to reuse the heap
sorting function introduced in secp256k1 v0.5.0. Tests updated
accordingly.
51873fe329
Add secp256k1_context as parameter of secp256k1_frost_sign()fe6fe3ae54
Update valgrind workflow as secp256k1 tests depend on extrakeys44e696ceaa
Merge secp256k1 v0.5.1 in frost55f93dfa99
Update .cirrus.yml to add FROST-specific configuration7cf2b6ab64
Revert commit 44e696c since secp256k1 fixed compilation errors542c5fa803
Fix unsigned char[] initialization in testrand_seed()cf04a27328
Update frost-on-windows workflow to update config parameters
This commit updates the frost-on-windows.yml workflow to replace
`--with-ecmult-window=auto` with `--with-ecmult-window=15` (with 15
the default value) and `--with-ecmult-gen-precision=auto` with
`--with-ecmult-gen-kb=86` (with 86 the default value) to incorporate
secp256k1 v0.5.1 updates.
37ccfabd35
Update ci workflow (arm64-macos-native) to build FROST module6a1bbc2c99
readme: fix badge pointing to functional tests, broken when renaming the workflows
This should have been part of f593d7395815. Caught by @matteonardelli.
bf6b12d5a3
scripts: document the purpose of verify-version-consistency.sh41a57cb9d3
scripts: typos in verify-version-consistency.sh86b9e6a07f
scripts: use BASE_DIR in verify-version-consistency.sh
The commit also sorts variables order.
d5f97aa1a3
scripts: improve comments in verify-version-consistency.sh9914b24fd7
scripts: introduce logging functions in verify-version-consistency.shda8083c026
scripts: in verify-version-consistency.sh, cleanup temporary directory when possible
When we exit on our initiative we can cleanut the temporary cmake directory.
Otherwise, we leave it untouched to allow debugging.
f8bd358a16
scripts: factor out initialize_cmake() in verify-version-consistency.sh68c1d542f6
ci: show that the project descriptions are different between the two build systems
The project descriptions are not exactly the same. However, we can enforce that
both contain a reference to the FROST signature scheme.
libsecp256k1.pc.in:
"Optimized C library for EC operations on curve secp256k1, with support for
FROST signature scheme"
CMakeLists.txt:
"Optimized C library for ECDSA signatures and secret/public key operations
on curve secp256k1, with support for FROST signature scheme"
Currently, this test fails.
fe66ac66ad
ci: fix the missing reference to Frost in the project description in CMakeLists.txt
From now on, we will enforce that the project descriptions both end with the
same reference to Frost.
e6b12bce70
ci: add the possibility of manually running the upstream CI
For our fork, it may be useful to be able to manually run the upstream CI jobs.
8e4d3f0bcf
frost: fix warning issued by clang22
Instructions to replicate the problem locally on Debian 13 trixie (in a
container or via Distrobox):
Optionally: use Distrobox to create an ephemeral debian environment:
```
distrobox create --image debian --name debian
distrobox enter debian
```
prerequisite: install clang-snapshot (22 as of today). Instructions taken from
`linux-debian.Dockerfile`:
```
# Setup GPG keys of LLVM repository
apt update
apt install --no-install-recommends -y wget
wget -qO- https://apt.llvm.org/llvm-snapshot.gpg.key | tee /etc/apt/trusted.gpg.d/apt.llvm.org.asc
# Add repository for this Debian release
. /etc/os-release
echo "deb http://apt.llvm.org/${VERSION_CODENAME} llvm-toolchain-${VERSION_CODENAME} main" >> /etc/apt/sources.list
apt update
# Determine the version number of the LLVM development branch
LLVM_VERSION=$(apt-cache search --names-only '^clang-[0-9]+$' | sort -V | tail -1 | cut -f1 -d" " | cut -f2 -d"-" )
# Install
apt install --no-install-recommends -y "clang-${LLVM_VERSION}"
# Create symlink
ln -s "/usr/bin/clang-${LLVM_VERSION}" /usr/bin/clang-snapshot
```
Configuration of the source tree:
```
export CC=clang-snapshot
./autogen.sh
./configure \
--enable-experimental=yes
--with-test-override-wide-multiply=int64
--with-asm=no
--with-ecmult-window=15
--with-ecmult-gen-kb=86
--enable-module-ecdh=yes
--enable-module-recovery=no
--enable-module-ellswift=yes
--enable-module-extrakeys=yes
--enable-module-schnorrsig=yes
--enable-module-frost=yes
--enable-examples=yes
--enable-ctime-tests=yes
--with-valgrind=yes
```
Trigger the error:
```
make
[...]
In file included from src/secp256k1.c:839:
src/modules/frost/main_impl.h:878:58: warning: variable 'rho_i' may be uninitialized when used here [-Wconditional-uninitialized]
878 | secp256k1_gej_mul_scalar(&partial, &binding_cmt, rho_i);
| ^~~~~
src/modules/frost/main_impl.h:855:32: note: initialize the variable 'rho_i' to silence this warning
855 | secp256k1_scalar *rho_i;
| ^
| = NULL
src/modules/frost/main_impl.h:1308:54: warning: variable 'matching_rho_i' may be uninitialized when used here [-Wconditional-uninitialized]
1308 | secp256k1_gej_mul_scalar(&partial, &binding_cmt, matching_rho_i);
| ^~~~~~~~~~~~~~
src/modules/frost/main_impl.h:1252:37: note: initialize the variable 'matching_rho_i' to silence this warning
1252 | secp256k1_scalar *matching_rho_i;
| ^
| = NULL
2 warnings generated.
[...more errors...]
```
75fabeabcf
muxator closed this
on Sep 11, 2025
muxator deleted the branch
on Sep 11, 2025
real-or-random added the label
invalid
on Sep 12, 2025
This is a metadata mirror of the GitHub repository
bitcoin-core/secp256k1.
This site is not affiliated with GitHub.
Content is generated from a GitHub metadata backup.
generated: 2025-09-16 14:15 UTC
This site is hosted by @0xB10C More mirrored repositories can be found on mirror.b10c.me
