Re: [CRYPTO] Basic SSL 3.x support added

[Alex Remily]

Just pulled master and successfully ran tests against OpenSSL 3.1.3 on Mac
OS 11 BigSur.  Nice work sebb!

Apache Commons Crypto 1.2.1-SNAPSHOT

Native code loaded OK: 1.2.1-SNAPSHOT

Native name: Apache Commons Crypto

Native built: Nov 17 2023

OpenSSL library loaded OK, version: 0x30100030

OpenSSL library info: OpenSSL 3.1.3 19 Sep 2023

DLL name: libcrypto.dylib

DLL path: /usr/local/Cellar/openssl@3/3.1.3/lib/libcrypto.3.dylib

Additional OpenSSL_version(n) details:

OpenSSLVersion(1): compiler: clang -fPIC -arch x86_64 -O3 -Wall -DL_ENDIAN
-DOPENSSL_PIC -D_REENTRANT -DOPENSSL_BUILDING_OPENSSL -DNDEBUG

OpenSSLVersion(2): built on: Tue Sep 19 13:01:49 2023 UTC

OpenSSLVersion(3): platform: darwin64-x86_64-cc

OpenSSLVersion(4): OPENSSLDIR: "/usr/local/etc/openssl@3"

OpenSSLVersion(5): ENGINESDIR: "/usr/local/Cellar/openssl@3
/3.1.3/lib/engines-3"

OpenSSLVersion(6): 3.1.3

OpenSSLVersion(7): 3.1.3

OpenSSLVersion(8): MODULESDIR: "/usr/local/Cellar/openssl@3
/3.1.3/lib/ossl-modules"

OpenSSLVersion(9): CPUINFO: OPENSSL_ia32cap=0x7ffaf3eb:0x27ab

Random instance created OK:
org.apache.commons.crypto.random.OpenSslCryptoRandom@30c4e352

Cipher AES/CTR/NoPadding instance created OK:
org.apache.commons.crypto.cipher.OpenSslCipher@673c4f6e

On Tue, Nov 14, 2023 at 8:27 AM sebb  wrote:

> On Tue, 14 Nov 2023 at 13:17, Alex Remily  wrote:
> >
> > That's fantastic.  I read that there were big API changes with the move
> to
> > OpenSSL 3, but maybe those changes were not in the functionality that
> > commons crypto exposes.  Have you merged into master yet?  I look forward
> > to playing around with it.
>
> Yes, it is in master.
>
> > Alex
> >
> > On Wed, Nov 8, 2023 at 7:12 PM sebb  wrote:
> >
> > > Crypto now builds and tests OK on
> > > macOS-latest - OpenSSL 3.1.4 24 Oct 2023
> > > and
> > > Ubuntu-latest - OpenSSL 3.0.2 15 Mar 2022
> > > Tested with Java 8 and 21
> > >
> > > I only had to allow for two changed names:
> > >
> > > EVP_CIPHER_CTX_block_size => EVP_CIPHER_CTX_get_block_size
> > > EVP_CIPHER_flags => EVP_CIPHER_get_flags
> > >
> > > This seems too easy, so I suspect there may be some missing tests.
> > >
> > > 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] Basic SSL 3.x support added

[Alex Remily]

That's fantastic.  I read that there were big API changes with the move to
OpenSSL 3, but maybe those changes were not in the functionality that
commons crypto exposes.  Have you merged into master yet?  I look forward
to playing around with it.

Alex

On Wed, Nov 8, 2023 at 7:12 PM sebb  wrote:

> Crypto now builds and tests OK on
> macOS-latest - OpenSSL 3.1.4 24 Oct 2023
> and
> Ubuntu-latest - OpenSSL 3.0.2 15 Mar 2022
> Tested with Java 8 and 21
>
> I only had to allow for two changed names:
>
> EVP_CIPHER_CTX_block_size => EVP_CIPHER_CTX_get_block_size
> EVP_CIPHER_flags => EVP_CIPHER_get_flags
>
> This seems too easy, so I suspect there may be some missing tests.
>
> 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 ?

[Alex Remily]

+1

On Wed, Nov 8, 2023, 7:24 PM sebb  wrote:

> I would really like to drop support for the oldest versions of SSL, i.e.
> 1.0.x
> These are seriously out of date.
> Can we even test them properly?
>
> Unless I hear otherwise, I propose to remove the code next week.
>
> Sebb
> On Mon, 30 Oct 2023 at 14:33, sebb  wrote:
> >
> > On Mon, 30 Oct 2023 at 12:31, Gary Gregory 
> wrote:
> > >
> > > Hi All,
> > >
> > > I am OK with dropping support for versions below 1.1.1 but it does not
> > > seem crucial.
> > >
> > > I would prefer we do a release for this before we do anything more
> toward 3.x.
> >
> > Not sure I understand what you mean here.
> >
> > Do you mean we should do a release purely to drop support for versions
> > below 1.1?
> > Or something else?
> >
> > Note I am not suggesting dropping support for 1.1.0 yet, but for
> > versions before that, i.e. 1.0.x.
> >
> > > Gary
> > >
> > > On Sun, Oct 29, 2023 at 8:49 PM Alex Remily 
> wrote:
> > > >
> > > > Good question.  I've asked it myself.  I've been planning on doing an
> > > > upgrade to support OpenSSL 3.X.+ that maintains support for 1.1.X.
> That
> > > > said, it's been at least a year and I haven't gotten around to it,
> and I'm
> > > > not firmly committed to the idea of maintaining backwards
> compatibility.  I
> > > > think that if we're going to break backwards compatibility with older
> > > > versions, the upgrade to 3.X would probably be a good time to do
> it.  From
> > > > what little I've read on the subject, the move from 1.1.1 to 3.X is a
> > > > significant change.  In short, I would be in favor of dropping legacy
> > > > OpenSSL support in the next commons crypto release.
> > > >
> > > > Alex
> > > >
> > > > On Sun, Oct 29, 2023 at 9:15 AM sebb  wrote:
> > > >
> > > > > There is quite a lot of Crypto code that depends on the check:
> > > > >
> > > > > if (dlsym_OpenSSL_version_num() < VERSION_1_1_X)
> > > > > where
> > > > > VERSION_1_1_X = 0x1010;
> > > > >
> > > > > Dropping such support would simplify the code.
> > > > >
> > > > > Is there any need to continue to support such old versions?
> > > > >
> > > > > 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
>
>

[CRYPTO] JNI Debug Config

[Alex Remily]

Does anyone have a working debug config for the commons-crypto project?  I
had one for Eclipse a few years ago but I blew it away and now recreating
it is getting to be a time sink.  I'm looking to be able to step from the
Java code to the native code.  I use Eclipse, but I'm also comfortable with
VSCode if you have a good JNI debug configuration for it.  I use GDB.

Alex

Re: [CRYPTO] Why does Makefile use CXX (C++) for linking?

[Alex Remily]

I believe it is for cross compilation, owing to the comments in the
makefile:
# for cross-compilation on Ubuntu, install the g++-mingw-w64-x86-64 package

# for cross-compilation on Ubuntu, install the g++-arm-linux-gnueabi package

# for cross-compilation on Ubuntu, install the g++-arm-linux-gnueabihf
package


On Wed, Nov 1, 2023 at 11:17 AM sebb  wrote:

> On Wed, 1 Nov 2023 at 12:53, Gary Gregory  wrote:
> >
> > Maybe there are cross compilation issues... I don't know for sure.
>
> But CXX is only used for the link phase.
>
> > What I
> > do know is that it quite tricky and time consuming to get everything just
> > right when I do a release from multiple machines to get macOS, Linux, and
> > Windows binaries correctly compiled, linked, and packaged up. I hope
> > nothing was broken in all the recent commits.
>
> I think there may need to be some more GH tests to check all the
> combinations.
>
> > Gary
> >
> > On Wed, Nov 1, 2023, 8:45 AM sebb  wrote:
> >
> > > Crypto currently only uses .c files, and the Makefile uses CC
> > > throughout, except for creating the object output. [This has been the
> > > case since the initial release.]
> > >
> > > Using CXX (C++) for the link does not make sense to me - surely CC can
> > > create the object equally well?
> > >
> > > It would simplify builds (and especially docker builds) if C++ could be
> > > dropped.
> > >
> > > But perhaps there is a good reason for using C++ for this step only?
> > >
> > > 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] Which native builds are supported in binary releases?

[Alex Remily]

The supported architectures documentation is limited to the discussion on
this distribution list.  At least, that's my recollection and
understanding.  I agree that this should be documented at least in the
release notes and web site.  Users shouldn't need to crack open the jar to
figure that out.

Alex

On Wed, Nov 1, 2023 at 11:36 AM sebb  wrote:

> The Crypto makefile includes a lot of different OS and architecture
> combinations.
>
> Not all of these are included in the binary jar.
>
> I don't think we need to generate native binaries for all the
> combinations, but I do think we need to document which ones are
> included, and note that any others must be generated from source.
>
> So: what determines which combinations are supported in the binary,
> and where is this documented?
>
> 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 ?

[Alex Remily]

Good question.  I've asked it myself.  I've been planning on doing an
upgrade to support OpenSSL 3.X.+ that maintains support for 1.1.X.  That
said, it's been at least a year and I haven't gotten around to it, and I'm
not firmly committed to the idea of maintaining backwards compatibility.  I
think that if we're going to break backwards compatibility with older
versions, the upgrade to 3.X would probably be a good time to do it.  From
what little I've read on the subject, the move from 1.1.1 to 3.X is a
significant change.  In short, I would be in favor of dropping legacy
OpenSSL support in the next commons crypto release.

Alex

On Sun, Oct 29, 2023 at 9:15 AM sebb  wrote:

> There is quite a lot of Crypto code that depends on the check:
>
> if (dlsym_OpenSSL_version_num() < VERSION_1_1_X)
> where
> VERSION_1_1_X = 0x1010;
>
> Dropping such support would simplify the code.
>
> Is there any need to continue to support such old versions?
>
> Sebb
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [CRYPTO] test failures with JNA

[Alex Remily]

How to reproduce these test failures?

On Sat, Sep 9, 2023 at 12:33 PM sebb  wrote:

> Some of the test runs fail when testing with the class:
>
> org.apache.commons.crypto.jna.OpenSslJna
>
> It looks like all the OSes complete the test OK if the default JNA
> library is used.
>
> However for some reason its version does not always agree with the
> default openSSL version.
>
> This library can be overridden by suitable use of the jna.library.path
> property.
>
> This is not necessary for Ubuntu, as it defaults to the correct library
> version.
>
> For macos one can use the lib from the ENGINESDIR value shown by
> 'openssl version -a'.
>
> I've not yet been able to find how to override the windows library
> successfully.
>
> Sebb
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [commons-crypto] OpenSSL 3.x, FIPS, digests, and HMAC

[Alex Remily]

Gary,

Can you have a look at this?

https://github.com/apache/commons-crypto/pull/242

Alex

On Sun, Aug 27, 2023 at 8:38 AM Gary Gregory  wrote:

> On Fri, Aug 25, 2023 at 9:48 PM Alex Remily  wrote:
> >
> >  Breakup
> > the current module into different maven modules? Not support both?>
> >
> > Agreed.  Just to provide some history, when I was working on the 1.1.x
> > upgrade I was guided by commons committer Marcelo Vanzin.  Marcelo
> required
> > a design that supported runtime discovery of the underlying openssl
> API.  I
> > don't recall all of the rationale for the requirement, but he insisted
> that
> > any commons-crypto upgrade must support legacy and current versions of
> > openssl transparently to the calling program.  The end result is what we
> > have now.  I don't recall where in the code commons-crypto makes the
> > underlying version checks, at library initialization time or when a
> > specific function is called, but the end result is that users need only
> > download the latest commons-crypto release regardless of their underlying
> > openssl API--as long as they are running supported openssl versions.
> >
> > In my view there are a few open questions regarding the current approach
> as
> > compared to an API-specific one.  One, what is the performance penalty
> > associated with the dynamic version checks?  Two, how much complexity
> does
> > it introduce into the codebase?  Finally, what was the use case that
> drove
> > the runtime checking requirement?  Marcelo could answer the last
> question.
> > I don't know if he is still involved in the community (I haven't seen him
> > around for awhile.  IIRC, he was primarily a Spark committer).
> >
> > Another consideration is the FIPS certification.  I work in a heavily
> > regulated industry and FIPS is a real constraint.  I haven't personally
> > encountered a requirement to deploy a FIPS compliant openssl in our
> > application code, but it's probably just a matter of time.  In terms of
> > expanding our user base, it may make sense to provide that capability.
> It
> > doesn't seem to be generally available from an existing provider.
> >
> > Regarding message digests/HMAC, I question whether the performance gain
> > from native code would significantly outperform some of the modern JCA
> > providers.  As Matt Sicker pointed out, there are other implementations
> > supported by major vendors, like AWS, that may be as fast as a JNI
> wrapper
> > on OpenSSL, or at least close enough not to bother with the added
> > complexity of the native stuff.  The only way I know to answer that
> > question is to write the code and run a load test comparison.
> >
> >
> https://aws.amazon.com/blogs/opensource/introducing-amazon-corretto-crypto-provider-accp/
> >
> > In what forum should we discuss these issues?
>
> This developer's mailing list is where all decisions MUST be recorded,
> so it makes sense that discussions occur here. We can also use Jira
> tickets for specific tasks. Different discussions can use these
> different forums as we best see fit. I would not recommend using Slack
> as that data does or will eventually disappear. I do use Slack as a
> convenience at times for reminding people/channels to vote or pay
> attention to something happening in Jira or on a mailing list.
>
> > Are we limited to this
> > distro or do we have other options?
>
> I'm not sure what this means.
>
> > How do we form teams?
> I'm not sure what that means in the context of Apache. Apache has no
> notion of teams that I am aware of. We have Projects like Apache
> Commons, and Commons has Components like Commons Crypto.
> We are all on this mailing list, we can work on whatever we want, and
> we can use Jira to track tasks. If someone wants to work on a task,
> they can announce it here or in a Jira ticket, to avoid clashes or
> just be informative.
>
> > What is our
> > governance model?
> The same as any Apache project with the usual leeway allowed to each PMC.
>
>  > How do we make decisions?
> The same as any Apache project with the usual leeway allowed to each PMC.
> See https://httpd.apache.org/dev/guidelines.html
> A project can come up with it's own processes, for example see
> https://www.apache.org/foundation/voting.html
>
> Gary
>
> >
> > FYI:  There's already issues on the backlog for OpenSSL 3 and HMAC:
> > https://issues.apache.org/jira/browse/CRYPTO-165
> > https://issues.apache.org/jira/browse/CRYPTO-164
> >
> > Alex
> >
> >
> > On Wed, Aug 23, 2023 at 10:21 PM Gary Gregory 
> > wr

Re: [commons-crypto] OpenSSL 3.x, FIPS, digests, and HMAC

[Alex Remily]

Given Marcelo's response, I think it makes sense to retain support for
1.1.x, add support for 3.0.x using dynamic version discovery, and drop
support for anything older than 1.1.  This would align us with the openssl
LTS versions.  Looks like 3.1.x isn't FIPS validated.

https://www.openssl.org/source/

Thoughts?

Alex

On Sun, Aug 27, 2023 at 8:38 AM Gary Gregory  wrote:

> On Fri, Aug 25, 2023 at 9:48 PM Alex Remily  wrote:
> >
> >  Breakup
> > the current module into different maven modules? Not support both?>
> >
> > Agreed.  Just to provide some history, when I was working on the 1.1.x
> > upgrade I was guided by commons committer Marcelo Vanzin.  Marcelo
> required
> > a design that supported runtime discovery of the underlying openssl
> API.  I
> > don't recall all of the rationale for the requirement, but he insisted
> that
> > any commons-crypto upgrade must support legacy and current versions of
> > openssl transparently to the calling program.  The end result is what we
> > have now.  I don't recall where in the code commons-crypto makes the
> > underlying version checks, at library initialization time or when a
> > specific function is called, but the end result is that users need only
> > download the latest commons-crypto release regardless of their underlying
> > openssl API--as long as they are running supported openssl versions.
> >
> > In my view there are a few open questions regarding the current approach
> as
> > compared to an API-specific one.  One, what is the performance penalty
> > associated with the dynamic version checks?  Two, how much complexity
> does
> > it introduce into the codebase?  Finally, what was the use case that
> drove
> > the runtime checking requirement?  Marcelo could answer the last
> question.
> > I don't know if he is still involved in the community (I haven't seen him
> > around for awhile.  IIRC, he was primarily a Spark committer).
> >
> > Another consideration is the FIPS certification.  I work in a heavily
> > regulated industry and FIPS is a real constraint.  I haven't personally
> > encountered a requirement to deploy a FIPS compliant openssl in our
> > application code, but it's probably just a matter of time.  In terms of
> > expanding our user base, it may make sense to provide that capability.
> It
> > doesn't seem to be generally available from an existing provider.
> >
> > Regarding message digests/HMAC, I question whether the performance gain
> > from native code would significantly outperform some of the modern JCA
> > providers.  As Matt Sicker pointed out, there are other implementations
> > supported by major vendors, like AWS, that may be as fast as a JNI
> wrapper
> > on OpenSSL, or at least close enough not to bother with the added
> > complexity of the native stuff.  The only way I know to answer that
> > question is to write the code and run a load test comparison.
> >
> >
> https://aws.amazon.com/blogs/opensource/introducing-amazon-corretto-crypto-provider-accp/
> >
> > In what forum should we discuss these issues?
>
> This developer's mailing list is where all decisions MUST be recorded,
> so it makes sense that discussions occur here. We can also use Jira
> tickets for specific tasks. Different discussions can use these
> different forums as we best see fit. I would not recommend using Slack
> as that data does or will eventually disappear. I do use Slack as a
> convenience at times for reminding people/channels to vote or pay
> attention to something happening in Jira or on a mailing list.
>
> > Are we limited to this
> > distro or do we have other options?
>
> I'm not sure what this means.
>
> > How do we form teams?
> I'm not sure what that means in the context of Apache. Apache has no
> notion of teams that I am aware of. We have Projects like Apache
> Commons, and Commons has Components like Commons Crypto.
> We are all on this mailing list, we can work on whatever we want, and
> we can use Jira to track tasks. If someone wants to work on a task,
> they can announce it here or in a Jira ticket, to avoid clashes or
> just be informative.
>
> > What is our
> > governance model?
> The same as any Apache project with the usual leeway allowed to each PMC.
>
>  > How do we make decisions?
> The same as any Apache project with the usual leeway allowed to each PMC.
> See https://httpd.apache.org/dev/guidelines.html
> A project can come up with it's own processes, for example see
> https://www.apache.org/foundation/voting.html
>
> Gary
>
> >
> > FYI:  There's already issues on the backlog for OpenSSL 3 and HMAC:
>

Re: [commons-crypto] OpenSSL 3.x, FIPS, digests, and HMAC

[Alex Remily]

Agreed.  Just to provide some history, when I was working on the 1.1.x
upgrade I was guided by commons committer Marcelo Vanzin.  Marcelo required
a design that supported runtime discovery of the underlying openssl API.  I
don't recall all of the rationale for the requirement, but he insisted that
any commons-crypto upgrade must support legacy and current versions of
openssl transparently to the calling program.  The end result is what we
have now.  I don't recall where in the code commons-crypto makes the
underlying version checks, at library initialization time or when a
specific function is called, but the end result is that users need only
download the latest commons-crypto release regardless of their underlying
openssl API--as long as they are running supported openssl versions.

In my view there are a few open questions regarding the current approach as
compared to an API-specific one.  One, what is the performance penalty
associated with the dynamic version checks?  Two, how much complexity does
it introduce into the codebase?  Finally, what was the use case that drove
the runtime checking requirement?  Marcelo could answer the last question.
I don't know if he is still involved in the community (I haven't seen him
around for awhile.  IIRC, he was primarily a Spark committer).

Another consideration is the FIPS certification.  I work in a heavily
regulated industry and FIPS is a real constraint.  I haven't personally
encountered a requirement to deploy a FIPS compliant openssl in our
application code, but it's probably just a matter of time.  In terms of
expanding our user base, it may make sense to provide that capability.  It
doesn't seem to be generally available from an existing provider.

Regarding message digests/HMAC, I question whether the performance gain
from native code would significantly outperform some of the modern JCA
providers.  As Matt Sicker pointed out, there are other implementations
supported by major vendors, like AWS, that may be as fast as a JNI wrapper
on OpenSSL, or at least close enough not to bother with the added
complexity of the native stuff.  The only way I know to answer that
question is to write the code and run a load test comparison.

https://aws.amazon.com/blogs/opensource/introducing-amazon-corretto-crypto-provider-accp/

In what forum should we discuss these issues?  Are we limited to this
distro or do we have other options?  How do we form teams?  What is our
governance model?  How do we make decisions?

FYI:  There's already issues on the backlog for OpenSSL 3 and HMAC:
https://issues.apache.org/jira/browse/CRYPTO-165
https://issues.apache.org/jira/browse/CRYPTO-164

Alex


On Wed, Aug 23, 2023 at 10:21 PM Gary Gregory 
wrote:

> That would be great. I think this is worth the effort. A big item to
> consider is if and how 1.1 vs 3.0 should be handled. Breakup the current
> module into different maven modules? Not support both?
>
> Gary
>
> On Wed, Aug 23, 2023, 8:37 PM Alex Remily  wrote:
>
> >  > how to implement message digests and HMAC on top of OpenSSL 3.0.8.>
> >
> > Implementing the OpenSSL 3 API and exposing OpenSSL HMAC functionality in
> > commons-crypto are things I've wanted to engage on for a while now.  I
> was
> > involved in the commons-crypto OpenSSL 1.1.x upgrade so I have some
> > familiarity with the code base, albeit dated.  The reason that neither
> the
> > OpenSSL 3 API nor the HMAC functionality have been added to
> commons-crypto
> > yet, IMHO, is because both are non-trivial efforts and we all have day
> > jobs. Until now, there hasn't been much of an ask for either feature, but
> > considering the recent chatter maybe there's enough interest to generate
> > some momentum.  I would be happy to collaborate on this effort if it
> gains
> > traction.
> >
> > Alex
> >
> > On Wed, Aug 23, 2023 at 5:21 PM Matt Sicker  wrote:
> >
> >> You may find this project (also Apache licensed, so fairly safe for
> reuse
> >> with commons-crypto updates) to be helpful for that aspect of message
> >> digests, Macs, etc.
> >>
> >> [image: amazon-corretto-crypto-provider.png]
> >>
> >> corretto/amazon-corretto-crypto-provider: The Amazon Corretto Crypto
> >> Provider is a collection of high-performance cryptographic
> implementations
> >> exposed via standard JCA/JCE interfaces.
> >> <https://github.com/corretto/amazon-corretto-crypto-provider>
> >> github.com <https://github.com/corretto/amazon-corretto-crypto-provider
> >
> >> <https://github.com/corretto/amazon-corretto-crypto-provider>
> >>
> >>
> >> On Aug 1, 2023, at 9:17 AM, Jim Showalter 
> >> wrote:
> >>
> >> I'm still trying to come up to speed on your PR/fork. A l

Re: [commons-crypto] OpenSSL 3.x, FIPS, digests, and HMAC

[Alex Remily]

Implementing the OpenSSL 3 API and exposing OpenSSL HMAC functionality in
commons-crypto are things I've wanted to engage on for a while now.  I was
involved in the commons-crypto OpenSSL 1.1.x upgrade so I have some
familiarity with the code base, albeit dated.  The reason that neither the
OpenSSL 3 API nor the HMAC functionality have been added to commons-crypto
yet, IMHO, is because both are non-trivial efforts and we all have day
jobs. Until now, there hasn't been much of an ask for either feature, but
considering the recent chatter maybe there's enough interest to generate
some momentum.  I would be happy to collaborate on this effort if it gains
traction.

Alex

On Wed, Aug 23, 2023 at 5:21 PM Matt Sicker  wrote:

