git-signify#

A tool to sign arbitrary objects in a git repository.

Generating keys#

Signing keys can be generated with a variety of different tools.

Signify#

With signify, from the OpenBSD project, one runs:

$ signify -G -p newkey.pub -s newkey.sec

If you do not wish to encrypt your keys, pass the -n flag to the command line of signify.

Minisign#

minisign provides a more portable alternative to signify. Keys can be generated with:

$ minisign -G -p newkey.pub -s newkey.sec

git-signify always assumes that minisign keys are encrypted, albeit the CLI tool allows generating non-encrypted keys.

ML-Signify#

ml-signify provides post-quantum secure keys in the form of ML-DSA. Keys can be generated with:

$ ml-signify keygen --signing-key newkey.sec --verifying-key newkey.pub

Basic usage#

This program keeps track of signatures made by a keypair with a given fingerprint as git references. References can be fetched from and pushed to a remote.

$ git signify pull origin
$ git signify push origin

Verification can be done with git signify verify. For example, to verify a release of git-signify itself:

$ git pull --tags
$ git signify pull
$ git signify verify -k <(curl -sfL https://gandas.us.to/keys/git.pub) v0.7.0
$ git signify verify -k <(curl -sfL https://gandas.us.to/keys/git_minisign.pub) v0.7.0

To sign git revisions, run something akin to:

$ git signify sign -k <secret-key> v0.7.0

In-depth#

Brief overview of how this program works#

git-signify writes a tree object to some git repository containing the following blobs:

100644 blob aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa	algorithm
100644 blob bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb	signature
100644 blob cccccccccccccccccccccccccccccccccccccccc	version
?????? ???? dddddddddddddddddddddddddddddddddddddddd	object

The entry object is a pointer to the respective git object being signed over, which typically assumes the form of a commit object. Then, signature contains the base64 encoded signify, minisign, or ml-signify signature over the raw (20 byte) id of object. The remaining blobs, version and algorithm, represent the current version of the git-signify tree format and the algorithm (signify, minisign, or ml-signify) being used, respectively.

The tree is then committed along with a potential parent, which is the commit hash being signed over, if any. The resulting commit's hash is returned by git signify raw sign.

Signatures end up in refs/signify/signatures/${key_fingerprint}/${sig_hash}, where $key_fingerprint can be computed by git signify fingerprint, and $sig_hash is a hash returned by git signify raw sign.

Why, we have GnuPG#

GPG sucks.