[crypto] Updated to Support OpenSSL 1.1.0i

[Alex Remily]

Commons Crypto Dev Team,

I modified a copy of the commons crypto codebase to support OpenSSL 1.1.0i
(this was before I saw JIRA CRYPTO-140 "adding suuport for openssl 1.1.0g
in common crypto"). It successfully runs mvn clean test on Mac OS X
10.13.6 and Ubuntu 18.04 with Java 8 and OpenSSL 1.1.0i. I was unable to
test on Windows, presumably because of CRYPTO-137 Error compiling on Win64
with Mingw. I did not preserve compatibility with previous versions of
OpenSSL because I don't need it for the project for which I'm using commons
crypto.

Is there is interest in maintaining separate branches for different
versions of OpenSSL or for incorporating some of my 1.1.0i-compatible code
into a master that supports multiple underlying OpenSSL versions? If so,
I'll fork the repo and send a pull request. I also need to incorporate
message digest functionality, so if there's interest in expanding that
functionality I'll be glad to share the end product.

Thoughts?

Alex

[Marcelo Vanzin]

Hi Alex,

There have been other attempts at this (e.g.
https://github.com/apache/commons-crypto/pull/90), and my main concern
with those is that they require different builds for OpenSSL 1.0 and
1.1. It seems your approach falls in that bucket, at least without
additional work.

The problem with that is that it becomes super annoying to consume
commons-crypto in other projects. Which maven coordinates do you use?
If you're building something like Spark, which is meant to be deployed
in a bunch of different places with potentially different OpenSSL
versions, how do you even do it?

So IMO any approach to this needs to support both OpenSSL versions in
the same commons-crypto jar file. That doesn't necessarily mean the
same underlying JNI library, although doing that would make creating a
binary releases easier (less build platforms to juggle).

Post by Alex Remily
Commons Crypto Dev Team,
I modified a copy of the commons crypto codebase to support OpenSSL 1.1.0i
(this was before I saw JIRA CRYPTO-140 "adding suuport for openssl 1.1.0g
in common crypto"). It successfully runs mvn clean test on Mac OS X
10.13.6 and Ubuntu 18.04 with Java 8 and OpenSSL 1.1.0i. I was unable to
test on Windows, presumably because of CRYPTO-137 Error compiling on Win64
with Mingw. I did not preserve compatibility with previous versions of
OpenSSL because I don't need it for the project for which I'm using commons
crypto.
Is there is interest in maintaining separate branches for different
versions of OpenSSL or for incorporating some of my 1.1.0i-compatible code
into a master that supports multiple underlying OpenSSL versions? If so,
I'll fork the repo and send a pull request. I also need to incorporate
message digest functionality, so if there's interest in expanding that
functionality I'll be glad to share the end product.
Thoughts?
Alex

[Alex Remily]

Marcelo,

Thanks for the note. When I started down this path, I was only concerned
with getting things working in my own environment, but after reading the
comments on the pull request at the link, I'm in complete agreement with
your goals here. I'll have to give it some thought, but at first glance I
don't think it would be too difficult to do a dynamic version lookup of
OpenSSL from which to instantiate the version-compatible commons-crypto
object. It appears that implementations for 1.0 and 1.1 are already
written, and the challenge is how to best merge them into one build.

Alex

Post by Marcelo Vanzin
Hi Alex,
There have been other attempts at this (e.g.
https://github.com/apache/commons-crypto/pull/90), and my main concern
with those is that they require different builds for OpenSSL 1.0 and
1.1. It seems your approach falls in that bucket, at least without
additional work.
The problem with that is that it becomes super annoying to consume
commons-crypto in other projects. Which maven coordinates do you use?
If you're building something like Spark, which is meant to be deployed
in a bunch of different places with potentially different OpenSSL
versions, how do you even do it?
So IMO any approach to this needs to support both OpenSSL versions in
the same commons-crypto jar file. That doesn't necessarily mean the
same underlying JNI library, although doing that would make creating a
binary releases easier (less build platforms to juggle).

Post by Alex Remily
Commons Crypto Dev Team,
I modified a copy of the commons crypto codebase to support OpenSSL

1.1.0i

Post by Alex Remily
(this was before I saw JIRA CRYPTO-140 "adding suuport for openssl 1.1.0g
in common crypto"). It successfully runs mvn clean test on Mac OS X
10.13.6 and Ubuntu 18.04 with Java 8 and OpenSSL 1.1.0i. I was unable to
test on Windows, presumably because of CRYPTO-137 Error compiling on

Win64

Post by Alex Remily
with Mingw. I did not preserve compatibility with previous versions of
OpenSSL because I don't need it for the project for which I'm using

commons

Post by Alex Remily
crypto.
Is there is interest in maintaining separate branches for different
versions of OpenSSL or for incorporating some of my 1.1.0i-compatible

code

Post by Alex Remily
into a master that supports multiple underlying OpenSSL versions? If so,
I'll fork the repo and send a pull request. I also need to incorporate
message digest functionality, so if there's interest in expanding that
functionality I'll be glad to share the end product.
Thoughts?
Alex

--
Marcelo
---------------------------------------------------------------------