@@ -11,13 +11,13 @@ gpg.program::
11
11
12
12
gpg.format::
13
13
Specifies which key format to use when signing with `--gpg-sign`.
14
- Default is "openpgp" and another possible value is "x509".
14
+ Default is "openpgp". Other possible values are "x509", "ssh ".
15
15
16
16
gpg.<format>.program::
17
17
Use this to customize the program used for the signing format you
18
18
chose. (see `gpg.program` and `gpg.format`) `gpg.program` can still
19
19
be used as a legacy synonym for `gpg.openpgp.program`. The default
20
- value for `gpg.x509.program` is "gpgsm".
20
+ value for `gpg.x509.program` is "gpgsm" and `gpg.ssh.program` is "ssh-keygen" .
21
21
22
22
gpg.minTrustLevel::
23
23
Specifies a minimum trust level for signature verification. If
@@ -33,3 +33,44 @@ gpg.minTrustLevel::
33
33
* `marginal`
34
34
* `fully`
35
35
* `ultimate`
36
+
37
+ gpg.ssh.defaultKeyCommand:
38
+ This command that will be run when user.signingkey is not set and a ssh
39
+ signature is requested. On successful exit a valid ssh public key is
40
+ expected in the first line of its output. To automatically use the first
41
+ available key from your ssh-agent set this to "ssh-add -L".
42
+
43
+ gpg.ssh.allowedSignersFile::
44
+ A file containing ssh public keys which you are willing to trust.
45
+ The file consists of one or more lines of principals followed by an ssh
46
+ public key.
47
+ e.g.: user1@example.com,user2@example.com ssh-rsa AAAAX1...
48
+ See ssh-keygen(1) "ALLOWED SIGNERS" for details.
49
+ The principal is only used to identify the key and is available when
50
+ verifying a signature.
51
+ +
52
+ SSH has no concept of trust levels like gpg does. To be able to differentiate
53
+ between valid signatures and trusted signatures the trust level of a signature
54
+ verification is set to `fully` when the public key is present in the allowedSignersFile.
55
+ Therefore to only mark fully trusted keys as verified set gpg.minTrustLevel to `fully`.
56
+ Otherwise valid but untrusted signatures will still verify but show no principal
57
+ name of the signer.
58
+ +
59
+ This file can be set to a location outside of the repository and every developer
60
+ maintains their own trust store. A central repository server could generate this
61
+ file automatically from ssh keys with push access to verify the code against.
62
+ In a corporate setting this file is probably generated at a global location
63
+ from automation that already handles developer ssh keys.
64
+ +
65
+ A repository that only allows signed commits can store the file
66
+ in the repository itself using a path relative to the top-level of the working tree.
67
+ This way only committers with an already valid key can add or change keys in the keyring.
68
+ +
69
+ Using a SSH CA key with the cert-authority option
70
+ (see ssh-keygen(1) "CERTIFICATES") is also valid.
71
+
72
+ gpg.ssh.revocationFile::
73
+ Either a SSH KRL or a list of revoked public keys (without the principal prefix).
74
+ See ssh-keygen(1) for details.
75
+ If a public key is found in this file then it will always be treated
76
+ as having trust level "never" and signatures will show as invalid.
0 commit comments