fix: use exact key matching in report sanitize to prevent false redaction

[saiashok0981]

Problem

The sanitize() function in report.go protects sensitive values in pack report output by redacting quoted strings on matching TOML field lines. However, it uses strings.HasPrefix to detect field names, which causes false-positive matches on any key that merely starts with one of the sensitive names.

For example, the sensitive field list includes "image" and "name". A future config key such as "image-mirror = ..." or "name-prefix = ..." would unintentionally have its value redacted, because "image-mirror" has the prefix "image".

Additionally, the redaction regex ("(.*?)") is compiled fresh inside sanitize() on every line, even though it is a constant expression. Repeated compilation is wasteful when pack report processes a config file with many lines.

Fix

• Replace the strings.HasPrefix check with a field-anchored regex that requires the match to be <field-name> followed immediately by optional whitespace and =. This ensures only the exact TOML key is matched, not keys that happen to share a prefix.
• Pre-compile both the value-redaction regex and the field-match helper at package initialisation time so they are compiled exactly once.

The new pattern for each sensitive field is:
^<field>\s*=

This is consistent with TOML syntax, where key = value and key=value are both valid.

Signed-off-by: saiashok103@gmail.com

Summary

Output

Before

After

Documentation

• Should this change be documented?
  • Yes, see #___
  • No

Related

Resolves #___

[jjbustamante]

Hi @saiashok0981

Thanks for this contribution. Would you mind fixing the DCO check and also adding test coverage to reproduce the behavior? This looks like a bug, if the bug doesn't exist, you can also create it and link this PR to that fix

[kunalworldwide]

Switching from strings.HasPrefix to exact key matching prevents false redaction on fields like image-mirror or name-prefix, which is exactly the bug described. Pre-compiling the regex at package initialization is also a nice cleanup for the hot path.

One edge case to consider: the regex will match empty quoted values (""). That's fine for redaction, but does it handle escaped quotes inside values? TOML supports \" inside strings, and the current regex would stop at the escaped quote. Since pack report is meant for human-readable output, that's probably acceptable, but worth documenting if not handled.

LGTM.