New submission from Vitaly Kruglikov <vitaly.k...@gmail.com>:
```
import copy
import ssl
copy.copy(ssl.create_default_context())
```
results in
`TypeError: can't pickle SSLContext objects`
This prevents me from being able to `copy.deepcopy()` an object that references
`ssl.SSLC
Change by Vitaly Kruglikov <vitaly.k...@gmail.com>:
--
type: -> crash
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33023>
___
_
Change by Vitaly Kruglikov <vitaly.k...@gmail.com>:
--
assignee: -> christian.heimes
components: +SSL
nosy: +christian.heimes
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Vitaly Kruglikov <vitaly.k...@gmail.com>:
`asyncio.WriteTransport.set_write_buffer_limits()` uses an unintuitive order of
the args (high, low). I would expect `low` to be the first arg, especially
since `asyncio.WriteTransport.get_write_buffer_limits()` return
New submission from Vitaly Kruglikov <vitaly.k...@gmail.com>:
```
In [9]: from urllib.parse import urlencode, parse_qs
In [10]: import ast, ssl
In [11]: d = dict(cert_reqs=ssl.CERT_NONE)
In [12]: urlencode(d)
Out[12]: 'cert_reqs=VerifyMode.CERT_NONE'
In [25]: parse_qs('cer
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment:
> What would those side-effects be?
Christian Heimes suggested that
> A context contains elements that can't be cloned easily, e.g. session
> resumption tickets.
My concern then would be potential side-effects fr
New submission from Vitaly Kruglikov <vitaly.k...@gmail.com>:
I need to write a test for my client to make sure it's non-blocking ssl
interactions are able to survive SSL renegotiation. However, I can't seem to
find anything in our python ssl API that calls `SSL_renegotiate()` in
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment:
> By the way, renegotiation is a problematic and has been replaced by rekeying
> in TLS 1.3
How can I trigger rekeying via python ssl? Many thanks.
--
___
Python
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment:
> For extra fun, openssl itself doesn't fully support renegotiation on duplex
> connections ...
The necessitated modification to the application protocol on that thread sounds
like an OpenSSL cop-out. There is no
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment:
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.SSLC
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment:
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
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment:
Thank you, I'll consider myself having been warned :)
On Sat, Mar 24, 2018, 7:28 AM Christian Heimes <rep...@bugs.python.org>
wrote:
>
> Christian Heimes <li...@cheimes.de> added the comment:
>
> Serhiy,
Change by Vitaly Kruglikov <vitaly.k...@gmail.com>:
--
type: -> behavior
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33206>
___
_
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment:
This behavior goes against the socket documentation
https://docs.python.org/2/library/socket.html which states "Supported values
for address_family are currently AF_INET and AF_INET6. If the IP address string
ip_string
New submission from Vitaly Kruglikov <vitaly.k...@gmail.com>:
I am seeing this with `socket.AF_INET6` on Windows running python 2.7.14
```
[00:02:33] File "C:\projects\pika\pika\adapters\host_tcp_connector.py", line
153, in _check_already_resolved
[00:02:33]
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment:
Zachary, thank you for noticing that Twisted is involved. inet_pton definitely
exists on Windows 2.7.14, but it turns out that Twisted monkey-patches it if
`socket.inet_pton(socket.AF_INET6, "::")` fails.
Aha! - b
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment:
Indeed, confirmed no `inet_pton()` on Windows in Python 2.7 :(.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
New submission from Vitaly Kruglikov <vitaly.k...@gmail.com>:
I see this exception on the terminal:
```
exception calling callback for
Traceback (most recent call last):
File
"/usr/local/Cellar/python/3.6.4_3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/concurrent/futur
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment:
> 'events.AbstractEventLoop.run_one_step()'
> This is highly unlikely to ever happen.
Sure, I can see how that could be a problem with other underlying
implementations, such as Twisted reactor. Just wish
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment:
Yet another paradigm is the likes of `GSource` in gnome's glib. GSource "tasks"
added to the event loop are polled by the event loop for readiness before the
event loop blocks on select/epoll/etc.. The ones that are r
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment:
... or `events.AbstractEventLoop.run_one_iteration()`.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment:
Thank you for following up. My use case is this:
In the Pika AMQP client package, we have a blocking AMQP connection adapter -
`BlockingConnection` - wrapped around an asynchronous AMQP connection adapter.
Pre
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment:
I'll have to settle for `set_write_buffer_limits(0, 0)` for my blocking wrapper
case.
I think that 'write_buffer_drained' callback is a good idea, though.
--
___
Python tracke
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment:
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
New submission from Vitaly Kruglikov <vitaly.k...@gmail.com>:
There doesn't appear to be an ordained mechanism for getting notified when a
Transport's (or WriteTransport's) write buffer drains to zero (i.e., all output
data has been transferred to socket). I don't want to
New submission from Vitaly Kruglikov :
assertCountEqual is a horribly misleading name because it misleads the
programmer and reader of the test code into thinking that it only compares the
counts of the elements.
It's name misrepresents what it does in a really bad way
Vitaly Kruglikov added the comment:
Well, when you do tab-completion in unit tests on `self.` and
`assertCountEqual` pops up, it sure sounds a lot like it's going to compare
just the count of the items. The point is that the name of the function is
not self-documenting, hence "misle
Change by Vitaly Kruglikov :
--
status: closed -> open
___
Python tracker
<https://bugs.python.org/issue38240>
___
___
Python-bugs-list mailing list
Unsubscrib
Vitaly Kruglikov added the comment:
Reopened per request from ammar2
--
___
Python tracker
<https://bugs.python.org/issue38240>
___
___
Python-bugs-list mailin
Vitaly Kruglikov added the comment:
Re-opened, thanks!
On Fri, Sep 20, 2019 at 3:01 PM Ammar Askar wrote:
>
> Ammar Askar added the comment:
>
> Hey Vitaly, not sure if you're the author of the original bug here:
> https://bugs.python.org/issue27071
>
> Coul
30 matches
Mail list logo
