Merge branch 'main' into develop

Dockerfile

@@ -215,7 +215,7 @@ RUN apt-get update -y \
     # Fixes CVE-2023-4911 can be removed when we update the base OS image to include this fix
     # docker run -it debian:12.1-slim ldd --version
     # This fix can be removed as long as the version printed in the above command is 2.36-9+deb12u3 or above
-    libc6=2.36-9+deb12u3 \ 
+    libc6=2.36-9+deb12u4 \
   && apt-get clean \
   && rm -rf /var/lib/apt/lists/*
 

README.md

@@ -32,17 +32,8 @@ some of our tests.
 
 ## Contribute
 
-To contribute, you'll need to [setup development environment](docs/development/README.md).
-
-[Contributions](CONTRIBUTING.md) are welcome, we simply ask to:
-
-* Fork the codebase
-* Make changes
-* Submit a pull request for review
-
-When contributing to this repository, we recommend discussing with the development team the change you wish to make using a [GitHub issue](https://github.com/radixdlt/radixdlt/issues) before making changes.
-
 Please follow our [Code of Conduct](CODE_OF_CONDUCT.md) in all your interactions with the project.
+See the [Contributing Guide](CONTRIBUTING.md) for more details on how to get involved.
 
 ## Links
 
@@ -55,9 +46,9 @@ Please follow our [Code of Conduct](CODE_OF_CONDUCT.md) in all your interactions
 
 ## License
 
-The executable components of the Babylon Node Code are licensed under the [Radix Node EULA](http://www.radixdlt.com/terms/nodeEULA).
+The executable components of the Babylon Node code are licensed under the [Radix Node EULA](http://www.radixdlt.com/terms/nodeEULA).
 
-The Babylon Node Code is released under the [Radix License 1.0 (modified Apache 2.0)](LICENSE):
+The Babylon Node code is released under the [Radix License 1.0 (modified Apache 2.0)](LICENSE):
 
 ```
 Copyright 2023 Radix Publishing Ltd incorporated in Jersey, Channel Islands.
@@ -130,4 +121,4 @@ operation logic, functionality, security and appropriateness of using the Work
 for any commercial or non-commercial purpose and for any reproduction or
 redistribution by You of the Work. You assume all risks associated with Your use
 of the Work and the exercise of permissions under this Licence.
-```
+```

common/src/main/java/com/radixdlt/crypto/RadixKeyStore.java

@@ -110,11 +110,9 @@
  * store,
  *
  * <p><b>Implementation note:</b><br>
- * This store uses a PKCS#12 representation for the underlying storage, and the store requires a
- * non-empty password to protect it. In order to ease unattended use, note that where a password is
- * required, a {@code null}, or zero length password may be provided, in which case the default 5
- * character password, "radix" is used. Clearly this is insecure, and clients should make an effort
- * to specify passwords in a secure way.
+ * This store uses a PKCS#12 representation for the underlying storage. It's required to supply a
+ * non-null password for the keystore, but it can be empty. An empty password will be used as-is,
+ * without any replacement default.
  */
 @SecurityCritical(SecurityKind.KEY_STORE)
 public final class RadixKeyStore implements Closeable {

core/build.gradle

@@ -210,6 +210,7 @@ dependencies {
     implementation project(':olympia-engine')
     implementation project(':common')
     implementation project(':core-rust-bridge')
+    implementation project(':keygen')
     implementation 'com.fasterxml.jackson.core:jackson-databind'
 
     implementation 'io.swagger:swagger-annotations:1.5.0'
@@ -377,3 +378,7 @@ task deb4docker(dependsOn: buildDeb) {
         println "SUCCESS: deb package copied for the docker build to: $destinationLocation"
     }
 }
+
+applicationDistribution.from(new File(project(':keygen').buildDir, "scripts")) {
+    into "bin"
+}

docs/branching-strategy.md

@@ -4,13 +4,13 @@ Once you have read the [contributing guide](../CONTRIBUTING.md), if you want to
 
 > [!NOTE]
 >
-> As of 2024-02-12, the strictly ordered list of supported base branches, starting from furthest upstream, is:
+> As of 2024-02-12, the strictly ordered list of supported base branches, starting from earliest/furthest upstream, is:
 > 
 > * `release/anemone` - This is currently running on mainnet.
 > * `main`
 > * `develop`
 > 
-> When clicking merge on a PR to one of these branches, it is your duty to ensure that PRs are raised to merge that branch into all downstream supported base branches.
+> When clicking merge on a PR to one of these branches, it is your duty to ensure that PRs are raised to merge that branch into all later/downstream supported base branches.
 
 ## Summary of approach
 
@@ -22,7 +22,7 @@ We use a variant of `git-flow`, where there are three types of base branches: th
 * The `develop` branch is the primary integration branch, for work targeting the next protocol version.
 * The `release/*` branches are for all named protocol versions (i.e. each 1.X in the naming scheme. Typically patch releases should re-use same branch). A subset of release branches are **currently supported** - typically these are those currently on a live environment, or under development.
 
-At any given time, there is a strict ordering on the supported base branches, where the process aims to guarantee all work on previous branches is in the downstream branches. This order (from most upstream to most downstream) is as follows:
+At any given time, there is a strict ordering on the supported base branches, where the process aims to guarantee all work on previous branches is in the later/downstream branches. This order (from earliest/most upstream to latest/most downstream) is as follows:
 
 * Released `release/*` branches still compatibile with a mainnet network
 * `main`
@@ -58,13 +58,13 @@ Public facing docs change unrelated to another ticket should use a base branch o
 
 ### Workflow / CI changes
 
-Workflow changes should branch from the _most downstream_ (earliest) supported branch. Typically this is a `release/*` branch.
+Workflow changes should branch from the _most upstream_ (earliest) supported branch. Typically this is a `release/*` branch.
 
-Once the post-merge process is followed, this change will find itself on all downstream base branches too.
+Once the post-merge process is followed, this change will find itself on all later/downstream base branches too.
 
 This ensures that these changes are on all supported branches, so builds can be built on `develop` or on all supported branches.
 
-## Merge or Rebase?
+## Merge or Rebase/Cherry-pick?
 
 This strategy relies on the fact that we always merge.