You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CHANGELOG.md
+17-3Lines changed: 17 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,6 +7,21 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
7
7
8
8
## [Unreleased]
9
9
10
+
## [0.3.1] - 2023-04-10
11
+
We strongly recommend updating to 0.3.1 if you use or plan to use Clang >=14 to compile libsecp256k1, e.g., Xcode >=14 on macOS has Clang >=14. When in doubt, check the Clang version using `clang -v`.
12
+
13
+
#### Security
14
+
- Fix "constant-timeness" issue with Clang >=14 that could leave applications using libsecp256k1 vulnerable to a timing side-channel attack. The fix avoids secret-dependent control flow and secret-dependent memory accesses in conditional moves of memory objects when libsecp256k1 is compiled with Clang >=14.
15
+
16
+
#### Added
17
+
- Added tests against [Project Wycheproof's](https://github.com/google/wycheproof/) set of ECDSA test vectors (Bitcoin "low-S" variant), a fixed set of test cases designed to trigger various edge cases.
18
+
19
+
#### Changed
20
+
- Increased minimum required CMake version to 3.13. CMake builds remain experimental.
21
+
22
+
#### ABI Compatibility
23
+
The ABI is compatible with version 0.3.0.
24
+
10
25
## [0.3.0] - 2023-03-08
11
26
12
27
#### Added
@@ -25,7 +40,6 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
25
40
- Removed the configuration header `src/libsecp256k1-config.h`. We recommend passing flags to `./configure` or `cmake` to set configuration options (see `./configure --help` or `cmake -LH`). If you cannot or do not want to use one of the supported build systems, pass configuration flags such as `-DSECP256K1_ENABLE_MODULE_SCHNORRSIG` manually to the compiler (see the file `configure.ac` for supported flags).
26
41
27
42
#### ABI Compatibility
28
-
29
43
Due to changes in the API regarding `secp256k1_context_static` described above, the ABI is *not* compatible with previous versions.
30
44
31
45
## [0.2.0] - 2022-12-12
@@ -45,7 +59,6 @@ Due to changes in the API regarding `secp256k1_context_static` described above,
45
59
- Module `schnorrsig`: renamed `secp256k1_schnorrsig_sign` to `secp256k1_schnorrsig_sign32`.
46
60
47
61
#### ABI Compatibility
48
-
49
62
Since this is the first release, we do not compare application binary interfaces.
50
63
However, there are earlier unreleased versions of libsecp256k1 that are *not* ABI compatible with this version.
51
64
@@ -55,7 +68,8 @@ This version was in fact never released.
55
68
The number was given by the build system since the introduction of autotools in Jan 2014 (ea0fe5a5bf0c04f9cc955b2966b614f5f378c6f6).
56
69
Therefore, this version number does not uniquely identify a set of source files.
3. Open a PR to the master branch with a commit (using message `"release cleanup: bump version after $MAJOR.$MINOR.$PATCH"`, for example) that sets `_PKG_VERSION_IS_RELEASE` to `false` and `_PKG_VERSION_PATCH` to `$PATCH + 1` and increases `_LIB_VERSION_REVISION`. If other maintainers are not present to approve the PR, it can be merged without ACKs.
27
+
3. Open a PR to the master branch with a commit (using message `"release cleanup: bump version after $MAJOR.$MINOR.$PATCH"`, for example) that
28
+
* sets `_PKG_VERSION_IS_RELEASE` to `false` and increments `_PKG_VERSION_PATCH` and `_LIB_VERSION_REVISION` in `configure.ac`, and
29
+
* increments the `$PATCH` component of `project(libsecp256k1 VERSION ...)` and `${PROJECT_NAME}_LIB_VERSION_REVISION` in `CMakeLists.txt`.
30
+
31
+
If other maintainers are not present to approve the PR, it can be merged without ACKs.
27
32
4. Create a new GitHub release with a link to the corresponding entry in [CHANGELOG.md](../CHANGELOG.md).
28
33
29
34
## Maintenance release
@@ -38,7 +43,9 @@ Note that bugfixes only need to be backported to releases for which no compatibl
38
43
2. Open a pull request to the `$MAJOR.$MINOR` branch that
39
44
* includes the bugfixes,
40
45
* finalizes the release notes,
41
-
* bumps `_PKG_VERSION_PATCH` and `_LIB_VERSION_REVISION` in `configure.ac` (with commit message `"release: update PKG_ and LIB_VERSION for $MAJOR.$MINOR.$PATCH"`, for example).
46
+
* increments `_PKG_VERSION_PATCH` and `_LIB_VERSION_REVISION` in `configure.ac`
47
+
and the `$PATCH` component of `project(libsecp256k1 VERSION ...)` and `${PROJECT_NAME}_LIB_VERSION_REVISION` in `CMakeLists.txt`
48
+
(with commit message `"release: bump versions for $MAJOR.$MINOR.$PATCH"`, for example).
42
49
3. After the PRs are merged, update the release branch and tag the commit:
0 commit comments