Merge remote-tracking branch 'upstream/master'

.gitignore

@@ -93,3 +93,7 @@ release/
 SHA256SUMS-*
 doc/.doc_version
 autogenerate-examples-status.log
+
+# Ignore nix outputs
+result
+result-[0-9]*

.version

@@ -0,0 +1 @@
+24.08.1

Makefile

@@ -726,7 +726,7 @@ clean: obsclean
 
 PYLNS=client proto testing
 # See doc/contribute-to-core-lightning/contributor-workflow.md
-update-py-versions: update-pyln-versions update-clnrest-version update-wss-proxy-version update-poetry-lock
+update-versions: update-pyln-versions update-clnrest-version update-wss-proxy-version update-poetry-lock update-dot-version
 
 update-pyln-versions: $(PYLNS:%=update-pyln-version-%)
 
@@ -754,6 +754,10 @@ update-reckless-version:
 	@if [ -z "$(NEW_VERSION)" ]; then echo "Set NEW_VERSION!" >&2; exit 1; fi
 	@sed -i "s/__VERSION__ = '\([.-z]*\)'/__VERSION__ = '$(NEW_VERSION)'/" tools/reckless
 
+update-dot-version:
+	@if [ -z "$(NEW_VERSION)" ]; then echo "Set NEW_VERSION!" >&2; exit 1; fi
+	echo $(NEW_VERSION) > .version
+
 update-mocks: $(ALL_TEST_PROGRAMS:%=update-mocks/%.c)
 
 $(ALL_TEST_PROGRAMS:%=update-mocks/%.c): $(ALL_GEN_HEADERS) $(EXTERNAL_LIBS) libccan.a ccan/ccan/cdump/tools/cdump-enumstr config.vars

README.md

