On Wed, 29 Jun 2022 at 16:11, Alex Remily <alex.rem...@gmail.com> wrote: > > I agree with Gary that we just don't support LibreSSL. To my knowledge > we've never advertised LibreSSL support, so I don't see it as an issue.
In that case AFAICT we will have to drop *all* support for macOS and Windows, as they both seem to default to LibreSSL. Note that adding support for LibreSSL was much easier for JNI, as it uses far fewer methods. Rather than checking the version, I changed the code to try OpenSSL 1.1 names first, then a fallback. That happens to work for 1.0.x and 1.1.x and LibreSSL. If you want to try it out, compare 16345bc (old) with 3ee3f65 (new) macOS fails on 16345bc because it now uses LibreSSL which has a different mix of names. I think it's vital we support JNI as far as possible (and the code already does with commit 3ee3f65). However JNA is more of a backstop, so the fact that it has stopped working for macOS and Windows is less of an issue. But I don't think we can say we are not supporting LibreSSL at all. > On Wed, Jun 29, 2022 at 10:21 AM sebb <seb...@gmail.com> wrote: > > > 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 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
