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.
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 > >
