Re: [Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

2015-11-23 Thread Alex Gaynor 
Hi all,

While I appreciate the vote of confidence from everyone, I'm not interested
in being the BDFL-delegate for this. I don't think it's a good idea, and
I'm not willing to put further time into.

If he's interested, Donald Stufft would make a good choice for delegate.

Really do appreciate everyone's confidence.

Cheers,
Alex

On Mon, Nov 23, 2015 at 2:35 PM, Christian Heimes 
wrote:

> On 2015-11-17 01:00, Guido van Rossum wrote:
> > Hm, making Christian the BDFL-delegate would mean two out of three
> > authors *and* the BDFL-delegate all working for Red Hat, which clearly
> > has a stake (and IIUC has already committed to this approach ahead of
> > PEP approval). SO then it would look like this is just rubber-stamping
> > Red Hat's internal decision process (if it's a process -- sounds more
> > like an accident :-).
> >
> > So, Alex, do you want to approve this PEP?
>
> I haven't read this thread until now. Independently from your objection
> I have raised the same concern with Nick today. I'd be willing to BDFL
> the PEP but I'd rather have somebody outside of Red Hat. Alex is a great
> choice.
>
>
> In the same mail I sent Nick a quick review of the latest PEP version in
> private.
>
>
> 1) The example implementation of the function doesn't check the
> sys.flags.ignore_environment. Internally CPython has specialized getenv
> function that ignores env vars with PYTHON prefix when the flag is set.
> PYTHON* env vars aren't removed from os.environ. Modules have to check
> the flag.
>
>
> 2) The PEP is rather Linux-centric. What's the recommended path to the
> config file on other platforms like BDS (/usr/local/etc/ is preferred
> for additional dependencies on FreeBSD), OSX and Windows?
>
>
> 3) What's the interaction between the location of the config file and
> virtual envs? Would it make sense to search for the file in a venv's
> etc/ first and then dispatch to global /etc/? That way venvs can
> influence the setting, too.
>
>
> 4) It makes sense to make the cert-verification.cfg file future-proof
> and reserve it for other cert-related configuration in the future. For
> example it could be used to define new contexts, set protocols, ciphers
> or hashes for cert pinning. It should be enough to say that CPython
> reserves the right to add more sections and keys later.
>
>
> 5) I'm not particular fond of the section name [https]. For one It is
> ambiguous because it doesn't distinguish between server certs and client
> certs. It's also not correct. The default context is used for other
> protocols like imap, smtp etc. over TLS.
>
> Christian
>



-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

2015-11-23 Thread Christian Heimes 
On 2015-11-17 01:00, Guido van Rossum wrote:
> Hm, making Christian the BDFL-delegate would mean two out of three
> authors *and* the BDFL-delegate all working for Red Hat, which clearly
> has a stake (and IIUC has already committed to this approach ahead of
> PEP approval). SO then it would look like this is just rubber-stamping
> Red Hat's internal decision process (if it's a process -- sounds more
> like an accident :-).
> 
> So, Alex, do you want to approve this PEP?

I haven't read this thread until now. Independently from your objection
I have raised the same concern with Nick today. I'd be willing to BDFL
the PEP but I'd rather have somebody outside of Red Hat. Alex is a great
choice.


In the same mail I sent Nick a quick review of the latest PEP version in
private.


1) The example implementation of the function doesn't check the
sys.flags.ignore_environment. Internally CPython has specialized getenv
function that ignores env vars with PYTHON prefix when the flag is set.
PYTHON* env vars aren't removed from os.environ. Modules have to check
the flag.


2) The PEP is rather Linux-centric. What's the recommended path to the
config file on other platforms like BDS (/usr/local/etc/ is preferred
for additional dependencies on FreeBSD), OSX and Windows?


3) What's the interaction between the location of the config file and
virtual envs? Would it make sense to search for the file in a venv's
etc/ first and then dispatch to global /etc/? That way venvs can
influence the setting, too.


4) It makes sense to make the cert-verification.cfg file future-proof
and reserve it for other cert-related configuration in the future. For
example it could be used to define new contexts, set protocols, ciphers
or hashes for cert pinning. It should be enough to say that CPython
reserves the right to add more sections and keys later.


5) I'm not particular fond of the section name [https]. For one It is
ambiguous because it doesn't distinguish between server certs and client
certs. It's also not correct. The default context is used for other
protocols like imap, smtp etc. over TLS.

