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 <notificati...@github.com> 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: us...@infra.apache.org With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
