[crypto] Updated to Support OpenSSL 1.1.0i

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[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
Reply | Threaded
Open this post in threaded view
|

Re: [crypto] Updated to Support OpenSSL 1.1.0i

Marcelo Vanzin-2
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).

On Tue, Nov 27, 2018 at 1:25 AM Alex Remily <[hidden email]> wrote:

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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [crypto] Updated to Support OpenSSL 1.1.0i

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

On Tue, Nov 27, 2018 at 11:04 AM Marcelo Vanzin <[hidden email]>
wrote:

> 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).
>
> On Tue, Nov 27, 2018 at 1:25 AM Alex Remily <[hidden email]> wrote:
> >
> > 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>