Christian
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] collections.Counter __add__ implementation quirk

2015-11-23 Thread Vlastimil Brom 
2015-11-23 7:21 GMT+01:00 Alexander Walters :
> collections.Counter.__add__ as a bit of a quirk.
>
> Counters allow for negative numbers.  You can subtract from a counter into
> the negative no problem.  However, if you have a counter with a negative
> value and add it to another counter, and if that value, after addition,
> would still be negative... that value is not included in the resulting
> Counter object.  This is kind of weird, to the point of thinking I had a bug
> in other code for several hours until I went and checked how Counters are
> implemented.
>
> Is there any particular reason counters drop negative values when you add
> them together?  I definitely expected them to act like ints do when you add
> negatives, and had to subclass it to get what I think is the obvious
> behavior.
> ___
> Python-Dev mailing list
...
Hi,
this is probably more appropriate for the general python list rathere
then this developers' maillist, however, as I asked a similar question
some time ago, I got some detailed explanations for the the current
design decissions from the original developer; cf.:
https://mail.python.org/pipermail/python-list/2010-March/570618.html

(I didn't check possible changes in Counter since that version (3.1 at
that time).)

hth,
  vbr
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

2015-11-23 Thread Nick Coghlan 
On 24 November 2015 at 11:59, Barry Warsaw  wrote:
> On Nov 24, 2015, at 10:18 AM, Nick Coghlan wrote:
>
>>Since we already know Red Hat are OK with the draft recommendations,
>>and I missed the RHEL 7.2 release date anyway, perhaps Barry or
>>Matthias might be interested in tilting at the Ubuntu 14.04 LTS stable
>>release update windmill? I know there was previously a decision from
>>Ubuntu Security not to backport PEPs 466 & 476 to 2.7.5 due to the
>>stability risks [1], but the configuration file based approach
>>recommended in PEP 493 is backwards compatible by default
>
> Right, but this isn't a patch we'd particularly want to carry ourselves.
> Maybe if it were available upstream, tried and tested, it could be considered
> for backporting, but it still wouldn't be zero cost.

If anyone wants to look through the patches implementing the backport,
they're available through the CentOS git repositories:
https://git.centos.org/commit/rpms!python.git/refs!heads!c7

> We'd have to also handle
> migration paths to newer Ubuntu releases, which probably means removing the
> config file on future upgrades.

You'll need to figure out those migration paths anyway, as the
certificate verification compatibility break will exist between 14.04
and 16.04 regardless of what happens with PEP 493.

> There's also the possibility of implementing
> different defaults on new installs of 14.04 versus upgrades to 14.04.

For those aspects, we left the defaults in RHEL 7.2 as implementing
the 2.7.5 behaviour (i.e. no cert verification), but used the
"platform default" mechanism in PEP 493 to ensure we had the ability
to change our mind if circumstances change.

For the immediately foreseeable future though, it will be up to
operations teams to decide how they want the Python 2.7 standard
library to behave with respect to HTTPS client certificate
verification on RHEL & CentOS 7.

> And
> even if a system administrator enabled it for one particular application, it
> could break other applications on the same machine, so it just punts a
> difficult decision down the line.
>
> We're also not seeing much (any?) demand from our users, and the initial
> attempt at turning this on by default *did* get a strong negative reaction
> because of the compatibility break.

My own main concern is providing an additional layer of defence
against certificate verification related security bugs in network
services and clients written in Python like OpenStack, Ansible,
FreeIPA, Pulp, etc, which is why I'm happy with the approach of giving
system operators the tools they need to make their own decision about
whether or not they want that additional layer of protection on a
given host. Folks building Docker images can also easily opt in or out
by including a suitable configuration file.

>From a change management perspective, there's also a very big
difference between "We made this decision for you, and you'll need to
update your systems accordingly in order to upgrade", and "We made it
possible for you to make your own decision about this new
configuration setting, based on what you think is best for your
particular situation".

There's still some risk in the latter case (since you may accidentally
break things), but the upstream releases flushed out a lot of those
problems for this particular update (e.g. the gevent compatibility
issue that affected the upstream PEP 466 backport).

Regards,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] collections.Counter __add__ implementation quirk

2015-11-23 Thread Raymond Hettinger 

