On 19 Dec 2023, at 12:45, Graham Leggett wrote:
> A search in the openldap source shows we don’t yet support the OpenSSL3
> provider OSSL_STORE_open() call, which takes a URL as a parameter.
>
> I’m happy to patch the openldap client to support this, would it make sen
On 03 Jan 2024, at 18:02, Howard Chu wrote:
>> https://bugs.openldap.org/show_bug.cgi?id=10149
>
> Looks a bit like a chicken'n'egg situation, why should anyone trust the
> connection that was used to
> retrieve certs and keys from the designated URI?
Not at all.
We’re referring to URIs
On 03 Jan 2024, at 18:23, Howard Chu wrote:
>> We’re referring to URIs known to crypto libraries, such as pkcs11 URLs (for
>> smartcard interfaces) and tpmkey URIs for TPM chips.
>
> Probably worth noting this in the manpages too then, that these are generally
> not internet URIs.
I’ve just
Hi all,
A search in the openldap source shows we don’t yet support the OpenSSL3
provider OSSL_STORE_open() call, which takes a URL as a parameter.
I’m happy to patch the openldap client to support this, would it make sense to
add a LDAP_OPT_X_TLS_URL option to ldap_option_set()?
Regards,
On 03 Apr 2024, at 13:03, Ondřej Kuzník wrote:
>> This has been historically vague - first off, what happens if an
>> attempt is made to call ldap_get_values() on binary data, do you get
>> an error, or garbage data? The source isn't giving me a clear answer.
>
> Hi Graham,
> in this case
Hi all,
Looking back in time to the definitions of ldap_get_values() and
ldap_get_values_len(), we are told that "If the attribute values are binary in
nature, and thus not suitable to be returned as an array of char *'s, the
ldap_get_values_len() routine can be used instead."
This has been
