Re: [PATCH 0/3] fast-import: add 'strip-if-invalid' mode to --signed-commits=<mode>

From: Christian Couder <christian.couder@gmail.com>
Date: Nov 12, 2025, 07:19 UTC
Message-ID: <CAP8UFD1YqadtkYriePJKUBjzhXAyYjNEk-9rj55ZxbGLRAOd2g@mail.gmail.com>
In-Reply-To: <xmqqjz04mtji.fsf@gitster.g>

On Wed, Nov 5, 2025 at 3:40 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 14 quoted lines

>
> Christian Couder <christian.couder@gmail.com> writes:
>
> > The `--signed-commits=<mode>` option in `git fast-import` allows users
> > to decide what should be done when commits with signatures are
> > imported.
> >
> > For tools like `git filter-repo`, it would be useful to be able to
> > strip signatures when they are invalid, so let's add a new
> > 'strip-if-invalid' mode for that purpose.
>
> Sorry, but I do not get it.  What is your definition of a signature
> being "invalid", and what is your assumptions of how accurate a
> validity check ought to be?

The definition of "valid" is the same as the definition used by `git verify-commit`. The description of this command is:

"Validates the GPG signature created by `git commit -S` on the commit objects given on the command line."

Here we just also "validate" commit signatures in the same way and using the same underlying code. If `git verify-commit` would return 0, we consider the commit signature valid, otherwise we consider it invalid.

I will add such clarification to the documentation of the feature in the v2 I plan to send soon.

> For example, are you assuming that you
> have all the necessary public keys, revocation data and accurate
> clock?

Yes, we assume all that, like `git verify-commit` assumes it has all that too.

If we want to be clearer about what is needed to make sure that commit signatures can be properly validated, I think we should start with working on `git verify-commit` and improve its related documentation, and perhaps even some of its features. It would be simpler to have all the docs and features about this there, and just refer to that command (using for example "see git-verify-commit(1)") in other places. Such `git verify-commit` improvements could be in a separate patch series though.

Or maybe there is a better place, like perhaps the `git tag` documentation, or a dedicated gitsignature(7) page, where all the information about tag and commit signatures could be. Anyway such improvements could also be in a separate series.

Show 7 quoted lines

> Even if you are not changing a single bit in the import,
> some of your early commits' signatures do not "validate" and may
> need to be stripped, and after that happens, wouldn't signatures of
> all later commits become unusable (i.e, you may be able to verify
> that the signature on the original commit object may still be valid,
> but because the commit has to become a child of a rewritten commit,
> in the resulting history the signature would no longer match)?

Yes, I agree it could be an optimization to consider all the subsequent signatures invalid after one of them is invalid, but it would require making sure that the commit history that `git fast-import` receives is completely linear or that we properly track commit history when it's not not linear. I think it's better to start with a relatively simpler implementation like this one though.