> On Nov 23, 2015, at 10:43 AM, Vlastimil Brom  wrote:
> 
>> Is there any particular reason counters drop negative values when you add
>> them together?  I definitely expected them to act like ints do when you add
>> negatives, and had to subclass it to get what I think is the obvious
>> behavior.
>> ___
>> Python-Dev mailing list
> ...
> Hi,
> this is probably more appropriate for the general python list rathere
> then this developers' maillist, however, as I asked a similar question
> some time ago, I got some detailed explanations for the the current
> design decissions from the original developer; cf.:
> https://mail.python.org/pipermail/python-list/2010-March/570618.html
> 
> (I didn't check possible changes in Counter since that version (3.1 at
> that time).)

In Python3.2, Counter grew a subtract() method:

>>> c = Counter(a=4, b=2, c=0, d=-2)
>>> d = Counter(a=1, b=2, c=3, d=4)
>>> c.subtract(d)
>>> c
Counter({'a': 3, 'b': 0, 'c': -3, 'd': -6})

The update() method has been around since the beginning:

>>> from collections import Counter
>>> c = Counter(a=4, b=2, c=0, d=-2)
>>> d = Counter(a=1, b=-5, c=-2, d=6)
>>> c.update(d)
>>> d
Counter({'d': 6, 'a': 1, 'c': -2, 'b': -5})


So, you have two ways of doing counter math:

1. Normal integer arithmetic using update() and subtract() does straight 
addition and subtraction, either starting with or ending-up with negative 
values.

2. Saturating arithmetic using the operators: + - & | excludes non-positive 
results.  This supports bag-like behavior (c.f. smalltalk) and multiset 
operations (https://en.wikipedia.org/wiki/Multiset).


Raymond






___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

2015-11-23 Thread Nick Coghlan 
On 24 November 2015 at 06:47, Wes Turner  wrote:
> 1. Does this affect easy_install?

easy_install has validated certificates since distribute was merged
back into the project as part of setuptools 0.7 [1], and aside from
one issue with HTTPS tunnelling [2], the certificate verification code
has been stable since setuptools 1.3 [3].

> 2. If/because this affects easy_install,
>   should the guidance / suggested package installation tool be [pip];
> because pip install_requires backports.ssl_match_hostname

setuptools/easy_install uses backports.ssl_match_hostname if it's
available, and otherwise has its own implementation.

Cheers,
Nick.

[1] https://pythonhosted.org/setuptools/history.html#id159
[2] https://pythonhosted.org/setuptools/history.html#id80
[3] https://pythonhosted.org/setuptools/history.html#id123

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

2015-11-23 Thread Wes Turner 
On Mon, Nov 23, 2015 at 5:56 PM, Nick Coghlan  wrote:

> On 24 November 2015 at 06:47, Wes Turner  wrote:
> > 1. Does this affect easy_install?
>
> easy_install has validated certificates since distribute was merged
> back into the project as part of setuptools 0.7 [1], and aside from
> one issue with HTTPS tunnelling [2], the certificate verification code
> has been stable since setuptools 1.3 [3].
>

Got it; thanks.

* https://bitbucket.org/pypa/setuptools/src/tip/setuptools/ssl_support.py


>
> > 2. If/because this affects easy_install,
> >   should the guidance / suggested package installation tool be [pip];
> > because pip install_requires backports.ssl_match_hostname
>
> setuptools/easy_install uses backports.ssl_match_hostname if it's
> available, and otherwise has its own implementation.
>

* setuptools 0.7 [src] -- 2013-06-?? --
https://bitbucket.org/pypa/setuptools/src/7f2c08e9/?at=0.7
* setuptools 0.7 [distro] -- 201X-XX-XX [see: whohas, ]

Setuptools latest is now at version 18.5 (2015-11-02).






>
> Cheers,
> Nick.
>
> [1] https://pythonhosted.org/setuptools/history.html#id159
> [2] https://pythonhosted.org/setuptools/history.html#id80
> [3] https://pythonhosted.org/setuptools/history.html#id123
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

2015-11-23 Thread Nick Coghlan 
Updated version of the PEP posted: https://hg.python.org/peps/rev/8decac213ebf

On 24 November 2015 at 05:35, Christian Heimes  wrote:
> 1) The example implementation of the function doesn't check the
> sys.flags.ignore_environment. Internally CPython has specialized getenv
> function that ignores env vars with PYTHON prefix when the flag is set.
> PYTHON* env vars aren't removed from os.environ. Modules have to check
> the flag.

