-
Notifications
You must be signed in to change notification settings - Fork 34
Take updated dependencies #579
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
Conversation
Probably not worth doing a major bump for? Do we have a deprecation mechanism here? Stick with 0.5 until rustls 0.24 comes out? |
a8cc72c
to
57b2fd6
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.
Probably not worth doing a major bump for?
Yeah, probably not, but the README's ABI stability claims mean consumers that take our .so need to treat every release as a major bump. I'd personally be inclined to wait for more changes to pile up in main
to do any kind of release (or revisiting if there's an explicit request from downstream).
Do we have a deprecation mechanism here?
I think cbindgen
supports translating #[deprecated]
into __attribute__((deprecated))
annotations in the .h if that's what you meant 🤔
Handle fallible verifier creation. Disable miri isolation as the existing tests now touch the file system (to load root certs).
Added a commit to enable this. Then I've added |
This is `rustls_platform_server_cert_verifier_with_provider` but with a more orderly way of reporting errors. Mark `rustls_platform_server_cert_verifier_with_provider` as deprecated.`
Notably this means
rustls_platform_server_cert_verifier_with_provider
can now return NULL. Avoiding that would mean using an out param and returning arustls_result
, but would be a major version bump. Thoughts?(I checked and curl uses
rustls_platform_server_cert_verifier
and is therefore suitably fallible.)