[GitHub] aremily commented on issue #92: OpenSSL 1.1.0 updates with backward compatibility for OpenSSL 1.0.2 and 1.0.1

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[GitHub] aremily commented on issue #92: OpenSSL 1.1.0 updates with backward compatibility for OpenSSL 1.0.2 and 1.0.1

GitBox
aremily commented on issue #92: OpenSSL 1.1.0 updates with backward compatibility for OpenSSL 1.0.2 and 1.0.1
URL: https://github.com/apache/commons-crypto/pull/92#issuecomment-460892037
 
 
   Time got away from me over the holidays, but I finally got back to this
   project.  Most of the conversion was indeed trivial, but between OpenSSL
   version 1.0.X and 1.1.X the EVP_CIPHER_CTX structure was made opaque, such
   that in 1.1.X the elements of the struct can only be accessed using the
   appropriate accessor function.  My specific challenge is that I can't
   compile context->encrypt in 1.1.X, and I can't find an
   EVP_CIPHER_CTX_encrypting function in 1.0.X.  I've tried mirroring the
   struct locally and casting it, but the structures didn't align properly and
   "encrypt" didn't have a value of 1 or 0.  If you know of a straightforward
   solution for sneaking a data type passed the compiler please share it.
   Otherwise, I'm pondering a few ways forward, in no particular order.
   
   1.  Pass the "encrypt" flag from the Java environment.  This would be very
   invasive to the existing codebase and may even change the API.  Probably a
   lot of refactoring.
   2.  Build a separate library that contains the required functions and dlsym
   them into the OpenSslNative.c object.  I think this would allow us to get
   the context->encrypt reference through the 1.1.0 compiler, but we would
   have to package another library with the distribution.  I'm also not sure
   how much 1.0.X code we'd have to pull over into the legacy support library
   in order to get all the required dependencies.
   3.  Limit the functionality of the Commons Crypto library to avoid
   context->encrypt.  The only place I can see that it's used is in the
   AEADBadTagException checking.  Two of 113 tests error out.  Everything else
   passes, but for that tiny snippet of code.  How important is the bad tag
   checking?
   
   Any advice?
   
   On Thu, Jan 3, 2019 at 2:40 PM Marcelo Vanzin <[hidden email]>
   wrote:
   
   > If you use runtime checks, you don't need to touch the build at all. The
   > same JNI library should work everywhere. If you test on a 1.1 system, it
   > should cover everything (since Travis here will test your changes on a
   > 1.0.2 system).
   >
   > If you use compile-time checks ("ifdefs"), then you need to build
   > different libraries, which is why I prefer the approach above.
   >
   > —
   > You are receiving this because you authored the thread.
   > Reply to this email directly, view it on GitHub
   > <https://github.com/apache/commons-crypto/pull/92#issuecomment-451254190>,
   > or mute the thread
   > <https://github.com/notifications/unsubscribe-auth/AGg8fnfQuJeQXGPfRx9x00D8soIusAmDks5u_lyqgaJpZM4ZgACn>
   > .
   >
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
[hidden email]


With regards,
Apache Git Services

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