Drop dependency on crypto crates

[djc]

This has the integration tests becoming more of an aws-lc-rs monoculture. I think that's okay because the crypto itself is not the part that's under test, and we still have algorithm tests in src/alg_tests.rs.

Depends on

• Move signature verification algorithms into provider crates rustls#2874

(Cargo Deny and Cargo Package failures are expected while this has git dependencies.)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.84%. Comparing base (748e18c) to head (80f7334).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #444      +/-   ##
==========================================
+ Coverage   96.80%   96.84%   +0.04%     
==========================================
  Files          20       20              
  Lines        3940     3898      -42     
==========================================
- Hits         3814     3775      -39     
+ Misses        126      123       -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[djc]

Porting these is non-trivial because they depend on library internals and we effectively have 3 different variants of aws-lc-rs:

• Default
• FIPS
• unstable

rustls-post-quantum has a test that exercises both ML-DSA-44 (for EE) and ML-DSA-87 (for CA), which might be good enough? Alternatively we can add more tests in rustls-aws-lc-rs.

[berkus]

Hi, @ctz :) long time no see.

Do you have plans on when to publish a new version of rustls-webpki with these changes? It removes a "ring" dependency from Cargo.lock for us, which has been flagged for a long time as a component dependency problem by static analysis tools.

[djc]

We could drop an alpha soon, but it will likely take us a few months before we release rustls 0.24 which will build upon this. I'm not completely sure whether you could make your own rustls 0.23 verifier implementation with a rustls-webpki alpha?

[berkus]

Well, alternatively we can patch the dependencies to include this change, not sure how much of a trouble it'll be yet.

[berkus]

@djc would it be possible to do a patch release with this change only? i'm not sure how much it touches based on the previous refactorings, but if it's isolated enough, it could be possible? then we can drop ring without forking rustls temporarily, which will be a huge relief (I'm dizzy keeping a security related project in a fork).

[djc]

@djc would it be possible to do a patch release with this change only? i'm not sure how much it touches based on the previous refactorings, but if it's isolated enough, it could be possible? then we can drop ring without forking rustls temporarily, which will be a huge relief (I'm dizzy keeping a security related project in a fork).

No, I don't think it's feasible.

The static analyses should be aware that Cargo.lock sometimes includes dependencies that are never actually built.

If this is for your work at Microsoft, I strongly suggest they sponsor our work on rustls.

[berkus]

rustls/rustls#2913