-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Binding Stability #5544
Comments
Are there bindings you need to use that wouldn’t be appropriate for APIs in pyOpenSSL? We’ve generally decided we don’t want to consider our bindings public API surface area, with the obvious exception of what pyOpenSSL consumes. If these can be APIs in pyOpenSSL that’s probably the easiest way to ensure we support it. That said, mitmproxy as a downstream test would be fine by me provided it executes reasonably quickly (e.g. a few minutes) and doesn’t have a significant degree of flakiness. You’ve been a great downstream so I’d be willing to spend some CI cycles avoiding breaking you/being aware that we’re going to so you can make plans. |
We can probably add pyOpenSSL APIs for the vast majority. Happy to go that way. 😃
Glad to hear that. I'd claim that we have relatively fast and stable tests, so that should work out. We're quite busy transitioning to a sans-io proxy core at the moment (which introduces a lot of hazmat usage), I'll send a PR once that is in. Thanks again! |
Hi all,
We wanted to add
SSL_get1_supported_ciphers
bindings for @mitmproxy when I discovered #5356, which removes related bindings for which you were not aware of any consumers.How can we support you best here? Add a comment to the respective bindings explaining our use case? Would you welcome us adding mitmproxy to the downstream tests? Anything else we can do?
The text was updated successfully, but these errors were encountered: