Skip to content
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

Closed
mhils opened this issue Nov 2, 2020 · 2 comments
Closed

Binding Stability #5544

mhils opened this issue Nov 2, 2020 · 2 comments

Comments

@mhils
Copy link
Member

mhils commented Nov 2, 2020

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.

If you see this PR in the future and are one of the people affected: we cannot support you if we don't know you exist!

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?

@reaperhulk
Copy link
Member

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.

@mhils
Copy link
Member Author

mhils commented Nov 4, 2020

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.

We can probably add pyOpenSSL APIs for the vast majority. Happy to go that way. 😃

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.

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!

@mhils mhils closed this as completed Nov 4, 2020
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 3, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

2 participants