base32 padding inconsistency between client and server in HS v3 client auth preview
There seems to be some base32 padding tolerance inconsistency between client and server for the HS v3 client auth preview in tor-0.3.5.1-alpha
The server seems to accept base32-encoded client public keys padded with = signs to 56 characters in length and won't work otherwise (i.e., if = signs are removed), while the client would work without the padding (i.e., = signs removed) but will ignore the client's private key if the padding is present.
I don't think this affects how the feature works (which I haven't been able to test anyway because it doesn't seem to enforce authorization at this stage - it still seems to let everyone in), but at least it seems to affect which values are valid and allowed to be loaded when reading the config.
Trac:
Username: jchevali