> You may find this project (also Apache licensed, so fairly safe for reuse
> with commons-crypto updates) to be helpful for that aspect of message
> digests, Macs, etc.
>
> [image: amazon-corretto-crypto-provider.png]
>
> corretto/amazon-corretto-crypto-provider: The Amazon Corretto Crypto
> Provider is a collection of high-performance cryptographic implementations
> exposed via standard JCA/JCE interfaces.
> 
> github.com 
> 
>
>
> On Aug 1, 2023, at 9:17 AM, Jim Showalter 
> wrote:
>
> I'm still trying to come up to speed on your PR/fork. A lot to learn!
>
> Ack about licensing. The idea wouldn't be to copy the code, but to learn
> how to implement message digests and HMAC on top of OpenSSL 3.0.8.
>
> On Tue, Aug 1, 2023, 5:03 AM Gary Gregory  wrote:
>
> In the short, the best way to help is to provide PRs.
> In more detail, we should probably come up with some kind of a plan so that
> everyone uses their time wisely.
>
> I'll review my branch this week or next and see where that stands, but feel
> free to look at it, use it, PR it, as I might not actually be able to take
> the time this week.
>
> WRT openssl4j, you CANNOT bring in anything licensed under the LGPL. IANAL,
> but our documentation seems clear to me, please see
> https://www.apache.org/legal/resolved.html#category-x
>
> Hope this helps and we can make it work!
> Gary
>
>
> On Mon, Jul 31, 2023, 8:02 PM Jim Showalter 
> wrote:
>
> A split seems reasonable. We were amazed at how few changes you had to
>
> make
>
> to support OpenSSL 3.x. The EVPs are very different. But it sounds like
> there's more to do.
>
> The problem with commons-codec is that it doesn't use OpenSSL or any
>
> other
>
> FIPS-certified cryptographic module. For example, HmacUtils uses Mac,
>
> which
>
> is supplied by the JRE, which isn't FIPS-certified.
>
> In order to qualify for FedRAMP High, which is table stakes for a lot of
> corporate and government contracts, FIPS has to be used. It's mandated by
> statute. No wiggle room.
>
> The promise of bc-fips is that it is FIPS-certified, is a JSP, and
> implements the full JCE. The drawback is that the bc-fips org is funded
> through donations and consulting, and is always very far behind Java
> releases (it's still on Java 11, for example).
>
> What we need is a full-featured JSP that is based on a FIPS-certified
> cryptographic module that is implemented using native code and JNI.
>
> We can get FIPS-certified digests and HMAC from openssl4j. What we need
> from commons-crypto are the ciphers, and they need to be on OpenSSL
>
> 3.0.8.
>
>
> If there's anything we can do to help make that happen, please let us
>
> know.
>
>
> On Mon, Jul 31, 2023 at 2:58 PM Gary Gregory 
> wrote:
>
> Hi Jim,
>
> My branch has not been merged because it does not fully work. It's
> challenging to update the code such that one can use either OpenSSL
>
> 1.1.1
>
> or 3.0.0 or both. We might need the component split into more than one
> Maven module.
>
> The name commons-crypto might have been poorly chosen because it's
>
> current
>
> remit is an OpelSSL wrapper. That said there is room for more features,
> which may mean splitting things up into more than one Maven module.
>
> Commons Code provides more convenience wrappers for JRE message digests
> including HMAC:
> https://commons.apache.org/proper/commons-codec/apidocs/index.html
>
> Are you looking to wrap or implement HMAC and message digests
>
> differently?
>
>
> Gary
>
>
> On Mon, Jul 31, 2023, 5:04 PM Jim Showalter <
>
> jamesleeshowal...@gmail.com
>
>
> wrote:
>
> We are trying to replace bc-fips (
>
> https://www.bouncycastle.org/fips-java/)
>
> with a JSP that is based on a cryptographic module that is 1) a
>
> native
>
> library and 2) is certified for FIPS 140-2 (
> https://csrc.nist.gov/pubs/fips/140-2/upd2/final).
>
> A native library is faster, plus it doesn't entangle the Java
>
> classpath
>
> with restrictions on Java versions or load order the way bc-fips
>
> does.
>
>
> The two available native libraries we're aware of are BoringSSL and
> OpenSSL.
>
> For various 

Re: [Crypto] Compile From Source and Openssl3 Support

[Alex Remily]

I've been meaning to add openssl3 support to common crypto for a while
now.  Maybe this will give me the push that I need.  I'm on my phone now
without access to the branch, but I recall a docker file that provided a
lot of build information on the main branch.  You may consider having a
look if you haven't already.


Alex

On Wed, Aug 9, 2023, 2:01 PM Daniel Thertell  wrote:

> ya that's totally fine!
> I will continue to try and figure this out.
>
> Thanks,
> Dan Thertell
>
>
> On Wed, Aug 9, 2023 at 4:53 PM Gary Gregory 
> wrote:
>
> > The branch is work in progress from a while ago, and it did not work
> > completely, that much i remember. I can't take the time today to look at
> it
> > today, I'm looking at other issues in Commons.
> >
> > Gary
> >
> > On Wed, Aug 9, 2023, 4:27 PM Daniel Thertell 
> wrote:
> >
> > > Hey Gary
> > >
> > > I believe I managed to get it to build, however I do have a few
> > questions.
> > >
> > > 1. Why were the make targets for the header files commented out and
> > > pointing to the wrong locations (in the make file)?
> > > 2. After successfully running make, how do I package everything into a
> > JAR
> > > for testing?
> > >
> > > Thanks,
> > > Dan Thertell
> > >
> > > On Wed, Aug 9, 2023 at 2:13 PM Daniel Thertell 
> > > wrote:
> > >
> > > > Hey Gary,
> > > >
> > > > lol ya I also have that note keeping issue!
> > > > By any chance do you know what the version env variable should be? I
> am
> > > > using 3_0_X right now.
> > > >
> > > > Thanks,
> > > > Dan Thertell
> > > >
> > > > On Wed, Aug 9, 2023 at 2:10 PM Gary Gregory 
> > > > wrote:
> > > >
> > > >> I should have kept notes!
> > > >>
> > > >> Gary
> > > >>
> > > >> On Wed, Aug 9, 2023, 1:49 PM Daniel Thertell 
> > > wrote:
> > > >>
> > > >> > Hey All,
> > > >> >
> > > >> > I am looking to compile Commons Crypto from source and I am
> > wondering
> > > if
> > > >> > there is any documentation for this process? I am trying to build
> > Gary
> > > >> > Gregory's OpenSSL3 branch but I am encountering the following
> > error. I
> > > >> know
> > > >> > this isn't the main branch but I am hoping someone will still be
> > able
> > > to
> > > >> > help out. I receive the following error when i run "make linux64"
> (i
> > > >> > received a similar error on a M1 when i ran 'make mac64')
> > > >> >
> > > >> > *** No rule to make target
> > > >> >
> > > >> >
> > > >>
> > >
> >
> 'target/jni-classes/org_apache_commons_crypto_random_OpenSslCryptoRandomNative.h',
> > > >> > needed by
> > > >> >
> > > 'target/commons-crypto-3_0_x-Linux-x86_64/OpenSslCryptoRandomNative.o'.
> > > >> > Stop.
> > > >> >
> > > >> > Any help or ideas would be appreciated!
> > > >> >
> > > >> > Thanks,
> > > >> > Dan Thertell
> > > >> >
> > > >>
> > > >
> > >
> >
>

Re: [ALL] Eventually, soon, Java 11

[Alex Remily]

Gary,

A few years ago I migrated commons crypto onto Java 11 in my local
environment.  I haven't kept the code, but it wasn't a heavy lift and I'm
happy to do it again for the community version.  Let me know how you'd like
me to proceed.

Alex

On Sun, Apr 23, 2023 at 9:47 AM Gary Gregory  wrote:

> Hi All,
>
> In the year 2023, and with Java 21 in EA (https://jdk.java.net/21/), I
> think it is time to start migrating our components from Java 8 to Java
> 11. I imagine this to happen slowly and surely over the course of this
> whole year.
>
> In addition, originally, it should also be time to update our GitHub
> builds to run on Java 21-EA.
>
> Gary
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE] Release Apache Commons Crypto 1.2.0 based on RC1

[Alex Remily]

Please remind me how the vote process works.  Do I just reply to this email?

On Fri, Jan 20, 2023 at 7:01 AM Gary Gregory  wrote:

> We need more reviews and votes please.
>
> Gary
>
> On Tue, Jan 17, 2023, 10:12 Gary Gregory  wrote:
>
> > Ping to PMC members.
> >
> > Gary
> >
> > On Sat, Jan 14, 2023, 17:39 Gary Gregory  wrote:
> >
> >> We have fixed a few bugs and made some enhancements since Apache
> >> Commons Crypto 1.1.0 was released, so I would like to release Apache
> >> Commons Crypto 1.2.0.
> >>
> >> Apache Commons Crypto 1.2.0 RC1 is available for review here:
> >> https://dist.apache.org/repos/dist/dev/commons/crypto/1.2.0-RC1
> >> (svn revision 59345)
> >>
> >> The Git tag commons-crypto-1.2.0-RC1 commit for this RC is
> >> d1ca10a92a61257ac225c6c1f8881af0aef91309 which you can browse here:
> >>
> >>
> https://gitbox.apache.org/repos/asf?p=commons-crypto.git;a=commit;h=d1ca10a92a61257ac225c6c1f8881af0aef91309
> >> You may checkout this tag using:
> >> git clone https://gitbox.apache.org/repos/asf/commons-crypto.git
> >> --branch <
> https://gitbox.apache.org/repos/asf/commons-crypto.git--branch>
> >> commons-crypto-1.2.0-RC1 commons-crypto-1.2.0-RC1
> >>
> >> Maven artifacts are here:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1616/org/apache/commons/commons-crypto/1.2.0/
> >>
> >> These are the artifacts and their hashes:
> >>
> >> #Release SHA-512s
> >> #Sat Jan 14 17:16:26 EST 2023
> >>
> >>
> commons-crypto-1.2.0-bin.tar.gz=fb9084a5d9adcd4df606c7deb9396fa5693443b6a91be12f5de17e4281d3e7d89b526dc6ebd7991569894bde2f9fb67036eb78504cb4fa26fae9b7a99d082051
> >>
> >>
> commons-crypto-1.2.0-bin.zip=c78d2d2f3343c0402d1e55301d9a85036550b937512024470ee9843f1cbcf6d28a49e2f1e2b2a6856c26898da61eec5739cfefac237abbf2e8735f0f69bb42bf
> >>
> >>
> commons-crypto-1.2.0-bom.json=104a6c100cad2e896836815449c0d74da1ab469e7260f0911ddf2230b6f89392ef4768768493192999b60dd36ffcca48483110508cee4c44e3a924fcbbe59a60
> >>
> >>
> commons-crypto-1.2.0-bom.xml=bf30ab0f46f0356d64ed4b3b39574c1dcc351b14d0f12233e63f1b8e9d04fb5fe223e2625dd118be65013682b9a64382fee29e56713a8bd949501b3f49bfd639
> >>
> >>
> commons-crypto-1.2.0-javadoc.jar=4a1944faca7aa68716bb2c55fafe0e10eff435c9ff10b1f3ad2cc96948c57ea0c7648b1fc6cb3d56a23d67f6f91b9e61d8b1eeb092e3c13335b2adba07e8540f
> >>
> >>
> commons-crypto-1.2.0-sources.jar=234fd31696293390c1e0f02a1b9362079452b5524bdb148fb635734f14c39d61c92a96799e2751d3291e33fee6cc2d469545b8b45d44486d9d5edf2b87ebf4c5
> >>
> >>
> commons-crypto-1.2.0-src.tar.gz=4ebbdc3eddedaeb142c2d4b30fe640b70f95d785d290b96422d7bd64f8179899c573a88e23048bf061e58d52c13f79ae6180fb694c2f86ec584b419847dbb381
> >>
> >>
> commons-crypto-1.2.0-src.zip=2ec1c7510893c6274722f587e6e5a2d3ec3ad4f077727be22fd85b13a18304feab5a93a5c57c82ffe9c8f2f8763b64452256e4053b5e186c68e620bf698ae857
> >>
> >>
> commons-crypto-1.2.0-test-sources.jar=d2a0218e8b60ca0f2f0b7b11d79636ec3d8c0f226b4a405d5f15a12f5128aeed65105b7b81310ada097fad85580276912910757b5672b66c2dacae7520a2506d
> >>
> >>
> commons-crypto-1.2.0-tests.jar=8439dd580eb36ba270da12c59c19c600ae1e2ea375e47b7bcf4855ac13a8baad833ee49d0796f804853a6639895c531318977c9f6b4760d3fc8617893a8d9b3f
> >>
> >>
> org.apache.commons_commons-crypto-1.2.0.spdx.json=31a4fa548308eda4c1798c9a5f6b0fef5c5034cb09586099c93dd93978e95fda81043faa45af237e5289ff9ecdccff8ec0b18af13e7ffc43095a79d3f217cb8b
> >>
> >> I have tested this with 'mvn -V -Prelease -Ptest-deploy clean package
> >> site deploy' using:
> >>
> >> Apache Maven 3.8.7 (b89d5959fcde851dcb1c8946a785a163f14e1e29)
> >> Maven home: /usr/local/Cellar/maven/3.8.7/libexec
> >> Java version: 1.8.0_352, vendor: Homebrew, runtime:
> >> /usr/local/Cellar/openjdk@8
> >> /1.8.0+352/libexec/openjdk.jdk/Contents/Home/jre
> >> Default locale: en_US, platform encoding: UTF-8
> >> OS name: "mac os x", version: "13.1", arch: "x86_64", family: "mac"
> >> Darwin gdg-mac-mini.local 22.2.0 Darwin Kernel Version 22.2.0: Fri Nov
> >> 11 02:08:47 PST 2022; root:xnu-8792.61.2~4/RELEASE_X86_64 x86_64
> >>
> >> Non-macOS native binaries were built on Windows 10 using Docker.
> >>
> >> Details of changes since 1.1.0 are in the release notes:
> >>
> >>
> https://dist.apache.org/repos/dist/dev/commons/crypto/1.2.0-RC1/RELEASE-NOTES.txt
> >>
> >>
> https://dist.apache.org/repos/dist/dev/commons/crypto/1.2.0-RC1/site/changes-report.html
> >>
> >> Site:
> >>
> >>
> https://dist.apache.org/repos/dist/dev/commons/crypto/1.2.0-RC1/site/index.html
> >> (note some *relative* links are broken and the 1.2.0 directories
> >> are not yet created - these will be OK once the site is deployed.)
> >>
> >> JApiCmp Report (compared to 1.1.0):
> >>
> >>
> https://dist.apache.org/repos/dist/dev/commons/crypto/1.2.0-RC1/site/japicmp.html
> >>
> >> RAT Report:
> >>
> >>
> https://dist.apache.org/repos/dist/dev/commons/crypto/1.2.0-RC1/site/rat-report.html
> >>
> >> KEYS:
> >>   https://downloads.apache.org/commons/KEYS
> >>
> >> Please review the release candidate and 

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

[Alex Remily]

I like the approach.  I wrote most of the version code that you're
touching, and your refactoring is more elegant.  I hadn't written much C
since school, so I kind of hacked my way through it.  It works, but
definitely room for improvement.  At first glance it appears that your
approach would be easier to build on when we start on OpenSSL 3.0
support, which is an added benefit.

Alex

On Fri, Jul 1, 2022 at 5:52 AM sebb  wrote:

> On Fri, 1 Jul 2022 at 04:16, Bernd Eckenfels 
> wrote:
> >
> > The Java.library.path controls the Java side loadLibrary() but that
> worked since it loaded the commons-crypto JNI lib.
> >
> > The dlopen In that shim searches various places, including PATH.
>
> According to dlopen(3) it does not search PATH, instead it uses
> LD_LIBRARY_PATH, and some DYLD_* paths.
>
> > If you can’t put the OpenSSL variant first, then it might instead help
> to define the path with a absolute name instead (maybe make it configurable
> with env or system property?)
>
> It's not possible in general to put the required version first, so I
> agree an (optional) override is needed.
> I don't think it would do any harm.
>
> BTW I'm working on code to show the actual path that was loaded; this
> will be shown in the Crypto main output.
>
> >
> https://github.com/apache/commons-crypto/blob/8539d5f09e483d8a01635df9df062e0a4972a71d/src/main/native/org/apache/commons/crypto/OpenSslInfoNative.c#L74
> >
> > It might also help to remove the global flag to avoid re-exports?
>
> Not sure that would make a difference here.
>
> > Whats the lib filename constant in above line in your case?
> >
> > Gruss
> > Bernd
> > --
> > http://bernd.eckenfels.net
> > 
> > Von: Alex Remily 
> > Gesendet: Friday, July 1, 2022 4:26:33 AM
> > An: Commons Developers List 
> > Betreff: Re: [CRYPTO] Problem with JNA on macOS and Windows
> >
> > 
> >
> > Yup.  Still loads LibreSSL.
> >
> > Alex@Alexs-MacBook-Pro commons-crypto % java
> > -Djava.library.path=/usr/local/opt/openssl/lib -cp target/classes
> > org.apache.commons.crypto.Crypto
> >
> > Apache Commons Crypto 1.1.1-SNAPSHOT
> >
> > Native code loaded OK: 1.1.1-SNAPSHOT
> >
> > Native name: Apache Commons Crypto
> >
> > Native built: Jun 30 2022
> >
> > OpenSSL library loaded OK, version: 0x2000
> >
> > OpenSSL library info: LibreSSL 2.2.9
> >
> > Random instance created OK:
> > org.apache.commons.crypto.random.OpenSslCryptoRandom@6442b0a6
> >
> > Cipher AES/CTR/NoPadding instance created OK:
> > org.apache.commons.crypto.cipher.OpenSslCipher@21bcffb5
> >
> > Additional OpenSSL_version(n) details:
> >
> > 1: not available
> >
> > 2: compiler: information not available
> >
> > 3: built on: date not available
> >
> > 4: platform: information not available
> >
> > 5: OPENSSLDIR: "/private/etc/ssl"
> >
> > Alex@Alexs-MacBook-Pro commons-crypto %
> >
> > On Thu, Jun 30, 2022 at 6:16 PM Gilles Sadowski 
> > wrote:
> >
> > > Le jeu. 30 juin 2022 à 23:35, sebb  a écrit :
> > > >
> > > > On Thu, 30 Jun 2022 at 16:21, Alex Remily 
> wrote:
> > > > >
> > > > >  when
> > > > > loading the dll, whereas Java apparently does not.>
> > > > >
> > > > > I experience the same behavior.  What's more interesting is that
> when
> > > I run
> > > > > the main function from Eclipse as a Run Configuration with the
> > > > > LD_LIBRARY_PATH set  as an Environment variable appended to the
> native
> > > > > environment, it runs as expected.  As of yet I haven't found a way
> to
> > > get
> > > > > the java CLI to recognize the LD_LIBRARY_PATH environment variable,
> > > even
> > > > > though it echos out correctly when queried.  Strange.
> > >
> > > Did you try with "java.library.path" (cf. [1])?
> > >
> > > Gilles
> > >
> > > [1]
> > >
> https://stackoverflow.com/questions/27945268/difference-between-using-java-library-path-and-ld-library-path
> > >
> > > > [...]
> > >
> > > -
> > > 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

[Alex Remily]

I tinkered with the same issues today and have come to the
same conclusion.  We may want to consider optionally prepending a path to
the COMMONS_CRYPTO_OPENSSL_LIBRARY to specify a specific libcrypto.

On Thu, Jun 30, 2022 at 5:35 PM sebb  wrote:

> On Thu, 30 Jun 2022 at 16:21, Alex Remily  wrote:
> >
> >  > loading the dll, whereas Java apparently does not.>
> >
> > I experience the same behavior.  What's more interesting is that when I
> run
> > the main function from Eclipse as a Run Configuration with the
> > LD_LIBRARY_PATH set  as an Environment variable appended to the native
> > environment, it runs as expected.  As of yet I haven't found a way to get
> > the java CLI to recognize the LD_LIBRARY_PATH environment variable, even
> > though it echos out correctly when queried.  Strange.
>
> If you use getenv within the JNI C code, it does not see any of the
> library-related environment variables.
>
> It looks like DYLD_* is dropped, along with LD_LIBRARY_PATH.
>
> There is some strange behaviour with export as well.
> Try the following:
>
> export LD_LIBRART_PATH=/usr/lib
> export LD_LIBRARY_PATH=/usr/lib
> env | grep LIBRAR
>
> I get:
>
> LD_LIBRART_PATH=/usr/lib
>
> Similarly with DYLD_*
>
> I think we may need to allow the user to provide the full path name to
> the crypto library.
>
> > On Thu, Jun 30, 2022 at 9:39 AM sebb  wrote:
> >
> > > I've started copying bits of the C code to create a standalone tool to
> > > load the dll and report some info.
> > >
> > > No idea why yet, but it behaves differently from basically the same
> > > code when run via JNI.
> > >
> > > For example, the standalone code takes note of LD_LIBRARY_PATH when
> > > loading the dll, whereas Java apparently does not.
> > >
> > > On Thu, 30 Jun 2022 at 13:22, Alex Remily 
> wrote:
> > > >
> > > > I also get the "Error looking up function 'ENGINE_load_rdrand'" when
> I
> > > run
> > > > the Jna test class from the command line.  Interesting.  dlopen
> finds the
> > > > LibreSSL when run from the CLI.
> > > >
> > > > On Thu, Jun 30, 2022 at 8:02 AM sebb  wrote:
> > > >
> > > > > That looks fine, however I don't see the same, and nor does GH.
> > > > >
> > > > > What version of macOS are you using?
> > > > >
> > > > > On Thu, 30 Jun 2022 at 12:52, Gary Gregory  >
> > > wrote:
> > > > > >
> > > > > > With the 1.1.0 tagm I get:
> > > > > >
> > > > > >  garydgregory@xxx  ~/git/commons-crypto  ➦ 3b2561b  java -cp
> > > > > > target/classes org.apache.commons.crypto.Crypto
> > > > > > Apache Commons Crypto 1.1.0
> > > > > > Native code loaded OK: 1.1.0
> > > > > > Native name: Apache Commons Crypto
> > > > > > Native built: Jun 30 2022
> > > > > > 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@266474c2
> > > > > > Cipher AES/CTR/NoPadding instance created OK:
> > > > > > org.apache.commons.crypto.cipher.OpenSslCipher@66d3c617
> > > > > > 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:30:00 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"
> > > > > >
> > > > > > and
> > > > > >
> > > > > >  garydgregory@xxx ~/git/commons-crypto  ➦ 3b2561b  mvn -q
> > > exec:java
> > > > > > -D"exec.mainClass=org.apache.commons.crypto.jna.OpenSslJna"
&

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

[Alex Remily]

Yup.  Still loads LibreSSL.

Alex@Alexs-MacBook-Pro commons-crypto % java
-Djava.library.path=/usr/local/opt/openssl/lib -cp target/classes
org.apache.commons.crypto.Crypto

Apache Commons Crypto 1.1.1-SNAPSHOT

Native code loaded OK: 1.1.1-SNAPSHOT

Native name: Apache Commons Crypto

Native built: Jun 30 2022

OpenSSL library loaded OK, version: 0x2000

OpenSSL library info: LibreSSL 2.2.9

Random instance created OK:
org.apache.commons.crypto.random.OpenSslCryptoRandom@6442b0a6

Cipher AES/CTR/NoPadding instance created OK:
org.apache.commons.crypto.cipher.OpenSslCipher@21bcffb5

Additional OpenSSL_version(n) details:

1: not available

2: compiler: information not available

3: built on: date not available

4: platform: information not available

5: OPENSSLDIR: "/private/etc/ssl"

Alex@Alexs-MacBook-Pro commons-crypto %

On Thu, Jun 30, 2022 at 6:16 PM Gilles Sadowski 
wrote:

> Le jeu. 30 juin 2022 à 23:35, sebb  a écrit :
> >
> > On Thu, 30 Jun 2022 at 16:21, Alex Remily  wrote:
> > >
> > >  > > loading the dll, whereas Java apparently does not.>
> > >
> > > I experience the same behavior.  What's more interesting is that when
> I run
> > > the main function from Eclipse as a Run Configuration with the
> > > LD_LIBRARY_PATH set  as an Environment variable appended to the native
> > > environment, it runs as expected.  As of yet I haven't found a way to
> get
> > > the java CLI to recognize the LD_LIBRARY_PATH environment variable,
> even
> > > though it echos out correctly when queried.  Strange.
>
> Did you try with "java.library.path" (cf. [1])?
>
> Gilles
>
> [1]
> https://stackoverflow.com/questions/27945268/difference-between-using-java-library-path-and-ld-library-path
>
> > [...]
>
> -
> 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

[Alex Remily]

I experience the same behavior.  What's more interesting is that when I run
the main function from Eclipse as a Run Configuration with the
LD_LIBRARY_PATH set  as an Environment variable appended to the native
environment, it runs as expected.  As of yet I haven't found a way to get
the java CLI to recognize the LD_LIBRARY_PATH environment variable, even
though it echos out correctly when queried.  Strange.

On Thu, Jun 30, 2022 at 9:39 AM sebb  wrote:

> I've started copying bits of the C code to create a standalone tool to
> load the dll and report some info.
>
> No idea why yet, but it behaves differently from basically the same
> code when run via JNI.
>
> For example, the standalone code takes note of LD_LIBRARY_PATH when
> loading the dll, whereas Java apparently does not.
>
> On Thu, 30 Jun 2022 at 13:22, Alex Remily  wrote:
> >
> > I also get the "Error looking up function 'ENGINE_load_rdrand'" when I
> run
> > the Jna test class from the command line.  Interesting.  dlopen finds the
> > LibreSSL when run from the CLI.
> >
> > On Thu, Jun 30, 2022 at 8:02 AM sebb  wrote:
> >
> > > That looks fine, however I don't see the same, and nor does GH.
> > >
> > > What version of macOS are you using?
> > >
> > > On Thu, 30 Jun 2022 at 12:52, Gary Gregory 
> wrote:
> > > >
> > > > With the 1.1.0 tagm I get:
> > > >
> > > >  garydgregory@xxx  ~/git/commons-crypto  ➦ 3b2561b  java -cp
> > > > target/classes org.apache.commons.crypto.Crypto
> > > > Apache Commons Crypto 1.1.0
> > > > Native code loaded OK: 1.1.0
> > > > Native name: Apache Commons Crypto
> > > > Native built: Jun 30 2022
> > > > 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@266474c2
> > > > Cipher AES/CTR/NoPadding instance created OK:
> > > > org.apache.commons.crypto.cipher.OpenSslCipher@66d3c617
> > > > 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:30:00 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"
> > > >
> > > > and
> > > >
> > > >  garydgregory@xxx ~/git/commons-crypto  ➦ 3b2561b  mvn -q
> exec:java
> > > > -D"exec.mainClass=org.apache.commons.crypto.jna.OpenSslJna"
> > > > isEnabled(): true
> > > > initialisationError(): null
> > > >
> > > > Gary
> > > >
> > > > On Thu, Jun 30, 2022 at 7:18 AM sebb  wrote:
> > > > >
> > > > > Yes, 1.1.0 builds OK on macOS, but the sample classes fail.
> > > > >
> > > > > As previously noted, please try:
> > > > > java -cp target/classes org.apache.commons.crypto.Crypto
> > > > > and
> > > > > mvn -q exec:java
> > > -D"exec.mainClass=org.apache.commons.crypto.jna.OpenSslJna"
> > > > >
> > > > > See the GH run I linked yesterday:
> > > > > https://github.com/apache/commons-crypto/actions/runs/2586011129
> > > > >
> > > > > I just noticed also that 'openssl version' shows 1.1.1p but the
> Crypto
> > > > > class shows
> > > > > OpenSSL library info: LibreSSL 2.2.9 (on current code; the 1.11.0
> code
> > > crashes)
> > > > >
> > > > > Something strange is going on; it looks like dlopen is finding a
> > > > > different version of the dynamic library from the default CLI.
> > > > > I have the same issue on my mac.
> > > > >
> > > > > On Thu, 30 Jun 2022 at 01:50, Gary Gregory  >
> > > wrote:
> > > > > >
> > > > > > FWIW, I just checked out the rel/commons-crypto-1.1.0 on macOS
> and
> > > ran
> 

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

[Alex Remily]

> > > > -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:
> > > > > >
> > > > > >  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 rel

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

[Alex Remily]

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

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

[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 

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

[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

[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] Updated docker build

[Alex Remily]

I went back and reviewed docker setup at your link:

https://github.com/apache/commons-crypto/tree/79374289bdd227b5b668039c9336cd10d9e3bf7c/src/docker

Nice work.  I agree that it's more flexible and provides the same
capability.  The instructions were straightforward and the end result was a
full build.  One can also experiment via the command line, which is nice.
A couple of comments.  The comments on lines 16-21 should be removed, as
you've provided updated instructions in the readme.  I recall that during
the last release process I recommended using 18.04 as the base image and
was overruled because of backwards compatibility concerns with the native
binaries.  I don't know that I share those concerns, but that was the
rationale for using the older base.

Otherwise, it seems ready to commit and close out 120 and 132.

Alex

On Tue, Jun 21, 2022 at 5:52 PM sebb  wrote:

> On Tue, 21 Jun 2022 at 22:32, Alex Remily  wrote:
> >
> >  previous
> > submission.>
> >
> > Don't know that it's an "improvement", but a different approach.  I think
> > if we provide a dockerfile that builds every supported arch (minus the
> Mac)
> > developers could easily modify it by removing parts they don't want as
> > opposed to adding dependencies and builds for the parts that they do.
>
> That is the case with my version.
> The builds are in separate script files that can be easily edited.
> And if a build fails due to a source issue, it can just be repeated
> after changing the source.
> No need to rebuild the image.
> Also no need to export the generated output as it is created on the host.
>
> > Also, I think this approach makes it easier for the next release manager
> > because it declares all the necessary dependencies and performs the
> builds
> > in the proper order.
>
> AFAICT there is no ordering issue with my version apart from linux32
> which needs an extra install.
>
> >  The last release was something of a challenge because
> > a lot of corporate knowledge had been lost when the original developers
> > left.
>
> Indeed.
>
> There is some documentation in the src/docker/README file, but it
> could be expanded.
>
> >  you
> > must have used a different checkout when you reported the failures.>
> >
> > I got sidetracked.  Apologies.  I need to do that and provide feedback.
> I
> > don't see why we can't have both, as long as we document them.
>
> I see no reason to have both.
>
> >  > updated.>
> >
> > As of this PR, it's in the POM but not in the dockerfile.
>
> Sorry, you are right.
> I thought I saw '32-bit build' but it was actually '32-bit Mac build'.
> Oops.
> We have already decided to drop that.
>
> > I see that you did a PR review.  I'll try to look at it tonight and
> > respond.
> >
> > Thanks.
> >
> > On Tue, Jun 21, 2022 at 4:23 PM sebb  wrote:
> >
> > > On Tue, 21 Jun 2022 at 20:00, Alex Remily 
> wrote:
> > > >
> > > > I went ahead and submitted a PR related to this discussion.  The
> > > dockerfile
> > > > does a full build, minus the Mac, and should simplify the release
> > > process.
> > >
> > > Not sure how it improves on the Docker build I derived from your
> > > previous submission.
> > >
> > > Did you try the sebb-docker branch again after my last reply?
> > > I think you must have used a different checkout when you reported the
> > > failures.
> > >
> > > > Developers can easily modify as needed for their own purposes.  I
> > > recommend
> > > > removing the 32-bit Mac build profile from the POM, but have not
> done so
> > > in
> > > > this PR.
> > >
> > > If it is removed from the POM then the Docker build will also need to
> > > be updated.
> > >
> > > Whilst it is unlikely that the 32 bit builds will be needed, at
> > > present they seem to work OK,
> > > so they might as well be kept.
> > >
> > > > Alex
> > > >
> > > > https://github.com/apache/commons-crypto/pull/166
> > > >
> > > > On Mon, Jun 20, 2022 at 10:24 AM sebb  wrote:
> > > >
> > > > > On Mon, 20 Jun 2022 at 14:35, Alex Remily 
> > > wrote:
> > > > > >
> > > > > > Sebb,
> > > > > >
> > > > > > I cloned your repo and ran the dockerfile.  Feedback:
> > > > > >
> > > > > > The Maven download link is broken.  It appears Apache updated to
> > > 3.8.6 on
> > > 

Re: [CRYPTO] Updated docker build

[Alex Remily]

Then I was definitely looking at the wrong version of your file.  I'll
circle back and run it again.

On Tue, Jun 21, 2022 at 5:52 PM sebb  wrote:

> On Tue, 21 Jun 2022 at 22:32, Alex Remily  wrote:
> >
> >  previous
> > submission.>
> >
> > Don't know that it's an "improvement", but a different approach.  I think
> > if we provide a dockerfile that builds every supported arch (minus the
> Mac)
> > developers could easily modify it by removing parts they don't want as
> > opposed to adding dependencies and builds for the parts that they do.
>
> That is the case with my version.
> The builds are in separate script files that can be easily edited.
> And if a build fails due to a source issue, it can just be repeated
> after changing the source.
> No need to rebuild the image.
> Also no need to export the generated output as it is created on the host.
>
> > Also, I think this approach makes it easier for the next release manager
> > because it declares all the necessary dependencies and performs the
> builds
> > in the proper order.
>
> AFAICT there is no ordering issue with my version apart from linux32
> which needs an extra install.
>
> >  The last release was something of a challenge because
> > a lot of corporate knowledge had been lost when the original developers
> > left.
>
> Indeed.
>
> There is some documentation in the src/docker/README file, but it
> could be expanded.
>
> >  you
> > must have used a different checkout when you reported the failures.>
> >
> > I got sidetracked.  Apologies.  I need to do that and provide feedback.
> I
> > don't see why we can't have both, as long as we document them.
>
> I see no reason to have both.
>
> >  > updated.>
> >
> > As of this PR, it's in the POM but not in the dockerfile.
>
> Sorry, you are right.
> I thought I saw '32-bit build' but it was actually '32-bit Mac build'.
> Oops.
> We have already decided to drop that.
>
> > I see that you did a PR review.  I'll try to look at it tonight and
> > respond.
> >
> > Thanks.
> >
> > On Tue, Jun 21, 2022 at 4:23 PM sebb  wrote:
> >
> > > On Tue, 21 Jun 2022 at 20:00, Alex Remily 
> wrote:
> > > >
> > > > I went ahead and submitted a PR related to this discussion.  The
> > > dockerfile
> > > > does a full build, minus the Mac, and should simplify the release
> > > process.
> > >
> > > Not sure how it improves on the Docker build I derived from your
> > > previous submission.
> > >
> > > Did you try the sebb-docker branch again after my last reply?
> > > I think you must have used a different checkout when you reported the
> > > failures.
> > >
> > > > Developers can easily modify as needed for their own purposes.  I
> > > recommend
> > > > removing the 32-bit Mac build profile from the POM, but have not
> done so
> > > in
> > > > this PR.
> > >
> > > If it is removed from the POM then the Docker build will also need to
> > > be updated.
> > >
> > > Whilst it is unlikely that the 32 bit builds will be needed, at
> > > present they seem to work OK,
> > > so they might as well be kept.
> > >
> > > > Alex
> > > >
> > > > https://github.com/apache/commons-crypto/pull/166
> > > >
> > > > On Mon, Jun 20, 2022 at 10:24 AM sebb  wrote:
> > > >
> > > > > On Mon, 20 Jun 2022 at 14:35, Alex Remily 
> > > wrote:
> > > > > >
> > > > > > Sebb,
> > > > > >
> > > > > > I cloned your repo and ran the dockerfile.  Feedback:
> > > > > >
> > > > > > The Maven download link is broken.  It appears Apache updated to
> > > 3.8.6 on
> > > > > > the 17th.  I think the 3.6.3 build is less likely (although
> still not
> > > > > > certain--as you pointed out) to get overwritten.
> > > > >
> > > > > My build uses 3.6.3, so I think you may have got the wrong checkout
> > > > >
> > > > >
> > > > >
> > >
> https://github.com/apache/commons-crypto/blob/79374289bdd227b5b668039c9336cd10d9e3bf7c/src/docker/Dockerfile#L52
> > > > >
> > > > > > RUN wget
> > > > > >
> > > > >
> > >
> https://dlcdn.apache.org/maven/maven-3/3.8.5/binaries/apache-maven-3.8.5-bin.tar.gz
> > > > >

Re: [CRYPTO] Updated docker build

[Alex Remily]

Don't know that it's an "improvement", but a different approach.  I think
if we provide a dockerfile that builds every supported arch (minus the Mac)
developers could easily modify it by removing parts they don't want as
opposed to adding dependencies and builds for the parts that they do.
Also, I think this approach makes it easier for the next release manager
because it declares all the necessary dependencies and performs the builds
in the proper order.  The last release was something of a challenge because
a lot of corporate knowledge had been lost when the original developers
left.



I got sidetracked.  Apologies.  I need to do that and provide feedback.  I
don't see why we can't have both, as long as we document them.



As of this PR, it's in the POM but not in the dockerfile.

I see that you did a PR review.  I'll try to look at it tonight and
respond.

Thanks.

On Tue, Jun 21, 2022 at 4:23 PM sebb  wrote:

> On Tue, 21 Jun 2022 at 20:00, Alex Remily  wrote:
> >
> > I went ahead and submitted a PR related to this discussion.  The
> dockerfile
> > does a full build, minus the Mac, and should simplify the release
> process.
>
> Not sure how it improves on the Docker build I derived from your
> previous submission.
>
> Did you try the sebb-docker branch again after my last reply?
> I think you must have used a different checkout when you reported the
> failures.
>
> > Developers can easily modify as needed for their own purposes.  I
> recommend
> > removing the 32-bit Mac build profile from the POM, but have not done so
> in
> > this PR.
>
> If it is removed from the POM then the Docker build will also need to
> be updated.
>
> Whilst it is unlikely that the 32 bit builds will be needed, at
> present they seem to work OK,
> so they might as well be kept.
>
> > Alex
> >
> > https://github.com/apache/commons-crypto/pull/166
> >
> > On Mon, Jun 20, 2022 at 10:24 AM sebb  wrote:
> >
> > > On Mon, 20 Jun 2022 at 14:35, Alex Remily 
> wrote:
> > > >
> > > > Sebb,
> > > >
> > > > I cloned your repo and ran the dockerfile.  Feedback:
> > > >
> > > > The Maven download link is broken.  It appears Apache updated to
> 3.8.6 on
> > > > the 17th.  I think the 3.6.3 build is less likely (although still not
> > > > certain--as you pointed out) to get overwritten.
> > >
> > > My build uses 3.6.3, so I think you may have got the wrong checkout
> > >
> > >
> > >
> https://github.com/apache/commons-crypto/blob/79374289bdd227b5b668039c9336cd10d9e3bf7c/src/docker/Dockerfile#L52
> > >
> > > > RUN wget
> > > >
> > >
> https://dlcdn.apache.org/maven/maven-3/3.8.5/binaries/apache-maven-3.8.5-bin.tar.gz
> > > >
> > > >
> > > > I updated all the references to 3.6.3 and reran the build.
> > > >
> > > >
> > > > It seems there is a pathing issue on the container:
> > > >
> > > >
> > > > > [22/23] RUN VERSION=1.1.1-SNAPSHOT
> > > > JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 make:
> > > >
> > > > #25 0.283 Error: Could not find or load main class
> > > > org.apache.commons.crypto.OsInfo
> > > >
> > > >
> > > > Note that it may not be possible to provide one *static* environment
> that
> > > > is capable of performing all builds.  This is because the 32-bit
> linux
> > > > build requires the "multilib" packages, and it appears that the
> > > "multilib"
> > > > packages overwrite the other gcc and g++ installations.  I happened
> > > across
> > > > this behavior when composing the full build dockerfile.  To
> illustrate,
> > > > refer to
> > > https://github.com/aremily/commons-crypto/blob/master/Dockerfile
> > > > and notice lines 63-65.  Now move the multilib installs (lines 63
> and 64)
> > > > somewhere before the other 32 bit builds (line 58), and I expect
> you'll
> > > get
> > > > a "not found" error during the build.
> > >
> > > Yes, I found that, and had to move linux32 into a separate build.
> > >
> > > It might perhaps be worth creating separate builds for 32 bit and 64
> bit
> > >
> > > However they would be nearly 2GB each, unless some pruning can be done.
> > >
> > > >
> > > > I would welcome the effort to (in)validate my observations or to
> > > identify a
> > > > solution.  I agr

Re: [CRYPTO] Updated docker build

[Alex Remily]

I went ahead and submitted a PR related to this discussion.  The dockerfile
does a full build, minus the Mac, and should simplify the release process.
Developers can easily modify as needed for their own purposes.  I recommend
removing the 32-bit Mac build profile from the POM, but have not done so in
this PR.

Alex

https://github.com/apache/commons-crypto/pull/166

On Mon, Jun 20, 2022 at 10:24 AM sebb  wrote:

> On Mon, 20 Jun 2022 at 14:35, Alex Remily  wrote:
> >
> > Sebb,
> >
> > I cloned your repo and ran the dockerfile.  Feedback:
> >
> > The Maven download link is broken.  It appears Apache updated to 3.8.6 on
> > the 17th.  I think the 3.6.3 build is less likely (although still not
> > certain--as you pointed out) to get overwritten.
>
> My build uses 3.6.3, so I think you may have got the wrong checkout
>
>
> https://github.com/apache/commons-crypto/blob/79374289bdd227b5b668039c9336cd10d9e3bf7c/src/docker/Dockerfile#L52
>
> > RUN wget
> >
> https://dlcdn.apache.org/maven/maven-3/3.8.5/binaries/apache-maven-3.8.5-bin.tar.gz
> >
> >
> > I updated all the references to 3.6.3 and reran the build.
> >
> >
> > It seems there is a pathing issue on the container:
> >
> >
> > > [22/23] RUN VERSION=1.1.1-SNAPSHOT
> > JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 make:
> >
> > #25 0.283 Error: Could not find or load main class
> > org.apache.commons.crypto.OsInfo
> >
> >
> > Note that it may not be possible to provide one *static* environment that
> > is capable of performing all builds.  This is because the 32-bit linux
> > build requires the "multilib" packages, and it appears that the
> "multilib"
> > packages overwrite the other gcc and g++ installations.  I happened
> across
> > this behavior when composing the full build dockerfile.  To illustrate,
> > refer to
> https://github.com/aremily/commons-crypto/blob/master/Dockerfile
> > and notice lines 63-65.  Now move the multilib installs (lines 63 and 64)
> > somewhere before the other 32 bit builds (line 58), and I expect you'll
> get
> > a "not found" error during the build.
>
> Yes, I found that, and had to move linux32 into a separate build.
>
> It might perhaps be worth creating separate builds for 32 bit and 64 bit
>
> However they would be nearly 2GB each, unless some pruning can be done.
>
> >
> > I would welcome the effort to (in)validate my observations or to
> identify a
> > solution.  I agree that it would be nice to provide an environment that
> > supports all build profiles.  I'm just not certain it's supportable.  I
> > think the simplest way ahead may be to provide one dockerfile that does a
> > full multi-arch build and let developers modify it as they see fit to
> > perform more limited builds.  Much easier to remove existing builds than
> to
> > add them.  Local builds can be performed locally, as they are now.
>
> That's partly why I removed the Maven builds from the Docker build; it
> makes things more flexible.
>
> >
> > Alex
> >
> >
> >
> >
> > On Sat, Jun 18, 2022 at 6:53 PM sebb  wrote:
> >
> > > I took the very useful Dockerfile from Alex and updated it to split
> > > the Maven build into a separate script.
> > >
> > > There are now two stages:
> > > - create the build environment with all the necessary tools
> > > - run Maven to build the various objects
> > >
> > > The container uses the source (and Maven repo) from the host, so the
> > > output is generated on the host.
> > >
> > > This means it is easy to make source changes; the Docker build should
> > > rarely need updating.
> > > For details, please see
> > > https://github.com/apache/commons-crypto/tree/sebb-docker/src/docker
> > >
> > > To try it, check out the sebb-docker branch and cd src/docker
> > >
> > > It probably needs some tweaking...
> > >
> > > 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] Updated docker build

[Alex Remily]

Sebb,

I cloned your repo and ran the dockerfile.  Feedback:

The Maven download link is broken.  It appears Apache updated to 3.8.6 on
the 17th.  I think the 3.6.3 build is less likely (although still not
certain--as you pointed out) to get overwritten.

RUN wget
https://dlcdn.apache.org/maven/maven-3/3.8.5/binaries/apache-maven-3.8.5-bin.tar.gz


I updated all the references to 3.6.3 and reran the build.


It seems there is a pathing issue on the container:


> [22/23] RUN VERSION=1.1.1-SNAPSHOT
JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 make:

#25 0.283 Error: Could not find or load main class
org.apache.commons.crypto.OsInfo


Note that it may not be possible to provide one *static* environment that
is capable of performing all builds.  This is because the 32-bit linux
build requires the "multilib" packages, and it appears that the "multilib"
packages overwrite the other gcc and g++ installations.  I happened across
this behavior when composing the full build dockerfile.  To illustrate,
refer to https://github.com/aremily/commons-crypto/blob/master/Dockerfile
and notice lines 63-65.  Now move the multilib installs (lines 63 and 64)
somewhere before the other 32 bit builds (line 58), and I expect you'll get
a "not found" error during the build.


I would welcome the effort to (in)validate my observations or to identify a
solution.  I agree that it would be nice to provide an environment that
supports all build profiles.  I'm just not certain it's supportable.  I
think the simplest way ahead may be to provide one dockerfile that does a
full multi-arch build and let developers modify it as they see fit to
perform more limited builds.  Much easier to remove existing builds than to
add them.  Local builds can be performed locally, as they are now.


Alex




On Sat, Jun 18, 2022 at 6:53 PM sebb  wrote:

> I took the very useful Dockerfile from Alex and updated it to split
> the Maven build into a separate script.
>
> There are now two stages:
> - create the build environment with all the necessary tools
> - run Maven to build the various objects
>
> The container uses the source (and Maven repo) from the host, so the
> output is generated on the host.
>
> This means it is easy to make source changes; the Docker build should
> rarely need updating.
> For details, please see
> https://github.com/apache/commons-crypto/tree/sebb-docker/src/docker
>
> To try it, check out the sebb-docker branch and cd src/docker
>
> It probably needs some tweaking...
>
> Sebb
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [CRYPTO] 32-bit builds for Windows and Mac - still needed?

[Alex Remily]

I've gone back and forth on that question myself.  My initial instinct was
to advocate dropping the 32 bit Windows support, but since then I've come
to the opinion that Commons Crypto should support 32 bit Windows as long as
OpenSSL still does.  There's minimal effort required to maintain
support, so why not?



Completely agree.

On Fri, Jun 17, 2022 at 9:38 AM sebb  wrote:

> The win32 profile build seems to work OK, but is there a need for it?
> If so, it can be added to build.sh; otherwise the profile and other
> references should be dropped.
>
> The mac32 profile build fails, and looks to be difficult to fix.
> We should remove it.
>
> Sebb
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [CRYPTO] Multiple Docker files - are they both needed?

[Alex Remily]

Yeah.  There's a couple tickets that could probably be subsumed by a new
one.  I'll have a look.

On Thu, Jun 16, 2022 at 8:04 PM Gilles Sadowski 
wrote:

> Hello.
>
> Le jeu. 16 juin 2022 à 19:36, Alex Remily  a écrit
> :
> >
> > Do you think we could simply use CRYPTO-120
> > <https://issues.apache.org/jira/browse/CRYPTO-120>?
>
> Maybe.
> Or open a new one with an up-to-date description,
> and signal that it replaces old/obsolete reports...
>
> Gilles
>
> > On Thu, Jun 16, 2022 at 1:31 PM Gilles Sadowski 
> > wrote:
> >
> > > Hello.
> > >
> > > Since there is an issue to be solved, could you file a report on JIRA?
> > > [And post there patches or new files, and instructions.]
> > >
> > > Thanks,
> > > Gilles
> > >
> > > Le jeu. 16 juin 2022 à 19:18, Alex Remily  a
> écrit
> > > :
> > > >
> > > > I just ran [2], and whatever it does, it doesn't appear to do a
> build of
> > > > commons-crypto.  I'd appreciate it if any developers who have the
> time
> > > > would take a look at the dockerfile here:
> > > >
> > > > https://github.com/aremily/commons-crypto
> > > >
> > > > If you're copying the dockerfile into your own fork, you'll need the
> > > > makefile.common file as well.
> > > >
> > > > Alex
> > > >
> > > > On Thu, Jun 16, 2022 at 1:07 PM Jochen Wiedmann <
> > > jochen.wiedm...@gmail.com>
> > > > wrote:
> > > >
> > > > > On Thu, Jun 16, 2022 at 7:00 PM sebb  wrote:
> > > > >
> > > > > > [1] src/docker/Dockerfile
> > > > > > [2] src/conf/Docker/Dockerfile-luw
> > > > >
> > > > > Have to admit, that I wasn't aware of [2], when I created [1].
> Mine is
> > > > > incomplete, and can easily be removed. Was basically just an
> attempt
> > > > > to reproduce the build instructions in the hope, that others would
> > > > > verify, and fix my errors.
> > > > >
> > > > > Jochen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Crypto] What is it ?

[Alex Remily]

sebb,

Thanks for taking the time to test it out and provide feedback.  Much
appreciated.  My thoughts below.



Good point.  I could modify the script to dump the final artifact in the
project root directory.



That link is static to that release and won't change with new updates.  The
directory structure maintains the version history:

https://downloads.apache.org/maven/maven-3/



That's the approach Gary took for the last release, and it's an open
question that I've posed to the community via another thread.  My
inclination is to do both.  Have one dockerfile that builds the
environment, and another that builds the artifact.



Actually the source is copied in from the host.  See "COPY .
/commons-crypto".



Agreed.  The Mac is the only build that can't be cross-compiled.  I think
it was Matt who noted on another thread that AWS offers MacVMs, which I
think is a promising route.

Thanks again for taking the time to provide feedback.

Alex


On Thu, Jun 16, 2022 at 2:48 PM sebb  wrote:

> On Thu, 16 Jun 2022 at 18:21, Alex Remily  wrote:
> >
> > Forwarding to the community dev list. Didn't realize it was dropped along
> > the way.
> >
> > Alex
> >
> > -- Forwarded message -
> > From: Alex Remily 
> > Date: Thu, Jun 16, 2022 at 1:01 PM
> > Subject: Re: [Crypto] What is it ?
> > To: Jochen Wiedmann 
> >
> >
> > Jochen,
> >
> > Please give my attempt at a docker build a try.  Copy the dockerfile and
> > the makefile.common file from the project directory at the link below
> into
> > your own project directory and try doing a "docker build . -t
> yourtagname"
> > from the project directory. The makefile.common is required because there
> > was a minor syntax error in the build args for the linux-arm build ("/"
> > omitted after JAVA_HOME) that caused the directory to resolve
> improperly).
> > Alternatively, you may be able to check out my fork and build it
> directly;
> > I'm not sure what the repo permissions allow.
> >
> > https://github.com/aremily/commons-crypto
> >
> > The dockerfile builds and tests the linux x86_64 build on Ubuntu 14.04
> and
> > cross compiles the remaining builds.  Note that I've omitted the Win32
> > build because I don't think anyone in the world uses 32 bit Windows
> > anymore, and the script itself can't do the Mac build (perhaps it's
> > possible to cross-compile for the Mac, but I lack the motivation to find
> > out at this point).  The workaround to perform a build that includes the
> > Mac is to perform Maven build on a Mac and then run the docker build.
> > Docker will copy the output of the Mac build into the container and
> bundle
> > it into the final artifact.
> >
> > Please provide feedback.  If it works, I'll update the build
> documentation
> > and submit a PR to close out CRYPTO-120
> > <https://issues.apache.org/jira/browse/CRYPTO-120>.
> >
>
> It works for me using Docker on macOS, though the output is in the
> container and it's not obvious how to extract it.
>
> I think it would be advisable to install Maven as a separate run step;
> if a new version is released (e.g. 3.6.4) the link will break.
> Ideally install the changeable items as separate steps, with the most
> volatile last to avoid rebuilds.
>
> Also I wonder if it would make sense to stop the build once all the
> required software has been installed, rather than continuing to build
> the code.
>
> This would make it easier to re-use the container with an updated
> crypto source; at present the source is built-in.
> This would require mapping the host source tree to the container; it
> would have the advantage that the output would end up on the host.
>
> If the host was macOS, I assume that could then be used to build the
> Mac object and generate the release.
> It's going to be easier to upload the release from the host rather
> than the container.
>
> > Alex
> >
> > On Wed, Jun 15, 2022 at 2:41 AM Jochen Wiedmann <
> jochen.wiedm...@gmail.com>
> > wrote:
> >
> > > Hi, Alex,
> > >
> > > ideally, I would like to have a variant of the current Dockerfile,
> > > that builds a jar file with all the binaries included. If we would
> > > have that, then we could use it to build a release.
> > >
> > > Thanks,
> > >
> > > Jochen
> > >
> > > On Tue, Jun 14, 2022 at 11:22 PM Alex Remily 
> > > wrote:
> > > >
> > > > Sure.  Happy to help.  I'll try to get to it this week.  I haven't
> been
> > > in the code for more than a year, so please be patient as 

Re: [Crypto] What is it ?

[Alex Remily]

I think that's a great idea, assuming as Gary pointed out that using a
MacVM for the build is legal (and I can't imagine AWS offering that service
if it wasn't).  Use the MacVM as the host OS.  Run the Mac build locally,
then run the dockerfile for the balance of the builds.  The Windows and
Linux builds can be cross-compiled.

On Thu, Jun 16, 2022 at 3:51 PM Matt Sicker  wrote:

> AWS offers macOS VMs. GitHub Actions support macOS which presumably uses
> something similar. I don’t think Apple offers an equivalent service, but
> there are more companies that do offer macOS VMs in the cloud.
>
> —
> Matt Sicker
>
> > On Jun 16, 2022, at 12:05, Jochen Wiedmann 
> wrote:
> >
> > On Wed, Jun 15, 2022 at 6:33 PM Matt Sicker  wrote:
> >>
> >> We could always request a Windows VM from Infra if necessary for
> building releases. Same for a Mac VM or Linux VM, though the Linux one can
> be done fairly easily via Docker on any OS (even FreeBSD supports Linux
> containers now).
> >
> > Didn't know, that MacOS VM's even exist. Seems like overkill, tohave
> > one, or even, two VM's just for a minor component, like Crypto. But
> > imagine such a VM, and a Jenkins agent/server running on it, which
> > could be used by all projects?
> >
> > Jochen
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>

Re: [CRYPTO] Multiple Docker files - are they both needed?

[Alex Remily]

Right.  Thanks for the pointer.

Ran a quick test on some of the build profiles, and dockerfile-luw is
missing dependencies for some of the linux builds, for example:

[exec] /bin/sh: 1: aarch64-linux-gnu-gcc: not found


That should be an easy fix that I'm happy to do, but to the larger question
of documenting the build process, I put the following to the community:


1.  Do we want a docker file like dockerfile-luw, which provides an
environment for the builds; or,

2.  do we want a docker file like the one at
https://github.com/aremily/commons-crypto that (nearly) completely
automates a full build; or,

3.  both; or

4.  something else?


I think there are benefits to 3, with the drawback being the potential
confusion of having two dockerfiles in one project.  I think, however, that
clear documentation could mitigate that drawback, while providing a fully
automated build capability as well as a flexible environment for targeted
builds.


Thoughts?

On Thu, Jun 16, 2022 at 1:58 PM sebb  wrote:

> On Thu, 16 Jun 2022 at 18:18, Alex Remily  wrote:
> >
> > I just ran [2], and whatever it does, it doesn't appear to do a build of
> > commons-crypto.
>
> That's correct; all it does is set up the environment.
> You have to then run Maven in the container.
>
> >  I'd appreciate it if any developers who have the time
> > would take a look at the dockerfile here:
> >
> > https://github.com/aremily/commons-crypto
> >
> > If you're copying the dockerfile into your own fork, you'll need the
> > makefile.common file as well.
> >
> > Alex
> >
> > On Thu, Jun 16, 2022 at 1:07 PM Jochen Wiedmann <
> jochen.wiedm...@gmail.com>
> > wrote:
> >
> > > On Thu, Jun 16, 2022 at 7:00 PM sebb  wrote:
> > >
> > > > [1] src/docker/Dockerfile
> > > > [2] src/conf/Docker/Dockerfile-luw
> > >
> > > Have to admit, that I wasn't aware of [2], when I created [1]. Mine is
> > > incomplete, and can easily be removed. Was basically just an attempt
> > > to reproduce the build instructions in the hope, that others would
> > > verify, and fix my errors.
> > >
> > > Jochen
> > >
> > > -
> > > 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] Multiple Docker files - are they both needed?

[Alex Remily]

Do you think we could simply use CRYPTO-120
<https://issues.apache.org/jira/browse/CRYPTO-120>?

On Thu, Jun 16, 2022 at 1:31 PM Gilles Sadowski 
wrote:

> Hello.
>
> Since there is an issue to be solved, could you file a report on JIRA?
> [And post there patches or new files, and instructions.]
>
> Thanks,
> Gilles
>
> Le jeu. 16 juin 2022 à 19:18, Alex Remily  a écrit
> :
> >
> > I just ran [2], and whatever it does, it doesn't appear to do a build of
> > commons-crypto.  I'd appreciate it if any developers who have the time
> > would take a look at the dockerfile here:
> >
> > https://github.com/aremily/commons-crypto
> >
> > If you're copying the dockerfile into your own fork, you'll need the
> > makefile.common file as well.
> >
> > Alex
> >
> > On Thu, Jun 16, 2022 at 1:07 PM Jochen Wiedmann <
> jochen.wiedm...@gmail.com>
> > wrote:
> >
> > > On Thu, Jun 16, 2022 at 7:00 PM sebb  wrote:
> > >
> > > > [1] src/docker/Dockerfile
> > > > [2] src/conf/Docker/Dockerfile-luw
> > >
> > > Have to admit, that I wasn't aware of [2], when I created [1]. Mine is
> > > incomplete, and can easily be removed. Was basically just an attempt
> > > to reproduce the build instructions in the hope, that others would
> > > verify, and fix my errors.
> > >
> > > Jochen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Fwd: [Crypto] What is it ?

[Alex Remily]

Forwarding to the community dev list. Didn't realize it was dropped along
the way.

Alex

-- Forwarded message -
From: Alex Remily 
Date: Thu, Jun 16, 2022 at 1:01 PM
Subject: Re: [Crypto] What is it ?
To: Jochen Wiedmann 


Jochen,

Please give my attempt at a docker build a try.  Copy the dockerfile and
the makefile.common file from the project directory at the link below into
your own project directory and try doing a "docker build . -t yourtagname"
from the project directory. The makefile.common is required because there
was a minor syntax error in the build args for the linux-arm build ("/"
omitted after JAVA_HOME) that caused the directory to resolve improperly).
Alternatively, you may be able to check out my fork and build it directly;
I'm not sure what the repo permissions allow.

https://github.com/aremily/commons-crypto

The dockerfile builds and tests the linux x86_64 build on Ubuntu 14.04 and
cross compiles the remaining builds.  Note that I've omitted the Win32
build because I don't think anyone in the world uses 32 bit Windows
anymore, and the script itself can't do the Mac build (perhaps it's
possible to cross-compile for the Mac, but I lack the motivation to find
out at this point).  The workaround to perform a build that includes the
Mac is to perform Maven build on a Mac and then run the docker build.
Docker will copy the output of the Mac build into the container and bundle
it into the final artifact.

Please provide feedback.  If it works, I'll update the build documentation
and submit a PR to close out CRYPTO-120
<https://issues.apache.org/jira/browse/CRYPTO-120>.

Alex

On Wed, Jun 15, 2022 at 2:41 AM Jochen Wiedmann 
wrote:

> Hi, Alex,
>
> ideally, I would like to have a variant of the current Dockerfile,
> that builds a jar file with all the binaries included. If we would
> have that, then we could use it to build a release.
>
> Thanks,
>
> Jochen
>
> On Tue, Jun 14, 2022 at 11:22 PM Alex Remily 
> wrote:
> >
> > Sure.  Happy to help.  I'll try to get to it this week.  I haven't been
> in the code for more than a year, so please be patient as I come back up to
> speed.  What exactly do you need help with?  Building the jar via the
> docker file?
> >
> > Alex
> >
> > On Tue, Jun 14, 2022 at 3:15 PM Jochen Wiedmann <
> jochen.wiedm...@gmail.com> wrote:
> >>
> >> Hi, Alex,
> >>
> >> On Tue, Jun 14, 2022 at 4:38 PM Alex Remily 
> wrote:
> >> > appropriately.  There is a Docker file currently in the repository,
> used
> >> > for the 1.1 release, that manages the cross-compilation for the JNI
> >> > libraries and packages them into the commons-crypto jar.
> >>
> >> Would you be able, and ready, to help me with that?
> >>
> >> Thanks,
> >>
> >> Jochen
>
>
>
> --
> Philosophy is useless, theology is worse. (Industrial Disease, Dire
> Straits)
>

Re: [CRYPTO] Multiple Docker files - are they both needed?

[Alex Remily]

I just ran [2], and whatever it does, it doesn't appear to do a build of
commons-crypto.  I'd appreciate it if any developers who have the time
would take a look at the dockerfile here:

https://github.com/aremily/commons-crypto

If you're copying the dockerfile into your own fork, you'll need the
makefile.common file as well.

Alex

On Thu, Jun 16, 2022 at 1:07 PM Jochen Wiedmann 
wrote:

> On Thu, Jun 16, 2022 at 7:00 PM sebb  wrote:
>
> > [1] src/docker/Dockerfile
> > [2] src/conf/Docker/Dockerfile-luw
>
> Have to admit, that I wasn't aware of [2], when I created [1]. Mine is
> incomplete, and can easily be removed. Was basically just an attempt
> to reproduce the build instructions in the hope, that others would
> verify, and fix my errors.
>
> Jochen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [CRYPTO] Multiple Docker files - are they both needed?

[Alex Remily]

Interesting.  Since I just finished up writing yet a third dockerfile, I'll
try running both of them and see what happens.  Hopefully, one of them was
used to perform the last release and we can just update the build
documentation to reflect.

On Thu, Jun 16, 2022 at 1:00 PM sebb  wrote:

> As the subject says: are the following both needed?
>
> [1] src/docker/Dockerfile
> [2] src/conf/Docker/Dockerfile-luw
>
> [1] uses a more recent version of ubuntu, but every install runs as a
> separate step, which increases resource usage
> [2] uses quite an old Ubuntu, and has a non-standard file name
>
> Can we eliminate one of the files?
>
> Sebb
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Crypto] What is it ?

[Alex Remily]

Currently, all a user needs to do to use commons-crypto is to include it as
a dependency in an application that runs on a supported operating system
with a supported version of OpenSSL (1.0 and 1.1).  Commons-crypto
dynamically, and IMO quite elegantly, determines the underlying OS and
OpenSSL version and calls the correct corresponding JNI library and OpenSSL
API.  It can do this because it packages JNI libraries for all supported
operating systems with the distribution and it performs runtime version
checks of OpenSSL.  It *is* easier to perform a single-platform build, but
that would require us to release a separate build for every supported OS,
which I would argue is more complex than releasing one build for all
supported operating systems.  Also, the heavy lifting of supporting a
multi-OS build has already been done via the existing Dockerfile.  I don't
see any reason to move away from the current release strategy.

On Tue, Jun 14, 2022 at 6:51 PM sebb  wrote:

> On Tue, 14 Jun 2022 at 16:26, Gary Gregory  wrote:
> >
> > Hi All,
> >
> > The component name was indeed ill chosen for what is effectively an
> > OpenSSL wrapper. Maybe we could make that obvious on the site by
> > calling the page "Apache Commons Crypto, an OpenSSL wrapper".
> >
> > I am in favor of adding more Java methods to wrap more OpenSSL APIs as
> > PR #165 does, that seems like a natural fit.
> >
> > I do not see the need to convert this component into a multi-module
> > Maven project. Keep it simple IMO.
>
> However, it might make it easier to release the binaries if they were
> packaged separately, one per OS.
>
> > Gary
> > https://github.com/apache/commons-crypto/pull/165
> >
> > On Tue, Jun 14, 2022 at 9:10 AM Gilles Sadowski 
> wrote:
> > >
> > > Hello.
> > >
> > > Contradicting comments about the latest contribution offer[1] suggest
> > > that the scope of the [Crypto] component is ill-defined.
> > >
> > > Is it a Java wrapper around a specific library ("openssl")?
> > > Is it a set of tools (a.o. strong random number generators) for
> developing
> > > cryptographic applications in Java?
> > > Is it both?  Does it intend to be more?
> > >
> > > In order to simplify maintenance (and clarify expectations), shouldn't
> it
> > > become a (maven) multi-module project, with explicit separation between
> > > platform-agnostic functionality and platform-specific (native) codes?
> > >
> > > Regards,
> > > Gilles
> > >
> > > [1] https://issues.apache.org/jira/browse/CRYPTO-162
> > >
> > > -
> > > 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] What is it ?

[Alex Remily]

Since we're talking about exposing new functionality, there's been a major
new OpenSSL release since our last release, so we should probably discuss
putting support for it on our roadmap, along with exposing
additional APIs.  I'd like to add support for Blake2 in the next release,
and I'm happy to help with the work.  I just need to wrap up a current
project to carve out some time.

Not sure of the proper mechanism for a discussion of the next release, but
look forward to participating.

Alex

On Tue, Jun 14, 2022 at 11:26 AM Gary Gregory 
wrote:

> Hi All,
>
> The component name was indeed ill chosen for what is effectively an
> OpenSSL wrapper. Maybe we could make that obvious on the site by
> calling the page "Apache Commons Crypto, an OpenSSL wrapper".
>
> I am in favor of adding more Java methods to wrap more OpenSSL APIs as
> PR #165 does, that seems like a natural fit.
>
> I do not see the need to convert this component into a multi-module
> Maven project. Keep it simple IMO.
>
> Gary
> https://github.com/apache/commons-crypto/pull/165
>
> On Tue, Jun 14, 2022 at 9:10 AM Gilles Sadowski 
> wrote:
> >
> > Hello.
> >
> > Contradicting comments about the latest contribution offer[1] suggest
> > that the scope of the [Crypto] component is ill-defined.
> >
> > Is it a Java wrapper around a specific library ("openssl")?
> > Is it a set of tools (a.o. strong random number generators) for
> developing
> > cryptographic applications in Java?
> > Is it both?  Does it intend to be more?
> >
> > In order to simplify maintenance (and clarify expectations), shouldn't it
> > become a (maven) multi-module project, with explicit separation between
> > platform-agnostic functionality and platform-specific (native) codes?
> >
> > Regards,
> > Gilles
> >
> > [1] https://issues.apache.org/jira/browse/CRYPTO-162
> >
> > -
> > 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] What is it ?

[Alex Remily]

As a user and past contributor, my view of Commons Crypto is that it is a
Java wrapper around certain common features of OpenSSL, full stop.  As
such, it provides near-native performance to the Java developer for
processor-intensive operations via a Java API.  It is a set of tools for
developing cryptographic applications in Java only to the extent that it
exposes underlying OpenSSL functionality.  The latest contribution offer
seems consistent with that scope because it relates specifically to
functionality that currently exists in the underlying native library.

I don't have a strong opinion as to whether the project should be converted
to multi-module, but I'm unclear as to whether or not it would confer any
additional benefit.  The existing project structure already separates the
native source from the Java source, and the maven build process already
compiles and packages the native and Java source and binaries
appropriately.  There is a Docker file currently in the repository, used
for the 1.1 release, that manages the cross-compilation for the JNI
libraries and packages them into the commons-crypto jar.

Anyway, that's my $0.02.

Alex

On Tue, Jun 14, 2022 at 9:10 AM Gilles Sadowski 
wrote:

> Hello.
>
> Contradicting comments about the latest contribution offer[1] suggest
> that the scope of the [Crypto] component is ill-defined.
>
> Is it a Java wrapper around a specific library ("openssl")?
> Is it a set of tools (a.o. strong random number generators) for developing
> cryptographic applications in Java?
> Is it both?  Does it intend to be more?
>
> In order to simplify maintenance (and clarify expectations), shouldn't it
> become a (maven) multi-module project, with explicit separation between
> platform-agnostic functionality and platform-specific (native) codes?
>
> Regards,
> Gilles
>
> [1] https://issues.apache.org/jira/browse/CRYPTO-162
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Crypto] How to build?

[Alex Remily]

I agree that a Docker build is a good idea.  In fact, I *thought* the
project already had a Dockerfile from the release process for 1.1.0.  I'm
certain that at least one contributor created one, but apparently it never
made the baseline.  I don't recall if it was actually used to build the
release.  Gary was the release manager, so he is probably the person most
likely to recall or to be aware of a functional Dockerfile's existence or
current location.

Alex

On Wed, May 18, 2022 at 2:34 PM Bernd Eckenfels 
wrote:

> Hello Jochen,
>
> I think that’s useful with the container. I would shift it relative to the
> source project, then you don’t need the wget and git clone but can use
> copy;mount to provide the source from the current version.
>
> But that’s probably not related to the problems you encounter.
>
> Gruss
> Bernd
>
>
> --
> http://bernd.eckenfels.net
> 
> Von: Jochen Wiedmann 
> Gesendet: Wednesday, May 18, 2022 4:59:43 PM
> An: Apache Commons Developers List 
> Betreff: [Crypto] How to build?
>
> Hi,
>
> I recently had the questionable pleasure to get in touch with Commons
> Crypto, and could not build it. There are some instructions in the
> BUILDING.txt file, but they aren't really helpful. In case, you don't
> know: Crypto is not a simple Java library. Instead, it requires
> building some shared libraries from C sources, that are being added to
> the jar file.
>
> The main problem here: We do not have something like a fully automated
> build procedure, that
>
>   a) ensures that the requirements are met, and then
>   b) performs all the necessary steps for building that jar file.
>
> Thinking about that, I came up with the idea, that we could add a
> Dockerfile to the sources, that could then be used with some simple
> commands, like
>
> docker image build -t apache/commons-crypto:1.1.1-SNAPSHOT
> docker container run --name mycrypto
> apache/commons-crypto:1.1.1-SNAPSHOT
> docker container cp
> "mycrypto:/usr/local/build/commons-crypto/target/*.jar" .
>
> (Not sure, that these might actually work, Docker beginner.)
>
> So, I started working with the Docker file below: Unfortnately, that fails
> with
> > [22/23] RUN VERSION=1.1.1-SNAPSHOT
> JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 make:
> #26 0.624 Error: Could not find or load main class
> org.apache.commons.crypto.OsInfo
> #26 0.697 Error: Could not find or load main class
> org.apache.commons.crypto.OsInfo
> #26 0.778 Error: Could not find or load main class
> org.apache.commons.crypto.OsInfo
> #26 0.790 make: *** No rule to make target
>
> 'target/jni-classes/org_apache_commons_crypto_random_OpenSslCryptoRandomNative.h',
> needed by
> 'target/commons-crypto-1.1.1-SNAPSHOT--/OpenSslCryptoRandomNative.o'.
> Stop.
>
> And that's, where I could need your help. What's wong?
>
> Thanks,
>
> Jochen
>
>
>
> FROM ubuntu:bionic-20220401
> RUN dpkg --add-architecture i386
> RUN apt update
> RUN apt-get -y install gcc
> RUN apt-get -y install g++
> RUN apt-get -y install make
> RUN apt-get -y install wget curl
> RUN apt-get -y install git
> RUN apt-get -y install openjdk-8-jdk
> RUN apt-get -y -oDebug::pkgAcquire::Worker=1 install openjdk-11-jdk
> RUN apt-get install -y mingw-w64
> # This package is documented in BUILDING.txt, but doesn't appear to be
> available.
> # RUN apt-get install -y x86_64-w64-mingw32-gcc
> RUN apt-get install -y gcc-mingw-w64-i686
> RUN apt-get install -y libssl-dev:i386 libssl-dev
> RUN apt-get install -y g++-multilib
> RUN mkdir -p /usr/local/build
> WORKDIR /usr/local/build
> RUN wget
> https://dlcdn.apache.org/maven/maven-3/3.8.5/binaries/apache-maven-3.8.5-bin.tar.gz
> RUN tar xzf apache-maven-3.8.5-bin.tar.gz
> RUN ln -s ../build/apache-maven-3.8.5/bin/mvn /usr/local/bin
> RUN git clone https://gitbox.apache.org/repos/asf/commons-crypto.git
> commons-crypto
> 
> WORKDIR /usr/local/build/commons-crypto
> RUN VERSION=1.1.1-SNAPSHOT JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 make
> RUN mvn
> CMD bash
>
>
>
>
> --
> Philosophy is useless, theology is worse. (Industrial Desease, Dire
> Straits)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [crypto] How to get the native library?

[Alex Remily]

If you actually don't have OpenSSL installed you can get it from the
website https://www.openssl.org/source/.

On Thu, May 5, 2022 at 4:24 PM Jochen Wiedmann 
wrote:

> Hi,
>
> trying to run the unit tests for commons-crypto, I get the error message
>
> Native library is not loaded
>
> I understand, what it tells me. However, I do not find any hints on
> how to get the native library. Not on the website, not in the
> top-level docs.
>
> Can anyone help with that?
>
> Thanks,
>
> Jochen
>
> P.S: My OS would be Windows, or Fedora Linux.
>
>
> --
> Philosophy is useless, theology is worse. (Industrial Desease, Dire
> Straits)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [crypto] How to get the native library?

[Alex Remily]

What version of OpenSSL do you have installed and how are you running the
unit tests, e.g., are you using the command line, maven, an integrated IDE
test runner, etc?

On Thu, May 5, 2022 at 4:24 PM Jochen Wiedmann 
wrote:

> Hi,
>
> trying to run the unit tests for commons-crypto, I get the error message
>
> Native library is not loaded
>
> I understand, what it tells me. However, I do not find any hints on
> how to get the native library. Not on the website, not in the
> top-level docs.
>
> Can anyone help with that?
>
> Thanks,
>
> Jochen
>
> P.S: My OS would be Windows, or Fedora Linux.
>
>
> --
> Philosophy is useless, theology is worse. (Industrial Desease, Dire
> Straits)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [crypto] Interest in adding support for cryptographic hash function?

[Alex Remily]

I echo all sentiments regarding benchmarking.  The deck at the link is a
bit dated, but it contains some benchmarking of the existing commons
crypto implementation against the JCE on JDK 8 and 9 that provides reason
for optimism.  Even if more recent versions of the JCE significantly narrow
the performance gap, which remains to be seen, I think commons crypto will
endure for the foreseeable future for users who need the performance and
can't or won't upgrade.

https://events.static.linuxfound.org/sites/events/files/slides/apache-commons-crypto-another-wheel.pdf

Regarding portability, the JNI libraries for each supported OS distribution
are bundled with the JAR and transparent to the caller of the commons
crypto api.  Yes, that makes it a hassle to build a release, but users need
only have libcrypto installed locally.



On Sun, Feb 28, 2021 at 6:21 PM Matt Sicker  wrote:

> That's why I'm interested in proper benchmarks before supporting a
> release of something with platform-specific code. The CPU extensions
> are ostensibly for optimizing the code where possible (the Blake3 code
> has a dynamic dispatch mechanism for checking CPU features at runtime
> to select the assembler-optimized variants), but if JNI overhead
> negates the gains there, then I'd agree that sticking to pure Java
> code here would be optimal.
>
> On Sun, 28 Feb 2021 at 17:18, sebb  wrote:
> >
> > On Sun, 28 Feb 2021 at 20:14, Matt Sicker  wrote:
> > >
> > > I'd also be interested in benchmarking comparisons as I've been
> > > working on a proof of concept using Blake3 to do similarly (I have a
> > > pure Java implementation and a JNI version that ultimately invokes the
> > > reference C implementation, though I've also wondered about linking
> > > the reference Rust implementation). The potential advantage to linking
> > > in the native implementations here would be in taking advantage of
> > > CPU-specific extensions like SSE, AVX, NEON, etc., which aren't
> > > accessible from the JVM without JNI or other patches to the JDK
> > > itself. If the overhead turns out to be non-negligible, then we should
> > > probably keep the native code bindings to commons-crypto while porting
> > > pure Java implementations to commons-codec.
> >
> > Of course the disadvantage is that the code is not portable.
> > Also each OS version will need separate testing and makes releasing
> > binaries harder.
> > This is an issue we have already faced with Crypto.
> > And there will be versions of Java for which it will not work.
> >
> > So unless the is a great performance improvement, I don't think it's
> > worth the extra overheads.
> >
> > > On Sun, 28 Feb 2021 at 09:25, Bernd Eckenfels 
> wrote:
> > > >
> > > > ... and also do benchmarking early, the native interface overhead
> might be a problem so that pure java (intrinsic) code is much faster
> > > >
> > > >
> > > > --
> > > > http://bernd.eckenfels.net
> > > > 
> > > > Von: Gary Gregory 
> > > > Gesendet: Sunday, February 28, 2021 2:45:26 PM
> > > > An: Commons Developers List 
> > > > Betreff: Re: [crypto] Interest in adding support for cryptographic
> hash function?
> > > >
> > > > That sounds reasonable to me. I think once we see a PR, we'll get a
> better
> > > > idea. Start small IMO.
> > > >
> > > > Gary
> > > >
> > > >
> > > > On Sat, Feb 27, 2021, 13:51 Alex Remily 
> wrote:
> > > >
> > > > > I'd be exposing additional elements of the OpenSSL API via
> additions to the
> > > > > commons crypto API.  Since I wouldn't be adding any additional
> > > > > dependencies, I would expect that licensing and portability would
> remain
> > > > > unchanged.  Would it not?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Alex
> > > > >
> > > > > On Sat, Feb 27, 2021 at 1:08 PM Gilles Sadowski <
> gillese...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Le sam. 27 févr. 2021 à 19:00, Bernd Eckenfels
> > > > > >  a écrit :
> > > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > I don’t think it’s a Good idea to introduce native
> dependencies to
> > > > > > formerly pure Java projects.
> > > > > >
> > > > > > +1
> > > >

Re: [crypto] Interest in adding support for cryptographic hash function?

[Alex Remily]

I'd be exposing additional elements of the OpenSSL API via additions to the
commons crypto API.  Since I wouldn't be adding any additional
dependencies, I would expect that licensing and portability would remain
unchanged.  Would it not?

Thanks,

Alex

On Sat, Feb 27, 2021 at 1:08 PM Gilles Sadowski 
wrote:

> Le sam. 27 févr. 2021 à 19:00, Bernd Eckenfels
>  a écrit :
> >
> > Hello,
> >
> > I don’t think it’s a Good idea to introduce native dependencies to
> formerly pure Java projects.
>
> +1
> [I thought that the idea was a (pure) Java implementation.]
>
> > So i think native optimized hash implementations would fit better in
> commons-crypto. So I would say go for it, keep in mind license clearance
> and portability.
> >
> > Gruß
> > Bernd
> >
> > > [...]
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[crypto] Interest in adding support for cryptographic hash function?

[Alex Remily]

I'm working on a project that makes heavy use of hashing, and I'd like to
use the OpenSSL implementation.  Thoughts on adding support for the SHA-2
and/or Blake2 family into commons crypto?  I'm happy to do the work if
there's someone out there willing to review and advise.

Alex

Re: Unapproved license

[Alex Remily]

Every time I've received a licence error working on the crypto project it
was because I was missing the Apache license in the source header.  That
seemed the most likely scenario here.

On Sun, Nov 22, 2020 at 11:22 AM sebb  wrote:

> On Sun, 22 Nov 2020 at 13:39, Alex Remily  wrote:
> >
> > Paste the license into the source file.  Check out any other source for
> an
> > example.
>
> Sorry, but that is not correct.
> One cannot just add the license to a file without checking that the
> license applies.
>
> What command are you using to build?
> Which files are causing the errors?
>
> It's possible that there are some spurious files that are being picked
> up by the license check.
> It may be necessary to update the list of excluded files, but again,
> this should only be done if the file does not need a license header.
>
> > On Sun, Nov 22, 2020 at 8:33 AM Arturo Bernal
> >  wrote:
> >
> > >
> > > Hi All,
> > >
> > >
> > > Ii'm trying to do some change in commons crypto project but i always
> get
> > > the following error-> "Too many files with unapproved license"
> > > Do i have to solve this issues?
> > >
> > >
> > >
> > > -
> > > 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: Unapproved license

[Alex Remily]

Paste the license into the source file.  Check out any other source for an
example.

On Sun, Nov 22, 2020 at 8:33 AM Arturo Bernal
 wrote:

>
> Hi All,
>
>
> Ii'm trying to do some change in commons crypto project but i always get
> the following error-> "Too many files with unapproved license"
> Do i have to solve this issues?
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE][RESULT] Release Apache Commons Crypto 1.1.0 based on RC1

[Alex Remily]

Speaking of which, do you want to do anything with the Dockerfile I
wrote for this build?  I have a pending PR that I can update or
withdraw, as necessary.

Alex

On Tue, Sep 1, 2020 at 3:38 PM Gary Gregory  wrote:
>
> It will be much easier moving forward IMO.
>
> Gary
>
> On Tue, Sep 1, 2020, 15:32 Geoffrey Blake 
> wrote:
>
> > Yes, thanks everyone for helping.  Was a long journey to get here.
> >
> > On Tue, Sep 1, 2020 at 11:32 AM Alex Remily  wrote:
> >
> > > Thank you to everyone involved for their part in getting this out.
> > >
> > > On Tue, Sep 1, 2020 at 11:58 AM Gary Gregory 
> > > wrote:
> > > >
> > > > This VOTE passes with the following +1s:
> > > >
> > > > - Alex Remily
> > > > - Geoffrey Blake
> > > > - Bruno P. Kinoshita, binding
> > > > - Rob Tompkins, binding
> > > > - Gary Gregory, binding
> > > >
> > > > Thank you all,
> > > > Gary
> > > >
> > > > On Tue, Sep 1, 2020 at 11:52 AM Gary Gregory 
> > > wrote:
> > > >
> > > > > My +1.
> > > > >
> > > > > Gary
> > > > >
> > > > > On Fri, Aug 28, 2020 at 4:35 PM Gary Gregory 
> > > wrote:
> > > > >
> > > > >> We have fixed quite a few bugs and added some significant
> > enhancements
> > > > >> since Apache Commons Crypto 1.0.0 was released, so I would like to
> > > release
> > > > >> Apache Commons Crypto 1.1.0.
> > > > >>
> > > > >> Apache Commons Crypto 1.1.0 RC1 is available for review here:
> > > > >> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1
> > > (svn
> > > > >> revision 41177)
> > > > >>
> > > > >> The Git tag commons-crypto-1.1.0-RC1 commit for this RC is
> > > > >> 3b2561bcdd9a428d01235a3d646cd08fbb6e597a which you can browse here:
> > > > >>
> > > > >>
> > >
> > https://gitbox.apache.org/repos/asf?p=commons-crypto.git;a=commit;h=3b2561bcdd9a428d01235a3d646cd08fbb6e597a
> > > > >> You may checkout this tag using:
> > > > >> git clone
> > https://gitbox.apache.org/repos/asf/commons-crypto.git
> > > > >> --branch commons-crypto-1.1.0-RC1 commons-crypto-1.1.0-RC1
> > > > >>
> > > > >> Maven artifacts are here:
> > > > >>
> > > > >>
> > >
> > https://repository.apache.org/content/repositories/orgapachecommons-1524/org/apache/commons/commons-crypto/1.1.0/
> > > > >>
> > > > >> These are the artifacts and their hashes:
> > > > >>
> > > > >> #Release SHA-512s
> > > > >> #Fri Aug 28 16:20:02 EDT 2020
> > > > >>
> > > > >>
> > >
> > commons-crypto-1.1.0-bin.tar.gz=a7c65d04bce6f6e415de5f818b9d13953bf819884e343ea47465a67ac8caaeb017dd54a1a7b3b47aab4a71f94fe9a2b8af7ba505b9d2d4786e90d095c3befa48
> > > > >>
> > > > >>
> > >
> > commons-crypto-1.1.0-bin.zip=5493b9b7967695efcb0c804fa3f3d27f66c3964b4a867c4e0ac3b92d116b71bce655254965092c8252882dd039e52b4386e42b8d306941811a839873a4c1e66a
> > > > >>
> > > > >>
> > >
> > commons-crypto-1.1.0-javadoc.jar=f37c1cadda93e87a5447cc6458d87441f03c0a4667ac2b647685b405b4b84f99bfbd6802741836a526303240671fcc0f89daabc851a6b31ecbf883f78b4bceed
> > > > >>
> > > > >>
> > >
> > commons-crypto-1.1.0-sources.jar=ed487f0100ca65ca6d5d0a7998a2ae86b2ed47f67040f3e5d60b0c27e145d9c64e79c51c3c179f4d7e06babd0c4fd1ed571ce58bf1190dd86a1c04d5cdc7a7f9
> > > > >>
> > > > >>
> > >
> > commons-crypto-1.1.0-src.tar.gz=f5ad97c8fdc722ff633b62e1653fb094bd95a7c0629fd7d203c3760ff4d99d665d415ea4180ed522021835f27ac0b4a17e2cd547e52705a8e3b99c1272a56436
> > > > >>
> > > > >>
> > >
> > commons-crypto-1.1.0-src.zip=3d877f5417d5446a79defa5c7575f903f37d8fcb19746a474f87ae6c39250cea8b2865238512892cc6f9394a590cbe4aa2cb80dde071e6731666c14625b9
> > > > >>
> > > > >>
> > >
> > commons-crypto-1.1.0-test-sources.jar=7d120012f27caa98362a2d871edec226a3910f17265ae0c8d8f889370c096e5413c43dc0a106aa163aaf0809ca1d90ee1af81641c21a1f3f8556f1d1b1979e41
> > > > >>
> > > > >>
> > >
> >

Re: [VOTE][RESULT] Release Apache Commons Crypto 1.1.0 based on RC1

[Alex Remily]

Thank you to everyone involved for their part in getting this out.

On Tue, Sep 1, 2020 at 11:58 AM Gary Gregory  wrote:
>
> This VOTE passes with the following +1s:
>
> - Alex Remily
> - Geoffrey Blake
> - Bruno P. Kinoshita, binding
> - Rob Tompkins, binding
> - Gary Gregory, binding
>
> Thank you all,
> Gary
>
> On Tue, Sep 1, 2020 at 11:52 AM Gary Gregory  wrote:
>
> > My +1.
> >
> > Gary
> >
> > On Fri, Aug 28, 2020 at 4:35 PM Gary Gregory  wrote:
> >
> >> We have fixed quite a few bugs and added some significant enhancements
> >> since Apache Commons Crypto 1.0.0 was released, so I would like to release
> >> Apache Commons Crypto 1.1.0.
> >>
> >> Apache Commons Crypto 1.1.0 RC1 is available for review here:
> >> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1 (svn
> >> revision 41177)
> >>
> >> The Git tag commons-crypto-1.1.0-RC1 commit for this RC is
> >> 3b2561bcdd9a428d01235a3d646cd08fbb6e597a which you can browse here:
> >>
> >> https://gitbox.apache.org/repos/asf?p=commons-crypto.git;a=commit;h=3b2561bcdd9a428d01235a3d646cd08fbb6e597a
> >> You may checkout this tag using:
> >> git clone https://gitbox.apache.org/repos/asf/commons-crypto.git
> >> --branch commons-crypto-1.1.0-RC1 commons-crypto-1.1.0-RC1
> >>
> >> Maven artifacts are here:
> >>
> >> https://repository.apache.org/content/repositories/orgapachecommons-1524/org/apache/commons/commons-crypto/1.1.0/
> >>
> >> These are the artifacts and their hashes:
> >>
> >> #Release SHA-512s
> >> #Fri Aug 28 16:20:02 EDT 2020
> >>
> >> commons-crypto-1.1.0-bin.tar.gz=a7c65d04bce6f6e415de5f818b9d13953bf819884e343ea47465a67ac8caaeb017dd54a1a7b3b47aab4a71f94fe9a2b8af7ba505b9d2d4786e90d095c3befa48
> >>
> >> commons-crypto-1.1.0-bin.zip=5493b9b7967695efcb0c804fa3f3d27f66c3964b4a867c4e0ac3b92d116b71bce655254965092c8252882dd039e52b4386e42b8d306941811a839873a4c1e66a
> >>
> >> commons-crypto-1.1.0-javadoc.jar=f37c1cadda93e87a5447cc6458d87441f03c0a4667ac2b647685b405b4b84f99bfbd6802741836a526303240671fcc0f89daabc851a6b31ecbf883f78b4bceed
> >>
> >> commons-crypto-1.1.0-sources.jar=ed487f0100ca65ca6d5d0a7998a2ae86b2ed47f67040f3e5d60b0c27e145d9c64e79c51c3c179f4d7e06babd0c4fd1ed571ce58bf1190dd86a1c04d5cdc7a7f9
> >>
> >> commons-crypto-1.1.0-src.tar.gz=f5ad97c8fdc722ff633b62e1653fb094bd95a7c0629fd7d203c3760ff4d99d665d415ea4180ed522021835f27ac0b4a17e2cd547e52705a8e3b99c1272a56436
> >>
> >> commons-crypto-1.1.0-src.zip=3d877f5417d5446a79defa5c7575f903f37d8fcb19746a474f87ae6c39250cea8b2865238512892cc6f9394a590cbe4aa2cb80dde071e6731666c14625b9
> >>
> >> commons-crypto-1.1.0-test-sources.jar=7d120012f27caa98362a2d871edec226a3910f17265ae0c8d8f889370c096e5413c43dc0a106aa163aaf0809ca1d90ee1af81641c21a1f3f8556f1d1b1979e41
> >>
> >> commons-crypto-1.1.0-tests.jar=35d769a1a7f0a8163e3bbb16880476cf0fc33d80c56da280901fe2c9e0e31162e7b8d39a8c7973b0b72295defb9bd13be9c2e2d2e225572b209fa8c70e5dddbc
> >>
> >> I have tested this with 'mvn -V -Duser.name=$my_apache_id
> >> -Dcommons_release_plugin_version=$commons_release_plugin_version -Prelease
> >> -Ptest-deploy -P jacoco -P japicmp package site deploy' plus building in
> >> Docker to produce the various native binaries using:
> >>
> >> 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"
> >>
> >> Details of changes since 1.0.0 are in the release notes:
> >>
> >> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/RELEASE-NOTES.txt
> >>
> >> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/site/changes-report.html
> >>
> >> Site:
> >>
> >> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/site/index.html
> >> (note some *relative* links are broken and the 1.1.0 directories are
> >> not yet created - these will be OK once the site is deployed.)
> >>
> >> *** JApiCmp Report (compared to 1.0.0):
> >>
> >> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/site/japicmp.html
> >>
> >> RAT Report:
> &

Re: [VOTE] Release Apache Commons Crypto 1.1.0 based on RC1

[Alex Remily]

Thanks Bruno.  Good info.

On Tue, Sep 1, 2020 at 7:51 AM Bruno P. Kinoshita  wrote:
>
> The vote is open to anyone Alex. The more the merrier.
>
> It has a requirement of at least three PMC members giving a +1 vote for the 
> vote to pass.
>
> Whenever a PMC -or anybody else in this mailing list- raises an issue or 
> votes -1 and explains what went wrong building or testing the proposed 
> release artefacts, we assess the issue and, in the case of a legit bug/issue, 
> then we cancel the vote, fix the issue, and then start over again.
>
> I got started with the ASF helping with vote threads, documentation issues, 
> and slowly got used to the code base, to the process and how to contribute. 
> So it's also a good way to get to know others here and get involved.
>
> Cheers
> Bruno
>
>
>
>
> On Tuesday, 1 September 2020, 11:41:08 pm NZST, Alex Remily 
>  wrote:
>
>
>
>
>
> What are the voting requirements?  Do you need to be an Apache member,
> committer, contributor, etc?
>
> On Mon, Aug 31, 2020 at 9:02 PM Gary Gregory  wrote:
> >
> > May I have PMC reviews please?
> >
> > Gary
> >
> > On Fri, Aug 28, 2020 at 4:35 PM Gary Gregory  wrote:
> >
> > > We have fixed quite a few bugs and added some significant enhancements
> > > since Apache Commons Crypto 1.0.0 was released, so I would like to release
> > > Apache Commons Crypto 1.1.0.
> > >
> > > Apache Commons Crypto 1.1.0 RC1 is available for review here:
> > >https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1 (svn
> > > revision 41177)
> > >
> > > The Git tag commons-crypto-1.1.0-RC1 commit for this RC is
> > > 3b2561bcdd9a428d01235a3d646cd08fbb6e597a which you can browse here:
> > >
> > > https://gitbox.apache.org/repos/asf?p=commons-crypto.git;a=commit;h=3b2561bcdd9a428d01235a3d646cd08fbb6e597a
> > > You may checkout this tag using:
> > >git clone https://gitbox.apache.org/repos/asf/commons-crypto.git
> > > --branch commons-crypto-1.1.0-RC1 commons-crypto-1.1.0-RC1
> > >
> > > Maven artifacts are here:
> > >
> > > https://repository.apache.org/content/repositories/orgapachecommons-1524/org/apache/commons/commons-crypto/1.1.0/
> > >
> > > These are the artifacts and their hashes:
> > >
> > > #Release SHA-512s
> > > #Fri Aug 28 16:20:02 EDT 2020
> > >
> > > commons-crypto-1.1.0-bin.tar.gz=a7c65d04bce6f6e415de5f818b9d13953bf819884e343ea47465a67ac8caaeb017dd54a1a7b3b47aab4a71f94fe9a2b8af7ba505b9d2d4786e90d095c3befa48
> > >
> > > commons-crypto-1.1.0-bin.zip=5493b9b7967695efcb0c804fa3f3d27f66c3964b4a867c4e0ac3b92d116b71bce655254965092c8252882dd039e52b4386e42b8d306941811a839873a4c1e66a
> > >
> > > commons-crypto-1.1.0-javadoc.jar=f37c1cadda93e87a5447cc6458d87441f03c0a4667ac2b647685b405b4b84f99bfbd6802741836a526303240671fcc0f89daabc851a6b31ecbf883f78b4bceed
> > >
> > > commons-crypto-1.1.0-sources.jar=ed487f0100ca65ca6d5d0a7998a2ae86b2ed47f67040f3e5d60b0c27e145d9c64e79c51c3c179f4d7e06babd0c4fd1ed571ce58bf1190dd86a1c04d5cdc7a7f9
> > >
> > > commons-crypto-1.1.0-src.tar.gz=f5ad97c8fdc722ff633b62e1653fb094bd95a7c0629fd7d203c3760ff4d99d665d415ea4180ed522021835f27ac0b4a17e2cd547e52705a8e3b99c1272a56436
> > >
> > > commons-crypto-1.1.0-src.zip=3d877f5417d5446a79defa5c7575f903f37d8fcb19746a474f87ae6c39250cea8b2865238512892cc6f9394a590cbe4aa2cb80dde071e6731666c14625b9
> > >
> > > commons-crypto-1.1.0-test-sources.jar=7d120012f27caa98362a2d871edec226a3910f17265ae0c8d8f889370c096e5413c43dc0a106aa163aaf0809ca1d90ee1af81641c21a1f3f8556f1d1b1979e41
> > >
> > > commons-crypto-1.1.0-tests.jar=35d769a1a7f0a8163e3bbb16880476cf0fc33d80c56da280901fe2c9e0e31162e7b8d39a8c7973b0b72295defb9bd13be9c2e2d2e225572b209fa8c70e5dddbc
> > >
> > > I have tested this with 'mvn -V -Duser.name=$my_apache_id
> > > -Dcommons_release_plugin_version=$commons_release_plugin_version -Prelease
> > > -Ptest-deploy -P jacoco -P japicmp package site deploy' plus building in
> > > Docker to produce the various native binaries using:
> > >
> > > 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"
> > >
> 

Re: [VOTE] Release Apache Commons Crypto 1.1.0 based on RC1

[Alex Remily]

What are the voting requirements?  Do you need to be an Apache member,
committer, contributor, etc?

On Mon, Aug 31, 2020 at 9:02 PM Gary Gregory  wrote:
>
> May I have PMC reviews please?
>
> Gary
>
> On Fri, Aug 28, 2020 at 4:35 PM Gary Gregory  wrote:
>
> > We have fixed quite a few bugs and added some significant enhancements
> > since Apache Commons Crypto 1.0.0 was released, so I would like to release
> > Apache Commons Crypto 1.1.0.
> >
> > Apache Commons Crypto 1.1.0 RC1 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1 (svn
> > revision 41177)
> >
> > The Git tag commons-crypto-1.1.0-RC1 commit for this RC is
> > 3b2561bcdd9a428d01235a3d646cd08fbb6e597a which you can browse here:
> >
> > https://gitbox.apache.org/repos/asf?p=commons-crypto.git;a=commit;h=3b2561bcdd9a428d01235a3d646cd08fbb6e597a
> > You may checkout this tag using:
> > git clone https://gitbox.apache.org/repos/asf/commons-crypto.git
> > --branch commons-crypto-1.1.0-RC1 commons-crypto-1.1.0-RC1
> >
> > Maven artifacts are here:
> >
> > https://repository.apache.org/content/repositories/orgapachecommons-1524/org/apache/commons/commons-crypto/1.1.0/
> >
> > These are the artifacts and their hashes:
> >
> > #Release SHA-512s
> > #Fri Aug 28 16:20:02 EDT 2020
> >
> > commons-crypto-1.1.0-bin.tar.gz=a7c65d04bce6f6e415de5f818b9d13953bf819884e343ea47465a67ac8caaeb017dd54a1a7b3b47aab4a71f94fe9a2b8af7ba505b9d2d4786e90d095c3befa48
> >
> > commons-crypto-1.1.0-bin.zip=5493b9b7967695efcb0c804fa3f3d27f66c3964b4a867c4e0ac3b92d116b71bce655254965092c8252882dd039e52b4386e42b8d306941811a839873a4c1e66a
> >
> > commons-crypto-1.1.0-javadoc.jar=f37c1cadda93e87a5447cc6458d87441f03c0a4667ac2b647685b405b4b84f99bfbd6802741836a526303240671fcc0f89daabc851a6b31ecbf883f78b4bceed
> >
> > commons-crypto-1.1.0-sources.jar=ed487f0100ca65ca6d5d0a7998a2ae86b2ed47f67040f3e5d60b0c27e145d9c64e79c51c3c179f4d7e06babd0c4fd1ed571ce58bf1190dd86a1c04d5cdc7a7f9
> >
> > commons-crypto-1.1.0-src.tar.gz=f5ad97c8fdc722ff633b62e1653fb094bd95a7c0629fd7d203c3760ff4d99d665d415ea4180ed522021835f27ac0b4a17e2cd547e52705a8e3b99c1272a56436
> >
> > commons-crypto-1.1.0-src.zip=3d877f5417d5446a79defa5c7575f903f37d8fcb19746a474f87ae6c39250cea8b2865238512892cc6f9394a590cbe4aa2cb80dde071e6731666c14625b9
> >
> > commons-crypto-1.1.0-test-sources.jar=7d120012f27caa98362a2d871edec226a3910f17265ae0c8d8f889370c096e5413c43dc0a106aa163aaf0809ca1d90ee1af81641c21a1f3f8556f1d1b1979e41
> >
> > commons-crypto-1.1.0-tests.jar=35d769a1a7f0a8163e3bbb16880476cf0fc33d80c56da280901fe2c9e0e31162e7b8d39a8c7973b0b72295defb9bd13be9c2e2d2e225572b209fa8c70e5dddbc
> >
> > I have tested this with 'mvn -V -Duser.name=$my_apache_id
> > -Dcommons_release_plugin_version=$commons_release_plugin_version -Prelease
> > -Ptest-deploy -P jacoco -P japicmp package site deploy' plus building in
> > Docker to produce the various native binaries using:
> >
> > 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"
> >
> > Details of changes since 1.0.0 are in the release notes:
> >
> > https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/RELEASE-NOTES.txt
> >
> > https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/site/changes-report.html
> >
> > Site:
> >
> > https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/site/index.html
> > (note some *relative* links are broken and the 1.1.0 directories are
> > not yet created - these will be OK once the site is deployed.)
> >
> > *** JApiCmp Report (compared to 1.0.0):
> >
> > https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/site/japicmp.html
> >
> > RAT Report:
> >
> > https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/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,
> >
> > Gary Gregory,
> > Release Manager (using key 86fdc7e2a11262cb)
> >
> > 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-crypto.git --branch
> > commons-crypto-1.1.0-RC1 commons-crypto-1.1.0-RC1
> > cd commons-crypto-1.1.0-RC1

Re: [VOTE] Release Apache Commons Crypto 1.1.0 based on RC1

[Alex Remily]

+1

Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /usr/local/Cellar/maven/3.6.3_1/libexec
Java version: 1.8.0_241, vendor: Oracle Corporation, runtime:
/Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac"
Darwin Alexs-MacBook-Pro.local 17.7.0 Darwin Kernel Version 17.7.0:
Thu Jun 18 21:21:34 PDT 2020; root:xnu-4570.71.82.5~1/RELEASE_X86_64
x86_64

On Fri, Aug 28, 2020 at 4:35 PM Gary Gregory  wrote:
>
> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons Crypto 1.0.0 was released, so I would like to release
> Apache Commons Crypto 1.1.0.
>
> Apache Commons Crypto 1.1.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1 (svn
> revision 41177)
>
> The Git tag commons-crypto-1.1.0-RC1 commit for this RC is
> 3b2561bcdd9a428d01235a3d646cd08fbb6e597a which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-crypto.git;a=commit;h=3b2561bcdd9a428d01235a3d646cd08fbb6e597a
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-crypto.git
> --branch commons-crypto-1.1.0-RC1 commons-crypto-1.1.0-RC1
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1524/org/apache/commons/commons-crypto/1.1.0/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Fri Aug 28 16:20:02 EDT 2020
> commons-crypto-1.1.0-bin.tar.gz=a7c65d04bce6f6e415de5f818b9d13953bf819884e343ea47465a67ac8caaeb017dd54a1a7b3b47aab4a71f94fe9a2b8af7ba505b9d2d4786e90d095c3befa48
> commons-crypto-1.1.0-bin.zip=5493b9b7967695efcb0c804fa3f3d27f66c3964b4a867c4e0ac3b92d116b71bce655254965092c8252882dd039e52b4386e42b8d306941811a839873a4c1e66a
> commons-crypto-1.1.0-javadoc.jar=f37c1cadda93e87a5447cc6458d87441f03c0a4667ac2b647685b405b4b84f99bfbd6802741836a526303240671fcc0f89daabc851a6b31ecbf883f78b4bceed
> commons-crypto-1.1.0-sources.jar=ed487f0100ca65ca6d5d0a7998a2ae86b2ed47f67040f3e5d60b0c27e145d9c64e79c51c3c179f4d7e06babd0c4fd1ed571ce58bf1190dd86a1c04d5cdc7a7f9
> commons-crypto-1.1.0-src.tar.gz=f5ad97c8fdc722ff633b62e1653fb094bd95a7c0629fd7d203c3760ff4d99d665d415ea4180ed522021835f27ac0b4a17e2cd547e52705a8e3b99c1272a56436
> commons-crypto-1.1.0-src.zip=3d877f5417d5446a79defa5c7575f903f37d8fcb19746a474f87ae6c39250cea8b2865238512892cc6f9394a590cbe4aa2cb80dde071e6731666c14625b9
> commons-crypto-1.1.0-test-sources.jar=7d120012f27caa98362a2d871edec226a3910f17265ae0c8d8f889370c096e5413c43dc0a106aa163aaf0809ca1d90ee1af81641c21a1f3f8556f1d1b1979e41
> commons-crypto-1.1.0-tests.jar=35d769a1a7f0a8163e3bbb16880476cf0fc33d80c56da280901fe2c9e0e31162e7b8d39a8c7973b0b72295defb9bd13be9c2e2d2e225572b209fa8c70e5dddbc
>
> I have tested this with 'mvn -V -Duser.name=$my_apache_id
> -Dcommons_release_plugin_version=$commons_release_plugin_version -Prelease
> -Ptest-deploy -P jacoco -P japicmp package site deploy' plus building in
> Docker to produce the various native binaries using:
>
> 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"
>
> Details of changes since 1.0.0 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/site/changes-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/site/index.html
> (note some *relative* links are broken and the 1.1.0 directories are
> not yet created - these will be OK once the site is deployed.)
>
> *** JApiCmp Report (compared to 1.0.0):
>
> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/site/japicmp.html
>
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/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,
>
> Gary Gregory,
> Release Manager (using key 86fdc7e2a11262cb)
>
> 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-crypto.git 

Re: [VOTE] Release Apache Commons Crypto 1.1.0 based on RC1

[Alex Remily]

Gary,

Should we note something about the backwards compatibility with
OpenSSL 1.0.2?  The way I read the docs now suggests that Commons
Crypto 1.0 supports OpenSSL 1.0.2 and that Commons Crypto 1.1 supports
OpenSSL 1.1.x.  In fact, the Commons Crypto 1.1 build supports OpenSSL
1.0.2+, 1.1.0 and 1.1.1.

Alex

On Fri, Aug 28, 2020 at 4:35 PM Gary Gregory  wrote:
>
> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons Crypto 1.0.0 was released, so I would like to release
> Apache Commons Crypto 1.1.0.
>
> Apache Commons Crypto 1.1.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1 (svn
> revision 41177)
>
> The Git tag commons-crypto-1.1.0-RC1 commit for this RC is
> 3b2561bcdd9a428d01235a3d646cd08fbb6e597a which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-crypto.git;a=commit;h=3b2561bcdd9a428d01235a3d646cd08fbb6e597a
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-crypto.git
> --branch commons-crypto-1.1.0-RC1 commons-crypto-1.1.0-RC1
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1524/org/apache/commons/commons-crypto/1.1.0/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Fri Aug 28 16:20:02 EDT 2020
> commons-crypto-1.1.0-bin.tar.gz=a7c65d04bce6f6e415de5f818b9d13953bf819884e343ea47465a67ac8caaeb017dd54a1a7b3b47aab4a71f94fe9a2b8af7ba505b9d2d4786e90d095c3befa48
> commons-crypto-1.1.0-bin.zip=5493b9b7967695efcb0c804fa3f3d27f66c3964b4a867c4e0ac3b92d116b71bce655254965092c8252882dd039e52b4386e42b8d306941811a839873a4c1e66a
> commons-crypto-1.1.0-javadoc.jar=f37c1cadda93e87a5447cc6458d87441f03c0a4667ac2b647685b405b4b84f99bfbd6802741836a526303240671fcc0f89daabc851a6b31ecbf883f78b4bceed
> commons-crypto-1.1.0-sources.jar=ed487f0100ca65ca6d5d0a7998a2ae86b2ed47f67040f3e5d60b0c27e145d9c64e79c51c3c179f4d7e06babd0c4fd1ed571ce58bf1190dd86a1c04d5cdc7a7f9
> commons-crypto-1.1.0-src.tar.gz=f5ad97c8fdc722ff633b62e1653fb094bd95a7c0629fd7d203c3760ff4d99d665d415ea4180ed522021835f27ac0b4a17e2cd547e52705a8e3b99c1272a56436
> commons-crypto-1.1.0-src.zip=3d877f5417d5446a79defa5c7575f903f37d8fcb19746a474f87ae6c39250cea8b2865238512892cc6f9394a590cbe4aa2cb80dde071e6731666c14625b9
> commons-crypto-1.1.0-test-sources.jar=7d120012f27caa98362a2d871edec226a3910f17265ae0c8d8f889370c096e5413c43dc0a106aa163aaf0809ca1d90ee1af81641c21a1f3f8556f1d1b1979e41
> commons-crypto-1.1.0-tests.jar=35d769a1a7f0a8163e3bbb16880476cf0fc33d80c56da280901fe2c9e0e31162e7b8d39a8c7973b0b72295defb9bd13be9c2e2d2e225572b209fa8c70e5dddbc
>
> I have tested this with 'mvn -V -Duser.name=$my_apache_id
> -Dcommons_release_plugin_version=$commons_release_plugin_version -Prelease
> -Ptest-deploy -P jacoco -P japicmp package site deploy' plus building in
> Docker to produce the various native binaries using:
>
> 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"
>
> Details of changes since 1.0.0 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/site/changes-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/site/index.html
> (note some *relative* links are broken and the 1.1.0 directories are
> not yet created - these will be OK once the site is deployed.)
>
> *** JApiCmp Report (compared to 1.0.0):
>
> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/site/japicmp.html
>
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/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,
>
> Gary Gregory,
> Release Manager (using key 86fdc7e2a11262cb)
>
> 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-crypto.git --branch
> commons-crypto-1.1.0-RC1 commons-crypto-1.1.0-RC1
> cd commons-crypto-1.1.0-RC1
>
> 2) Check Apache licenses
>
> This step is not required if the site includes a RAT report page which you
> then 

Re: [Crypto] requesting help testing native binaries

[Alex Remily]

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  wrote:
>
> On Mon, Aug 24, 2020 at 7:28 PM Alex Remily  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 
> > 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  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 
> > > > wrote:
> > > > >
> > > > > I wondering if anyone can confirm the following issue and/or help
> > explain
> > > 

Re: [Crypto] requesting help testing native binaries

[Alex Remily]

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  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  wrote:
>
> > Hi all,
> >
> > I intent on creating a release candidate for Commons Crypto soon.
> >
> > I pushed a snapshot today which contains native binaries for Windows 32
> > and 64, Linux 32 and 64, Mac 64, and ARM and ARM HF.
> >
> > Please help testing these on whatever platforms you may have access to.
> >
> > Gary
> >
> >
> >

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

Re: [Crypto] requesting help testing native binaries

[Alex Remily]

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  wrote:
>
> On Mon, Aug 24, 2020 at 12:10 PM Geoffrey Blake 
> 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  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 exp

Re: [Crypto] requesting help testing native binaries

[Alex Remily]

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  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 
>  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  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 <
> > garydgreg...@gmail.com> wrote:
> >
> >
> >
> >
> >
> > Hi all,
> >
> > I intent on creating a release candidate 

Re: [Crypto] requesting help testing native binaries

[Alex Remily]

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

Re: [Crypto] requesting help testing native binaries

[Alex Remily]

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  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  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 
> > 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 
> > wrote:
> > >
> > > > Hi all,
> > > >
> > > > I intent on creating a release candidate for Commons Crypto soon.
> > > >
> > > > I pushed a snapshot today which contains native binaries for Windows 32
> > > > and 64, Linux 32 and 64, Mac 64, and ARM and ARM HF.
> > > >
> > > > Please help testing these on whatever platforms you may have access to.
> > > >
> > > > Gary
> > > >
> > > >
> > > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

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

Re: [Crypto] requesting help testing native binaries

[Alex Remily]

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  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  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 
> > 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 
> > wrote:
> > >
> > > > Hi all,
> > > >
> > > > I intent on creating a release candidate for Commons Crypto soon.
> > > >
> > > > I pushed a snapshot today which contains native binaries for Windows 32
> > > > and 64, Linux 32 and 64, Mac 64, and ARM and ARM HF.
> > > >
> > > > Please help testing these on whatever platforms you may have access to.
> > > >
> > > > Gary
> > > >
> > > >
> > > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

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

Re: [Crypto] requesting help testing native binaries

[Alex Remily]

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  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  wrote:
>
> > Hi all,
> >
> > I intent on creating a release candidate for Commons Crypto soon.
> >
> > I pushed a snapshot today which contains native binaries for Windows 32
> > and 64, Linux 32 and 64, Mac 64, and ARM and ARM HF.
> >
> > Please help testing these on whatever platforms you may have access to.
> >
> > Gary
> >
> >
> >

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

Re: [Crypto] requesting help testing native binaries

[Alex Remily]

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  wrote:
>
> Hi all,
>
> I intent on creating a release candidate for Commons Crypto soon.
>
> I pushed a snapshot today which contains native binaries for Windows 32 and
> 64, Linux 32 and 64, Mac 64, and ARM and ARM HF.
>
> Please help testing these on whatever platforms you may have access to.
>
> Gary

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

Re: [CRYPTO] Random AEADBadTagException in GcmCipherTest?

[Alex Remily]

The test is fixed.  It's included in my PR #103, along with the
revised Dockerfile.

On Thu, Aug 6, 2020 at 11:03 AM Rob Tompkins  wrote:
>
> Precisely. That’s another technique we’ve used in rng.
>
> -Ropb
>
> > On Aug 6, 2020, at 11:01 AM, Matt Sicker  wrote:
> >
> > Or alternatively, if using random values each time, have it retry the
> > test with a different value. It's typically better to use an actual
> > property testing library for these types of tests anyways. One example
> > library I found is https://jqwik.net/ (these types of testing
> > libraries are more common in functional programming like in Scala).
> >
> > On Thu, 6 Aug 2020 at 09:59, Matt Sicker  wrote:
> >>
> >> Choose a seed value for the `new Random()` constructor and the tests
> >> will be deterministic.
> >>
> >> On Thu, 6 Aug 2020 at 09:57, Rob Tompkins  wrote:
> >>>
> >>>
> >>>
> >>>> On Aug 6, 2020, at 10:56 AM, Gary Gregory  wrote:
> >>>>
> >>>> This is all fine and good but how would you fix the test such that it 
> >>>> does
> >>>> not fail randomly. PR anyone?
> >>>
> >>> Either static inputs for determinism, or putting a probabilistic boundary 
> >>> in which the solution can fall.
> >>>
> >>> -Rob
> >>>
> >>>>
> >>>> Gary
> >>>>
> >>>> On Thu, Aug 6, 2020 at 10:54 AM Matt Sicker  wrote:
> >>>>
> >>>>> The ECC stuff I mostly learned about from various Bernstein papers
> >>>>> like this one: https://cr.yp.to/newelliptic/nistecc-20160106.pdf
> >>>>>
> >>>>> On Thu, 6 Aug 2020 at 09:50, Rob Tompkins  wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> On Aug 6, 2020, at 10:42 AM, Matt Sicker  wrote:
> >>>>>>>
> >>>>>>> Well, for testing RNGs, I can understand using property testing, yes.
> >>>>>>> It would also be useful for testing fuzzing scenarios like making sure
> >>>>>>> the GCM tag is invalid for any random input data (giving a near zero
> >>>>>>> probability of valid data) or that an elliptic curve implementation
> >>>>>>> doesn't leak out information about points outside the curve or respond
> >>>>>>> to invalid inputs improperly or things like that.
> >>>>>>
> >>>>>> +1 - the elliptic curve stuff I’ll have to defer to you on as I’m less 
> >>>>>> a
> >>>>> number theorist and more of a logician.
> >>>>>>
> >>>>>> -Rob
> >>>>>>
> >>>>>>>
> >>>>>>> On Thu, 6 Aug 2020 at 09:37, Rob Tompkins  wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On Aug 6, 2020, at 10:33 AM, Matt Sicker  wrote:
> >>>>>>>>>
> >>>>>>>>> Now I hope we don't have unit tests depending on non-static state 
> >>>>>>>>> for
> >>>>>>>>> its random number generator! ;)
> >>>>>>>>
> >>>>>>>> We actually do have a considerable number of those in our projects
> >>>>> where we use probabilistic epsilons on the output. See commons-rng. 
> >>>>> Note,
> >>>>> Gilles is quite good at writing such tests.
> >>>>>>>>
> >>>>>>>> -Rob
> >>>>>>>>
> >>>>>>>>> I'd expect a crypto library's test
> >>>>>>>>> suites to include several hard-coded known-good and known-bad
> >>>>>>>>> ciphertexts with static keys/IVs similar to the test cases presented
> >>>>>>>>> in their RFCs (especially since said tests are typically small 
> >>>>>>>>> enough
> >>>>>>>>> to copy/paste the binary data fairly easily).
> >>>>>>>>>
> >>>>>>>>> On Thu, 6 Aug 2020 at 08:19, Gary Gregory 
> >>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> On Thu, Aug 6, 2020 at 8:31 AM Alex Remily 
> >>>>

Re: [CRYPTO] Random AEADBadTagException in GcmCipherTest?

[Alex Remily]

Since I'm in the code base anyway I'll see if I can look at it this
weekend and include it in my PR with the Dockerfile.


On Thu, Aug 6, 2020 at 10:56 AM Gary Gregory  wrote:
>
> This is all fine and good but how would you fix the test such that it does
> not fail randomly. PR anyone?
>
> Gary
>
> On Thu, Aug 6, 2020 at 10:54 AM Matt Sicker  wrote:
>
> > The ECC stuff I mostly learned about from various Bernstein papers
> > like this one: https://cr.yp.to/newelliptic/nistecc-20160106.pdf
> >
> > On Thu, 6 Aug 2020 at 09:50, Rob Tompkins  wrote:
> > >
> > >
> > >
> > > > On Aug 6, 2020, at 10:42 AM, Matt Sicker  wrote:
> > > >
> > > > Well, for testing RNGs, I can understand using property testing, yes.
> > > > It would also be useful for testing fuzzing scenarios like making sure
> > > > the GCM tag is invalid for any random input data (giving a near zero
> > > > probability of valid data) or that an elliptic curve implementation
> > > > doesn't leak out information about points outside the curve or respond
> > > > to invalid inputs improperly or things like that.
> > >
> > > +1 - the elliptic curve stuff I’ll have to defer to you on as I’m less a
> > number theorist and more of a logician.
> > >
> > > -Rob
> > >
> > > >
> > > > On Thu, 6 Aug 2020 at 09:37, Rob Tompkins  wrote:
> > > >>
> > > >>
> > > >>
> > > >>> On Aug 6, 2020, at 10:33 AM, Matt Sicker  wrote:
> > > >>>
> > > >>> Now I hope we don't have unit tests depending on non-static state for
> > > >>> its random number generator! ;)
> > > >>
> > > >> We actually do have a considerable number of those in our projects
> > where we use probabilistic epsilons on the output. See commons-rng. Note,
> > Gilles is quite good at writing such tests.
> > > >>
> > > >> -Rob
> > > >>
> > > >>> I'd expect a crypto library's test
> > > >>> suites to include several hard-coded known-good and known-bad
> > > >>> ciphertexts with static keys/IVs similar to the test cases presented
> > > >>> in their RFCs (especially since said tests are typically small enough
> > > >>> to copy/paste the binary data fairly easily).
> > > >>>
> > > >>> On Thu, 6 Aug 2020 at 08:19, Gary Gregory 
> > wrote:
> > > >>>>
> > > >>>> On Thu, Aug 6, 2020 at 8:31 AM Alex Remily 
> > wrote:
> > > >>>>
> > > >>>>> No problem.  I'll do it when I get home tonight.
> > > >>>>>
> > > >>>>
> > > >>>> Thanks Alex!
> > > >>>>
> > > >>>> Gary
> > > >>>>
> > > >>>>
> > > >>>>>
> > > >>>>> On Thu, Aug 6, 2020, 8:25 AM Gary Gregory 
> > wrote:
> > > >>>>>
> > > >>>>>> Hi Alex,
> > > >>>>>>
> > > >>>>>> Would you mind creating that ticket with that info?
> > > >>>>>>
> > > >>>>>> Thank you,
> > > >>>>>> Gary
> > > >>>>>>
> > > >>>>>> On Thu, Aug 6, 2020, 08:10 Alex Remily 
> > wrote:
> > > >>>>>>
> > > >>>>>>> That is an intermittent issue that I haven't been able to
> > reliably
> > > >>>>>>> reproduce.  As I recall, the test that's failing is supposed to
> > fail,
> > > >>>>> but
> > > >>>>>>> in a different way.  I think it's supposed to fail because of a
> > short
> > > >>>>>>> buffer but occasionally fails because of an internal error, and
> > when
> > > >>>>> that
> > > >>>>>>> happens this test fails.  I don't know when it was introduced.
> > We
> > > >>>>> should
> > > >>>>>>> probably document it in jira and or realese notes.
> > > >>>>>>>
> > > >>>>>>> On Wed, Aug 5, 2020, 10:53 PM Gary Gregory <
> > garydgreg...@gmail.com>
> > > >>>>>> wrote:
> > > >&

Re: [CRYPTO] Random AEADBadTagException in GcmCipherTest?

[Alex Remily]

No problem.  I'll do it when I get home tonight.

On Thu, Aug 6, 2020, 8:25 AM Gary Gregory  wrote:

> Hi Alex,
>
> Would you mind creating that ticket with that info?
>
> Thank you,
> Gary
>
> On Thu, Aug 6, 2020, 08:10 Alex Remily  wrote:
>
> > That is an intermittent issue that I haven't been able to reliably
> > reproduce.  As I recall, the test that's failing is supposed to fail, but
> > in a different way.  I think it's supposed to fail because of a short
> > buffer but occasionally fails because of an internal error, and when that
> > happens this test fails.  I don't know when it was introduced.  We should
> > probably document it in jira and or realese notes.
> >
> > On Wed, Aug 5, 2020, 10:53 PM Gary Gregory 
> wrote:
> >
> > > Hi All:
> > >
> > > I am seeing what may be a random AEADBadTagException in GcmCipherTest?
> > >
> > > For example:
> > >
> > > [ERROR]
> > testGcmTamperedData(org.apache.commons.crypto.cipher.GcmCipherTest)
> > >  Time elapsed: 0.015 s  <<< ERROR!
> > > 881java.lang.Exception: Unexpected exception,
> > > expected but
> > > was
> > > 882 at
> > >
> >
> org.apache.commons.crypto.cipher.GcmCipherTest.testGcmTamperedData(GcmCipherTest.java:224)
> > > 883
> > > 884
> > >
> > >
> > >
> > >
> > >
> > > Any thoughts?
> > >
> > > The above is from
> > > https://travis-ci.org/github/apache/commons-crypto/jobs/715348986
> > >
> > > Gary
> > >
> >
>

Re: [CRYPTO] Random AEADBadTagException in GcmCipherTest?

[Alex Remily]

That is an intermittent issue that I haven't been able to reliably
reproduce.  As I recall, the test that's failing is supposed to fail, but
in a different way.  I think it's supposed to fail because of a short
buffer but occasionally fails because of an internal error, and when that
happens this test fails.  I don't know when it was introduced.  We should
probably document it in jira and or realese notes.

On Wed, Aug 5, 2020, 10:53 PM Gary Gregory  wrote:

> Hi All:
>
> I am seeing what may be a random AEADBadTagException in GcmCipherTest?
>
> For example:
>
> [ERROR] testGcmTamperedData(org.apache.commons.crypto.cipher.GcmCipherTest)
>  Time elapsed: 0.015 s  <<< ERROR!
> 881java.lang.Exception: Unexpected exception,
> expected but
> was
> 882 at
> org.apache.commons.crypto.cipher.GcmCipherTest.testGcmTamperedData(GcmCipherTest.java:224)
> 883
> 884
>
>
>
>
>
> Any thoughts?
>
> The above is from
> https://travis-ci.org/github/apache/commons-crypto/jobs/715348986
>
> Gary
>

Re: [crypto] New Release

[Alex Remily]

I don't see why it couldn't.  I don't think OSX images are publicly
accessible in Docker Hub though, and if not we'd need a Mac as the
base machine to run the build.  From the base machine we should be
able to call docker using the Maven exec plugin, use docker to pull in
the desired linux arch host, and configure that host to cross compile
the Windows build using MinGW.

Thoughts?  I'm convalescing this weekend so I should have some time to
try it out.

Alex

On Sat, Jul 25, 2020 at 12:21 AM Geoffrey Blake
 wrote:
>
> Docker would be great.  Next question, can that be integrated into
> Maven for automating these releases that someone knows offhand?
>
> -Geoff
>
> On Fri, Jul 24, 2020 at 7:50 PM Alex Remily  wrote:
> >
> > Sounds like a great idea.
> >
> > On Fri, Jul 24, 2020, 8:29 PM Marcelo Vanzin  wrote:
> >
> > > Is it possible to cross-compile from Linux to MacOS?
> > >
> > > Even if it isn't, might be a good idea to write a docker image to do
> > > the other cross-builds; then from a Mac you can build the MacOS binary
> > > and call docker to build all the others.
> > >
> > > On Fri, Jul 24, 2020 at 5:04 PM Alex Remily  wrote:
> > > >
> > > > I'd recommend using MinGW.  I installed it through brew on my Mac and
> > > cross
> > > > compiled the windows build with little difficulty.  I expect a similar
> > > > experience on Linux.  The MinGW install contains all the necessary
> > > windows
> > > > headers.
> > > >
> > > > On Fri, Jul 24, 2020, 7:16 PM Gary Gregory 
> > > wrote:
> > > >
> > > > > Thanks Geoffrey,
> > > > >
> > > > > Are you available at some point to do a webex to straighten out my
> > > local
> > > > > set up? Just email me directly so we can coordinate.
> > > > >
> > > > > Gary
> > > > >
> > > > > On Fri, Jul 24, 2020 at 4:34 PM Geoffrey Blake <
> > > geoffrey.w.bl...@gmail.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > Hi Gary,
> > > > > >
> > > > > > windows.h/Windows.h/WINDOWS.H are all names for the same file, on
> > > > > > Windows I've found out, the FS is case-insensitive.  This is not 
> > > > > > true
> > > > > > on a Linux box though.  I submitted a new PR to fix this and get
> > > > > > Windows builds working again on a Linux box, as well as testing that
> > > > > > windows artifacts will still build via Travis.  Hopefully this can
> > > > > > unstick the release as you can now cross-compile everything save the
> > > > > > OSX shared-lib on one box by pointing Maven to the proper targets.
> > > > > >
> > > > > > -Geoff
> > > > > >
> > > > > > On Sat, Jul 18, 2020 at 11:25 AM Gary Gregory <
> > > garydgreg...@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > On Thu, Jul 2, 2020 at 12:39 PM Geoffrey Blake <
> > > > > > geoffrey.w.bl...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I took a bit of time to set up an x86 Ubuntu 14.04 VM via
> > > virtualbox
> > > > > > > > and vagrant, but it looks like the windows build is broken.
> > > There
> > > > > are
> > > > > > > > typos trying to include "Windows.h" which should be "windows.h"
> > > to
> > > > > > > >
> > > > > > >
> > > > > > > Are you sure that this include is not referring the to Microsoft
> > > > > header,
> > > > > > > for example, on my machine:
> > > > > > >
> > > > > > > C:\Program Files (x86)\Windows
> > > > > Kits\10\Include\10.0.17763.0\um\Windows.h
> > > > > > >
> > > > > > > ?
> > > > > > >
> > > > > > > Gary
> > > > > > >
> > > > > > > > compile with mingw and redefined macros that I think are mixing
> > > > > > > > between Linux and windows headers.  I won't be able to get to
> > > trying
> > > > > > > > to fix and submit any PRs on these this week or next.  But
> > > 

