Alex, All: Thank you for your review Alex. I agree that LibreSSL could be out of scope here. But, FTR, here is what I found:
LibreSSL 2.8.3 does not seem to implement ENGINE_load_rdrand. https://www.libressl.org/ points to https://github.com/libressl-portable/openbsd and looking for ENGINE_load_rdrand: git log -S ENGINE_load_rdrand --oneline reveals: 7a713945c A few months back there was a big community fuss regarding direct-use of the intel RDRAND instruction. Consensus was RDRAND should probably only be used as an additional source of entropy in a mixer. 947b08e07 used for windows dll builds only adc55c5b9 resolve conflicts e728adc5e import OpenSSL-1.0.1c c15741c9f import OpenSSL-1.0.1c bbd40b4de import OpenSSL-1.0.1c Then: git diff 947b08e07 | grep "ENGINE_load_rdrand" Shows ENGINE_load_rdrand going away: - ENGINE_load_rdrand(); -void ENGINE_load_rdrand (void) -void ENGINE_load_rdrand (void) {} -void ENGINE_load_rdrand(void); - ENGINE_load_rdrand(); -void ENGINE_load_rdrand (void) -void ENGINE_load_rdrand (void) {} -void ENGINE_load_rdrand(void); in this commit: commit 947b08e07e10d9c522c7dd7e1db04096f9ab8f98 Author: miod <> Date: Mon Apr 14 18:31:08 2014 +0000 used for windows dll builds only Which according to https://www.libressl.org/releases.html might match up to a version in or after "LibreSSL 2.0.0 (Jul 11, 2014) - First LibreSSL release, based on OpenBSD 5.6 development snapshot." So that function might never have been in a released LibreSSL since there is no history on the page pre-2.0.0. Gary On Wed, Aug 26, 2020 at 9:39 PM Alex Remily <alex.rem...@gmail.com> wrote: > Gary, > > I tested the most recent jar against Mac x86_64 and Linux x86_64 > OpenSSL version 1.1.1. The unit tests passed and the main function > ran to completion with expected output. I'll try to get to the > Windows x86_64 test tomorrow and the OpenSSL 1.0 tests on the same > three architectures by the end of the weekend. > > I'd like to get to the bottom of this UnsatisfiedLinkError in the main > function. I hope it's not a code issue. It may be an issue of the > JNI libraries loading the libcrypto library associated with LibreSSL. > I don't use LibreSSL and about half the Mac tests skip when run > against it. From my perspective it is out of scope. The JNI > libraries look for the OpenSSL_version function (API 1.1) or the > SSLeay_version function (API 1.0) only after a call to > OpenSSL_version_num() or SSLeay() to determine the underlying OpenSSL > API (1.0 or 1.1). If the initial calls both return null (no function > found) then an error is supposed to be thrown. It may be that the > LibreSSL uses a different specification to identify the library > version than OpenSSL, and it's causing the JNI to look for a function > that doesn't exist in the underlying OpenSSL libcrypto, i.e., it's > looking for a 1.1 function in a 1.0 library. Can you test with the > libcrypto that shipped with OpenSSL? > > I'm not sure why Bruno is getting the same error if he doesn't have > OpenSSL or LibreSSL installed. The JNI libraries should error out > before getting to that point. I'm hoping to learn more about his > configuration. > > Alex > > On Mon, Aug 24, 2020 at 3:18 PM Gary Gregory <garydgreg...@gmail.com> > wrote: > > > > On Mon, Aug 24, 2020 at 12:10 PM Geoffrey Blake < > geoffrey.w.bl...@gmail.com> > > wrote: > > > > > Hi Gary, > > > > > > Which snapshots have Linux binaries in them? As far as I can tell, > the > > > recent ones uploaded are Mac only, and the one from 8/18 had that weird > > > /native/native directory issue. For what it's worth, Mac binaries are > > > working on my laptop, though I'm using LibreSSL which is what comes > > > installed by default. > > > > > > > Whops, please try again, I deployed a fresh snapshot containing: > > > > 22456 01-22-2020 15:10 > > org/apache/commons/crypto/native/Linux/aarch64/libcommons-crypto.so > > 21880 01-22-2020 15:10 > > org/apache/commons/crypto/native/Linux/arm/libcommons-crypto.so > > 17800 01-22-2020 15:10 > > org/apache/commons/crypto/native/Linux/armhf/libcommons-crypto.so > > 21856 01-22-2020 15:10 > > org/apache/commons/crypto/native/Linux/x86/libcommons-crypto.so > > 22552 01-22-2020 15:10 > > org/apache/commons/crypto/native/Linux/x86_64/libcommons-crypto.so > > 23116 01-22-2020 15:10 > > org/apache/commons/crypto/native/Mac/x86_64/libcommons-crypto.jnilib > > 25088 01-22-2020 15:10 > > org/apache/commons/crypto/native/Windows/x86/commons-crypto.dll > > 28160 01-22-2020 15:10 > > org/apache/commons/crypto/native/Windows/x86_64/commons-crypto.dll > > > > I just removed OpenSSL 1.1.1g from my PATH, I now have LibreSSL 2.8.3. > > > > I am testing from the my local repo folder with: > > > > java -cp target/classes -Dcommons.crypto.lib.tempdir=target > > -Dcommons.crypto.debug=true org.apache.commons.crypto.Crypto > > Apache Commons Crypto 1.1.0-SNAPSHOT > > Extracting > > '/org/apache/commons/crypto/native/Mac/x86_64/libcommons-crypto.jnilib' > to > > > '/Users/garydgregory/git/commons-crypto/target/commons-crypto-c7da6852-0a52-465b-be2b-ec39b240e7f0-libcommons-crypto.jnilib'... > > Extracted > > '/org/apache/commons/crypto/native/Mac/x86_64/libcommons-crypto.jnilib' > to > > > '/Users/garydgregory/git/commons-crypto/target/commons-crypto-c7da6852-0a52-465b-be2b-ec39b240e7f0-libcommons-crypto.jnilib': > > 23,116 bytes. > > Validating > > > '/Users/garydgregory/git/commons-crypto/target/commons-crypto-c7da6852-0a52-465b-be2b-ec39b240e7f0-libcommons-crypto.jnilib'... > > Native code loaded OK: 1.1.0-SNAPSHOT > > Native name: Apache Commons Crypto > > Native built: Aug 23 2020 > > Exception in thread "main" java.lang.UnsatisfiedLinkError: > OpenSSL_version > > at org.apache.commons.crypto.OpenSslInfoNative.OpenSSL(Native Method) > > at org.apache.commons.crypto.Crypto.main(Crypto.java:144) > > > > Same issue with using -cp target/commons-crypto-1.1.0-SNAPSHOT.jar > instead > > of target/class which is not a surprise. > > > > Which version of LibreSSL do you use? > > > > Gary > > > > > > > -Geoff > > > > > > On Sun, Aug 23, 2020 at 9:08 PM Alex Remily <alex.rem...@gmail.com> > wrote: > > > > > > > FWIW I have the same basic setup. The original LibreSSL is still > > > > installed and I used homebrew to install the various versions of > > > > OpenSSL, which I put first on my PATH. I don't routinely call the > > > > main function when I test, I usually just run the unit tests, so it's > > > > quite possible this is an error that's been overlooked. If it is a > > > > config issue with the Mac, I expect it will be one common to all Mac > > > > users that we'll need to document. > > > > > > > > On Sun, Aug 23, 2020 at 9:50 PM Gary Gregory <garydgreg...@gmail.com > > > > > > wrote: > > > > > > > > > > I do have LibreSSL but I used homebrew to install OpenSSL 1.1.1g > which > > > I > > > > > put first on the PATH. Maybe something is off in my setup... > > > > > > > > > > Gary > > > > > > > > > > On Sun, Aug 23, 2020, 21:46 Alex Remily <alex.rem...@gmail.com> > wrote: > > > > > > > > > > > Gary, > > > > > > > > > > > > I'll have a look. I did the 1.1 support stuff and I'm familiar > with > > > > > > that class and that error, although I don't recall seeing that > > > > > > specific error in that class. The JNI libraries check the > OpenSSL > > > > > > version at runtime, but maybe a compile time dependency got > through. > > > > > > > > > > > > Out of curiosity, I assume you also have LibreSSL installed? I > have > > > > > > run into issues on my Mac with which librypto gets loaded by the > JNI > > > > > > libraries during the dlsym. I wonder if the runtime is > referring to > > > > > > one version and the JNI library is loading another. > > > > > > > > > > > > Anyway, I'll poke around and see what I can figure out. I'll > try to > > > > > > get to it with the rest of the testing this week. > > > > > > > > > > > > Alex > > > > > > > > > > > > On Sun, Aug 23, 2020 at 11:18 AM Gary Gregory < > > > garydgreg...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > > I wondering if anyone can confirm the following issue and/or > help > > > > explain > > > > > > > it, on MacOS 10.15.6 with OpenSSL 1.1.1g, running: > > > > > > > > > > > > > > mvn package > > > > > > > > > > > > > > then: > > > > > > > > > > > > > > java -Xdiag -Xcheck:jni -cp target/classes > > > > > > > -Dcommons.crypto.lib.tempdir=target/ > > > org.apache.commons.crypto.Crypto > > > > > > > WARNING in native method: JNI call made without checking > exceptions > > > > when > > > > > > > required to from CallStaticObjectMethod > > > > > > > WARNING in native method: JNI call made without checking > exceptions > > > > when > > > > > > > required to from CallObjectMethod > > > > > > > Apache Commons Crypto 1.1.0-SNAPSHOT > > > > > > > Native code loaded OK: 1.1.0-SNAPSHOT > > > > > > > Native name: Apache Commons Crypto > > > > > > > Native built: Aug 22 2020 > > > > > > > Exception in thread "main" java.lang.UnsatisfiedLinkError: > > > > > > OpenSSL_version > > > > > > > at org.apache.commons.crypto.OpenSslInfoNative.OpenSSL(Native > > > > Method) > > > > > > > at org.apache.commons.crypto.Crypto.main(Crypto.java:144) > > > > > > > > > > > > > > I wonder if we have issues on 1.1.x vs 1.0.x. > > > > > > > > > > > > > > My versions: > > > > > > > > > > > > > > openssl version > > > > > > > OpenSSL 1.1.1g 21 Apr 2020 > > > > > > > > > > > > > > mvn -version > > > > > > > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) > > > > > > > Maven home: /opt/apache-maven-3.6.3 > > > > > > > Java version: 1.8.0_265, vendor: AdoptOpenJDK, runtime: > > > > > > > > > > > > /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre > > > > > > > Default locale: en_US, platform encoding: UTF-8 > > > > > > > OS name: "mac os x", version: "10.15.6", arch: "x86_64", > family: > > > > "mac" > > > > > > > > > > > > > > Thank you, > > > > > > > Gary > > > > > > > > > > > > > > > > > > > > > On Sat, Aug 22, 2020 at 7:48 PM Gary Gregory < > > > garydgreg...@gmail.com > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > I intent on creating a release candidate for Commons Crypto > soon. > > > > > > > > > > > > > > > > I pushed a snapshot today which contains native binaries for > > > > Windows 32 > > > > > > > > and 64, Linux 32 and 64, Mac 64, and ARM and ARM HF. > > > > > > > > > > > > > > > > Please help testing these on whatever platforms you may have > > > > access to. > > > > > > > > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > 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 > >
