from:"A"

[issue45381] IDLE cannot kill process. "interupt" ctl+c and "restart shell" freeze program.

2021-10-05 Thread A A



New submission from A A :

Idle3 with python 3.7.3 on Debian Buster and XFCE.
Attempting to run the line 'print ("Hello World" * 8**8)' from either the Idle 
shell window or Idle editor will cause Idle to hang and one CPU core runs 
100%.(allowed it to run for several minutes) 
ctl+c or menu Shell>interrupt execution simply pauses CPU processing but does 
not terminate the process nor is there an option to continue the process. 
Following this interrupt with use of menu Shell>Restart-shell causes Idle to 
fully freeze and then requires a system terminate signal to close Idle.
The same line of python used in Idle on another student's MS-Windows laptop 
required ctl-alt-del this was a fresh download with v3.9 as I recall.

When used used on the system Bash shell and python 3.7.3, the line operates 
without any trouble and finishes in 20seconds as: $ python3 -c 'print ( "Hello 
World " * 8**8)' 

Suggestion is that the ctl+c or the Interrupt menu option in Idle should 
terminate the running code rather than pause it.

--
assignee: terry.reedy
components: IDLE
messages: 403259
nosy: capsicumw, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE cannot kill process. "interupt" ctl+c and "restart shell" freeze 
program.
type: behavior
versions: Python 3.7

___
Python tracker 
<https://bugs.python.org/issue45381>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9290] IDLE and Command line present different behavior for sys.stdin

2012-03-11 Thread a


a  added the comment:

Other quirks apparently caused by this bug:

msvcrt.getch() does not block and wait for a keypress in IDLE.  Returns 
immediately with b'\xff'.

Some of the suggested usage in the manual for sys.stdin does not work under 
IDLE.  E.g. sys.stdin.detach() doesn't work in IDLE.  On this last point, the 
manual has a caveat in the last line of the sys.stdin description that could 
exonerate it.  Regardless, the behavior is inconsistent and makes for awkward 
UI when using IDLE.

------
nosy: +a
versions: +Python 3.2 -Python 3.1

___
Python tracker 
<http://bugs.python.org/issue9290>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31809] ssl module unnecessarily pins the client curve when using ECDH

2017-10-18 Thread A

New submission from A :

When using elliptic curves in combination with the ssl module to wrap a socket,
the only curve the client accepts is prime256v1. Expected behavior is to accept
all curves that are on the default list and supported by the server.

We noticed the issue when connecting to a server that is configured with a non
standard curve, we get

[SSL: WRONG_CURVE] wrong curve (_ssl.c:661)

unless we explicitly specify to use the correct curve for the context using

context.set_ecdh_curve("secp521r1")

The bug happens both when using a context or ssl.wrap_socket directly.

The bug is that cpython calls OpenSSL (or whatever lib is linked) server
methods even when the context is purely for client communications. The flow is:

- A ssl.SSLContext gets instantiated that will later be used in
SSLContext.wrap_socket with server_side either True or False (bug happens when
this is client side, so server_side=False).

- In the context's constructor, where it's not yet clear if the context is for
a client or a server socket, there is this code:
https://github.com/python/cpython/blob/b9a860f3bf80b0d4a6c25d0f2f6ef849d9bf3594/Modules/_ssl.c#L2180

That code calls (in many cases, depending on the Python and OpenSSL versions
involved) server side only methods, SSL_CTX_set_ecdh_auto or
SSL_CTX_set_tmp_ecdh.

Those methods should in theory not influence the client side of the context,
there is even a comment in the docs for SSLContext.set_ecdh_curve which does
similar things that says "This setting doesn’t apply to client sockets".
However, this being OpenSSL, this is not true. The methods actually set the
list of acceptable curves that is used for both, server and client side
connections, to exactly a single curve, prime256v1. This happens for both,
SSL_CTX_set_tmp_ecdh and SSL_CTX_set_ecdh_auto.

Versions affected:

OpenSSL has changed the API twice here. Before 1.0.2, SSL_CTX_set_tmp_ecdh was
mandatory, 1.0.2 - <1.1.0 used SSL_CTX_set_ecdh_auto and 1.1.0+ doesn't need
this setting at all.

Python 2.7.14+ added a check for 1.1.0+ in
https://github.com/python/cpython/commit/f1a696efd6ca674579e25de29ec4053ff5a5ade1
so starting from that version the issue only happens when using OpenSSL
<1.1.0. I suspect this is the case for many machines still, including all Macs
(haven't confirmed the actual bug there). For LibreSSL the server side methods
will be called too, I can't confirm if that combination is vulnerable too.

Python 3.5.3 gives me the same error, no reason to believe that higher versions
are not affected.

--
assignee: christian.heimes
components: SSL
messages: 304577
nosy: christian.heimes, gr
priority: normal
severity: normal
status: open
title: ssl module unnecessarily pins the client curve when using ECDH
type: behavior
versions: Python 2.7, Python 3.5

___
Python tracker
<https://bugs.python.org/issue31809>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 2560 matches

Mail list logo