git/gpg-interface.c, branch jch

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 'uk/signature-is-good-after-key-expires'

2026-03-03T01:06:50Z

A signature on a commit that was GPG signed long time ago ought to be still valid after the key that was used to sign it has expired, but we showed them in alarming red. * uk/signature-is-good-after-key-expires: gpg-interface: signatures by expired keys are fine

gpg-interface: remove an unnecessary NULL initialization

2026-02-06T01:59:19Z

We assign this variable unconditionally, so we do not need to initialize it to NULL where it is defined. Signed-off-by: Collin Funk Signed-off-by: Junio C Hamano

global: constify some pointers that are not written to

2026-02-06T01:52:49Z

The recent glibc 2.43 release had the following change listed in its NEWS file: For ISO C23, the functions bsearch, memchr, strchr, strpbrk, strrchr, strstr, wcschr, wcspbrk, wcsrchr, wcsstr and wmemchr that return pointers into their input arrays now have definitions as macros that return a pointer to a const-qualified type when the input argument is a pointer to a const-qualified type. When compiling with GCC 15, which defaults to -std=gnu23, this causes many warnings like this: merge-ort.c: In function ‘apply_directory_rename_modifications’: merge-ort.c:2734:36: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] 2734 | char *last_slash = strrchr(cur_path, '/'); | ^~~~~~~ This patch fixes the more obvious ones by making them const when we do not write to the returned pointer. Signed-off-by: Collin Funk Signed-off-by: Junio C Hamano

gpg-interface: signatures by expired keys are fine

2026-02-04T17:28:10Z

If a signature is made with a valid key and that key later expires, the signature should still be considered good. GnuPG emits in this case something like: [GNUPG:] NEWSIG gpg: Signature made Wed 26 Nov 2014 05:56:50 AM CET gpg: using RSA key FE3958F9067BC667 [GNUPG:] KEYEXPIRED 1478449622 [GNUPG:] KEY_CONSIDERED D783920D6D4F0C06AA4C25F3FE3958F9067BC667 0 [GNUPG:] KEYEXPIRED 1478449622 [GNUPG:] SIG_ID 8tAN3Fx6XB2NAoH5U8neoguQ9MI 2014-11-26 1416977810 [GNUPG:] EXPKEYSIG FE3958F9067BC667 Jason Cooper gpg: Good signature from "Jason Cooper " [expired] [GNUPG:] VALIDSIG D783920D6D4F0C06AA4C25F3FE3958F9067BC667 2014-11-26 1416977810 0 4 0 1 2 00 D783920D6D4F0C06AA4C25F3FE3958F9067BC667 gpg: Note: This key has expired! D783920D6D4F0C06AA4C25F3FE3958F9067BC667 (signature and signed data in this example is taken from Linux commit 756f80cee766574ae282baa97fdcf9cc). So GnuPG is relaxed and the fact that the key is expired is only worth a "Note" which is weaker than e.g. gpg: WARNING: The key's User ID is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. which git still considers ok. So stop coloring the signature by an expired key red and handle it like any other good signature. Signed-off-by: Uwe Kleine-König 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()

Merge branch 'jc/optional-path'

2025-12-05T05:49:56Z

"git config get --path" segfaulted on an ":(optional)path" that does not exist, which has been corrected. * jc/optional-path: config: really treat missing optional path as not configured config: really pretend missing :(optional) value is not there config: mark otherwise unused function as file-scope static

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