2.x.x (and earier?): yet another decoding SSHA issue

[John Dennis]

On 07/16/2013 09:40 AM, Alan DeKok wrote:
> Arran Cudbard-Bell wrote:
> 
>> SSHA1-Password will then hold the raw octet value of the hash. Unfortunately
>> I believe that rlm_pap has it's own normalization logic, 
>> so may still attempt to decode the raw octets as hex or base64 *sigh*. 
> 
>   Only if the data is longer than the length of the binary hash.
> 
>   i.e.
> 
> - length == length of hash ---> DONE
> 
> - length is 4/3 (or so) + other stuff.. --> base64
> 
> - starts with "0x" and length is 2x the length of the hash --> hex
> 
>   It should be pretty fail-safe.

I'm not a fan of heuristics, every time you think you've got the logic
nailed down some corner case will prove you wrong. Plus it's magical, I
don't like magic, I prefer explicit well defined behavior. Plus in this
instance the behavior is tied to well known digests, what about all the
other places where binary conversion from text encoding might be called
for? Shouldn't everything obey the same rules?

Is it possible to add a qualifier indicating the format of the item,
e.g. base64, hex, etc.?

John