akovalenko/lnd.xprv
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

docs+build: explain how to verify docker images

Browse Source
This commit is contained in:
Oliver Gugger 2021-01-13 14:58:50 +01:00
parent 97a141e7af
commit 356fdb82f8
No known key found for this signature in database
GPG Key ID: 8E4256593F177720
3 changed files with 64 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

36
.github/workflows/release.yaml vendored
View File

@ -70,42 +70,32 @@ jobs:
```
curl https://keybase.io/bitconner/pgp_keys.asc | gpg --import
curl https://keybase.io/roasbeef/pgp_keys.asc | gpg --import
```
Once you have the required PGP keys, you can verify the release (assuming `manifest-${{ env.RELEASE_VERSION }}.txt` and `manifest-${{ env.RELEASE_VERSION }}.txt.sig` are in the current directory) with:
Once you have the required PGP keys, you can verify the release (assuming `manifest-roasbeef-${{ env.RELEASE_VERSION }}.txt.asc` is in the current directory) with:
```
gpg --verify manifest-${{ env.RELEASE_VERSION }}.txt.sig
gpg --verify manifest-roasbeef-${{ env.RELEASE_VERSION }}.txt.asc
```
You should see the following if the verification was successful:
```
gpg: assuming signed data in 'manifest-${{ env.RELEASE_VERSION }}.txt'
gpg: Signature made Thu Oct 1 16:38:32 2020 PDT
gpg: using RSA key 9C8D61868A7C492003B2744EE7D737B67FA592C7
gpg: Good signature from "Conner Fromknecht <conner@lightning.engineering>" [ultimate]
```
That will verify the signature of the manifest file, which ensures integrity and authenticity of the archive you've downloaded locally containing the binaries. Next, depending on your operating system, you should then re-compute the `sha256` hash of the archive with `shasum -a 256 <filename>`, compare it with the corresponding one in the manifest file, and ensure they match *exactly*.
For this release roasbeef's signature is the secondary signature which can be verified with the following command:
```
gpg --verify roasbeef-manifest-${{ env.RELEASE_VERSION }}.txt.sig manifest-${{ env.RELEASE_VERSION }}.txt
gpg: Signature made Wed Sep 30 17:35:20 2020 PDT
gpg: using RSA key 4AB7F8DA6FAEBB3B70B1F903BC13F65E2DC84465
gpg: Good signature from "Olaoluwa Osuntokun <laolu32@gmail.com>" [ultimate]
```
That will verify the signature of the manifest file, which ensures integrity and authenticity of the archive you've downloaded locally containing the binaries. Next, depending on your operating system, you should then re-compute the `sha256` hash of the archive with `shasum -a 256 <filename>`, compare it with the corresponding one in the manifest file, and ensure they match *exactly*.
## Verifying the Release Timestamp
From this new version onwards, in addition time-stamping the _git tag_ with [OpenTimeStamps](https://opentimestamps.org/), we'll also now timestamp the manifest file along with its signature. Two new files are now included along with the rest of our release artifacts: ` manifest-${{ env.RELEASE_VERSION }}.txt.sig.ots` and `manifest-${{ env.RELEASE_VERSION }}.txt.ots`.
From this new version onwards, in addition time-stamping the _git tag_ with [OpenTimeStamps](https://opentimestamps.org/), we'll also now timestamp the manifest file along with its signature. Two new files are now included along with the rest of our release artifacts: ` manifest-roasbeef-${{ env.RELEASE_VERSION }}.txt.asc.ots`.
Assuming you have the opentimestamps client installed locally, the timestamps can be verified with the following commands:
```
ots verify manifest-${{ env.RELEASE_VERSION }}.txt.ots
ots verify manifest-${{ env.RELEASE_VERSION }}.txt.sig.ots -f roasbeef-manifest-${{ env.RELEASE_VERSION }}.txt.sig
ots verify manifest-roasbeef-${{ env.RELEASE_VERSION }}.txt.asc.ots -f manifest-roasbeef-${{ env.RELEASE_VERSION }}.txt.asc
```
Alternatively, [the open timestamps website](https://opentimestamps.org/) can be used to verify timestamps if one doesn't have a `bitcoind` instance accessible locally.
@ -129,6 +119,18 @@ jobs:
gpg: Good signature from "Olaoluwa Osuntokun <laolu32@gmail.com>" [ultimate]
```
## Verifying the Docker Images
To verify the `lnd` and `lncli` binaries inside the docker images against the signed, reproducible release binaries, there is a verification script in the image that can be called (before starting the container for example):
```shell
$ docker pull lightninglabs/lnd:${{ env.RELEASE_VERSION }}
$ docker run --rm --entrypoint="" lightninglabs/lnd:${{ env.RELEASE_VERSION }} /verify-install.sh
$ OK=$?
$ if [ "$OK" -ne "0" ]; then echo "Verification failed!"; exit 1; done
$ docker run lightninglabs/lnd [command-line options]
```
# Building the Contained Release
Users are able to rebuild the target release themselves without having to fetch any of the dependencies. In order to do so, assuming

32
docs/DOCKER.md
View File

@ -21,7 +21,7 @@ spins up a `btcd` backend alongside `lnd`. Check out the documentation at
[docker/README.md](../docker/README.md) to learn more about how to use that
setup to create a small local Lightning Network.
## Production
## Production (manual build)
To use Docker in a production environment, you can run `lnd` by creating a
Docker container, adding the appropriate command-line options as parameters.
@ -37,10 +37,36 @@ It is recommended that you checkout the latest released tag.
You can continue by creating and running the container:
```
$ docker run lnd [command-line options]
$ docker run myrepository/lnd [command-line options]
```
Note: there currently are no automated docker image builds available.
## Production (official images)
Starting with `lnd v0.12.0-beta`, there are official, automatically built docker
images of `lnd` available in the
[`lightninglabs/lnd` repository on Docker Hub](https://hub.docker.com/r/lightninglabs/lnd).
You can just pull those images by specifying a release tag:
```shell
$ docker pull lightninglabs/lnd:v0.12.0-beta
$ docker run lightninglabs/lnd [command-line options]
```
### Verifying docker images
To verify the `lnd` and `lncli` binaries inside the docker images against the
signed, [reproducible release binaries](release.md), there is a verification
script in the image that can be called (before starting the container for
example):
```shell
$ docker pull lightninglabs/lnd:v0.12.0-beta
$ docker run --rm --entrypoint="" lightninglabs/lnd:v0.12.0-beta /verify-install.sh
$ OK=$?
$ if [ "$OK" -ne "0" ]; then echo "Verification failed!"; exit 1; done
$ docker run lightninglabs/lnd [command-line options]
```
## Volumes

16
docs/release.md
View File

@ -85,3 +85,19 @@ and `go` (matching the same version used in the release):
release script and recompute the `SHA256` hash of the release binaries (lnd
and lncli) with `shasum -a 256 <filename>`. These should match __exactly__
as the ones noted above.
## Verifying docker images
To verify the `lnd` and `lncli` binaries inside the
[official provided docker images](https://hub.docker.com/r/lightninglabs/lnd)
against the signed, reproducible release binaries, there is a verification
script in the image that can be called (before starting the container for
example):
```shell
$ docker pull lightninglabs/lnd:v0.12.0-beta
$ docker run --rm --entrypoint="" lightninglabs/lnd:v0.12.0-beta /verify-install.sh
$ OK=$?
$ if [ "$OK" -ne "0" ]; then echo "Verification failed!"; exit 1; done
$ docker run lightninglabs/lnd [command-line options]
```