Python 3.5.5 repairs an import path security regression

A Python application can execute the intended entry point and still load code from an unintended directory. The distinction matters for privileged processes, where an import search path can cross a trust boundary before the application reaches its own access checks. Python 3.5.5 includes a repair for exactly that kind of regression in interpreter startup.

The release page explains that the 3.5 branch has entered security-fix-only maintenance and that this release provides source code without official binary installers. Its descriptive text dates the release to February 4, matching the final release changelog in the source tree. The final contains no new changes beyond its release candidate. The small version increment therefore carries both a security correction and a change in the branch's distribution arrangements.

I choose Python largely because of the libraries available around it, while finding its packaging arrangements frustrating. A source-only interpreter release makes that reservation concrete. An upstream fix exists, but the route from that fix to an installed runtime depends on whoever builds and distributes that runtime.

Import locations have different meanings

The command-line documentation shipped with 3.5.5 distinguishes a source-file argument from a directory or zipfile argument. A source-file invocation puts the file's containing directory at the beginning of sys.path. A directory or zipfile invocation instead puts the named import location there and executes its __main__.py.

python3.5 /opt/example/application.py
python3.5 /opt/example/application
python3.5 /opt/example/application.pyz

These represent different packaging arrangements. In the first, the script lives inside a directory that can also contain imported modules. In the other forms, the directory or archive is itself the location from which Python obtains the entry point. The enclosing directory is a separate place and need not belong in the application's import search path.

The release candidate changelog included in 3.5.5 describes bpo-32551. An earlier sys.path[0] initialization change exposed an inconsistency when running __main__ from a zipfile, directory or another import location. The regression could cause a privileged process to load code from user-controlled directories in circumstances where it had not done so before.

The correction prevents the import location's parent directory from being added during this initialization. It also prevents inadvertent modification of other search-path entries when inserting the location named on the command line. Both details matter. Repairing the first entry must preserve the rest of the search path, since otherwise a startup fix can change which modules resolve elsewhere.

Startup behaviour is part of application security

The failure is especially instructive because it concerns the relationship between two legitimate interpreter behaviours. Python supports executable archives and directories. It also initializes a module search path before running application code. Their interaction must preserve the difference between the application container and its parent directory.

An absolute path to an entry point describes where execution begins. It does not, by itself, describe every location from which later imports may obtain code. The changelog's privileged-process example shows why an application review has to account for startup semantics as well as the entry point's ownership. This is a consequence of the reported regression, rather than a claim that every directory or zip application is exploitable.

Python 3.5 already offers isolated mode. The version's command-line documentation says -I excludes the script directory and user site-packages directory from sys.path, and ignores Python environment variables. That is a broader execution choice than repairing an unintended parent-directory entry. The update corrects the ordinary startup behaviour; isolated mode expresses an additional policy about which ambient inputs an invocation accepts.

That difference also affects compatibility. Applications that intentionally import neighbouring code have assumptions about their launch arrangement. An isolated invocation can reject those assumptions. The security fix has the narrower purpose of restoring the intended import-location handling without asking every application to change its launch policy.

Native components remain relevant to the patch

The same candidate changelog records an integer-overflow correction in PyBytes_DecodeEscape, identified as CVE-2017-1000158. It also records updates to the embedded Expat library. One update obtains security fixes, while another repairs copying of partial UTF-8 characters. These entries concern lower-level interpreter and parser code, so a patch's relevance is not confined to visible changes in Python syntax.

The changelog identifies the embedded copy specifically. That qualification matters when discussing what the upstream source contains. A distributor's build choices determine the exact runtime it delivers, and the upstream notes alone do not establish the composition of every installed interpreter. The release is a concrete source update, not evidence about an arbitrary machine's package state.

My judgement is that maintaining an older interpreter branch requires this distribution detail to remain explicit. The 3.5.5 announcement supplies no new official binary installers. For users of packaged Python, the party delivering their package must turn the upstream source corrections into the runtime they actually execute. The import-path repair gives that work a specific behavioural target, the removal of an unintended parent directory during startup from an import location.