Add OpenSSL 1.1.X Engine Bindings

[brimonk]

Changes

• Added handwritten engine bindings
• Exposed Engine functionality in the main crate

This PR is certainly incomplete, and is a WIP. Using this PR to check for CI and get feedback.

I would like to have this functionality exposed in the library because I haven't yet found an easy way to convert an OpenSSL engine into a provider, at least not without rewriting the engine.

That being said, I figured I would like to get some input on this before I work on implementing the rest of the engine substrate (RSA_METHOD, DSA_METHOD, ENGINE_LOAD_KEY_PTR , etc.).

Open Questions

1. Are there any objections to exposing this engine functionality?
2. What is the correct way to restrict these engine functions to 1.1.X versions of OpenSSL, and similarly for the ENGINE_cleanup call for 1.1.0?
3. Can I complete as much of the engine interface as is present, and in subsequent PRs, complete the other pieces (RSA_METHOD, etc.)?

[sfackler]

#[cfg(all(ossl110, not(ossl300)))] should be the right cfg to do that I think.

Yeah, definitely on board with splitting the implementation across multiple smaller PRs than one huge one.

FYI OpenSSL 1.1.x is EOL in a month or so.

[mvar-ms]

#[cfg(all(ossl110, not(ossl300)))] should be the right cfg to do that I think.

Yeah, definitely on board with splitting the implementation across multiple smaller PRs than one huge one.

FYI OpenSSL 1.1.x is EOL in a month or so.

Hi.

Wandering if this PR is still in development or abandoned.
Engines are still part of ossl 3.0 so should be supported until Sep 2026?

[SercanKaraoglu]

I think this is a great groundwork to enable hardware accelerated cryptography via engines like QAT. I helped you to advance this in here => #2194 - let's push this further.

[brimonk]

For future context, I've decided that approaching this from the ENGINE direction is too large a task for one PR, so I'm closing this, and continuing the work with some smaller PRs, starting with #2219.