3.0.4: binary LDAP attributes

[Nikolai Kondrashov]

On 01/15/2015 04:45 AM, Arran Cudbard-Bell wrote:
>
>> On 7 Jan 2015, at 20:07, Nikolai Kondrashov <Nikolai.Kondrashov at redhat.com> wrote:
>>
>> Hi Alan,
>>
>> On 12/09/2014 03:02 PM, Alan DeKok wrote:
>>> On Dec 9, 2014, at 6:51 AM, Nikolai Kondrashov <Nikolai.Kondrashov at redhat.com> wrote:
>>>> They have noticed that binary LDAP values get truncated on embedded zero
>>>> characters (\0) in RADIUS replies, in radiusReplyMessage in particular.
>>>> I.e. for
>>>
>>>    Arran and I have spent the last two weeks fixing those issues.  The
>>>    server *never* dealt well with embedded zeros in “string” data.  Octets,
>>>    yes. Strings, no.
>>
>> We already have an integration test for strings with embedded zeros. We would
>> like to add a test for zeros in "binary" attributes.
>>
>> I'm not sure exactly what you mean by octets here. Is it attributes with
>> "octets" type in dictionaries? If so, are LDAP attributes supposed to contain
>> hex strings for them, and it is basically "00" bytes which were the problem?
>> Or could there be a direct binary representation for "octets"?
>
> IIRC there's still issues with embedded zeroes in string attributes, because
> they were going via pairparse value. I don't know if Alan fixed this, if he
> didn't, i'll try and get it sorted for 3.0.8.
>
> To test, insert binary data (with embedded zeroes) into any string attribute in LDAP
> then map the string attribute to an octets type attribute in the server.
>
> You should see that the entire attribute value is copied, embedded zeroes and all.
>
> Previously the copy would have stopped at the first embedded zero.
>
>> Is the "abinary" type affected?
>
> abinary is ascend binary filters. It's a way of packing filtering rules into a binary
> blob. abinary is expected to be in its presentation format (text) when entering the
> server from any route other than the RADIUS decoder, so no.
>
>> Could you perhaps suggest attribute names/types and LDAP attribute values to
>> test for?
>
> See above.

Thanks, Arran!
We've postponed the binary value testing for now, but I think we'll get around
to it. I'll forward this to our QE guy.

Nick