You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 2bb3dea
Browse filesBrowse the repository at this point in the historyBrowse files
fix(secrets): do not cap a hex password in URI user info as an unlabelled identifier (#831)
unlabelledHexIdentifierCap holds a bare 32/40/64-hex generic finding at 55
unless one of secretLabelWords is on the line. It was applied to every
candidate in processScopedCandidates, including the structural ones
findURIUserinfo produces. A URI user-info password is labelled by its
position in the URI grammar (#766), not by a word, and `REDIS_URL` names
none of the label words, so a hex password (the shape `openssl rand -hex 16`
prints) was held at 55 LOW with confidence_ceiling 55 and --pre-commit-mode
exited 0, while the same URI with a mixed-case password reported 100 HIGH.
The ceiling is now skipped for a structural candidate, as the M24 cap already
is. The user-info dispositions' own LOW ceiling (cand.ceiling) still applies,
so default vocabulary and a repeated user name stay LOW.
Main (0501dcd) vs this branch, --checks all --confidence all:
REDIS_URL=redis://default:<32 hex>@cache.internal:6379/0
55 LOW, exit 0 -> 100 HIGH, exit 1
same URI, 32-char mixed-case password 100 HIGH -> 100 HIGH
40-hex and 64-hex URI passwords 55 LOW -> 100 HIGH
40-hex token as a clone-URL user name 55 LOW -> 100 HIGH
ImageUniqueID: "<32 hex>" 55 LOW -> 55 LOW
redis://default:password@... 55 LOW -> 55 LOW
the #766 matrix (TestURIUserinfoMatrix) 185/185 -> 185/185
Co-authored-by: union <union@example.invalid>
0 commit comments