Re: [crypto] New Release

[Alex Remily]

Sounds like a great idea.

On Fri, Jul 24, 2020, 8:29 PM Marcelo Vanzin  wrote:

> Is it possible to cross-compile from Linux to MacOS?
>
> Even if it isn't, might be a good idea to write a docker image to do
> the other cross-builds; then from a Mac you can build the MacOS binary
> and call docker to build all the others.
>
> On Fri, Jul 24, 2020 at 5:04 PM Alex Remily  wrote:
> >
> > I'd recommend using MinGW.  I installed it through brew on my Mac and
> cross
> > compiled the windows build with little difficulty.  I expect a similar
> > experience on Linux.  The MinGW install contains all the necessary
> windows
> > headers.
> >
> > On Fri, Jul 24, 2020, 7:16 PM Gary Gregory 
> wrote:
> >
> > > Thanks Geoffrey,
> > >
> > > Are you available at some point to do a webex to straighten out my
> local
> > > set up? Just email me directly so we can coordinate.
> > >
> > > Gary
> > >
> > > On Fri, Jul 24, 2020 at 4:34 PM Geoffrey Blake <
> geoffrey.w.bl...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hi Gary,
> > > >
> > > > windows.h/Windows.h/WINDOWS.H are all names for the same file, on
> > > > Windows I've found out, the FS is case-insensitive.  This is not true
> > > > on a Linux box though.  I submitted a new PR to fix this and get
> > > > Windows builds working again on a Linux box, as well as testing that
> > > > windows artifacts will still build via Travis.  Hopefully this can
> > > > unstick the release as you can now cross-compile everything save the
> > > > OSX shared-lib on one box by pointing Maven to the proper targets.
> > > >
> > > > -Geoff
> > > >
> > > > On Sat, Jul 18, 2020 at 11:25 AM Gary Gregory <
> garydgreg...@gmail.com>
> > > > wrote:
> > > > >
> > > > > On Thu, Jul 2, 2020 at 12:39 PM Geoffrey Blake <
> > > > geoffrey.w.bl...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > I took a bit of time to set up an x86 Ubuntu 14.04 VM via
> virtualbox
> > > > > > and vagrant, but it looks like the windows build is broken.
> There
> > > are
> > > > > > typos trying to include "Windows.h" which should be "windows.h"
> to
> > > > > >
> > > > >
> > > > > Are you sure that this include is not referring the to Microsoft
> > > header,
> > > > > for example, on my machine:
> > > > >
> > > > > C:\Program Files (x86)\Windows
> > > Kits\10\Include\10.0.17763.0\um\Windows.h
> > > > >
> > > > > ?
> > > > >
> > > > > Gary
> > > > >
> > > > > > compile with mingw and redefined macros that I think are mixing
> > > > > > between Linux and windows headers.  I won't be able to get to
> trying
> > > > > > to fix and submit any PRs on these this week or next.  But
> anyone who
> > > > > > wants to try cross-compiling, here are the packages I installed
> to
> > > get
> > > > > > up and running minimally on Ubuntu:
> > > > > >
> > > > > > sudo apt-get install build-essential g++-mingw-w64
> > > > > > gcc-aarch64-linux-gnu libc6-dev-i386
> > > > > > sudo apt-get install libssl-dev git
> > > > > > sudo add-apt-repository ppa:openjdk-r/ppa
> > > > > > sudo apt-get install openjdk-8-jdk
> > > > > >
> > > > > > Don't install the Ubuntu supplied maven, its too old.  Just grab
> the
> > > > > > 3.6 tarball from apache.
> > > > > >
> > > > > > -Geoff
> > > > > >
> > > > > > On Tue, Jun 30, 2020 at 8:24 PM Alex Remily <
> alex.rem...@gmail.com>
> > > > wrote:
> > > > > > >
> > > > > > > I'll see if I have any time this weekend, but this part is
> largely
> > > > > > > unfamiliar to me, so not sure how far I'll get even if I have
> the
> > > > time
> > > > > > > to look at it.
> > > > > > >
> > > > > > > On Tue, Jun 30, 2020 at 4:59 PM Geoffrey Blake
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > I think you're right Alex.  I just happ

Re: [crypto] New Release

[Alex Remily]

I'd recommend using MinGW.  I installed it through brew on my Mac and cross
compiled the windows build with little difficulty.  I expect a similar
experience on Linux.  The MinGW install contains all the necessary windows
headers.

On Fri, Jul 24, 2020, 7:16 PM Gary Gregory  wrote:

> Thanks Geoffrey,
>
> Are you available at some point to do a webex to straighten out my local
> set up? Just email me directly so we can coordinate.
>
> Gary
>
> On Fri, Jul 24, 2020 at 4:34 PM Geoffrey Blake  >
> wrote:
>
> > Hi Gary,
> >
> > windows.h/Windows.h/WINDOWS.H are all names for the same file, on
> > Windows I've found out, the FS is case-insensitive.  This is not true
> > on a Linux box though.  I submitted a new PR to fix this and get
> > Windows builds working again on a Linux box, as well as testing that
> > windows artifacts will still build via Travis.  Hopefully this can
> > unstick the release as you can now cross-compile everything save the
> > OSX shared-lib on one box by pointing Maven to the proper targets.
> >
> > -Geoff
> >
> > On Sat, Jul 18, 2020 at 11:25 AM Gary Gregory 
> > wrote:
> > >
> > > On Thu, Jul 2, 2020 at 12:39 PM Geoffrey Blake <
> > geoffrey.w.bl...@gmail.com>
> > > wrote:
> > >
> > > > I took a bit of time to set up an x86 Ubuntu 14.04 VM via virtualbox
> > > > and vagrant, but it looks like the windows build is broken.  There
> are
> > > > typos trying to include "Windows.h" which should be "windows.h" to
> > > >
> > >
> > > Are you sure that this include is not referring the to Microsoft
> header,
> > > for example, on my machine:
> > >
> > > C:\Program Files (x86)\Windows
> Kits\10\Include\10.0.17763.0\um\Windows.h
> > >
> > > ?
> > >
> > > Gary
> > >
> > > > compile with mingw and redefined macros that I think are mixing
> > > > between Linux and windows headers.  I won't be able to get to trying
> > > > to fix and submit any PRs on these this week or next.  But anyone who
> > > > wants to try cross-compiling, here are the packages I installed to
> get
> > > > up and running minimally on Ubuntu:
> > > >
> > > > sudo apt-get install build-essential g++-mingw-w64
> > > > gcc-aarch64-linux-gnu libc6-dev-i386
> > > > sudo apt-get install libssl-dev git
> > > > sudo add-apt-repository ppa:openjdk-r/ppa
> > > > sudo apt-get install openjdk-8-jdk
> > > >
> > > > Don't install the Ubuntu supplied maven, its too old.  Just grab the
> > > > 3.6 tarball from apache.
> > > >
> > > > -Geoff
> > > >
> > > > On Tue, Jun 30, 2020 at 8:24 PM Alex Remily 
> > wrote:
> > > > >
> > > > > I'll see if I have any time this weekend, but this part is largely
> > > > > unfamiliar to me, so not sure how far I'll get even if I have the
> > time
> > > > > to look at it.
> > > > >
> > > > > On Tue, Jun 30, 2020 at 4:59 PM Geoffrey Blake
> > > > >  wrote:
> > > > > >
> > > > > > I think you're right Alex.  I just happened to look at the
> Makefile
> > > > > > and saw this above the win64 target:
> > > > > >
> > > > > > # for cross-compilation on Ubuntu, install the
> g++-mingw-w64-x86-64
> > > > package
> > > > > >
> > > > > > We could potentially build everything but MacOS on 1 Ubuntu
> > 16.04LTS
> > > > > > box.  Or even a 14.04 box if necessary.  Anybody have the time to
> > try?
> > > > > >
> > > > > > On Thu, Jun 25, 2020 at 4:12 PM Alex Remily <
> alex.rem...@gmail.com
> > >
> > > > wrote:
> > > > > > >
> > > > > > > Not sure if it's relevant or not, but to get the build to
> > compile on
> > > > > > > Windows with MinGW, I commented out line 137 of
> > > > > > >
> > > >
> >
> https://github.com/apache/commons-crypto/blob/master/src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h
> > > > :
> > > > > > >
> > > > > > > //#define inline __inline;
> > > > > > >
> > > > > > > I never did learn why it was there in the first place, but the
> > broken
> > > > > > > build

[crypto] Release Build Requirements

[Alex Remily]

Gary,

I compiled the 64-bit Windows build on my Mac and tested it in a
Windows VM.  It was fairly straightforward with mingw.  I still need
to cross-compile the Linux builds, but I'm cautiously optimistic that
they will be trivial compared to the Windows cross compilation.
Everything is easier on Linux.  Where do we go from here in terms of
getting a release out?  I see a couple of paths forward.  One, I could
work with you to get the build out on your machine; or, two, you could
work with me to get the build out on my machine.  I'm new to this
process, so defer to your judgement without recommendation.

Alex

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

Re: [all] Thoughts on build system maven -> gradle??

[Alex Remily]

For those of us not as familiar with Gradle, what are some of the
benefits?  Drawbacks?

On Thu, Jul 16, 2020 at 5:30 PM Rob Tompkins  wrote:
>
> I think we might be coming towards time to make this move or at least 
> accommodate for gradle builds in commons. Let’s look to the success the 
> Spring Framework has had here with gradle. That said, I’m merely trying to 
> gauge opinions here and am entirely content to stay with maven, if that’s 
> what the community wishes.
>
> I’m a +1 on at least letting gradle be a part of our systems (don’t have to 
> get rid of maven either).
>
> Cheers,
> -Rob
> -
> 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] New Release

[Alex Remily]

I'll see if I have any time this weekend, but this part is largely
unfamiliar to me, so not sure how far I'll get even if I have the time
to look at it.

On Tue, Jun 30, 2020 at 4:59 PM Geoffrey Blake
 wrote:
>
> I think you're right Alex.  I just happened to look at the Makefile
> and saw this above the win64 target:
>
> # for cross-compilation on Ubuntu, install the g++-mingw-w64-x86-64 package
>
> We could potentially build everything but MacOS on 1 Ubuntu 16.04LTS
> box.  Or even a 14.04 box if necessary.  Anybody have the time to try?
>
> On Thu, Jun 25, 2020 at 4:12 PM Alex Remily  wrote:
> >
> > Not sure if it's relevant or not, but to get the build to compile on
> > Windows with MinGW, I commented out line 137 of
> > https://github.com/apache/commons-crypto/blob/master/src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h:
> >
> > //#define inline __inline;
> >
> > I never did learn why it was there in the first place, but the broken
> > build was originally reported as
> >
> > https://issues.apache.org/jira/browse/CRYPTO-137.
> >
> > Now I'm wondering if it may have had something to do with
> > cross-compiling for the build.
> >
> > On Thu, Jun 25, 2020 at 1:13 PM Geoffrey Blake
> >  wrote:
> > >
> > > Is there anything needed to help move this release along?  From the
> > > looks of the Makefile, Windows was using GCC.  I don't think the
> > > compiler is going to have much of an impact since the JNI bindings are
> > > simply calling through to the OpenSSL library that is already
> > > precompiled for the environment.
> > >
> > > On Sat, Jun 13, 2020 at 6:14 PM Xeno Amess  wrote:
> > > >
> > > > I have a feeling about both mingw or cygwin build output will be slower
> > > > than microsoft-visual-studio build output...
> > > > Just a feeling, but no evidence.
> > > >
> > > > Alex Remily  于2020年6月14日周日 上午7:02写道：
> > > >
> > > > > I used MinGW64.  It does indeed ship with make.  I can provide a link
> > > > > to the distribution I used if there's interest.
> > > > >
> > > > > On Sat, Jun 13, 2020 at 6:26 PM Marcelo Vanzin  
> > > > > wrote:
> > > > > >
> > > > > > Pretty sure I remember comments in the code about building with 
> > > > > > mingw
> > > > > > on Windows (not cygwin). That should have a version of make, too,
> > > > > > IIRC.
> > > > > >
> > > > > > On Sat, Jun 13, 2020 at 3:11 PM Gary Gregory 
> > > > > > 
> > > > > wrote:
> > > > > > >
> > > > > > > Except that you can't build on plain Windows because the build 
> > > > > > > uses
> > > > > make
> > > > > > > and Microsoft version is called nmake. I might have to cobble up 
> > > > > > > some
> > > > > > > cygwin thing...
> > > > > > >
> > > > > > > Gary
> > > > > > >
> > > > > > > On Sat, Jun 13, 2020, 18:02 Alex Remily  
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I can't speak to how the original developers did the build, but 
> > > > > > > > all
> > > > > > > > the Windows builds that I did were on a Windows machine.  I 
> > > > > > > > always
> > > > > > > > assumed that the original developers just manually packed the 
> > > > > > > > release
> > > > > > > > jar with artifacts from each supported environment.  I never 
> > > > > > > > did any
> > > > > > > > investigation into the process.  Is cobbling together a release 
> > > > > > > > in
> > > > > > > > that manner really a non-starter here?
> > > > > > > >
> > > > > > > > Alex
> > > > > > > >
> > > > > > > > On Sat, Jun 13, 2020 at 5:44 PM Gary Gregory 
> > > > > > > >  > > > > >
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi Matt:
> > > > > > > > >
> > > > > > > > > > I have:
> > >

Re: [crypto] New Release

[Alex Remily]

Not sure if it's relevant or not, but to get the build to compile on
Windows with MinGW, I commented out line 137 of
https://github.com/apache/commons-crypto/blob/master/src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h:

//#define inline __inline;

I never did learn why it was there in the first place, but the broken
build was originally reported as

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

Now I'm wondering if it may have had something to do with
cross-compiling for the build.

On Thu, Jun 25, 2020 at 1:13 PM Geoffrey Blake
 wrote:
>
> Is there anything needed to help move this release along?  From the
> looks of the Makefile, Windows was using GCC.  I don't think the
> compiler is going to have much of an impact since the JNI bindings are
> simply calling through to the OpenSSL library that is already
> precompiled for the environment.
>
> On Sat, Jun 13, 2020 at 6:14 PM Xeno Amess  wrote:
> >
> > I have a feeling about both mingw or cygwin build output will be slower
> > than microsoft-visual-studio build output...
> > Just a feeling, but no evidence.
> >
> > Alex Remily  于2020年6月14日周日 上午7:02写道：
> >
> > > I used MinGW64.  It does indeed ship with make.  I can provide a link
> > > to the distribution I used if there's interest.
> > >
> > > On Sat, Jun 13, 2020 at 6:26 PM Marcelo Vanzin  wrote:
> > > >
> > > > Pretty sure I remember comments in the code about building with mingw
> > > > on Windows (not cygwin). That should have a version of make, too,
> > > > IIRC.
> > > >
> > > > On Sat, Jun 13, 2020 at 3:11 PM Gary Gregory 
> > > wrote:
> > > > >
> > > > > Except that you can't build on plain Windows because the build uses
> > > make
> > > > > and Microsoft version is called nmake. I might have to cobble up some
> > > > > cygwin thing...
> > > > >
> > > > > Gary
> > > > >
> > > > > On Sat, Jun 13, 2020, 18:02 Alex Remily  wrote:
> > > > >
> > > > > > I can't speak to how the original developers did the build, but all
> > > > > > the Windows builds that I did were on a Windows machine.  I always
> > > > > > assumed that the original developers just manually packed the 
> > > > > > release
> > > > > > jar with artifacts from each supported environment.  I never did any
> > > > > > investigation into the process.  Is cobbling together a release in
> > > > > > that manner really a non-starter here?
> > > > > >
> > > > > > Alex
> > > > > >
> > > > > > On Sat, Jun 13, 2020 at 5:44 PM Gary Gregory  > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > Hi Matt:
> > > > > > >
> > > > > > > > I have:
> > > > > > > >
> > > > > > > > /mnt/c/git/commons-crypto# find /usr -name windows.h
> > > > > > > > /usr/i686-w64-mingw32/include/windows.h
> > > > > > > > /usr/share/mingw-w64/include/windows.h
> > > > > > > > /usr/x86_64-w64-mingw32/include/windows.h
> > > > > > > >
> > > > > > > > Case matters here, so I wonder if the original others did not
> > > cross
> > > > > > > compile
> > > > > > > > from Linux and instead built a little here, a little there, and
> > > so on.
> > > > > > > >
> > > > > > > > I can see "-Ilib/inc_win" in the build but I am not sure where
> > > that is
> > > > > > > > supposed to be...
> > > > > > >
> > > > > > > Gary
> > > > > > >
> > > > > > > On Sat, Jun 13, 2020, 15:41 Matt Sicker  wrote:
> > > > > > >
> > > > > > > > Are the Windows headers even available when using Ming32 or
> > > Cygwin?
> > > > > > > > That sounds more like a Visual Studio compiler thing.
> > > > > > > >
> > > > > > > > On Sat, 13 Jun 2020 at 09:29, Gary Gregory <
> > > garydgreg...@gmail.com>
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > > The challenge is getting everything set up just right for
> > > building
> > > > >

Re: [crypto] New Release

[Alex Remily]

I used MinGW64.  It does indeed ship with make.  I can provide a link
to the distribution I used if there's interest.

On Sat, Jun 13, 2020 at 6:26 PM Marcelo Vanzin  wrote:
>
> Pretty sure I remember comments in the code about building with mingw
> on Windows (not cygwin). That should have a version of make, too,
> IIRC.
>
> On Sat, Jun 13, 2020 at 3:11 PM Gary Gregory  wrote:
> >
> > Except that you can't build on plain Windows because the build uses make
> > and Microsoft version is called nmake. I might have to cobble up some
> > cygwin thing...
> >
> > Gary
> >
> > On Sat, Jun 13, 2020, 18:02 Alex Remily  wrote:
> >
> > > I can't speak to how the original developers did the build, but all
> > > the Windows builds that I did were on a Windows machine.  I always
> > > assumed that the original developers just manually packed the release
> > > jar with artifacts from each supported environment.  I never did any
> > > investigation into the process.  Is cobbling together a release in
> > > that manner really a non-starter here?
> > >
> > > Alex
> > >
> > > On Sat, Jun 13, 2020 at 5:44 PM Gary Gregory 
> > > wrote:
> > > >
> > > > Hi Matt:
> > > >
> > > > > I have:
> > > > >
> > > > > /mnt/c/git/commons-crypto# find /usr -name windows.h
> > > > > /usr/i686-w64-mingw32/include/windows.h
> > > > > /usr/share/mingw-w64/include/windows.h
> > > > > /usr/x86_64-w64-mingw32/include/windows.h
> > > > >
> > > > > Case matters here, so I wonder if the original others did not cross
> > > > compile
> > > > > from Linux and instead built a little here, a little there, and so on.
> > > > >
> > > > > I can see "-Ilib/inc_win" in the build but I am not sure where that is
> > > > > supposed to be...
> > > >
> > > > Gary
> > > >
> > > > On Sat, Jun 13, 2020, 15:41 Matt Sicker  wrote:
> > > >
> > > > > Are the Windows headers even available when using Ming32 or Cygwin?
> > > > > That sounds more like a Visual Studio compiler thing.
> > > > >
> > > > > On Sat, 13 Jun 2020 at 09:29, Gary Gregory 
> > > wrote:
> > > > > >
> > > > > > The challenge is getting everything set up just right for building
> > > the
> > > > > > various OS profiles. This component is quite different in this
> > > regard,
> > > > > > getting help from the original contributors would be helpful.
> > > > > >
> > > > > > After much fiddling to install the proper packages, this builds OK:
> > > > > >
> > > > > > mvn package -DskipTests -P linux64
> > > > > > mvn package -DskipTests -P linux32
> > > > > >
> > > > > > But these do not:
> > > > > > mvn package -DskipTests -P win64
> > > > > > mvn package -DskipTests -P win32
> > > > > >
> > > > > > due to:
> > > > > >
> > > > > > [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto ---
> > > > > > [INFO] Executing tasks
> > > > > >
> > > > > > make:
> > > > > >  [exec] make native CROSS_PREFIX=x86_64-w64-mingw32-
> > > OS_NAME=Windows
> > > > > > OS_ARCH=x86_64
> > > > > >  [exec] make[1]: Entering directory '/mnt/c/git/commons-crypto'
> > > > > >  [exec] x86_64-w64-mingw32-gcc
> > > > > > -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include" -I"/include"
> > > > > > -Ilib/inc_win -O2 -fno-inline -Ilib/include -I/usr/include
> > > > > > -I"src/main/native/org/apache/commons/crypto/"
> > > > > > -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include/linux"
> > > > > > -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-crypt

Re: [crypto] New Release

[Alex Remily]

ptoRandomNative.c
> > > -o
> > >
> > target/commons-crypto-1.1.0-SNAPSHOT-Linux-arm/OpenSslCryptoRandomNative.o
> > >  [exec] Makefile:54: recipe for target
> > >
> > 'target/commons-crypto-1.1.0-SNAPSHOT-Linux-arm/OpenSslCryptoRandomNative.o'
> > > failed
> > >  [exec] make[1]: Leaving directory '/mnt/c/git/commons-crypto'
> > >  [exec] Makefile:101: recipe for target 'linux-arm' failed
> > >  [exec] cc1: fatal error: lib/inc_linux/jni_md.h: No such file or
> > > directory
> > >  [exec] compilation terminated.
> > >  [exec] make[1]: ***
> > >
> > [target/commons-crypto-1.1.0-SNAPSHOT-Linux-arm/OpenSslCryptoRandomNative.o]
> > > Error 1
> > >  [exec] make: *** [linux-arm] Error 2
> > > [INFO]
> > > 
> > > [INFO] BUILD FAILURE
> > > [INFO]
> > > 
> > > [INFO] Total time:  10.906 s
> > > [INFO] Finished at: 2020-06-13T14:13:37Z
> > > [INFO]
> > > 
> > > [ERROR] Failed to execute goal
> > > org.apache.maven.plugins:maven-antrun-plugin:1.8:run (make) on project
> > > commons-crypto: An Ant BuildException has occured: exec returned: 2
> > > [ERROR] around Ant part ... > > dir="/mnt/c/git/commons-crypto" executable="make">... @ 5:78 in
> > > /mnt/c/git/commons-crypto/target/antrun/build-make.xml
> > >
> > > Same kind of issue with the linux-armhf profile:
> > >
> > > [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto ---
> > > [INFO] Executing tasks
> > >
> > > make:
> > >  [exec] make native CROSS_PREFIX=arm-linux-gnueabihf- OS_NAME=Linux
> > > OS_ARCH=armhf
> > >  [exec] make[1]: Entering directory '/mnt/c/git/commons-crypto'
> > >  [exec] arm-linux-gnueabihf-gcc -include lib/inc_linux/jni_md.h
> > > -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include" -O2 -fPIC
> > > -fvisibility=hidden -mfloat-abi=hard -Ilib/include -I/usr/include
> > > -I"src/main/native/org/apache/commons/crypto/"
> > > -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include/linux"
> > > -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-SNAPSHOT-Linux-armhf/OpenSslCryptoRandomNative.o
> > >  [exec] Makefile:54: recipe for target
> > >
> > 'target/commons-crypto-1.1.0-SNAPSHOT-Linux-armhf/OpenSslCryptoRandomNative.o'
> > > failed
> > >  [exec] make[1]: Leaving directory '/mnt/c/git/commons-crypto'
> > >  [exec] Makefile:105: recipe for target 'linux-armhf' failed
> > >  [exec] cc1: fatal error: lib/inc_linux/jni_md.h: No such file or
> > > directory
> > >  [exec] compilation terminated.
> > >  [exec] make[1]: ***
> > >
> > [target/commons-crypto-1.1.0-SNAPSHOT-Linux-armhf/OpenSslCryptoRandomNative.o]
> > > Error 1
> > >  [exec] make: *** [linux-armhf] Error 2
> > > [INFO]
> > > 
> > > [INFO] BUILD FAILURE
> > > [INFO]
> > > 
> > > [INFO] Total time:  10.400 s
> > > [INFO] Finished at: 2020-06-13T14:16:53Z
> > > [INFO]
> > > 
> > > [ERROR] Failed to execute goal
> > > org.apache.maven.plugins:maven-antrun-plugin:1.8:run (make) on project
> > > commons-crypto: An Ant BuildException has occured: exec returned: 2
> > > [ERROR] around Ant part ... > > dir="/mnt/c/git/commons-crypto" executable="make">... @ 5:78 in
> > > /mnt/c/git/commons-crypto/target/antrun/build-make.xml
> > >
> > > For the  linux-aarch64 profile, I need to install the proper package:
> > >
> > > [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto ---
> > > [INFO] Executing tasks
> > >
> > > make:
> > >  [exec] make native CROSS_PREFIX=aarch64-linux-gnu- OS_NAME=Linux
> > > OS_ARCH=aarch64
> 

[crypto] New Release

[Alex Remily]

Just checking in on the status of the 1.1 release.

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

Re: [crypto] Help Releasing new Commons Crypto

[Alex Remily]

So I did a little homework and JNA appears to be a first class citizen
in Commons Crypto.  One instantiates a JNA-backed CryptoCipher just as
one does JNI or JCE.  The OpenSslJna class is exposed for that
purpose.  I hacked together the below from some JNA test classes to
demonstrate and it runs successfully to completion as a stand alone
program.

I think we're back to asking the question of whether or not to support
LibreSSL.  I know that Commons Crypto fully supports OpenSSL on a Mac
because that is my primary development environment.  I also understand
the convenience argument and I know it's a PITA to install OpenSSL
manually on a Mac, especially a new one.  Nevertheless, this build is
already complex in large part because of the native interface, so
adding yet another native binary to the support list is going to
exacerbate the situation.  Maybe we put it on the roadmap as a future
enhancement and see how many votes it gets.

Thoughts?

Alex

public static void main(final String args[]) throws Exception {

final String cipherClass = OpenSslJna.getCipherClass().getName();
Properties props = new Properties();
props.setProperty(CryptoCipherFactory.CLASSES_KEY, cipherClass);
String transformation = "AES/CBC/NoPadding";
final byte[] key = DatatypeConverter
.parseHexBinary("2b7e151628aed2a6abf7158809cf4f3c");
final byte[] iv = DatatypeConverter
.parseHexBinary("000102030405060708090a0b0c0d0e0f");
final byte[] inputBytes = DatatypeConverter
.parseHexBinary("6bc1bee22e409f96e93d7e117393172a");
final byte[] outputBytes = DatatypeConverter
.parseHexBinary("7649abac8119b246cee98e9b12e9197d");

CryptoCipher enc = Utils.getCipherInstance(transformation, props);
enc.init(Cipher.ENCRYPT_MODE, new SecretKeySpec(key, "AES"),
new IvParameterSpec(iv));

CryptoCipher dec = Utils.getCipherInstance(transformation, props);
dec.init(Cipher.DECRYPT_MODE, new SecretKeySpec(key, "AES"),
new IvParameterSpec(iv));

final int blockSize = enc.getBlockSize();
byte[] temp = new byte[inputBytes.length + blockSize];
final int n = enc.doFinal(inputBytes, 0, inputBytes.length, temp, 0);
final byte[] cipherText = new byte[n];
System.arraycopy(temp, 0, cipherText, 0, n);
Assert.assertArrayEquals("byte array encryption error.", outputBytes,
cipherText);

temp = new byte[cipherText.length + blockSize];
final int m = dec.doFinal(cipherText, 0, cipherText.length, temp, 0);
final byte[] plainText = new byte[m];
System.arraycopy(temp, 0, plainText, 0, m);
Assert.assertArrayEquals("byte array decryption error.", inputBytes,
plainText);
}


On Mon, Apr 27, 2020 at 1:14 PM Geoffrey Blake
 wrote:
>
> JNA is the middle ground between JNI and JCE in terms of performance
> is my understanding without needing any .c files to create linkage.
> The problem appears to be that there is no conditional loading and
> stubbing of functions like can be done easily in the JNI code and is
> why macOS throws that error, LibreSSL lacks the rdrand() function.
> Perhaps it was included as a path to get rid of the native binaries
> that have to be built for JNI?  But wonder if the performance wasn't
> there, or the macOS failures prevented its full development?
>
> -Geoff
>
> On Mon, Apr 27, 2020 at 9:15 AM Adam Retter
>  wrote:
> >
> > > I think Geoff just answered this question for us.
> >
> > Yup he was quicker with his reply than me! Thanks :-)
> >
> >
> > --
> > Adam Retter
> >
> > skype: adam.retter
> > tweet: adamretter
> > http://www.adamretter.org.uk
> >
> > -
> > 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] Help Releasing new Commons Crypto

[Alex Remily]

My apologies.  It is only the JNA.  I wasn't paying attention and got
crossed with some errors I dealt with while troubleshooting another
issue.

** WARN: JNA could not be enabled: Error looking up function
'ENGINE_load_rdrand': dlsym(0x7f859c4b6db0, ENGINE_load_rdrand):
symbol not found.

I've never used JNA before, but I wonder why the original developers
would bother putting it in if it is unusable externally.

On Mon, Apr 27, 2020 at 9:41 AM Geoffrey Blake
 wrote:
>
> Hi Alex,
>
> Just a sanity check, are you sure it was the JNI failing to load or
> was it the JNA?  At least on my Mojave MacOS install, libreSSL is
> found and links fine with JNI.  JNA is the library that fails to load
> on macOS, but that is apparently ok as the JNA implementation is not
> used by anything user accessible.
>
> -Geoff
>
> On Mon, Apr 27, 2020 at 7:53 AM Alex Remily  wrote:
> >
> > Adam,
> >
> > Fair points.  I don't know if commons-crypto "officially" supports
> > LibreSSL, but now that I think about it, it may be a moot point.  As
> > long as LibreSSL complies with the OpenSSL 1.0 or 1.1 API, it *should*
> > run.  It did compile and build against LibreSSL on the Mac, and the
> > tests didn't fail--they were skipped because commons-crypto couldn't
> > find the native libraries for JNI.  I think the issue is probably an
> > environment variable or path that needs to be set so commons-crypto
> > can find the native binaries.  The tests may well pass if the native
> > library is present.  Even if they don't, at least we'd know.  Would
> > you be willing to troubleshoot that on Travis?  If so, I'd recommend
> > checking out the NativeCodeLoader class.
> >
> > Marcelo is more familiar with the application than I am, so maybe he
> > can give some pointers.
> >
> > @Marcelo - Any suggestions?
> >
> > Alex
> >
> >
> > Alex
> >
> > On Mon, Apr 27, 2020 at 7:10 AM Adam Retter
> >  wrote:
> > >
> > > Hi Alex,
> > >
> > > > Just submitted a PR to increase the coverage in the streams package.
> > > > While prepping the PR I noticed the Travis Mac build is testing
> > > > against LibreSSL
> > >
> > > I recently improved the Travis builds for a few platforms, however
> > > libressl on Mac OS has been the case since before I was involved.
> > > Looking back through the Git history it looks like it has been this
> > > way since October 2018 -
> > > https://github.com/apache/commons-crypto/commit/c5c6220c2509c4d12de3fc08d591f82b89f882a0#diff-354f30a63fb0907d4ad57269548329e3
> > >
> > > Whilst it is possible with some manual work to install OpenSSL on
> > > MacOS, and I could make this happen in the Travis builds if you
> > > wish... this feels a bit unfriendly to users to me, as of course most
> > > Java users just add the Jar dependency and get going without a second
> > > thought ;-)
> > > So I just wanted to check some stuff with you first.
> > >
> > > The README.md does not make it very clear that OpenSSL is required on
> > > MacOS, it says:
> > >
> > > 4. JNI-based implementation to achieve comparable performance to the
> > > native C/C++ version based on OpenSsl.
> > > 5. Portable across various operating systems (currently only
> > > Linux/MacOSX/Windows); Apache Commons Crypto loads the library
> > > according to your machine environment (it checks system properties,
> > > os.name and os.arch).
> > > 6. Simple usage. Add the commons-crypto-(version).jar file to your 
> > > classpath.
> > >
> > > So I guess my question is - Does commons-crypto only support OpenSSL,
> > > and there is no plan to change that?. If so then I can make the
> > > changes on Travis for you, and I think we must improve the README.md
> > > so it is clear that Mac users have to manually install OpenSSL and
> > > override LibreSSL if they want to use the JNI part of Commons Crypto.
> > >
> > >
> > > Cheers Adam.
> > >
> > >
> > >
> > > --
> > > Adam Retter
> > >
> > > skype: adam.retter
> > > tweet: adamretter
> > > http://www.adamretter.org.uk
> > >
> > > -
> > > 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
>

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

Re: [crypto] Help Releasing new Commons Crypto

[Alex Remily]

Adam,

I think Geoff just answered this question for us.  I'll go back and
check the Travis logs to see which tests were actually skipped.  If
they were just the JNA tests then it's probably not much of a problem.

On Mon, Apr 27, 2020 at 9:44 AM Adam Retter
 wrote:
>
> Thanks Alex,
>
> I don't have a great deal of time available to look into this. If
> someone could assure me that this compiles, and all the tests run
> correctly on their MacOS with LibreSSL first, then I could then figure
> out the difference on Travis. I suspect it is a more general Mac issue
> than just Travis, as the Travis Mac environment is fairly standard.
>
> On Mon, 27 Apr 2020 at 14:53, Alex Remily  wrote:
> >
> > Adam,
> >
> > Fair points.  I don't know if commons-crypto "officially" supports
> > LibreSSL, but now that I think about it, it may be a moot point.  As
> > long as LibreSSL complies with the OpenSSL 1.0 or 1.1 API, it *should*
> > run.  It did compile and build against LibreSSL on the Mac, and the
> > tests didn't fail--they were skipped because commons-crypto couldn't
> > find the native libraries for JNI.  I think the issue is probably an
> > environment variable or path that needs to be set so commons-crypto
> > can find the native binaries.  The tests may well pass if the native
> > library is present.  Even if they don't, at least we'd know.  Would
> > you be willing to troubleshoot that on Travis?  If so, I'd recommend
> > checking out the NativeCodeLoader class.
> >
> > Marcelo is more familiar with the application than I am, so maybe he
> > can give some pointers.
> >
> > @Marcelo - Any suggestions?
> >
> > Alex
> >
> >
> > Alex
> >
> > On Mon, Apr 27, 2020 at 7:10 AM Adam Retter
> >  wrote:
> > >
> > > Hi Alex,
> > >
> > > > Just submitted a PR to increase the coverage in the streams package.
> > > > While prepping the PR I noticed the Travis Mac build is testing
> > > > against LibreSSL
> > >
> > > I recently improved the Travis builds for a few platforms, however
> > > libressl on Mac OS has been the case since before I was involved.
> > > Looking back through the Git history it looks like it has been this
> > > way since October 2018 -
> > > https://github.com/apache/commons-crypto/commit/c5c6220c2509c4d12de3fc08d591f82b89f882a0#diff-354f30a63fb0907d4ad57269548329e3
> > >
> > > Whilst it is possible with some manual work to install OpenSSL on
> > > MacOS, and I could make this happen in the Travis builds if you
> > > wish... this feels a bit unfriendly to users to me, as of course most
> > > Java users just add the Jar dependency and get going without a second
> > > thought ;-)
> > > So I just wanted to check some stuff with you first.
> > >
> > > The README.md does not make it very clear that OpenSSL is required on
> > > MacOS, it says:
> > >
> > > 4. JNI-based implementation to achieve comparable performance to the
> > > native C/C++ version based on OpenSsl.
> > > 5. Portable across various operating systems (currently only
> > > Linux/MacOSX/Windows); Apache Commons Crypto loads the library
> > > according to your machine environment (it checks system properties,
> > > os.name and os.arch).
> > > 6. Simple usage. Add the commons-crypto-(version).jar file to your 
> > > classpath.
> > >
> > > So I guess my question is - Does commons-crypto only support OpenSSL,
> > > and there is no plan to change that?. If so then I can make the
> > > changes on Travis for you, and I think we must improve the README.md
> > > so it is clear that Mac users have to manually install OpenSSL and
> > > override LibreSSL if they want to use the JNI part of Commons Crypto.
> > >
> > >
> > > Cheers Adam.
> > >
> > >
> > >
> > > --
> > > Adam Retter
> > >
> > > skype: adam.retter
> > > tweet: adamretter
> > > http://www.adamretter.org.uk
> > >
> > > -
> > > 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
> >
>
>
> --
> Adam Retter
>
> skype: adam.retter
> tweet: adamretter
> http://www.adamretter.org.uk
>
> -
> 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] Help Releasing new Commons Crypto

[Alex Remily]

I assumed it was JNI.  I'll have to go back and check.

On Mon, Apr 27, 2020 at 9:41 AM Geoffrey Blake
 wrote:
>
> Hi Alex,
>
> Just a sanity check, are you sure it was the JNI failing to load or
> was it the JNA?  At least on my Mojave MacOS install, libreSSL is
> found and links fine with JNI.  JNA is the library that fails to load
> on macOS, but that is apparently ok as the JNA implementation is not
> used by anything user accessible.
>
> -Geoff
>
> On Mon, Apr 27, 2020 at 7:53 AM Alex Remily  wrote:
> >
> > Adam,
> >
> > Fair points.  I don't know if commons-crypto "officially" supports
> > LibreSSL, but now that I think about it, it may be a moot point.  As
> > long as LibreSSL complies with the OpenSSL 1.0 or 1.1 API, it *should*
> > run.  It did compile and build against LibreSSL on the Mac, and the
> > tests didn't fail--they were skipped because commons-crypto couldn't
> > find the native libraries for JNI.  I think the issue is probably an
> > environment variable or path that needs to be set so commons-crypto
> > can find the native binaries.  The tests may well pass if the native
> > library is present.  Even if they don't, at least we'd know.  Would
> > you be willing to troubleshoot that on Travis?  If so, I'd recommend
> > checking out the NativeCodeLoader class.
> >
> > Marcelo is more familiar with the application than I am, so maybe he
> > can give some pointers.
> >
> > @Marcelo - Any suggestions?
> >
> > Alex
> >
> >
> > Alex
> >
> > On Mon, Apr 27, 2020 at 7:10 AM Adam Retter
> >  wrote:
> > >
> > > Hi Alex,
> > >
> > > > Just submitted a PR to increase the coverage in the streams package.
> > > > While prepping the PR I noticed the Travis Mac build is testing
> > > > against LibreSSL
> > >
> > > I recently improved the Travis builds for a few platforms, however
> > > libressl on Mac OS has been the case since before I was involved.
> > > Looking back through the Git history it looks like it has been this
> > > way since October 2018 -
> > > https://github.com/apache/commons-crypto/commit/c5c6220c2509c4d12de3fc08d591f82b89f882a0#diff-354f30a63fb0907d4ad57269548329e3
> > >
> > > Whilst it is possible with some manual work to install OpenSSL on
> > > MacOS, and I could make this happen in the Travis builds if you
> > > wish... this feels a bit unfriendly to users to me, as of course most
> > > Java users just add the Jar dependency and get going without a second
> > > thought ;-)
> > > So I just wanted to check some stuff with you first.
> > >
> > > The README.md does not make it very clear that OpenSSL is required on
> > > MacOS, it says:
> > >
> > > 4. JNI-based implementation to achieve comparable performance to the
> > > native C/C++ version based on OpenSsl.
> > > 5. Portable across various operating systems (currently only
> > > Linux/MacOSX/Windows); Apache Commons Crypto loads the library
> > > according to your machine environment (it checks system properties,
> > > os.name and os.arch).
> > > 6. Simple usage. Add the commons-crypto-(version).jar file to your 
> > > classpath.
> > >
> > > So I guess my question is - Does commons-crypto only support OpenSSL,
> > > and there is no plan to change that?. If so then I can make the
> > > changes on Travis for you, and I think we must improve the README.md
> > > so it is clear that Mac users have to manually install OpenSSL and
> > > override LibreSSL if they want to use the JNI part of Commons Crypto.
> > >
> > >
> > > Cheers Adam.
> > >
> > >
> > >
> > > --
> > > Adam Retter
> > >
> > > skype: adam.retter
> > > tweet: adamretter
> > > http://www.adamretter.org.uk
> > >
> > > -
> > > 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
>

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

Re: [crypto] Help Releasing new Commons Crypto

[Alex Remily]

Adam,

Fair points.  I don't know if commons-crypto "officially" supports
LibreSSL, but now that I think about it, it may be a moot point.  As
long as LibreSSL complies with the OpenSSL 1.0 or 1.1 API, it *should*
run.  It did compile and build against LibreSSL on the Mac, and the
tests didn't fail--they were skipped because commons-crypto couldn't
find the native libraries for JNI.  I think the issue is probably an
environment variable or path that needs to be set so commons-crypto
can find the native binaries.  The tests may well pass if the native
library is present.  Even if they don't, at least we'd know.  Would
you be willing to troubleshoot that on Travis?  If so, I'd recommend
checking out the NativeCodeLoader class.

Marcelo is more familiar with the application than I am, so maybe he
can give some pointers.

@Marcelo - Any suggestions?

Alex


Alex

On Mon, Apr 27, 2020 at 7:10 AM Adam Retter
 wrote:
>
> Hi Alex,
>
> > Just submitted a PR to increase the coverage in the streams package.
> > While prepping the PR I noticed the Travis Mac build is testing
> > against LibreSSL
>
> I recently improved the Travis builds for a few platforms, however
> libressl on Mac OS has been the case since before I was involved.
> Looking back through the Git history it looks like it has been this
> way since October 2018 -
> https://github.com/apache/commons-crypto/commit/c5c6220c2509c4d12de3fc08d591f82b89f882a0#diff-354f30a63fb0907d4ad57269548329e3
>
> Whilst it is possible with some manual work to install OpenSSL on
> MacOS, and I could make this happen in the Travis builds if you
> wish... this feels a bit unfriendly to users to me, as of course most
> Java users just add the Jar dependency and get going without a second
> thought ;-)
> So I just wanted to check some stuff with you first.
>
> The README.md does not make it very clear that OpenSSL is required on
> MacOS, it says:
>
> 4. JNI-based implementation to achieve comparable performance to the
> native C/C++ version based on OpenSsl.
> 5. Portable across various operating systems (currently only
> Linux/MacOSX/Windows); Apache Commons Crypto loads the library
> according to your machine environment (it checks system properties,
> os.name and os.arch).
> 6. Simple usage. Add the commons-crypto-(version).jar file to your classpath.
>
> So I guess my question is - Does commons-crypto only support OpenSSL,
> and there is no plan to change that?. If so then I can make the
> changes on Travis for you, and I think we must improve the README.md
> so it is clear that Mac users have to manually install OpenSSL and
> override LibreSSL if they want to use the JNI part of Commons Crypto.
>
>
> Cheers Adam.
>
>
>
> --
> Adam Retter
>
> skype: adam.retter
> tweet: adamretter
> http://www.adamretter.org.uk
>
> -
> 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] Help Releasing new Commons Crypto

[Alex Remily]

Just submitted a PR to increase the coverage in the streams package.
While prepping the PR I noticed the Travis Mac build is testing
against LibreSSL, which doesn't successfully load the native libraries
to support JNI:

[WARNING] Tests run: 139, Failures: 0, Errors: 0, Skipped: 42

Note the 42 tests that are skipped.  40 of these tests are skipped
because commons-crypto couldn't find the native library to run the JNI
test.  If possible, I'd recommend configuring the Travis Mac build
with OpenSSL proper, not LibreSSL.  I'd prefer not to support any
derivative distribution.





On Fri, Apr 24, 2020 at 12:16 PM Geoffrey Blake
 wrote:
>
> I figure everyone is a bit busy, but wanted to ask where we are all in
> getting close to a new release of commons-crypto that contains the new
> binaries, Alex, Gary?  Any other unit test areas that need attention
> Alex that you may need help with?
>
> -Geoff
>
> On Wed, Apr 22, 2020 at 11:33 AM Adam Retter
>  wrote:
> >
> > If you want to build on CentOS for releases that is fine - I can add
> > Docker Build Environments as a Travis job that use older CentOS.
> >
> > On Wed, 22 Apr 2020 at 18:02, Geoffrey Blake  
> > wrote:
> > >
> > > I think it depends on whether using Ubuntu 14.04/16.04 as the base
> > > distro for releases is ok.  It seems most projects like to build on
> > > some variant of RHEL/CentOS as they typically use stable (read older)
> > > compilers and libc.
> > >
> > > Does Travis allow building all the binaries then having a final
> > > process that gathers all the artifacts up in the end to perform the
> > > release?
> > >
> > > @garydgregory, thoughts on this?
> > >
> > > On Wed, Apr 22, 2020 at 3:39 AM Adam Retter
> > >  wrote:
> > > >
> > > > No that https://github.com/apache/commons-crypto/pull/96 has been
> > > > merged, we have support for Arm64, ppc64le and x64 in Travis.
> > > >
> > > > I wondered if it was useful for the "Release Process" if we had Travis
> > > > build and store release artifacts? I believe we can have Travis do
> > > > this only when Git tags are created. So if there is a Tag for each
> > > > release (which I assume there is) - then you could have the release
> > > > binaries built and delivered automatically for you. It is possible to
> > > > go as far as having them uploaded to Maven Central (staging) if you
> > > > wished.
> > > >
> > > > On Sat, 18 Apr 2020 at 17:40, Adam Retter  
> > > > wrote:
> > > > >
> > > > > As promised, I added support for further environments to Travis -
> > > > > https://github.com/apache/commons-crypto/pull/96
> > > > >
> > > > > On Mon, 13 Apr 2020 at 16:35, Alex Remily  
> > > > > wrote:
> > > > > >
> > > > > > I don't know whether it would help the build manager with the 
> > > > > > release
> > > > > > process, but I think it would be a good idea to update the build 
> > > > > > matrix
> > > > > > regardless.  I made an attempt a while ago to add coverage for more
> > > > > > environments, but ultimately I wasn't successful.  I don't recall 
> > > > > > if the
> > > > > > limitations were Travis's or my own, but I would certainly welcome 
> > > > > > someone
> > > > > > fleshing out the build matrix to test against OpenSSL 1.0 and 1.1 
> > > > > > APIs in
> > > > > > whatever Windows, Mac, Linux and Arm64 environments Travis 
> > > > > > supports.  My
> > > > > > $0.02.
> > > > > >
> > > > > > Alex
> > > > > >
> > > > > > On Mon, Apr 13, 2020 at 2:53 AM Adam Retter
> > > > > >  wrote:
> > > > > >
> > > > > > > Travis now offer Arm64 and Mac. I could setup a job to build 
> > > > > > > binaries on
> > > > > > > Travis and keep a copy either on every commit or when a tag is 
> > > > > > > created.
> > > > > > > Would that be helpful?
> > > > > > >
> > > > > > > On Mon, 13 Apr 2020, 03:13 Gary Gregory,  
> > > > > > > wrote:
> > > > > > >
> > > > > > > > On Sun, Apr 12, 2020 at 8:57 PM Alex Remily 
> > > > &

Re: [crypto] Help Releasing new Commons Crypto

[Alex Remily]

I hope to have a PR in this weekend sometime with an increase in code
coverage for streams.  I haven't touched anything else yet, so any other
package is fair game.

On Fri, Apr 24, 2020 at 12:16 PM Geoffrey Blake 
wrote:

> I figure everyone is a bit busy, but wanted to ask where we are all in
> getting close to a new release of commons-crypto that contains the new
> binaries, Alex, Gary?  Any other unit test areas that need attention
> Alex that you may need help with?
>
> -Geoff
>
> On Wed, Apr 22, 2020 at 11:33 AM Adam Retter
>  wrote:
> >
> > If you want to build on CentOS for releases that is fine - I can add
> > Docker Build Environments as a Travis job that use older CentOS.
> >
> > On Wed, 22 Apr 2020 at 18:02, Geoffrey Blake 
> wrote:
> > >
> > > I think it depends on whether using Ubuntu 14.04/16.04 as the base
> > > distro for releases is ok.  It seems most projects like to build on
> > > some variant of RHEL/CentOS as they typically use stable (read older)
> > > compilers and libc.
> > >
> > > Does Travis allow building all the binaries then having a final
> > > process that gathers all the artifacts up in the end to perform the
> > > release?
> > >
> > > @garydgregory, thoughts on this?
> > >
> > > On Wed, Apr 22, 2020 at 3:39 AM Adam Retter
> > >  wrote:
> > > >
> > > > No that https://github.com/apache/commons-crypto/pull/96 has been
> > > > merged, we have support for Arm64, ppc64le and x64 in Travis.
> > > >
> > > > I wondered if it was useful for the "Release Process" if we had
> Travis
> > > > build and store release artifacts? I believe we can have Travis do
> > > > this only when Git tags are created. So if there is a Tag for each
> > > > release (which I assume there is) - then you could have the release
> > > > binaries built and delivered automatically for you. It is possible to
> > > > go as far as having them uploaded to Maven Central (staging) if you
> > > > wished.
> > > >
> > > > On Sat, 18 Apr 2020 at 17:40, Adam Retter <
> adam.ret...@googlemail.com> wrote:
> > > > >
> > > > > As promised, I added support for further environments to Travis -
> > > > > https://github.com/apache/commons-crypto/pull/96
> > > > >
> > > > > On Mon, 13 Apr 2020 at 16:35, Alex Remily 
> wrote:
> > > > > >
> > > > > > I don't know whether it would help the build manager with the
> release
> > > > > > process, but I think it would be a good idea to update the build
> matrix
> > > > > > regardless.  I made an attempt a while ago to add coverage for
> more
> > > > > > environments, but ultimately I wasn't successful.  I don't
> recall if the
> > > > > > limitations were Travis's or my own, but I would certainly
> welcome someone
> > > > > > fleshing out the build matrix to test against OpenSSL 1.0 and
> 1.1 APIs in
> > > > > > whatever Windows, Mac, Linux and Arm64 environments Travis
> supports.  My
> > > > > > $0.02.
> > > > > >
> > > > > > Alex
> > > > > >
> > > > > > On Mon, Apr 13, 2020 at 2:53 AM Adam Retter
> > > > > >  wrote:
> > > > > >
> > > > > > > Travis now offer Arm64 and Mac. I could setup a job to build
> binaries on
> > > > > > > Travis and keep a copy either on every commit or when a tag is
> created.
> > > > > > > Would that be helpful?
> > > > > > >
> > > > > > > On Mon, 13 Apr 2020, 03:13 Gary Gregory, <
> garydgreg...@gmail.com> wrote:
> > > > > > >
> > > > > > > > On Sun, Apr 12, 2020 at 8:57 PM Alex Remily <
> alex.rem...@gmail.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > I can do the 64 bit builds on Mac, Linux and Windows, so
> I'm happy to
> > > > > > > > > provide whichever of those is required.  It seems that
> Geoff can do the
> > > > > > > > > arm64 build.  Do we even bother supporting 32 bit
> architectures at this
> > > > > > > > > point?
> > > > > > > > >
> > > > > > > >
> > > &g

Re: [crypto] Help Releasing new Commons Crypto

[Alex Remily]

Still plugging away on streams.  I bumped one class 15 to 20 points and I'm
on to the next class.  My initial impression is that there's good coverage
on the happy paths, but anything non-standard is less well covered.  The
biggest challenge so far has been to figure out what input to use to get to
the right branch and where to plug the new stuff into the existing test
structure.

On Mon, Apr 20, 2020 at 5:55 PM Geoffrey Blake 
wrote:

> I've gotten through the JNA code and Random code for increasing unit
> testing.  I've got some changes I'm readying to bump up coverage by a
> few percentage points, mainly along the lines of passing in invalid
> output and making sure nothing falls over.
>
> @Alex, any luck with the stream portion of the tests?
>
> One thing I have noticed is that the JNA code is effectively dead,
> nothing is exposed to a consumer of the commons-crypto library and the
> JNA support is partially implemented unlike JCE or JNI native codes.
> I filed a JIRA on this as it makes no sense for the code to be in here
> if the only real choice is JNI or JCE.
>
> - Geoff
>
> On Sun, Apr 19, 2020 at 9:57 AM Adam Retter
>  wrote:
> >
> > Adding OpenSSL 1.1.x for x64, arm64, and ppc64le, turned out to be
> > trivial so I just pushed it now in an additional commit to the same
> > PR.
> >
> > On Sun, 19 Apr 2020 at 15:19, Alex Remily  wrote:
> > >
> > > Makes sense to me, but I defer to Gary.  Thanks again for making the
> > > effort.
> > >
> > > On Sun, Apr 19, 2020 at 5:33 AM Adam Retter
> > >  wrote:
> > >
> > > > Presumably that should come as a separate PR which builds on this
> one?
> > > >
> > > > On Sun, 19 Apr 2020, 11:26 Adam Retter, 
> > > > wrote:
> > > >
> > > > > Shouldn't be too bad. Depends on what packages are prebuilt and
> available
> > > > > - I can take a look later
> > > > >
> > > > > On Sun, 19 Apr 2020, 04:43 Alex Remily, 
> wrote:
> > > > >
> > > > >> Thanks Adam.  Very much appreciated.  How much effort would it be
> to do
> > > > >> the
> > > > >> same for OpenSSL 1.1.x?
> > > > >>
> > > > >> On Sat, Apr 18, 2020 at 11:41 AM Adam Retter
> > > > >>  wrote:
> > > > >>
> > > > >> > As promised, I added support for further environments to Travis
> -
> > > > >> > https://github.com/apache/commons-crypto/pull/96
> > > > >> >
> > > > >> > On Mon, 13 Apr 2020 at 16:35, Alex Remily <
> alex.rem...@gmail.com>
> > > > >> wrote:
> > > > >> > >
> > > > >> > > I don't know whether it would help the build manager with the
> > > > release
> > > > >> > > process, but I think it would be a good idea to update the
> build
> > > > >> matrix
> > > > >> > > regardless.  I made an attempt a while ago to add coverage
> for more
> > > > >> > > environments, but ultimately I wasn't successful.  I don't
> recall if
> > > > >> the
> > > > >> > > limitations were Travis's or my own, but I would certainly
> welcome
> > > > >> > someone
> > > > >> > > fleshing out the build matrix to test against OpenSSL 1.0 and
> 1.1
> > > > >> APIs in
> > > > >> > > whatever Windows, Mac, Linux and Arm64 environments Travis
> supports.
> > > > >> My
> > > > >> > > $0.02.
> > > > >> > >
> > > > >> > > Alex
> > > > >> > >
> > > > >> > > On Mon, Apr 13, 2020 at 2:53 AM Adam Retter
> > > > >> > >  wrote:
> > > > >> > >
> > > > >> > > > Travis now offer Arm64 and Mac. I could setup a job to build
> > > > >> binaries
> > > > >> > on
> > > > >> > > > Travis and keep a copy either on every commit or when a tag
> is
> > > > >> created.
> > > > >> > > > Would that be helpful?
> > > > >> > > >
> > > > >> > > > On Mon, 13 Apr 2020, 03:13 Gary Gregory, <
> garydgreg...@gmail.com>
> > > > >> > wrote:
> > > > >> > > >
> > > > >> > > > > On Sun, Ap

Re: [crypto] Help Releasing new Commons Crypto

[Alex Remily]

Makes sense to me, but I defer to Gary.  Thanks again for making the
effort.

On Sun, Apr 19, 2020 at 5:33 AM Adam Retter
 wrote:

> Presumably that should come as a separate PR which builds on this one?
>
> On Sun, 19 Apr 2020, 11:26 Adam Retter, 
> wrote:
>
> > Shouldn't be too bad. Depends on what packages are prebuilt and available
> > - I can take a look later
> >
> > On Sun, 19 Apr 2020, 04:43 Alex Remily,  wrote:
> >
> >> Thanks Adam.  Very much appreciated.  How much effort would it be to do
> >> the
> >> same for OpenSSL 1.1.x?
> >>
> >> On Sat, Apr 18, 2020 at 11:41 AM Adam Retter
> >>  wrote:
> >>
> >> > As promised, I added support for further environments to Travis -
> >> > https://github.com/apache/commons-crypto/pull/96
> >> >
> >> > On Mon, 13 Apr 2020 at 16:35, Alex Remily 
> >> wrote:
> >> > >
> >> > > I don't know whether it would help the build manager with the
> release
> >> > > process, but I think it would be a good idea to update the build
> >> matrix
> >> > > regardless.  I made an attempt a while ago to add coverage for more
> >> > > environments, but ultimately I wasn't successful.  I don't recall if
> >> the
> >> > > limitations were Travis's or my own, but I would certainly welcome
> >> > someone
> >> > > fleshing out the build matrix to test against OpenSSL 1.0 and 1.1
> >> APIs in
> >> > > whatever Windows, Mac, Linux and Arm64 environments Travis supports.
> >> My
> >> > > $0.02.
> >> > >
> >> > > Alex
> >> > >
> >> > > On Mon, Apr 13, 2020 at 2:53 AM Adam Retter
> >> > >  wrote:
> >> > >
> >> > > > Travis now offer Arm64 and Mac. I could setup a job to build
> >> binaries
> >> > on
> >> > > > Travis and keep a copy either on every commit or when a tag is
> >> created.
> >> > > > Would that be helpful?
> >> > > >
> >> > > > On Mon, 13 Apr 2020, 03:13 Gary Gregory, 
> >> > wrote:
> >> > > >
> >> > > > > On Sun, Apr 12, 2020 at 8:57 PM Alex Remily <
> >> alex.rem...@gmail.com>
> >> > > > wrote:
> >> > > > >
> >> > > > > > I can do the 64 bit builds on Mac, Linux and Windows, so I'm
> >> happy
> >> > to
> >> > > > > > provide whichever of those is required.  It seems that Geoff
> can
> >> > do the
> >> > > > > > arm64 build.  Do we even bother supporting 32 bit
> architectures
> >> at
> >> > this
> >> > > > > > point?
> >> > > > > >
> >> > > > >
> >> > > > > Unfortunately, we cannot just pick up bits from folks here and
> >> > there. It
> >> > > > > all has to be buildable from Maven by the release manager in
> >> order to
> >> > > > > generate the file signatures properly.
> >> > > > >
> >> > > > > Based on what I see in the docs, it looks like this is buildable
> >> > using
> >> > > > > cross-compilation with MinGW on Windows. Not sure about the Mac
> >> stuff
> >> > > > yet.
> >> > > > >
> >> > > > > I'm not sure what the use-case is for 32-bit at this point.
> >> > > > >
> >> > > > > Gary
> >> > > > >
> >> > > > >
> >> > > > > > On Sun, Apr 12, 2020 at 7:36 PM Marcelo Vanzin <
> >> van...@apache.org>
> >> > > > > wrote:
> >> > > > > >
> >> > > > > > > Hi Gary,
> >> > > > > > >
> >> > > > > > > On Sun, Apr 12, 2020 at 8:53 AM Gary Gregory <
> >> > garydgreg...@gmail.com
> >> > > > >
> >> > > > > > > wrote:
> >> > > > > > > > > The 1.0 release on maven central only included linux32
> and
> >> > > > linux64
> >> > > > > > > native
> >> > > > > > > > > libs, even though the Makefile supports many more
> targets
> >> > > > > > > >

