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
Unable to copy ssl.SSLContext #77204
Comments
results in
This prevents me from being able to The apparent root cause is apparently that |
This is rather a feature than a bug. It is not possible to make a copy of a SSLContext object because OpenSSL doesn't support the operation. A context contains elements that can't be cloned easily, e.g. session resumption tickets. |
Hi Christian, thank you for following up. Here is my use case, and perhaps you can suggest something else that will work: I am refactoring the transport layer in the Pika AMQP client library. The user provides an ssl.SSLContext instance for connecting to an AMQP broker (e.g., RabbitMQ). Pika will resolve the hostname via getaddrinfo and make attempts to establish TCP and AMQP connection to the candidate IP addresses until one succeeds in establishing an AMQP connection over SSL. Each connection attempt will require a fresh unadulterated clone of the ssl.SSLContext instance provided by user to avoid any side-effects from prior connection attempts. How can I obtain this pristine clone cleanly for each new connection attempt? |
Also, updating ssl.SSLContext documentation about intentional inability to copy generically and suggestion how to go about it if you need to obtain a clone or similar would be terrific and save developers time so they won't run into this gotcha when designing and implementing solutions. Many thanks! |
What would those side-effects be? |
Christian Heimes suggested that
My concern then would be potential side-effects from such session resumption tickets and anything else that one connection attempt might save/change within an SSL Context that might have an undesirable side-effect on the follow-on connection attempts. |
You won't have any session resumption tickets until a connection succeeds. And even then, I don't think it would be a problem. By design, SSL contexts are meant to be re-used accross multiple connections. |
Antoine is correct. Session resumption is fully transparent for the application layer. The context object is designed to be reused by multiple connections to same or different servers. |
PR 6099 changes error message "can't pickle SSLContext objects" to "cannot serialize SSLContext object", right? Wouldn't be better to change the standard error message instead? |
It would be very helpful to make a statement in SSLContext's documentation to the effect that it's not copyable. This is frankly the first time I run into a non-copyable object.I spend quite a bit of time researching this after implementing a copying strategy that failed. It would have saved me (and others...) so much time is there was a warning in SSLContext documentation about not being able to serialize/copy/deepcopy by design! Also, making that exception message more generic (ha, I wasn't pickling anything?!) as Serhiy Storchaka suggested would be a welcome addition, but not replacement for documentation. |
Serhiy, Vitaly, |
Thank you, I'll consider myself having been warned :) On Sat, Mar 24, 2018, 7:28 AM Christian Heimes <report@bugs.python.org>
|
Christian, I thought the reason of adding __getstate__ methods which raise an exception is that the existing error message doesn't satisfy your. What is the other reason? |
That's the only reason for PR 6099. The change makes it more obvious that SSL objects can't be serialized or copied. |
See bpo-33138. |
The change to the dup() method looks as a bug fix to me. It needs to be backported to all maintained versions. New tests can be backported to all versions except perhaps 2.7 (not tested). Changes to __getstate__() will be not needed if merge bpo-33138 PR 6239 (they just change the error message). But it may be needed to apply them to 2.7 only. |
If changes to __getstate__() be merged in 2.7, I suggest to unify them with bpo-33138. |
After discussing on Python-Dev all error messages were changed to "cannot pickle 'XXX' object". https://mail.python.org/pipermail/python-dev/2018-October/155599.html I suggest to not add __getstate__() methods with different error messages. But the dup() method should be fixed. |
PR 10934 fixes just a typo in the name of NotImplementedError. It fixes also a similar typo in IDLE. It adds new tests and fixes existing tests for NotImplementedError in SSLSocket. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: