Consider publishing cryptography-x509-verification and related libraries as standalone crates

[TaaviE]

I was trying to find a pure-Rust implementation of RFC 5280 and it seems like cryptography-x509-verification is one of the few implementations out there, if not the only one that actually exposes all of the necessary functionality. The blogpost about the implementation seems to confirm my suspicion.

Unfortunately it's rather tedious to utilize the code outside of using cryptography in Python, especially when trying to avoid OpenSSL (due to WASM targets), which is a huge pity.

Have you considered publishing these core Rust libraries as standalone crates so that other (Rust or Python) projects could utilize them?

[alex]

We'd ultimately like this to be possible, but the hard part is figuring out what sort of stability policy to apply. Right now we benefit from teh ability to change teh APIs as we see fit.

[TaaviE]

Well, as long as semver is followed and the crate/API is generally advertised as in-flux, I don't see any real constraints anyone could impose on you in terms of API stability.

[reaperhulk]

That's true, but as people start consuming it anyway it becomes difficult to both say we've published it so others can use it but we also make zero promises that we won't break APIs in every release. The crate ecosystem does make that more tenable than it is in Python though...

[TaaviE]

The crates are relatively self-contained though - it would offer its own data types and structures and they would not cause ripples through the crate ecosystem. (At least for a while.) But yes, these would be critical components and they're currently the biggest obstacle right now for standalone usage. The lack of "clean" (non-Python/non-OpenSSL) implementations for CryptoOps/CryptographyError/PolicyBuilder and so make things difficult. Plus the lifetime management of Certificate is a bit difficult at times.

Given enough warning I'm sure people would rather deal with any future API incompatibilities. It generally sounds rather minor compared to the hassle (or horror) that is implementing RFC 5280 from scratch or trying to extract (and adapt) the functionality from existing crates 😄

[DemiMarie]

I did implement RFC5280 from scratch, but it was a bare bones implementation (https://github.com/barebones-x509/barebones-x509, now unmaintained) that didn't support things like chain building.

[alex]

Are you just spamming us with LLM generated summaries? If so, stop it immediately.

[alex]

@reaperhulk and I discussed:

We'd be happy to take a PR that does the following:

• Add direct testing of the rust API using x509-limbo. (Which we already use against the Python API)
• Add automation to set crate version numbers to a version mapping to a cryptography version but pre 1.0 (so cryptography 47.0.0 is version 0.47.0 of the rust crate).
• Adds new automation to our release process that publishes the relevant crates to crates.io (Using trusted publishing)
• Document that these technically follow SemVer but we are making no attempts to minimize backwards incompatible changes (and should be treated as somewhat experimental as a result).