-
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
IP address support #5
Conversation
Codecov Report
@@ Coverage Diff @@
## main #5 +/- ##
==========================================
+ Coverage 76.09% 86.07% +9.98%
==========================================
Files 14 15 +1
Lines 1556 2349 +793
==========================================
+ Hits 1184 2022 +838
+ Misses 372 327 -45
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
@ctz I am happy to own the missing tasks so that we can move this further. What would be the best way to add work on top of this PR in order to check some of those boxes? Thanks :) |
Can't wait to see this get merged! Thanks for the great effort @ereslibre! |
Usually submitting PRs that target another PRs branch works quite well. |
Is 100% line/diff coverage a realistic requirement? |
I expect to be able to cover it. I should be able to open a PR this week. |
Hi, @ereslibre thank you for this change! |
I have started to work on #14. If you folks have a recommendation on how to run |
#14 is ready for review and targeting this branch :) |
1e752c1
to
fb85e76
Compare
I opened #20 that should check the "100% line diff coverage". |
@djc I have reviewed @ereslibre's changes here, but my commits on this could use a look-over. Then I plan to merge this and #18. Together they provide almost 20 percentage points of testing line coverage. |
These are near the top of my list of things to review once I manage to get the family through Christmas chaos. 🎄 |
src/end_entity.rs
Outdated
@@ -27,6 +27,9 @@ use core::convert::TryFrom; | |||
/// certificate is currently valid *for use by a TLS server*. | |||
/// * `EndEntityCert.verify_is_valid_for_dns_name`: Verify that the server's | |||
/// certificate is valid for the host that is being connected to. | |||
/// * `EndEntityCert.verify_is_valid_for_dns_name_or_ip`: Verify that the server's |
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 (I think) rustls is the only significant user of this API, I kinda feel like it would be good enough to rename the existing method instead of adding another one. Since we rename the function and it will accept a type of a different argument, downstream users will be forced to change the code anyway, and we don't get stuck with additional API surface that will probably go unused.
What do you think?
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.
The main reason why I think it's important is that current users of briansmith/webpki
won't start accepting certificates they would have rejected without this PR. But I understand this does not matter much to rustls
today. However, if a slightly different version of webpki
merges some day and rustls
deviated from that, it will need to adapt to the new webpki
API.
If that is fine, I see no issue in renaming the method instead of adding a new one.
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 suppose I was assuming this would be in a semver-incompatible release, in which case it wouldn't matter, but if this is to go in a semver-compatible release this approach makes sense to me.
So you're saying this PR only makes semver-compatible changes to the public API?
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.
Yes, the contribution to briansmith/webpki
was meant to be semver-compatible.
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.
Unresolving this: given that we're about the release the first version of rustls-webpki we don't have any semver-compatibility constraints here, in which case I think it's better to replace the old method with the new method (instead of retaining both).
src/name/name.rs
Outdated
ip_address::ipv4_octets(dns_name_or_ip).map_err(|_| InvalidDnsNameOrIpError)?, | ||
))); | ||
} | ||
if ip_address::is_valid_ipv6_address(untrusted::Input::from(dns_name_or_ip)) { | ||
return Ok(DnsNameOrIpRef::IpAddress(IpAddressRef::IpV6AddressRef( | ||
dns_name_or_ip, | ||
ip_address::ipv6_octets(dns_name_or_ip).map_err(|_| InvalidDnsNameOrIpError)?, | ||
))); | ||
} | ||
Ok(DnsNameOrIpRef::DnsName( | ||
DnsNameRef::try_from_ascii(dns_name_or_ip).map_err(|_| InvalidDnsNameOrIpError)?, |
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.
These map_err
are swallowing all the error messages.
Would be nice if we could add a string to InvalidDnsNameOrIpError
to forward some details or at least add debug! log statements.
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.
What would be a good error information in this case? Note that this approach is trying to parse ipv4, then ipv6, then a dns name.
If someone provides an invalid ipv4 address, but meaning an ipv4 address, it's not trivial to return a meaningful error message, given we later tried ipv6, and then we tried a dns name.
Minded to merge this now; wdyt @djc? |
I think it's close, but I'd like to do another pass, will try to do that today. (Sorry, this week is still a school/work holiday so my screen time has been fairly limited.) Meanwhile, I did put a comment in #18 (comment) yesterday which I think is relevant to the API proposed here. |
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.
Noted some further feedback. I think it'd be okay to merge, we can address the feedback after merging this if we prefer. Would be good squash the commits from this one as we merge.
@@ -19,7 +19,11 @@ pub use dns_name::{DnsNameRef, InvalidDnsNameError}; | |||
#[cfg(feature = "alloc")] | |||
pub use dns_name::DnsName; | |||
|
|||
mod ip_address; | |||
#[allow(clippy::module_inception)] | |||
mod name; |
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.
Let's rename this to subject_name
?
src/end_entity.rs
Outdated
@@ -27,6 +27,9 @@ use core::convert::TryFrom; | |||
/// certificate is currently valid *for use by a TLS server*. | |||
/// * `EndEntityCert.verify_is_valid_for_dns_name`: Verify that the server's | |||
/// certificate is valid for the host that is being connected to. | |||
/// * `EndEntityCert.verify_is_valid_for_dns_name_or_ip`: Verify that the server's |
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.
Unresolving this: given that we're about the release the first version of rustls-webpki we don't have any semver-compatibility constraints here, in which case I think it's better to replace the old method with the new method (instead of retaining both).
Let me know if I can help somehow. I think it’s probably a bit more cumbersome for me to address feedback at this time given I have to open a PR and we want to squash some commits at least, if not all. I am happy to own further work. |
Introduce `IpAddrRef`, `SubjectNameRef` and the owned type `IpAddr`. Introduce a new public function `verify_is_valid_for_subject_name` that validates a given host name or IP address against a certificate. IP addresses are only compared against Subject Alternative Names. It's possible to convert the already existing types `DnsNameRef` and `IpAddrRef` into a `SubjectNameRef` for better ergonomics when calling to `verify_is_valid_for_subject_name`. The behavior of `verify_cert_dns_name` has not been altered, and works in the same way as it has done until now, so that if `webpki` gets bumped as a dependency, it won't start accepting certificates that would have been rejected until now without notice. Neither `IpAddrRef`, `SubjectNameRef` nor `IpAddr` can be instantiated directly. They must be instantiated through the `try_from_ascii` and `try_from_ascii_str` public functions. This ensures that instances of these types are correct by construction. IPv6 addresses are only validated and supported in their uncompressed form.
@ereslibre addressing my feedback from above in new PRs would be great, thanks for all your hard work so far! |
Submitted #24 |
This is wholly based on the work of @ereslibre - with some testing and fixing the resulting issues found.
TODO list to move this out of draft:
For #4