-
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
Expose built path in public API #174
Conversation
Codecov Report
@@ Coverage Diff @@
## main #174 +/- ##
==========================================
+ Coverage 96.44% 96.53% +0.08%
==========================================
Files 20 20
Lines 4478 4617 +139
==========================================
+ Hits 4319 4457 +138
- Misses 159 160 +1
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
It's common for there to be several possible valid paths (eg if a CA is both cross-signed and also directly trusted, like Let's Encrypt in past years). So this API would be OK for consumers that want to (eg) display or log one of the valid paths, but not for those who want to apply further constraints to it (HPKP, DANE, etc.) if those constraints allow one possible chain but not others. Further constraints really have to be applied during path building so the search could continue to consider other paths. |
Fair point! This PR (and the previous) were mostly focused on first creating a representation of the (Would appreciate any suggestions on how to test |
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.
Very cool!
In terms of testing, I think my comment about exposing more public API surface will be helpful. After that, perhaps generate some certificate paths where one contains an additional EKU that you verify for in the callback, rejecting the candidates that do not have the required EKU throughout?
bc5a487
to
8c68276
Compare
I think so? I think there's no point in cutting a 0.102 release until rustls is ready for 0.22, so I suspect there's some time. |
👍 Added to the list. |
ff13776
to
6307b14
Compare
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.
This is great 👍
de9386c
to
c7d165a
Compare
I find this useful while developing (especially for more explorative development). We deny warnings in CI, so warnings still shouldn't make it to the main branch.
4bfbcd2
to
58b4de2
Compare
@ctz did you want to take another look at this? |
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.
lgtm!
/// Path from end-entity certificate to trust anchor that's been verified. | ||
/// | ||
/// See [`EndEntityCert::verify_for_usage()`] for more details on what verification entails. | ||
pub struct VerifiedPath<'p> { |
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.
do we want any derives on this? (i guess not, based on EndEntityCert
and Cert
not having any?)
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.
We should maybe reconsider that, but given that EndEntityCert
and Cert
don't have any it seems mostly orthogonal to this PR.
Published alpha.5. |
Builds on top of #173. This shows that it is possible to expose the built path without doing substantial extra work (130 extra lines, but with fairly okay abstractions IMO).
Instead of storing the intermediate certificates in stack frames, this pre-allocates an array of fixed size
MAX_CA_SUB_COUNT
(on the stack) and stores the parsed certificates in there. ThePathNode
from #173 is then redefined to iterate over thePartialPath
type containing this array, and path building functions are changed to yield theTrustAnchor
.