Observed behavior: On current default-branch commit
253e306ccd937fa556fa9a241fed2f043410aebe, the public pure
sanitizeError export receives the fictional nested drive path
D:\E:\SECRET and returns <path>:\SECRET. The second drive suffix remains
visible on the first pass and the output is already idempotent.
Expected behavior: Redact both drive-qualified path segments in one pass,
without retaining the second drive suffix.
Root cause: A Windows scanAbsolutePath remembers only its initial drive
colon. It consumes a later backslash and drive letter as part of the first
span, then stops at the later colon. The outer scanner cannot re-enter at the
consumed second drive start.
How to reproduce safely: Call the exported pure sanitizer with the literal
fictional string D:\E:\SECRET and compare its exact first and second
outputs. No filesystem, daemon, network, credentials, or production data are
involved.
Resolution context: Discovered during the exact-SHA R6 review of Bug #925
and PR #1080. It is pre-existing on default branch and distinct from Bug #1090,
which covers a POSIX path followed by one drive. The same nested-drive colon
handling required for #925's candidate-only blocking finding is expected to
fix this Bug; record the fixing candidate and verify it on the default branch
rather than leaving a stale deferral.
Campaign scope: Native Bug outside the frozen S3 and S4 inventories. Link
only; do not add it as a native child of the current campaign Epic.
Environment:
Observed behavior: On current default-branch commit
253e306ccd937fa556fa9a241fed2f043410aebe, the public puresanitizeErrorexport receives the fictional nested drive pathD:\E:\SECRETand returns<path>:\SECRET. The second drive suffix remainsvisible on the first pass and the output is already idempotent.
Expected behavior: Redact both drive-qualified path segments in one pass,
without retaining the second drive suffix.
Root cause: A Windows
scanAbsolutePathremembers only its initial drivecolon. It consumes a later backslash and drive letter as part of the first
span, then stops at the later colon. The outer scanner cannot re-enter at the
consumed second drive start.
How to reproduce safely: Call the exported pure sanitizer with the literal
fictional string
D:\E:\SECRETand compare its exact first and secondoutputs. No filesystem, daemon, network, credentials, or production data are
involved.
Resolution context: Discovered during the exact-SHA R6 review of Bug #925
and PR #1080. It is pre-existing on default branch and distinct from Bug #1090,
which covers a POSIX path followed by one drive. The same nested-drive colon
handling required for #925's candidate-only blocking finding is expected to
fix this Bug; record the fixing candidate and verify it on the default branch
rather than leaving a stale deferral.
Campaign scope: Native Bug outside the frozen S3 and S4 inventories. Link
only; do not add it as a native child of the current campaign Epic.
Environment: