[Bug] Flux source-controller retains Git verification after trust-key rotation

[N0zoM1z0]

Summary

After a GitRepository.spec.verify.secretRef change, source-controller can
reuse the same-revision optimized path without rechecking the commit
signature. The prior SourceVerified=True condition and artifact remain
advertised for the new generation.

Impact

A rotated or revoked signing key can remain effectively trusted for the
currently advertised artifact. A downstream GitOps consumer can continue to
accept that artifact even though the current verification Secret no longer
authorizes its signer.

Reproduction

The attached attachments.zip contains a concise envtest reproducer. It uses
a real SSH-signed commit, two different valid public-key Secrets, a local Git
HTTP server, and two complete controller reconciliations.

unzip attachments.zip
cd attachments
SOURCE_CONTROLLER_DIR=../source-controller-v1.9.3 \
KUBEBUILDER_ASSETS=../envtest-assets \
./reproduce.sh

Observed on v1.9.3 and current main:

artifact_revision_unchanged=true
git_core_old_key_verification=passed
git_core_new_key_verification=failed
source_verified_after_rotation=True
source_verified_observed_generation=1
ready_after_rotation=True
ready_observed_generation=2

The second reconciliation logs no changes since last reconciliation and
returns before signature verification because requiresVerification tracks
the mode but not the verification SecretRef/key set.

Expected behavior

Changing the verification SecretRef or its key material should establish a
new verification-policy epoch. The unchanged revision should be reverified
under the new policy before SourceVerified=True and Ready=True are
advertised for the new generation.

Versions

• source-controller v1.9.3: ed61ebda88cd70159b24df1c8df50b1e6be4cc3d
• source-controller current main: 143c11a58d226bee6f9efd774751cec92cd8dfff

Detailed source analysis, pinned GitHub links, logs, and the reproducer are in
report.md and attachments.zip.

The report and reproduction code were assisted by an LLM. I personally
reviewed the analysis and confirmed the behavior with the attached reproducer.
I apologize if this LLM assistance creates extra work; the additional detail
is intended to make the behavior and fix location easier to verify.

Attachments

report.md

attachments.zip

[matheuscscp]

What changed: the GitRepository object or the Secret object? Did the value of .spec.verify.secretRef.name actually change, or was it only the contents of the Secret? If it was only the contents of the Secret, that behavior is expected, not a bug. We don't watch Secrets. This is a feature request for watching Secrets.

[N0zoM1z0]

Thanks for checking. In my test, I changed the GitRepository itself:
.spec.verify.secretRef.name went from old-key to new-key. This was not an
in-place update to one Secret; both Secrets already existed and contained
different SSH public keys.

The update triggered a new reconciliation, but since the Git revision was
unchanged, the optimized path returned no changes since last reconciliation
without checking the commit against new-key. Git core accepts the commit
with the old key and rejects it with the new key, while Flux kept the previous
SourceVerified=True / Ready=True result.

So this case is about changing the referenced Secret, rather than watching
Secret contents. Hope that clears it up.

[matheuscscp]

@N0zoM1z0 I filed a PR to fix this, but it involves introducing a new field in GitRepository.status, so we can only ship it in Flux 2.10.