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

[Arran Cudbard-Bell]

On 16 Jul 2013, at 15:54, John Dennis <jdennis at redhat.com> wrote:

> 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.?

You could use as part of the atribute name to indicate a cast.

<string>SSHA-Password := <hash>

But it's still awful.

Anyway Stefan's point about SSHA is correct. Maybe an option to turn off the normalisation done by rlm_pap would be useful.

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team