You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@commons.apache.org by Gary Gregory <ga...@gmail.com> on 2020/08/22 23:48:58 UTC

[Crypto] requesting help testing native binaries

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

Re: [Crypto] requesting help testing native binaries

Posted by Geoffrey Blake <ge...@gmail.com>.

From my end, that latest jar from 8/24 is working on AArch64 with a simple
test on OpenSSL 1.1.x and OpenSSL 1.0.x based distros.  I'm now trying it
out on Spark to see if it links up with OpenSSL instead of the JCE.

-Geoff

On Tue, Aug 25, 2020 at 9:47 AM Alex Remily <al...@gmail.com> wrote:

> Bruno,
>
> Are you certain that OpenSSL isn't installed on your Windows box?
> It's supposed to fail before it looks for "OpenSSL_version" if there's
> no OpenSSL installed.
>
> Alex
>
> On Tue, Aug 25, 2020 at 2:37 AM Bruno P. Kinoshita <ki...@apache.org>
> wrote:
> >
> > Hi Gary,
> >
> > I did a mvn clean test install from master, and it worked OK on my Linux
> box. Then grabbed the snapshot from
> https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-crypto/1.1.0-SNAPSHOT/
> (the latest), and ran the command to test it successfully:
> >
> > $ java -cp commons-crypto-1.1.0-20200824.190246-21.jar
> org.apache.commons.crypto.Crypto
> > Apache Commons Crypto 1.1.0-SNAPSHOT
> > Native code loaded OK: 1.1.0-SNAPSHOT
> > Native name: Apache Commons Crypto
> > Native built: Aug 23 2020
> > OpenSSL library loaded OK, version: 0x1010107f
> > OpenSSL library info: OpenSSL 1.1.1g  21 Apr 2020
> > Random instance created OK:
> org.apache.commons.crypto.random.OpenSslCryptoRandom@2a84aee7
> > Cipher AES/CTR/NoPadding instance created OK:
> org.apache.commons.crypto.cipher.OpenSslCipher@1fb3ebeb
> > Additional OpenSSL_version(n) details:
> > 1: compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall
> -Wa,--noexecstack -g -O2
> -fdebug-prefix-map=/build/openssl-InlZB1/openssl-1.1.1g=.
> -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong
> -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DL_ENDIAN
> -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
> -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
> -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM
> -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG
> -Wdate-time -D_FORTIFY_SOURCE=2
> > 2: built on: Tue Apr 21 14:30:52 2020 UTC
> > 3: platform: debian-amd64
> > 4: OPENSSLDIR: "/usr/lib/ssl"
> > 5: ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1"
> >
> >
> > Alas on my Windows box it failed, probably due to missing OpenSSL.
> >
> > >java -cp commons-crypto-1.1.0-20200824.190246-21.jar
> org.apache.commons.crypto.Crypto
> > Apache Commons Crypto 1.1.0-SNAPSHOT
> > Native code loaded OK: 1.1.0-SNAPSHOT
> > Native name: Apache Commons Crypto
> > Native built: Aug 16 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)
> >
> >
> > And I don't dare to install anything on this box right now, as IT
> support is taking a bit longer to reply (it's a $work laptop) due to the
> lockdown.
> >
> > At least it appears to be working OK for Linux 64.
> >
> > Hope that helps
> >
> > Bruno
> >
> >
> >
> > On Monday, 24 August 2020, 1:53:12 am NZST, Gary Gregory <
> garydgregory@gmail.com> wrote:
> >
> >
> >
> >
> >
> > Building the binaries can be tricky, be warned.
> >
> > The trickiest to validate are aarch64, arm, and artmhf. All help is
> welcome
> > of course.
> >
> > A smoke test would be to make sure that the native code from the SNAPSHOT
> > jar from our SNAPSHOT repo can be loaded, for example, by calling from
> the
> > command line the class org.apache.commons.crypto.Crypto
> >
> > For example, on:
> >
> > Linux dfd13586af7a 4.19.76-linuxkit #1 SMP Tue May 26 11:42:35 UTC 2020
> > x86_64 x86_64 x86_64 GNU/Linux
> >
> > java -cp target/classes org.apache.commons.crypto.Crypto
> >
> > should output:
> >
> > Apache Commons Crypto 1.1.0-SNAPSHOT
> > Native code loaded OK: 1.1.0-SNAPSHOT
> > Native name: Apache Commons Crypto
> > Native built: Aug 23 2020
> > OpenSSL library loaded OK, version: 0x1000106f
> > OpenSSL library info: OpenSSL 1.0.1f 6 Jan 2014
> > Random instance created OK:
> > org.apache.commons.crypto.random.OpenSslCryptoRandom@355da254
> > Cipher instance created OK:
> > org.apache.commons.crypto.cipher.OpenSslCipher@6ff3c5b5
> > Additional OpenSSL_version(n) details:
> > 1: not available
> > 2: compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT
> > -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2
> > -fstack-protector --param=ssp-buffer-size=4 -Wformat
> > -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions
> > -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2
> > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
> > -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
> > -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
> > 3: built on: Tue Dec  4 20:09:18 UTC 2018
> > 4: platform: debian-amd64
> > 5: OPENSSLDIR: "/usr/lib/ssl"
> >
> > Gary
> >
> > On Sun, Aug 23, 2020 at 2:23 AM Bruno P. Kinoshita <ki...@apache.org>
> wrote:
> >
> > > Hi Gary,
> > >
> > > I might be able to test on Win64 and Linux64 this week. You mentioned
> > > snapshots… what is the easiest way to test them? Run some code using
> the
> > > code of the snapshots, or perhaps run the build+tests from a
> tag/commit?
> > >
> > >
> > > Cheers
> > > Bruno
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Sunday, 23 August 2020, 11:49:21 am NZST, Gary Gregory <
> > > garydgregory@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-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: [Crypto] requesting help testing native binaries

Posted by Alex Remily <al...@gmail.com>.

Bruno,

Are you certain that OpenSSL isn't installed on your Windows box?
It's supposed to fail before it looks for "OpenSSL_version" if there's
no OpenSSL installed.

Alex

On Tue, Aug 25, 2020 at 2:37 AM Bruno P. Kinoshita <ki...@apache.org> wrote:
>
> Hi Gary,
>
> I did a mvn clean test install from master, and it worked OK on my Linux box. Then grabbed the snapshot from https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-crypto/1.1.0-SNAPSHOT/ (the latest), and ran the command to test it successfully:
>
> $ java -cp commons-crypto-1.1.0-20200824.190246-21.jar org.apache.commons.crypto.Crypto
> Apache Commons Crypto 1.1.0-SNAPSHOT
> Native code loaded OK: 1.1.0-SNAPSHOT
> Native name: Apache Commons Crypto
> Native built: Aug 23 2020
> OpenSSL library loaded OK, version: 0x1010107f
> OpenSSL library info: OpenSSL 1.1.1g  21 Apr 2020
> Random instance created OK: org.apache.commons.crypto.random.OpenSslCryptoRandom@2a84aee7
> Cipher AES/CTR/NoPadding instance created OK: org.apache.commons.crypto.cipher.OpenSslCipher@1fb3ebeb
> Additional OpenSSL_version(n) details:
> 1: compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-InlZB1/openssl-1.1.1g=. -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
> 2: built on: Tue Apr 21 14:30:52 2020 UTC
> 3: platform: debian-amd64
> 4: OPENSSLDIR: "/usr/lib/ssl"
> 5: ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1"
>
>
> Alas on my Windows box it failed, probably due to missing OpenSSL.
>
> >java -cp commons-crypto-1.1.0-20200824.190246-21.jar org.apache.commons.crypto.Crypto
> Apache Commons Crypto 1.1.0-SNAPSHOT
> Native code loaded OK: 1.1.0-SNAPSHOT
> Native name: Apache Commons Crypto
> Native built: Aug 16 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)
>
>
> And I don't dare to install anything on this box right now, as IT support is taking a bit longer to reply (it's a $work laptop) due to the lockdown.
>
> At least it appears to be working OK for Linux 64.
>
> Hope that helps
>
> Bruno
>
>
>
> On Monday, 24 August 2020, 1:53:12 am NZST, Gary Gregory <ga...@gmail.com> wrote:
>
>
>
>
>
> Building the binaries can be tricky, be warned.
>
> The trickiest to validate are aarch64, arm, and artmhf. All help is welcome
> of course.
>
> A smoke test would be to make sure that the native code from the SNAPSHOT
> jar from our SNAPSHOT repo can be loaded, for example, by calling from the
> command line the class org.apache.commons.crypto.Crypto
>
> For example, on:
>
> Linux dfd13586af7a 4.19.76-linuxkit #1 SMP Tue May 26 11:42:35 UTC 2020
> x86_64 x86_64 x86_64 GNU/Linux
>
> java -cp target/classes org.apache.commons.crypto.Crypto
>
> should output:
>
> Apache Commons Crypto 1.1.0-SNAPSHOT
> Native code loaded OK: 1.1.0-SNAPSHOT
> Native name: Apache Commons Crypto
> Native built: Aug 23 2020
> OpenSSL library loaded OK, version: 0x1000106f
> OpenSSL library info: OpenSSL 1.0.1f 6 Jan 2014
> Random instance created OK:
> org.apache.commons.crypto.random.OpenSslCryptoRandom@355da254
> Cipher instance created OK:
> org.apache.commons.crypto.cipher.OpenSslCipher@6ff3c5b5
> Additional OpenSSL_version(n) details:
> 1: not available
> 2: compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT
> -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2
> -fstack-protector --param=ssp-buffer-size=4 -Wformat
> -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions
> -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
> -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
> 3: built on: Tue Dec  4 20:09:18 UTC 2018
> 4: platform: debian-amd64
> 5: OPENSSLDIR: "/usr/lib/ssl"
>
> Gary
>
> On Sun, Aug 23, 2020 at 2:23 AM Bruno P. Kinoshita <ki...@apache.org> wrote:
>
> > Hi Gary,
> >
> > I might be able to test on Win64 and Linux64 this week. You mentioned
> > snapshots… what is the easiest way to test them? Run some code using the
> > code of the snapshots, or perhaps run the build+tests from a tag/commit?
> >
> >
> > Cheers
> > Bruno
> >
> >
> >
> >
> >
> >
> > On Sunday, 23 August 2020, 11:49:21 am NZST, Gary Gregory <
> > garydgregory@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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [Crypto] requesting help testing native binaries

Posted by "Bruno P. Kinoshita" <ki...@apache.org>.

Hi Gary,

I did a mvn clean test install from master, and it worked OK on my Linux box. Then grabbed the snapshot from https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-crypto/1.1.0-SNAPSHOT/ (the latest), and ran the command to test it successfully:

$ java -cp commons-crypto-1.1.0-20200824.190246-21.jar org.apache.commons.crypto.Crypto
Apache Commons Crypto 1.1.0-SNAPSHOT
Native code loaded OK: 1.1.0-SNAPSHOT
Native name: Apache Commons Crypto
Native built: Aug 23 2020
OpenSSL library loaded OK, version: 0x1010107f
OpenSSL library info: OpenSSL 1.1.1g  21 Apr 2020
Random instance created OK: org.apache.commons.crypto.random.OpenSslCryptoRandom@2a84aee7
Cipher AES/CTR/NoPadding instance created OK: org.apache.commons.crypto.cipher.OpenSslCipher@1fb3ebeb
Additional OpenSSL_version(n) details:
1: compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-InlZB1/openssl-1.1.1g=. -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
2: built on: Tue Apr 21 14:30:52 2020 UTC
3: platform: debian-amd64
4: OPENSSLDIR: "/usr/lib/ssl"
5: ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1"

Alas on my Windows box it failed, probably due to missing OpenSSL.