I guarded the relevant sections in the examples with "if not
sys.flags.ignore_environment:"

> 2) The PEP is rather Linux-centric. What's the recommended path to the
> config file on other platforms like BDS (/usr/local/etc/ is preferred
> for additional dependencies on FreeBSD), OSX and Windows?

The environment variable section should be generic, and the
configuration file section is largely specific to vendors offering
long term commercial support options for Linux distros.

There was already a qualification in the "Recommended file location"
section limiting the scope to *nix systems, so rather than trying to
cover non-Linux systems, I've instead updated that qualification to
limit the recommendation even further to specifically Linux systems.
If *BSD folks pipe up saying they'd like to be included, then adding
another filename recommendation wouldn't be difficult.

> 3) What's the interaction between the location of the config file and
> virtual envs? Would it make sense to search for the file in a venv's
> etc/ first and then dispatch to global /etc/? That way venvs can
> influence the setting, too.

This is a system level configuration setting to preserve backwards
compatible behaviour in the system Python, so scoping it at the
interpreter level was a deliberate design decision. However, I added a
new section to both recommendations describing the lack of interaction
with virtual environments.

> 4) It makes sense to make the cert-verification.cfg file future-proof
> and reserve it for other cert-related configuration in the future. For
> example it could be used to define new contexts, set protocols, ciphers
> or hashes for cert pinning. It should be enough to say that CPython
> reserves the right to add more sections and keys later.

For future releases, I think a different filename makes sense, as we
don't really want a global "turn off HTTPS certificate verification"
flag. Perhaps something like "/etc/python/network-security.cfg", for
example.

> 5) I'm not particular fond of the section name [https]. For one It is
> ambiguous because it doesn't distinguish between server certs and client
> certs.

I added a note to clarify that the section name comes from the "https"
URL schema passed to the relevant client APIs.

> It's also not correct. The default context is used for other
> protocols like imap, smtp etc. over TLS.

That changed in PEP 476 - there's a separate private context for HTTPS
standard library clients now, which allows HTTPS to verify hostnames
by default, while other clients are still permissive. This is noted in
PEP 476: https://www.python.org/dev/peps/pep-0476/#other-protocols

The reason for this is that browsers have provided a pretty good
forcing function in getting folks to use properly signed certificates,
at least on the public internet, but self-signed and improperly signed
certificates are still significantly more common for other protocols.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

2015-11-23 Thread Nick Coghlan 
On 24 November 2015 at 05:35, Christian Heimes  wrote:
> On 2015-11-17 01:00, Guido van Rossum wrote:
>> Hm, making Christian the BDFL-delegate would mean two out of three
>> authors *and* the BDFL-delegate all working for Red Hat, which clearly
>> has a stake (and IIUC has already committed to this approach ahead of
>> PEP approval). SO then it would look like this is just rubber-stamping
>> Red Hat's internal decision process (if it's a process -- sounds more
>> like an accident :-).
>>
>> So, Alex, do you want to approve this PEP?
>
> I haven't read this thread until now. Independently from your objection
> I have raised the same concern with Nick today. I'd be willing to BDFL
> the PEP but I'd rather have somebody outside of Red Hat.

Likewise, but the intersection between "wants to get PEP 476 into the
hands of as many system operators as possible as soon as possible",
"is a CPython core developer", and "doesn't work for Red Hat" is
looking to be a rather select group :)

Since we already know Red Hat are OK with the draft recommendations,
and I missed the RHEL 7.2 release date anyway, perhaps Barry or
Matthias might be interested in tilting at the Ubuntu 14.04 LTS stable
release update windmill? I know there was previously a decision from
Ubuntu Security not to backport PEPs 466 & 476 to 2.7.5 due to the
stability risks [1], but the configuration file based approach
recommended in PEP 493 is backwards compatible by default, with the
decision to opt in to the improved settings after upgrading current
systems being made by system administrators rather than the distro
vendor. With around 3 1/2 years still to run on 14.04's support
lifecycle, that has the potential to reach quite a few systems that
otherwise wouldn't benefit from the change until well after Ubuntu
16.04 is released next year.

Regards,
Nick.

[1] http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-9365.html

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

