date:20220629

Re: [collections] JMH results for IndexedLinkedList

2022-06-29 Thread Rodion Efremov

Hi Matt and community,

Have you take a look at my work? If so, what do you think?

Best regards,
rodde

to 23.6.2022 klo 19.06 Matt Juntunen  kirjoitti:

> Hello,
>
> Thanks for providing the data here. I will hopefully have time to take
> a look at this over the weekend. Send me a ping here on the dev list
> if you don't hear back from me (or someone else) within a week.
>
> Regards,
> Matt J
>
> On Tue, Jun 21, 2022 at 7:22 AM Rodion Efremov 
> wrote:
> >
> > Hi,
> >
> > Data structure: IndexedLinkedList
> > 
> > Benchmark: IndexedLinkedListBenchmark
> > 
> >
> > Benchmark output:
> > https://github.com/coderodde/indexedLinkedList/#benchmark-output
> >
> > From the benchmark output, we can judge that IndexedLinkedList
> outperforms
> > both java.util.LinkedList and the Apache Commons Collections TreeList.
> It,
> > however, does not seem to supersede the java.util.ArrayList.
> >
> > Basically, I would expect the IndexedLinkedList to beat the ArrayList
> where
> > we have a lot of following operations:
> >
> >- addFirst(E)
> >- add(int, E)
> >- remove(int)
> >
> > So, what do you think? I am getting anywhere with that?
> >
> > Best regards,
> > rodde
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[VOTE] Release Apache Commons Configuration 2.8.0 based on RC3

2022-06-29 Thread Matt Juntunen

We have fixed quite a few bugs and added some significant enhancements
since Apache Commons Configuration 2.7 was released, so I would like
to release Apache Commons Configuration 2.8.0.

Apache Commons Configuration 2.8.0 RC3 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/configuration/2.8.0-RC3
(svn revision 55351)

The Git tag commons-configuration-2.8.0-RC3 commit for this RC is
59e5152722198526c6ffe5361de7d1a6a87275c7 which you can browse here:

https://gitbox.apache.org/repos/asf?p=commons-configuration.git;a=commit;h=59e5152722198526c6ffe5361de7d1a6a87275c7
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-configuration.git
--branch commons-configuration-2.8.0-RC3
commons-configuration-2.8.0-RC3

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1591/org/apache/commons/commons-configuration2/2.8.0/

These are the artifacts and their hashes:

#Release SHA-512s
#Thu Jun 30 00:04:49 EDT 2022
commons-configuration2-2.8.0-bin.tar.gz=7f60d1d67e10f2198f2863bb374de79a1dcfd777bc56201407b9d8015a187f9bb63b853449a402a60bb0f8c459108d1dcee06d792865a500627388d21f122ccd
commons-configuration2-2.8.0-bin.zip=4f9f8d2d6ea1948cc91dc31b6fb07d0bdc1b359bd7f67685c1f8306aa93b8326ec30f4818176f3da5bae267b121f020e7a0f9dd8f6f055066fab3cbb9aebfa54
commons-configuration2-2.8.0-javadoc.jar=80cca911d1bd58e3a460fc5c8ecd2129eccf84ec9e788b13dd53750454a9966cae3662f2d3af4c1eb7864b850ac36e4f4d7ee39bc842a70ca3aeefaeab94f128
commons-configuration2-2.8.0-sources.jar=6d52b9e84c522bb908492028117da786ca041e10ba456bf2162d4ede5467a8e53a4dc05d4338d9e29b445129a7707f2f8bfa8c8590c23777012649333686609e
commons-configuration2-2.8.0-src.tar.gz=0f73494a124f35cf4c781ca53aadc48dfff77b543a8dc9e91d781a35b4c643ca1c06bae55c1a38fbbc234cfa7aefd89862cb74bd64db56806e11de90622e8694
commons-configuration2-2.8.0-src.zip=128a33001733e97d4960ad2a89ab90b717a79a9a522263ed9e1aeb4e62bd1298e9e0e9cd7918a1693f75c35168edb9d2257b0b6f4fa246cbcc3865ada7959c11
commons-configuration2-2.8.0-test-sources.jar=8dd085a5cd1f07f274f067e618a74d7149662b1ea27b6253df2d8073ba7afde8c58ebfde9817e146f88ebb69ea7381f36a140253249113426bad5b8851ae8626
commons-configuration2-2.8.0-tests.jar=17648ae07d2cfbae0eab7c18a2bd6adf2c9f03b72161c51055bb19d166ca1f6bd6ca4feec999cb747137895fb020fe7bf6c20a873a9ae4c3fa79a30cb159c26e

I have tested this with ***'mvn clean install site'*** using:
***
Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: /home/matt/tools/maven/apache-maven-3.8.4
Java version: 1.8.0_322, vendor: Temurin, runtime:
/home/matt/lang/java/jdk8u322-b06/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.18.6-200.fc36.x86_64", arch: "amd64",
family: "unix"

Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: /home/matt/tools/maven/apache-maven-3.8.4
Java version: 11.0.14.1, vendor: Eclipse Adoptium, runtime:
/home/matt/lang/java/jdk-11.0.14.1+1
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.18.6-200.fc36.x86_64", arch: "amd64",
family: "unix"
***

Details of changes since 2.7 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/configuration/2.8.0-RC3/RELEASE-NOTES.txt

https://dist.apache.org/repos/dist/dev/commons/configuration/2.8.0-RC3/site/changes-report.html

Site:

https://dist.apache.org/repos/dist/dev/commons/configuration/2.8.0-RC3/site/index.html
(note some *relative* links are broken and the 2.8.0 directories
are not yet created - these will be OK once the site is deployed.)

JApiCmp Report (compared to 2.7):

https://dist.apache.org/repos/dist/dev/commons/configuration/2.8.0-RC3/site/japicmp.html

RAT Report:

https://dist.apache.org/repos/dist/dev/commons/configuration/2.8.0-RC3/site/rat-report.html

KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thank you,

Matt Juntunen,
Release Manager (using key 7DD53AEFEDF1C3D392B51EBE346F4FCECFB70B1A)

For following is intended as a helper and refresher for reviewers.

Validating a release candidate
==

These guidelines are NOT complete.

Requirements: Git, Java, Maven.

You can validate a release from a release candidate (RC) tag as follows.

1) Clone and checkout the RC tag

git clone https://gitbox.apache.org/repos/asf/commons-configuration.git
--branch commons-configuration-2.8.0-RC3
commons-configuration-2.8.0-RC3
cd commons-configuration-2.8.0-RC3

2) Check Apache licenses

This step is not required if the site includes a RAT report page which
you then must check.

mvn apache-rat:check

3) Check binary compatibility

Older components still use Apache Clirr:

This step is not required if the site

Re: [CRYPTO] Problem with JNA on macOS and Windows

2022-06-29 Thread Matt Sicker

The only OpenSSL fork I know of in macOS is BoringSSL which is also used by 
Chrome. This fork maintains some level of compatibility though.

—
Matt Sicker

