Harness the power of signify(1) to sign arbitrary git objects
update readme
+37
-22
+37
-22
README.md
+37
-22
README.md
···
4
4
5
5
## Generating keys
6
6
7
-
Signing keys can be generated with [`signify`], from the OpenBSD project.
7
+
Signing keys can be generated with a variety of different tools.
8
+
9
+
### Signify
10
+
11
+
With [`signify`](https://man.openbsd.org/signify.1), from the OpenBSD project,
12
+
one runs:
8
13
9
14
```
10
15
$ signify -G -p newkey.pub -s newkey.sec
11
16
```
12
17
13
-
If you do not wish to encrypt your keys, pass the `-n` flag to the
14
-
command line of `signify`.
18
+
If you do not wish to encrypt your keys, pass the `-n` flag to the command line
19
+
of `signify`.
15
20
16
-
Alternatively, [`minisign`] keys may also be used. This project provides
17
-
a more portable alternative to [`signify`].
21
+
### Minisign
22
+
23
+
[`minisign`](https://github.com/jedisct1/minisign) provides a more portable
24
+
alternative to [`signify`](https://man.openbsd.org/signify.1). Keys can be
25
+
generated with:
18
26
19
27
```
20
28
$ minisign -G -p newkey.pub -s newkey.sec
21
29
```
22
30
23
-
`git-signify` always assumes that [`minisign`] keys are encrypted,
24
-
albeit the CLI tool allows generating non-encrypted keys.
31
+
`git-signify` always assumes that
32
+
[`minisign`](https://github.com/jedisct1/minisign) keys are encrypted, albeit
33
+
the CLI tool allows generating non-encrypted keys.
34
+
35
+
### ML-Signify
36
+
37
+
[`ml-signify`](https://git.sr.ht/~sugo/ml-signify) provides post-quantum secure
38
+
keys in the form of [ML-DSA](https://csrc.nist.gov/pubs/fips/204/final). Keys
39
+
can be generated with:
25
40
26
-
[`signify`]: https://man.openbsd.org/signify.1
27
-
[`minisign`]: https://github.com/jedisct1/minisign
41
+
```
42
+
$ ml-signify keygen --signing-key newkey.sec --verifying-key newkey.pub
43
+
```
28
44
29
45
## Basic usage
30
46
31
47
This program keeps track of signatures made by a keypair with a given
32
-
fingerprint as git references. References can be fetched from and
33
-
pushed to a remote.
48
+
fingerprint as git references. References can be fetched from and pushed to a
49
+
remote.
34
50
35
51
```
36
52
$ git signify pull origin
37
53
$ git signify push origin
38
54
```
39
55
40
-
Verification can be done with `git signify verify`. For example, to
41
-
verify a release of `git-signify` itself:
56
+
Verification can be done with `git signify verify`. For example, to verify a
57
+
release of `git-signify` itself:
42
58
43
59
```
44
60
$ git pull --tags
···
67
83
?????? ???? dddddddddddddddddddddddddddddddddddddddd object
68
84
```
69
85
70
-
The entry `object` is a pointer to the respective git object being
71
-
signed over, which typically assumes the form of a commit object.
72
-
Then, `signature` contains the base64 encoded `signify` or `minisign`
73
-
signature over the raw (20 byte) id of `object`. The remaining blobs,
74
-
`version` and `algorithm`, represent the current version of the
75
-
`git-signify` tree format and the algorithm (`minisign` or `signify`)
76
-
being used, respectively.
86
+
The entry `object` is a pointer to the respective git object being signed over,
87
+
which typically assumes the form of a commit object. Then, `signature` contains
88
+
the base64 encoded `signify`, `minisign`, or `ml-signify` signature over the raw
89
+
(20 byte) id of `object`. The remaining blobs, `version` and `algorithm`,
90
+
represent the current version of the `git-signify` tree format and the algorithm
91
+
(`signify`, `minisign`, or `ml-signify`) being used, respectively.
77
92
78
93
The tree is then committed along with a potential parent, which is the commit
79
-
hash being signed over, if any. The resulting commit's hash is returned by
80
-
`git signify raw sign`.
94
+
hash being signed over, if any. The resulting commit's hash is returned by `git
95
+
signify raw sign`.
81
96
82
97
Signatures end up in `refs/signify/signatures/${key_fingerprint}/${sig_hash}`,
83
98
where `$key_fingerprint` can be computed by `git signify fingerprint`, and