Redact secret values from conversion-failure exceptions (S1)

[guy-lud]

S1 — Redact secret values from conversion-failure exceptions

Found during the P5 security review. A bound configuration value that fails type conversion could reach logs two ways:

1. Our own SettingsPropertyValueException message interpolated the raw value ([{value}]).
2. The failing converter's framework inner exception embeds the raw input in its own message (FormatException/ArgumentException for int/enum/DateTime) and was chained in, so Exception.ToString() / ILogger printed it.

Realistic trigger: a secret on a typed property (a credentialed Uri that fails to parse, or a secret mis-bound to int/enum). A secret bound to string never fails conversion, so it doesn't hit this.

Fix (full — Rec 1)

The three-specialist plan review chose the full fix and rejected an opt-in "restore diagnostics" flag as insecure-by-configuration.

• Resources.PropertySetterExceptionMessage — no longer includes the value; reports property name, target type, and the failing converter's exception type name (a compile-time identifier, cannot carry a secret). Fixes the to to typo.
• SettingsPropertyValueException — ctor drops the value param and no longer chains the framework inner. Invariant: never carries a value, never chains an inner → auditably leak-proof.
• New SettingsPropertyNullException (internal) — the value-free "AllowEmpty = false, no value" path keeps its full, useful message instead of being redacted; ConvertPropertyValue rethrows it unredacted.
• ISectionBinder — doc note that custom binders must not throw value-bearing messages (the public SettingsBindingException chains the binder's inner; the four built-ins don't).

Both changed exceptions are internal → non-breaking.

Tests

Conversion/ExceptionRedactionTests.cs (+5): binds a sentinel secret to int/enum/DateTime/Uri and to a hostile custom converter, asserting the sentinel is absent from the entire ex.ToString() chain while property name + target type remain. Existing null-path test updated to SettingsPropertyNullException + message assertion. Suite 76 net10 (was 71).

Note (modern .NET): UriFormatException is generic (no URI), so the Uri leak was via our message, not the inner — the Uri test targets our message accordingly.

Tradeoff

A non-secret misconfiguration now loses the framework message/stack (gets property + target + failure type instead). Deliberate security-over-diagnostics call — worth a release-note mention.

Review

• Plan reviewed by security-auditor (ENDORSE-WITH-CHANGES; all 3 required changes folded in), architecture + performance lenses (off the hot path — failure-only).
• Code reviewed via /code-review (high) + Roslyn detect_antipatterns (0) — blast radius is only the two throw sites + tests.

[guy-lud]

We can say is not SettingsPropertyNullException in the catch(exception).

[guy-lud]

Done in 3d0e9b8 — switched to catch (Exception e) when (e is not SettingsPropertyNullException). Same behavior, and the filter skips the catch entirely so the null exception's throw context is untouched (no rethrow). Thanks!