[Fix] nvm_sanitize_auth_header: allow ~, completing RFC 7235 token68

`~` is a member of RFC 7235 §2.1 `token68`,
and thus of RFC 6750 §2.1 `b64token`,
but the allowlist stripped it,
silently corrupting any opaque Bearer credential containing it:

    Bearer mF_9.B5f-4.1JqM~+/=  ->  Bearer mF_9.B5f-4.1JqM+/=

`Basic` credentials were never affected,
since RFC 4648 §4 base64 cannot emit `~`;
`;` stays stripped, as it belongs to no auth-scheme production.

Cover the charset in the unit test,
and assert the credential reaches the downloader intact via the existing fake-`wget` harness,
which needs no container.
This commit is contained in:
Andres Mejia Sanchez
2026-09-02 19:36:04 -07:00
committed by Jordan Harband
parent 6798d1dbc9
commit dd0f702fb1
3 changed files with 23 additions and 2 deletions
@@ -35,4 +35,18 @@ case "${RESULT}" in
;;
esac
# Test 6: every character of RFC 7235 §2.1 `token68` is preserved.
# token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"="
# This is a superset of both base64 and base64url; note the '~', which no
# base64 variant emits but which an opaque token may legitimately contain.
TOKEN68="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-._~+/="
RESULT=$(nvm_sanitize_auth_header "${TOKEN68}")
[ "${RESULT}" = "${TOKEN68}" ] || die "FAIL: token68 chars were stripped. Got: '${RESULT}'"
# Test 7: the RFC 6750 §2.1 example Bearer token, extended with the remaining
# valid `b64token` characters, survives intact.
B64TOKEN="Bearer mF_9.B5f-4.1JqM~+/="
RESULT=$(nvm_sanitize_auth_header "${B64TOKEN}")
[ "${RESULT}" = "${B64TOKEN}" ] || die "FAIL: b64token chars were stripped. Got: '${RESULT}'"
echo "All nvm_sanitize_auth_header tests passed"