The options -h and -p got removed from client tools in commit
66af4cfd5d. However, they were still
present in the options[] array in several client tools source files. So,
if one of those tools got executed with -h or -p followed by a value,
this lead to the error "unrecognized option -", without mentioning
which option was problematic. Removing 'h' and 'p' from options[] fixes
this.
`rc` collects exit status all the way down but is not used at all? If `code`
comparison at exit is intended then there exists some path that leaves it in
garbage value, say when `ldap_whoami` or `ldap_cancel` fails.
The option string, e.g. '<oid>=:dn:' is parsed like a LDIF entry starting from
the '=' and replacing the '=' with a dummy variable 'x'. In this case, said
string is 'x:dn:', so the resulting effective value is 'dn:'. This also implies
that base64 values have to be passed in the form '<oid>=::<b64value>'.
Probably-Signed-off-by: Dave Bender <bender@benegon.com>
[yann.morin.1998@free.fr: patch was made by Dave, but he
forgot his SoB line, so I added it]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[Retrieved from:
https://git.buildroot.net/buildroot/tree/package/openldap/0001-fix_cross_strip.patch]
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
The spec says that upon StartTLS 'success', both TLS communications is
established on the octet following the Start TLS response (and the
request)... and that once one starts TLS communications, one can never
go back to LDAP without TLS. So if there's a TLS failure (whether as
part of TLS nego or later), LDAP communications cannot be continued
(without TLS).
Only ignoring LDAP errors (rc > 0) ensures that if TLS negotiation
fails, we don't attempt to send LDAP operations without TLS.
The LDIF output wasn't being explicitly flushed. In certain scenarios,
such as piping the output of a persistent ldapsearch to node.js v0.12
on Mac OS X 10.10.3, the output is unavailable to the process
consuming the search results until the stdio buffer fills (8192 bytes
for example). This can leave the tail end of persistent search results
in the buffer for a long time (until enough output has accumulated).
Explicitly call flush so that the output is immediately available.
