(Oops, I had a version of this reply sitting in my Drafts folder for a
week, and only noticed after pushing the most recent PEP update that
it had never been sent)
On 1 December 2015 at 06:32, Barry Warsaw wrote:
> On Nov 27, 2015, at 04:04 PM, Nick Coghlan wrote:
>
>>New draft pushed: https://hg
On Nov 27, 2015, at 04:04 PM, Nick Coghlan wrote:
>New draft pushed: https://hg.python.org/peps/rev/f602a47ea795
>
>This is a significant rewrite that switches the PEP to a Standards Track PEP
>proposing two new features for 2.7.12+: an "ssl._verify_https_certificates()"
>configuration function, a
Nick Coghlan writes:
> This is a significant rewrite that switches the PEP to a Standards
> Track PEP proposing two new features for 2.7.12+: an
> "ssl._verify_https_certificates()" configuration function, and a
> "PYTHONHTTPSVERIFY" environment variable (although writing them
> together like
On 27 November 2015 at 18:47, Cory Benfield wrote:
> Perhaps I missed this, Nick, but what happens if multiple third party
> libraries apply updates to call this function in incompatible ways? For
> example, if you depend on libfoo which calls
> ssl._verify_https_certificates(False) and libbar
> On 27 Nov 2015, at 06:04, Nick Coghlan wrote:
>
> Feature: Configuration API
> ==
>
> This change is proposed for inclusion in CPython 2.7.12 and later CPython
> 2.7.x
> releases. It consists of a new ``ssl._verify_https_certificates()`` to specify
> the default handl
Nick Coghlan writes:
> This is a significant rewrite that switches the PEP to a Standards
> Track PEP proposing two new features for 2.7.12+: an
> "ssl._verify_https_certificates()" configuration function, and a
> "PYTHONHTTPSVERIFY" environment variable (although writing them
> together like
On 27 November 2015 at 17:42, Stephen J. Turnbull wrote:
> Nick Coghlan writes:
>
> > This is a significant rewrite that switches the PEP to a Standards
> > Track PEP proposing two new features for 2.7.12+: an
> > "ssl._verify_https_certificates()" configuration function, and a
> > "PYTHONHTTP
On 27 November 2015 at 10:52, Nick Coghlan wrote:
> On 27 November 2015 at 03:15, Barry Warsaw wrote:
>> On Nov 26, 2015, at 03:06 PM, Nick Coghlan wrote:
>>>In this particular case, the migration problems were already raised in
>>>the PEP 476 discussions, and the decision was made to *not* provi
On Nov 26, 2015 4:53 PM, "Nick Coghlan" wrote:
>
> On 27 November 2015 at 03:15, Barry Warsaw wrote:
>
> > Likewise in Ubuntu, we try to keep deviations from Debian at a minimum,
and
> > document them when we must deviate. Ubuntu is a community driven
distro so
> > while Canonical itself has cu
On 27 November 2015 at 03:15, Barry Warsaw wrote:
> On Nov 26, 2015, at 03:06 PM, Nick Coghlan wrote:
>
>>I'm not a big fan of it either, but it's the way sustainable
>>commercial open source distribution works in practice:
>
> While it's inevitable that redistributors have to deviate from upstrea
On Nov 26, 2015, at 03:06 PM, Nick Coghlan wrote:
>I'm not a big fan of it either, but it's the way sustainable
>commercial open source distribution works in practice:
While it's inevitable that redistributors have to deviate from upstream, in
Debian and Ubuntu, we really try to keep that at a mi
On Nov 26, 2015, at 02:13 PM, Nick Coghlan wrote:
>PEP 476 rejected providing a public indefinitely maintained API for this, so
>PEP 493 is specifically about helping commercial redistributors offer a
>smoother transition plan to customers without affecting the public Python
>level API, and withou
On 26 November 2015 at 06:17, Robert Collins wrote:
> On 26 November 2015 at 08:57, Barry Warsaw wrote:
>> There's a lot to process in this thread, but as I see it, the issue breaks
>> down to these questions:
>>
>> * How should PEP 493 be implemented?
>>
>> * What should the default be?
>>
>> *
On 26 November 2015 at 05:57, Barry Warsaw wrote:
> There's a lot to process in this thread, but as I see it, the issue breaks
> down to these questions:
>
> * How should PEP 493 be implemented?
>
> * What should the default be?
>
> * How should PEP 493 be worded to express the right tone to redis
On Nov 25, 2015, at 03:39 PM, R. David Murray wrote:
>I think we should include the environment variable support in CPython
>and be done with it (nuke the PEP otherwise). Which is what I've
>thought from the beginning :)
+1. I'd like to see my proposed convenience function added too. I'm -0 on
On Nov 24, 2015, at 02:12 PM, Nick Coghlan wrote:
>On 24 November 2015 at 11:59, Barry Warsaw wrote:
>> 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 an
On Nov 24, 2015, at 09:16 AM, Toshio Kuratomi wrote:
>It sounds like the implementation sections of the PEP are acceptable
Well, see my follow up to MAL's email. From Rob's and RDM's responses, it
seems we're not alone. :)
I like all your other proposed changes, although I'll note the preferenc
In a message of Wed, 25 Nov 2015 15:39:54 -0500, "R. David Murray" writes:
>I think we should include the environment variable support in CPython
>and be done with it (nuke the PEP otherwise). Which is what I've
>thought from the beginning :)
>
>--David
I like this idea too.
Laura
__
On Thu, 26 Nov 2015 09:17:02 +1300, Robert Collins
wrote:
> On 26 November 2015 at 08:57, Barry Warsaw wrote:
> > There's a lot to process in this thread, but as I see it, the issue breaks
> > down to these questions:
> >
> > * How should PEP 493 be implemented?
> >
> > * What should the default
On 26 November 2015 at 08:57, Barry Warsaw wrote:
> There's a lot to process in this thread, but as I see it, the issue breaks
> down to these questions:
>
> * How should PEP 493 be implemented?
>
> * What should the default be?
>
> * How should PEP 493 be worded to express the right tone to redis
There's a lot to process in this thread, but as I see it, the issue breaks
down to these questions:
* How should PEP 493 be implemented?
* What should the default be?
* How should PEP 493 be worded to express the right tone to redistributors?
Let me take on the implementation details here.
On
> On 24 Nov 2015, at 12:53, Christian Heimes wrote:
> Right, with Antoine and Alex out of scope and you, Victor and me working
> for Red Hat, the air is getting thin. Benjamin is familiar with the ssl
> module. Or we can follow Alex's advice and ask somebody from the PyCA
> group (Donald, Paul, l
On 25 Nov 2015 05:42, "Toshio Kuratomi" wrote:
> >
>
> Yeah, I think you are correct in your understanding of what actual
> changes to the python distrribution are being proposed for
> redistributors in the PEP. Reading through the PEP again, I'm not
> sure if I'm correct in thinking that this o
On Tue, Nov 24, 2015 at 10:56 AM, Paul Moore wrote:
> On 24 November 2015 at 18:37, Toshio Kuratomi wrote:
>> The cornercases come
>> into play because you don't always control all of the devices and
>> services on your network. The site could evaluate and decide that
>> MITM isn't a threat to
On 24 November 2015 at 18:37, Toshio Kuratomi wrote:
> I don't quite agree with this but it's probably moot in the face of
> the previous and certain cornercases. Self-signed certs work just
> fine with the backports to python-2.7.9+ but you have to add the ca to
> the clients. An organization t
On Tue, Nov 24, 2015 at 10:08 AM, Paul Moore wrote:
> I'm not actually sure that it's the place of this PEP to even comment
> on what the long term answer for such environments should be (or
> indeed, any answer, long term or not). I've argued the position that
> in some organisations it feels li
On 24 November 2015 at 17:16, Toshio Kuratomi wrote:
> 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 c
On Mon, Nov 23, 2015 at 5:59 PM, Barry Warsaw wrote:
> 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
On 24 November 2015 at 14:27, Laura Creighton wrote:
> In a message of Tue, 24 Nov 2015 14:05:53 +, Paul Moore writes:
>>Simply adding "people who have no control over their broken
>>infrastructure" with a note that this PEP helps them, would be
>>sufficient here (and actually helps the case f
On 2015-11-24 00:47, Nick Coghlan wrote:
> 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 CPytho
I think the PEP is a good step forward to compromise between
the crypto purists (use whatever technologies makes us more
secure even if it breaks things) and those who cannot upgrade
their Python 2.7 because of the PEP 476 change, since it causes their
applications to fail (e.g. because the embedde
On 25 November 2015 at 00:27, Laura Creighton wrote:
> In a message of Tue, 24 Nov 2015 14:05:53 +, Paul Moore writes:
>>Simply adding "people who have no control over their broken
>>infrastructure" with a note that this PEP helps them, would be
>>sufficient here (and actually helps the case f
In a message of Tue, 24 Nov 2015 14:05:53 +, Paul Moore writes:
>Simply adding "people who have no control over their broken
>infrastructure" with a note that this PEP helps them, would be
>sufficient here (and actually helps the case for the PEP, so why not?
>;-))
But does it help them? Or d
On 24 November 2015 at 13:20, Nick Coghlan wrote:
> I believe you're referring mainly to the original PEP 476 change there. In
> the context of PEP 493, this is another group that would potentially benefit
> from the suggested "security downgrade" environment variable (if any
> redistributors deci
On 24 Nov 2015 8:12 pm, "Paul Moore" wrote:
>
> On 24 November 2015 at 03:46, Nick Coghlan wrote:
> > 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 silen
> On Nov 24, 2015, at 7:53 AM, Christian Heimes wrote:
>
> On 2015-11-24 01:18, Nick Coghlan wrote:
>> 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
On 2015-11-24 01:18, Nick Coghlan wrote:
> 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
On 24 November 2015 at 03:46, Nick Coghlan wrote:
> 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
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 1
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 g
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 o
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 wa
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 w
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 thi
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 be
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
... 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_in
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 Coghla
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 eve
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 l
On 11 November 2015 at 10:47, Nick Coghlan wrote:
> 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 reas
On 17 November 2015 at 20:33, Victor Stinner wrote:
> 2015-11-17 1:00 GMT+01:00 Guido van Rossum :
>> 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
2015-11-17 1:00 GMT+01:00 Guido van Rossum :
> 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 l
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 d
On 17 November 2015 at 09:07, Guido van Rossum wrote:
> So I dropped the ball on this too -- I was going to either have a look
> or tell you quickly to find a BDFL-delegate, but ended up doing
> neither. Skimming it now I really don't think I'm the right person to
> review this. Maybe you could as
So I dropped the ball on this too -- I was going to either have a look
or tell you quickly to find a BDFL-delegate, but ended up doing
neither. Skimming it now I really don't think I'm the right person to
review this. Maybe you could ask Alex Gaynor?
On Tue, Nov 10, 2015 at 4:47 PM, Nick Coghlan
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 bac
57 matches
Mail list logo
