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:22 UTC
Message-ID: <CAP8UFD10yqwmdDEbkq19ANtgxfG93_Mcw7tK50Ouyu-G7MwGWQ@mail.gmail.com>
In-Reply-To: <CABPp-BFWem8iWFQn0Sq7JhHigm7rZsa81D6r7zbsQSh3+ZH91Q@mail.gmail.com>

On Sat, Nov 8, 2025 at 1:35 AM Elijah Newren <newren@gmail.com> wrote:

Show 22 quoted lines

> 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.

Thanks for a great description of the context motivating this series.

Show 14 quoted lines

> 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 agree with this analysis.

Show 7 quoted lines

> 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 would be a different strategy. Perhaps useful for some people, but I think it could have drawbacks.

For example since signatures are not checked at export time, it's possible that some invalid signatures at export time would still be imported back. Also what if the signature becomes invalid between export and import times because for example some keys are revoked?

If invalid signatures can actually be imported, then a name like 'strip-if-invalid' could be deceptive, so such a strategy should probably have a different name.

> It's
> the only alternative I can think of to what Christian is doing here;
> am I missing others?

I think what I am implementing is what most people would expect. So I think it's worth implementing even if in some cases another strategy might be better.