| 1 | gpg.program:: |
| 2 | Pathname of the program to use instead of "`gpg`" when |
| 3 | making or verifying a PGP signature. The program must support the |
| 4 | same command-line interface as GPG, namely, to verify a detached |
| 5 | signature, "`gpg --verify $signature - <$file`" is run, and the |
| 6 | program is expected to signal a good signature by exiting with |
| 7 | code 0. To generate an ASCII-armored detached signature, the |
| 8 | standard input of "`gpg -bsau $key`" is fed with the contents to be |
| 9 | signed, and the program is expected to send the result to its |
| 10 | standard output. |
| 11 | |
| 12 | gpg.format:: |
| 13 | Specifies which key format to use when signing with `--gpg-sign`. |
| 14 | Default is "openpgp". Other possible values are "x509", "ssh". |
| 15 | + |
| 16 | See linkgit:gitformat-signature[5] for the signature format, which differs |
| 17 | based on the selected `gpg.format`. |
| 18 | |
| 19 | gpg.<format>.program:: |
| 20 | Use this to customize the program used for the signing format you |
| 21 | chose. (see `gpg.program` and `gpg.format`) `gpg.program` can still |
| 22 | be used as a legacy synonym for `gpg.openpgp.program`. The default |
| 23 | value for `gpg.x509.program` is "gpgsm" and `gpg.ssh.program` is "ssh-keygen". |
| 24 | |
| 25 | gpg.minTrustLevel:: |
| 26 | Specifies a minimum trust level for signature verification. If |
| 27 | this option is unset, then signature verification for merge |
| 28 | operations requires a key with at least `marginal` trust. Other |
| 29 | operations that perform signature verification require a key |
| 30 | with at least `undefined` trust. Setting this option overrides |
| 31 | the required trust-level for all operations. Supported values, |
| 32 | in increasing order of significance: |
| 33 | + |
| 34 | * `undefined` |
| 35 | * `never` |
| 36 | * `marginal` |
| 37 | * `fully` |
| 38 | * `ultimate` |
| 39 | |
| 40 | gpg.ssh.defaultKeyCommand:: |
| 41 | This command will be run when user.signingkey is not set and a ssh |
| 42 | signature is requested. On successful exit a valid ssh public key |
| 43 | prefixed with `key::` is expected in the first line of its output. |
| 44 | This allows for a script doing a dynamic lookup of the correct public |
| 45 | key when it is impractical to statically configure `user.signingKey`. |
| 46 | For example when keys or SSH Certificates are rotated frequently or |
| 47 | selection of the right key depends on external factors unknown to git. |
| 48 | |
| 49 | gpg.ssh.allowedSignersFile:: |
| 50 | A file containing ssh public keys which you are willing to trust. |
| 51 | The file consists of one or more lines of principals followed by an ssh |
| 52 | public key. |
| 53 | e.g.: `user1@example.com,user2@example.com ssh-rsa AAAAX1...` |
| 54 | See ssh-keygen(1) "ALLOWED SIGNERS" for details. |
| 55 | The principal is only used to identify the key and is available when |
| 56 | verifying a signature. |
| 57 | + |
| 58 | SSH has no concept of trust levels like gpg does. To be able to differentiate |
| 59 | between valid signatures and trusted signatures the trust level of a signature |
| 60 | verification is set to `fully` when the public key is present in the allowedSignersFile. |
| 61 | Otherwise the trust level is `undefined` and git verify-commit/tag will fail. |
| 62 | + |
| 63 | This file can be set to a location outside of the repository and every developer |
| 64 | maintains their own trust store. A central repository server could generate this |
| 65 | file automatically from ssh keys with push access to verify the code against. |
| 66 | In a corporate setting this file is probably generated at a global location |
| 67 | from automation that already handles developer ssh keys. |
| 68 | + |
| 69 | A repository that only allows signed commits can store the file |
| 70 | in the repository itself using a path relative to the top-level of the working tree. |
| 71 | This way only committers with an already valid key can add or change keys in the keyring. |
| 72 | + |
| 73 | Since OpensSSH 8.8 this file allows specifying a key lifetime using valid-after & |
| 74 | valid-before options. Git will mark signatures as valid if the signing key was |
| 75 | valid at the time of the signature's creation. This allows users to change a |
| 76 | signing key without invalidating all previously made signatures. |
| 77 | + |
| 78 | Using a SSH CA key with the cert-authority option |
| 79 | (see ssh-keygen(1) "CERTIFICATES") is also valid. |
| 80 | |
| 81 | gpg.ssh.revocationFile:: |
| 82 | Either a SSH KRL or a list of revoked public keys (without the principal prefix). |
| 83 | See ssh-keygen(1) for details. |
| 84 | If a public key is found in this file then it will always be treated |
| 85 | as having trust level "never" and signatures will show as invalid. |