Refuse a private member whose value is base64url padding only

[zandbelt]

Summary

Follow-up to #189, which landed while this was in flight. The guard it added tests the decoded buffer pointer:

if (NULL != json_object_get(jwk_json, key) && NULL == *buffer)

but base64url padding on its own decodes to zero octets with a non-NULL buffer: cjose_base64url_decode breaks out of its loop on the first =, publishes the allocated buffer and reports a length of 0. So a private member of "==" or "====" walks past the check and

{"kty":"RSA","n":"...","e":"AQAB","d":"=="}

still imports as a public RSA key, which is exactly what #189 set out to prevent. "=" alone was already refused, by the inlen % 4 == 1 gate in the decoder, which is why the hole is easy to miss. The same applies to p, q, dp, dq and qi.

The guard now tests the decoded length as well. EC and OKP keys were never affected: their importers pass a non-zero expected length, so the decoder's length check rejects the padding first. RSA passes 0, meaning "any length", so there is nothing else to catch it.

Found by an independent review agent over the open PRs, which is the practice you asked for in #185 — this is the first thing it turned up.

Testing

• test_cjose_jwk_import_empty_private_member now covers "==" and "====" beside the empty string and null, so 24 negative cases over the six private members, plus the public and private serializations of the same key still importing. It fails on master with "a d of "==" was accepted".
• Full check_cjose, clang-format produces no diff.

🤖 Generated with Claude Code