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
Add support for enforcing CRL expiration #1922
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1922 +/- ##
==========================================
+ Coverage 95.48% 95.49% +0.01%
==========================================
Files 86 86
Lines 18664 18709 +45
==========================================
+ Hits 17821 17866 +45
Misses 843 843 ☔ View full report in Codecov by Sentry. |
Just wanted to note IME this job always fails when there's a cargo patch in play, so don't worry about debugging this 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.
Thank you, this looks good 🌠
Are you open to adding an integration test for this? There are some existing tests (starting around here) in api.rs
.
I don't think it needs to be super extensive. Something like:
- updating test_ca.rs to generate an expired CRL alongside the others
- adding one integration test that uses the default verification behaviour, allowing the expired CRL to be processed without err
- adding one integration test that uses the customized behaviour, verifying the CRL is rejected with the expected err.
@cpu Thanks, I've added in this 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.
Thanks for adding the integration test. I had a bit of feedback on the details but the overall test logic looks spot on.
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.
Looks good to me. Thanks!
Would you mind tidying the commit history? Unless anyone else has an opinion I would vote to do this in two commits: one to land the feature, and one to land the integration test update. It feels worth keeping the two separate in this case since the latter requires a large test-ca diff.
Benchmark resultsInstruction countsSignificant differencesClick to expand
Other differencesClick to expand
Wall-timeSignificant differencesThere are no significant wall-time differences Other differencesClick to expand
Additional informationCheckout details:
|
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! Could benefit from some squashes, especially the back-and-forth on the testing commits.
9e09ce6
to
5577cc8
Compare
5577cc8
to
62c9d78
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 seems to be jammed up. The last job (Build+test (stable, ubuntu-latest)) is completed, but spinning. I'm going to pull it out and requeue and see if that does the trick. |
Looks like there's a broader outage. |
This adds support for enforcing the CRL nextUpdate field (i.e. expiration). The corresponding changes in webpki are here: rustls/webpki#227