>java -cp commons-crypto-1.1.0-20200824.190246-21.jar org.apache.commons.crypto.Crypto
Apache Commons Crypto 1.1.0-SNAPSHOT
Native code loaded OK: 1.1.0-SNAPSHOT
Native name: Apache Commons Crypto
Native built: Aug 16 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)

And I don't dare to install anything on this box right now, as IT support is taking a bit longer to reply (it's a $work laptop) due to the lockdown.

At least it appears to be working OK for Linux 64.

Hope that helps

Bruno

On Monday, 24 August 2020, 1:53:12 am NZST, Gary Gregory <ga...@gmail.com> wrote: 

Building the binaries can be tricky, be warned.

The trickiest to validate are aarch64, arm, and artmhf. All help is welcome
of course.

A smoke test would be to make sure that the native code from the SNAPSHOT
jar from our SNAPSHOT repo can be loaded, for example, by calling from the
command line the class org.apache.commons.crypto.Crypto

For example, on:

Linux dfd13586af7a 4.19.76-linuxkit #1 SMP Tue May 26 11:42:35 UTC 2020
x86_64 x86_64 x86_64 GNU/Linux

java -cp target/classes org.apache.commons.crypto.Crypto

should output:

Apache Commons Crypto 1.1.0-SNAPSHOT
Native code loaded OK: 1.1.0-SNAPSHOT
Native name: Apache Commons Crypto
Native built: Aug 23 2020
OpenSSL library loaded OK, version: 0x1000106f
OpenSSL library info: OpenSSL 1.0.1f 6 Jan 2014
Random instance created OK:
org.apache.commons.crypto.random.OpenSslCryptoRandom@355da254
Cipher instance created OK:
org.apache.commons.crypto.cipher.OpenSslCipher@6ff3c5b5
Additional OpenSSL_version(n) details:
1: not available
2: compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT
-DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2
-fstack-protector --param=ssp-buffer-size=4 -Wformat
-Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions
-Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
-DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
3: built on: Tue Dec  4 20:09:18 UTC 2018
4: platform: debian-amd64
5: OPENSSLDIR: "/usr/lib/ssl"

Gary

On Sun, Aug 23, 2020 at 2:23 AM Bruno P. Kinoshita <ki...@apache.org> wrote:

> Hi Gary,
>
> I might be able to test on Win64 and Linux64 this week. You mentioned
> snapshots… what is the easiest way to test them? Run some code using the
> code of the snapshots, or perhaps run the build+tests from a tag/commit?
>
>
> Cheers
> Bruno
>
>
>
>
>
>
> On Sunday, 23 August 2020, 11:49:21 am NZST, Gary Gregory <
> garydgregory@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [Crypto] requesting help testing native binaries

Posted by Gary Gregory <ga...@gmail.com>.

On Sun, Aug 23, 2020 at 10:46 AM Xeno Amess <xe...@gmail.com> wrote:

> Got it.
> I will explain my plan first.
> First, I will write a maven-plugin today.
> The maven plugin can accept two parameters, one be repo git url, the other
> be test codes relatice dir.
> When the plugin invoke (at phase prepare-test-source), it will use jgit to
> clone the repo you set, and copy its test files into generated-test-sources
> folder.
> Then all tests in that repo will invoke one by one.
> After that, I will write an repo (named commons-crypto-test or something)
> and use that plugin, and use commons-crypto's snapshot as dependency.
> After that, I will write a set of github actions to run this repo's build.
>
> Will this help?
>

I don't quite see how but I am obviously not comprehending your plan.

Gary


>
> Gary Gregory <ga...@gmail.com> 于2020年8月23日周日 下午10:40写道：
>
> > The Apache snapshot repository is here:
> > https://repository.apache.org/snapshots/
> > You just need a repository entry in your POM pointing to it in order for
> > Maven to resolve versions postfixed with "-SNAPSHOT".
> >
> > Gary
> >
> > On Sun, Aug 23, 2020 at 10:31 AM Xeno Amess <xe...@gmail.com> wrote:
> >
> > > Hi Gary.
> > > Where is the snapshot jar?
> > > Is it at oss snapshot center?
> > > If so, then I will have a very, very tricky way to test it,
> > > and that test is reusable.
> > >
> > >
> > > Gary Gregory <ga...@gmail.com> 于2020年8月23日周日 下午9:53写道：
> > >
> > > > Building the binaries can be tricky, be warned.
> > > >
> > > > The trickiest to validate are aarch64, arm, and artmhf. All help is
> > > welcome
> > > > of course.
> > > >
> > > > A smoke test would be to make sure that the native code from the
> > SNAPSHOT
> > > > jar from our SNAPSHOT repo can be loaded, for example, by calling
> from
> > > the
> > > > command line the class org.apache.commons.crypto.Crypto
> > > >
> > > > For example, on:
> > > >
> > > > Linux dfd13586af7a 4.19.76-linuxkit #1 SMP Tue May 26 11:42:35 UTC
> 2020
> > > > x86_64 x86_64 x86_64 GNU/Linux
> > > >
> > > > java -cp target/classes org.apache.commons.crypto.Crypto
> > > >
> > > > should output:
> > > >
> > > > Apache Commons Crypto 1.1.0-SNAPSHOT
> > > > Native code loaded OK: 1.1.0-SNAPSHOT
> > > > Native name: Apache Commons Crypto
> > > > Native built: Aug 23 2020
> > > > OpenSSL library loaded OK, version: 0x1000106f
> > > > OpenSSL library info: OpenSSL 1.0.1f 6 Jan 2014
> > > > Random instance created OK:
> > > > org.apache.commons.crypto.random.OpenSslCryptoRandom@355da254
> > > > Cipher instance created OK:
> > > > org.apache.commons.crypto.cipher.OpenSslCipher@6ff3c5b5
> > > > Additional OpenSSL_version(n) details:
> > > > 1: not available
> > > > 2: compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT
> > > > -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2
> > > > -fstack-protector --param=ssp-buffer-size=4 -Wformat
> > > > -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions
> > > > -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int
> > -DOPENSSL_IA32_SSE2
> > > > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
> > > > -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
> > > > -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
> > > > 3: built on: Tue Dec  4 20:09:18 UTC 2018
> > > > 4: platform: debian-amd64
> > > > 5: OPENSSLDIR: "/usr/lib/ssl"
> > > >
> > > > Gary
> > > >
> > > > On Sun, Aug 23, 2020 at 2:23 AM Bruno P. Kinoshita <kinow@apache.org
> >
> > > > wrote:
> > > >
> > > > > Hi Gary,
> > > > >
> > > > > I might be able to test on Win64 and Linux64 this week. You
> mentioned
> > > > > snapshots… what is the easiest way to test them? Run some code
> using
> > > the
> > > > > code of the snapshots, or perhaps run the build+tests from a
> > > tag/commit?
> > > > >
> > > > >
> > > > > Cheers
> > > > > Bruno
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Sunday, 23 August 2020, 11:49:21 am NZST, Gary Gregory <
> > > > > garydgregory@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-unsubscribe@commons.apache.org
> > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: [Crypto] requesting help testing native binaries

Posted by Xeno Amess <xe...@gmail.com>.

Got it.
I will explain my plan first.
First, I will write a maven-plugin today.
The maven plugin can accept two parameters, one be repo git url, the other
be test codes relatice dir.
When the plugin invoke (at phase prepare-test-source), it will use jgit to
clone the repo you set, and copy its test files into generated-test-sources
folder.
Then all tests in that repo will invoke one by one.
After that, I will write an repo (named commons-crypto-test or something)
and use that plugin, and use commons-crypto's snapshot as dependency.
After that, I will write a set of github actions to run this repo's build.

Will this help?


Gary Gregory <ga...@gmail.com> 于2020年8月23日周日 下午10:40写道：

> The Apache snapshot repository is here:
> https://repository.apache.org/snapshots/
> You just need a repository entry in your POM pointing to it in order for
> Maven to resolve versions postfixed with "-SNAPSHOT".
>
> Gary
>
> On Sun, Aug 23, 2020 at 10:31 AM Xeno Amess <xe...@gmail.com> wrote:
>
> > Hi Gary.
> > Where is the snapshot jar?
> > Is it at oss snapshot center?
> > If so, then I will have a very, very tricky way to test it,
> > and that test is reusable.
> >
> >
> > Gary Gregory <ga...@gmail.com> 于2020年8月23日周日 下午9:53写道：
> >
> > > Building the binaries can be tricky, be warned.
> > >
> > > The trickiest to validate are aarch64, arm, and artmhf. All help is
> > welcome
> > > of course.
> > >
> > > A smoke test would be to make sure that the native code from the
> SNAPSHOT
> > > jar from our SNAPSHOT repo can be loaded, for example, by calling from
> > the
> > > command line the class org.apache.commons.crypto.Crypto
> > >
> > > For example, on:
> > >
> > > Linux dfd13586af7a 4.19.76-linuxkit #1 SMP Tue May 26 11:42:35 UTC 2020
> > > x86_64 x86_64 x86_64 GNU/Linux
> > >
> > > java -cp target/classes org.apache.commons.crypto.Crypto
> > >
> > > should output:
> > >
> > > Apache Commons Crypto 1.1.0-SNAPSHOT
> > > Native code loaded OK: 1.1.0-SNAPSHOT
> > > Native name: Apache Commons Crypto
> > > Native built: Aug 23 2020
> > > OpenSSL library loaded OK, version: 0x1000106f
> > > OpenSSL library info: OpenSSL 1.0.1f 6 Jan 2014
> > > Random instance created OK:
> > > org.apache.commons.crypto.random.OpenSslCryptoRandom@355da254
> > > Cipher instance created OK:
> > > org.apache.commons.crypto.cipher.OpenSslCipher@6ff3c5b5
> > > Additional OpenSSL_version(n) details:
> > > 1: not available
> > > 2: compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT
> > > -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2
> > > -fstack-protector --param=ssp-buffer-size=4 -Wformat
> > > -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions
> > > -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int
> -DOPENSSL_IA32_SSE2
> > > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
> > > -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
> > > -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
> > > 3: built on: Tue Dec  4 20:09:18 UTC 2018
> > > 4: platform: debian-amd64
> > > 5: OPENSSLDIR: "/usr/lib/ssl"
> > >
> > > Gary
> > >
> > > On Sun, Aug 23, 2020 at 2:23 AM Bruno P. Kinoshita <ki...@apache.org>
> > > wrote:
> > >
> > > > Hi Gary,
> > > >
> > > > I might be able to test on Win64 and Linux64 this week. You mentioned
> > > > snapshots… what is the easiest way to test them? Run some code using
> > the
> > > > code of the snapshots, or perhaps run the build+tests from a
> > tag/commit?
> > > >
> > > >
> > > > Cheers
> > > > Bruno
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Sunday, 23 August 2020, 11:49:21 am NZST, Gary Gregory <
> > > > garydgregory@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-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
> > >
> >
>

Re: [Crypto] requesting help testing native binaries

Posted by Gary Gregory <ga...@gmail.com>.

The Apache snapshot repository is here:
https://repository.apache.org/snapshots/
You just need a repository entry in your POM pointing to it in order for
Maven to resolve versions postfixed with "-SNAPSHOT".

Gary

On Sun, Aug 23, 2020 at 10:31 AM Xeno Amess <xe...@gmail.com> wrote:

