2023-01-20 20:57:59 +00:00
|
|
|
# sig #
|
2020-11-16 12:21:30 +00:00
|
|
|
|
2023-01-20 20:57:59 +00:00
|
|
|
The simple code signature toolchain for git repos.
|
2020-11-16 12:21:30 +00:00
|
|
|
|
|
|
|
## Features
|
|
|
|
|
2023-01-20 20:57:59 +00:00
|
|
|
* Attach any number of signatures to any given git ref
|
2020-11-16 12:21:30 +00:00
|
|
|
* Verify git history contains a minimum threshold of unique commit siguatures
|
|
|
|
* Verify signatures belong to a defined GPG alias group
|
2023-01-20 20:57:59 +00:00
|
|
|
* Verify code changes made since last time minimum valid signatures were present
|
2020-11-18 00:11:29 +00:00
|
|
|
* Allow user to manually verify new keys and add to alias groups on the fly
|
|
|
|
* Prompt user to install or upgrade any required tools as needed
|
2023-01-20 20:57:59 +00:00
|
|
|
* Signs aginst git agnostic "tree hash" so signatures survive rebases
|
|
|
|
* So long as the directory contents at a given ref do not change
|
2020-11-16 12:21:30 +00:00
|
|
|
|
|
|
|
## Install
|
|
|
|
|
|
|
|
1. Clone
|
2020-11-16 12:31:25 +00:00
|
|
|
|
|
|
|
```
|
|
|
|
git clone git@gitlab.com/pchq/sig.git sig
|
|
|
|
```
|
2020-11-16 12:21:30 +00:00
|
|
|
|
2023-01-19 22:03:41 +00:00
|
|
|
2. Review source code and signatures manually
|
2020-11-16 12:36:05 +00:00
|
|
|
|
2023-01-26 02:03:59 +00:00
|
|
|
Using `sig` to verify the signatures of `sig` itself is not recommended.
|
2020-11-16 12:31:25 +00:00
|
|
|
|
2023-01-19 22:03:41 +00:00
|
|
|
Consider using the following one liner which is much faster to review:
|
2020-11-16 12:31:25 +00:00
|
|
|
```
|
2023-01-19 22:03:41 +00:00
|
|
|
while read -r line; do \
|
|
|
|
gpg --verify \
|
2023-01-26 02:03:59 +00:00
|
|
|
<(printf "$line" | sed 's/.*pgp://g'| openssl base64 -d -A) \
|
|
|
|
<(printf "$line" | sed 's/pgp:.*/pgp/g'); \
|
2023-01-19 22:03:41 +00:00
|
|
|
done < <(git notes --ref=signatures show)
|
2020-11-16 12:31:25 +00:00
|
|
|
```
|
2020-11-16 12:21:30 +00:00
|
|
|
|
2023-01-26 02:03:59 +00:00
|
|
|
3. Copy to `$PATH`
|
2020-11-16 12:31:25 +00:00
|
|
|
|
|
|
|
```
|
|
|
|
cp sig ~/.local/bin/
|
|
|
|
```
|
2020-11-16 12:21:30 +00:00
|
|
|
|
2020-11-17 23:40:34 +00:00
|
|
|
## Usage
|
|
|
|
|
2023-01-19 22:03:41 +00:00
|
|
|
* sig verify [-g,--group=<group>] [-t,--threshold=<N>] [-r,--ref=<ref> ] [-d,--diff=<branch>]
|
2023-01-26 02:03:59 +00:00
|
|
|
* Verify m-of-n signatures by given group are present for a given git ref.
|
2020-11-17 23:40:34 +00:00
|
|
|
* sig add
|
2023-01-19 22:03:41 +00:00
|
|
|
* Add signature to this git ref
|
2020-11-20 09:21:39 +00:00
|
|
|
* sig fetch [-g,--group=<group>]
|
|
|
|
* Fetch key by fingerprint. Optionally add to group.
|
2020-11-17 23:40:34 +00:00
|
|
|
* sig help
|
|
|
|
* Show help text.
|
|
|
|
* sig version
|
|
|
|
* Show version information.
|
|
|
|
|
2020-11-16 12:21:30 +00:00
|
|
|
## Methods
|
|
|
|
|
|
|
|
### Git
|
|
|
|
|
2020-12-04 04:56:38 +00:00
|
|
|
This method verifies the current HEAD was signed exactly as-is by one or more
|
|
|
|
keys.
|
2020-11-16 12:21:30 +00:00
|
|
|
|
2020-12-04 04:56:38 +00:00
|
|
|
This counts the commit signature, and any number of signed tags pointing at
|
|
|
|
this ref.
|
2020-11-16 12:21:30 +00:00
|
|
|
|
2020-12-04 04:56:38 +00:00
|
|
|
### Assumptions
|
2023-01-19 22:03:41 +00:00
|
|
|
- Single sig mode: Repo contents controlled by signer
|
|
|
|
- Multi-sig mode: Repo contents verified by multiple signers
|
|
|
|
- Multi-sig group mode: Repo contents approved by specified individuals
|
|
|
|
- Hashing scheme for respective backend is not broken: (sha256)
|
2020-11-16 12:21:30 +00:00
|
|
|
|
2020-11-16 12:43:14 +00:00
|
|
|
## Examples
|
|
|
|
|
2023-01-19 22:03:41 +00:00
|
|
|
#### Verify at least one signature is present with a known key
|
2020-11-16 12:21:30 +00:00
|
|
|
|
|
|
|
```
|
|
|
|
sig verify
|
|
|
|
```
|
|
|
|
|
2023-01-19 22:03:41 +00:00
|
|
|
#### Verify 2 unique signatures from known keys
|
2020-11-16 12:21:30 +00:00
|
|
|
|
|
|
|
```
|
|
|
|
sig verify --threshold 2
|
|
|
|
```
|
|
|
|
|
2023-01-19 22:03:41 +00:00
|
|
|
#### Verify 3 unique signatures from specified signing group
|
2020-11-25 02:16:50 +00:00
|
|
|
|
|
|
|
```
|
2023-01-19 22:03:41 +00:00
|
|
|
sig verify --threshold 3 --group myteam
|
2020-11-16 12:21:30 +00:00
|
|
|
```
|
|
|
|
|
2023-01-20 20:57:59 +00:00
|
|
|
#### Show diff between HEAD and last ref with 2 verified unique signatures
|
|
|
|
|
|
|
|
```
|
|
|
|
sig verify --threshold 2 --diff
|
|
|
|
`
|
|
|
|
|
2023-01-19 22:03:41 +00:00
|
|
|
#### Add signature
|
2020-11-16 12:21:30 +00:00
|
|
|
|
|
|
|
```
|
|
|
|
sig add
|
|
|
|
```
|
2020-11-17 00:22:24 +00:00
|
|
|
|
|
|
|
## Frequently Asked Questions
|
|
|
|
|
|
|
|
### Why Bash?
|
|
|
|
|
2020-11-17 23:56:39 +00:00
|
|
|
Because it is easy to quickly verify at any time, has wide OS compatibility and
|
|
|
|
the majority of the needed operations are calling other programs already on
|
|
|
|
most systems like gpg and openssl.
|
2020-11-17 00:22:24 +00:00
|
|
|
|
|
|
|
If this were in another language it would be harder to audit on the fly, would
|
|
|
|
require the user to have a specific language toolchain installed, and it would
|
|
|
|
still mostly just be a bunch of shell executions to call system binaries
|
|
|
|
anyway.
|
|
|
|
|
|
|
|
### Why PGP?
|
|
|
|
|
|
|
|
In spite of many popular claims to the contrary, PGP is still the most well
|
|
|
|
supported protocol for distribution, verification, and signing for keys held
|
2020-11-18 00:37:13 +00:00
|
|
|
by individual humans. It is also the only protocol with wide HSM support
|
|
|
|
allowing you to keep keys out of system memory and require physical approval
|
|
|
|
for each operation. E.G a trezor, ledger, yubikey, etc.
|
2020-11-17 00:22:24 +00:00
|
|
|
|
|
|
|
Admittedly the GnuPG codebase itself is a buggy dated mess, but PGP as a spec
|
|
|
|
is still Pretty Good for many use cases. A recent modern rewrite by a number
|
|
|
|
of former GnuPG team members is near complete and set to give PGP a long and
|
|
|
|
stable future.
|
|
|
|
|
|
|
|
See: https://sequoia-pgp.org/
|
|
|
|
|
2020-11-18 00:37:13 +00:00
|
|
|
### Why not "notary" ?
|
|
|
|
|
|
|
|
Notary is very well designed and well supports many HSMs.
|
|
|
|
|
|
|
|
It may be worth supporting as an alternate method in the future if m-of-n
|
|
|
|
multisig is ever implemented as a part of the TUF specification which has been
|
|
|
|
on their TODO list for a few years now.
|
|
|
|
|
|
|
|
It has the very desirable feature of conditionally expiring signatures which
|
|
|
|
no other solution has at the time of this writing, which comes from it being
|
|
|
|
purpose built for software signing concerns.
|
|
|
|
|
|
|
|
See: [The Update Framework](https://theupdateframework.io)
|
|
|
|
|
|
|
|
### Why not straight "openssl" ?
|
|
|
|
|
|
|
|
Openssl has HSM support via OpenSC that is fairly well supported via PKSC#11.
|
|
|
|
|
|
|
|
Contributions suggesting this an alterantive backend to OpenPGP are welcome,
|
|
|
|
however they would have to also come with methods for key discovery and pinned
|
|
|
|
key groups via configuration files of some kind.
|
|
|
|
|
|
|
|
PGP gives us these features almost for free.
|
|
|
|
|
|
|
|
### Why not "signify", "age", or "crev" ?
|
|
|
|
|
|
|
|
These alternatives have poor if any support for HSM workflows and thus put
|
|
|
|
private keys at too much risk of theft or loss to recommend for general use at
|
|
|
|
this time.
|
|
|
|
|
|
|
|
That said, verifying folders/repos that use these methods is certianly of value
|
|
|
|
and contributions to support doing this on systems where those tools are
|
|
|
|
available are welcome.
|