docs(crypto): state the real base64 key contract

Claude-Run commented

2026-08-02 16:14:43 +02:00

Member

The decode_master_key doc comment claimed standard base64 was accepted "with or without padding via a trim". That is false: both key decoders use the B64_STANDARD engine, whose PAD config defaults to DecodePaddingMode::RequireCanonical, so an unpadded 43-character key is rejected. The trim only strips surrounding whitespace. decode_session_key documented nothing about the alphabet or padding at all, and both failure messages said only "is not valid base64", giving an operator no hint about what to change.

Decoding behavior is unchanged: canonical decoding of a security key is the right default, since it rejects a truncated or re-encoded key instead of silently accepting it. Both doc comments now state the contract (standard alphabet, padding required, exactly 32 decoded bytes, i.e. what openssl rand -base64 32 emits), both base64 error contexts name the requirement and the minting recipe, and new unit tests pin the strictness by asserting that unpadded and URL-safe encodings are rejected for both keys. The wrong-length error stays separate.

#MCPWEB-8

The decode_master_key doc comment claimed standard base64 was accepted "with or without padding via a trim". That is false: both key decoders use the B64_STANDARD engine, whose PAD config defaults to DecodePaddingMode::RequireCanonical, so an unpadded 43-character key is rejected. The trim only strips surrounding whitespace. decode_session_key documented nothing about the alphabet or padding at all, and both failure messages said only "is not valid base64", giving an operator no hint about what to change. Decoding behavior is unchanged: canonical decoding of a security key is the right default, since it rejects a truncated or re-encoded key instead of silently accepting it. Both doc comments now state the contract (standard alphabet, padding required, exactly 32 decoded bytes, i.e. what `openssl rand -base64 32` emits), both base64 error contexts name the requirement and the minting recipe, and new unit tests pin the strictness by asserting that unpadded and URL-safe encodings are rejected for both keys. The wrong-length error stays separate. #MCPWEB-8

Claude-Run added 1 commit

2026-08-02 16:14:43 +02:00

docs(crypto): state the real base64 key contract

Check / fmt + clippy + build + tests (pull_request) Successful in 1m20s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

9875e6db22

The decode_master_key doc comment claimed standard base64 was accepted "with or without padding via a trim". That is false: both key decoders use the B64_STANDARD engine, whose PAD config defaults to DecodePaddingMode::RequireCanonical, so an unpadded 43-character key is rejected. The trim only strips surrounding whitespace. decode_session_key documented nothing about the alphabet or padding at all, and both failure messages said only "is not valid base64", giving an operator no hint about what to change.

Decoding behavior is unchanged: canonical decoding of a security key is the right default, since it rejects a truncated or re-encoded key instead of silently accepting it. Both doc comments now state the contract (standard alphabet, padding required, exactly 32 decoded bytes, i.e. what `openssl rand -base64 32` emits), both base64 error contexts name the requirement and the minting recipe, and new unit tests pin the strictness by asserting that unpadded and URL-safe encodings are rejected for both keys. The wrong-length error stays separate.

#MCPWEB-8

Claude-Run merged commit a8adc9f75e into main

2026-08-02 16:16:45 +02:00

Claude-Run deleted branch fix/MCPWEB-8-base64-key-contract

2026-08-02 16:16:46 +02:00

Claude-Run referenced this pull request from a commit

2026-08-02 16:16:47 +02:00

Merge pull request 'docs(crypto): state the real base64 key contract' (#7) from fix/MCPWEB-8-base64-key-contract into main

Rows
Columns

docs(crypto): state the real base64 key contract #7