> Hi Gary.
> Where is the snapshot jar?
> Is it at oss snapshot center?
> If so, then I will have a very, very tricky way to test it,
> and that test is reusable.
>
>
> Gary Gregory <ga...@gmail.com> 于2020年8月23日周日 下午9:53写道：
>
> > Building the binaries can be tricky, be warned.
> >
> > The trickiest to validate are aarch64, arm, and artmhf. All help is
> welcome
> > of course.
> >
> > A smoke test would be to make sure that the native code from the SNAPSHOT
> > jar from our SNAPSHOT repo can be loaded, for example, by calling from
> the
> > command line the class org.apache.commons.crypto.Crypto
> >
> > For example, on:
> >
> > Linux dfd13586af7a 4.19.76-linuxkit #1 SMP Tue May 26 11:42:35 UTC 2020
> > x86_64 x86_64 x86_64 GNU/Linux
> >
> > java -cp target/classes org.apache.commons.crypto.Crypto
> >
> > should output:
> >
> > Apache Commons Crypto 1.1.0-SNAPSHOT
> > Native code loaded OK: 1.1.0-SNAPSHOT
> > Native name: Apache Commons Crypto
> > Native built: Aug 23 2020
> > OpenSSL library loaded OK, version: 0x1000106f
> > OpenSSL library info: OpenSSL 1.0.1f 6 Jan 2014
> > Random instance created OK:
> > org.apache.commons.crypto.random.OpenSslCryptoRandom@355da254
> > Cipher instance created OK:
> > org.apache.commons.crypto.cipher.OpenSslCipher@6ff3c5b5
> > Additional OpenSSL_version(n) details:
> > 1: not available
> > 2: compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT
> > -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2
> > -fstack-protector --param=ssp-buffer-size=4 -Wformat
> > -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions
> > -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2
> > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
> > -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
> > -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
> > 3: built on: Tue Dec  4 20:09:18 UTC 2018
> > 4: platform: debian-amd64
> > 5: OPENSSLDIR: "/usr/lib/ssl"
> >
> > Gary
> >
> > On Sun, Aug 23, 2020 at 2:23 AM Bruno P. Kinoshita <ki...@apache.org>
> > wrote:
> >
> > > Hi Gary,
> > >
> > > I might be able to test on Win64 and Linux64 this week. You mentioned
> > > snapshots… what is the easiest way to test them? Run some code using
> the
> > > code of the snapshots, or perhaps run the build+tests from a
> tag/commit?
> > >
> > >
> > > Cheers
> > > Bruno
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Sunday, 23 August 2020, 11:49:21 am NZST, Gary Gregory <
> > > garydgregory@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-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
>

Re: [Crypto] requesting help testing native binaries

Posted by Xeno Amess <xe...@gmail.com>.

Hi Gary.
Where is the snapshot jar?
Is it at oss snapshot center?
If so, then I will have a very, very tricky way to test it,
and that test is reusable.


Gary Gregory <ga...@gmail.com> 于2020年8月23日周日 下午9:53写道：

> Building the binaries can be tricky, be warned.
>
> The trickiest to validate are aarch64, arm, and artmhf. All help is welcome
> of course.
>
> A smoke test would be to make sure that the native code from the SNAPSHOT
> jar from our SNAPSHOT repo can be loaded, for example, by calling from the
> command line the class org.apache.commons.crypto.Crypto
>
> For example, on:
>
> Linux dfd13586af7a 4.19.76-linuxkit #1 SMP Tue May 26 11:42:35 UTC 2020
> x86_64 x86_64 x86_64 GNU/Linux
>
> java -cp target/classes org.apache.commons.crypto.Crypto
>
> should output:
>
> Apache Commons Crypto 1.1.0-SNAPSHOT
> Native code loaded OK: 1.1.0-SNAPSHOT
> Native name: Apache Commons Crypto
> Native built: Aug 23 2020
> OpenSSL library loaded OK, version: 0x1000106f
> OpenSSL library info: OpenSSL 1.0.1f 6 Jan 2014
> Random instance created OK:
> org.apache.commons.crypto.random.OpenSslCryptoRandom@355da254
> Cipher instance created OK:
> org.apache.commons.crypto.cipher.OpenSslCipher@6ff3c5b5
> Additional OpenSSL_version(n) details:
> 1: not available
> 2: compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT
> -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2
> -fstack-protector --param=ssp-buffer-size=4 -Wformat
> -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions
> -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
> -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
> 3: built on: Tue Dec  4 20:09:18 UTC 2018
> 4: platform: debian-amd64
> 5: OPENSSLDIR: "/usr/lib/ssl"
>
> Gary
>
> On Sun, Aug 23, 2020 at 2:23 AM Bruno P. Kinoshita <ki...@apache.org>
> wrote:
>
> > Hi Gary,
> >
> > I might be able to test on Win64 and Linux64 this week. You mentioned
> > snapshots… what is the easiest way to test them? Run some code using the
> > code of the snapshots, or perhaps run the build+tests from a tag/commit?
> >
> >
> > Cheers
> > Bruno
> >
> >
> >
> >
> >
> >
> > On Sunday, 23 August 2020, 11:49:21 am NZST, Gary Gregory <
> > garydgregory@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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>

Re: [Crypto] requesting help testing native binaries

Posted by Gary Gregory <ga...@gmail.com>.

Building the binaries can be tricky, be warned.

The trickiest to validate are aarch64, arm, and artmhf. All help is welcome
of course.

A smoke test would be to make sure that the native code from the SNAPSHOT
jar from our SNAPSHOT repo can be loaded, for example, by calling from the
command line the class org.apache.commons.crypto.Crypto

For example, on:

Linux dfd13586af7a 4.19.76-linuxkit #1 SMP Tue May 26 11:42:35 UTC 2020
x86_64 x86_64 x86_64 GNU/Linux

java -cp target/classes org.apache.commons.crypto.Crypto

should output:

Apache Commons Crypto 1.1.0-SNAPSHOT
Native code loaded OK: 1.1.0-SNAPSHOT
Native name: Apache Commons Crypto
Native built: Aug 23 2020
OpenSSL library loaded OK, version: 0x1000106f
OpenSSL library info: OpenSSL 1.0.1f 6 Jan 2014
Random instance created OK:
org.apache.commons.crypto.random.OpenSslCryptoRandom@355da254
Cipher instance created OK:
org.apache.commons.crypto.cipher.OpenSslCipher@6ff3c5b5
Additional OpenSSL_version(n) details:
1: not available
2: compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT
-DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2
-fstack-protector --param=ssp-buffer-size=4 -Wformat
-Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions
-Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
-DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
3: built on: Tue Dec  4 20:09:18 UTC 2018
4: platform: debian-amd64
5: OPENSSLDIR: "/usr/lib/ssl"

Gary

On Sun, Aug 23, 2020 at 2:23 AM Bruno P. Kinoshita <ki...@apache.org> wrote:

> Hi Gary,
>
> I might be able to test on Win64 and Linux64 this week. You mentioned
> snapshots… what is the easiest way to test them? Run some code using the
> code of the snapshots, or perhaps run the build+tests from a tag/commit?
>
>
> Cheers
> Bruno
>
>
>
>
>
>
> On Sunday, 23 August 2020, 11:49:21 am NZST, Gary Gregory <
> garydgregory@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: [Crypto] requesting help testing native binaries

Posted by Xeno Amess <xe...@gmail.com>.

on the snapshot's release. sorry for the typo

Xeno Amess <xe...@gmail.com> 于2020年8月23日周日 下午2:44写道：

> >  what is the easiest way to test them? Run some code using the code of
> the snapshots, or perhaps run the build+tests from a tag/commit?
> How about fork its tests to a new repo, and import the original codes as a
> maven dependency, run the tests on the snapshot's source?
>
> Bruno P. Kinoshita <ki...@apache.org> 于2020年8月23日周日 下午2:23写道：
>
>> Hi Gary,
>>
>> I might be able to test on Win64 and Linux64 this week. You mentioned
>> snapshots… what is the easiest way to test them? Run some code using the
>> code of the snapshots, or perhaps run the build+tests from a tag/commit?
>>
>>
>> Cheers
>> Bruno
>>
>>
>>
>>
>>
>>
>> On Sunday, 23 August 2020, 11:49:21 am NZST, Gary Gregory <
>> garydgregory@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>

Re: [Crypto] requesting help testing native binaries

Posted by Xeno Amess <xe...@gmail.com>.

>  what is the easiest way to test them? Run some code using the code of
the snapshots, or perhaps run the build+tests from a tag/commit?
How about fork its tests to a new repo, and import the original codes as a
maven dependency, run the tests on the snapshot's source?

Bruno P. Kinoshita <ki...@apache.org> 于2020年8月23日周日 下午2:23写道：

> Hi Gary,
>
> I might be able to test on Win64 and Linux64 this week. You mentioned
> snapshots… what is the easiest way to test them? Run some code using the
> code of the snapshots, or perhaps run the build+tests from a tag/commit?
>
>
> Cheers
> Bruno
>
>
>
>
>
>
> On Sunday, 23 August 2020, 11:49:21 am NZST, Gary Gregory <
> garydgregory@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: [Crypto] requesting help testing native binaries

Posted by "Bruno P. Kinoshita" <ki...@apache.org>.

Hi Gary,

I might be able to test on Win64 and Linux64 this week. You mentioned snapshots… what is the easiest way to test them? Run some code using the code of the snapshots, or perhaps run the build+tests from a tag/commit?


Cheers
Bruno






On Sunday, 23 August 2020, 11:49:21 am NZST, Gary Gregory <ga...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [Crypto] requesting help testing native binaries

Posted by Gary Gregory <ga...@gmail.com>.

Side note: Your English is good, no need to apologize :-)

Gary

On Sun, Aug 23, 2020 at 1:56 PM Xeno Amess <xe...@gmail.com> wrote:

> @Gary Gregory <ga...@gmail.com>
> Hi.
> I done it at https://github.com/XenoAmess/commons-crypto-smoke-test
> Please have a look.
>
> > I don't quite see how but I am obviously not comprehending your plan.
>
> Then I will explain it again :)
>
> Step 1, I wrote a maven-plugin, whose usage is to copy tests from another
> repo when build.
> That plugin is released at
> https://github.com/XenoAmess/add-from-repo-maven-plugin btw.
>
> Step 2, I wrote a repo, who have nothing in src, and have Apache Commons
> Crypto 1.1.0-SNAPSHOT as dependency.
> And this repo use that plugin I wrote in step 1, to force copy all test
> codes directly from Crypto's git repo.
> Notice that only copy tests(src/test), no sources(src/main), means this
> repo do not build any sources, but only invoke tests upon original jars.
> Well I do think, if all tests in original lib (Commons Crypto) CAN pass,
> then we can say that it works correctly in this platform.
> (If I be wrong you can just tell me what examinations we need to add, and
> I will add them)
>
> Step 3, I wrote github actions to make this repo we made in Step 2, to
> make this repo run on windows, macos, and ubuntu.
>
> And the result is all pass.
> Is this explanation better?
> I'm not very good at English, sorry if I made some mistakes.
>
> Gary Gregory <ga...@gmail.com> 于2020年8月23日周日 下午11:18写道：
>
>> 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 <ga...@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
>> >
>> >
>> >
>>
>

Re: [Crypto] requesting help testing native binaries

Posted by Xeno Amess <xe...@gmail.com>.

@Gary Gregory <ga...@gmail.com>
Hi.
I done it at https://github.com/XenoAmess/commons-crypto-smoke-test
Please have a look.

> I don't quite see how but I am obviously not comprehending your plan.

Then I will explain it again :)

Step 1, I wrote a maven-plugin, whose usage is to copy tests from another
repo when build.
That plugin is released at
https://github.com/XenoAmess/add-from-repo-maven-plugin btw.

Step 2, I wrote a repo, who have nothing in src, and have Apache Commons
Crypto 1.1.0-SNAPSHOT as dependency.
And this repo use that plugin I wrote in step 1, to force copy all test
codes directly from Crypto's git repo.
Notice that only copy tests(src/test), no sources(src/main), means this
repo do not build any sources, but only invoke tests upon original jars.
Well I do think, if all tests in original lib (Commons Crypto) CAN pass,
then we can say that it works correctly in this platform.
(If I be wrong you can just tell me what examinations we need to add, and I
will add them)

Step 3, I wrote github actions to make this repo we made in Step 2, to make
this repo run on windows, macos, and ubuntu.

And the result is all pass.
Is this explanation better?
I'm not very good at English, sorry if I made some mistakes.

Gary Gregory <ga...@gmail.com> 于2020年8月23日周日 下午11:18写道：

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

Re: [Crypto] requesting help testing native binaries

Posted by Matt Sicker <bo...@gmail.com>.

Public place for binaries: https://dist.apache.org/repos/dist/dev/commons/

On Mon, 24 Aug 2020 at 14:40, Gary Gregory <ga...@gmail.com> wrote:
>
> Here is a jar since I don't have a public place for binaries.
>
> Gary
>
>  commons-crypto-1.1.0-20200824.190246-21.jar
> <https://drive.google.com/file/d/1yNLeKrGQibh38ZQSN2mz_48Qj2rENo3e/view?usp=drive_web>
>
>
> On Mon, Aug 24, 2020 at 12:10 PM Geoffrey Blake <ge...@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.
> >
> > -Geoff
> >
> > On Sun, Aug 23, 2020 at 9:08 PM Alex Remily <al...@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 <ga...@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 <al...@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 <
> > garydgregory@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 <
> > garydgregory@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-unsubscribe@commons.apache.org
> > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >



-- 
Matt Sicker <bo...@gmail.com>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [Crypto] requesting help testing native binaries

Posted by Xeno Amess <xe...@gmail.com>.

Hi.
seems all machines that github actions can provide (means [ windows-2019,
ubuntu-20.04, ubuntu-18.04, ubuntu-16.04, macos-10.15 ])
can invoke your snapshot correctly...

Gary Gregory <ga...@gmail.com> 于2020年8月25日周二 上午3:40写道：

> Here is a jar since I don't have a public place for binaries.
>
> Gary
>
>  commons-crypto-1.1.0-20200824.190246-21.jar
> <
> https://drive.google.com/file/d/1yNLeKrGQibh38ZQSN2mz_48Qj2rENo3e/view?usp=drive_web
> >
>
>
> On Mon, Aug 24, 2020 at 12:10 PM Geoffrey Blake <
> geoffrey.w.blake@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.
> >
> > -Geoff
> >
> > On Sun, Aug 23, 2020 at 9:08 PM Alex Remily <al...@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 <ga...@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 <al...@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 <
> > garydgregory@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 <
> > garydgregory@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-unsubscribe@commons.apache.org
> > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
>

Re: [Crypto] requesting help testing native binaries

Posted by Gary Gregory <ga...@gmail.com>.

Here is a jar since I don't have a public place for binaries.

Gary

 commons-crypto-1.1.0-20200824.190246-21.jar
<https://drive.google.com/file/d/1yNLeKrGQibh38ZQSN2mz_48Qj2rENo3e/view?usp=drive_web>


On Mon, Aug 24, 2020 at 12:10 PM Geoffrey Blake <ge...@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.
>
> -Geoff
>
> On Sun, Aug 23, 2020 at 9:08 PM Alex Remily <al...@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 <ga...@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 <al...@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 <
> garydgregory@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 <
> garydgregory@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-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>

Re: [Crypto] requesting help testing native binaries

Posted by Gary Gregory <ga...@gmail.com>.

The snapshot repo keeps getting overwritten by CI builds, let me find a
more stable place...

Gary


On Mon, Aug 24, 2020 at 12:10 PM Geoffrey Blake <ge...@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.
>
> -Geoff
>
> On Sun, Aug 23, 2020 at 9:08 PM Alex Remily <al...@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 <ga...@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 <al...@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 <
> garydgregory@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 <
> garydgregory@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-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>

Re: [Crypto] requesting help testing native binaries

Posted by Gary Gregory <ga...@gmail.com>.

On Wed, Aug 26, 2020 at 11:00 PM Gary Gregory <ga...@gmail.com>
wrote:

