Skip to content

Sanitizer retains malformed doubled-colon path suffix #1113

Description

@bcdonadio

Observed behavior: On current default-branch commit
0200484b8111919fccc42e6115ca18f54c15c9f1, the public pure
sanitizeError export receives the fictional malformed mixed path
/p\C:\E::\SECRET and returns <path>:\E::\SECRET. The R7 candidate for
Bug #925 improves the prefix to <path>\<path>::\SECRET, but both outputs
retain the private suffix and are already idempotent.

Expected behavior: Conservatively redact the remaining absolute-looking
path suffix without relying on a second sanitization pass.

Root cause: E:: is not a valid Windows drive construct. A path scan stops
at the doubled colon and the remaining :\SECRET text has no recognized path
start, so the outer scanner does not reclassify it.

How to reproduce safely: Call the exported pure sanitizer with the literal
fictional string /p\C:\E::\SECRET and compare the exact first and second
outputs. No filesystem, daemon, network, credentials, or production data are
involved.

Resolution context: Discovered during the exact-SHA R7 review of Bug #925
and PR #1080. It is pre-existing, distinct from Bug #1090's POSIX-to-drive
handoff and Bug #1104's valid nested drive path, and is not fixed by the R7
candidate. Addressing malformed residue requires a separate scanner policy and
must not expand the bounded #925 fix.

Campaign scope: Accepted P2 deferred after the initial remediation budget
was exhausted. Native Bug outside the frozen S3 and S4 inventories; link only
and do not add it as a native child of the current campaign Epic.

Environment:

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    Fields

    Priority

    Medium

    Effort

    None yet

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions