Skip to content

Preserve repeated keys in INI store - #2315

Open
gochist wants to merge 2 commits into
getsops:mainfrom
gochist:fix/ini-repeated-keys-2314
Open

gochist wants to merge 2 commits into
getsops:mainfrom
gochist:fix/ini-repeated-keys-2314

Conversation

@gochist

@gochist gochist commented Oct 11, 2026 •

Copy link
Copy Markdown

Summary

  • Preserve repeated INI keys when parsing and encoding SOPS trees.
  • Add a regression test covering duplicate and identical repeated keys through an encrypt/decrypt-style round trip.

Fixes #2314

Tests

  • go test ./stores/... — passed.
  • go vet ./stores/ini — passed.
  • go test -race -coverprofile=profile.out -covermode=atomic ./... — passed.

@gochist
gochist marked this pull request as draft October 11, 2026 09:37
@gochist
gochist marked this pull request as ready for review October 11, 2026 09:53
@ToniAdreal

Copy link
Copy Markdown

Independently verified the fix against the reported case: on current main the round trip collapses the three driver lines to one; with this PR all three survive, including the identical duplicate.

Two smaller things I noticed while testing:

  1. If a comment sits directly before the last occurrence of a repeated key, it ends up in the tree once per value. Repro: [sec] with driver = a, then ; note mid, then driver = b — parsing produces [driver a, Comment("note mid"), driver b, Comment("note mid")], because the key.Comment append runs inside the ValueWithShadows() loop. Hoisting that append out of the loop (once per key) fixes it. The re-encoded INI happens to render the comment once, but the duplicate is in the tree itself.
  2. Interleaved repeats get regrouped: driver = a / other = 1 / driver = b round-trips as driver = a / driver = b / other = 1. All values are preserved; only the cross-key ordering changes (this follows from section.Keys() yielding each key once with its shadows grouped). Flagging it in case strict order preservation matters for the OpenStack use case in INI encryption silently drops repeated keys within a section #2314.

Allow duplicate keys when parsing and encoding INI files, and expand
shadow values into separate SOPS tree items. This preserves repeated
keys across an encrypt/decrypt round trip.

Assisted-by: OpenAI Codex
Signed-off-by: June Yi <june.yi@samsung.com>
Move the key comment outside the ValueWithShadows loop so it is added
to the SOPS tree only once for repeated keys. Add a regression test for
the reported case.

Assisted-by: OpenAI Codex

Signed-off-by: June Yi <june.yi@samsung.com>
@gochist
gochist force-pushed the fix/ini-repeated-keys-2314 branch from 9429a08 to 9ab57ed Compare October 14, 2026 14:05
@gochist

gochist commented Oct 14, 2026

Copy link
Copy Markdown
Author

Thanks for the review. I moved the key.Comment append outside the ValueWithShadows() loop so each repeated key's comment is added to the SOPS tree only once, and added a regression test for the reported case.

For the ordering point, I checked oslo.config, OpenStack's configuration library. It looks up options by name, so it does not depend on the order of different keys; the regrouping of interleaved repeated keys does not affect that use case.

I ran go test ./... and go vet ./stores/ini locally in a container; both passed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

INI encryption silently drops repeated keys within a section

2 participants