-
Notifications
You must be signed in to change notification settings - Fork 761
crypto: access ticketer via crypto provider #2754
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Benchmark resultsInstruction countsSignificant differencesClick to expand
Other differencesClick to expand
Wall-timeSignificant differencesThere are no significant wall-time differences Other differencesClick to expand
Memory usageKey:
Significant differencesClick to expand
Additional informationCheckout details:
|
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #2754 +/- ##
==========================================
- Coverage 94.96% 94.93% -0.03%
==========================================
Files 98 98
Lines 22047 22017 -30
Branches 632 635 +3
==========================================
- Hits 20936 20902 -34
- Misses 974 975 +1
- Partials 137 140 +3 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
cb2d1d8 to
4ce73ff
Compare
Fixes #1876 by providing an optional
TicketerFactoryimplementation inCryptoProviders.@cpu in that issue:
I think it's probably helpful to have crypto providers provide a default option. In this PR, I've made the
CryptoProviderfield anOptionso that providers can still opt out of providing it (although that makes usage little uglier). I think the API I came up with (independently) mirrors @ctz's suggestion in the issue. With this setup, callers can still provider their ownTicketProducerimplementation but crypto providers have a way of exposing a default one for their crypto stack.Quoting myself:
I don't think this is workable, since the existing AEAD traits are very focused on messages.