On Wed, 29 Jun 2022 at 14:17, Gary Gregory <garydgreg...@gmail.com> wrote: > > The simple solution is to keep doing what we do now: only support OpenSSL > and not whatever Apple does with LibreSSL which may or may not be up to > date.
I think this also affects Windows. I don't have Windows box at present, but I have seen this on GH Actions. If you have a WIndows build, perhaps you could try these tests: mvn -q exec:java -D"exec.mainClass=org.apache.commons.crypto.Crypto" mvn -q exec:java -D"exec.mainClass=org.apache.commons.crypto.jna.OpenSslJna" The first one should show the SSL details; on GH the output includes: OpenSSL library loaded OK, version: 0x20000000 OpenSSL library info: LibreSSL 3.0.2 Additional OpenSSL_version(n) details: 4: OPENSSLDIR: "C:/Windows/libressl/ssl" The second test crashes with: java.lang.UnsatisfiedLinkError: Error looking up function 'ENGINE_load_rdrand': The specified procedure could not be found. isEnabled(): false initialisationError(): java.lang.UnsatisfiedLinkError: Error looking up function 'ENGINE_load_rdrand': The specified procedure could not be found. at com.sun.jna.Function.<init>(Function.java:252) ... It would certainly be easier to ignore the problem for now. > Gary > > On Wed, Jun 29, 2022, 06:59 sebb <seb...@gmail.com> wrote: > > > It looks like macOS 10.5+ and Windows (latest) use LibreSSL by default > > rather than OpenSSL. > > > > The LibreSSL API does not have the same functions as either 1.0.2 or > > 1.1.1, so needs its own JNA class. In particular it looks like > > ENGINE_load_rdrand is not present, nor is OpenSSL_version_num; 1.0.2 > > has the former only, and 1.1.1 has the latter only. > > > > This makes it hard to support JNA with the current design. > > It would require another OpenSsl<version>NativeJna class, and the > > parent class OpenSslNativeJna would need to use yet another condition > > in each of its methods. > > > > This is quite tedious and error-prone. > > > > Seems to me it would be better to use something like a set of > > singleton classes that implement the required methods. The appropriate > > one can then be initialised and used by OpenSslNativeJna to field the > > actual methods. i.e. replace the conditional logic with a static > > reference to the correct API interface instance. This should only > > affect non-public classes. > > > > Any other suggestions? > > > > Sebb > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
