anandbhat | 29 Jun 05:50 2016

[issue27410] DLL hijacking vulnerability in Python 3.5.2 installer


New submission from anandbhat:

The Python 3.5.2 Windows x86-64 executable installer (MD5: 4da6dbc8e43e2249a0892d257e977291)
downloaded from https://www.python.org/ftp/python/3.5.2/python-3.5.2-amd64.exe is vulnerable
to DLL hijacking.

The installer attempts to load DLLs from the current directory, which in most cases, is the Downloads
directory. As explained in
http://blog.opensecurityresearch.com/2014/01/unsafe-dll-loading-vulnerabilities.html and
https://textslashplain.com/2015/12/18/dll-hijacking-just-wont-die/, installers that are
vulnerable to DLL hijacking can be used to load untrusted and malicious DLLs. A maliciously crafted DLL
when dropped into the user's Downloads directory will be executed by this installer.

System used for testing: Windows 10

Steps to reproduce:

1. Download a dummy DLL file for this demo -- version.dll -- from
https://www.dropbox.com/s/3l5qwz7ppevs9za/version.dll?dl=0 and place it in the default Downloads
directory. Virustotal report for this file: https://www.virustotal.com/en/file/29b51fdb8e498ef5d3fe05e924e23fcaffa554d64fb024b042101236028242b0/analysis/1467171188/

2. Download the Python 3.5.2 Windows x86-64 executable installer (MD5:
4da6dbc8e43e2249a0892d257e977291) from
https://www.python.org/ftp/python/3.5.2/python-3.5.2-amd64.exe and save it to the default
Downloads directory (e.g., C:\Users\xxx\Downloads)

3. Attempt to run the downloaded installer.

4. Windows loads version.dll placed in step [1]. This is just one of several DLLs that can be exploited.
(Continue reading)

Martin Panter | 29 Jun 04:54 2016

[issue27409] List socket.SO_*, SCM_*, MSG_*, IPPROTO_* symbols


New submission from Martin Panter:

The documentation just says that SO_* etc constants are defined. However when people add new ones, they add
them as new features to a specific version (not backported as bug fixes), but do not alter the
documentation at all. IMO it is silly adding undocumented features. E.g. Issue 26907 was opened to add
(among others) SO_PASSCRED, which was already added, undocumented, as part of Issue 6560.

This patch attempts to indicate which symbols are defined by Python (depending on OS availability), and
therefore one can deduce if Python does not define a particular symbol. It could be adapted to the 2.7
documentation, but I am not really motivated for that on my own.

I also remove a redundant definition in the module, and removed a conditional because SO_REUSEADDR is
required to always be defined according to the test suite. These specific changes should only be applied
to 3.6.

I also found Issue 1732367, which has a patch documenting each AF_* symbol in a little more detail. That
patch was never updated nor comitted, but it sounds like this kind of addition might be acceptable.

----------
assignee: docs <at> python
components: Documentation
files: socket-const.patch
keywords: patch
messages: 269460
nosy: docs <at> python, martin.panter
priority: normal
severity: normal
stage: patch review
status: open
(Continue reading)

Martin Panter | 29 Jun 04:45 2016

[issue1732367] Document the constants in the socket module


Martin Panter added the comment:

Reopening because the consensus seems to be to update and apply this sort of change.

----------
nosy: +martin.panter
stage:  -> needs patch
status: closed -> open

_______________________________________
Python tracker <report <at> bugs.python.org>
<http://bugs.python.org/issue1732367>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/python-python-bugs-list%40m.gmane.org

Brett Cannon | 29 Jun 04:22 2016

[issue27408] Document importlib.abc.ExecutionLoader implements get_data()


New submission from Brett Cannon:

The fact that importlib.abc.ExectionLoader.get_data() is implemented is missing (or put another way,
it isn't documented that get_source() still needs to be implemented).

----------
assignee: docs <at> python
components: Documentation
messages: 269458
nosy: brett.cannon, docs <at> python
priority: normal
severity: normal
stage: needs patch
status: open
title: Document importlib.abc.ExecutionLoader implements get_data()
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report <at> bugs.python.org>
<http://bugs.python.org/issue27408>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/python-python-bugs-list%40m.gmane.org

George Ge | 28 Jun 17:51 2016

[issue27407] prepare_ssl.py missing in PCBuild folder


New submission from George Ge:

The readme.txt file in the PCBuild folder in Python 2.7.11 and 2.7.12 sources both contain instructions on
how to configure to build a different OpenSSL version using PCbuild\prepare_ssl.py, but this file is
missing on both versions.

----------
components: Installation, Windows
messages: 269440
nosy: George Ge, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: prepare_ssl.py missing in PCBuild folder
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report <at> bugs.python.org>
<http://bugs.python.org/issue27407>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/python-python-bugs-list%40m.gmane.org

Kristján Valur Jónsson | 28 Jun 16:09 2016

[issue27406] subprocess.Popen() hangs in multi-threaded code


New submission from Kristján Valur Jónsson:

On a quad-core raspberrypi, i have experienced that subprocess.Popen() sometimes does not return
immediatelly, but only much later, when an unrelated process has exited.
Debugging the issue, I find the parent process hanging in 
                # Wait for exec to fail or succeed; possibly raising exception
                # Exception limited to 1M
                data = _eintr_retry_call(os.read, errpipe_read, 1048576)

This behaviour is consistent with the problem described in pipe_cloexec():

def pipe_cloexec(self):
            """Create a pipe with FDs set CLOEXEC."""
            # Pipes' FDs are set CLOEXEC by default because we don't want them
            # to be inherited by other subprocesses: the CLOEXEC flag is removed
            # from the child's FDs by _dup2(), between fork() and exec().
            # This is not atomic: we would need the pipe2() syscall for that.
            r, w = os.pipe()
            self._set_cloexec_flag(r)
            self._set_cloexec_flag(w)
            return r, w

In short:  It appears that occasionally the pipe FD is leaked to a different subprocess (started on a
separate thread) before the cloexec flags can be set.  This causes the parent process to wait until that
other instance of the file descriptor is closed, i.e. when that other unrelated process exits.

I currently have a workaround which involves using a threading.Lock() around the call.

This is not very nice, however.  Also, there is #Issue12196 which could be backported to 2.7 to address this problem.
(Continue reading)

Serhiy Storchaka | 28 Jun 10:06 2016

[issue27405] Ability to trace Tcl commands executed by Tkinter


New submission from Serhiy Storchaka:

For debugging purpose it would be helpful to have an ability to show all Tcl commands executed by Tkinter. In
particular it would be helpful for testing wherever some issue is Tkinter issue or Tcl/Tk issue.

I'm working on a patch, but there is a design question about an interface.

In simplest case you set the debug property of Tk instance to True and all Tcl commands are printed to stdout
or stderr in the form ready for executing with Tcl/Tk interpreter. You also can set the module global
tkinter.debug to True, and this will affect all new Tk instances (as with tkinter.wantobjects).

But maybe there is a need in larger customization? For example specifying the command that accepts every
Tcl command as a string or a tuple?

----------
components: Tkinter
messages: 269425
nosy: serhiy.storchaka, terry.reedy
priority: normal
severity: normal
status: open
title: Ability to trace Tcl commands executed by Tkinter
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report <at> bugs.python.org>
<http://bugs.python.org/issue27405>
_______________________________________
(Continue reading)

STINNER Victor | 27 Jun 23:14 2016

[issue27404] Misc/NEWS: add [Security] prefix to Python 3.5.2 changelog


New submission from STINNER Victor:

As discussed on the Security-SIG mailing list, changes related to security should be prefixed by [Security]:

https://mail.python.org/pipermail/security-sig/2016-June/000003.html

Here is a first patch for Python 3.5.2 (and the future 3.5.3) changelog.

----------
files: NEWS.patch
keywords: patch
messages: 269405
nosy: haypo
priority: normal
severity: normal
status: open
title: Misc/NEWS: add [Security] prefix to Python 3.5.2 changelog
type: security
versions: Python 3.5
Added file: http://bugs.python.org/file43568/NEWS.patch

_______________________________________
Python tracker <report <at> bugs.python.org>
<http://bugs.python.org/issue27404>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/python-python-bugs-list%40m.gmane.org

(Continue reading)

Dustin Oprea | 27 Jun 23:03 2016

[issue27403] os.path.dirname doesn't handle Windows' URNs correctly


New submission from Dustin Oprea:

Notice that os.path.dirname() returns whatever it is given if it is given a URN, regardless of slash-type.
Oddly, you have to double-up the forward-slashes (like you're escaping them) in order to get the correct
result (if you're using forward-slashes). Back-slashes appear to be broken no matter what.

C:\Python35-32>python
Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:01:18) [MSC v.1900 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os.path
>>> os.path.dirname("\\\\a\\b")
'\\\\a\\b'
>>> os.path.dirname("//a/b")
'//a/b'
>>> os.path.dirname("////a//b")
'////a'

Any ideas?

----------
components: Windows
messages: 269404
nosy: Dustin.Oprea, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.path.dirname doesn't handle Windows' URNs correctly
type: behavior
versions: Python 2.7, Python 3.5
(Continue reading)

Michael Lee | 27 Jun 19:09 2016

[issue27402] Sequence example in typing module documentation does not typecheck


New submission from Michael Lee:

In the documentation for the `typing` module, the [entry for the `List` type][0] uses the following
example to help demonstrate when to use `Sequence` vs `List`:

    T = TypeVar('T', int, float)

    def vec2(x: T, y: T) -> List[T]:
        return [x, y]

    def slice__to_4(vector: Sequence[T]) -> List[T]:
        return vector[0:4]

However, the `slice__to_4` function does not actually typecheck since there's no guarantee that a slice
of a sequence will return a `List`. For example the vector could be a numpy array or a custom subclass of
`collections.abc.Sequence` with an unusual `__getitem__`. (Mypy correctly catches this error and
complains about an "Incompatible return value type").

The documentation should probably be updated to use an example that _does_ typecheck, though I'm not sure
what exactly that example might look like? Maybe replace `slice__to_4` with something like this?

    def keep_positives(vector: Sequence[T]) -> List[T]:
        return [item for item in vector if item > 0]

----------
assignee: docs <at> python
components: Documentation
messages: 269389
nosy: docs <at> python, michael0x2a
(Continue reading)

Jarod Brennfleck | 27 Jun 17:57 2016

[issue27401] Wrong FTP links in 5.3.2 installer


New submission from Jarod Brennfleck:

So far, the only installers tested is the Python 5.3.2 x86 and x86_64 installers.

When selecting customise install, the installer is unable to gather the files required, because the
installer is looking for them in:
https://www.python.org/ftp/python/3.5.2/amd64/

Following the link will result in a 404, as the folder does not exist. This reason has been found thanks to the
log file of the installation that is given upon error during the installation. (Cheers for that! :D)

The correct link is:
https://www.python.org/ftp/python/3.5.2/amd64rc1/

----------
components: Installation
messages: 269383
nosy: Jarod Brennfleck
priority: normal
severity: normal
status: open
title: Wrong FTP links in 5.3.2 installer
type: crash
versions: Python 3.5

_______________________________________
Python tracker <report <at> bugs.python.org>
<http://bugs.python.org/issue27401>
_______________________________________
(Continue reading)


Gmane