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

From: Elijah Newren <newren@gmail.com>
Date: Nov 8, 2025, 00:34 UTC
Message-ID: <CABPp-BFWem8iWFQn0Sq7JhHigm7rZsa81D6r7zbsQSh3+ZH91Q@mail.gmail.com>
In-Reply-To: <xmqqjz04mtji.fsf@gitster.g>

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

Show 22 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?  For example, are you assuming that you
> have all the necessary public keys, revocation data and accurate
> clock?  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)?

Good questions.  Let me step back and perhaps motivate the change a bit:

There's a fairly significant chunk of `git filter-repo` users who also have git histories with commit or tag signatures in their history. They often want to specify rules for rewriting history which happen to only affect "recent" commits. While they could try to specify commit ranges corresponding to "recent" commits, they worry about getting it wrong and want to just automatically rewrite everything, expecting older commit signatures to be untouched (since the modification rules didn't need to modify older commits), and get new commit OIDs starting with the first commit that was modified by one of the rewrite rules. Unfortunately, when fast-export exports history, it does so without signatures, and thus they get every commit rewritten, not just the recent history.

Christian's previous series allows us to have fast-export also export the signatures, but then we run into the problem of determining whether those signatures are still valid and what to do if they aren't. This series attempts to help us determine if they are valid, and implements one choice when they aren't (strip), in addition to one that the previous series implemented (keep-it-anyway), while leaving another (re-sign) for future work.

So, yeah, I'd presume this mode would have to assume the user had all the necessary public keys in order for fast-import to be able to check validity. Perhaps that is a tall order for a small percentage of repos out there, but for them, is there any good alternative?

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

I guess one alternative would be having fast-export include for any signed commit, what that signed commit's OID would have been had it been unsigned. That would allow fast-import to check what the commit OID would be without the signature, and if it matches, then just keep the signature without checking whether it's actually valid. It'd be a change to the fast-export & fast-import format to get such an extra piece of data, but perhaps that would be a preferable strategy? It's the only alternative I can think of to what Christian is doing here; am I missing others?