Make ring an optional dependency in pingora-rustls

[mattgarmon]

Make ring optional in pingora-rustls

Alternative to #630.

Summary

pingora-rustls unconditionally depends on ring and activates rustls/ring, which prevents consumers from using a different CryptoProvider (e.g. aws-lc-rs, Apple corecrypto, Windows CNG, or custom FIPS implementations).

This PR makes ring an optional, default-on feature and adds a rustls-base feature across the crate stack for consumers who want to provide their own CryptoProvider.

Fully backward compatible: features = ["rustls"] continues to include ring.

New dep: sha2 = "0.10" - replaces ring::digest in hash_certificate() so it works regardless of CryptoProvider.

Usage

# Existing behavior (unchanged) - includes ring
pingora-proxy = { version = "0.8", features = ["rustls"] }

# New, TLS plumbing only, consumer installs their own CryptoProvider
pingora-proxy = { version = "0.8", features = ["rustls-base"] }

[53v3n3d4]

Hi Matt,

The approach is more like I see in other crates and also pingora, only a generic rustls feature. Than user choose, in this case, 2 options: ring or aws lc rs.

Here is how I am using

aws-lc-rs = { version = "1.15.1", default-features = false, features = ["fips"] }
pingora-core = { path = "../../../pingora/pingora-core", features = ["rustls"] }
pingora-proxy = { path = "../../../pingora/pingora-proxy", features = ["rustls"] }
pingora-rustls = { path = "../../../pingora/pingora-rustls", features = ["aws-lc-rs"] }

Than I have no ring in my tree and all use fips. The only changed from #630 is

# pingora-rustls/Cargo.toml

[features]
ring = ["rustls/ring", "dep:ring"]
aws-lc-rs = ["rustls/aws-lc-rs", "dep:aws-lc-rs"]

All other crates can keep the rustls feature as it is

pingora-rustls = { version = "0.8.0", path = "../pingora-rustls", optional = true }

[mattgarmon]

Thanks @53v3n3d4, this approach makes sense.

However there are a couple of concerns with it:

1. Only supporting two CryptoProviders (ring and aws-lc-rs) is restrictive. There are other providers like Apple corecrypto, Windows CNG, and custom implementations that should also be able to be used. Adding these one by one is not ideal, the better alternative it to allow the consumers to provide their own.

2. Keeping other crates using pingora-rustls without default-features=false will still pull in the ring transitive dependency. This is because cargo features are additive, so even if a consumer adds a direct dependency on pingora-rustls with features = ["aws-lc-rs"], the default = ["ring"] from pingora-rustls (activated when pingora-core enables it without default-features = false) can't be suppressed, both are compiled in.

I've updated the PR with some improvements:

• No negative rustls-no-ring feature, instead I've added the rustls-base feature which can be used to include rustls but provide your own CryptoProvider.
• Updated hash_certificate to use sha2, so it works regardless of CryptoProvider being used.
• Added rustls_derived internal feature following the existing openssl_derived convention.

[53v3n3d4]

Maybe follow rustls which currently is maintaining aws lc rs and ring. The others make a custom CryptoProvider. For me having a way to use aws lc rs through rustls is ok.

About the sha, in fips this will be not allowed correct? I ended up not using a default ring, user should select, and other crates stay clean.