We cannot remove support for Windows and macOS, that's silly. I have not followed all the branches and commits, so I'm not sure what the current problems are, but I know I was able to release all OSs last go around. I don't see why we need to rip out anything as fundamental.
Gary On Wed, Jun 29, 2022, 12:00 sebb <seb...@gmail.com> wrote: > 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 > >
