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