@@ -40,7 +40,7 @@ Pruning (`prune=n` option in `groestlcoin.conf`) is partially supported, see [he
 
 ### Installation
 
-There are 4 supported installation options:
+There are 3 supported installation options:
 
  - Installation of a pre-compiled binary from the [release page][releases] on GitHub.
  - Using one of the [provided docker images][dockerhub] on the Docker Hub.

doc/contribute-to-core-lightning/release-checklist.md

@@ -15,16 +15,16 @@ Here's a checklist for the release process.
 2. Look through outstanding issues, to identify any problems that might be necessary to fixup before the release. Good candidates are reports of the project not building on different architectures or crashes.
 3. Identify a good lead for each outstanding issue, and ask them about a fix timeline.
 4. Create a milestone for the _next_ release on Github, and go though open issues and PRs and mark accordingly.
-5. Ask (via email) the most significant contributor who has not already named a release to name the release (use  
+5. Ask (via email) the most significant contributor who has not already named a release to name the release (use
    `devtools/credit --verbose v<PREVIOUS-VERSION>` to find this contributor). CC previous namers and team.
 
 ## Preparing for -rc1
 
 1. Check that `CHANGELOG.md` is well formatted, ordered in areas, covers all signficant changes, and sub-ordered approximately by user impact & coolness.
-2. Use `devtools/changelog.py` to collect the changelog entries from pull request commit messages and merge them into the manually maintained `CHANGELOG.md`.  This does API queries to GitHub, which are severely  
+2. Use `devtools/changelog.py` to collect the changelog entries from pull request commit messages and merge them into the manually maintained `CHANGELOG.md`.  This does API queries to GitHub, which are severely
    ratelimited unless you use an API token: set the `GH_TOKEN` environment variable to a Personal Access Token from <https://github.com/settings/tokens>
 3. Create a new CHANGELOG.md heading to `v<VERSION>rc1`, and create a link at the bottom. Note that you should exactly copy the date and name format from a previous release, as the `build-release.sh` script relies on this.
-4. Update the contrib/pyln package versions: `make update-py-versions NEW_VERSION=<VERSION>`
+4. Update the package versions: `make update-versions NEW_VERSION=<VERSION>`
 5. Create a PR with the above.
 
 ## Releasing -rc1
@@ -47,7 +47,7 @@ Here's a checklist for the release process.
 ## Releasing -rc2, ..., -rcN
 
 1. Update CHANGELOG.md by changing rc(N-1) to rcN. Update the changelog list with information from newly merged PRs also.
-2. Update the contrib/pyln package versions: `make update-py-versions NEW_VERSION=<VERSION>`
+2. Update the package versions: `make update-versions NEW_VERSION=<VERSION>`
 3. Add a PR with the rcN.
 4. Tag it `git pull && git tag -s v<VERSION>rcN && git push --tags`
 5. Draft a new `v<VERSION>rcN` pre-release on Github, upload reproducible builds, SHA256SUMS and SHA256SUMS.asc.
@@ -71,9 +71,9 @@ Here's a checklist for the release process.
    - Build reproducible Ubuntu-v18.04, Ubuntu-v20.04, Ubuntu-v22.04 images. Follow [link](https://docs.corelightning.org/docs/repro#building-using-the-builder-image) for manually Building Ubuntu Images.
    - Build Docker images for amd64 and arm64v8. Follow [link](https://docs.corelightning.org/docs/docker-images) for more details on Docker publishing.
    - Create and sign checksums. Follow [link](https://docs.corelightning.org/docs/repro#co-signing-the-release-manifest) for manually signing the release.
-6. The tarballs may be owned by root, so revert ownership if necessary:  
+6. The tarballs may be owned by root, so revert ownership if necessary:
    `sudo chown ${USER}:${USER} *${VERSION}*`
-7. Upload the resulting files to github and save as a draft.  
+7. Upload the resulting files to github and save as a draft.
    (<https://github.com/ElementsProject/lightning/releases/>)
 8. Send `SHA256SUMS` & `SHA256SUMS.asc` files to the rest of the team to check and sign the release.
 9. Team members can verify the release with the help of `build-release.sh`:

doc/developers-guide/app-development/grpc.md

@@ -25,7 +25,7 @@ The plugin only runs when `lightningd` is configured with the option `--grpc-por
 - `server.pem` and `server-key.pem`: this is the identity (certificate and private key) used by the plugin to authenticate itself. It is signed by the CA, and the client will verify its identity.
 - `client.pem` and `client-key.pem`: this is an example identity that can be used by a client to connect to the plugin, and issue requests. It is also signed by the CA.
 
-These files are generated with sane defaults, however you can generate custom certificates should you require some changes (see [below](doc:app-development#generating-custom-certificates) for details).
+These files are generated with sane defaults, however you can generate custom certificates should you require some changes (see [below](doc:grpc#generating-custom-certificates) for details).
 
 The client needs a valid mTLS identity in order to connect to the plugin, so copy over the `ca.pem`, `client.pem` and `client-key.pem` files from the node to your project directory.
 
@@ -107,7 +107,7 @@ used as `--grpc-port` option when we started our node.
 
 In this example, we first load the client identity as well as the CA certificate so we can verify the server's identity against it. We then create a `creds` instance using those details. Next we open a secure channel, i.e., a channel over TLS with verification of identities.
 
-Notice that we override the expected SSL name with `cln`. This is required because the plugin does not know the domain under which it will be reachable, and will therefore use `cln` as a standin. See [custom certificate generation](doc:app-development#generating-custom-certificates) for how this could be changed.
+Notice that we override the expected SSL name with `cln`. This is required because the plugin does not know the domain under which it will be reachable, and will therefore use `cln` as a standin. See [custom certificate generation](doc:grpc#generating-custom-certificates) for how this could be changed.
 
 We then use the channel to instantiate the `NodeStub` representing the service and its methods, so we can finally call the `Getinfo` method with default arguments.
 
@@ -140,4 +140,56 @@ openssl x509 -req -CA ca.pem -CAkey ca-key.pem \
 
 
 
-This will finally create the `server.pem` file, signed by the CA, allowing you to access the node through its real domain name. You can now move `server.pem` and `server-key.pem` into the lightning directory, and they should be picked up during the start.
+This will finally create the `server.pem` file, signed by the CA, allowing you to access the node through its real domain name. You can now move `server.pem` and `server-key.pem` into the lightning directory (ex. `<lightning-dir>/bitcoin` for `mainnet`), and they should be picked up during the start.
+
+#### Generating custom certificates using SANs (Subject Alternative Names)
+
+To add additional domain names to the custom certificate, you can use a variation of the above commands. This is helpful, for example, if you are exposing the API over Tor, or experiencing errors due to client SSL verification asking for verification via a `SAN` instead of `CN`.
+
+```shell
+openssl genrsa -out server-key.pem 2048
+```
+
+
+
+As above, generate a new server key.
+
+Then, create an openssl CSR configuration file name `cln-csr.conf` that looks something like the following:
+
+```
+[req]
+default_bits       = 2048
+distinguished_name = req_distinguished_name
+req_extensions     = req_ext
+
+[req_distinguished_name]
+CN = "cln rest server"
+
+[req_ext]
+subjectAltName = @alt_names
+
+[alt_names]
+IP.1  = 127.0.0.1
+DNS.1 = localhost
+DNS.2 = cln
+DNS.3 = <put your custom DNS name here and add more if desired>
+```
+
+
+Consult the `openssl` [documentation ](https://docs.openssl.org/master/man1/openssl-req/#configuration-file-format) for your version for additional customization.
+
+```shell
+openssl req -new -key server-key.pem -out server.csr -config cln-csr.conf
+```
+
+
+
+This example configuration suggests the generated default for _Common Name_, but can be changed when prompted.
+
+```shell
+openssl x509 -req -CA ca.pem -CAkey ca-key.pem -in server.csr -out server.pem -days 365 -CAcreateserial -extensions req_ext -extfile cln-csr.conf
+```
+
+
+
+As above, generate the new server certificate, but this time with the `SAN` configuration. Copy `server.pem` and `server-key.pem` into the certificates location (ex. `<lightning-dir>/bitcoin` for `mainnet`) and restart the service to take effect.

doc/developers-guide/developers-guide.md

@@ -46,8 +46,24 @@ Clean up the lightning directories:
  destroy_ln
 ```
 
-
-
 ## Using Polar
 
 [Polar](https://lightningpolar.com/) offers a one-click setup of Lightning Network for local app development & testing.
+
+## Using Nix
+
+Install [Nix](https://nixos.org/download/)
+
+Update git submodules `git submodule update --init --recursive`.
+
+The entry point is `flake.nix` in the root of the project, where the inputs and outputs are defined.
+
+`nix develop` will create the default shell env with the build and runtime dependencies of the cln package. Then you can call `make` manually and the project will compile as usual.
+
+`nix develop .#rust` will create a shell env for developing rust.
+
+`nix build .?submodules=1` will build the default package (cln).
+
+`nix flake check .?submodules=1` will build the cln and rust packages. Rust tests are run during the build. There are also checks to run cargo audit and nixfmt.
+
+If you have nix installed you can use `nix run "git+https://github.com/hashrelay/lightning?ref=flake&submodules=1#lightningd"` to run lightningd without having to manually clone the repo. This make use of the flake output apps.

flake.nix

@@ -0,0 +1,64 @@
+{
+  description = "Core Lightning (CLN): A specification compliant Lightning Network implementation in C";
+
+  inputs = {
+    nixpkgs.url = "github:NixOS/nixpkgs/nixos-24.05";
+
+    flake-parts.url = "github:hercules-ci/flake-parts";
+
+    crane.url = "github:ipetkov/crane";
+
+    treefmt-nix.url = "github:numtide/treefmt-nix";
+
+    advisory-db = {
+      url = "github:rustsec/advisory-db";
+      flake = false;
+    };
+  };
+
+  outputs =
+    inputs@{
+      self,
+      nixpkgs,
+      flake-parts,
+      ...
+    }:
+    flake-parts.lib.mkFlake { inherit inputs; } {
+      systems = nixpkgs.lib.systems.flakeExposed;
+      imports = [
+        inputs.treefmt-nix.flakeModule
+        ./nix/pkgs/flake-module.nix
+        ./nix/checks/flake-module.nix
+        ./nix/shells.nix
+        ./nix/treefmt.nix
+      ];
+      perSystem =
+        {
+          config,
+          pkgs,
+          self',
+          system,
+          ...
+        }:
+        {
+          _module.args.pkgs = import inputs.nixpkgs {
+            inherit system;
+            overlays = [ (final: prev: { craneLib = (inputs.crane.mkLib pkgs); }) ];
+          };
+          apps = {
+            lightningd = {
+              program = "${self'.packages.cln}/bin/lightningd";
+            };
+            lightning-cli = {
+              program = "${self'.packages.cln}/bin/lightning-cli";
+            };
+            lightning-hsmtool = {
+              program = "${self'.packages.cln}/bin/lightning-hsmtool";
+            };
+            reckless = {
+              program = "${self'.packages.cln}/bin/reckless";
+            };
+          };
+        };
+    };
+}

nix/checks/flake-module.nix

@@ -0,0 +1,20 @@
+{ inputs, self, ... }:
+{
+  perSystem =
+    { pkgs, config, ... }:
+    let
+      advisory-db = inputs.advisory-db;
+    in
+    {
+      checks = {
+        cln = config.packages.cln;
+        cln-postgres = config.packages.cln-postgres;
+        rust = config.packages.rust;
+        cargo-audit = pkgs.craneLib.cargoAudit {
+          src = ../../.;
+          inherit advisory-db;
+        };
+        formatting = config.treefmt.build.check self;
+      };
+    };
+}