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

[Arran Cudbard-Bell]

> It is also very gentle on the source; looking at lib/valuepair.c, four
> lines of code change would do wonders:
> 
> For the odd-number-of-characters around line 1100:
> 
> if ((strlen(cp) & 0x01) != 0) {
>      radlog(L_INFO, "The input superficially looks like it's
> hex-encoded, but it's not. Interpreting as literal octet stream.");
>      break;
> }
> 
> For the 0x prefix immediately after:
> 
> if (sscanf(cp, "%02x", &tmp) != 1) {
>  radlog(L_INFO, "The input superfially looks like it's hex-encoded, but
> it's not (character sequence %c%c is not in the hexadecimal alphabet).
> Interpreting as literal octet stream.", cp[0], cp[1]);
>  break;
> }
> 
> That solves the problem as good as it gets

Or you can define a local string attribute which you write the value to,
and use the base64 xlats to correctly 

I agree with your points, but it's a non-trivial behaviour change. 
Thinking about it more, although it's very unlikely hex and plaintext 
could get conflated with base64, it's still possible, and adding more 
implicit conversions makes it worse.

I'll let Alan decide about the firmness of hex decoding, but there is an
easier solution for you in 2.2.1.

Define a local string type attribute to hold the base64 encoded value.

update control {
	SSHA1-Password = "%{base64tohex:SSHA1-Password-Base64}"
}

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


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