Re: [crypto] Help Releasing new Commons Crypto

[Alex Remily]

Thanks Adam.  Very much appreciated.  How much effort would it be to do the
same for OpenSSL 1.1.x?

On Sat, Apr 18, 2020 at 11:41 AM Adam Retter
 wrote:

> As promised, I added support for further environments to Travis -
> https://github.com/apache/commons-crypto/pull/96
>
> On Mon, 13 Apr 2020 at 16:35, Alex Remily  wrote:
> >
> > I don't know whether it would help the build manager with the release
> > process, but I think it would be a good idea to update the build matrix
> > regardless.  I made an attempt a while ago to add coverage for more
> > environments, but ultimately I wasn't successful.  I don't recall if the
> > limitations were Travis's or my own, but I would certainly welcome
> someone
> > fleshing out the build matrix to test against OpenSSL 1.0 and 1.1 APIs in
> > whatever Windows, Mac, Linux and Arm64 environments Travis supports.  My
> > $0.02.
> >
> > Alex
> >
> > On Mon, Apr 13, 2020 at 2:53 AM Adam Retter
> >  wrote:
> >
> > > Travis now offer Arm64 and Mac. I could setup a job to build binaries
> on
> > > Travis and keep a copy either on every commit or when a tag is created.
> > > Would that be helpful?
> > >
> > > On Mon, 13 Apr 2020, 03:13 Gary Gregory, 
> wrote:
> > >
> > > > On Sun, Apr 12, 2020 at 8:57 PM Alex Remily 
> > > wrote:
> > > >
> > > > > I can do the 64 bit builds on Mac, Linux and Windows, so I'm happy
> to
> > > > > provide whichever of those is required.  It seems that Geoff can
> do the
> > > > > arm64 build.  Do we even bother supporting 32 bit architectures at
> this
> > > > > point?
> > > > >
> > > >
> > > > Unfortunately, we cannot just pick up bits from folks here and
> there. It
> > > > all has to be buildable from Maven by the release manager in order to
> > > > generate the file signatures properly.
> > > >
> > > > Based on what I see in the docs, it looks like this is buildable
> using
> > > > cross-compilation with MinGW on Windows. Not sure about the Mac stuff
> > > yet.
> > > >
> > > > I'm not sure what the use-case is for 32-bit at this point.
> > > >
> > > > Gary
> > > >
> > > >
> > > > > On Sun, Apr 12, 2020 at 7:36 PM Marcelo Vanzin 
> > > > wrote:
> > > > >
> > > > > > Hi Gary,
> > > > > >
> > > > > > On Sun, Apr 12, 2020 at 8:53 AM Gary Gregory <
> garydgreg...@gmail.com
> > > >
> > > > > > wrote:
> > > > > > > > The 1.0 release on maven central only included linux32 and
> > > linux64
> > > > > > native
> > > > > > > > libs, even though the Makefile supports many more targets
> > > > > > > >
> > > > > > >
> > > > > > > Please see the snapshot builds which now include more:
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-crypto/1.1.0-SNAPSHOT
> > > > > >
> > > > > > Here's the native stuff in your snapshot jar:
> > > > > >
> > > > > > $ jar tf commons-crypto-1.1.0-20200411.124009-5.jar | grep
> > > > > > nativeorg/apache/commons/crypto/native/
> > > > > > org/apache/commons/crypto/native/Linux/
> > > > > > org/apache/commons/crypto/native/Linux/x86_64/
> > > > > >
> org/apache/commons/crypto/native/Linux/x86_64/libcommons-crypto.so
> > > > > >
> > > > > > Here's the 1.0 release:
> > > > > >
> > > > > > $ jar tf
> > > > > >
> > > > >
> > > >
> > >
> ~/.ivy2/cache/org.apache.commons/commons-crypto/jars/commons-crypto-1.0.0.jar
> > > > > > | grep native
> > > > > > org/apache/commons/crypto/native/
> > > > > > org/apache/commons/crypto/native/Linux/
> > > > > > org/apache/commons/crypto/native/Linux/x86/
> > > > > > org/apache/commons/crypto/native/Linux/x86_64/
> > > > > > org/apache/commons/crypto/native/Mac/
> > > > > > org/apache/commons/crypto/native/Mac/x86_64/
> > > > > > org/apache/commons/crypto/native/Windows/
> > > > > > o

Re: [crypto] Help Releasing new Commons Crypto

[Alex Remily]

I've seen the expected exception error, but rarely and I've never been able
to reproduce it.  I'm surprised it's come up on Travis because it's only
come up a few times for me in the hundreds of builds I've done.  Maybe we
log it as a bug just to document it, but like I said, I don't know how to
reproduce it for a fix.  I know I've seen it on a Mac, so it's not just an
Ubuntu issue.

Regarding the code coverage, Just a heads up that I've started working
through the org.apache.commons.crypto.stream package to hook in some tests
where I can.  Slow going, but I'm planning on just plugging away at it
until I've gone through all the packages and either added tests or decided
I won't or can't.  Let me know if you want to split the packages between
the two of us.

Alex

On Wed, Apr 15, 2020 at 5:46 PM Geoffrey Blake 
wrote:

> So, I built commons-crypto against SSL 1.0.2n on Ubuntu 18.04LTS and
> all the tests pass.  The code coverage bumps to 72%, I'm guessing if I
> did Mac we'd see the 73% coverage seen from Travis CI.
>
> @Gary, what should a reasonable coverage target be?  73% is not great,
> but not sure how much higher this can get with many code paths that
> may be unreachable from unit-testing from what I'm seeing (private
> constructors, private overridden methods that are not used, static
> classes etc).  There are some functions that can be added, but is it
> worth it right now for getting a new release?
>
> Still, I've seen this error pop up in Travis multiple times now for the
> repo:
>
> 3040[ERROR]
> testGcmTamperedData(org.apache.commons.crypto.cipher.GcmCipherTest)
>  Time elapsed: 0.019 s  <<< ERROR!
> 3041java.lang.Exception: Unexpected exception,
> expected but
> was
> 3042 at
> org.apache.commons.crypto.cipher.GcmCipherTest.testGcmTamperedData(GcmCipherTest.java:224)
>
> Is that an error in commons-crypto, or something up with the Travis CI
> env?  I haven't seen it on my dev environments.
>
> -Geoff
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [crypto] Help Releasing new Commons Crypto

[Alex Remily]

I don't know whether it would help the build manager with the release
process, but I think it would be a good idea to update the build matrix
regardless.  I made an attempt a while ago to add coverage for more
environments, but ultimately I wasn't successful.  I don't recall if the
limitations were Travis's or my own, but I would certainly welcome someone
fleshing out the build matrix to test against OpenSSL 1.0 and 1.1 APIs in
whatever Windows, Mac, Linux and Arm64 environments Travis supports.  My
$0.02.

Alex

On Mon, Apr 13, 2020 at 2:53 AM Adam Retter
 wrote:

> Travis now offer Arm64 and Mac. I could setup a job to build binaries on
> Travis and keep a copy either on every commit or when a tag is created.
> Would that be helpful?
>
> On Mon, 13 Apr 2020, 03:13 Gary Gregory,  wrote:
>
> > On Sun, Apr 12, 2020 at 8:57 PM Alex Remily 
> wrote:
> >
> > > I can do the 64 bit builds on Mac, Linux and Windows, so I'm happy to
> > > provide whichever of those is required.  It seems that Geoff can do the
> > > arm64 build.  Do we even bother supporting 32 bit architectures at this
> > > point?
> > >
> >
> > Unfortunately, we cannot just pick up bits from folks here and there. It
> > all has to be buildable from Maven by the release manager in order to
> > generate the file signatures properly.
> >
> > Based on what I see in the docs, it looks like this is buildable using
> > cross-compilation with MinGW on Windows. Not sure about the Mac stuff
> yet.
> >
> > I'm not sure what the use-case is for 32-bit at this point.
> >
> > Gary
> >
> >
> > > On Sun, Apr 12, 2020 at 7:36 PM Marcelo Vanzin 
> > wrote:
> > >
> > > > Hi Gary,
> > > >
> > > > On Sun, Apr 12, 2020 at 8:53 AM Gary Gregory  >
> > > > wrote:
> > > > > > The 1.0 release on maven central only included linux32 and
> linux64
> > > > native
> > > > > > libs, even though the Makefile supports many more targets
> > > > > >
> > > > >
> > > > > Please see the snapshot builds which now include more:
> > > > >
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-crypto/1.1.0-SNAPSHOT
> > > >
> > > > Here's the native stuff in your snapshot jar:
> > > >
> > > > $ jar tf commons-crypto-1.1.0-20200411.124009-5.jar | grep
> > > > nativeorg/apache/commons/crypto/native/
> > > > org/apache/commons/crypto/native/Linux/
> > > > org/apache/commons/crypto/native/Linux/x86_64/
> > > > org/apache/commons/crypto/native/Linux/x86_64/libcommons-crypto.so
> > > >
> > > > Here's the 1.0 release:
> > > >
> > > > $ jar tf
> > > >
> > >
> >
> ~/.ivy2/cache/org.apache.commons/commons-crypto/jars/commons-crypto-1.0.0.jar
> > > > | grep native
> > > > org/apache/commons/crypto/native/
> > > > org/apache/commons/crypto/native/Linux/
> > > > org/apache/commons/crypto/native/Linux/x86/
> > > > org/apache/commons/crypto/native/Linux/x86_64/
> > > > org/apache/commons/crypto/native/Mac/
> > > > org/apache/commons/crypto/native/Mac/x86_64/
> > > > org/apache/commons/crypto/native/Windows/
> > > > org/apache/commons/crypto/native/Windows/x86/
> > > > org/apache/commons/crypto/native/Windows/x86_64/
> > > > org/apache/commons/crypto/native/Linux/x86/libcommons-crypto.so
> > > > org/apache/commons/crypto/native/Linux/x86_64/libcommons-crypto.so
> > > > org/apache/commons/crypto/native/Mac/x86_64/libcommons-crypto.jnilib
> > > > org/apache/commons/crypto/native/Windows/x86/commons-crypto.dll
> > > > org/apache/commons/crypto/native/Windows/x86_64/commons-crypto.dll
> > > >
> > > > That's the only thing that worries me: finding someone who can build
> > > > all those extra native libraries. I tend to agree that linux64 is the
> > > > most important one, but it would be technically a regression from 1.0
> > > > to skip the others.
> > > >
> > > > That being said, if we can't solve that, I think it's better to
> > > > release something rather than nothing.
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >
> > > >
> > >
> >
>

Re: [crypto] Help Releasing new Commons Crypto

[Alex Remily]

I can do the 64 bit builds on Mac, Linux and Windows, so I'm happy to
provide whichever of those is required.  It seems that Geoff can do the
arm64 build.  Do we even bother supporting 32 bit architectures at this
point?

On Sun, Apr 12, 2020 at 7:36 PM Marcelo Vanzin  wrote:

> Hi Gary,
>
> On Sun, Apr 12, 2020 at 8:53 AM Gary Gregory 
> wrote:
> > > The 1.0 release on maven central only included linux32 and linux64
> native
> > > libs, even though the Makefile supports many more targets
> > >
> >
> > Please see the snapshot builds which now include more:
> >
> https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-crypto/1.1.0-SNAPSHOT
>
> Here's the native stuff in your snapshot jar:
>
> $ jar tf commons-crypto-1.1.0-20200411.124009-5.jar | grep
> nativeorg/apache/commons/crypto/native/
> org/apache/commons/crypto/native/Linux/
> org/apache/commons/crypto/native/Linux/x86_64/
> org/apache/commons/crypto/native/Linux/x86_64/libcommons-crypto.so
>
> Here's the 1.0 release:
>
> $ jar tf
> ~/.ivy2/cache/org.apache.commons/commons-crypto/jars/commons-crypto-1.0.0.jar
> | grep native
> org/apache/commons/crypto/native/
> org/apache/commons/crypto/native/Linux/
> org/apache/commons/crypto/native/Linux/x86/
> org/apache/commons/crypto/native/Linux/x86_64/
> org/apache/commons/crypto/native/Mac/
> org/apache/commons/crypto/native/Mac/x86_64/
> org/apache/commons/crypto/native/Windows/
> org/apache/commons/crypto/native/Windows/x86/
> org/apache/commons/crypto/native/Windows/x86_64/
> org/apache/commons/crypto/native/Linux/x86/libcommons-crypto.so
> org/apache/commons/crypto/native/Linux/x86_64/libcommons-crypto.so
> org/apache/commons/crypto/native/Mac/x86_64/libcommons-crypto.jnilib
> org/apache/commons/crypto/native/Windows/x86/commons-crypto.dll
> org/apache/commons/crypto/native/Windows/x86_64/commons-crypto.dll
>
> That's the only thing that worries me: finding someone who can build
> all those extra native libraries. I tend to agree that linux64 is the
> most important one, but it would be technically a regression from 1.0
> to skip the others.
>
> That being said, if we can't solve that, I think it's better to
> release something rather than nothing.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [crypto] Help Releasing new Commons Crypto

[Alex Remily]

I'll see if I can look at the code coverage this week.  Today is busy with
family stuff.  I can contribute an OS X build (High Sierra) if you're
looking for one.

Alex

On Sun, Apr 12, 2020 at 11:53 AM Gary Gregory 
wrote:

> On Sun, Apr 12, 2020 at 10:49 AM Geoffrey Blake <
> geoffrey.w.bl...@gmail.com>
> wrote:
>
> > Gary, Alex,
> >
> > Let me know what else needs doing.
>
>
> Hi All:
>
> See my previous email WRT code coverage using JaCoCo.
>
>
> > I can certainly help with building
> > artifacts, just need guidance on minimum distro and Java to use.
> >
>
> Thank you for the offer. I plan on doing the building and releasing, which
> will be all based on what the pom and makefiles provide as currently in git
> master.
>
>
> > The 1.0 release on maven central only included linux32 and linux64 native
> > libs, even though the Makefile supports many more targets
> >
>
> Please see the snapshot builds which now include more:
>
> https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-crypto/1.1.0-SNAPSHOT
>
> If you want more in there, you'll have to provide a PR.
>
> I am building on:
>
> Linux US-L-GG02 4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST
> 2014 x86_64 x86_64 x86_64 GNU/Linux
>
> Within Microsoft Windows [Version 10.0.16299.1747]
>
> With:
>
> gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
>
> GNU Make 4.1
> Built for x86_64-pc-linux-gnu
>
> g++ (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
>
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /mnt/c/Java/apache-maven-3.6.3
> Java version: 1.8.0_242, vendor: Private Build, runtime:
> /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-43-microsoft", arch: "amd64", family:
> "unix"
>
> Thanks!
> Gary
>
>
> >
> > -Geoff
> >
> > On Sun, Apr 12, 2020 at 9:17 AM Gary Gregory 
> > wrote:
> >
> > > On Sat, Apr 11, 2020 at 1:55 PM Alex Remily 
> > wrote:
> > >
> > > > This looks to be done.  I added a comment to the ticket with a link
> to
> > > the
> > > > commit.
> > > >
> > > >
> > > >
> > >
> >
> https://github.com/apache/commons-crypto/commit/3466943e4552474ab681d7852dbfa62c74d8e1ce
> > >
> > >
> > > Thanks Alex, I resolved the parent ticket and added it to changes.xml.
> > >
> > > When I run tests and look at code coverage JaCoCo report, it does not
> > look
> > > great IMO:
> > >
> > > mvn -V clean install site -P jacoco -P japicmp
> > >
> > > Then open the site in target/site
> > >
> > > Is there any chance you can improve on this?
> > >
> > > Thank you,
> > > Gary
> > >
> > >
> > >
> > > >
> > > > Alex
> > > >
> > > > On Sat, Apr 11, 2020 at 11:54 AM Gary Gregory <
> garydgreg...@gmail.com>
> > > > wrote:
> > > >
> > > > > On Sat, Apr 11, 2020 at 8:43 AM Gary Gregory <
> garydgreg...@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > On Fri, Apr 10, 2020 at 8:38 PM Marcelo Vanzin <
> van...@apache.org>
> > > > > wrote:
> > > > > >
> > > > > >> (-CCs)
> > > > > >>
> > > > > >> Hi Gary, thanks for volunteering to help. If needed I can try
> > > helping
> > > > > with
> > > > > >> the release process (e.g. uploading artifacts), but I don't
> really
> > > > have
> > > > > >> the
> > > > > >> ability to build anything but the linux64 native lib (maybe the
> > > > linux32
> > > > > >> one
> > > > > >> if I can find the right packages or docker image).
> > > > > >>
> > > > > >
> > > > > The ticket:
> > > > >
> > > > > https://issues.apache.org/jira/browse/CRYPTO-59
> > > > >
> > > > > refers to the incomplete subtask:
> > > > >
> > > > > https://issues.apache.org/jira/browse/CRYPTO-126
> > > > >
> > > > > May you complete this task with a PR on GitHub? If it is already
> > done,
> > > > then
> > > > > please update the ticket with what clas

Re: [crypto] Help Releasing new Commons Crypto

[Alex Remily]

This looks to be done.  I added a comment to the ticket with a link to the
commit.

https://github.com/apache/commons-crypto/commit/3466943e4552474ab681d7852dbfa62c74d8e1ce

Alex

On Sat, Apr 11, 2020 at 11:54 AM Gary Gregory 
wrote:

> On Sat, Apr 11, 2020 at 8:43 AM Gary Gregory 
> wrote:
>
> > On Fri, Apr 10, 2020 at 8:38 PM Marcelo Vanzin 
> wrote:
> >
> >> (-CCs)
> >>
> >> Hi Gary, thanks for volunteering to help. If needed I can try helping
> with
> >> the release process (e.g. uploading artifacts), but I don't really have
> >> the
> >> ability to build anything but the linux64 native lib (maybe the linux32
> >> one
> >> if I can find the right packages or docker image).
> >>
> >
> The ticket:
>
> https://issues.apache.org/jira/browse/CRYPTO-59
>
> refers to the incomplete subtask:
>
> https://issues.apache.org/jira/browse/CRYPTO-126
>
> May you complete this task with a PR on GitHub? If it is already done, then
> please update the ticket with what classes and methods perform the tests.
>
> Thank you,
> Gary
>
>
>
> >
> >> I looked at the 1.0 release and it seems to include linux32/64, win32/64
> >> and macos64.
> >
> >
> > You can review what is in git master or what I also pushed as a snapshot
> > build to
> >
> https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-crypto/1.1.0-SNAPSHOT
> >
> >
> >>
> >> src/changes/changes.xml probably needs some love too.
> >>
> >
> > Indeed, this file was not updated with each change. It needs updates. A
> PR
> > is welcome or a message here confirming that all JIRAs listed on
> > https://issues.apache.org/jira/projects/CRYPTO/versions/12335578 are
> > indeed in git master. Then I can update the changes.xml if no one
> submits a
> > PR.
> >
> > Gary
> >
> >
> >>
> >>
> >> On Fri, Apr 10, 2020 at 5:02 PM Gary Gregory 
> >> wrote:
> >>
> >> > I'll see what I can do over the weekend.
> >> >
> >> > Gary
> >> >
> >> >
> >> > On Thu, Apr 9, 2020 at 8:45 PM Alex Remily 
> >> wrote:
> >> >
> >> >> Commons Crypto Team,
> >> >>
> >> >> It's been four years since the last release of commons crypto.  There
> >> have
> >> >> been many updates to the repository since then, notably the
> >> integration of
> >> >> OpenSSL 1.1.1, and native arm64 support.  Geoff Blake (copied) and I
> >> have
> >> >> been advocating for a new release, and we need assistance from
> someone
> >> who
> >> >> knows the release process and has the necessary accesses.  If any of
> >> you
> >> >> are willing to assist with this effort, please come up on the apache
> >> >> commons dev list (also copied) and announce yourself.
> >> >>
> >> >> Looking forward to hearing from you.
> >> >>
> >> >> Alex
> >> >>
> >> >
> >>
> >
>

Re: [crypto] Help Releasing new Commons Crypto

[Alex Remily]

Gary,

I confirmed that all JIRAs listed on
https://issues.apache.org/jira/projects/CRYPTO/versions/12335578 are in git
 master.

Alex

On Sat, Apr 11, 2020 at 8:44 AM Gary Gregory  wrote:

> On Fri, Apr 10, 2020 at 8:38 PM Marcelo Vanzin  wrote:
>
> > (-CCs)
> >
> > Hi Gary, thanks for volunteering to help. If needed I can try helping
> with
> > the release process (e.g. uploading artifacts), but I don't really have
> the
> > ability to build anything but the linux64 native lib (maybe the linux32
> one
> > if I can find the right packages or docker image).
> >
> > I looked at the 1.0 release and it seems to include linux32/64, win32/64
> > and macos64.
> >
>
> You can review what is in git master or what I also pushed as a snapshot
> build to
>
> https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-crypto/1.1.0-SNAPSHOT
>
>
> >
> > src/changes/changes.xml probably needs some love too.
> >
>
> Indeed, this file was not updated with each change. It needs updates. A PR
> is welcome or a message here confirming that all JIRAs listed on
> https://issues.apache.org/jira/projects/CRYPTO/versions/12335578 are
> indeed in git master. Then I can update the changes.xml if no one submits a
> PR.
>
> Gary
>
>
> >
> >
> > On Fri, Apr 10, 2020 at 5:02 PM Gary Gregory 
> > wrote:
> >
> > > I'll see what I can do over the weekend.
> > >
> > > Gary
> > >
> > >
> > > On Thu, Apr 9, 2020 at 8:45 PM Alex Remily 
> > wrote:
> > >
> > >> Commons Crypto Team,
> > >>
> > >> It's been four years since the last release of commons crypto.  There
> > have
> > >> been many updates to the repository since then, notably the
> integration
> > of
> > >> OpenSSL 1.1.1, and native arm64 support.  Geoff Blake (copied) and I
> > have
> > >> been advocating for a new release, and we need assistance from someone
> > who
> > >> knows the release process and has the necessary accesses.  If any of
> you
> > >> are willing to assist with this effort, please come up on the apache
> > >> commons dev list (also copied) and announce yourself.
> > >>
> > >> Looking forward to hearing from you.
> > >>
> > >> Alex
> > >>
> > >
> >
>

Re: [crypto] Help Releasing new Commons Crypto

[Alex Remily]

Disregard.  I figured it out.

On Fri, Apr 10, 2020 at 9:17 PM Alex Remily  wrote:

> Gary,
>
> I don't have access to the page at the link.  Can you add me?
> Sorry, you can't view this page
> This page is only available to Jira Software users. If you think you
> should be a Jira Software user, you should ask your administrator to give
> you application access to Jira Software.
>
> On Fri, Apr 10, 2020 at 8:20 PM Gary Gregory 
> wrote:
>
>> On Fri, Apr 10, 2020 at 8:02 PM Gary Gregory 
>> wrote:
>>
>> > I'll see what I can do over the weekend.
>> >
>> > Gary
>> >
>>
>> Alex,
>>
>> Here is how you can help now:
>>
>> Please review the tickets for 1.1.0 here:
>> https://issues.apache.org/jira/projects/CRYPTO/versions/12335578
>>
>> These are all marked as resolved. Can you confirm that these indeed all
>> are?
>>
>> TY,
>> Gary
>>
>>
>> >
>> > On Thu, Apr 9, 2020 at 8:45 PM Alex Remily 
>> wrote:
>> >
>> >> Commons Crypto Team,
>> >>
>> >> It's been four years since the last release of commons crypto.  There
>> have
>> >> been many updates to the repository since then, notably the
>> integration of
>> >> OpenSSL 1.1.1, and native arm64 support.  Geoff Blake (copied) and I
>> have
>> >> been advocating for a new release, and we need assistance from someone
>> who
>> >> knows the release process and has the necessary accesses.  If any of
>> you
>> >> are willing to assist with this effort, please come up on the apache
>> >> commons dev list (also copied) and announce yourself.
>> >>
>> >> Looking forward to hearing from you.
>> >>
>> >> Alex
>> >>
>> >
>>
>

Re: [crypto] Help Releasing new Commons Crypto

[Alex Remily]

Gary,

I don't have access to the page at the link.  Can you add me?
Sorry, you can't view this page
This page is only available to Jira Software users. If you think you should
be a Jira Software user, you should ask your administrator to give you
application access to Jira Software.

On Fri, Apr 10, 2020 at 8:20 PM Gary Gregory  wrote:

> On Fri, Apr 10, 2020 at 8:02 PM Gary Gregory 
> wrote:
>
> > I'll see what I can do over the weekend.
> >
> > Gary
> >
>
> Alex,
>
> Here is how you can help now:
>
> Please review the tickets for 1.1.0 here:
> https://issues.apache.org/jira/projects/CRYPTO/versions/12335578
>
> These are all marked as resolved. Can you confirm that these indeed all
> are?
>
> TY,
> Gary
>
>
> >
> > On Thu, Apr 9, 2020 at 8:45 PM Alex Remily 
> wrote:
> >
> >> Commons Crypto Team,
> >>
> >> It's been four years since the last release of commons crypto.  There
> have
> >> been many updates to the repository since then, notably the integration
> of
> >> OpenSSL 1.1.1, and native arm64 support.  Geoff Blake (copied) and I
> have
> >> been advocating for a new release, and we need assistance from someone
> who
> >> knows the release process and has the necessary accesses.  If any of you
> >> are willing to assist with this effort, please come up on the apache
> >> commons dev list (also copied) and announce yourself.
> >>
> >> Looking forward to hearing from you.
> >>
> >> Alex
> >>
> >
>

[crypto] Help Releasing new Commons Crypto

[Alex Remily]

Commons Crypto Team,

It's been four years since the last release of commons crypto.  There have
been many updates to the repository since then, notably the integration of
OpenSSL 1.1.1, and native arm64 support.  Geoff Blake (copied) and I have
been advocating for a new release, and we need assistance from someone who
knows the release process and has the necessary accesses.  If any of you
are willing to assist with this effort, please come up on the apache
commons dev list (also copied) and announce yourself.

Looking forward to hearing from you.

Alex

Re: [crypto] Help getting new release of commons-crypto?

[Alex Remily]

Thanks for the links.  I'll do just that.

On Wed, Apr 8, 2020 at 7:46 PM Gilles Sadowski  wrote:

> Hi.
>
> 2020-04-09 1:15 UTC+02:00, Alex Remily :
> > I guess we're both in the same boat.
>
> Did you try and ping the people[1] (or their respective project[2])
> who contributed to that component?
>
> Regards,
> Gilles
>
> [1] http://commons.apache.org/proper/commons-crypto/team-list.html
> [2]
> https://gitbox.apache.org/repos/asf?p=commons-crypto.git;a=blob;f=PROPOSAL.html;h=6d3740dc4cc4c61c016d16cfd82020e38c17;hb=HEAD
>
> >>> [...]
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [crypto] Help getting new release of commons-crypto?

[Alex Remily]

I guess we're both in the same boat.

On Wed, Apr 8, 2020 at 5:48 PM Geoffrey Blake 
wrote:

> Marcelo Vanzin was the one to help get a patch I submitted pushed into
> commons-crypto for natively supported arm64 this past week.  He is
> still around but mentioned in my PR he is not aware of how to create
> the release and upload it.  I'm able to manually build the different
> bits of the release on the required platforms, but I certainly don't
> know what is needed in terms of credentials and process to make a new
> release of a commons* package.
>
> -Geoff
>
> On Tue, Apr 7, 2020 at 8:43 PM Alex Remily  wrote:
> >
> > I think most of the original developers have moved on.  I did some of the
> > recent updates surrounding 1.1.1 support, and Marcelo was a big help
> > throughout the process.  He established design goals, reviewed code,
> > provided tips, etc.  I haven't seen him around in a while though, and I'm
> > not sure that he's still active.  I've also asked about getting a new
> > release out, and I'm happy to work with someone who has commit
> permissions
> > to make it happen.  I've never done a release for apache commons, but I'm
> > sure I could figure it out if I was teamed with someone who had the
> proper
> > access and was pointed in the right direction.
> >
> > Alex
> >
> > On Tue, Apr 7, 2020 at 4:04 PM Geoffrey Blake <
> geoffrey.w.bl...@gmail.com>
> > wrote:
> >
> > > Hi all,
> > >
> > > I see its been 4 years since the last release of commons crypto to
> > > https://mvnrepository.com/artifact/org.apache.commons/commons-crypto.
> > > There has been many updates to the repository since then, notably the
> > > integration of OpenSSL 1.1.1, and native arm64 support.
> > >
> > > What are the blockers to make a new release of commons-crypto, say
> > > v1.1?  Is there a maintainer around that can help with getting a new
> > > release uploaded to Maven central?
> > >
> > > Thanks,
> > > Geoff Blake
> > >
> > > -
> > > 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] Help getting new release of commons-crypto?

[Alex Remily]

I think most of the original developers have moved on.  I did some of the
recent updates surrounding 1.1.1 support, and Marcelo was a big help
throughout the process.  He established design goals, reviewed code,
provided tips, etc.  I haven't seen him around in a while though, and I'm
not sure that he's still active.  I've also asked about getting a new
release out, and I'm happy to work with someone who has commit permissions
to make it happen.  I've never done a release for apache commons, but I'm
sure I could figure it out if I was teamed with someone who had the proper
access and was pointed in the right direction.

Alex

On Tue, Apr 7, 2020 at 4:04 PM Geoffrey Blake 
wrote:

> Hi all,
>
> I see its been 4 years since the last release of commons crypto to
> https://mvnrepository.com/artifact/org.apache.commons/commons-crypto.
> There has been many updates to the repository since then, notably the
> integration of OpenSSL 1.1.1, and native arm64 support.
>
> What are the blockers to make a new release of commons-crypto, say
> v1.1?  Is there a maintainer around that can help with getting a new
> release uploaded to Maven central?
>
> Thanks,
> Geoff Blake
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>