[Security-sig] Policy PEP (was Re: RFC: PEP: Make os.urandom() blocking on Linux)

[Nick Coghlan]

On 24 June 2016 at 07:01, Barry Warsaw <barry at python.org> wrote:
> On Jun 24, 2016, at 12:11 AM, Victor Stinner wrote:
>
>>Once we modified Python 3.6 to handle correctly "the bug" and we
>>consider that the implementation is tested enough, I suggest to
>>backport it to Python 2.7 as well. Moreover, I would also suggest to
>>backport the change to Python 3.5, I would be sad if Python 2 is more
>>secure than the latest Python 3 release :-)
>
> This is the fundamental point of disagreement, and I think it points again to
> a deficiency in our process.  Regardless of outcome of this specific case, I
> think we should try to tighten up our definitions and codify our policy in an
> informational PEP.
>
> What criteria do we use to classify an issue as a security bug requiring a
> fix, with backports, overriding any backward compatibility breaks?
>
> I think we've been largely ad-hoc about this question.

PEP 466 aimed to answer it:
https://www.python.org/dev/peps/pep-0466/#why-these-particular-changes

The most significant sentence in that section is this one: "The key
requirement for a feature to be considered for inclusion in this
proposal was that it must have security implications beyond the
specific application that is written in Python and the system that
application is running on."

Earlier drafts of the PEP did aim to define that as a standard policy,
but Guido nixed that idea, instead requesting that every such security
related backport proposal receive its own dedicated PEP.

For PEP 466, the limitations of the Python 2.7 standard library were
holding back the evolution of network security in general (e.g. by
acting as a brake on the adoption of Server-Name-Indication and on
servers forcing TLS-only secure connections). For PEP 476, the
mismatch between how people assumed the standard library handled HTTPS
connections and how it actually did handle them was causing real
security vulnerabilities in networked applications.

For the PEPs currently under consideration, I don't think the
situation is as critical as that - we're talking about a rare
situation specific to secret generation on Linux with poorly
configured entropy sources, not the core handling of SSL/TLS and HTTPS
used by a large proportion of networked applications. That means I
believe "Folks that genuinely care about secure secret generation
should upgrade to Python 3.6 and a Linux kernel with getrandom()
support" is an entirely reasonable position for us to take in this
case.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia