URL: https://github.com/freeipa/freeipa/pull/298 Title: #298: ipaldap: handle binary encoding option transparently
jcholast commented: """ `ipaldap` is not the proper place to handle this - it implements a (almost) generic LDAP client, not a 389 DS client, and as such should not contain any 389 DS specific hacks. The premise is that the server gets exactly what the user of `ipaldap` requested, and the user gets exactly what the server returned. The binary transfer option is currently handled in code of the affected commands. The next layer below is `baseldap`, which is where the handling should be moved to make it generic for all commands. Also note that the real bug in 389 DS is that it defines the attribute types to use octet string syntax, rather than the certificate syntax as defined in RFC 4523. It actually behaves correctly, not enforcing the binary transfer option on attribute types with octet string syntax. """ See the full comment at https://github.com/freeipa/freeipa/pull/298#issuecomment-268451076
-- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
