Identity servers do not always return standard Base64

[zecakeh]

As per matrix-org/matrix-spec#2060, Sydent can return both standard and url-safe base64-encoded public keys, but we only expect standard base64 so they fail to deserialize.

Note that both Synapse and Sydent use the python-unpaddedbase64 that decodes both indifferently.

This affects:

• All the endpoints in ruma_identity_service_api::keys
• RoomThirdPartyEventContent (which was reported in the Matrix Rust SDK room)

ruma_identity_service_api::invitation::store_invitation::v2::PublicKey should be affected too except that it doesn't use Base64 but String.

I am not sure if we should be using Base64 in this case. The problem that I see with this type is that it decodes the string during deserialization and reencodes it during serialization, which can be lossy (regarding to padding). But the server might store the base64-encoded key (this is was Sydent does), so it might not be able to find the key if it does not use the exact same string, on the endpoints to check the validity of the key.

It should be noted that RoomThirdPartyEventContent and ruma_identity_service_api::invitation::store_invitation::v2::Response use their own PublicKey type but it should probably be the same type.

[jplatte]

I propose we add struct StupidSydentCompatibleBase64(pub String); with relevant methods like fn decode(&self) -> Result<Vec<u8>, _>.

[zecakeh]

I like the type name. 😛

[zecakeh]

Note that state-res is also affected as we try to decode the base64 as part of the authorization check.

[zecakeh]

Actually, the only place that needs to be able to decode the string should be the homeserver, when it needs to check the signature.

That would mean that ruma_signatures::verify_json would need to be able to decode URL-safe base64. Should we do that unconditionnally?