git/gpg-interface.h, branch main

fast-import: add 'abort-if-invalid' mode to '--signed-commits='

2026-03-26T19:42:57Z

The '--signed-commits=' option for git-fast-import(1) configures how signed commits are handled when encountered. In cases where an invalid commit signature is encountered, a user may wish to abort the operation entirely. Introduce an 'abort-if-invalid' mode to do so. Signed-off-by: Justin Tobler Signed-off-by: Junio C Hamano

fast-import: add mode to sign commits with invalid signatures

2026-03-13T04:28:20Z

With git-fast-import(1), handling of signed commits is controlled via the `--signed-commits=` option. When an invalid signature is encountered, a user may want the option to sign the commit again as opposed to just stripping the signature. To facilitate this, introduce a "sign-if-invalid" mode for the `--signed-commits` option. Optionally, a key ID may be explicitly provided in the form `sign-if-invalid[=]` to specify which signing key should be used when signing invalid commit signatures. Note that to properly support interoperability mode when signing commit signatures, the commit buffer must be created in both the repository and compatability object formats to generate the appropriate signatures accordingly. As currently implemented, the commit buffer for the compatability object format is not reconstructed and thus signing commits in interoperability mode is not yet supported. Support may be added in the future. Signed-off-by: Justin Tobler Signed-off-by: Junio C Hamano

gpg-interface: allow sign_buffer() to use default signing key

2026-03-13T04:28:20Z

The `sign_commit_to_strbuf()` helper in "commit.c" provides fallback logic to get the default configured signing key when a key is not provided and handles generating the commit signature accordingly. This signing operation is not really specific to commits as any arbitrary buffer can be signed. Also, in a subsequent commit, this same logic is reused by git-fast-import(1) when signing commits with invalid signatures. Remove the `sign_commit_to_strbuf()` helper from "commit.c" and extend `sign_buffer()` in "gpg-interface.c" to support using the default key as a fallback when the `SIGN_BUFFER_USE_DEFAULT_KEY` flag is provided. Call sites are updated accordingly. Signed-off-by: Justin Tobler Signed-off-by: Junio C Hamano

Merge branch 'cc/fast-import-strip-if-invalid'

2025-12-05T05:49:58Z

"git fast-import" learns "--strip-if-invalid" option to drop invalid cryptographic signature from objects. * cc/fast-import-strip-if-invalid: fast-import: add 'strip-if-invalid' mode to --signed-commits= commit: refactor verify_commit_buffer() fast-import: refactor finalize_commit_buffer()

fast-import: add 'strip-if-invalid' mode to --signed-commits=

2025-11-26T16:43:44Z

Tools like `git filter-repo`[1] use `git fast-export` and `git fast-import` to rewrite repository history. When rewriting history using one such tool though, commit signatures might become invalid because the commits they sign changed due to the changes in the repository history made by the tool between the fast-export and the fast-import steps. Note that as far as signature handling goes: * Since fast-export doesn't know what changes filter-repo may make to the stream, it can't know whether the signatures will still be valid. * Since filter-repo doesn't know what history canonicalizations fast-export performed (and it performs a few), it can't know whether the signatures will still be valid. * Therefore, fast-import is the only process in the pipeline that can know whether a specified signature remains valid. Having invalid signatures in a rewritten repository could be confusing, so users rewritting history might prefer to simply discard signatures that are invalid at the fast-import step. For example a common use case is to rewrite only "recent" history. While specifying commit ranges corresponding to "recent" commits could work, users worry about getting it wrong and want to just automatically rewrite everything, expecting older commit signatures to be untouched. To let them do that, let's add a new 'strip-if-invalid' mode to the `--signed-commits=` option of `git fast-import`. It would be interesting for the `--signed-tags=` option to have this mode too, but we leave that for a future improvement. It might also be possible for `git fast-export` to have such a mode in its `--signed-commits=` and `--signed-tags=` options, but the use cases for it are much less clear, so we also leave that for possible future improvements. For now let's just die() if 'strip-if-invalid' is passed to these options where it hasn't been implemented yet. [1]: https://github.com/newren/git-filter-repo Helped-by: Elijah Newren Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano

gpg-interface: use left shift to define GPG_VERIFY_*

2025-10-30T14:06:58Z

In "gpg-interface.h", the definitions of the GPG_VERIFY_* boolean flags are currently using 1, 2 and 4 while we often prefer the bitwise left shift operator, `<<`, for that purpose to make it clearer that they are boolean. Let's use the left shift operator here too. Let's also fix an indent issue with "4" while at it. Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano

gpg-interface: refactor 'enum sign_mode' parsing

2025-09-17T18:18:28Z

The definition of 'enum sign_mode' as well as its parsing code are in "builtin/fast-export.c". This was fine because `git fast-export` was the only command with '--signed-tags=' or '--signed-commits=' options. In a following commit, we are going to add a similar option to `git fast-import`, which will be simpler, easier and cleaner if we can reuse the 'enum sign_mode' defintion and parsing code. So let's move that definition and parsing code from "builtin/fast-export.c" to "gpg-interface.{c,h}". While at it, let's fix a small indentation issue with the arguments of parse_opt_sign_mode(). Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano

fast-(import|export): improve on commit signature output format

2025-07-09T23:08:29Z

A recent commit, d9cb0e6ff8 (fast-export, fast-import: add support for signed-commits, 2025-03-10), added support for signed commits to fast-export and fast-import. When a signed commit is processed, fast-export can output either "gpgsig sha1" or "gpgsig sha256" depending on whether the signed commit uses the SHA-1 or SHA-256 Git object format. However, this implementation has a number of limitations: - the output format was not properly described in the documentation, - the output format is not very informative as it doesn't even say if the signature is an OpenPGP, an SSH, or an X509 signature, - the implementation doesn't support having both one signature on the SHA-1 object and one on the SHA-256 object. Let's improve on these limitations by improving fast-export and fast-import so that: - all the signatures are exported, - at most one signature on the SHA-1 object and one on the SHA-256 are imported, - if there is more than one signature on the SHA-1 object or on the SHA-256 object, fast-import emits a warning for each additional signature, - the output format is "gpgsig

", where is the Git object format as before, and is the signature type ("openpgp", "x509", "ssh" or "unknown"), - the output is properly documented. About the output format: - allows to know which representation of the commit was signed (the SHA-1 or the SHA-256 version) which helps with both signature verification and interoperability between repos with different hash functions, - helps tools that process the fast-export stream, so they don't have to parse the ASCII armor to identify the signature type. It could be even better to be able to import more than one signature on the SHA-1 object and on the SHA-256 object, but other parts of Git don't handle that well for now, so this is left for future improvements. Helped-by: brian m. carlson Helped-by: Elijah Newren Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano

gpg-interface: fix misdesigned signing key interfaces

2024-09-05T15:49:11Z

The interfaces to retrieve signing keys and their IDs are misdesigned as they return string constants even though they indeed allocate memory, which leads to memory leaks. Refactor the code to instead always return allocated strings and let the callers free them accordingly. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

tag: fix sign_buffer() call to create a signed tag

2024-02-07T18:47:25Z

The command "git tag -s" internally calls sign_buffer() to make a cryptographic signature using the chosen backend like GPG and SSH. The internal helper functions used by "git tag" implementation seem to use a "negative return values are errors, zero or positive return values are not" convention, and there are places (e.g., verify_tag() that calls gpg_verify_tag()) that these internal helper functions translate return values that signal errors to conform to this convention, but do_sign() that calls sign_buffer() forgets to do so. Fix it, so that a failed call to sign_buffer() that can return the exit status from pipe_command() will not be overlooked. Reported-by: Sergey Kosukhin Signed-off-by: Junio C Hamano