> On Jun 29, 2022, at 20:03, Alex Remily  wrote:
> 
> Which Mac OS version did you use?  Since I upgraded to BigSur (OS 11) my
> Commons Crypto builds fail.  I think Apple moved a bunch of the developer
> libraries, but I haven't taken the time to troubleshoot.
> 
>> On Wed, Jun 29, 2022 at 8:55 PM Gary Gregory  wrote:
>> 
>> Arg, idiotic line wrapping removed: https://pastebin.com/raw/nPczrrd8
>> 
>> Gary
>> 
>>> On Wed, Jun 29, 2022 at 8:49 PM Gary Gregory 
>>> wrote:
>>> 
>>> FWIW, I just checked out the rel/commons-crypto-1.1.0 on macOS and ran
>>> 'mvn clean verify' and everything built just fine.
>>> 
>>> The Maven ant-run output was:
>>> 
>>> [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto ---
>>> [INFO] Executing tasks
>>> 
>>> make:
>>> [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah" -force
>>> -classpath target/classes -o
>>> 
>> target/jni-classes/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.h
>>> org.apache.commons.crypto.random.OpenSslCryptoRandomNative
>>> [exec] gcc -arch x86_64 -Ilib/inc_mac
>>> -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
>>> -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
>>> -I/usr/local/opt/openssl/include -Ilib/include -I/usr/include
>>> -I"src/main/native/org/apache/commons/crypto/"
>>> -I"/usr/local/Cellar/openjdk@8
>> /1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
>>> -I"target/jni-classes/org/apache/commons/crypto/cipher"
>>> -I"target/jni-classes/org/apache/commons/crypto/random" -c
>>> 
>> src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c
>>> -o target/commons-crypto-1.1.0-Mac-x86_64/OpenSslCryptoRandomNative.o
>>> [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah" -force
>>> -classpath target/classes -o
>>> target/jni-classes/org/apache/commons/crypto/cipher/OpenSslNative.h
>>> org.apache.commons.crypto.cipher.OpenSslNative
>>> [exec] gcc -arch x86_64 -Ilib/inc_mac
>>> -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
>>> -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
>>> -I/usr/local/opt/openssl/include -Ilib/include -I/usr/include
>>> -I"src/main/native/org/apache/commons/crypto/"
>>> -I"/usr/local/Cellar/openjdk@8
>> /1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
>>> -I"target/jni-classes/org/apache/commons/crypto/cipher"
>>> -I"target/jni-classes/org/apache/commons/crypto/random" -c
>>> src/main/native/org/apache/commons/crypto/cipher/OpenSslNative.c -o
>>> target/commons-crypto-1.1.0-Mac-x86_64/OpenSslNative.o
>>> [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah" -force
>>> -classpath target/classes -o
>>> target/jni-classes/org/apache/commons/crypto/OpenSslInfoNative.h
>>> org.apache.commons.crypto.OpenSslInfoNative
>>> [exec] gcc -arch x86_64 -Ilib/inc_mac
>>> -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
>>> -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
>>> -I/usr/local/opt/openssl/include -Ilib/include -I/usr/include
>>> -I"src/main/native/org/apache/commons/crypto/"
>>> -I"/usr/local/Cellar/openjdk@8
>> /1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
>>> -I"target/jni-classes/org/apache/commons/crypto/cipher"
>>> -I"target/jni-classes/org/apache/commons/crypto/random"
>>> -DVERSION='"1.1.0"' -DPROJECT_NAME='"Apache Commons Crypto"'
>>> -I"target/jni-classes/org/apache/commons/crypto" -c
>>> src/main/native/org/apache/commons/crypto/OpenSslInfoNative.c -o
>>> target/commons-crypto-1.1.0-Mac-x86_64/OpenSslInfoNative.o
>>> [exec] gcc -arch x86_64 -Ilib/inc_mac
>>> -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
>>> -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
>>> -I/usr/local/opt/openssl/include -Ilib/include  -I/usr/include
>>> -I"/usr/local/Cellar/openjdk@8
>> /1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
>>> -I"target/jni-classes/org/apache/commons/crypto/cipher"
>>> -I"target/jni-classes/org/apache/commons/crypto/random" -o
>>> target/commons-crypto-1.1.0-Mac-x86_64/libcommons-crypto.jnilib
>>> target/commons-crypto-1.1.0-Mac-x86_64/OpenSslCryptoRandomNative.o
>>> target/commons-crypto-1.1.0-Mac-x86_64/OpenSslNative.o
>>> target/commons-crypto-1.1.0-Mac-x86_64/OpenSslInfoNative.o -dynamiclib
>>> -L/usr/local/lib
>>> [exec] strip -x
>>> target/commons-crypto-1.1.0-Mac-x86_64/libcommons-crypto.jnilib
>>> [exec] cp
>> target/commons-crypto-1.1.0-Mac-x86_64/libcommons-crypto.jnilib
>>> 
>> target/classes/org/apache/commons/crypto/native/Mac/x86_64/libcommons-crypto.jnilib
>>> [exec] cp
>> target/commons-crypto-1.1.0-Mac-x86_64/libcommons-crypto.jnilib
>>> 
>> target/classes/org/apache/commons/crypto/native/Mac/x86_64/libcommons-crypto.jnilib
>>> 
>>> Gary
>>> 
>>> On Wed, Jun 29, 2022 at 8:48 PM

Re: [CRYPTO] Problem with JNA on macOS and Windows

2022-06-29 Thread Alex Remily

Which Mac OS version did you use?  Since I upgraded to BigSur (OS 11) my
Commons Crypto builds fail.  I think Apple moved a bunch of the developer
libraries, but I haven't taken the time to troubleshoot.

On Wed, Jun 29, 2022 at 8:55 PM Gary Gregory  wrote:

> Arg, idiotic line wrapping removed: https://pastebin.com/raw/nPczrrd8
>
> Gary
>
> On Wed, Jun 29, 2022 at 8:49 PM Gary Gregory 
> wrote:
> >
> > FWIW, I just checked out the rel/commons-crypto-1.1.0 on macOS and ran
> > 'mvn clean verify' and everything built just fine.
> >
> > The Maven ant-run output was:
> >
> > [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto ---
> > [INFO] Executing tasks
> >
> > make:
> >  [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah" -force
> > -classpath target/classes -o
> >
> target/jni-classes/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.h
> > org.apache.commons.crypto.random.OpenSslCryptoRandomNative
> >  [exec] gcc -arch x86_64 -Ilib/inc_mac
> > -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
> > -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
> > -I/usr/local/opt/openssl/include -Ilib/include -I/usr/include
> > -I"src/main/native/org/apache/commons/crypto/"
> > -I"/usr/local/Cellar/openjdk@8
> /1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
> > -I"target/jni-classes/org/apache/commons/crypto/cipher"
> > -I"target/jni-classes/org/apache/commons/crypto/random" -c
> >
> src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c
> > -o target/commons-crypto-1.1.0-Mac-x86_64/OpenSslCryptoRandomNative.o
> >  [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah" -force
> > -classpath target/classes -o
> > target/jni-classes/org/apache/commons/crypto/cipher/OpenSslNative.h
> > org.apache.commons.crypto.cipher.OpenSslNative
> >  [exec] gcc -arch x86_64 -Ilib/inc_mac
> > -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
> > -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
> > -I/usr/local/opt/openssl/include -Ilib/include -I/usr/include
> > -I"src/main/native/org/apache/commons/crypto/"
> > -I"/usr/local/Cellar/openjdk@8
> /1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
> > -I"target/jni-classes/org/apache/commons/crypto/cipher"
> > -I"target/jni-classes/org/apache/commons/crypto/random" -c
> > src/main/native/org/apache/commons/crypto/cipher/OpenSslNative.c -o
> > target/commons-crypto-1.1.0-Mac-x86_64/OpenSslNative.o
> >  [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah" -force
> > -classpath target/classes -o
> > target/jni-classes/org/apache/commons/crypto/OpenSslInfoNative.h
> > org.apache.commons.crypto.OpenSslInfoNative
> >  [exec] gcc -arch x86_64 -Ilib/inc_mac
> > -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
> > -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
> > -I/usr/local/opt/openssl/include -Ilib/include -I/usr/include
> > -I"src/main/native/org/apache/commons/crypto/"
> > -I"/usr/local/Cellar/openjdk@8
> /1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
> > -I"target/jni-classes/org/apache/commons/crypto/cipher"
> > -I"target/jni-classes/org/apache/commons/crypto/random"
> > -DVERSION='"1.1.0"' -DPROJECT_NAME='"Apache Commons Crypto"'
> > -I"target/jni-classes/org/apache/commons/crypto" -c
> > src/main/native/org/apache/commons/crypto/OpenSslInfoNative.c -o
> > target/commons-crypto-1.1.0-Mac-x86_64/OpenSslInfoNative.o
> >  [exec] gcc -arch x86_64 -Ilib/inc_mac
> > -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
> > -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
> > -I/usr/local/opt/openssl/include -Ilib/include  -I/usr/include
> > -I"/usr/local/Cellar/openjdk@8
> /1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
> > -I"target/jni-classes/org/apache/commons/crypto/cipher"
> > -I"target/jni-classes/org/apache/commons/crypto/random" -o
> > target/commons-crypto-1.1.0-Mac-x86_64/libcommons-crypto.jnilib
> > target/commons-crypto-1.1.0-Mac-x86_64/OpenSslCryptoRandomNative.o
> > target/commons-crypto-1.1.0-Mac-x86_64/OpenSslNative.o
> > target/commons-crypto-1.1.0-Mac-x86_64/OpenSslInfoNative.o -dynamiclib
> > -L/usr/local/lib
> >  [exec] strip -x
> > target/commons-crypto-1.1.0-Mac-x86_64/libcommons-crypto.jnilib
> >  [exec] cp
> target/commons-crypto-1.1.0-Mac-x86_64/libcommons-crypto.jnilib
> >
> target/classes/org/apache/commons/crypto/native/Mac/x86_64/libcommons-crypto.jnilib
> >  [exec] cp
> target/commons-crypto-1.1.0-Mac-x86_64/libcommons-crypto.jnilib
> >
> target/classes/org/apache/commons/crypto/native/Mac/x86_64/libcommons-crypto.jnilib
> >
> > Gary
> >
> > On Wed, Jun 29, 2022 at 8:48 PM Gary Gregory 
> wrote:
> > >
> > > I agree with Alex.
> > >
> > > Forget LibreSSL. Commons Crypto is for OpenSSL, nice, simple, and
> > > tight. Last time I checked I had an antique version of LibreSSL on my
> > > mac years ago, I just installed

Re: [CRYPTO] Problem with JNA on macOS and Windows

2022-06-29 Thread Gary Gregory

Arg, idiotic line wrapping removed: https://pastebin.com/raw/nPczrrd8

Gary

On Wed, Jun 29, 2022 at 8:49 PM Gary Gregory  wrote:
>
> FWIW, I just checked out the rel/commons-crypto-1.1.0 on macOS and ran
> 'mvn clean verify' and everything built just fine.
>
> The Maven ant-run output was:
>
> [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto ---
> [INFO] Executing tasks
>
> make:
>  [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah" -force
> -classpath target/classes -o
> target/jni-classes/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.h
> org.apache.commons.crypto.random.OpenSslCryptoRandomNative
>  [exec] gcc -arch x86_64 -Ilib/inc_mac
> -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
> -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
> -I/usr/local/opt/openssl/include -Ilib/include -I/usr/include
> -I"src/main/native/org/apache/commons/crypto/"
> -I"/usr/local/Cellar/openjdk@8/1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
> -I"target/jni-classes/org/apache/commons/crypto/cipher"
> -I"target/jni-classes/org/apache/commons/crypto/random" -c
> src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c
> -o target/commons-crypto-1.1.0-Mac-x86_64/OpenSslCryptoRandomNative.o
>  [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah" -force
> -classpath target/classes -o
> target/jni-classes/org/apache/commons/crypto/cipher/OpenSslNative.h
> org.apache.commons.crypto.cipher.OpenSslNative
>  [exec] gcc -arch x86_64 -Ilib/inc_mac
> -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
> -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
> -I/usr/local/opt/openssl/include -Ilib/include -I/usr/include
> -I"src/main/native/org/apache/commons/crypto/"
> -I"/usr/local/Cellar/openjdk@8/1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
> -I"target/jni-classes/org/apache/commons/crypto/cipher"
> -I"target/jni-classes/org/apache/commons/crypto/random" -c
> src/main/native/org/apache/commons/crypto/cipher/OpenSslNative.c -o
> target/commons-crypto-1.1.0-Mac-x86_64/OpenSslNative.o
>  [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah" -force
> -classpath target/classes -o
> target/jni-classes/org/apache/commons/crypto/OpenSslInfoNative.h
> org.apache.commons.crypto.OpenSslInfoNative
>  [exec] gcc -arch x86_64 -Ilib/inc_mac
> -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
> -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
> -I/usr/local/opt/openssl/include -Ilib/include -I/usr/include
> -I"src/main/native/org/apache/commons/crypto/"
> -I"/usr/local/Cellar/openjdk@8/1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
> -I"target/jni-classes/org/apache/commons/crypto/cipher"
> -I"target/jni-classes/org/apache/commons/crypto/random"
> -DVERSION='"1.1.0"' -DPROJECT_NAME='"Apache Commons Crypto"'
> -I"target/jni-classes/org/apache/commons/crypto" -c
> src/main/native/org/apache/commons/crypto/OpenSslInfoNative.c -o
> target/commons-crypto-1.1.0-Mac-x86_64/OpenSslInfoNative.o
>  [exec] gcc -arch x86_64 -Ilib/inc_mac
> -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
> -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
> -I/usr/local/opt/openssl/include -Ilib/include  -I/usr/include
> -I"/usr/local/Cellar/openjdk@8/1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
> -I"target/jni-classes/org/apache/commons/crypto/cipher"
> -I"target/jni-classes/org/apache/commons/crypto/random" -o
> target/commons-crypto-1.1.0-Mac-x86_64/libcommons-crypto.jnilib
> target/commons-crypto-1.1.0-Mac-x86_64/OpenSslCryptoRandomNative.o
> target/commons-crypto-1.1.0-Mac-x86_64/OpenSslNative.o
> target/commons-crypto-1.1.0-Mac-x86_64/OpenSslInfoNative.o -dynamiclib
> -L/usr/local/lib
>  [exec] strip -x
> target/commons-crypto-1.1.0-Mac-x86_64/libcommons-crypto.jnilib
>  [exec] cp target/commons-crypto-1.1.0-Mac-x86_64/libcommons-crypto.jnilib
> target/classes/org/apache/commons/crypto/native/Mac/x86_64/libcommons-crypto.jnilib
>  [exec] cp target/commons-crypto-1.1.0-Mac-x86_64/libcommons-crypto.jnilib
> target/classes/org/apache/commons/crypto/native/Mac/x86_64/libcommons-crypto.jnilib
>
> Gary
>
> On Wed, Jun 29, 2022 at 8:48 PM Gary Gregory  wrote:
> >
> > I agree with Alex.
> >
> > Forget LibreSSL. Commons Crypto is for OpenSSL, nice, simple, and
> > tight. Last time I checked I had an antique version of LibreSSL on my
> > mac years ago, I just installed OpenSSL and never looked back.
> >
> > Gary
> >
> > On Wed, Jun 29, 2022 at 8:11 PM Alex Remily  wrote:
> > >
> > >  > > issues with JNA on macOS and Windows, and if so, whether this needs to
> > > be done for the current or a later release. If we don't fix this
> > > release, obviously it needs some mention in the release notes.>
> > >
> > > I wouldn't characterize the issues running against LibreSSL as
> > > "undetected".  I also don't see this as an

Re: [CRYPTO] Problem with JNA on macOS and Windows

2022-06-29 Thread Gary Gregory

FWIW, I just checked out the rel/commons-crypto-1.1.0 on macOS and ran
'mvn clean verify' and everything built just fine.

The Maven ant-run output was:

[INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto ---
[INFO] Executing tasks

make:
 [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah" -force
-classpath target/classes -o
target/jni-classes/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.h
org.apache.commons.crypto.random.OpenSslCryptoRandomNative
 [exec] gcc -arch x86_64 -Ilib/inc_mac
-I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
-mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
-I/usr/local/opt/openssl/include -Ilib/include -I/usr/include
-I"src/main/native/org/apache/commons/crypto/"
-I"/usr/local/Cellar/openjdk@8/1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
-I"target/jni-classes/org/apache/commons/crypto/cipher"
-I"target/jni-classes/org/apache/commons/crypto/random" -c
src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c
-o target/commons-crypto-1.1.0-Mac-x86_64/OpenSslCryptoRandomNative.o
 [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah" -force
-classpath target/classes -o
target/jni-classes/org/apache/commons/crypto/cipher/OpenSslNative.h
org.apache.commons.crypto.cipher.OpenSslNative
 [exec] gcc -arch x86_64 -Ilib/inc_mac
-I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
-mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
-I/usr/local/opt/openssl/include -Ilib/include -I/usr/include
-I"src/main/native/org/apache/commons/crypto/"
-I"/usr/local/Cellar/openjdk@8/1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
-I"target/jni-classes/org/apache/commons/crypto/cipher"
-I"target/jni-classes/org/apache/commons/crypto/random" -c
src/main/native/org/apache/commons/crypto/cipher/OpenSslNative.c -o
target/commons-crypto-1.1.0-Mac-x86_64/OpenSslNative.o
 [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah" -force
-classpath target/classes -o
target/jni-classes/org/apache/commons/crypto/OpenSslInfoNative.h
org.apache.commons.crypto.OpenSslInfoNative
 [exec] gcc -arch x86_64 -Ilib/inc_mac
-I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
-mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
-I/usr/local/opt/openssl/include -Ilib/include -I/usr/include
-I"src/main/native/org/apache/commons/crypto/"
-I"/usr/local/Cellar/openjdk@8/1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
-I"target/jni-classes/org/apache/commons/crypto/cipher"
-I"target/jni-classes/org/apache/commons/crypto/random"
-DVERSION='"1.1.0"' -DPROJECT_NAME='"Apache Commons Crypto"'
-I"target/jni-classes/org/apache/commons/crypto" -c
src/main/native/org/apache/commons/crypto/OpenSslInfoNative.c -o
target/commons-crypto-1.1.0-Mac-x86_64/OpenSslInfoNative.o
 [exec] gcc -arch x86_64 -Ilib/inc_mac
-I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
-mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
-I/usr/local/opt/openssl/include -Ilib/include  -I/usr/include
-I"/usr/local/Cellar/openjdk@8/1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
-I"target/jni-classes/org/apache/commons/crypto/cipher"
-I"target/jni-classes/org/apache/commons/crypto/random" -o
target/commons-crypto-1.1.0-Mac-x86_64/libcommons-crypto.jnilib
target/commons-crypto-1.1.0-Mac-x86_64/OpenSslCryptoRandomNative.o
target/commons-crypto-1.1.0-Mac-x86_64/OpenSslNative.o
target/commons-crypto-1.1.0-Mac-x86_64/OpenSslInfoNative.o -dynamiclib
-L/usr/local/lib
 [exec] strip -x
target/commons-crypto-1.1.0-Mac-x86_64/libcommons-crypto.jnilib
 [exec] cp target/commons-crypto-1.1.0-Mac-x86_64/libcommons-crypto.jnilib
target/classes/org/apache/commons/crypto/native/Mac/x86_64/libcommons-crypto.jnilib
 [exec] cp target/commons-crypto-1.1.0-Mac-x86_64/libcommons-crypto.jnilib
target/classes/org/apache/commons/crypto/native/Mac/x86_64/libcommons-crypto.jnilib

Gary

On Wed, Jun 29, 2022 at 8:48 PM Gary Gregory  wrote:
>
> I agree with Alex.
>
> Forget LibreSSL. Commons Crypto is for OpenSSL, nice, simple, and
> tight. Last time I checked I had an antique version of LibreSSL on my
> mac years ago, I just installed OpenSSL and never looked back.
>
> Gary
>
> On Wed, Jun 29, 2022 at 8:11 PM Alex Remily  wrote:
> >
> >  > issues with JNA on macOS and Windows, and if so, whether this needs to
> > be done for the current or a later release. If we don't fix this
> > release, obviously it needs some mention in the release notes.>
> >
> > I wouldn't characterize the issues running against LibreSSL as
> > "undetected".  I also don't see this as an issue with Mac or Windows, but
> > with LibreSSL.  Install any supported OpenSSL library on any supported
> > architecture (to include Mac and Windows) and all commons crypto
> > functionality is available.  I first encountered the rand issue you
> > describe years ago when I was becoming familiar with commons

Re: [CRYPTO] Problem with JNA on macOS and Windows

2022-06-29 Thread Gary Gregory

I agree with Alex.

Forget LibreSSL. Commons Crypto is for OpenSSL, nice, simple, and
tight. Last time I checked I had an antique version of LibreSSL on my
mac years ago, I just installed OpenSSL and never looked back.

Gary

On Wed, Jun 29, 2022 at 8:11 PM Alex Remily  wrote:
>
>  issues with JNA on macOS and Windows, and if so, whether this needs to
> be done for the current or a later release. If we don't fix this
> release, obviously it needs some mention in the release notes.>
>
> I wouldn't characterize the issues running against LibreSSL as
> "undetected".  I also don't see this as an issue with Mac or Windows, but
> with LibreSSL.  Install any supported OpenSSL library on any supported
> architecture (to include Mac and Windows) and all commons crypto
> functionality is available.  I first encountered the rand issue you
> describe years ago when I was becoming familiar with commons crypto.  I did
> a little research, discovered that I was running LibreSSL (and an old
> version at that), installed a supported version of OpenSSL and forgot
> all about it until this thread.  I don't think it's unreasonable to expect
> users to install a supported version of OpenSSL on a supported architecture
> as a precondition of using commons crypto.  I think it could become
> cumbersome to try and support every vendor default *SSL install.  That
> said, I don't have a problem committing this particular "fix" to the
> baseline, particularly since you have already done the work.  I just don't
> think that the project should obligate itself to do so or advertise
> LibreSSL (or any other non-OpenSSL branch) support as such.  I'm advocating
> a "use at your own risk" approach to anything but OpenSSL proper.  I agree
> that we should update the documentation to reflect whatever we move forward
> with.
>
> Anyway, that's my $0.02 worth.
>
> Alex
>
> On Wed, Jun 29, 2022 at 6:14 PM sebb  wrote:
>
> > On Wed, 29 Jun 2022 at 18:06, Gary Gregory  wrote:
> > >
> > > We cannot remove support for Windows and macOS, that's silly.
> >
> > AFAICT that means we must support the different set of function names
> > in LibreSSL.
> > Note that we only currently use a small proportion of them.
> >
> > > I have not followed all the branches and commits, so I'm not sure what
> > the
> > > current problems are, but I know I was able to release all OSs last go
> > > around. I don't see why we need to rip out anything as fundamental.
> >
> > Well, I have tried running the Crypto and OpenSslJna main classes on
> > macOS and Windows, and they both fail with the 1.1.0 release.
> >
> > With current master, Crypto succeeds, but OpenSslJna fails to find
> > ENGINE_load_rdrand on both macOS and Windows.
> > (The job step succeeds, because the code catches the exception)
> >
> > It looks like the test which would have exposed at least one of the
> > issues was never enabled because of a failures on macOS; this hid the
> > same problem on Windows.
> >
> > I am not suggesting we rip out anything at this point.
> >
> > The question is whether to do anything about the previously undetected
> > issues with JNA on macOS and Windows, and if so, whether this needs to
> > be done for the current or a later release. If we don't fix this
> > release, obviously it needs some mention in the release notes.
> >
> > Sebb
> > https://github.com/apache/commons-crypto/actions/runs/2586011129
> > > Gary
> > >
> > > On Wed, Jun 29, 2022, 12:00 sebb  wrote:
> > >
> > > > On Wed, 29 Jun 2022 at 16:11, Alex Remily 
> > wrote:
> > > > >
> > > > > I agree with Gary that we just don't support LibreSSL.  To my
> > knowledge
> > > > > we've never advertised LibreSSL support, so I don't see it as an
> > issue.
> > > >
> > > > In that case AFAICT we will have to drop *all* support for macOS and
> > > > Windows, as they both seem to default to LibreSSL.
> > > >
> > > > Note that adding support for LibreSSL was much easier for JNI, as it
> > > > uses far fewer methods.
> > > > Rather than checking the version, I changed the code to try OpenSSL
> > > > 1.1 names first, then a fallback.
> > > > That happens to work for 1.0.x and 1.1.x and LibreSSL.
> > > >
> > > > If you want to try it out, compare 16345bc (old) with 3ee3f65 (new)
> > > > macOS fails on 16345bc because it now uses LibreSSL which has a
> > > > different mix of names.
> > > >
> > > > I think it's vital we support JNI as far as possible (and the code
> > > > already does with commit 3ee3f65).
> > > >
> > > > However JNA is more of a backstop, so the fact that it has stopped
> > > > working for macOS and Windows is less of an issue.
> > > >
> > > > But I don't think we can say we are not supporting LibreSSL at all.
> > > >
> > > > > On Wed, Jun 29, 2022 at 10:21 AM sebb  wrote:
> > > > >
> > > > > > On Wed, 29 Jun 2022 at 14:17, Gary Gregory  > >
> > > > wrote:
> > > > > > >
> > > > > > > The simple solution is to keep doing what we do now: only support
> > > > OpenSSL
> > > > > > > and not whatever Apple does with

Re: [CRYPTO] Problem with JNA on macOS and Windows

2022-06-29 Thread Alex Remily



I wouldn't characterize the issues running against LibreSSL as
"undetected".  I also don't see this as an issue with Mac or Windows, but
with LibreSSL.  Install any supported OpenSSL library on any supported
architecture (to include Mac and Windows) and all commons crypto
functionality is available.  I first encountered the rand issue you
describe years ago when I was becoming familiar with commons crypto.  I did
a little research, discovered that I was running LibreSSL (and an old
version at that), installed a supported version of OpenSSL and forgot
all about it until this thread.  I don't think it's unreasonable to expect
users to install a supported version of OpenSSL on a supported architecture
as a precondition of using commons crypto.  I think it could become
cumbersome to try and support every vendor default *SSL install.  That
said, I don't have a problem committing this particular "fix" to the
baseline, particularly since you have already done the work.  I just don't
think that the project should obligate itself to do so or advertise
LibreSSL (or any other non-OpenSSL branch) support as such.  I'm advocating
a "use at your own risk" approach to anything but OpenSSL proper.  I agree
that we should update the documentation to reflect whatever we move forward
with.

Anyway, that's my $0.02 worth.

Alex

On Wed, Jun 29, 2022 at 6:14 PM sebb  wrote:

> On Wed, 29 Jun 2022 at 18:06, Gary Gregory  wrote:
> >
> > We cannot remove support for Windows and macOS, that's silly.
>
> AFAICT that means we must support the different set of function names
> in LibreSSL.
> Note that we only currently use a small proportion of them.
>
> > I have not followed all the branches and commits, so I'm not sure what
> the
> > current problems are, but I know I was able to release all OSs last go
> > around. I don't see why we need to rip out anything as fundamental.
>
> Well, I have tried running the Crypto and OpenSslJna main classes on
> macOS and Windows, and they both fail with the 1.1.0 release.
>
> With current master, Crypto succeeds, but OpenSslJna fails to find
> ENGINE_load_rdrand on both macOS and Windows.
> (The job step succeeds, because the code catches the exception)
>
> It looks like the test which would have exposed at least one of the
> issues was never enabled because of a failures on macOS; this hid the
> same problem on Windows.
>
> I am not suggesting we rip out anything at this point.
>
> The question is whether to do anything about the previously undetected
> issues with JNA on macOS and Windows, and if so, whether this needs to
> be done for the current or a later release. If we don't fix this
> release, obviously it needs some mention in the release notes.
>
> Sebb
> https://github.com/apache/commons-crypto/actions/runs/2586011129
> > Gary
> >
> > On Wed, Jun 29, 2022, 12:00 sebb  wrote:
> >
> > > On Wed, 29 Jun 2022 at 16:11, Alex Remily 
> wrote:
> > > >
> > > > I agree with Gary that we just don't support LibreSSL.  To my
> knowledge
> > > > we've never advertised LibreSSL support, so I don't see it as an
> issue.
> > >
> > > In that case AFAICT we will have to drop *all* support for macOS and
> > > Windows, as they both seem to default to LibreSSL.
> > >
> > > Note that adding support for LibreSSL was much easier for JNI, as it
> > > uses far fewer methods.
> > > Rather than checking the version, I changed the code to try OpenSSL
> > > 1.1 names first, then a fallback.
> > > That happens to work for 1.0.x and 1.1.x and LibreSSL.
> > >
> > > If you want to try it out, compare 16345bc (old) with 3ee3f65 (new)
> > > macOS fails on 16345bc because it now uses LibreSSL which has a
> > > different mix of names.
> > >
> > > I think it's vital we support JNI as far as possible (and the code
> > > already does with commit 3ee3f65).
> > >
> > > However JNA is more of a backstop, so the fact that it has stopped
> > > working for macOS and Windows is less of an issue.
> > >
> > > But I don't think we can say we are not supporting LibreSSL at all.
> > >
> > > > On Wed, Jun 29, 2022 at 10:21 AM sebb  wrote:
> > > >
> > > > > On Wed, 29 Jun 2022 at 14:17, Gary Gregory  >
> > > wrote:
> > > > > >
> > > > > > The simple solution is to keep doing what we do now: only support
> > > OpenSSL
> > > > > > and not whatever Apple does with LibreSSL which may or may not
> be up
> > > to
> > > > > > date.
> > > > >
> > > > > I think this also affects Windows.
> > > > >
> > > > > I don't have  Windows box at present, but I have seen this on GH
> > > Actions.
> > > > >
> > > > > If you have a WIndows build, perhaps you could try these tests:
> > > > >
> > > > > mvn -q exec:java
> -D"exec.mainClass=org.apache.commons.crypto.Crypto"
> > > > > mvn -q exec:java
> > > > > -D"exec.mainClass=org.apache.commons.crypto.jna.OpenSslJna"
> > > > >
> > > > > The first one should show the SSL details; on GH the output
> includes:
> > > > >
> > > > > OpenSSL library loaded OK, version: 0x2000
> > > > > OpenSSL library info:

Re: [CRYPTO] Problem with JNA on macOS and Windows

2022-06-29 Thread Bernd Eckenfels

Hello,

I don’t really understand why we “must” support libreSSL. I mean it is good if 
we would support multiple implementations to cater for a wider audience, but if 
commons-crypto requires a certain OpenSSL library and if that library is 
available for all platforms, why not.

Integrators (aka users) can always ship a compatible one. I think none of the 
libraries comes out of the box on windows (and even if it did it would not be a 
showstopper)? So why would libressl be prefered. Other question, why do the 
symbols differ wasn’t there some form of replaceability?

Gruss
Bernd

--
http://bernd.eckenfels.net

Von: sebb 
Gesendet: Thursday, June 30, 2022 12:14:06 AM
An: Commons Developers List 
Betreff: Re: [CRYPTO] Problem with JNA on macOS and Windows

On Wed, 29 Jun 2022 at 18:06, Gary Gregory  wrote:
>
> We cannot remove support for Windows and macOS, that's silly.

AFAICT that means we must support the different set of function names
in LibreSSL.
Note that we only currently use a small proportion of them.

> I have not followed all the branches and commits, so I'm not sure what the
> current problems are, but I know I was able to release all OSs last go
> around. I don't see why we need to rip out anything as fundamental.

Well, I have tried running the Crypto and OpenSslJna main classes on
macOS and Windows, and they both fail with the 1.1.0 release.

With current master, Crypto succeeds, but OpenSslJna fails to find
ENGINE_load_rdrand on both macOS and Windows.
(The job step succeeds, because the code catches the exception)

It looks like the test which would have exposed at least one of the
issues was never enabled because of a failures on macOS; this hid the
same problem on Windows.

I am not suggesting we rip out anything at this point.

The question is whether to do anything about the previously undetected
issues with JNA on macOS and Windows, and if so, whether this needs to
be done for the current or a later release. If we don't fix this
release, obviously it needs some mention in the release notes.

Sebb
https://github.com/apache/commons-crypto/actions/runs/2586011129
> Gary
>
> On Wed, Jun 29, 2022, 12:00 sebb  wrote:
>
> > On Wed, 29 Jun 2022 at 16:11, Alex Remily  wrote:
> > >
> > > I agree with Gary that we just don't support LibreSSL.  To my knowledge
> > > we've never advertised LibreSSL support, so I don't see it as an issue.
> >
> > In that case AFAICT we will have to drop *all* support for macOS and
> > Windows, as they both seem to default to LibreSSL.
> >
> > Note that adding support for LibreSSL was much easier for JNI, as it
> > uses far fewer methods.
> > Rather than checking the version, I changed the code to try OpenSSL
> > 1.1 names first, then a fallback.
> > That happens to work for 1.0.x and 1.1.x and LibreSSL.
> >
> > If you want to try it out, compare 16345bc (old) with 3ee3f65 (new)
> > macOS fails on 16345bc because it now uses LibreSSL which has a
> > different mix of names.
> >
> > I think it's vital we support JNI as far as possible (and the code
> > already does with commit 3ee3f65).
> >
> > However JNA is more of a backstop, so the fact that it has stopped
> > working for macOS and Windows is less of an issue.
> >
> > But I don't think we can say we are not supporting LibreSSL at all.
> >
> > > On Wed, Jun 29, 2022 at 10:21 AM sebb  wrote:
> > >
> > > > On Wed, 29 Jun 2022 at 14:17, Gary Gregory 
> > wrote:
> > > > >
> > > > > The simple solution is to keep doing what we do now: only support
> > OpenSSL
> > > > > and not whatever Apple does with LibreSSL which may or may not be up
> > to
> > > > > date.
> > > >
> > > > I think this also affects Windows.
> > > >
> > > > I don't have  Windows box at present, but I have seen this on GH
> > Actions.
> > > >
> > > > If you have a WIndows build, perhaps you could try these tests:
> > > >
> > > > mvn -q exec:java -D"exec.mainClass=org.apache.commons.crypto.Crypto"
> > > > mvn -q exec:java
> > > > -D"exec.mainClass=org.apache.commons.crypto.jna.OpenSslJna"
> > > >
> > > > The first one should show the SSL details; on GH the output includes:
> > > >
> > > > OpenSSL library loaded OK, version: 0x2000
> > > > OpenSSL library info: LibreSSL 3.0.2
> > > > Additional OpenSSL_version(n) details:
> > > > 4: OPENSSLDIR: "C:/Windows/libressl/ssl"
> > > >
> > > > The second test crashes with:
> > > > java.lang.UnsatisfiedLinkError: Error looking up function
> > > > 'ENGINE_load_rdrand': The specified procedure could not be found.
> > > > isEnabled(): false
> > > >
> > > > initialisationError(): java.lang.UnsatisfiedLinkError: Error looking
> > > > up function 'ENGINE_load_rdrand': The specified procedure could not be
> > > > found.
> > > > at com.sun.jna.Function.(Function.java:252)
> > > > ...
> > > >
> > > > It would certainly be easier to ignore the problem for now.
> > > >
> > > > > Gary
> > > > >
> > > > > On Wed, Jun 29, 2022, 06:59 sebb  wrote:
> > > > >
> > > > > > It looks like macOS

Re: [CRYPTO] Problem with JNA on macOS and Windows

2022-06-29 Thread sebb

On Wed, 29 Jun 2022 at 18:06, Gary Gregory  wrote:
>
> We cannot remove support for Windows and macOS, that's silly.

AFAICT that means we must support the different set of function names
in LibreSSL.
Note that we only currently use a small proportion of them.

> I have not followed all the branches and commits, so I'm not sure what the
> current problems are, but I know I was able to release all OSs last go
> around. I don't see why we need to rip out anything as fundamental.

Well, I have tried running the Crypto and OpenSslJna main classes on
macOS and Windows, and they both fail with the 1.1.0 release.

With current master, Crypto succeeds, but OpenSslJna fails to find
ENGINE_load_rdrand on both macOS and Windows.
(The job step succeeds, because the code catches the exception)

It looks like the test which would have exposed at least one of the
issues was never enabled because of a failures on macOS; this hid the
same problem on Windows.

I am not suggesting we rip out anything at this point.

The question is whether to do anything about the previously undetected
issues with JNA on macOS and Windows, and if so, whether this needs to
be done for the current or a later release. If we don't fix this
release, obviously it needs some mention in the release notes.

Sebb
https://github.com/apache/commons-crypto/actions/runs/2586011129
> Gary
>
> On Wed, Jun 29, 2022, 12:00 sebb  wrote:
>
> > On Wed, 29 Jun 2022 at 16:11, Alex Remily  wrote:
> > >
> > > I agree with Gary that we just don't support LibreSSL.  To my knowledge
> > > we've never advertised LibreSSL support, so I don't see it as an issue.
> >
> > In that case AFAICT we will have to drop *all* support for macOS and
> > Windows, as they both seem to default to LibreSSL.
> >
> > Note that adding support for LibreSSL was much easier for JNI, as it
> > uses far fewer methods.
> > Rather than checking the version, I changed the code to try OpenSSL
> > 1.1 names first, then a fallback.
> > That happens to work for 1.0.x and 1.1.x and LibreSSL.
> >
> > If you want to try it out, compare 16345bc (old) with 3ee3f65 (new)
> > macOS fails on 16345bc because it now uses LibreSSL which has a
> > different mix of names.
> >
> > I think it's vital we support JNI as far as possible (and the code
> > already does with commit 3ee3f65).
> >
> > However JNA is more of a backstop, so the fact that it has stopped
> > working for macOS and Windows is less of an issue.
> >
> > But I don't think we can say we are not supporting LibreSSL at all.
> >
> > > On Wed, Jun 29, 2022 at 10:21 AM sebb  wrote:
> > >
> > > > On Wed, 29 Jun 2022 at 14:17, Gary Gregory 
> > wrote:
> > > > >
> > > > > The simple solution is to keep doing what we do now: only support
> > OpenSSL
> > > > > and not whatever Apple does with LibreSSL which may or may not be up
> > to
> > > > > date.
> > > >
> > > > I think this also affects Windows.
> > > >
> > > > I don't have  Windows box at present, but I have seen this on GH
> > Actions.
> > > >
> > > > If you have a WIndows build, perhaps you could try these tests:
> > > >
> > > > mvn -q exec:java -D"exec.mainClass=org.apache.commons.crypto.Crypto"
> > > > mvn -q exec:java
> > > > -D"exec.mainClass=org.apache.commons.crypto.jna.OpenSslJna"
> > > >
> > > > The first one should show the SSL details; on GH the output includes:
> > > >
> > > > OpenSSL library loaded OK, version: 0x2000
> > > > OpenSSL library info: LibreSSL 3.0.2
> > > > Additional OpenSSL_version(n) details:
> > > > 4: OPENSSLDIR: "C:/Windows/libressl/ssl"
> > > >
> > > > The second test crashes with:
> > > > java.lang.UnsatisfiedLinkError: Error looking up function
> > > > 'ENGINE_load_rdrand': The specified procedure could not be found.
> > > > isEnabled(): false
> > > >
> > > > initialisationError(): java.lang.UnsatisfiedLinkError: Error looking
> > > > up function 'ENGINE_load_rdrand': The specified procedure could not be
> > > > found.
> > > > at com.sun.jna.Function.(Function.java:252)
> > > > ...
> > > >
> > > > It would certainly be easier to ignore the problem for now.
> > > >
> > > > > Gary
> > > > >
> > > > > On Wed, Jun 29, 2022, 06:59 sebb  wrote:
> > > > >
> > > > > > It looks like macOS 10.5+ and Windows (latest) use LibreSSL by
> > default
> > > > > > rather than OpenSSL.
> > > > > >
> > > > > > The LibreSSL API does not have the same functions as either 1.0.2
> > or
> > > > > > 1.1.1, so needs its own JNA class. In particular it looks like
> > > > > > ENGINE_load_rdrand is not present, nor is OpenSSL_version_num;
> > 1.0.2
> > > > > > has the former only, and 1.1.1 has the latter only.
> > > > > >
> > > > > > This makes it hard to support JNA with the current design.
> > > > > > It would require another OpenSslNativeJna class, and the
> > > > > > parent class OpenSslNativeJna would need to use yet another
> > condition
> > > > > > in each of its methods.
> > > > > >
> > > > > > This is quite tedious and error-prone.
> > > > > >
> > > > > > Seems to me it would be better

Re: [CRYPTO] Drop support for OpenSSL < 1.1.x

2022-06-29 Thread Gary Gregory

An important aspect to consider is compatibility, we do not want to break
anything within a major version.

Gary

On Wed, Jun 29, 2022, 11:15 Alex Remily  wrote:

> How do we do release planning here?  I think the next major release should
> support OpenSSL 3.0.X and 1.1.1x and perhaps include Blake2 hash, but I
> don't know how to have that conversation in the Apache governance model.
>
> On Wed, Jun 29, 2022 at 7:02 AM sebb  wrote:
>
> > Seems to me we should deprecate the code that supports OpenSSL 1.0.x
> > for the next release.
> >
> > Then drop it at the first proper opportunity (major release?)
> >
> > Agreed?
> >
> > Sebb
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: [CRYPTO] Problem with JNA on macOS and Windows

2022-06-29 Thread Gary Gregory

We cannot remove support for Windows and macOS, that's silly.

I have not followed all the branches and commits, so I'm not sure what the
current problems are, but I know I was able to release all OSs last go
around. I don't see why we need to rip out anything as fundamental.

Gary

On Wed, Jun 29, 2022, 12:00 sebb  wrote:

> On Wed, 29 Jun 2022 at 16:11, Alex Remily  wrote:
> >
> > I agree with Gary that we just don't support LibreSSL.  To my knowledge
> > we've never advertised LibreSSL support, so I don't see it as an issue.
>
> In that case AFAICT we will have to drop *all* support for macOS and
> Windows, as they both seem to default to LibreSSL.
>
> Note that adding support for LibreSSL was much easier for JNI, as it
> uses far fewer methods.
> Rather than checking the version, I changed the code to try OpenSSL
> 1.1 names first, then a fallback.
> That happens to work for 1.0.x and 1.1.x and LibreSSL.
>
> If you want to try it out, compare 16345bc (old) with 3ee3f65 (new)
> macOS fails on 16345bc because it now uses LibreSSL which has a
> different mix of names.
>
> I think it's vital we support JNI as far as possible (and the code
> already does with commit 3ee3f65).
>
> However JNA is more of a backstop, so the fact that it has stopped
> working for macOS and Windows is less of an issue.
>
> But I don't think we can say we are not supporting LibreSSL at all.
>
> > On Wed, Jun 29, 2022 at 10:21 AM sebb  wrote:
> >
> > > On Wed, 29 Jun 2022 at 14:17, Gary Gregory 
> wrote:
> > > >
> > > > The simple solution is to keep doing what we do now: only support
> OpenSSL
> > > > and not whatever Apple does with LibreSSL which may or may not be up
> to
> > > > date.
> > >
> > > I think this also affects Windows.
> > >
> > > I don't have  Windows box at present, but I have seen this on GH
> Actions.
> > >
> > > If you have a WIndows build, perhaps you could try these tests:
> > >
> > > mvn -q exec:java -D"exec.mainClass=org.apache.commons.crypto.Crypto"
> > > mvn -q exec:java
> > > -D"exec.mainClass=org.apache.commons.crypto.jna.OpenSslJna"
> > >
> > > The first one should show the SSL details; on GH the output includes:
> > >
> > > OpenSSL library loaded OK, version: 0x2000
> > > OpenSSL library info: LibreSSL 3.0.2
> > > Additional OpenSSL_version(n) details:
> > > 4: OPENSSLDIR: "C:/Windows/libressl/ssl"
> > >
> > > The second test crashes with:
> > > java.lang.UnsatisfiedLinkError: Error looking up function
> > > 'ENGINE_load_rdrand': The specified procedure could not be found.
> > > isEnabled(): false
> > >
> > > initialisationError(): java.lang.UnsatisfiedLinkError: Error looking
> > > up function 'ENGINE_load_rdrand': The specified procedure could not be
> > > found.
> > > at com.sun.jna.Function.(Function.java:252)
> > > ...
> > >
> > > It would certainly be easier to ignore the problem for now.
> > >
> > > > Gary
> > > >
> > > > On Wed, Jun 29, 2022, 06:59 sebb  wrote:
> > > >
> > > > > It looks like macOS 10.5+ and Windows (latest) use LibreSSL by
> default
> > > > > rather than OpenSSL.
> > > > >
> > > > > The LibreSSL API does not have the same functions as either 1.0.2
> or
> > > > > 1.1.1, so needs its own JNA class. In particular it looks like
> > > > > ENGINE_load_rdrand is not present, nor is OpenSSL_version_num;
> 1.0.2
> > > > > has the former only, and 1.1.1 has the latter only.
> > > > >
> > > > > This makes it hard to support JNA with the current design.
> > > > > It would require another OpenSslNativeJna class, and the
> > > > > parent class OpenSslNativeJna would need to use yet another
> condition
> > > > > in each of its methods.
> > > > >
> > > > > This is quite tedious and error-prone.
> > > > >
> > > > > Seems to me it would be better to use something like a set of
> > > > > singleton classes that implement the required methods. The
> appropriate
> > > > > one can then be initialised and used by OpenSslNativeJna to field
> the
> > > > > actual methods. i.e. replace the conditional logic with a static
> > > > > reference to the correct API interface instance. This should only
> > > > > affect non-public classes.
> > > > >
> > > > > Any other suggestions?
> > > > >
> > > > > Sebb
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > > >
> > > > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [CRYPTO] Problem with JNA on macOS and Windows

2022-06-29 Thread sebb

On Wed, 29 Jun 2022 at 16:11, Alex Remily  wrote:
>
> I agree with Gary that we just don't support LibreSSL.  To my knowledge
> we've never advertised LibreSSL support, so I don't see it as an issue.

In that case AFAICT we will have to drop *all* support for macOS and
Windows, as they both seem to default to LibreSSL.

Note that adding support for LibreSSL was much easier for JNI, as it
uses far fewer methods.
Rather than checking the version, I changed the code to try OpenSSL
1.1 names first, then a fallback.
That happens to work for 1.0.x and 1.1.x and LibreSSL.

If you want to try it out, compare 16345bc (old) with 3ee3f65 (new)
macOS fails on 16345bc because it now uses LibreSSL which has a
different mix of names.

I think it's vital we support JNI as far as possible (and the code
already does with commit 3ee3f65).

However JNA is more of a backstop, so the fact that it has stopped
working for macOS and Windows is less of an issue.

But I don't think we can say we are not supporting LibreSSL at all.

> On Wed, Jun 29, 2022 at 10:21 AM sebb  wrote:
>
> > On Wed, 29 Jun 2022 at 14:17, Gary Gregory  wrote:
> > >
> > > The simple solution is to keep doing what we do now: only support OpenSSL
> > > and not whatever Apple does with LibreSSL which may or may not be up to
> > > date.
> >
> > I think this also affects Windows.
> >
> > I don't have  Windows box at present, but I have seen this on GH Actions.
> >
> > If you have a WIndows build, perhaps you could try these tests:
> >
> > mvn -q exec:java -D"exec.mainClass=org.apache.commons.crypto.Crypto"
> > mvn -q exec:java
> > -D"exec.mainClass=org.apache.commons.crypto.jna.OpenSslJna"
> >
> > The first one should show the SSL details; on GH the output includes:
> >
> > OpenSSL library loaded OK, version: 0x2000
> > OpenSSL library info: LibreSSL 3.0.2
> > Additional OpenSSL_version(n) details:
> > 4: OPENSSLDIR: "C:/Windows/libressl/ssl"
> >
> > The second test crashes with:
> > java.lang.UnsatisfiedLinkError: Error looking up function
> > 'ENGINE_load_rdrand': The specified procedure could not be found.
> > isEnabled(): false
> >
> > initialisationError(): java.lang.UnsatisfiedLinkError: Error looking
> > up function 'ENGINE_load_rdrand': The specified procedure could not be
> > found.
> > at com.sun.jna.Function.(Function.java:252)
> > ...
> >
> > It would certainly be easier to ignore the problem for now.
> >
> > > Gary
> > >
> > > On Wed, Jun 29, 2022, 06:59 sebb  wrote:
> > >
> > > > It looks like macOS 10.5+ and Windows (latest) use LibreSSL by default
> > > > rather than OpenSSL.
> > > >
> > > > The LibreSSL API does not have the same functions as either 1.0.2 or
> > > > 1.1.1, so needs its own JNA class. In particular it looks like
> > > > ENGINE_load_rdrand is not present, nor is OpenSSL_version_num; 1.0.2
> > > > has the former only, and 1.1.1 has the latter only.
> > > >
> > > > This makes it hard to support JNA with the current design.
> > > > It would require another OpenSslNativeJna class, and the
> > > > parent class OpenSslNativeJna would need to use yet another condition
> > > > in each of its methods.
> > > >
> > > > This is quite tedious and error-prone.
> > > >
> > > > Seems to me it would be better to use something like a set of
> > > > singleton classes that implement the required methods. The appropriate
> > > > one can then be initialised and used by OpenSslNativeJna to field the
> > > > actual methods. i.e. replace the conditional logic with a static
> > > > reference to the correct API interface instance. This should only
> > > > affect non-public classes.
> > > >
> > > > Any other suggestions?
> > > >
> > > > Sebb
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >
> > > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

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

Re: [CRYPTO] Drop support for OpenSSL < 1.1.x

2022-06-29 Thread Alex Remily

How do we do release planning here?  I think the next major release should
support OpenSSL 3.0.X and 1.1.1x and perhaps include Blake2 hash, but I
don't know how to have that conversation in the Apache governance model.

On Wed, Jun 29, 2022 at 7:02 AM sebb  wrote:

> Seems to me we should deprecate the code that supports OpenSSL 1.0.x
> for the next release.
>
> Then drop it at the first proper opportunity (major release?)
>
> Agreed?
>
> Sebb
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [CRYPTO] Problem with JNA on macOS and Windows

2022-06-29 Thread Alex Remily

I agree with Gary that we just don't support LibreSSL.  To my knowledge
we've never advertised LibreSSL support, so I don't see it as an issue.

On Wed, Jun 29, 2022 at 10:21 AM sebb  wrote:

> On Wed, 29 Jun 2022 at 14:17, Gary Gregory  wrote:
> >
> > The simple solution is to keep doing what we do now: only support OpenSSL
> > and not whatever Apple does with LibreSSL which may or may not be up to
> > date.
>
> I think this also affects Windows.
>
> I don't have  Windows box at present, but I have seen this on GH Actions.
>
> If you have a WIndows build, perhaps you could try these tests:
>
> mvn -q exec:java -D"exec.mainClass=org.apache.commons.crypto.Crypto"
> mvn -q exec:java
> -D"exec.mainClass=org.apache.commons.crypto.jna.OpenSslJna"
>
> The first one should show the SSL details; on GH the output includes:
>
> OpenSSL library loaded OK, version: 0x2000
> OpenSSL library info: LibreSSL 3.0.2
> Additional OpenSSL_version(n) details:
> 4: OPENSSLDIR: "C:/Windows/libressl/ssl"
>
> The second test crashes with:
> java.lang.UnsatisfiedLinkError: Error looking up function
> 'ENGINE_load_rdrand': The specified procedure could not be found.
> isEnabled(): false
>
> initialisationError(): java.lang.UnsatisfiedLinkError: Error looking
> up function 'ENGINE_load_rdrand': The specified procedure could not be
> found.
> at com.sun.jna.Function.(Function.java:252)
> ...
>
> It would certainly be easier to ignore the problem for now.
>
> > Gary
> >
> > On Wed, Jun 29, 2022, 06:59 sebb  wrote:
> >
> > > It looks like macOS 10.5+ and Windows (latest) use LibreSSL by default
> > > rather than OpenSSL.
> > >
> > > The LibreSSL API does not have the same functions as either 1.0.2 or
> > > 1.1.1, so needs its own JNA class. In particular it looks like
> > > ENGINE_load_rdrand is not present, nor is OpenSSL_version_num; 1.0.2
> > > has the former only, and 1.1.1 has the latter only.
> > >
> > > This makes it hard to support JNA with the current design.
> > > It would require another OpenSslNativeJna class, and the
> > > parent class OpenSslNativeJna would need to use yet another condition
> > > in each of its methods.
> > >
> > > This is quite tedious and error-prone.
> > >
> > > Seems to me it would be better to use something like a set of
> > > singleton classes that implement the required methods. The appropriate
> > > one can then be initialised and used by OpenSslNativeJna to field the
> > > actual methods. i.e. replace the conditional logic with a static
> > > reference to the correct API interface instance. This should only
> > > affect non-public classes.
> > >
> > > Any other suggestions?
> > >
> > > Sebb
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [CRYPTO] Problem with JNA on macOS and Windows

2022-06-29 Thread sebb

On Wed, 29 Jun 2022 at 14:17, Gary Gregory  wrote:
>
> The simple solution is to keep doing what we do now: only support OpenSSL
> and not whatever Apple does with LibreSSL which may or may not be up to
> date.

I think this also affects Windows.

I don't have  Windows box at present, but I have seen this on GH Actions.

If you have a WIndows build, perhaps you could try these tests:

mvn -q exec:java -D"exec.mainClass=org.apache.commons.crypto.Crypto"
mvn -q exec:java -D"exec.mainClass=org.apache.commons.crypto.jna.OpenSslJna"

The first one should show the SSL details; on GH the output includes:

OpenSSL library loaded OK, version: 0x2000
OpenSSL library info: LibreSSL 3.0.2
Additional OpenSSL_version(n) details:
4: OPENSSLDIR: "C:/Windows/libressl/ssl"

The second test crashes with:
java.lang.UnsatisfiedLinkError: Error looking up function
'ENGINE_load_rdrand': The specified procedure could not be found.
isEnabled(): false

initialisationError(): java.lang.UnsatisfiedLinkError: Error looking
up function 'ENGINE_load_rdrand': The specified procedure could not be
found.
at com.sun.jna.Function.(Function.java:252)
...

It would certainly be easier to ignore the problem for now.

> Gary
>
> On Wed, Jun 29, 2022, 06:59 sebb  wrote:
>
> > It looks like macOS 10.5+ and Windows (latest) use LibreSSL by default
> > rather than OpenSSL.
> >
> > The LibreSSL API does not have the same functions as either 1.0.2 or
> > 1.1.1, so needs its own JNA class. In particular it looks like
> > ENGINE_load_rdrand is not present, nor is OpenSSL_version_num; 1.0.2
> > has the former only, and 1.1.1 has the latter only.
> >
> > This makes it hard to support JNA with the current design.
> > It would require another OpenSslNativeJna class, and the
> > parent class OpenSslNativeJna would need to use yet another condition
> > in each of its methods.
> >
> > This is quite tedious and error-prone.
> >
> > Seems to me it would be better to use something like a set of
> > singleton classes that implement the required methods. The appropriate
> > one can then be initialised and used by OpenSslNativeJna to field the
> > actual methods. i.e. replace the conditional logic with a static
> > reference to the correct API interface instance. This should only
> > affect non-public classes.
> >
> > Any other suggestions?
> >
> > Sebb
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

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

Re: [CRYPTO] Problem with JNA on macOS and Windows

2022-06-29 Thread Gary Gregory

The simple solution is to keep doing what we do now: only support OpenSSL
and not whatever Apple does with LibreSSL which may or may not be up to
date.

Gary

On Wed, Jun 29, 2022, 06:59 sebb  wrote:

> It looks like macOS 10.5+ and Windows (latest) use LibreSSL by default
> rather than OpenSSL.
>
> The LibreSSL API does not have the same functions as either 1.0.2 or
> 1.1.1, so needs its own JNA class. In particular it looks like
> ENGINE_load_rdrand is not present, nor is OpenSSL_version_num; 1.0.2
> has the former only, and 1.1.1 has the latter only.
>
> This makes it hard to support JNA with the current design.
> It would require another OpenSslNativeJna class, and the
> parent class OpenSslNativeJna would need to use yet another condition
> in each of its methods.
>
> This is quite tedious and error-prone.
>
> Seems to me it would be better to use something like a set of
> singleton classes that implement the required methods. The appropriate
> one can then be initialised and used by OpenSslNativeJna to field the
> actual methods. i.e. replace the conditional logic with a static
> reference to the correct API interface instance. This should only
> affect non-public classes.
>
> Any other suggestions?
>
> Sebb
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [CRYPTO] Drop support for OpenSSL < 1.1.x

2022-06-29 Thread Gary Gregory

Deprecation seems ok, just make sure the deprecations are documented with
any replacement or explanation.

Gary

On Wed, Jun 29, 2022, 07:02 sebb  wrote:

> Seems to me we should deprecate the code that supports OpenSSL 1.0.x
> for the next release.
>
> Then drop it at the first proper opportunity (major release?)
>
> Agreed?
>
> Sebb
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[CRYPTO] Drop support for OpenSSL < 1.1.x

2022-06-29 Thread sebb

Seems to me we should deprecate the code that supports OpenSSL 1.0.x
for the next release.

Then drop it at the first proper opportunity (major release?)

Agreed?

Sebb

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

[CRYPTO] Problem with JNA on macOS and Windows

2022-06-29 Thread sebb

It looks like macOS 10.5+ and Windows (latest) use LibreSSL by default
rather than OpenSSL.

The LibreSSL API does not have the same functions as either 1.0.2 or
1.1.1, so needs its own JNA class. In particular it looks like
ENGINE_load_rdrand is not present, nor is OpenSSL_version_num; 1.0.2
has the former only, and 1.1.1 has the latter only.

This makes it hard to support JNA with the current design.
It would require another OpenSslNativeJna class, and the
parent class OpenSslNativeJna would need to use yet another condition
in each of its methods.

This is quite tedious and error-prone.

Seems to me it would be better to use something like a set of
singleton classes that implement the required methods. The appropriate
one can then be initialised and used by OpenSslNativeJna to field the
actual methods. i.e. replace the conditional logic with a static
reference to the correct API interface instance. This should only
affect non-public classes.

Any other suggestions?

Sebb

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

Re: [collections] JMH results for IndexedLinkedList

[VOTE] Release Apache Commons Configuration 2.8.0 based on RC3

Re: [CRYPTO] Problem with JNA on macOS and Windows

Re: [CRYPTO] Problem with JNA on macOS and Windows

Re: [CRYPTO] Problem with JNA on macOS and Windows

Re: [CRYPTO] Problem with JNA on macOS and Windows

Re: [CRYPTO] Problem with JNA on macOS and Windows

Re: [CRYPTO] Problem with JNA on macOS and Windows

Re: [CRYPTO] Problem with JNA on macOS and Windows

Re: [CRYPTO] Problem with JNA on macOS and Windows

Re: [CRYPTO] Drop support for OpenSSL < 1.1.x

Re: [CRYPTO] Problem with JNA on macOS and Windows

Re: [CRYPTO] Problem with JNA on macOS and Windows

Re: [CRYPTO] Drop support for OpenSSL < 1.1.x

Re: [CRYPTO] Problem with JNA on macOS and Windows

Re: [CRYPTO] Problem with JNA on macOS and Windows

Re: [CRYPTO] Problem with JNA on macOS and Windows

Re: [CRYPTO] Drop support for OpenSSL < 1.1.x

[CRYPTO] Drop support for OpenSSL < 1.1.x

[CRYPTO] Problem with JNA on macOS and Windows

20 matches

Site Navigation

Mail list logo

Footer information