[ldap-sdk-announce] UnboundID LDAP SDK for Java 6.0.5

[Neil W. <nei...@pi...>]

We have just released version 6.0.5 of the UnboundID LDAP SDK for Java
<https://github.com/pingidentity/ldapsdk>. It is available for download
from GitHub <https://github.com/pingidentity/ldapsdk/releases> and
SourceForge <https://sourceforge.net/projects/ldap-sdk/files/>, and it is
available in the Maven Central Repository
<https://search.maven.org/search?q=g:com.unboundid%20AND%20a:unboundid-ldapsdk&core=gav>.
You can find the release notes at
https://docs.ldap.com/ldap-sdk/docs/release-notes.html, but here’s a
summary of the changes included in this version:

General Updates:


   -

   We fixed an issue that could occasionally cause the LDAP SDK to hide the
   actual cause of a StartTLS failure by using information from a second, less
   useful exception.



   -

   We fixed an issue that could cause the ldifsearch tool to display a
   malformed message when the first unnamed trailing argument was expected to
   be a search filter but could not be parsed as a valid filter.



   -

   We improved support for validating and comparing values using the
   telephone number syntax. Previously, we used a loose interpretation of the
   specification, which would consider any printable string (including strings
   without any digits) to be valid, and would only ignore spaces and hyphens
   when comparing values. You can now configure varying levels of strictness
   (either programmatically or using system properties), including requiring
   at least one digit or strict conformance to the X.520 specification. You
   can also configure it to ignore all non-digit characters when comparing
   values, and this is now the default behavior.



   -

   We fixed a bug in which the ldapcompare tool did not properly close its
   output file if one was configured. The output file does get automatically
   closed when the tool exits so it’s not an issue when running ldapcompare
   from the command line, but this can cause problems if the tool is invoked
   programmatically from another application.



   -

   We fixed an issue with the tool properties file created using the
   --generatePropertiesFile argument in command-line tools that support it.
   The generated properties file did not properly escape backslash, carriage
   return, line feed, or form feed characters.


Updates Specific to Use With the Ping Identity Directory Server:


   -

   We added support for encoding controls to JSON objects, and for decoding
   JSON objects as controls. There is a generic JSON representation that will
   work for any type of control (in which the value is provided as the
   base64-encoded representation of the raw value used in the LDAP
   representation of the control), but most controls provided as part of the
   LDAP SDK also support a more user-friendly representation in which the
   components of the value are represented in a nested JSON object.



   -

   We added client-side support for a new JSON-formatted request control
   that can be used to send request controls to a Ping Identity Directory
   Server with the controls encoded as JSON objects rather than a raw LDAP
   representation. We also added support for a JSON-formatted response control
   that can be used to receive JSON-encoded response controls from the server.



   -

   We updated the ldapsearch and ldapmodify command-line tools to add a
   --useJSONFormattedRequestControls argument that will cause any request
   controls to be sent using a JSON-formatted request control, and it will
   cause any response controls returned by the server to be embedded in a
   JSON-formatted response control.



   -

   We fixed an issue with the way that the parallel-update tool created
   assured replication request controls when an explicit local or remote
   assurance level was specified. Previously, it would only specify a minimum
   assurance level without specifying a maximum level, which could cause the
   server to use a higher assurance level than requested by the client.



   -

   We updated the topology registry trust manager to allow trusting a
   certificate chain if either the peer certificate or any of its issuers is
   found in the server’s topology registry. Previously, it would only trust a
   certificate chain if the peer certificate itself was found in the topology
   registry, and having an issuer certificate was not sufficient. The former
   behavior is still available with a configuration option.



   -

   We updated the topology registry trust manager to make it possible to
   ignore the certificate validity window for peer and issuer certificates.
   The validity window is still respected by default, but if the trust manager
   is configured to ignore it, then a certificate chain may be trusted even if
   the peer or an issuer certificate is expired or not yet valid.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._