[issue42997] Improve error message for missing : before suites

2021-01-21 Thread Serhiy Storchaka


Serhiy Storchaka  added the comment:

See also issue1634034.

--
nosy: +serhiy.storchaka

___
Python tracker 

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



[issue42384] Inconsistent sys.path between python and pdb

2021-01-21 Thread Andrey Bienkowski


Andrey Bienkowski  added the comment:

I'll give it a try

--

___
Python tracker 

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



[issue40304] Classes created using type() don't need to explicitly inherit from object

2021-01-21 Thread Terry J. Reedy


Change by Terry J. Reedy :


--
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



[issue40304] Classes created using type() don't need to explicitly inherit from object

2021-01-21 Thread miss-islington


miss-islington  added the comment:


New changeset 98e1f5c778b9719f6338a3247da95402192bad18 by Miss Islington (bot) 
in branch '3.9':
bpo-40304: Correct type(name, bases, dict) doc (GH-19553)
https://github.com/python/cpython/commit/98e1f5c778b9719f6338a3247da95402192bad18


--

___
Python tracker 

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



[issue40304] Classes created using type() don't need to explicitly inherit from object

2021-01-21 Thread miss-islington


miss-islington  added the comment:


New changeset 34f3f4ac70e3ba2e603ba7792addf973c94f90cb by Miss Islington (bot) 
in branch '3.8':
bpo-40304: Correct type(name, bases, dict) doc (GH-19553)
https://github.com/python/cpython/commit/34f3f4ac70e3ba2e603ba7792addf973c94f90cb


--

___
Python tracker 

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



[issue40304] Classes created using type() don't need to explicitly inherit from object

2021-01-21 Thread miss-islington


Change by miss-islington :


--
pull_requests: +23119
pull_request: https://github.com/python/cpython/pull/24296

___
Python tracker 

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



[issue40304] Classes created using type() don't need to explicitly inherit from object

2021-01-21 Thread miss-islington


Change by miss-islington :


--
keywords: +patch
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +23118
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24295

___
Python tracker 

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



[issue40304] Classes created using type() don't need to explicitly inherit from object

2021-01-21 Thread Terry J. Reedy

Terry J. Reedy  added the comment:


New changeset 644d52818a6391535e5838fd57d58ffcb1163056 by Борис Верховский in 
branch 'master':
bpo-40304: Correct type(name, bases, dict) doc (GH-19553)
https://github.com/python/cpython/commit/644d52818a6391535e5838fd57d58ffcb1163056


--
nosy: +terry.reedy

___
Python tracker 

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



[issue42606] Support POSIX atomicity guarantee of O_APPEND on Windows

2021-01-21 Thread Eryk Sun


Eryk Sun  added the comment:

FYI, here are the access rights applicable to files, including their membership 
in generic (R)ead, (W)rite, and e(X)execute access:

0x0100_ --- ACCESS_SYSTEM_SECURITY
0x0010_ RWX SYNCHRONIZE
0x0008_ --- WRITE_OWNER
0x0004_ --- WRITE_DAC
0x0002_ RWX READ_CONTROL
0x0001_ --- DELETE

0x_0001 R-- FILE_READ_DATA
0x_0002 -W- FILE_WRITE_DATA
0x_0004 -W- FILE_APPEND_DATA
0x_0008 R-- FILE_READ_EA
0x_0010 -W- FILE_WRITE_EA
0x_0020 --X FILE_EXECUTE
0x_0040 --- FILE_DELETE_CHILD
0x_0080 R-X FILE_READ_ATTRIBUTES
0x_0100 -W- FILE_WRITE_ATTRIBUTES

> _wopen() uses GENERIC_READ/GENERIC_WRITE access rights, but 
> _wopen() doesn't have a contractual obligation to do exactly 
> that AFAIU. For example, if it got some extra access rights, 
> then my code would "drop" them while switching FILE_WRITE_DATA off.

I overlooked a case that's a complication. For O_TEMPORARY, the open uses 
FILE_FLAG_DELETE_ON_CLOSE; adds DELETE to the requested access; and adds 
FILE_SHARE_DELETE to the share mode. 

With delete-on-close, a file gets marked as deleted as soon as the last handle 
for the kernel File is closed. This is the classic Windows 'deleted' state in 
which the filename remains linked in the directory but inaccessible for any new 
access (as opposed to the immediate POSIX style delete that DeleteFileW 
attempts in Windows 10). Existing opens (i.e. kernel File objects from 
CreateFileW) are still valid, and, if they have delete access, they can even be 
used to undelete the file via SetFileInformationByHandle: FileDispositionInfo. 

_Py_wopen_noraise() can easily keep the required DELETE access. The 
complication is that you have to be careful not to close the original file 
descriptor until after you've successfully created the duplicate file 
descriptor. If it fails, you have to return the original file descriptor from 
_wopen(). If you close all handles for the kernel File and fail the call, the 
side effect of deleting the file is unacceptable. 

The C runtime itself isn't careful about using O_TEMPORARY in text mode, given 
how it closes the file if truncation fails or has to open the file twice in 
O_WRONLY mode in order to read the BOM. But at least it's reliable in binary 
mode. The file descriptor is pre-allocated with _alloc_osfhnd(), so it won't 
fail after CreateFileW() is called.

> Are you aware of a common scenario when a regular file allows 
> appending but not writing?

It's certainly not common for regular files. (It's more common for directories, 
for which append access corresponds to the right to create a subdirectory.) 
Maybe users are only allowed to append to a given log file. But I think most 
scenarios will be accidental. 

For example, say an admin wants to deny write access to standard users. Denying 
simple or generic write access is wrong, since doing so also denies rights 
required for reading, i.e. synchronize and read-control. So the admin runs the 
following command to deny only write-data access: `icacls filename /deny 
*BU:(WD)`. This forgets about append-data (AD) access. It's still sufficient 
for most applications, which request generic-write access.

--

___
Python tracker 

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



[issue42999] `pathlib.Path.link_to()` documentation is misleading

2021-01-21 Thread Barney Gale


Change by Barney Gale :


--
pull_requests: +23117
pull_request: https://github.com/python/cpython/pull/24294

___
Python tracker 

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



[issue43000] All SSL requests fail with WRONG_VERSION_NUMBER when a packet sniffer is open

2021-01-21 Thread Darren Skidmore


New submission from Darren Skidmore :

As of Python 3.9.1, when attempting to perform any SSL requests when a packet 
sniffer tool (e.g. Telerik Fiddler) is intercepting SSL traffic, the program 
will hang for about a minute and then crash with a WRONG_VERSION_NUMBER error. 
This has been tested to occur with urllib2 and requests modules. Alternatives 
such as verify=False and adding the Fiddler Root Certificate to Python's 
cacert.pem file do not rectify this error.

This traceback was generated when attempting to access https://example.com:443 
while Fiddler 5.0.20204.45441 was open:

Traceback (most recent call last):
  File 
"C:\Users\Darren\AppData\Local\Programs\Python\Python39\lib\site-packages\urllib3\connectionpool.py",
 line 696, in urlopen
self._prepare_proxy(conn)
  File 
"C:\Users\Darren\AppData\Local\Programs\Python\Python39\lib\site-packages\urllib3\connectionpool.py",
 line 964, in _prepare_proxy
conn.connect()
  File 
"C:\Users\Darren\AppData\Local\Programs\Python\Python39\lib\site-packages\urllib3\connection.py",
 line 359, in connect
conn = self._connect_tls_proxy(hostname, conn)
  File 
"C:\Users\Darren\AppData\Local\Programs\Python\Python39\lib\site-packages\urllib3\connection.py",
 line 496, in _connect_tls_proxy
