I found another bug while testing ldap(1) to M$ AD.
Attributes like objectGUID are encoded as OCTET STRING, but are binary
data, which are not UTF-8 strings.
When looking at RFC4511 I found the following:
4.1.5. Attribute Value
A field of type AttributeValue is an OCTET STRING containing an
encoded attribute value. The attribute value is encoded according to
the LDAP-specific encoding definition of its corresponding syntax.
So we should not blindly utoa on an OCTET STRING.
Diff below alleviates the problems when comparing the output of
ldapsearch from OpenLDAP, but is probably horribly wrong.
Note that because of the current assumptions some values aren't printed
at all, because they contain NUL-characters in the string. The patch
below does not address this issue.
martijn@
Index: aldap.c
===================================================================
RCS file: /cvs/src/usr.bin/ldap/aldap.c,v
retrieving revision 1.5
diff -u -p -r1.5 aldap.c
--- aldap.c 12 Aug 2018 22:04:09 -0000 1.5
+++ aldap.c 22 Oct 2018 06:54:22 -0000
@@ -860,7 +860,9 @@ aldap_get_stringset(struct ber_element *
a = a->be_next, i++) {
ber_get_string(a, &s);
- ret[i] = utoa(s);
+ if ((ret[i] = calloc(a->be_len + 1, 1)) == NULL)
+ continue;
+ memcpy(ret[i], s, a->be_len);
}
ret[i + 1] = NULL;
