On 16 Jul 2013, at 15:54, John Dennis <jdennis@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@freeradius.org> FreeRADIUS Development Team