return ssl_wrap_socket(
  File 
"C:\Users\Darren\AppData\Local\Programs\Python\Python39\lib\site-packages\urllib3\util\ssl_.py",
 line 432, in ssl_wrap_socket
ssl_sock = _ssl_wrap_socket_impl(sock, context, tls_in_tls)
  File 
"C:\Users\Darren\AppData\Local\Programs\Python\Python39\lib\site-packages\urllib3\util\ssl_.py",
 line 474, in _ssl_wrap_socket_impl
return ssl_context.wrap_socket(sock)
  File "C:\Users\Darren\AppData\Local\Programs\Python\Python39\lib\ssl.py", 
line 500, in wrap_socket
return self.sslsocket_class._create(
  File "C:\Users\Darren\AppData\Local\Programs\Python\Python39\lib\ssl.py", 
line 1040, in _create
self.do_handshake()
  File "C:\Users\Darren\AppData\Local\Programs\Python\Python39\lib\ssl.py", 
line 1309, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:1123)

This exact question has recently been asked on StackOverflow: 
https://stackoverflow.com/questions/65516325/ssl-wrong-version-number-on-python-request

--
assignee: christian.heimes
components: SSL
messages: 385476
nosy: christian.heimes, darrenrs
priority: normal
severity: normal
status: open
title: All SSL requests fail with WRONG_VERSION_NUMBER when a packet sniffer is 
open
type: crash
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



[issue42999] `pathlib.Path.link_to()` documentation is misleading

2021-01-21 Thread Jay Chu


Change by Jay Chu :


--
nosy: +tothesong

___
Python tracker 

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



[issue42999] `pathlib.Path.link_to()` documentation is misleading

2021-01-21 Thread Barney Gale


Change by Barney Gale :


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

___
Python tracker 

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



[issue39950] Add pathlib.Path.hardlink_to()

2021-01-21 Thread Barney Gale


Barney Gale  added the comment:

I've logged bpo-42999 to cover fixing the existing `link_to()` docs issues. PR 
incoming...

--

___
Python tracker 

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



[issue42999] `pathlib.Path.link_to()` documentation is misleading

2021-01-21 Thread Barney Gale


New submission from Barney Gale :

Compare the documentation of `symlink_to()` and `link_to()`:

.. method:: Path.symlink_to(target, target_is_directory=False)
Make this path a symbolic link to *target*.

.. method:: Path.link_to(target)
Create a hard link pointing to a path named *target*.

In fact, `link_to()` does something like:

Make *target* a hard link to this path.

Which is unexpected given the naming and inconsistency with `symlink_to()`, but 
it's the way the current implementation works, and so the documentation should 
reflect that.

Adding a replacement `hardlink_to()` function is covered here in bpo-39950.

--
assignee: docs@python
components: Documentation
messages: 385474
nosy: barneygale, docs@python
priority: normal
severity: normal
status: open
title: `pathlib.Path.link_to()` documentation is misleading
type: behavior

___
Python tracker 

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



[issue42998] pathlib.Path: add `username` argument to `home()`

2021-01-21 Thread Barney Gale


Barney Gale  added the comment:

I should add that this is part of a plan to spin out some `Path` methods into a 
new `UserPath` class. Notably, in this case, `UserPath.expanduser()` will call 
`self.home()` under-the-hood. This is done to reduce the surface area of 
abstract methods that subclasses of `UserPath` need implement. More discussion 
here: https://discuss.python.org/t/make-pathlib-extensible/3428

--

___
Python tracker 

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



[issue42998] pathlib.Path: add `username` argument to `home()`

2021-01-21 Thread Barney Gale


New submission from Barney Gale :

The `pathlib.Path.home()` function looks like:

@classmethod
def home(cls):
"""Return a new path pointing to the user's home directory (as
returned by os.path.expanduser('~')).
"""
return cls(cls()._flavour.gethomedir(None))

If we add a `username=None` parameter and pass this to `gethomedir()` we can 
easily add a lookup of another user's home directory, so:

import pathlib
username = 'phil'
pathlib.Path.home(username) == pathlib.Path('~' + username).expanduser()

--
components: Library (Lib)
messages: 385472
nosy: barneygale
priority: normal
severity: normal
status: open
title: pathlib.Path: add `username` argument to `home()`
type: enhancement

___
Python tracker 

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



[issue39950] Add pathlib.Path.hardlink_to()

2021-01-21 Thread Jay Chu

Jay Chu  added the comment:

For me, and as you've pointed out, the current doc of `Path.link_to` is already 
wrong and misleading. Perhaps a fix of the doc should be made as a first step.

The doc uses the expression "Create a hard link pointing to a path named 
target." 
But comparing this to the doc of `Path.symlink_to`, which says "Make this path 
a symbolic link to target.", 
(and the doc of `os.link`, which says, "Create a hard link pointing to src 
named dst.",)
the current doc should actually be "Create a hard link at `target` pointing to 
this path." Sadly the argument name can't be changed here already.

And the doc of `Path.symlink_to` even have a helpful note: "Note: The order of 
arguments (link, target) is the reverse of os.symlink()’s." 
We could also add one for `Path.link_to`, too, like "Note: The order of 
arguments (link, target) is the consistent with os.link()’s.

Based on that foundation, we could finally continue to implement the correct 
"Path.hardlink_to". 

We can refer to how people retained `subprocess.call` while adding a newer , 
preferred `subprocess.run`, by noting people to prefer `Path.hardlink_to` as 
it's more consistent with the `pathlib` and OOP, along with telling them the 
obscurity of `Path.link_to` and why it's left here for backward capability.

--

___
Python tracker 

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



[issue42384] Inconsistent sys.path between python and pdb

2021-01-21 Thread Guido van Rossum


Guido van Rossum  added the comment:

Hey Andrey, this has been merged into 3.10, but the backports didn't work 
because the structure of the tests has changed (os_helper doesn't exist). Do 
you want to fix these?

--
nosy: +gvanrossum

___
Python tracker 

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



[issue42985] AMD64 Arch Linux Asan 3.x fails: command timed out: 1200 seconds without output

2021-01-21 Thread Pablo Galindo Salgado


Pablo Galindo Salgado  added the comment:

> About SIGSEGV logs, one option is to use ASAN_OPTIONS="handle_segv=0".

Opened https://github.com/python/buildmaster-config/pull/222

--

___
Python tracker 

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



[issue42997] Improve error message for missing : before suites

2021-01-21 Thread Pablo Galindo Salgado


Pablo Galindo Salgado  added the comment:

PR 24293 implements the second idea (only new rules and no new machinery)

--

___
Python tracker 

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



[issue42997] Improve error message for missing : before suites

2021-01-21 Thread Pablo Galindo Salgado


Change by Pablo Galindo Salgado :


--
pull_requests: +23115
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24293

___
Python tracker 

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



[issue42990] Improve the C code for calling Python code

2021-01-21 Thread Guido van Rossum


Change by Guido van Rossum :


--
nosy: +brett.cannon, petr.viktorin, rhettinger, serhiy.storchaka, vstinner, 
yselivanov

___
Python tracker 

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



[issue41928] ZipFile does not supports Unicode Path Extra Field (0x7075) zip header field

2021-01-21 Thread Andrea Giudiceandrea


Andrea Giudiceandrea  added the comment:

I submitted more than a month ago a PR that adds support for Unicode Path Extra 
Field in ZipFile.
The PR https://github.com/python/cpython/pull/23736 is awaiting a review in 
order to be merged.

--

___
Python tracker 

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



[issue42997] Improve error message for missing : before suites

2021-01-21 Thread Pablo Galindo Salgado


Change by Pablo Galindo Salgado :


--
nosy: +gvanrossum

___
Python tracker 

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



[issue42997] Improve error message for missing : before suites

2021-01-21 Thread Pablo Galindo Salgado


Pablo Galindo Salgado  added the comment:

There are several ways to implement this:

In PR24292 I implemented this idea by adding a new element to the grammar: 
'&&'. This allows to hard-expect a token: if the token is not there the parsing 
hard-fails immediately without trying anything else and displays an appropriate 
error message

The other possibility if we think that PR24292 is overkill is manually adding 
an "invalid_wathever" for every possible compound statement option that parses 
the statement with a !':' and then raises appropriately. This option is more 
verbose in the grammar but requires no new machinery.

--
stage: patch review -> 

___
Python tracker 

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



[issue42997] Improve error message for missing : before suites

2021-01-21 Thread Pablo Galindo Salgado


Change by Pablo Galindo Salgado :


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

___
Python tracker 

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



[issue42997] Improve error message for missing : before suites

2021-01-21 Thread Pablo Galindo Salgado


Change by Pablo Galindo Salgado :


--
nosy: +lys.nikolaou

___
Python tracker 

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



[issue42384] Inconsistent sys.path between python and pdb

2021-01-21 Thread miss-islington


miss-islington  added the comment:


New changeset 8603dfb4219989644601f6ede75b57e82648cd4e by Andrey Bienkowski in 
branch 'master':
bpo-42384: pdb: correctly populate sys.path[0] (GH-23338)
https://github.com/python/cpython/commit/8603dfb4219989644601f6ede75b57e82648cd4e


--

___
Python tracker 

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



[issue42384] Inconsistent sys.path between python and pdb

2021-01-21 Thread miss-islington


Change by miss-islington :


--
pull_requests: +23112
pull_request: https://github.com/python/cpython/pull/24291

___
Python tracker 

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



[issue42384] Inconsistent sys.path between python and pdb

2021-01-21 Thread miss-islington


Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 1.0 -> 2.0
pull_requests: +23111
pull_request: https://github.com/python/cpython/pull/24290

___
Python tracker 

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



[issue42997] Improve error message for missing : before suites

2021-01-21 Thread Pablo Galindo Salgado


New submission from Pablo Galindo Salgado :

Instead of displaying a generic syntax error:

Python 3.8.6 (default, Oct 10 2020, 18:31:21)
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> for x in range
  File "", line 1
for x in range
 ^
SyntaxError: invalid syntax
>>>

we could display:

>>> for x in range
  File "", line 1
for x in range
  ^
SyntaxError: expected ':'

The same idea applies for every suite that has a missing ':'

--
messages: 385463
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Improve error message for missing : before suites
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



[issue42780] os.set_inheritable() fails for O_PATH file descriptors on Linux

2021-01-21 Thread STINNER Victor


STINNER Victor  added the comment:

> No problem! I've noticed at least one other (relatively minor) issue in `os`, 
> so I may be submitting further bug reports.

Please do. But I suggest to open new issues.

> I haven't been keeping close track of 3.6/3.7's status, so I added them in 
> without thinking it. Thanks for the reminder.

Don't worry (be happy). Everybody is confused by the Versions field.

--

___
Python tracker 

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



[issue31904] Python should support VxWorks RTOS

2021-01-21 Thread STINNER Victor


STINNER Victor  added the comment:


New changeset 5e45f1c8e7bc5f0ab8feba88b9b6e47066203a5c by pxinwr in branch 
'master':
bpo-31904: setup.py: fix cross-compilation on VxWorks (GH-24191)
https://github.com/python/cpython/commit/5e45f1c8e7bc5f0ab8feba88b9b6e47066203a5c


--

___
Python tracker 

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



[issue42988] Information disclosure via pydoc -p: /getfile?key=path allows to read arbitrary file on the filesystem

2021-01-21 Thread STINNER Victor


STINNER Victor  added the comment:

> I'd suggest to print a big warning on the console, explaining that the web 
> server will potentially make all content accessible by the user visible to 
> anyone else on the same server.

I dislike this idea. If they are vulnerabilities, they should be fixed. Users 
usually have no idea what to do when seeing such warning.

--

___
Python tracker 

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



[issue42985] AMD64 Arch Linux Asan 3.x fails: command timed out: 1200 seconds without output

2021-01-21 Thread STINNER Victor


STINNER Victor  added the comment:

> Both sound reasonable. But not sure if they will resolve this crash tough.

Many tests do crash *on purpose*. Example on test_concurrent_futures.py:

def _crash(delay=None):
"""Induces a segfault."""
if delay:
time.sleep(delay)
import faulthandler
faulthandler.disable()
faulthandler._sigsegv()

Internally, faulthandler._sigsegv() disables crash reports.

There is also test.support.SuppressCrashReport context manager to disable crash 
reports. But I failed to find a way to disable ASAN signal handler at runtime.

It's possible to disable the ASAN signal handler at runtime using 
signal.signal(SIGSEGV, signal.SIG_DFT), but that should be done before Python 
installs its own signal handler for that, like before calling 
faulthandler.enable(). It would require to inject code in test_faulthandler to 
restore the default handler *before* calling faulthandler.enable(). Right now, 
test_faulthandler is skipped on the ASAN buildbots.

--

___
Python tracker 

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



[issue39950] Add pathlib.Path.hardlink_to()

2021-01-21 Thread Barney Gale


Barney Gale  added the comment:

Makes sense to me. Should I leave the documentation for `link_to` completely 
alone? With the addition of a similar function, I wonder if that may in itself 
cause confusion.

--

___
Python tracker 

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



[issue42996] hashlib documentation references an obsolete RFC 2898

2021-01-21 Thread Illia Volochii


Change by Illia Volochii :


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

___
Python tracker 

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



[issue42996] hashlib documentation references an obsolete RFC 2898

2021-01-21 Thread Illia Volochii


New submission from Illia Volochii :

RFC 2898 mentioned in the "See also" section of hashlib documentation was 
superseded by RFC 8018.

https://docs.python.org/3/library/hashlib.html
https://www.ietf.org/rfc/rfc8018.txt

--
assignee: docs@python
components: Documentation
messages: 385457
nosy: docs@python, illia-v
priority: normal
severity: normal
status: open
title: hashlib documentation references an obsolete RFC 2898

___
Python tracker 

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



[issue42606] Support POSIX atomicity guarantee of O_APPEND on Windows

2021-01-21 Thread Alexey Izbyshev


Alexey Izbyshev  added the comment:

> I don't know what you mean by default access rights.

I meant the access rights of the handle created by _wopen(). In my PR I 
basically assume that _wopen() uses GENERIC_READ/GENERIC_WRITE access rights, 
but _wopen() doesn't have a contractual obligation to do exactly that AFAIU. 
For example, if it got some extra access rights, then my code would "drop" them 
while switching FILE_WRITE_DATA off.

> For example, if FILE_WRITE_DATA isn't granted, then open() can't open for 
> appending. A direct CreateFileW() call can remove FILE_WRITE_DATA from the 
> desired access.

Indeed, I haven't thought about it. Are you aware of a common scenario when a 
regular file allows appending but not writing?

But, at least, this is not a regression: currently open()/os.open() can't open 
such files for appending too.

> An opener could also work like your PR via os.open(), msvcrt.get_osfhandle(), 
> _winapi.GetFileType(), _winapi.DuplicateHandle(), os.close(), and 
> msvcrt.open_osfhandle().

True, but it still falls into "etc" category of "ctypes/pywin32/etc" :) 
Certainly doable, but it seems better to have consistent O_APPEND behavior 
across platforms out-of-the-box.

--

___
Python tracker 

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



[issue42995] Add PurePath.with_suffix_appended()

2021-01-21 Thread Brendan Gerrity


Change by Brendan Gerrity :


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

___
Python tracker 

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



[issue42982] Update suggested number of iterations for pbkdf2_hmac()

2021-01-21 Thread Illia Volochii


Illia Volochii  added the comment:

I didn't find any. I think it is based on some benchmarks like `openssl speed 
sha`.

--

___
Python tracker 

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



[issue42606] Support POSIX atomicity guarantee of O_APPEND on Windows

2021-01-21 Thread Eryk Sun


Eryk Sun  added the comment:

> can a new handle have non-default access rights? Or can the 
> default change at this point of Windows history?

I don't know what you mean by default access rights.

C open() requests generic access rights, which map to the standard and 
file-specific rights in the File type's generic mapping. If all of the 
requested access rights aren't granted, then the open fails with an access 
denied error. For example, if FILE_WRITE_DATA isn't granted, then open() can't 
open for appending. A direct CreateFileW() call can remove FILE_WRITE_DATA from 
the desired access.

DuplicateHandle() can always request the same or less access than the source 
handle. For some object types, it can perform an access check to get more 
access, but not for a File handle.

> Currently, the only way to achieve atomic append in Python on 
> Windows that I know is to use a custom opener that would call
> CreateFile() with the right arguments via ctypes/pywin32/etc.

An opener could also work like your PR via os.open(), msvcrt.get_osfhandle(), 
_winapi.GetFileType(), _winapi.DuplicateHandle(), os.close(), and 
msvcrt.open_osfhandle().

--

___
Python tracker 

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



[issue42980] argparse: GNU-style help formatter

2021-01-21 Thread Will Noble


Will Noble  added the comment:

The main contribution of my PR is simply factoring out _format_option_with_args 
as an overridable method. Note that this actually enables subclassing 
HelpFormatter to produce all the examples you presented above with 1-3 trivial 
lines of code, as opposed to overriding the entire _format_action_invocation 
which is 20 lines in the base class.

If HelpFormatter had a stable internal structure (i.e. some sort of assurance 
that it's overridable methods were not subject to change), I wouldn't have 
bothered including an implementation of GnuStyleLongOptionsHelpFormatter in 
this PR, since I could just implement it downstream as-needed. However, I chose 
to push it upstream because a) it's trivial and non-invasive and b) it 
establishes a use-case of _format_option_with_args for posterity, just in case 
anybody came in later and saw such a trivial, "private" (underscore-prefixed) 
method and decided to inline it.

This lack of perceived stability is alluded to in 
https://bugs.python.org/issue42966. My preferred solution would be to refactor 
HelpFormatter to have more overridable methods like this, make them 
non-"private", document them properly, and keep them relatively stable. In 
order to do that, we'd want to establish all the desired use-cases and be sure 
to craft the method structure in such a way that they're all supported. Since 
that would be a somewhat daunting design task and probably not high on the 
priority list atm, I think this small incremental improvement pushes things in 
the right direction; establishing a desirable use-case without committing to 
too many implementation details yet.

--

___
Python tracker 

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



[issue42994] Missing MIME types for opus, AAC, 3gpp and 3gpp2

2021-01-21 Thread Nathan Beals


Change by Nathan Beals :


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

___
Python tracker 

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



[issue42995] Add PurePath.with_suffix_appended()

2021-01-21 Thread Brendan Gerrity


Brendan Gerrity  added the comment:

This could addressed with either a new helper or an option in the 
`PurePath.with_suffix()`.

--

___
Python tracker 

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



[issue42995] Add PurePath.with_suffix_appended()

2021-01-21 Thread Brendan Gerrity


New submission from Brendan Gerrity :

Appending a new suffix to a file is common operation.

The operations don't come across as elegant:

e.g. `foo_path.with_suffix(foo_path.suffix + ".old")`

--
components: Library (Lib)
messages: 385451
nosy: bgerrity
priority: normal
severity: normal
status: open
title: Add PurePath.with_suffix_appended()
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



[issue42800] Traceback objects allow accessing frame objects without triggering audit hooks

2021-01-21 Thread Ryan Hileman


Ryan Hileman  added the comment:

How's this for maintainable?

https://github.com/lunixbochs/cpython/commit/2bf1cc93d19a49cbed09b45f7dbb00212229f0a1

--

___
Python tracker 

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



[issue42447] robotsparser deny all with some rules

2021-01-21 Thread Terry J. Reedy


Change by Terry J. Reedy :


--
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



[issue42994] Missing MIME types for opus, AAC, 3gpp and 3gpp2

2021-01-21 Thread Nathan Beals


Change by Nathan Beals :


--
title: Missing MIME types for opus, AAC and 3gpp(2) -> Missing MIME types for 
opus, AAC, 3gpp and 3gpp2

___
Python tracker 

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



[issue42994] Missing MIME types for opus, AAC and 3gpp(2)

2021-01-21 Thread Nathan Beals


New submission from Nathan Beals :

These are officially recognized MIME types by IANA: 
https://www.iana.org/assignments/media-types/media-types.xhtml#audio

- .opus: audio/opus (https://www.iana.org/assignments/media-types/audio/opus 
and https://tools.ietf.org/html/rfc7845 for recommended file extension)
- .aac: audip/aac (https://www.iana.org/assignments/media-types/audio/aac)
- .3gp: audio/3gpp (https://www.iana.org/assignments/media-types/audio/3gpp)
- .3g2: audio/3gpp2 (https://www.iana.org/assignments/media-types/audio/3gpp2)

--
components: Library (Lib)
messages: 385449
nosy: nbeals
priority: normal
severity: normal
status: open
title: Missing MIME types for opus, AAC and 3gpp(2)
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



[issue42980] argparse: GNU-style help formatter

2021-01-21 Thread paul j3


paul j3  added the comment:

The refactoring looks reasonable.

But while we are tweaking:

def _format_action_invocation(self, action):

I wonder if we also give users more control over how multiple option strings 
are formatted.  Currently if 

 parser.add_argument('-f', '--foo', help='something')

the help line will be

 -f FOO, --foo FOO something

with this alternate formatter it would be (I think)

 -f FOO, --foo=FOO something

But with longer option strings users often want

 -f, --foo FOO something

or even just

 -f, --foo something

we can almost get the last with `metavar=''`

 -f , --foosomething

which has a superfluous space before the comma.

I don't recall if there's already a bug/issue for this or not.  Maybe the fix 
is a subclass with a complete replacement of this _format_action_invocation 
method.  I'll have do more research (here and on Stackoverflow).

--

___
Python tracker 

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



[issue42993] doc xml.etree.ElementTree.ElementTree.write does not mention attribute order

2021-01-21 Thread Christian Buhtz


New submission from Christian Buhtz :

The docs for 'xml.etree.ElementTree.ElementTree.write' in Python 3.7 (and 
possible earlier) does not say a word about the ordering of the attributes.

This makes unittesting hard.

But looking in the code tells me that the attributes are ordered lexically. 
Important to know. So please upgrade the docu about that.

In Python 3.8 the ordering behavior changed again but is mentioned in the docu. 
So no need to change in 3.8 or later.

--
assignee: docs@python
components: Documentation
messages: 385448
nosy: buhtz, docs@python
priority: normal
severity: normal
status: open
title: doc xml.etree.ElementTree.ElementTree.write does not mention attribute 
order
type: enhancement
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



[issue42992] Tkinter bbox coordinates incorrectly drawn

2021-01-21 Thread Ron Hoffmann


New submission from Ron Hoffmann :

position coordinates retrieved from any object on a canvas with
pos = canvas.bbox(object) are returned correctly

but when drawn on the canvas (x0,y0) are correct, but
(x1, y1) are not drawn in the proper positions. x1 has been divided by 2 
somewhere and y1 as been multiplied by 2 somewhere.
in order for the bounding box to be drawn correctly
x1 and y1 need to be recalculated as follows

x1 = pos[0] + ( ( pos[2] - pos[0] ) * 2 )
y1 = pos[1] + ( ( pos[3] - pos[1] ) / 2 )

--
components: Tkinter
messages: 385446
nosy: rhoffmann
priority: normal
severity: normal
status: open
title: Tkinter bbox coordinates incorrectly drawn
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



[issue42991] support for splitting multichannel audio fragments in audioop module

2021-01-21 Thread Ramón Fraterman

Change by Ramón Fraterman :


--
status: pending -> open

___
Python tracker 

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



[issue42862] Use functools.lru_cache iso. _sqlite.Cache in sqlite3 module

2021-01-21 Thread Erlend Egeberg Aasland


Erlend Egeberg Aasland  added the comment:

> Or is it ok to call gc.collect() in the test suite?

Seems like it's ok:

$ grep -r gc.collect Lib/test | wc -l
366

--

___
Python tracker 

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



[issue42862] Use functools.lru_cache iso. _sqlite.Cache in sqlite3 module

2021-01-21 Thread Erlend Egeberg Aasland


Erlend Egeberg Aasland  added the comment:

This works:

1) fully implement GC in connection (bpo-42972)
2) also visit statement_cache
3) explicitly close connections _and_ call GC in problematic tests

The first point might not be needed for this particular fix.
The last point is a workaround, not a solution. Or is it ok to call 
gc.collect() in the test suite?

--

___
Python tracker 

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



[issue42991] support for splitting multichannel audio fragments in audioop module

2021-01-21 Thread Ramón Fraterman

Change by Ramón Fraterman :


--
status: open -> pending

___
Python tracker 

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



[issue42991] support for splitting multichannel audio fragments in audioop module

2021-01-21 Thread Ramon


Change by Ramon :


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

___
Python tracker 

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



[issue42991] support for splitting multichannel audio fragments in audioop module

2021-01-21 Thread Ramon


New submission from Ramon :

All functions from the audioop module that work on stereo fragments, provide 
the same behaviour on multichannel (i.e. 5.1 channel LPCM) fragments. This is, 
however, not true for the tomono() function, that only makes sense when 
supplied with a 2-channel fragment.

Therefore, I suggest adding an extra function to the module that demultiplexes 
any N-channel fragment and returns a given channel as mono fragment:
audioop.demux(fragment, width, nChannels, channel)

When, for example, applied to a 16 bit stereo fragment, audioop.demux(fragment, 
2, 2, 0) would give the same result as audioop.tomono(fragment, 2, 1.0, 0).

--
components: Extension Modules
messages: 385443
nosy: Th4R4
priority: normal
severity: normal
status: open
title: support for splitting multichannel audio fragments in audioop module
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



[issue42982] Update suggested number of iterations for pbkdf2_hmac()

2021-01-21 Thread Christian Heimes


Christian Heimes  added the comment:

Is there any scientific research or mathematical proof for 250,000 iteration?

--
nosy: +christian.heimes

___
Python tracker 

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



[issue33289] tkinter askcolor returning floats for r, g, b values instead of ints

2021-01-21 Thread Serhiy Storchaka


Serhiy Storchaka  added the comment:


New changeset 6713e869c4989c04318158b406c30a147ea52904 by Cheryl Sabella in 
branch 'master':
bpo-33289: Return RGB triplet of ints instead of floats from 
tkinter.colorchooser (GH-6578)
https://github.com/python/cpython/commit/6713e869c4989c04318158b406c30a147ea52904


--

___
Python tracker 

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



[issue42800] Traceback objects allow accessing frame objects without triggering audit hooks

2021-01-21 Thread Ryan Hileman


Ryan Hileman  added the comment:

My understanding as per the outline in PEP 551 as well as PEP 578, is that the 
audit system is meant primarily to observe the behavior of code rather than to 
have good sandbox coverage / directly prevent behavior.

I am using audit hooks to observe the behavior of third party Python, and I 
identified an indicator of shady behavior which includes code and frame object 
access (which includes sys._getframe(), and __code__, both of which are part of 
the original PEP 578).

I looked into it further and realized the CPython's auditing for those 
attributes/objects is superficial. I understand that auditing isn't perfect, 
and I'm not trying to change that. This patch just seems to me like a really 
basic and obvious extension of the existing __code__ and getframe audit points.



I ask that if your main hesitation is the impact of future audit hooks, we use 
this opportunity to establish a basic written precedent we can reference in the 
future about which kind of audit hook modifications are likely to be accepted 
without, say, another PEP.

One possible set of criteria:
 - The added hooks should be justified as functionally identical to something 
the existing PEP(s) suggested.
 - Performance should be measured and it should have very little impact on 
stdlib or general code.
 - The requester should be expected to justify the change, e.g. how it closes 
an obvious gap in an existing PEP 578 hook.

And my answers for those criteria:
 - These are functionally equivalent to the existing PEP 578 hooks for 
sys._getframe() and function.__code__ - they operate on similar types of 
objects and are used for accessing the exact same information.
 - Performance impact here appears to be only for debugging code, and 
performance impact on debugging code is infinitesimal when no audit hook is 
active.
 - I am auditing code for trivial usage of Python frames and code objects, and 
I can't do that sufficiently with the existing hooks (especially so now that 
I'm publicly documenting this gap).



If the primary complaint is maintenance burden, would it be preferable to add 
an attribute audit flag to PyMemberDef instead of using one-off PyGetSetDef 
functions? e.g.:

static PyMemberDef frame_memberlist[] = {
{"f_code",  T_OBJECT,   OFF(f_code),  
READONLY|AUDIT_ACCESS},
}

That would definitely simplify the implementation.

If these additions aren't worth it, I would almost recommend removing or 
deprecating the existing __code__ and sys._getframe() audit hooks instead, as I 
find them to be not very useful without this patch.

--

___
Python tracker 

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



[issue42969] pthread_exit & PyThread_exit_thread from PyEval_RestoreThread etc. are harmful

2021-01-21 Thread Alexey Izbyshev


Change by Alexey Izbyshev :


--
nosy: +izbyshev

___
Python tracker 

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



[issue42888] Not installed “libgcc_s.so.1” causes exit crash.

2021-01-21 Thread Alexey Izbyshev


Alexey Izbyshev  added the comment:

Thank you for testing. I've added a NEWS entry to the PR, so it's ready for 
review by the core devs.

Note that PyThread_exit_thread() can still be called by daemon threads if they 
try to take the GIL after Py_Finalize(), and also via C APIs like 
PyEval_RestoreThreads() (see bpo-42969), so, in general, libgcc_s is still 
required for CPython.

--
versions: +Python 3.8, Python 3.9

___
Python tracker 

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



[issue42514] Relocatable framework for macOS

2021-01-21 Thread Tom Goddard


Change by Tom Goddard :


--
nosy: +tomgoddard

___
Python tracker 

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



[issue33289] tkinter askcolor returning floats for r, g, b values instead of ints

2021-01-21 Thread Terry J. Reedy


Terry J. Reedy  added the comment:

Your Linux result is the same as on Windows. Given strings 'abc' or 'abcd', 
ignore 'c' or 'cd' and expand 'ab' to 'abab', making value 0xabab.  Is your 
computer Ubuntu (implying that personal Ubuntu != CI Ubuntu) or a different 
Linux?  Are there tk/tcl compilation flags or X window options that could 
affect stored color values?

--

___
Python tracker 

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



[issue33289] tkinter askcolor returning floats for r, g, b values instead of ints

2021-01-21 Thread Serhiy Storchaka


Serhiy Storchaka  added the comment:

I do not understand why #abc00 and #abcd give 0xabab on my computer 
(Linux) and even weirder result on Ubuntu on CI. Reading the code I expected 
the same behavior as on macOS.

--

___
Python tracker 

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



[issue42606] Support POSIX atomicity guarantee of O_APPEND on Windows

2021-01-21 Thread Alexey Izbyshev


Alexey Izbyshev  added the comment:

> It's possible to query the granted access of a kernel handle via 
> NtQueryObject: ObjectBasicInformation

Ah, thanks for the info. But it wouldn't help for option (1) that I had in mind 
because open() and os.open() currently set only msvcrt-level O_APPEND.

It probably could be used in my current PR instead of just assuming the default 
access rights for file handles, but I'm not sure whether it makes sense: can a 
new handle have non-default access rights? Or can the default change at this 
point of Windows history?

> Python could implement its own umask value in Windows. os.umask() would set 
> the C umask value as well, but only for the sake of consistency with C 
> extensions and embedding.

Would it be a long shot to ask MS to add the needed functionality to MSVCRT 
instead? Or at least to declare the bug with _umask_s() that I described a 
feature. Maybe Steve Dower could help.

> Open attribute flags could also be supported, such as O_ATTR_HIDDEN and 
> O_ATTR_SYSTEM. These are needed because a hidden or system file is required 
> to remain as such when it's overwritten, else CreateFileW fails.

I didn't know that, thanks. Indeed, a simple open(path, 'w') fails on a hidden 
file with "Permission denied".

> If it's important enough, msvcrt.open() and msvcrt.O_TEXT could be provided.

Yes, I'd be glad to move support for more obscure MSVCRT flags to msvcrt.open() 
-- the less MSVCRT details we leak in os.open(), the more freedom we have to 
implement it via proper Win32 APIs.

===

Anyway, even if the blockers for implementing open()/os.open() via CreateFile() 
are solved, my current PR doesn't seem to conflict with such an implementation 
(it could just be replaced in the future).

Currently, the only way to achieve atomic append in Python on Windows that I 
know is to use a custom opener that would call CreateFile() with the right 
arguments via ctypes/pywin32/etc.

--

___
Python tracker 

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



[issue42988] Information disclosure via pydoc -p: /getfile?key=path allows to read arbitrary file on the filesystem

2021-01-21 Thread Ken Jin


Ken Jin  added the comment:

I created a PR to remove the getfile function - now it just places the 
hyperlinked file path there but clicking on it won't render the file contents.

Personally I agree with Marc-Andre Lemburg's comments on how _url_handler 
probably has other vulnerabilities somewhere. But I don't really see an easy 
solution other than removing the web server altogether. It uses http.server, 
which has a disclaimer on the docs page saying it isn't recommended for 
production. Someone looking hard enough can probably find a few more 
vulnerabilities in http.server itself rather than just pydoc.

I think the "Allowlist populated while generating links" suggested by Julien is 
pretty clever. 

I thought about file: // approach too - it's probably the most secure. But it 
would require a lot of change (and also generating all the .py files to .html 
initially).

Maybe I'll make a PR exploring the other approaches if the current one isn't 
favorable.

Thanks for your time.

--

___
Python tracker 

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



[issue33289] tkinter askcolor returning floats for r, g, b values instead of ints

2021-01-21 Thread Terry J. Reedy


Terry J. Reedy  added the comment:

65535 = 35536 - 1 = 256 * 256 - 1 == 255 * 257

On Windows, each r, g, b value is n * 257 for n in range(256) (see attached 
file).  The precision loss happens when colors are stored, before the division 
in winfo_rgb.  Perhaps 8 bits/channel (including alpha) is baked in.

Since divmod(n * 257, 257) = (n, 0) and divmod(n * 257, 256) = (n, n),
(n*257) // m = divmod(n*257, m)[0] = n whether m is 256 or 257.
---

macOS appears (from limited experiments) to handle 1 and 2 digits the same as 
Windows (repeat 4 or 2 times): val('#a00') = val('#') = 0x, 
val('#ab') = val('#abab') = 0xabab.  4 digits are left alone while 
3 digits use the 1st as the 4th val('#abc00') = val('#abca') = 
0xabca.

--
Added file: https://bugs.python.org/file49756/tk_rgb.py

___
Python tracker 

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



[issue42988] Information disclosure via pydoc -p: /getfile?key=path allows to read arbitrary file on the filesystem

2021-01-21 Thread Ken Jin


Change by Ken Jin :


--
keywords: +patch
nosy: +kj
nosy_count: 4.0 -> 5.0
pull_requests: +23104
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24285

___
Python tracker 

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



[issue42966] argparse: customizable help formatter

2021-01-21 Thread hai shi


Change by hai shi :


--
nosy: +paul.j3, rhettinger

___
Python tracker 

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



[issue42035] [C API] PyType_GetSlot cannot get tp_name

2021-01-21 Thread hai shi


hai shi  added the comment:

Wait. petr mentioned `_PyType_Name` in PR 23903 which use the short name. So I 
am not sure which way is better. Lol~

--

___
Python tracker 

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



[issue42990] Improve the C code for calling Python code

2021-01-21 Thread Mark Shannon


New submission from Mark Shannon :

Currently, to make a call to Python (modules, classes, etc, not just functions) 
from C has to use the monster that is `_PyEval_EvalCode`.
As Python has adding features over the years, _PyEval_EvalCode has grown and 
grown. It is time for a refactor.

`_PyEval_EvalCode` takes 16, yes sixteen parameters!
Those 16 parameters fall into two main groups, one describing the function 
being called, and the other describing the arguments to the call.
Due to the jumbo size and complexity of _PyEval_EvalCode, we also have 
specialised forms of it, e.g. _PyFunction_Vectorcall that handle common cases 
and then bail to _PyEval_EvalCode in other cases.

In outline _PyEval_EvalCode performs the following actions:
1. Make a new frame.
2. Fill in that frame using the arguments and defaults provided.
3. If the code object has flags set for a generator, or coroutine, return a new 
generator or coroutine.
4. Otherwise call the interpreter with the newly created frame.

As _PyEval_EvalCode or its earlier equivalents have gained arguments, they have 
a left of list of legacy functions. It is not clear what is the "correct" 
function to use in C extensions. Hopefully extension code uses the 
`PyObject_Call` API, but `PyEval_EvalCodeEx` is part of the C-API.


To improve this situation, I propose:

A new C struct, the "frame descriptor" which contains the code object, 
defaults, globals, and names that describe the code to be executed. 
`PyFunctionObject` would wrap this, to simplify the common case of calling a 
Python function. 

Split the Eval functions into vector and tuple/dict forms, both forms taking a 
"frame descriptor", as well as the arguments.

Mark the older forms of the Eval functions as "legacy", creating a local "frame 
descriptor" and transforming the arguments in vector or tuple/dict forms, in 
the legacy functions.

Factor out the frame creation part of the Eval functions.


The above changes will be necessary for PEP 651, but I think would be a 
worthwhile improvement even if PEP 651 is not accepted.

--
assignee: Mark.Shannon
components: Interpreter Core
messages: 385432
nosy: Mark.Shannon
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve the C code for calling Python code

___
Python tracker 

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



[issue42989] Bug

2021-01-21 Thread Zachary Ware


Zachary Ware  added the comment:

That line on its own will cause an IndentationError, which is a subclass of 
SyntaxError.  However, out of context, without the full traceback, and without 
a description of your environment, the only thing I have to go on here is the 
fact that the vast majority of syntax errors are problems in user code, not 
Python itself.  This is not a forum for getting help with your own program, but 
you can try out discuss.python.org or the python-l...@python.org mailing list 
for that.

--
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



[issue1375011] http.cookies, Cookie.py: Improper handling of duplicate cookies

2021-01-21 Thread Christoph Zwerschke


Christoph Zwerschke  added the comment:

This patch should really be included.

As carl already mentioned, the relevant spec is RFC 6265, see section 5.4.2: 
"The user agent SHOULD sort the cookie-list in the following order: Cookies 
with longer paths are listed before cookies with shorter paths. Among cookies 
that have equal-length path fields, cookies with earlier creation-times are 
listed before cookies with later creation-times."

Currently, if the cookies are loaded with cookies.load(env['HTTP_COOKIE']) as 
most web frameworks do, then the cookies will be populated with the least 
specific or oldest values if there are duplicates. This is really bad.

--
nosy: +cito

___
Python tracker 

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



[issue42800] Traceback objects allow accessing frame objects without triggering audit hooks

2021-01-21 Thread Mark Shannon


Mark Shannon  added the comment:

If the point of the proposed change is not to deny access to globals, then what 
is the point of it?

You say that this change is to "close a simpler gap in the audit system".
What it is that the audit system is supposed to prevent, that is currently 
possible, and that your proposed change would prevent?

I'm worried that we end up adding more and more hooks. Performance and 
maintainability will suffer.

--

___
Python tracker 

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



[issue42985] AMD64 Arch Linux Asan 3.x fails: command timed out: 1200 seconds without output

2021-01-21 Thread Senthil Kumaran


Senthil Kumaran  added the comment:

> IMO we should disable ASAN (handling of signals) at runtime when we trigger a 
> crash on purpose (ex: faulthandler._sigsegv()).

> ASAN_OPTIONS="handle_segv=0".

Both sound reasonable. But not sure if they will resolve this crash tough.

--
nosy: +orsenthil

___
Python tracker 

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



[issue42989] Bug

2021-01-21 Thread Andrew C


New submission from Andrew C :

if playerChoice == "2": reports the ":" as a "syntax error"

--
components: Windows
messages: 385427
nosy: ASCRong, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Bug
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



[issue42977] Tkinter Optionmenu Too Narrow on Mac

2021-01-21 Thread E. Paine


E. Paine  added the comment:

I suspect this is just a MacOS behaviour, if not then it is a Tk bug. If you 
really need to enforce the width, you could tell it to expand horizontally in 
the layout. An example of this would be as follows:

tk.Frame(root, height=1, width=300).pack()
tk.OptionMenu(root, tk.StringVar(), "test").pack(fill="x")

A bit more detail on the Tk side of things:
tkinter doesn't actually use `tk_optionMenu` and instead creates its own 
menubutton and menu. The issue with the menubutton width not changing also 
exists when working directly with Tk (`pack [menubutton .p -width 100]`). 
However, the same behaviour can be shown when using `tk_optionMenu`, so 
changing tkinter to use that instead would not fix this issue.

--
nosy: +epaine, serhiy.storchaka

___
Python tracker 

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



[issue42800] Traceback objects allow accessing frame objects without triggering audit hooks

2021-01-21 Thread Ryan Hileman


Ryan Hileman  added the comment:

My personal motivation is not to unilaterally prevent access to globals, but to 
close a simpler gap in the audit system that affects a currently deployed high 
performance production system (which is not trying to be a sandbox). I am also 
already using a C audit hook for my purposes.

If you are referencing vstinner's first message, please remember to read their 
follow up https://bugs.python.org/msg384988 where they seem to have changed 
their mind in support of the patch.

The audit attributes I'm chasing here are fairly small in scope, and 
overwhelmingly only used in debug code. I believe adding them is in the spirit 
of the original PEP. I have also done extensive testing and CPython C and 
stdlib code analysis as part of this effort.

If you agree with the original PEP authors that __code__ and sys._getframe() 
are worth auditing, then I believe this is a natural extension of that concept. 
My patch improves upon the PEP by increasing the audit coverage to every way I 
can see of getting a frame and code object from basic CPython types.

This is a simple patch with clear performance metrics. I don't see any reason 
to expand the scope of this in the future unless CPython adds another basic 
object type along the same lines (e.g. a new async function type, a new 
traceback type, or a new frame type).

--

___
Python tracker 

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



[issue42911] Addition chains for pow saves 5-20% time for pow(int, int)

2021-01-21 Thread Jurjen N.E. Bos


Jurjen N.E. Bos  added the comment:

...not to mention the new gcd and lcm functions, and the fact that the number 
conversion is linear for exponent-of-two bases, and the negative power modulo a 
prime number!

--

___
Python tracker 

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



[issue42911] Addition chains for pow saves 5-20% time for pow(int, int)

2021-01-21 Thread Jurjen N.E. Bos


Jurjen N.E. Bos  added the comment:

Well, I would argue that there is already quite a work going to for 
crypto-sized computations in the integer code, as well as the crypto-oriented 
.bit_count() function that was recently added.

For starters, the arguably crypto-oriented three argument pow() was there from 
Python 0.1 already, where I used it :-).
There's Karatsuba multiplication, five-ary powering, and quite a few 
optimizations on the speed of the number conversion.

And then of course the incredible implementation of Decimal, which does include 
a subquadratic division. I would say this would fit there.

And maybe I'll make a subquadratic division for ints someday...

Tim, your vote please...

--

___
Python tracker 

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



[issue42988] Information disclosure via pydoc -p: /getfile?key=path allows to read arbitrary file on the filesystem

2021-01-21 Thread STINNER Victor


STINNER Victor  added the comment:

The getfile feature is used to display the source code of a Python module.

For example, on the difflib documentation, there a link to difflib.py. If you 
click, a webpage displays the content of the file.

I suggest to remove the whole feature. I don't think that it's so useful, 
compared to the vulnerability.

--

___
Python tracker 

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



[issue42988] Information disclosure via pydoc -p: /getfile?key=path allows to read arbitrary file on the filesystem

2021-01-21 Thread STINNER Victor


STINNER Victor  added the comment:

An option is also to remove the whole getfile feature. It was added in bpo-2001 
by:

commit 7bb30b72d8a165f8bacbc480b8d5a15834fa4c35
Author: Nick Coghlan 
Date:   Fri Dec 3 09:29:11 2010 +

Improve Pydoc interactive browsing (#2001).  Patch by Ron Adam.

* A -b option to start an enhanced browsing session.
* Allow -b and -p options to be used together.
* Specifying port 0 will pick an arbitrary unused socket port.
* A new browse() function to start the new server and browser.
* Show Python version information in the header.
* A *Get* field which takes the same input as the help() function.
* A *Search* field which replaces the Tkinter search box.
* Links to *Module Index*, *Topics*, and *Keywords*.
* Improved source file viewing.
* An HTMLDoc.filelink() method.
* The -g option and the gui() and serve() functions are deprecated.

--

___
Python tracker 

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



[issue42988] Information disclosure via pydoc -p: /getfile?key=path allows to read arbitrary file on the filesystem

2021-01-21 Thread STINNER Victor


STINNER Victor  added the comment:

I searched for "pydoc by Ka-Ping Yee" in Google and only found two online pydoc 
services:

* https://gae-pydoc.appspot.com/
* 
http://www.cc.kyoto-su.ac.jp/~atsushi/Programs/VisualWorks/CSV2HTML/CSV2HTML_PyDoc/index_of_modules.html

The first one runs on Python 2.7 which doesn't have the getfile feature (added 
in Python 3.6), the second one is a static website.

=> there is no public vulnerable website: good!

I don't think that pydoc is commonly used to run a server on the Internet.

--
title: Information disclosure via pydoc -p -> Information disclosure via pydoc 
-p: /getfile?key=path allows to read arbitrary file on the filesystem

___
Python tracker 

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



[issue42985] AMD64 Arch Linux Asan 3.x fails: command timed out: 1200 seconds without output

2021-01-21 Thread STINNER Victor


STINNER Victor  added the comment:

Documentation of ASAN_OPTIONS:
https://github.com/google/sanitizers/wiki/SanitizerCommonFlags
https://github.com/google/sanitizers/wiki/AddressSanitizerFlags

--

___
Python tracker 

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



[issue42985] AMD64 Arch Linux Asan 3.x fails: command timed out: 1200 seconds without output

2021-01-21 Thread STINNER Victor


STINNER Victor  added the comment:

About SIGSEGV logs, one option is to use ASAN_OPTIONS="handle_segv=0".

--

___
Python tracker 

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



[issue42988] Information disclosure via pydoc -p

2021-01-21 Thread Marc-Andre Lemburg


Marc-Andre Lemburg  added the comment:

Looking at the _url_handler() code in pydoc.py, this was clearly not written 
with web server standards in mind. None of the handlers apply security checks 
on the user input and there are most likely several other vulnerabilities in 
there to be found.

It's not just the getfile query allowing reading arbitrary files. The user may 
well have code in his or her Python installation which is not meant to be 
published to other users on the same server.

I'd suggest to print a big warning on the console, explaining that the web 
server will potentially make all content accessible by the user visible to 
anyone else on the same server.

Perhaps adding some extra check to the html_getfile() handler would be good as 
well, making sure that the path is on sys.path and maps to a Python file (there 
could be non-Python file resources in package dirs as well).

Alternatively, perhaps the whole getfile logic could be removed and the web 
server just provide the path to the source file (as file:// link), so that the 
user can easily open it, but needs access permissions for this to be successful.

--
nosy: +lemburg

___
Python tracker 

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



[issue42985] AMD64 Arch Linux Asan 3.x fails: command timed out: 1200 seconds without output

2021-01-21 Thread STINNER Victor


STINNER Victor  added the comment:

It seems like something changed on the buildbot, not in Python, since it also 
fails on 3.8 and 3.9.

AMD64 Arch Linux Asan 3.9:
https://buildbot.python.org/all/#builders/579/builds/105

AMD64 Arch Linux Asan 3.8:
https://buildbot.python.org/all/#builders/580/builds/86

IMO we should disable ASAN (handling of signals) at runtime when we trigger a 
crash on purpose (ex: faulthandler._sigsegv()).

--

___
Python tracker 

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



[issue42988] Information disclosure via pydoc -p

2021-01-21 Thread STINNER Victor


STINNER Victor  added the comment:

Downstream Fedora issue: https://bugzilla.redhat.com/show_bug.cgi?id=1917807

--

___
Python tracker 

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



[issue42988] Information disclosure via pydoc -p

2021-01-21 Thread STINNER Victor


Change by STINNER Victor :


--
nosy: +vstinner

___
Python tracker 

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



[issue42955] Add sys.module_names: list of stdlib module names (Python and extension modules)

2021-01-21 Thread hai shi


Change by hai shi :


--
nosy: +shihai1991

___
Python tracker 

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



[issue42780] os.set_inheritable() fails for O_PATH file descriptors on Linux

2021-01-21 Thread cptpcrd


cptpcrd  added the comment:

No problem! I've noticed at least one other (relatively minor) issue in `os`, 
so I may be submitting further bug reports.

I haven't been keeping close track of 3.6/3.7's status, so I added them in 
without thinking it. Thanks for the reminder.

--

___
Python tracker 

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



[issue42988] Information disclosure via pydoc -p

2021-01-21 Thread Julien Palard


Julien Palard  added the comment:

Nice find! I am able to reproduce it too in many Python releases.

I see differnt ways we can fix it:


# Using a random secret generated at startup time

Used any way, like by providing an hmac on getfile urls to ensure they are 
signed with the server secret.

Con: getfile URLS won't work from a run to another run (the secret should be 
random and changed at every start), and can't be shared (do someone share them 
in the first place?)


# Allowlist according to sys.path

In getfile implementation, we can check if the asked path is under a path from 
sys.path.

Con: If someone have ~/ in sys.path, we still can access all its home, or if 
someone start it using `python -m pydoc` while being in its home directory as 
Python will prepend the cwd in sys.path.


# Allowlist populated while generating links

Idea is: each time the server generates a getfile link, the target is added to 
an allowlist.

Each time a getfile link is requested, if the file is not in the allowlist, 
request is denied.

Con: Refreshing a page won't work after a server restart (thus having an empty 
allowlist).


# fnmatch allowlist

We could allow only `.py` files.

Con: Secrets stored in `.py` files under user project could still be leaked.


-

My personal preference goes for the allowlist populated while generating links.

--
nosy: +mdk

___
Python tracker 

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



[issue42988] Information disclosure via pydoc -p

2021-01-21 Thread Miro Hrončok

New submission from Miro Hrončok :

Hello Python security,
a Fedora user has reported the following security vulnerability to us (I was 
able to verify it):

Running `pydoc -p` allows other local users to extract arbitrary files.

Steps to Reproduce:
1. start pydoc on a port
2. as a different user guess or extract the port
3. call getfile on the server to extract arbitrary files, e.g. 
http://localhost:/getfile?key=/home/dave/.ssh/id_rsa

Actual results:
any local user on the multi-user system can read all my keys and secrets

Expected results:
Access is prevented.

Additional info:
At least a warning should be printed, that this is insecure on multi-user 
systems.

Python notebook works around this by providing a token that is required to 
access the notepad. Depending on the system being able to read arbitrary files 
can allow to impersonate my, by  e.g. stealing my ssh-key (if it is 
non-encrypted) 



I've originally reported this to secur...@python.org but I was asked to open a 
public issue here.

--
components: Library (Lib)
messages: 385412
nosy: hroncok
priority: normal
severity: normal
status: open
title: Information disclosure via pydoc -p
type: security
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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



[issue41545] gc API requiring matching number of gc.disable - gc.enable calls

2021-01-21 Thread Yonatan Goldschmidt


Yonatan Goldschmidt  added the comment:

Dennis, you're right. I guess I missed it when I previously searched for 
matching issues. https://bugs.python.org/issue31356 indeed solves my problem. 
Closing this as a duplicate.

--
resolution:  -> duplicate
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



[issue42800] Traceback objects allow accessing frame objects without triggering audit hooks

2021-01-21 Thread Mark Shannon


Mark Shannon  added the comment:

I agree with Victor, we should not be attempting to build a sandbox.
https://www.python.org/dev/peps/pep-0578/#why-not-a-sandbox

Preventing access to global variables is next to impossible. Adding more and 
more hooks to prevent access to globals, merely adds the illusion of security. 
Sooner or later, someone will find a path to globals that would have a serious 
impact on performance to block.

We should assume that globals are accessible from user code, and write the 
audit function accordingly. Either in C or using a closure.

--
nosy: +Mark.Shannon

___
Python tracker 

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



[issue42752] multiprocessing Queue leaks a file descriptor associated with the pipe writer (#33081 still a problem)

2021-01-21 Thread mattip


Change by mattip :


--
nosy: +davin, pitrou

___
Python tracker 

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



  1   2   >