> Part 2, trying to get macos to behave:
>
> echo $PATH
> /opt/apache-maven-3.6.3/bin:/usr/local/opt/openssl@1.1
> /bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
>
> *export LD_LIBRARY_PATH=/usr/local/Cellar/openssl@1.1/1.1.1g/lib/*
> *java -cp target/classes org.apache.commons.crypto.Crypto*
> Apache Commons Crypto 1.1.0-SNAPSHOT
> 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)
>
> Bummer.
>
> Then:
>
> *link /usr/local/Cellar/openssl@1.1/1.1.1g/lib/libcrypto.dylib
> /Users/garydgregory/lib/libcrypto.dylib*
> *java -cp target/classes org.apache.commons.crypto.Crypto*
> Apache Commons Crypto 1.1.0-SNAPSHOT
> 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)
>
> Arg.
>

Oh and this:

sudo ln -s -v  /usr/local/Cellar/openssl@1.1/1.1.1g/lib/libcrypto.dylib
/usr/lib/libcrypto.dylib
ln: /usr/lib/libcrypto.dylib: Operation not permitted

Arg, arg.

Gary


>
> Gary
>
> On Wed, Aug 26, 2020 at 9:39 PM Alex Remily <al...@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 <ga...@gmail.com>
>> wrote:
>> >
>> > On Mon, Aug 24, 2020 at 12:10 PM Geoffrey Blake <
>> geoffrey.w.blake@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 <al...@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 <
>> garydgregory@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 <al...@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 <
>> > > garydgregory@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 <
>> > > garydgregory@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-unsubscribe@commons.apache.org
>> > > > > > For additional commands, e-mail: dev-help@commons.apache.org
>> > > > > >
>> > > > > >
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > > > For additional commands, e-mail: dev-help@commons.apache.org
>> > > >
>> > > >
>> > >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>

Re: [Crypto] requesting help testing native binaries

Posted by Gary Gregory <ga...@gmail.com>.

Part 2, trying to get macos to behave:

echo $PATH
/opt/apache-maven-3.6.3/bin:/usr/local/opt/openssl@1.1
/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

*export LD_LIBRARY_PATH=/usr/local/Cellar/openssl@1.1/1.1.1g/lib/*
*java -cp target/classes org.apache.commons.crypto.Crypto*
Apache Commons Crypto 1.1.0-SNAPSHOT
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)

Bummer.

Then:

*link /usr/local/Cellar/openssl@1.1/1.1.1g/lib/libcrypto.dylib
/Users/garydgregory/lib/libcrypto.dylib*
*java -cp target/classes org.apache.commons.crypto.Crypto*
Apache Commons Crypto 1.1.0-SNAPSHOT
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)

Arg.

Gary

On Wed, Aug 26, 2020 at 9:39 PM Alex Remily <al...@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 <ga...@gmail.com>
> wrote:
> >
> > On Mon, Aug 24, 2020 at 12:10 PM Geoffrey Blake <
> geoffrey.w.blake@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 <al...@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 <garydgregory@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 <al...@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 <
> > > garydgregory@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 <
> > > garydgregory@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-unsubscribe@commons.apache.org
> > > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > > >
> > > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: [Crypto] requesting help testing native binaries

Posted by Gary Gregory <ga...@gmail.com>.

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 <al...@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 <ga...@gmail.com>
> wrote:
> >
> > On Mon, Aug 24, 2020 at 12:10 PM Geoffrey Blake <
> geoffrey.w.blake@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 <al...@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 <garydgregory@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 <al...@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 <
> > > garydgregory@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 <
> > > garydgregory@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-unsubscribe@commons.apache.org
> > > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > > >
> > > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: [Crypto] requesting help testing native binaries

Posted by Alex Remily <al...@gmail.com>.

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 <ga...@gmail.com> wrote:
>
> On Mon, Aug 24, 2020 at 12:10 PM Geoffrey Blake <ge...@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 <al...@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 <ga...@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 <al...@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 <
> > garydgregory@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 <
> > garydgregory@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-unsubscribe@commons.apache.org
> > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [Crypto] requesting help testing native binaries

Posted by Gary Gregory <ga...@gmail.com>.

On Mon, Aug 24, 2020 at 12:10 PM Geoffrey Blake <ge...@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 <al...@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 <ga...@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 <al...@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 <
> garydgregory@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 <
> garydgregory@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-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>

Re: [Crypto] requesting help testing native binaries

Posted by Geoffrey Blake <ge...@gmail.com>.

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.

-Geoff

On Sun, Aug 23, 2020 at 9:08 PM Alex Remily <al...@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 <ga...@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 <al...@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 <ga...@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 <garydgregory@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-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: [Crypto] requesting help testing native binaries

Posted by Alex Remily <al...@gmail.com>.

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 <ga...@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 <al...@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 <ga...@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 <ga...@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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [Crypto] requesting help testing native binaries

Posted by Gary Gregory <ga...@gmail.com>.

I will proceed with an RC today! :-)

Gary

On Fri, Aug 28, 2020 at 10:42 AM Gary Gregory <ga...@gmail.com>
wrote:

> Thanks Geoffrey, updating our tally:
>
> Here is what community testing we have so far for the Crypto.main() smoke
> test:
>
> - darwin64-x86_64-cc; OpenSSL 1.1.1g; Gary Gregory, Alex Remily
> - debian-amd64; OpenSSL 1.0.1f; Gary Gregory
> - debian-amd64; OpenSSL 1.1.1g; Bruno P. Kinoshita
> - Linux x86_64; OpenSSL 1.1.1; Alex Remily
> - Windows 64 (mingw64); OpenSSL 1.1.1d; Alex Remily
> - linux-aarch64; OpenSSL 1.0.2k-fips; Geoffrey Blake
> - debian-arm64; OpenSSL 1.1.1f; Geoffrey Blake
>
> Gary
>
>
> On Fri, Aug 28, 2020 at 10:25 AM Geoffrey Blake <
> geoffrey.w.blake@gmail.com> wrote:
>
>> Hi all,
>>
>> For the simple smoke test, on AArch64 for AmazonLinux2 (OpenSSL 1.0.2k)
>> and
>> Ubuntu 20.04 (OpenSSL 1.1.1f) everything loads ok with the current Jar
>> that
>> Gary posted.
>>
>> -Geoff
>>
>> AL2 output:
>> java -cp commons-crypto-1.1.0-20200824.190246-21.jar
>> org.apache.commons.crypto.Crypto
>> Apache Commons Crypto 1.1.0-SNAPSHOT
>> Native code loaded OK: 1.1.0-SNAPSHOT
>> Native name: Apache Commons Crypto
>> Native built: Aug 18 2020
>> OpenSSL library loaded OK, version: 0x100020bf
>> OpenSSL library info: OpenSSL 1.0.2k-fips  26 Jan 2017
>> Random instance created OK:
>> org.apache.commons.crypto.random.OpenSslCryptoRandom@54bedef2
>> Cipher AES/CTR/NoPadding instance created OK:
>> org.apache.commons.crypto.cipher.OpenSslCipher@13221655
>> Additional OpenSSL_version(n) details:
>> 1: not available
>> 2: compiler: gcc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DZLIB
>> -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT
>> -DL_ENDIAN -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
>> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
>> -Wa,--noexecstack -DPURIFY -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM
>> 3: built on: reproducible build, date unspecified
>> 4: platform: linux-aarch64
>> 5: OPENSSLDIR: "/etc/pki/tls"
>>
>> Ubuntu output:
>> java -cp commons-crypto-1.1.0-20200824.190246-21.jar
>> org.apache.commons.crypto.Crypto
>> Apache Commons Crypto 1.1.0-SNAPSHOT
>> Native code loaded OK: 1.1.0-SNAPSHOT
>> Native name: Apache Commons Crypto
>> Native built: Aug 18 2020
>> OpenSSL library loaded OK, version: 0x1010106f
>> OpenSSL library info: OpenSSL 1.1.1f  31 Mar 2020
>> Random instance created OK:
>> org.apache.commons.crypto.random.OpenSslCryptoRandom@65b54208
>> Cipher AES/CTR/NoPadding instance created OK:
>> org.apache.commons.crypto.cipher.OpenSslCipher@119d7047
>> Additional OpenSSL_version(n) details:
>> 1: compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack
>> -g -O2 -fdebug-prefix-map=/build/openssl-9j6sUa/openssl-1.1.1f=.
>> -fstack-protector-strong -Wformat -Werror=format-security
>> -DOPENSSL_TLS_SECURITY_LEVEL=2 -DOPENSSL_USE_NODELETE -DOPENSSL_PIC
>> -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM
>> -DSHA512_ASM -DKECCAK1600_ASM -DVPAES_ASM -DECP_NISTZ256_ASM
>> -DPOLY1305_ASM
>> -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
>> 2: built on: Mon Apr 20 11:53:50 2020 UTC
>> 3: platform: debian-arm64
>> 4: OPENSSLDIR: "/usr/lib/ssl"
>> 5: ENGINESDIR: "/usr/lib/aarch64-linux-gnu/engines-1.1"
>>
>> On Thu, Aug 27, 2020 at 10:05 PM Matt Sicker <bo...@gmail.com> wrote:
>>
>> > For a library with as many vulnerabilities as OpenSSL, I’m surprised
>> macOS
>> > keeps such an ancient version! It’s not like they ship a trimmed down
>> and
>> > audited version of LibreSSL, either.
>> >
>> > On Thu, Aug 27, 2020 at 20:19 Gary Gregory <ga...@gmail.com>
>> wrote:
>> >
>> > > The issue for me is that it was a PITA to override macos' baked in
>> > >
>> > > (ancient) LibreSSL.
>> > >
>> > >
>> > >
>> > > Gary
>> > >
>> > >
>> > >
>> > > On Thu, Aug 27, 2020, 20:03 Alex Remily <al...@gmail.com>
>> wrote:
>> > >
>> > >
>> > >
>> > > > Interesting.  If I understand correctly, you did get it to run
>> > >
>> > > > successfully to completion, but only after placing a compatible
>> > >
>> > > > libcrypto in the directory of execution, probably the first place
>> > >
>> > > > dlopen looks for it.  Would you agree then that the error was caused
>> > >
>> > > > by loading an incompatible libcrypto?  I'm inclined to think this
>> is a
>> > >
>> > > > configuration issue that should be well documented, as opposed to
>> one
>> > >
>> > > > that should be addressed through code.  Like you, I also tried
>> setting
>> > >
>> > > > the LD_LIBRARY_PATH environment variable with no success.  I was
>> able
>> > >
>> > > > to symlink the libcrypto in the usr/local/lib directory, though,
>> which
>> > >
>> > > > fixed the issue, but I agree this is a limitation.  A user should be
>> > >
>> > > > able to run more than one instance of libcrypto on the same host.
>> I'm
>> > >
>> > > > unsure as to the best way to proceed.
>> > >
>> > > >
>> > >
>> > > >
>> > >
>> > > > On Thu, Aug 27, 2020 at 6:41 PM Gary Gregory <
>> garydgregory@gmail.com>
>> > >
>> > > > wrote:
>> > >
>> > > > >
>> > >
>> > > > > On Mon, Aug 24, 2020 at 7:28 PM Alex Remily <
>> alex.remily@gmail.com>
>> > >
>> > > > wrote:
>> > >
>> > > > >
>> > >
>> > > > > > Gary,
>> > >
>> > > > > >
>> > >
>> > > > > > Can you check that your libcrypto.dylib is symlinked to the
>> > libcrypto
>> > >
>> > > > > > for OpenSSL 1.1.1.g?  Mine wasn't, and I was getting different
>> > output
>> > >
>> > > > > > from the main function than from the unit test output.  I'm not
>> > >
>> > > > > > confident that this is the root of the problem, but it may at
>> least
>> > >
>> > > > > > eliminate a possibility.
>> > >
>> > > > > >
>> > >
>> > > > > > On my machine I had to set /usr/local/lib/libcrypto.dylib -->
>> > >
>> > > > > > /usr/local/Cellar/openssl@1.1/1.1.1g/lib/libcrypto.1.1.dylib.
>> The
>> > > JNI
>> > >
>> > > > > > libraries use dlopen to find and load libcrypto, and dlopen
>> looks
>> > for
>> > >
>> > > > > >
>> > >
>> > > > >
>> > >
>> > > > > That did not work for me. The only thing that works is copying the
>> > > dylib
>> > >
>> > > > > file to the current dir. Hack!
>> > >
>> > > > >
>> > >
>> > > > > Gary
>> > >
>> > > > >
>> > >
>> > > > >
>> > >
>> > > > > > it in /usr/local/lib/, among other places.
>> > >
>> > > > > >
>> > >
>> > > > > >
>> > >
>> > > > > >
>> > >
>> > > >
>> > >
>> >
>> https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/dlopen.3.html
>> > >
>> > > > > >
>> > >
>> > > > > > If that doesn't work I'm going to need to step through the code.
>> > My
>> > >
>> > > > > > output:
>> > >
>> > > > > >
>> > >
>> > > > > > 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 24 2020
>> > >
>> > > > > > OpenSSL library loaded OK, version: 0x1010107f
>> > >
>> > > > > > OpenSSL library info OpenSSL 1.1.1g  21 Apr 2020
>> > >
>> > > > > > Random instance created OK
>> > >
>> > > > > > Cipher instance created OK
>> > >
>> > > > > > Additional OpenSSL_version(n) details:
>> > >
>> > > > > > 1: compiler: clang -fPIC -arch x86_64 -O3 -Wall -DL_ENDIAN
>> > >
>> > > > > > -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2
>> > >
>> > > > > > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
>> -DOPENSSL_BN_ASM_GF2m
>> > >
>> > > > > > -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM
>> > >
>> > > > > > -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
>> > >
>> > > > > > -DX25519_ASM -DPOLY1305_ASM -D_REENTRANT -DNDEBUG
>> > >
>> > > > > > 2: built on: Tue Apr 21 13:29:43 2020 UTC
>> > >
>> > > > > > 3: platform: darwin64-x86_64-cc
>> > >
>> > > > > > 4: OPENSSLDIR: "/usr/local/etc/openssl@1.1"
>> > >
>> > > > > > 5: ENGINESDIR: "/usr/local/Cellar/openssl@1.1
>> > > /1.1.1g/lib/engines-1.1"
>> > >
>> > > > > >
>> > >
>> > > > > > Alex
>> > >
>> > > > > >
>> > >
>> > > > > > On Sun, Aug 23, 2020 at 9:50 PM Gary Gregory <
>> > garydgregory@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.remily@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 <
>> > >
>> > > > garydgregory@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 <
>> > >
>> > > > garydgregory@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-unsubscribe@commons.apache.org
>> > >
>> > > > > > > > For additional commands, e-mail:
>> dev-help@commons.apache.org
>> > >
>> > > > > > > >
>> > >
>> > > > > > > >
>> > >
>> > > > > >
>> > >
>> > > > > >
>> > ---------------------------------------------------------------------
>> > >
>> > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > >
>> > > > > > For additional commands, e-mail: dev-help@commons.apache.org
>> > >
>> > > > > >
>> > >
>> > > > > >
>> > >
>> > > >
>> > >
>> > > >
>> ---------------------------------------------------------------------
>> > >
>> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > >
>> > > > For additional commands, e-mail: dev-help@commons.apache.org
>> > >
>> > > >
>> > >
>> > > >
>> > >
>> > > --
>> > Matt Sicker <bo...@gmail.com>
>> >
>>
>

Re: [Crypto] requesting help testing native binaries

Posted by Gary Gregory <ga...@gmail.com>.

Thanks Geoffrey, updating our tally:

Here is what community testing we have so far for the Crypto.main() smoke
test:

- darwin64-x86_64-cc; OpenSSL 1.1.1g; Gary Gregory, Alex Remily
- debian-amd64; OpenSSL 1.0.1f; Gary Gregory
- debian-amd64; OpenSSL 1.1.1g; Bruno P. Kinoshita
- Linux x86_64; OpenSSL 1.1.1; Alex Remily
- Windows 64 (mingw64); OpenSSL 1.1.1d; Alex Remily
- linux-aarch64; OpenSSL 1.0.2k-fips; Geoffrey Blake
- debian-arm64; OpenSSL 1.1.1f; Geoffrey Blake

Gary


On Fri, Aug 28, 2020 at 10:25 AM Geoffrey Blake <ge...@gmail.com>
wrote:

> Hi all,
>
> For the simple smoke test, on AArch64 for AmazonLinux2 (OpenSSL 1.0.2k) and
> Ubuntu 20.04 (OpenSSL 1.1.1f) everything loads ok with the current Jar that
> Gary posted.
>
> -Geoff
>
> AL2 output:
> java -cp commons-crypto-1.1.0-20200824.190246-21.jar
> org.apache.commons.crypto.Crypto
> Apache Commons Crypto 1.1.0-SNAPSHOT
> Native code loaded OK: 1.1.0-SNAPSHOT
> Native name: Apache Commons Crypto
> Native built: Aug 18 2020
> OpenSSL library loaded OK, version: 0x100020bf
> OpenSSL library info: OpenSSL 1.0.2k-fips  26 Jan 2017
> Random instance created OK:
> org.apache.commons.crypto.random.OpenSslCryptoRandom@54bedef2
> Cipher AES/CTR/NoPadding instance created OK:
> org.apache.commons.crypto.cipher.OpenSslCipher@13221655
> Additional OpenSSL_version(n) details:
> 1: not available
> 2: compiler: gcc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DZLIB
> -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT
> -DL_ENDIAN -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
> -Wa,--noexecstack -DPURIFY -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM
> 3: built on: reproducible build, date unspecified
> 4: platform: linux-aarch64
> 5: OPENSSLDIR: "/etc/pki/tls"
>
> Ubuntu output:
> java -cp commons-crypto-1.1.0-20200824.190246-21.jar
> org.apache.commons.crypto.Crypto
> Apache Commons Crypto 1.1.0-SNAPSHOT
> Native code loaded OK: 1.1.0-SNAPSHOT
> Native name: Apache Commons Crypto
> Native built: Aug 18 2020
> OpenSSL library loaded OK, version: 0x1010106f
> OpenSSL library info: OpenSSL 1.1.1f  31 Mar 2020
> Random instance created OK:
> org.apache.commons.crypto.random.OpenSslCryptoRandom@65b54208
> Cipher AES/CTR/NoPadding instance created OK:
> org.apache.commons.crypto.cipher.OpenSslCipher@119d7047
> Additional OpenSSL_version(n) details:
> 1: compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack
> -g -O2 -fdebug-prefix-map=/build/openssl-9j6sUa/openssl-1.1.1f=.
> -fstack-protector-strong -Wformat -Werror=format-security
> -DOPENSSL_TLS_SECURITY_LEVEL=2 -DOPENSSL_USE_NODELETE -DOPENSSL_PIC
> -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM
> -DSHA512_ASM -DKECCAK1600_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM
> -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
> 2: built on: Mon Apr 20 11:53:50 2020 UTC
> 3: platform: debian-arm64
> 4: OPENSSLDIR: "/usr/lib/ssl"
> 5: ENGINESDIR: "/usr/lib/aarch64-linux-gnu/engines-1.1"
>
> On Thu, Aug 27, 2020 at 10:05 PM Matt Sicker <bo...@gmail.com> wrote:
>
> > For a library with as many vulnerabilities as OpenSSL, I’m surprised
> macOS
> > keeps such an ancient version! It’s not like they ship a trimmed down and
> > audited version of LibreSSL, either.
> >
> > On Thu, Aug 27, 2020 at 20:19 Gary Gregory <ga...@gmail.com>
> wrote:
> >
> > > The issue for me is that it was a PITA to override macos' baked in
> > >
> > > (ancient) LibreSSL.
> > >
> > >
> > >
> > > Gary
> > >
> > >
> > >
> > > On Thu, Aug 27, 2020, 20:03 Alex Remily <al...@gmail.com> wrote:
> > >
> > >
> > >
> > > > Interesting.  If I understand correctly, you did get it to run
> > >
> > > > successfully to completion, but only after placing a compatible
> > >
> > > > libcrypto in the directory of execution, probably the first place
> > >
> > > > dlopen looks for it.  Would you agree then that the error was caused
> > >
> > > > by loading an incompatible libcrypto?  I'm inclined to think this is
> a
> > >
> > > > configuration issue that should be well documented, as opposed to one
> > >
> > > > that should be addressed through code.  Like you, I also tried
> setting
> > >
> > > > the LD_LIBRARY_PATH environment variable with no success.  I was able
> > >
> > > > to symlink the libcrypto in the usr/local/lib directory, though,
> which
> > >
> > > > fixed the issue, but I agree this is a limitation.  A user should be
> > >
> > > > able to run more than one instance of libcrypto on the same host.
> I'm
> > >
> > > > unsure as to the best way to proceed.
> > >
> > > >
> > >
> > > >
> > >
> > > > On Thu, Aug 27, 2020 at 6:41 PM Gary Gregory <garydgregory@gmail.com
> >
> > >
> > > > wrote:
> > >
> > > > >
> > >
> > > > > On Mon, Aug 24, 2020 at 7:28 PM Alex Remily <alex.remily@gmail.com
> >
> > >
> > > > wrote:
> > >
> > > > >
> > >
> > > > > > Gary,
> > >
> > > > > >
> > >
> > > > > > Can you check that your libcrypto.dylib is symlinked to the
> > libcrypto
> > >
> > > > > > for OpenSSL 1.1.1.g?  Mine wasn't, and I was getting different
> > output
> > >
> > > > > > from the main function than from the unit test output.  I'm not
> > >
> > > > > > confident that this is the root of the problem, but it may at
> least
> > >
> > > > > > eliminate a possibility.
> > >
> > > > > >
> > >
> > > > > > On my machine I had to set /usr/local/lib/libcrypto.dylib -->
> > >
> > > > > > /usr/local/Cellar/openssl@1.1/1.1.1g/lib/libcrypto.1.1.dylib.
> The
> > > JNI
> > >
> > > > > > libraries use dlopen to find and load libcrypto, and dlopen looks
> > for
> > >
> > > > > >
> > >
> > > > >
> > >
> > > > > That did not work for me. The only thing that works is copying the
> > > dylib
> > >
> > > > > file to the current dir. Hack!
> > >
> > > > >
> > >
> > > > > Gary
> > >
> > > > >
> > >
> > > > >
> > >
> > > > > > it in /usr/local/lib/, among other places.
> > >
> > > > > >
> > >
> > > > > >
> > >
> > > > > >
> > >
> > > >
> > >
> >
> https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/dlopen.3.html
> > >
> > > > > >
> > >
> > > > > > If that doesn't work I'm going to need to step through the code.
> > My
> > >
> > > > > > output:
> > >
> > > > > >
> > >
> > > > > > 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 24 2020
> > >
> > > > > > OpenSSL library loaded OK, version: 0x1010107f
> > >
> > > > > > OpenSSL library info OpenSSL 1.1.1g  21 Apr 2020
> > >
> > > > > > Random instance created OK
> > >
> > > > > > Cipher instance created OK
> > >
> > > > > > Additional OpenSSL_version(n) details:
> > >
> > > > > > 1: compiler: clang -fPIC -arch x86_64 -O3 -Wall -DL_ENDIAN
> > >
> > > > > > -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2
> > >
> > > > > > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
> -DOPENSSL_BN_ASM_GF2m
> > >
> > > > > > -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM
> > >
> > > > > > -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
> > >
> > > > > > -DX25519_ASM -DPOLY1305_ASM -D_REENTRANT -DNDEBUG
> > >
> > > > > > 2: built on: Tue Apr 21 13:29:43 2020 UTC
> > >
> > > > > > 3: platform: darwin64-x86_64-cc
> > >
> > > > > > 4: OPENSSLDIR: "/usr/local/etc/openssl@1.1"
> > >
> > > > > > 5: ENGINESDIR: "/usr/local/Cellar/openssl@1.1
> > > /1.1.1g/lib/engines-1.1"
> > >
> > > > > >
> > >
> > > > > > Alex
> > >
> > > > > >
> > >
> > > > > > On Sun, Aug 23, 2020 at 9:50 PM Gary Gregory <
> > garydgregory@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.remily@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 <
> > >
> > > > garydgregory@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 <
> > >
> > > > garydgregory@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-unsubscribe@commons.apache.org
> > >
> > > > > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > > > > > > >
> > >
> > > > > > > >
> > >
> > > > > >
> > >
> > > > > >
> > ---------------------------------------------------------------------
> > >
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >
> > > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > > > > >
> > >
> > > > > >
> > >
> > > >
> > >
> > > > ---------------------------------------------------------------------
> > >
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > > >
> > >
> > > >
> > >
> > > --
> > Matt Sicker <bo...@gmail.com>
> >
>

Re: [Crypto] requesting help testing native binaries

Posted by Geoffrey Blake <ge...@gmail.com>.

Hi all,

For the simple smoke test, on AArch64 for AmazonLinux2 (OpenSSL 1.0.2k) and
Ubuntu 20.04 (OpenSSL 1.1.1f) everything loads ok with the current Jar that
Gary posted.

-Geoff

AL2 output:
java -cp commons-crypto-1.1.0-20200824.190246-21.jar
org.apache.commons.crypto.Crypto
Apache Commons Crypto 1.1.0-SNAPSHOT
Native code loaded OK: 1.1.0-SNAPSHOT
Native name: Apache Commons Crypto
Native built: Aug 18 2020
OpenSSL library loaded OK, version: 0x100020bf
OpenSSL library info: OpenSSL 1.0.2k-fips  26 Jan 2017
Random instance created OK:
org.apache.commons.crypto.random.OpenSslCryptoRandom@54bedef2
Cipher AES/CTR/NoPadding instance created OK:
org.apache.commons.crypto.cipher.OpenSslCipher@13221655
Additional OpenSSL_version(n) details:
1: not available
2: compiler: gcc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DZLIB
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT
-DL_ENDIAN -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-Wa,--noexecstack -DPURIFY -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM
3: built on: reproducible build, date unspecified
4: platform: linux-aarch64
5: OPENSSLDIR: "/etc/pki/tls"

Ubuntu output:
java -cp commons-crypto-1.1.0-20200824.190246-21.jar
org.apache.commons.crypto.Crypto
Apache Commons Crypto 1.1.0-SNAPSHOT
Native code loaded OK: 1.1.0-SNAPSHOT
Native name: Apache Commons Crypto
Native built: Aug 18 2020
OpenSSL library loaded OK, version: 0x1010106f
OpenSSL library info: OpenSSL 1.1.1f  31 Mar 2020
Random instance created OK:
org.apache.commons.crypto.random.OpenSslCryptoRandom@65b54208
Cipher AES/CTR/NoPadding instance created OK:
org.apache.commons.crypto.cipher.OpenSslCipher@119d7047
Additional OpenSSL_version(n) details:
1: compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack
-g -O2 -fdebug-prefix-map=/build/openssl-9j6sUa/openssl-1.1.1f=.
-fstack-protector-strong -Wformat -Werror=format-security
-DOPENSSL_TLS_SECURITY_LEVEL=2 -DOPENSSL_USE_NODELETE -DOPENSSL_PIC
-DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM
-DSHA512_ASM -DKECCAK1600_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM
-DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
2: built on: Mon Apr 20 11:53:50 2020 UTC
3: platform: debian-arm64
4: OPENSSLDIR: "/usr/lib/ssl"
5: ENGINESDIR: "/usr/lib/aarch64-linux-gnu/engines-1.1"

On Thu, Aug 27, 2020 at 10:05 PM Matt Sicker <bo...@gmail.com> wrote:

> For a library with as many vulnerabilities as OpenSSL, I’m surprised macOS
> keeps such an ancient version! It’s not like they ship a trimmed down and
> audited version of LibreSSL, either.
>
> On Thu, Aug 27, 2020 at 20:19 Gary Gregory <ga...@gmail.com> wrote:
>
> > The issue for me is that it was a PITA to override macos' baked in
> >
> > (ancient) LibreSSL.
> >
> >
> >
> > Gary
> >
> >
> >
> > On Thu, Aug 27, 2020, 20:03 Alex Remily <al...@gmail.com> wrote:
> >
> >
> >
> > > Interesting.  If I understand correctly, you did get it to run
> >
> > > successfully to completion, but only after placing a compatible
> >
> > > libcrypto in the directory of execution, probably the first place
> >
> > > dlopen looks for it.  Would you agree then that the error was caused
> >
> > > by loading an incompatible libcrypto?  I'm inclined to think this is a
> >
> > > configuration issue that should be well documented, as opposed to one
> >
> > > that should be addressed through code.  Like you, I also tried setting
> >
> > > the LD_LIBRARY_PATH environment variable with no success.  I was able
> >
> > > to symlink the libcrypto in the usr/local/lib directory, though, which
> >
> > > fixed the issue, but I agree this is a limitation.  A user should be
> >
> > > able to run more than one instance of libcrypto on the same host.  I'm
> >
> > > unsure as to the best way to proceed.
> >
> > >
> >
> > >
> >
> > > On Thu, Aug 27, 2020 at 6:41 PM Gary Gregory <ga...@gmail.com>
> >
> > > wrote:
> >
> > > >
> >
> > > > On Mon, Aug 24, 2020 at 7:28 PM Alex Remily <al...@gmail.com>
> >
> > > wrote:
> >
> > > >
> >
> > > > > Gary,
> >
> > > > >
> >
> > > > > Can you check that your libcrypto.dylib is symlinked to the
> libcrypto
> >
> > > > > for OpenSSL 1.1.1.g?  Mine wasn't, and I was getting different
> output
> >
> > > > > from the main function than from the unit test output.  I'm not
> >
> > > > > confident that this is the root of the problem, but it may at least
> >
> > > > > eliminate a possibility.
> >
> > > > >
> >
> > > > > On my machine I had to set /usr/local/lib/libcrypto.dylib -->
> >
> > > > > /usr/local/Cellar/openssl@1.1/1.1.1g/lib/libcrypto.1.1.dylib.  The
> > JNI
> >
> > > > > libraries use dlopen to find and load libcrypto, and dlopen looks
> for
> >
> > > > >
> >
> > > >
> >
> > > > That did not work for me. The only thing that works is copying the
> > dylib
> >
> > > > file to the current dir. Hack!
> >
> > > >
> >
> > > > Gary
> >
> > > >
> >
> > > >
> >
> > > > > it in /usr/local/lib/, among other places.
> >
> > > > >
> >
> > > > >
> >
> > > > >
> >
> > >
> >
> https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/dlopen.3.html
> >
> > > > >
> >
> > > > > If that doesn't work I'm going to need to step through the code.
> My
> >
> > > > > output:
> >
> > > > >
> >
> > > > > 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 24 2020
> >
> > > > > OpenSSL library loaded OK, version: 0x1010107f
> >
> > > > > OpenSSL library info OpenSSL 1.1.1g  21 Apr 2020
> >
> > > > > Random instance created OK
> >
> > > > > Cipher instance created OK
> >
> > > > > Additional OpenSSL_version(n) details:
> >
> > > > > 1: compiler: clang -fPIC -arch x86_64 -O3 -Wall -DL_ENDIAN
> >
> > > > > -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2
> >
> > > > > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
> >
> > > > > -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM
> >
> > > > > -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
> >
> > > > > -DX25519_ASM -DPOLY1305_ASM -D_REENTRANT -DNDEBUG
> >
> > > > > 2: built on: Tue Apr 21 13:29:43 2020 UTC
> >
> > > > > 3: platform: darwin64-x86_64-cc
> >
> > > > > 4: OPENSSLDIR: "/usr/local/etc/openssl@1.1"
> >
> > > > > 5: ENGINESDIR: "/usr/local/Cellar/openssl@1.1
> > /1.1.1g/lib/engines-1.1"
> >
> > > > >
> >
> > > > > Alex
> >
> > > > >
> >
> > > > > On Sun, Aug 23, 2020 at 9:50 PM Gary Gregory <
> garydgregory@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 <al...@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 <
> >
> > > garydgregory@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 <
> >
> > > garydgregory@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-unsubscribe@commons.apache.org
> >
> > > > > > > For additional commands, e-mail: dev-help@commons.apache.org
> >
> > > > > > >
> >
> > > > > > >
> >
> > > > >
> >
> > > > >
> ---------------------------------------------------------------------
> >
> > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >
> > > > > For additional commands, e-mail: dev-help@commons.apache.org
> >
> > > > >
> >
> > > > >
> >
> > >
> >
> > > ---------------------------------------------------------------------
> >
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >
> > > For additional commands, e-mail: dev-help@commons.apache.org
> >
> > >
> >
> > >
> >
> > --
> Matt Sicker <bo...@gmail.com>
>

Re: [Crypto] requesting help testing native binaries

Posted by Matt Sicker <bo...@gmail.com>.

For a library with as many vulnerabilities as OpenSSL, I’m surprised macOS
keeps such an ancient version! It’s not like they ship a trimmed down and
audited version of LibreSSL, either.

On Thu, Aug 27, 2020 at 20:19 Gary Gregory <ga...@gmail.com> wrote:

> The issue for me is that it was a PITA to override macos' baked in
>
> (ancient) LibreSSL.
>
>
>
> Gary
>
>
>
> On Thu, Aug 27, 2020, 20:03 Alex Remily <al...@gmail.com> wrote:
>
>
>
> > Interesting.  If I understand correctly, you did get it to run
>
> > successfully to completion, but only after placing a compatible
>
> > libcrypto in the directory of execution, probably the first place
>
> > dlopen looks for it.  Would you agree then that the error was caused
>
> > by loading an incompatible libcrypto?  I'm inclined to think this is a
>
> > configuration issue that should be well documented, as opposed to one
>
> > that should be addressed through code.  Like you, I also tried setting
>
> > the LD_LIBRARY_PATH environment variable with no success.  I was able
>
> > to symlink the libcrypto in the usr/local/lib directory, though, which
>
> > fixed the issue, but I agree this is a limitation.  A user should be
>
> > able to run more than one instance of libcrypto on the same host.  I'm
>
> > unsure as to the best way to proceed.
>
> >
>
> >
>
> > On Thu, Aug 27, 2020 at 6:41 PM Gary Gregory <ga...@gmail.com>
>
> > wrote:
>
> > >
>
> > > On Mon, Aug 24, 2020 at 7:28 PM Alex Remily <al...@gmail.com>
>
> > wrote:
>
> > >
>
> > > > Gary,
>
> > > >
>
> > > > Can you check that your libcrypto.dylib is symlinked to the libcrypto
>
> > > > for OpenSSL 1.1.1.g?  Mine wasn't, and I was getting different output
>
> > > > from the main function than from the unit test output.  I'm not
>
> > > > confident that this is the root of the problem, but it may at least
>
> > > > eliminate a possibility.
>
> > > >
>
> > > > On my machine I had to set /usr/local/lib/libcrypto.dylib -->
>
> > > > /usr/local/Cellar/openssl@1.1/1.1.1g/lib/libcrypto.1.1.dylib.  The
> JNI
>
> > > > libraries use dlopen to find and load libcrypto, and dlopen looks for
>
> > > >
>
> > >
>
> > > That did not work for me. The only thing that works is copying the
> dylib
>
> > > file to the current dir. Hack!
>
> > >
>
> > > Gary
>
> > >
>
> > >
>
> > > > it in /usr/local/lib/, among other places.
>
> > > >
>
> > > >
>
> > > >
>
> >
> https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/dlopen.3.html
>
> > > >
>
> > > > If that doesn't work I'm going to need to step through the code.  My
>
> > > > output:
>
> > > >
>
> > > > 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 24 2020
>
> > > > OpenSSL library loaded OK, version: 0x1010107f
>
> > > > OpenSSL library info OpenSSL 1.1.1g  21 Apr 2020
>
> > > > Random instance created OK
>
> > > > Cipher instance created OK
>
> > > > Additional OpenSSL_version(n) details:
>
> > > > 1: compiler: clang -fPIC -arch x86_64 -O3 -Wall -DL_ENDIAN
>
> > > > -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2
>
> > > > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
>
> > > > -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM
>
> > > > -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
>
> > > > -DX25519_ASM -DPOLY1305_ASM -D_REENTRANT -DNDEBUG
>
> > > > 2: built on: Tue Apr 21 13:29:43 2020 UTC
>
> > > > 3: platform: darwin64-x86_64-cc
>
> > > > 4: OPENSSLDIR: "/usr/local/etc/openssl@1.1"
>
> > > > 5: ENGINESDIR: "/usr/local/Cellar/openssl@1.1
> /1.1.1g/lib/engines-1.1"
>
> > > >
>
> > > > Alex
>
> > > >
>
> > > > On Sun, Aug 23, 2020 at 9:50 PM Gary Gregory <garydgregory@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 <al...@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 <
>
> > garydgregory@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 <
>
> > garydgregory@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-unsubscribe@commons.apache.org
>
> > > > > > For additional commands, e-mail: dev-help@commons.apache.org
>
> > > > > >
>
> > > > > >
>
> > > >
>
> > > > ---------------------------------------------------------------------
>
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>
> > > > For additional commands, e-mail: dev-help@commons.apache.org
>
> > > >
>
> > > >
>
> >
>
> > ---------------------------------------------------------------------
>
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>
> > For additional commands, e-mail: dev-help@commons.apache.org
>
> >
>
> >
>
> --
Matt Sicker <bo...@gmail.com>

Re: [Crypto] requesting help testing native binaries

Posted by Gary Gregory <ga...@gmail.com>.

The issue for me is that it was a PITA to override macos' baked in
(ancient) LibreSSL.

Gary

On Thu, Aug 27, 2020, 20:03 Alex Remily <al...@gmail.com> wrote:

> Interesting.  If I understand correctly, you did get it to run
> successfully to completion, but only after placing a compatible
> libcrypto in the directory of execution, probably the first place
> dlopen looks for it.  Would you agree then that the error was caused
> by loading an incompatible libcrypto?  I'm inclined to think this is a
> configuration issue that should be well documented, as opposed to one
> that should be addressed through code.  Like you, I also tried setting
> the LD_LIBRARY_PATH environment variable with no success.  I was able
> to symlink the libcrypto in the usr/local/lib directory, though, which
> fixed the issue, but I agree this is a limitation.  A user should be
> able to run more than one instance of libcrypto on the same host.  I'm
> unsure as to the best way to proceed.
>
>
> On Thu, Aug 27, 2020 at 6:41 PM Gary Gregory <ga...@gmail.com>
> wrote:
> >
> > On Mon, Aug 24, 2020 at 7:28 PM Alex Remily <al...@gmail.com>
> wrote:
> >
> > > Gary,
> > >
> > > Can you check that your libcrypto.dylib is symlinked to the libcrypto
> > > for OpenSSL 1.1.1.g?  Mine wasn't, and I was getting different output
> > > from the main function than from the unit test output.  I'm not
> > > confident that this is the root of the problem, but it may at least
> > > eliminate a possibility.
> > >
> > > On my machine I had to set /usr/local/lib/libcrypto.dylib -->
> > > /usr/local/Cellar/openssl@1.1/1.1.1g/lib/libcrypto.1.1.dylib.  The JNI
> > > libraries use dlopen to find and load libcrypto, and dlopen looks for
> > >
> >
> > That did not work for me. The only thing that works is copying the dylib
> > file to the current dir. Hack!
> >
> > Gary
> >
> >
> > > it in /usr/local/lib/, among other places.
> > >
> > >
> > >
> https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/dlopen.3.html
> > >
> > > If that doesn't work I'm going to need to step through the code.  My
> > > output:
> > >
> > > 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 24 2020
> > > OpenSSL library loaded OK, version: 0x1010107f
> > > OpenSSL library info OpenSSL 1.1.1g  21 Apr 2020
> > > Random instance created OK
> > > Cipher instance created OK
> > > Additional OpenSSL_version(n) details:
> > > 1: compiler: clang -fPIC -arch x86_64 -O3 -Wall -DL_ENDIAN
> > > -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2
> > > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
> > > -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM
> > > -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
> > > -DX25519_ASM -DPOLY1305_ASM -D_REENTRANT -DNDEBUG
> > > 2: built on: Tue Apr 21 13:29:43 2020 UTC
> > > 3: platform: darwin64-x86_64-cc
> > > 4: OPENSSLDIR: "/usr/local/etc/openssl@1.1"
> > > 5: ENGINESDIR: "/usr/local/Cellar/openssl@1.1/1.1.1g/lib/engines-1.1"
> > >
> > > Alex
> > >
> > > On Sun, Aug 23, 2020 at 9:50 PM Gary Gregory <ga...@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 <al...@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 <
> garydgregory@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 <
> garydgregory@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-unsubscribe@commons.apache.org
> > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: [Crypto] requesting help testing native binaries

Posted by Alex Remily <al...@gmail.com>.

Interesting.  If I understand correctly, you did get it to run
successfully to completion, but only after placing a compatible
libcrypto in the directory of execution, probably the first place
dlopen looks for it.  Would you agree then that the error was caused
by loading an incompatible libcrypto?  I'm inclined to think this is a
configuration issue that should be well documented, as opposed to one
that should be addressed through code.  Like you, I also tried setting
the LD_LIBRARY_PATH environment variable with no success.  I was able
to symlink the libcrypto in the usr/local/lib directory, though, which
fixed the issue, but I agree this is a limitation.  A user should be
able to run more than one instance of libcrypto on the same host.  I'm
unsure as to the best way to proceed.


On Thu, Aug 27, 2020 at 6:41 PM Gary Gregory <ga...@gmail.com> wrote:
>
> On Mon, Aug 24, 2020 at 7:28 PM Alex Remily <al...@gmail.com> wrote:
>
> > Gary,
> >
> > Can you check that your libcrypto.dylib is symlinked to the libcrypto
> > for OpenSSL 1.1.1.g?  Mine wasn't, and I was getting different output
> > from the main function than from the unit test output.  I'm not
> > confident that this is the root of the problem, but it may at least
> > eliminate a possibility.
> >
> > On my machine I had to set /usr/local/lib/libcrypto.dylib -->
> > /usr/local/Cellar/openssl@1.1/1.1.1g/lib/libcrypto.1.1.dylib.  The JNI
> > libraries use dlopen to find and load libcrypto, and dlopen looks for
> >
>
> That did not work for me. The only thing that works is copying the dylib
> file to the current dir. Hack!
>
> Gary
>
>
> > it in /usr/local/lib/, among other places.
> >
> >
> > https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/dlopen.3.html
> >
> > If that doesn't work I'm going to need to step through the code.  My
> > output:
> >
> > 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 24 2020
> > OpenSSL library loaded OK, version: 0x1010107f
> > OpenSSL library info OpenSSL 1.1.1g  21 Apr 2020
> > Random instance created OK
> > Cipher instance created OK
> > Additional OpenSSL_version(n) details:
> > 1: compiler: clang -fPIC -arch x86_64 -O3 -Wall -DL_ENDIAN
> > -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2
> > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
> > -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM
> > -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
> > -DX25519_ASM -DPOLY1305_ASM -D_REENTRANT -DNDEBUG
> > 2: built on: Tue Apr 21 13:29:43 2020 UTC
> > 3: platform: darwin64-x86_64-cc
> > 4: OPENSSLDIR: "/usr/local/etc/openssl@1.1"
> > 5: ENGINESDIR: "/usr/local/Cellar/openssl@1.1/1.1.1g/lib/engines-1.1"
> >
> > Alex
> >
> > On Sun, Aug 23, 2020 at 9:50 PM Gary Gregory <ga...@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 <al...@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 <ga...@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 <garydgregory@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-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [Crypto] requesting help testing native binaries

Posted by Gary Gregory <ga...@gmail.com>.

On Mon, Aug 24, 2020 at 7:28 PM Alex Remily <al...@gmail.com> wrote:

> Gary,
>
> Can you check that your libcrypto.dylib is symlinked to the libcrypto
> for OpenSSL 1.1.1.g?  Mine wasn't, and I was getting different output
> from the main function than from the unit test output.  I'm not
> confident that this is the root of the problem, but it may at least
> eliminate a possibility.
>
> On my machine I had to set /usr/local/lib/libcrypto.dylib -->
> /usr/local/Cellar/openssl@1.1/1.1.1g/lib/libcrypto.1.1.dylib.  The JNI
> libraries use dlopen to find and load libcrypto, and dlopen looks for
>

That did not work for me. The only thing that works is copying the dylib
file to the current dir. Hack!

Gary


> it in /usr/local/lib/, among other places.
>
>
> https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/dlopen.3.html
>
> If that doesn't work I'm going to need to step through the code.  My
> output:
>
> 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 24 2020
> OpenSSL library loaded OK, version: 0x1010107f
> OpenSSL library info OpenSSL 1.1.1g  21 Apr 2020
> Random instance created OK
> Cipher instance created OK
> Additional OpenSSL_version(n) details:
> 1: compiler: clang -fPIC -arch x86_64 -O3 -Wall -DL_ENDIAN
> -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM
> -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
> -DX25519_ASM -DPOLY1305_ASM -D_REENTRANT -DNDEBUG
> 2: built on: Tue Apr 21 13:29:43 2020 UTC
> 3: platform: darwin64-x86_64-cc
> 4: OPENSSLDIR: "/usr/local/etc/openssl@1.1"
> 5: ENGINESDIR: "/usr/local/Cellar/openssl@1.1/1.1.1g/lib/engines-1.1"
>
> Alex
>
> On Sun, Aug 23, 2020 at 9:50 PM Gary Gregory <ga...@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 <al...@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 <ga...@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 <garydgregory@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-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: [Crypto] requesting help testing native binaries

Posted by Alex Remily <al...@gmail.com>.

Gary,

Can you check that your libcrypto.dylib is symlinked to the libcrypto
for OpenSSL 1.1.1.g?  Mine wasn't, and I was getting different output
from the main function than from the unit test output.  I'm not
confident that this is the root of the problem, but it may at least
eliminate a possibility.

On my machine I had to set /usr/local/lib/libcrypto.dylib -->
/usr/local/Cellar/openssl@1.1/1.1.1g/lib/libcrypto.1.1.dylib.  The JNI
libraries use dlopen to find and load libcrypto, and dlopen looks for
it in /usr/local/lib/, among other places.

https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/dlopen.3.html

If that doesn't work I'm going to need to step through the code.  My output:

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 24 2020
OpenSSL library loaded OK, version: 0x1010107f
OpenSSL library info OpenSSL 1.1.1g  21 Apr 2020
Random instance created OK
Cipher instance created OK
Additional OpenSSL_version(n) details:
1: compiler: clang -fPIC -arch x86_64 -O3 -Wall -DL_ENDIAN
-DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM
-DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
-DX25519_ASM -DPOLY1305_ASM -D_REENTRANT -DNDEBUG
2: built on: Tue Apr 21 13:29:43 2020 UTC
3: platform: darwin64-x86_64-cc
4: OPENSSLDIR: "/usr/local/etc/openssl@1.1"
5: ENGINESDIR: "/usr/local/Cellar/openssl@1.1/1.1.1g/lib/engines-1.1"

Alex

On Sun, Aug 23, 2020 at 9:50 PM Gary Gregory <ga...@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 <al...@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 <ga...@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 <ga...@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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [Crypto] requesting help testing native binaries

Posted by Alex Remily <al...@gmail.com>.

Let me see if I can reproduce the error.  I'm just speculating from
memory at this point.

On Sun, Aug 23, 2020 at 9:50 PM Gary Gregory <ga...@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 <al...@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 <ga...@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 <ga...@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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [Crypto] requesting help testing native binaries

Posted by Gary Gregory <ga...@gmail.com>.

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 <al...@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 <ga...@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 <ga...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: [Crypto] requesting help testing native binaries

Posted by Alex Remily <al...@gmail.com>.

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 <ga...@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 <ga...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [Crypto] requesting help testing native binaries

Posted by Gary Gregory <ga...@gmail.com>.

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

Re: [Crypto] requesting help testing native binaries

Posted by Gary Gregory <ga...@gmail.com>.

Thanks Alex, updating tally:

Here is what community testing we have so far for the Crypto.main() smoke
test:

- darwin64-x86_64-cc; OpenSSL 1.1.1g; Gary Gregory, Alex Remily
- debian-amd64; OpenSSL 1.0.1f; Gary Gregory
- debian-amd64; OpenSSL 1.1.1g; Bruno P. Kinoshita
- Linux x86_64; OpenSSL 1.1.1; Alex Remily
- Windows 64 (mingw64); OpenSSL 1.1.1d; Alex Remily

Gary

On Thu, Aug 27, 2020 at 7:28 PM Alex Remily <al...@gmail.com> wrote:

> Gary,
>
> You can add the Windows 64 build.  Unit tests passed as expected and
> main function output is:
>
> Apache Commons Crypto 1.1.0-SNAPSHOT
> Native code loaded OK: 1.1.0-SNAPSHOT
> Native name: Apache Commons Crypto
> Native built: Aug 16 2020
> OpenSSL library loaded OK, version: 0x1010104f
> OpenSSL library info: OpenSSL 1.1.1d  10 Sep 2019
> Random instance created OK:
> org.apache.commons.crypto.random.OpenSslCryptoRandom@482f8f11
> Cipher AES/CTR/NoPadding instance created OK:
> org.apache.commons.crypto.cipher.OpenSslCipher@4b9e13df
> Additional OpenSSL_version(n) details:
> 1: compiler: x86_64-w64-mingw32-gcc -m64 -Wall -O3 -fno-ident
> -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPU
> ID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
> -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1
> _ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM
> -DVPAES_ASM -DGHASH_ASM -DECP_NI
> STZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DUNICODE -D_UNICODE
> -DWIN32_LEAN_AND_MEAN -D_MT -DNDEBUG
> 2: built on: Tue Sep 10 13:13:07 2019 UTC
> 3: platform: mingw64
> 4: OPENSSLDIR: "C:/Windows/System32/OpenSSL/ssl"
> 5: ENGINESDIR: "C:/Windows/System32/OpenSSL/lib/engines-1_1"
>
> On Thu, Aug 27, 2020 at 6:51 PM Gary Gregory <ga...@gmail.com>
> wrote:
> >
> > Here is what community testing we have so far for the Crypto.main() smoke
> > test:
> >
> > - darwin64-x86_64-cc; OpenSSL 1.1.1g; Gary Gregory, Alex Remily
> > - debian-amd64; OpenSSL 1.0.1f; Gary Gregory
> > - debian-amd64; OpenSSL 1.1.1g; Bruno P. Kinoshita
> > - Linux x86_64; OpenSSL 1.1.1; Alex Remily
> >
> > Gary
> >
> >
> > On Sat, Aug 22, 2020 at 7:48 PM Gary Gregory <ga...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: [Crypto] requesting help testing native binaries

Posted by Alex Remily <al...@gmail.com>.

Gary,

You can add the Windows 64 build.  Unit tests passed as expected and
main function output is:

Apache Commons Crypto 1.1.0-SNAPSHOT
Native code loaded OK: 1.1.0-SNAPSHOT
Native name: Apache Commons Crypto
Native built: Aug 16 2020
OpenSSL library loaded OK, version: 0x1010104f
OpenSSL library info: OpenSSL 1.1.1d  10 Sep 2019
Random instance created OK:
org.apache.commons.crypto.random.OpenSslCryptoRandom@482f8f11
Cipher AES/CTR/NoPadding instance created OK:
org.apache.commons.crypto.cipher.OpenSslCipher@4b9e13df
Additional OpenSSL_version(n) details:
1: compiler: x86_64-w64-mingw32-gcc -m64 -Wall -O3 -fno-ident
-DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPU
ID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
-DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1
_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM
-DVPAES_ASM -DGHASH_ASM -DECP_NI
STZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DUNICODE -D_UNICODE
-DWIN32_LEAN_AND_MEAN -D_MT -DNDEBUG
2: built on: Tue Sep 10 13:13:07 2019 UTC
3: platform: mingw64
4: OPENSSLDIR: "C:/Windows/System32/OpenSSL/ssl"
5: ENGINESDIR: "C:/Windows/System32/OpenSSL/lib/engines-1_1"

On Thu, Aug 27, 2020 at 6:51 PM Gary Gregory <ga...@gmail.com> wrote:
>
> Here is what community testing we have so far for the Crypto.main() smoke
> test:
>
> - darwin64-x86_64-cc; OpenSSL 1.1.1g; Gary Gregory, Alex Remily
> - debian-amd64; OpenSSL 1.0.1f; Gary Gregory
> - debian-amd64; OpenSSL 1.1.1g; Bruno P. Kinoshita
> - Linux x86_64; OpenSSL 1.1.1; Alex Remily
>
> Gary
>
>
> On Sat, Aug 22, 2020 at 7:48 PM Gary Gregory <ga...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [Crypto] requesting help testing native binaries

Posted by Gary Gregory <ga...@gmail.com>.

Here is what community testing we have so far for the Crypto.main() smoke
test:

- darwin64-x86_64-cc; OpenSSL 1.1.1g; Gary Gregory, Alex Remily
- debian-amd64; OpenSSL 1.0.1f; Gary Gregory
- debian-amd64; OpenSSL 1.1.1g; Bruno P. Kinoshita
- Linux x86_64; OpenSSL 1.1.1; Alex Remily

Gary


On Sat, Aug 22, 2020 at 7:48 PM Gary Gregory <ga...@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
>
>
>

Re: [Crypto] requesting help testing native binaries

Posted by Gary Gregory <ga...@gmail.com>.

On Sun, Aug 23, 2020 at 8:31 AM Alex Remily <al...@gmail.com> wrote:

> Gary,
>
> I can test the 64 bit Mac, Windows and Linx builds this week.  Did you
> want to include this test fix in the snapshot:
>
> https://issues.apache.org/jira/browse/CRYPTO-149
>
> There's a pending PR with the fix.  It's only one line of code so it
> should merge easily.
>

Done.

Gary


>
> In the past I've had some success testing builds by running the
> project test code against the binary as a dependency, similar to what
> Xeno described earlier.
>
> Thanks again,
>
> Alex
>
> On Sat, Aug 22, 2020 at 7:49 PM Gary Gregory <ga...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: [Crypto] requesting help testing native binaries

Posted by Alex Remily <al...@gmail.com>.

Gary,

I can test the 64 bit Mac, Windows and Linx builds this week.  Did you
want to include this test fix in the snapshot:

https://issues.apache.org/jira/browse/CRYPTO-149

There's a pending PR with the fix.  It's only one line of code so it
should merge easily.

In the past I've had some success testing builds by running the
project test code against the binary as a dependency, similar to what
Xeno described earlier.

Thanks again,

Alex

On Sat, Aug 22, 2020 at 7:49 PM Gary Gregory <ga...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org