Skip to content
This repository was archived by the owner on Aug 5, 2026. It is now read-only.

fix(archive): kind cross-check on definition-ref label resolution - #25

Merged
braghettos merged 1 commit into
mainfrom
fix/ref-label-kind-guard
Jul 13, 2026
Merged

fix(archive): kind cross-check on definition-ref label resolution#25
braghettos merged 1 commit into
mainfrom
fix/ref-label-kind-guard

Conversation

@braghettos

Copy link
Copy Markdown
Collaborator

What

Hardening follow-up to #24. Step 1 of searchCompositionDefinition (definition-ref label resolution) trusted the instance's composition-definition-name/-namespace labels blindly — no kind cross-check. If those labels ever pointed at a CompositionDefinition of a different kind (mislabeled instance, or name reuse after a delete/recreate), step 1 would resolve — and fetch — the wrong chart.

The guard

After finding the CD by name+namespace in step 1, verify its status.kind equals the instance kind (via the existing getChartVersionKind helper; its version return is ignored, and an error reading the status kind is treated as a mismatch):

  • Match → use it (current behavior, unchanged).
  • Mismatch → log a Warn (refName/refNamespace, expected kind, found kind) and fall through to step 2 (exact version+kind match) — the mislabeled CD is neither used nor turned into an error, so the later fallbacks can still resolve the true owner.

The stale-label path (ref labels matching no CD at all) keeps its existing Debug log and fall-through.

Test

New table case in getter_search_test.go: instance ref-labels point at an existing CD whose status.kind differs → resolution falls through and succeeds via the exact version+kind match on the true owner. All 7 cases pass:

--- PASS: TestSearchCompositionDefinition
    --- PASS: .../definition-ref_labels_win_despite_version_skew_and_same-kind_ambiguity
    --- PASS: .../exact_version+kind_match_still_works_without_ref_labels
    --- PASS: .../stale_ref_labels_fall_through_to_exact_version_match
    --- PASS: .../ref_labels_pointing_at_a_different-kind_definition_fall_through_to_exact_match
    --- PASS: .../unique-kind_fallback_tolerates_version_skew_without_ref_labels
    --- PASS: .../ambiguous_same-kind_definitions_with_version_skew_still_error
    --- PASS: .../single_definition_fast_path_unchanged

gofmt clean, go build ./... and go test ./internal/tools/archive/... pass.

🤖 Generated with Claude Code

Step 1 of searchCompositionDefinition trusted the definition-ref labels
blindly: if they ever pointed at a CompositionDefinition of a different
kind (mislabeled instance, name reuse after delete/recreate) it would
fetch the wrong chart. Verify status.kind against the instance kind via
getChartVersionKind before using the referenced definition; on mismatch
(or unreadable status kind) log a Warn and fall through to the exact
version+kind match instead of using it or erroring.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@braghettos
braghettos merged commit 9c4270f into main Jul 13, 2026
3 checks passed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant