Python 3.5.8rc1 updates security fixes on the older branch

Security maintenance on an older interpreter is partly about preserving boundaries that application code already assumes. A parser should not accept a misleading portion of an invalid address, and a malformed header should not keep a process parsing forever. Python 3.5.8rc1 brings fixes for both cases to the older release branch.

The release candidate is dated September 9, 2019. Its release page explains that Python 3.5 is in security-fixes-only mode and that this candidate is distributed as source. The distinction matters to anyone expecting an ordinary binary installer or the broader changes of a feature release.

The candidate's versioned notes list email parsing corrections alongside URL security fixes. This is a preview of a security maintenance update. The useful story is what those backports change for programs that continue to depend on the 3.5 branch.

I am interested in that maintenance work because Python's libraries are often the reason to accept the language's operational complexity. Dependence on the ecosystem includes dependence on its older runtime contracts. Security fixes need to reach those contracts without requiring an unrelated application rewrite just to understand the change.

Invalid addresses should not become plausible prefixes

The notes describe bpo-34155 as a correction for email addresses containing more than one at sign. Their example is a@b@c.com. The earlier behavior could return the portion before the second at sign as though it were a valid address. The fix prevents that particular partial interpretation.

The defect is consequential because a parser's output can look more trustworthy than its input. A caller may reasonably distinguish raw text from a value returned by an address parser. If the parser extracts a plausible prefix from a malformed address, later application logic can operate on an identity that does not accurately describe the supplied string.

Rejecting that interpretation is different from proving that a mailbox exists or that a sender controls it. The fix addresses parsing of an invalid form. Delivery, ownership and authorization remain separate questions. Keeping those distinctions explicit avoids giving a maintenance correction a broader guarantee than its source claims.

This also explains why apparently permissive parsing can be undesirable. Recovering something useful from damaged input is sometimes appropriate for display. Reusing the recovered value in a decision about identity can give that recovery a different meaning. The release note identifies a case in which retaining a prefix was the wrong result.

A parser must make progress

A separate change under bpo-37461 fixes an infinite loop while parsing specially crafted email headers. The notes credit Abhilash Raj. They do not need a new public function to describe the correction, because the problem is termination of an existing parsing operation.

An infinite loop turns input handling into a resource-lifetime problem. A process can remain occupied with a header instead of completing that work. The note establishes the affected behavior without establishing that every application using email parsing is remotely exploitable. Exposure still depends on how an application obtains and processes those headers.

For a service that parses external messages, termination is part of the practical contract. Even if a caller discards malformed data after parsing, that policy cannot run while parsing never returns. Repairing the loop therefore affects the caller's ability to reach its own error-handling code.

The address-prefix fix and the loop fix address different properties. One concerns the meaning of a returned value. The other concerns whether the operation finishes. Both belong in the security update, but describing them separately helps a maintainer relate each correction to the program's use of the email library.

URL fixes reach the same branch

The candidate also includes the restriction on local-file:// and local_file:// in URLopener().open() and URLopener().retrieve(). The notes identify that change as CVE-2019-9948 and describe its purpose as avoiding file reading through those schemes. This affects operation selection through a URL, independently of the email parser.

CVE-2019-9740 addresses URL paths containing embedded whitespace or control characters that could reach an HTTP client request. Affected inputs now cause http.client.InvalidURL. The candidate additionally carries a correction for mishandling pre-normalization characters in urlsplit(), recorded as bpo-36742.

These changes illustrate why a patch description needs the actual branch and version. A fix appearing elsewhere in the project does not establish that a given installed interpreter includes it. The release candidate collects the documented corrections for the 3.5 branch so its users can assess that branch's behavior.

My preference is to keep such explanations specific. An exception for an affected HTTP path, a scheme restriction and an email parsing correction each change a different contract. A general claim that networking is safer would conceal the inputs and functions that actually matter.

Source distribution defines the delivery boundary

The release page's source-only status means producing an installed runtime is a separate step from obtaining the candidate. The upstream artifact supplies the interpreter source. A downstream distributor or a local build process determines how that source becomes the executable an application uses.

The candidate notes include a build compatibility correction for ISO C89 syntax in a backported pickle patch, specifically mentioning GCC 4.8's gnu89 mode. That detail fits the maintenance task. Backports must remain buildable in environments used by the branch, alongside correcting the runtime behavior.

Python 3.5.8rc1 therefore provides a defined set of security corrections in a source release candidate. Its email fixes preserve both the interpretation of malformed addresses and the completion of header parsing. Those are concrete runtime properties for applications that continue to rely on this supported security-maintenance branch.