2015-11-23 Thread Nick Coghlan 
On 24 November 2015 at 12:05, Barry Warsaw  wrote:
> On Nov 17, 2015, at 11:44 PM, Nick Coghlan wrote:
>
>>For Debian, Ubuntu and SUSE, their original determinations for the
>>relevant CVE were "too intrusive to backport", so folks currently need
>>to upgrade to newer versions of those distros to get the improved
>>default behaviour:
>
> This is an example of my problem with the tone of PEP 493 (sorry Nick, nothing
> personal!).  "Improved default behavior"... for whom?  It's not improved for
> the folks whose applications are broken by changing the default.

I think there are three relevant categories here:

1. Folks who assume that "https" means the same thing in Python that
it means in web browsers, and are currently experiencing a silent
security failure
2. Folks who already know it doesn't, and are relying on that to keep
their infrastructure working
3. Folks currently in group 2 who would like to improve their
infrastructure to default to verifying certificates

The upstream change in PEP 476 was driven by the interests of folks in
group 1. This makes a lot of sense, given that a popular way of
introducing folks to programming now is by writing programs that
interact with web APIs over HTTPS. Rebasing is fine for reaching
desktop audiences, so this group should already have been covered by
the updated python.org binaries for Windows and Mac OS X, new binary
releases from the cross-platform redistributors, and updates to
non-LTS Linux distros.

For folks in group 2, the main goal is "Don't break their stuff as a
side effect of updating a supported version", which is why PEP 493
recommends leaving certificate verification disabled by default if
backporting the PEP 476 changes.

The target audience for PEP 493 is then the folks in group 3:
infrastructure operators that *want* to turn failures to validate
certificates in Python applications into a noisy failure, but *don't*
want to have to switch to a new major version of their entire base
operating system to do it. With the PEP, opting in to PEP 476 for
Python 2 applications and services is just a configuration file
setting, readily managed with any configuration management tool. If
just the configuration file approach is supported (as is the case for
RHEL 7.2), then that decision needs to be made on a system-wide basis,
and you need to use a chroot (or a full Linux container) in order to
opt out (or in) for a single application. If the environment variable
downgrade is also supported, then the environments for individual
applications can be tweaked, even while the overall environment is
upgraded to complain about missing security checks by default.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

2015-11-23 Thread Barry Warsaw 
On Nov 24, 2015, at 10:18 AM, Nick Coghlan wrote:

>Since we already know Red Hat are OK with the draft recommendations,
>and I missed the RHEL 7.2 release date anyway, perhaps Barry or
>Matthias might be interested in tilting at the Ubuntu 14.04 LTS stable
>release update windmill? I know there was previously a decision from
>Ubuntu Security not to backport PEPs 466 & 476 to 2.7.5 due to the
>stability risks [1], but the configuration file based approach
>recommended in PEP 493 is backwards compatible by default

Right, but this isn't a patch we'd particularly want to carry ourselves.
Maybe if it were available upstream, tried and tested, it could be considered
for backporting, but it still wouldn't be zero cost.  We'd have to also handle
migration paths to newer Ubuntu releases, which probably means removing the
config file on future upgrades.  There's also the possibility of implementing
different defaults on new installs of 14.04 versus upgrades to 14.04.  And
even if a system administrator enabled it for one particular application, it
could break other applications on the same machine, so it just punts a
difficult decision down the line.

We're also not seeing much (any?) demand from our users, and the initial
attempt at turning this on by default *did* get a strong negative reaction
because of the compatibility break.

I'm concerned about accepting PEP 493 making a strong recommendation to
downstreams.  Yes, in an ideal world we all want security by default, but I
think the backward compatibility concerns of the PEP are understated,
especially as they relate to a maintenance release of a stable long term
support version of the OS.  I don't want PEP 493 to be a cudgel that people
beat us up with instead of having an honest discussion of the difficult
trade-offs involved.

Having said all that, I think informing people of the issue, and letting any
future reconsideration be demand driven is the right approach for now.

$0.02-ly y'rs,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

2015-11-23 Thread Barry Warsaw 
On Nov 17, 2015, at 11:44 PM, Nick Coghlan wrote:

>For Debian, Ubuntu and SUSE, their original determinations for the
>relevant CVE were "too intrusive to backport", so folks currently need
>to upgrade to newer versions of those distros to get the improved
>default behaviour:

This is an example of my problem with the tone of PEP 493 (sorry Nick, nothing
personal!).  "Improved default behavior"... for whom?  It's not improved for
the folks whose applications are broken by changing the default.

Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

