Hi Stefan, all, On Sat, Feb 25, 2017 at 9:37 PM, Stefan Seelmann <[email protected]> wrote: > On 02/25/2017 06:31 PM, Thilo-Alexander Ginkel wrote: >> 1. There is an existing BCrypt implementation for Java, jBCrypt [1, 2] >> licensed under the ISC license, which is compatible with the Apache >> License 2.0 according to [3]. Do you consider it acceptable to >> introduce a new dependency to support a new encryption algorithm? >> AFAICS the dependency would need to be added to >> org.apache.directory.api:api-ldap-model. > > In general that sounds ok. The library is minimal, contains only the one > BCrypt class, no further dependencies. (side-note: the same class is > meanwhile modified used in Spring Security [5]). Only question is if > additional paper work is required [4]? > > On the other hand, ApacheDS (but not the API) already uses Bouncycastle > dependency which also contains a BCrypt implementation.
one obstacle showed up when attempting to use jBCrypt from within the API: The original implementation does not come as an OSGi bundle causing the OSGi integration tests to fail. There is a fork [1], which adds OSGi support, but has been compiled with Java 1.8 target level. :-/ Would it be an option to "vendor" the class, i.e., copy it to the directory-shared repo? Alternatively, we could resort to using Bouncy Castle, but adding a Bouncy Castle dependency to the API just to get the BCrypt implementation feels somewhat wrong... > 3rd option: commons-codec has support for other Unix crypt variants, but > BCrypt is missing. Maybe it makes sense to add BCrypt there? I have no gut feeling how difficult and/or time consuming it would be to get the algorithm added to commons-codec, so I'm somewhat reluctant to involve a third project. ;-) But in theory that sounds like a sensible option. Thanks, Thilo [1] https://github.com/svenkubiak/jBCrypt
