updated release document
- removed duplicate content - clarified what is signed and since which release - updated verification sample output (also in wiki) using the output of https://github.com/PrivateBin/docker-nginx-fpm-alpine/actions/runs/7228527399/job/19698112056#step:7:156 - Corrected release process - we trigger the release on the push of the tag, not a branch (fixed point in time instead of a moving target)
This commit is contained in:
El RIDO
parent
43d162f452
commit
255fd4b12b
|
|
@ -1,11 +1,10 @@
|
|||
# Release
|
||||
|
||||
## Properties
|
||||
## Overview of Supply-Chain Security
|
||||
|
||||
### Supply-chain security
|
||||
As of the PrivateBin 1.0 release we [cryptographically sign](https://git-scm.com/book/uz/v2/Git-Tools-Signing-Your-Work) our git commits and tags, so that you can verify we actually developed the software. Later, we also [started signing the release archives on GitHub](https://github.com/PrivateBin/PrivateBin/issues/219) and retroactively signed all releases from 1.0 forward.
|
||||
|
||||
Since [v1.6.2](https://github.com/PrivateBin/PrivateBin/releases/tag/1.6.2) our release assets are [verified with the SLSA framework](https://slsa.dev/).
|
||||
SLSA stands for „Supply-chain Levels for Software Artifacts”.
|
||||
Since [release 1.6.2](https://github.com/PrivateBin/PrivateBin/releases/tag/1.6.2) our release assets additionally also are [verified with the SLSA (Supply-chain Levels for Software Artifacts) framework](https://slsa.dev/), providing an in-toto manifest of the release archive.
|
||||
|
||||
This achieves the following:
|
||||
1. It ensures no maintainer has gone rogue and has modified/tampered with the source code before “building” the release.
|
||||
|
|
@ -13,58 +12,33 @@ This achieves the following:
|
|||
This includes the workflow file defining how the release is done itself.
|
||||
3. Our release should achieve [SLSA build level 3](https://slsa.dev/spec/v1.0/levels#build-l3) as it [runs on GitHub](https://slsa.dev/spec/v1.0/threats). Some more properties [are thus achieved](https://slsa.dev/spec/v1.0/threats).
|
||||
|
||||
That said, here are some caveasts:
|
||||
* None of our dependencies has any SLSA verification yet (as of Dec 2023) and thus we (cannot) verify any of our own supply chain.
|
||||
That said, this is mitigated by the fact that the project has not that many dependencies at all.
|
||||
|
||||
For more information [see the corresponding issue](https://github.com/PrivateBin/PrivateBin/issues/1169) and [the GitHub workflow file](/.github/workflows/release.yml).
|
||||
|
||||
#### How to verify
|
||||
|
||||
Git signature for verifying the reproducibility and that a maintainer in posession with that PGP private key created the release with that content:
|
||||
```
|
||||
$ gpg2 --verify PrivateBin-1.2.1.tar.gz.asc # TODO: update for v1.6.2
|
||||
gpg: assuming signed data in 'PrivateBin-1.2.1.tar.gz'
|
||||
gpg: Signature made Sat Aug 11 22:38:29 2018 CEST
|
||||
gpg: using RSA key 0xE11B7950E9E183DB
|
||||
gpg: Good signature from "PrivateBin release (solely used for signing releases)" [<trust level here>]
|
||||
gpg: aka "PrivateBin code-sign (solely used for code signing) <git@privatebin.net>" [<trust level here>]
|
||||
Primary key fingerprint: 28CA 7C96 4938 EA5C 1481 D42A E11B 7950 E9E1 83DB
|
||||
```
|
||||
|
||||
For a more step-by-step guide in detail [see this FAQ](https://github.com/PrivateBin/PrivateBin/wiki/FAQ#how-can-i-securely-clonedownload-your-project).
|
||||
|
||||
## Reproducible builds
|
||||
|
||||
Since a long time, we signed release `.tar.gz` and `.zip` files with personal PGP keys confirming the authenticity of the fact that the release has been build by a PrivateBin maintainer.
|
||||
All releases `.tar.gz` and `.zip` archives since 1.0 come with corresponding `.asc` signatures that can be used to confirm the authenticity of the fact that the release has been issued by a PrivateBin maintainer.
|
||||
|
||||
This uses traditional [PGP](https://en.wikipedia.org/wiki/Pretty_Good_Privacy) signatures.
|
||||
|
||||
### How to verify
|
||||
## Verification
|
||||
|
||||
You can use the gpg signatures for verifying the reproducibility and that a maintainer in posession with that PGP private key created the release with that content:
|
||||
|
||||
Git signature for verifying the reproducibility and that a maintainer in posession with that PGP private key created the release with that content:
|
||||
```
|
||||
$ gpg2 --verify PrivateBin-1.2.1.tar.gz.asc # TODO: update for v1.6.2
|
||||
gpg: assuming signed data in 'PrivateBin-1.2.1.tar.gz'
|
||||
gpg: Signature made Sat Aug 11 22:38:29 2018 CEST
|
||||
gpg: using RSA key 0xE11B7950E9E183DB
|
||||
gpg: Good signature from "PrivateBin release (solely used for signing releases)" [<trust level here>]
|
||||
gpg: aka "PrivateBin code-sign (solely used for code signing) <git@privatebin.net>" [<trust level here>]
|
||||
$ gpg2 --verify 1.6.2.tar.gz.asc
|
||||
gpg: assuming signed data in '1.6.2.tar.gz'
|
||||
gpg: Signature made Fri Dec 15 06:21:08 2023 UTC
|
||||
gpg: using RSA key 28CA7C964938EA5C1481D42AE11B7950E9E183DB
|
||||
gpg: Good signature from "PrivateBin release (solely used for signing releases)" [unknown]
|
||||
gpg: WARNING: This key is not certified with a trusted signature!
|
||||
gpg: There is no indication that the signature belongs to the owner.
|
||||
Primary key fingerprint: 28CA 7C96 4938 EA5C 1481 D42A E11B 7950 E9E1 83DB
|
||||
```
|
||||
|
||||
For a more step-by-step guide in detail [see this FAQ](https://github.com/PrivateBin/PrivateBin/wiki/FAQ#how-can-i-securely-clonedownload-your-project).
|
||||
|
||||
## How to release
|
||||
SLSA verification can be performed using the [SLSA verifier](https://github.com/slsa-framework/slsa-verifier#verification-of-slsa-provenance).
|
||||
|
||||
1. Create a release branch (schema: `x.y.z`) and push that as a new branch to GitHub.
|
||||
2. This will automatically trigger the worflow [/.github/workflows/release.yml](/.github/workflows/release.yml) on GitHub that will generate SLSA provenance _and_ draft a release with most artifacts attached at the end.
|
||||
3. Now you will need to generate a release `.zip` and `.tar.gz` locally too. Just use `git archive` command for that (TODO: please add specifics).
|
||||
**Important:** Please don't just download them from GitHub, this bringes no security benefit as that would basically mean trusting GitHub and letting GitHub “build” the release.
|
||||
4. Sign that release with GPG with your private key:
|
||||
```
|
||||
git sign # TODO
|
||||
```
|
||||
5. Upload the `.tar.gz.sig` and `.zip.sig` on GitHub/attach them to the release.
|
||||
**Note** It may also be a good idea to follow the above guide on how to verify the reproducible builds by verifying the hashes of the two release archives.
|
||||
Alternatively, you can also compare the hashes of the release file from GitHub and your local one to verify the are the same.
|
||||
## Release process
|
||||
|
||||
The release process is outlined in the [release checklist](https://github.com/PrivateBin/PrivateBin/wiki/Release-Checklist). The key manual steps are performed using a [Makefile](https://github.com/PrivateBin/PrivateBin/blob/master/Makefile#L31-L43) and using a [shell script](https://github.com/rugk/gittools/blob/master/signrelease.sh).
|
||||
|
|
|
|||
Loading…
Reference in New Issue