-
Notifications
You must be signed in to change notification settings - Fork 612
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
Remove TrustAnchorWithDn type #1459
Conversation
/// use x509_parser::prelude::FromDer; | ||
/// println!("{}", x509_parser::x509::X509Name::from_der(dn.as_ref())?.1); | ||
/// ``` | ||
pub fn in_sequence(bytes: &[u8]) -> Self { |
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.
Any name suggestions?
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.
I can think of lots of other names, but no convincing arguments why they'd be better than 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.
Seems like a perfectly cromulent name as-is 👍
Codecov Report
@@ Coverage Diff @@
## main #1459 +/- ##
==========================================
- Coverage 96.50% 96.49% -0.01%
==========================================
Files 71 71
Lines 15148 15105 -43
==========================================
- Hits 14619 14576 -43
Misses 529 529
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
9d18339
to
a6c2aca
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.
TBD: do we still need/want the
RootCertStore
type after this, or can we make do with aVec<TrustAnchor<'static>>
?
I feel like the two remaining methods get quite a bit of use and are generally useful -- so I would like to see them kept. I guess they could become free functions that mutate a Vec<TrustAnchor>
? The other option would be an extension trait on Vec<TrustAnchor>
, which I generally find to be pretty annoying from an API discoverability point of view.
Given the item in RootCertStore
is and always has been pub
, people can move into/out of this type pretty freely to use these functions if desired?
/// use x509_parser::prelude::FromDer; | ||
/// println!("{}", x509_parser::x509::X509Name::from_der(dn.as_ref())?.1); | ||
/// ``` | ||
pub fn in_sequence(bytes: &[u8]) -> Self { |
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.
I can think of lots of other names, but no convincing arguments why they'd be better than 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
/// use x509_parser::prelude::FromDer; | ||
/// println!("{}", x509_parser::x509::X509Name::from_der(dn.as_ref())?.1); | ||
/// ``` | ||
pub fn in_sequence(bytes: &[u8]) -> Self { |
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.
Seems like a perfectly cromulent name as-is 👍
TBD: do we still need/want the
RootCertStore
type after this, or can we make do with aVec<TrustAnchor<'static>>
? I think we'll still need a place to wrapwebpki::extract_trust_anchor()
, and this eliminates the annoying allocations required to convert aVec<TrustAnchorWithDn<'_>>
to a&[TrustAnchor<'_>]
so keeping it probably makes sense?