Bug 2549486

This would be the third package for OpenSSL bindings for Rust in Fedora which is a bit unfortunate.
Does this really need its own custom bindings or would the bindings from the "openssl" (widely used) or "ossl" (also developed by Red Hat) crate work here too?

I understand your concerns.

rust-openssl does not use modern OpenSSL APIs and overall doesn't really have a good future as an openssl binding. It is also slow. 

ossl is more focused on low level work (kryoptic and sequoia). 

I started native-ossl to address high level applications concerns. The concept was successfully validated through synta, Akamu, Ahdapa, and now kuipa components of FreeIPA modernization work which is coming to Fedora. One of main goals was to make Rust API easier to use for developers who don't really dealt with low-level OpenSSL API in the past. This also proved to work well with agentic workflows.

The family of crates currently includes four:
 - system bindings (this request)
 - openssl API (native-ossl)
 - rustls wrappers (to be submitted) so that applications that expect Rustls can work without changes, by only adding a re-export shim
 - ring wrappers so that RustCrypt consumers can work without changes, by only adding re-export shims.

None of the other bindings is able to provide consistent API behavior without changes to actual Rust applications. I think it is a worthy goal and achievement, both to application developers and to distributions that want to have consistent crypto primitives use (and reduction of downstream maintenance needs).

One example I have, which is important to keep Fedora on the frontier of post-quantum is ability to support new certificate types for Rust applications.

For example, with rustls-native-ossl and synta crates a regular Tokio+Axium application gains support for Merkle Tree Certificates with a trivial extension. This is next to impossible to achieve with any other Rustls code (because there is no support for MTCs there yet) and with any other OpenSSL crates (because MTC support is missing in OpenSSL either). Here is the code for kuipa: https://github.com/abbra/kuipa/pull/22/changes/1b8eaaa21bb806d48efefa34226d649304d4de1e, most of the change is documentation update.

MTCs are important because Google, Apple, Let's Encrypt, Cloudflare, and other public CAs vendors plan to switch to them for their ACME issuers and clients (eg. Chrome) in Q1-Q2 next year. By the time Fedora 46-47 are released Fedora will have to deal with them in both client and server side.

Having multiple libraries that do the same thing is one concern, but the bigger concern is that multiple "-sys" crates that link the same "native" library are can cause problems (due to unpredictable symbol resolution during link time and / or linker errors). This is why cargo enforces this and errors out if multiple crates in an application's dependency tree have the same "links" attribute - see also the cargo docs:

https://doc.rust-lang.org/cargo/reference/build-scripts.html#the-links-manifest-key

It looks like native-ossl would only not hit this safety check issue because it sets `links = "ssl"` (which is arguably more correct) while the openssl-sys and ossl-sys crates use `links = "openssl"` - but *technically* any application that has two or more of openssl-sys / ossl-sys / native-openssl-sys in its dependency tree is at risk of hard-to-debug issues or linker errors.

---

Side note:

> ring wrappers so that RustCrypt consumers can work without changes

The RustCrypto ecosystem does not use the "ring" crate. It was primarily used as the default backend of rustls, but is now superseded by aws-lc-rs.