-
Notifications
You must be signed in to change notification settings - Fork 51
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
RFC: change high-level API to make key usage explicit #133
Conversation
Codecov Report
@@ Coverage Diff @@
## main #133 +/- ##
==========================================
- Coverage 95.74% 95.16% -0.58%
==========================================
Files 15 15
Lines 3431 3620 +189
==========================================
+ Hits 3285 3445 +160
- Misses 146 175 +29
... and 4 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
This triggers the semver check because we're adding a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, this seems like a nice improvement 👍
Reduced coverage is mostly about the deprecated functions which we no longer call in tests, I think that's okay? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💯
Given that we're going to bump to 0.102 anyway for the optional ring PR, can we pull that in here to avoid the deprecation stuff? |
Sorry, yes let's hold this till tomorrow. I would like to release an 0.101.2 (mainly to get #132 out) before moving main to 0.102.x. I think the deprecations require a semver bump anyway -- we can't control downstreams that write |
I think that's what they're opting into anyway if they set |
Yeah https://doc.rust-lang.org/cargo/reference/semver.html#minor-introducing-new-lints agrees with that intepretation. |
Improved the documentation for |
Ah, this isn't merging because |
@ctz we can hit the "Merge without waiting for requirements to be met" for this case? Or alternatively exclude the semver stuff from the merge queue checks. |
Inspired by #119, I was thinking it might make sense to stop having a bunch of different but mostly similar verification functions, and instead provide a single API call that (a) makes the key usage parameter explicit, and in exchange (b) does away with the shallow trust anchor slice wrappers.
As written, this maintains the explicit connection to a particular key usage but does it in a more generic way. I've chosen methods on
ExtendedKeyUsage
for the common usage values here, but we could alternatively expose these asconst
s and/or potentially hide theExtendedKeyUsage
enum inside an opaquestruct
to force callers to go through an explicit API.cc @sietseringers