2015-11-23 Thread Wes Turner 
... Just had this discussion in regards to easy_install, Ubuntu 14.04 LTS,
and the ReadTheDocs Docker images (as well as: ~why should I have to
wget/curl get-pip.py)
https://github.com/rtfd/readthedocs-docker-images/pull/3
On Nov 23, 2015 2:47 PM, "Wes Turner"  wrote:

> 1. Does this affect easy_install?
> 2. If/because this affects easy_install,
>   should the guidance / suggested package installation tool be [pip];
> because pip install_requires backports.ssl_match_hostname
>
> https://pypi.python.org/pypi/backports.ssl_match_hostname
> On Nov 10, 2015 6:48 PM, "Nick Coghlan"  wrote:
>
>> Hi folks,
>>
>> I have a confession to make - I dropped the ball on the HTTPS
>> verification backport proposals in PEP 493, and let the upstream and
>> downstream approval processes get out of sequence.
>>
>> As a result, the RHEL 7.2 beta released back in September incorporates
>> the HTTPS verification feature backport based on the current PEP 493
>> draft, even though that hasn't formally been pronounced as an Active
>> recommendation by python-dev yet.
>>
>> Accordingly, I'm belatedly submitting it for pronouncement now:
>> https://www.python.org/dev/peps/pep-0493/
>>
>> There's currently no BDFL-Delegate assigned, so if Guido doesn't want
>> to handle it, we'll need to address that question first.
>>
>> Our last discussion back in July seemed to show that folks either
>> didn't care about the question (because they're using unmodified
>> upstream versions so the PEP didn't affect them), or else thought the
>> approach described in the PEP was reasonable, so I'm hoping the
>> consequences of my mistake won't be too severe.
>>
>> Regards,
>> Nick.
>>
>> P.S. I'm aware that this looks like presenting a fait accompli at a
>> point where it's too late to realistically say "No", but the truth is
>> that preparation for the Python in Education miniconf at PyCon
>> Australia ramped up immediately after the July discussion, and then I
>> personally got confused as to the scope of what was being included in
>> 7.2 (I mistakenly thought it was just PEP 466 for now, with 476+493
>> being deferred to a later release, but it's actually the whole package
>> of 466+476+493). That's my fault for trying to keep track of too many
>> things at once (and thus failing at some of them), not anyone else's.
>>
>> 
>>
>> PEP: 493
>> Title: HTTPS verification recommendations for Python 2.7 redistributors
>> Version: $Revision$
>> Last-Modified: $Date$
>> Author: Nick Coghlan ,
>> Robert Kuska ,
>> Marc-André Lemburg 
>> Status: Draft
>> Type: Informational
>> Content-Type: text/x-rst
>> Created: 10-May-2015
>> Post-History: 06-Jul-2015
>>
>>
>> Abstract
>> 
>>
>> PEP 476 updated Python's default handling of HTTPS certificates to be
>> appropriate for communication over the public internet. The Python 2.7
>> long
>> term maintenance series was judged to be in scope for this change, with
>> the
>> new behaviour introduced in the Python 2.7.9 maintenance release.
>>
>> This PEP provides recommendations to downstream redistributors wishing to
>> provide a smoother migration experience when helping their users to manage
>> this change in Python's default behaviour.
>>
>>
>> Rationale
>> =
>>
>> PEP 476 changed Python's default behaviour to better match the needs and
>> expectations of developers operating over the public internet, a category
>> which appears to include most new Python developers. It is the position of
>> the authors of this PEP that this was a correct decision.
>>
>> However, it is also the case that this change *does* cause problems for
>> infrastructure administrators operating private intranets that rely on
>> self-signed certificates, or otherwise encounter problems with the new
>> default
>> certificate verification settings.
>>
>> The long term answer for such environments is to update their internal
>> certificate management to at least match the standards set by the public
>> internet, but in the meantime, it is desirable to offer these
>> administrators
>> a way to continue receiving maintenance updates to the Python 2.7 series,
>> without having to gate that on upgrades to their certificate management
>> infrastructure.
>>
>> PEP 476 did attempt to address this question, by covering how to revert
>> the
>> new settings process wide by monkeypatching the ``ssl`` module to restore
>> the
>> old behaviour. Unfortunately, the ``sitecustomize.py`` based technique
>> proposed
>> to allow system administrators to disable the feature by default in their
>> Standard Operating Environment definition has been determined to be
>> insufficient in at least some cases. The specific case of interest to the
>> authors of this PEP is the one where a Linux distributor aims to provide
>> their users with a
>> `smoother migration path
>>

Re: [Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

2015-11-23 Thread Wes Turner 
1. Does this affect easy_install?
2. If/because this affects easy_install,
  should the guidance / suggested package installation tool be [pip];
because pip install_requires backports.ssl_match_hostname

https://pypi.python.org/pypi/backports.ssl_match_hostname
On Nov 10, 2015 6:48 PM, "Nick Coghlan"  wrote:

> Hi folks,
>
> I have a confession to make - I dropped the ball on the HTTPS
> verification backport proposals in PEP 493, and let the upstream and
> downstream approval processes get out of sequence.
>
> As a result, the RHEL 7.2 beta released back in September incorporates
> the HTTPS verification feature backport based on the current PEP 493
> draft, even though that hasn't formally been pronounced as an Active
> recommendation by python-dev yet.
>
> Accordingly, I'm belatedly submitting it for pronouncement now:
> https://www.python.org/dev/peps/pep-0493/
>
> There's currently no BDFL-Delegate assigned, so if Guido doesn't want
> to handle it, we'll need to address that question first.
>
> Our last discussion back in July seemed to show that folks either
> didn't care about the question (because they're using unmodified
> upstream versions so the PEP didn't affect them), or else thought the
> approach described in the PEP was reasonable, so I'm hoping the
> consequences of my mistake won't be too severe.
>
> Regards,
> Nick.
>
> P.S. I'm aware that this looks like presenting a fait accompli at a
> point where it's too late to realistically say "No", but the truth is
> that preparation for the Python in Education miniconf at PyCon
> Australia ramped up immediately after the July discussion, and then I
> personally got confused as to the scope of what was being included in
> 7.2 (I mistakenly thought it was just PEP 466 for now, with 476+493
> being deferred to a later release, but it's actually the whole package
> of 466+476+493). That's my fault for trying to keep track of too many
> things at once (and thus failing at some of them), not anyone else's.
>
> 
>
> PEP: 493
> Title: HTTPS verification recommendations for Python 2.7 redistributors
> Version: $Revision$
> Last-Modified: $Date$
> Author: Nick Coghlan ,
> Robert Kuska ,
> Marc-André Lemburg 
> Status: Draft
> Type: Informational
> Content-Type: text/x-rst
> Created: 10-May-2015
> Post-History: 06-Jul-2015
>
>
> Abstract
> 
>
> PEP 476 updated Python's default handling of HTTPS certificates to be
> appropriate for communication over the public internet. The Python 2.7 long
> term maintenance series was judged to be in scope for this change, with the
> new behaviour introduced in the Python 2.7.9 maintenance release.
>
> This PEP provides recommendations to downstream redistributors wishing to
> provide a smoother migration experience when helping their users to manage
> this change in Python's default behaviour.
>
>
> Rationale
> =
>
> PEP 476 changed Python's default behaviour to better match the needs and
> expectations of developers operating over the public internet, a category
> which appears to include most new Python developers. It is the position of
> the authors of this PEP that this was a correct decision.
>
> However, it is also the case that this change *does* cause problems for
> infrastructure administrators operating private intranets that rely on
> self-signed certificates, or otherwise encounter problems with the new
> default
> certificate verification settings.
>
> The long term answer for such environments is to update their internal
> certificate management to at least match the standards set by the public
> internet, but in the meantime, it is desirable to offer these
> administrators
> a way to continue receiving maintenance updates to the Python 2.7 series,
> without having to gate that on upgrades to their certificate management
> infrastructure.
>
> PEP 476 did attempt to address this question, by covering how to revert the
> new settings process wide by monkeypatching the ``ssl`` module to restore
> the
> old behaviour. Unfortunately, the ``sitecustomize.py`` based technique
> proposed
> to allow system administrators to disable the feature by default in their
> Standard Operating Environment definition has been determined to be
> insufficient in at least some cases. The specific case of interest to the
> authors of this PEP is the one where a Linux distributor aims to provide
> their users with a
> `smoother migration path
> `__
> than the standard one provided by consuming upstream CPython 2.7 releases
> directly, but other potential challenges have also been pointed out with
> updating embedded Python runtimes and other user level installations of
> Python.
>
> Rather than allowing a plethora of mutually incompatibile migration
> techniques
> to bloom, this PEP proposes two alternative approaches that redistributors
>