Re: [Python-Dev] gdb support could use some love

[Skip Montanaro]

> There are a bunch of open issues regarding gdb support including one with a 
> PR in need of review for 3.6+.

I rejected one (which assumed everyone now uses a python-aware gdb),
commented on another (ceval.c-related name changes in several
commands), and created a PR for third (documentation for the
user-defined commands). Unfortunately, it's been so long since I
contributed, I don't quite understand the ins and outs of the workflow
anymore. In particular, I could find no way to add the "skip news"
label. I'm afraid someone might have to intervene here:

https://github.com/python/cpython/pull/6384

Skip
___
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] ssl module and LibreSSL CVE-2018-8970

[Brett Cannon]

Nice work! Something to add to our "finding C compiler bugs" list of
accomplishments. 😁

On Wed, Apr 4, 2018, 13:39 Christian Heimes,  wrote:

> Hi,
>
> I like to share the story of a critical security bug with you. Contrary
> to other issues in TLS/SSL, it's a story with happy ending. Nobody was
> harmed. The bug was fixed before it affected the general population.
>
>
> Introduction
> 
>
> Python's ssl.match_hostname() function was a source of several CVEs and
> other security bugs. After a long struggle, I decided to drop support
> for old OpenSSL releases and uses a new OpenSSL method to offload host
> name verification to OpenSSL. The improvement [1] eventually landed in
> Python 3.7. Nowadays OpenSSL verifies host name or IP address during the
> TLS/SSL handshake.
>
> Later I discovered that LibreSSL <= 2.6 did not have
> X509_VERIFY_PARAM_set1_host() [2]. We had to temporarily suspend support
> for LibreSSL. About two months later, LibreSSL caught up and released
> version 2.7.0 with support for the function.
>
>
> The bug
> ---
>
> One day after the release of LibreSSL 2.7.0, I started to port Python
> 3.7 to LibreSSL. In matter of minutes I got the ssl module to compile
> and work with LibreSSL. All tests were passing -- except for negative
> the host name verification tests. LibreSSL was accepting all invalid
> host names as correct! Python's vigorous test suite had discovered a
> critical security bug in LibreSSL.
>
> It turned out that LibreSSL copied the implementation of
> X509_VERIFY_PARAM_set1_host(param, name, namelen) from BoringSSL and the
> documentation from OpenSSL. BoringSSL's implementation didn't support
> the special case of 0 as namelen parammeter. OpenSSL supports namelen =
> 0, which is interpreted as namelen=strlen(name). It is documented in
> OpenSSL's man page and was even recommended on OpenSSL's wiki as
> preferred way.
>
>
> Happy Ending
> 
>
> So I got in contact with LibreSSL's security team and BoringSSL's
> security team [3]. Less than a day later, both libraries released fixes
> for the bug [4]. Mitre has assigned CVE-2018-8970 [5] to the bug.
> Disaster averted!
>
> BoringSSL's security issue [3] contains more information. Adam Langley
> lifted the restriction about an hour ago.
>
> I like to thank Bob Beck (LibreSSL), Adam Langley (Google) and David
> Benjamin (Google) for their assistance and cooperation.
>
> Regards,
> Christian
>
> [1] https://bugs.python.org/issue31399
> [2] https://github.com/libressl-portable/portable/issues/381
> [3] https://bugs.chromium.org/p/chromium/issues/detail?id=824799
> [4] https://www.libressl.org/releases.html
> [5] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8970
>
> ___
> 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/brett%40python.org
>
___
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] gdb support could use some love

[Brett Cannon]

On Thu, 5 Apr 2018 at 02:49 Skip Montanaro  wrote:

> > There are a bunch of open issues regarding gdb support including one
> with a PR in need of review for 3.6+.
>
> I rejected one (which assumed everyone now uses a python-aware gdb),
> commented on another (ceval.c-related name changes in several
> commands), and created a PR for third (documentation for the
> user-defined commands). Unfortunately, it's been so long since I
> contributed, I don't quite understand the ins and outs of the workflow
> anymore. In particular, I could find no way to add the "skip news"
> label.


There's a "Labels" section in the right-hand column. You can click "Labels"
and a drop-down of available and selected labels will show up.

-Brett



> I'm afraid someone might have to intervene here:
>
> https://github.com/python/cpython/pull/6384
>
> Skip
> ___
> 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/brett%40python.org
>
___
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] gdb support could use some love

[Ned Deily]

On Apr 5, 2018, at 12:35, Brett Cannon  wrote:
> On Thu, 5 Apr 2018 at 02:49 Skip Montanaro  wrote:
>> > There are a bunch of open issues regarding gdb support including one with 
>> > a PR in need of review for 3.6+.
>> 
>> I rejected one (which assumed everyone now uses a python-aware gdb),
>> commented on another (ceval.c-related name changes in several
>> commands), and created a PR for third (documentation for the
>> user-defined commands). Unfortunately, it's been so long since I
>> contributed, I don't quite understand the ins and outs of the workflow
>> anymore. In particular, I could find no way to add the "skip news"
>> label.
> There's a "Labels" section in the right-hand column. You can click "Labels" 
> and a drop-down of available and selected labels will show up.

Modifying GitHub Labels is only available to people with commit privs and, 
IIRC, Skip asked to drop his commit privs a few years ago (although I'm sure we 
would all be happy to welcome him back!).

> I'm afraid someone might have to intervene here:
> 
> https://github.com/python/cpython/pull/6384

Thanks for pushing that!  It's now merged.

--
  Ned Deily
  n...@python.org -- []

___
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] ssl module and LibreSSL CVE-2018-8970

[Wes Turner]

+1. Thanks!

Which tests?

On Wednesday, April 4, 2018, Christian Heimes  wrote:

> Hi,
>
> I like to share the story of a critical security bug with you. Contrary
> to other issues in TLS/SSL, it's a story with happy ending. Nobody was
> harmed. The bug was fixed before it affected the general population.
>
>
> Introduction
> 
>
> Python's ssl.match_hostname() function was a source of several CVEs and
> other security bugs. After a long struggle, I decided to drop support
> for old OpenSSL releases and uses a new OpenSSL method to offload host
> name verification to OpenSSL. The improvement [1] eventually landed in
> Python 3.7. Nowadays OpenSSL verifies host name or IP address during the
> TLS/SSL handshake.
>
> Later I discovered that LibreSSL <= 2.6 did not have
> X509_VERIFY_PARAM_set1_host() [2]. We had to temporarily suspend support
> for LibreSSL. About two months later, LibreSSL caught up and released
> version 2.7.0 with support for the function.
>
>
> The bug
> ---
>
> One day after the release of LibreSSL 2.7.0, I started to port Python
> 3.7 to LibreSSL. In matter of minutes I got the ssl module to compile
> and work with LibreSSL. All tests were passing -- except for negative
> the host name verification tests. LibreSSL was accepting all invalid
> host names as correct! Python's vigorous test suite had discovered a
> critical security bug in LibreSSL.
>
> It turned out that LibreSSL copied the implementation of
> X509_VERIFY_PARAM_set1_host(param, name, namelen) from BoringSSL and the
> documentation from OpenSSL. BoringSSL's implementation didn't support
> the special case of 0 as namelen parammeter. OpenSSL supports namelen =
> 0, which is interpreted as namelen=strlen(name). It is documented in
> OpenSSL's man page and was even recommended on OpenSSL's wiki as
> preferred way.
>
>
> Happy Ending
> 
>
> So I got in contact with LibreSSL's security team and BoringSSL's
> security team [3]. Less than a day later, both libraries released fixes
> for the bug [4]. Mitre has assigned CVE-2018-8970 [5] to the bug.
> Disaster averted!
>
> BoringSSL's security issue [3] contains more information. Adam Langley
> lifted the restriction about an hour ago.
>
> I like to thank Bob Beck (LibreSSL), Adam Langley (Google) and David
> Benjamin (Google) for their assistance and cooperation.
>
> Regards,
> Christian
>
> [1] https://bugs.python.org/issue31399
> [2] https://github.com/libressl-portable/portable/issues/381
> [3] https://bugs.chromium.org/p/chromium/issues/detail?id=824799
> [4] https://www.libressl.org/releases.html
> [5] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8970
>
> ___
> 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/
> wes.turner%40gmail.com
>
___
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] gdb support could use some love

[Terry Reedy]

On 4/5/2018 5:47 AM, Skip Montanaro wrote:

There are a bunch of open issues regarding gdb support including one with a PR 
in need of review for 3.6+.


I rejected one (which assumed everyone now uses a python-aware gdb),
commented on another (ceval.c-related name changes in several
commands), and created a PR for third (documentation for the
user-defined commands). Unfortunately, it's been so long since I
contributed, I don't quite understand the ins and outs of the workflow
anymore. In particular, I could find no way to add the "skip news"
label. I'm afraid someone might have to intervene here:

https://github.com/python/cpython/pull/6384


You created the PR from your local python repository master branch.  I 
have done this, with negative consequences.  I believe you will find 
life with git easier if you never edit your master branch, or at least, 
never make local commits to it, and only commit to and create PRs from 
special-purpose patch branches, as described in the devguide.


--
Terry Jan Reedy

___
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] gdb support could use some love

[Ned Deily]

On Apr 5, 2018, at 14:48, Terry Reedy  wrote:
> On 4/5/2018 5:47 AM, Skip Montanaro wrote:
>>> There are a bunch of open issues regarding gdb support including one with a 
>>> PR in need of review for 3.6+.
>> I rejected one (which assumed everyone now uses a python-aware gdb),
>> commented on another (ceval.c-related name changes in several
>> commands), and created a PR for third (documentation for the
>> user-defined commands). Unfortunately, it's been so long since I
>> contributed, I don't quite understand the ins and outs of the workflow
>> anymore. In particular, I could find no way to add the "skip news"
>> label. I'm afraid someone might have to intervene here:
>> https://github.com/python/cpython/pull/6384
> 
> You created the PR from your local python repository master branch.  I have 
> done this, with negative consequences.  I believe you will find life with git 
> easier if you never edit your master branch, or at least, never make local 
> commits to it, and only commit to and create PRs from special-purpose patch 
> branches, as described in the devguide.

That's a good observation, Terry.  The main problem is that, when a core 
developer merges the PR from your local repo to the main python/cpython repo, 
we do a squash merge which means that the change or changes committed in the 
python/cpython and included in the PR will end up with a single new hash id 
that differs from what you originally committed in your cpython fork.  So the 
next time you pull to your cpython fork (conventionally "origin") from the main 
cpython repo ("upstream"), there will be a conflict on the "normal" branch, 
i.e. master, 3.7, etc, requiring a merge or rebase, but you don't want to do 
that since the change is already upstream.

Once the PR is merged into the main cpython repo, you can fix the problem by 
force removing the original commit(s) from the "normal" branch in your forked 
repo.  See for example:

https://stackoverflow.com/questions/9646167/clean-up-a-fork-and-restart-it-from-the-upstream

--
  Ned Deily
  n...@python.org -- []

___
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] gdb support could use some love

[Skip Montanaro]

> You created the PR from your local python repository master branch.  I have
> done this, with negative consequences.  I believe you will find life with
> git easier if you never edit your master branch, or at least, never make
> local commits to it, and only commit to and create PRs from special-purpose
> patch branches, as described in the devguide.

Thanks. I clearly need to brush up on workflow and etiquette.

Skip
___
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] gdb support could use some love

[Skip Montanaro]

> Modifying GitHub Labels is only available to people with commit privs and, 
> IIRC, Skip asked to drop his commit privs a few years ago (although I'm sure 
> we would all be happy to welcome him back!).

Alas, then I would feel some obligation to be semi-responsive to buggy
things in areas where I have some interest. I'd really rather be out
on my bike. :-)

S
___
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

[Python-Dev] GH-6392: Enum, __contains__, TypeError, and DeprecationWarnings

[Ethan Furman]

Oh my!  ;)

So, after the previous discussion about when __contains__ should raise TypeError instead of returning False, it seems 
there are a couple cases where a TypeError should be raised now:


1)  non-enum-instance in EnumClass
2)  anything in enum_instance
3)  non-flag-instance in flag instance

(1) can be True/False if an Enum instance is checked for;
(2) should (and does already) always raise TypeError;
(3) can be True/False when a Flag instance is checked for in another flag 
instance.

I suspect these are corner cases, and infrequently, if ever, being used incorrectly now, but I would rather have a 
deprecation period in 3.7 instead of just changing in 3.8 to TypeErrors.  To that end I have a PR [1] readay, and would 
appreciate any review, thoughts, and/or comments.


--
~Ethan~

[1] https://github.com/python/cpython/pull/6392
___
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

[Python-Dev] Timeline for Pull request reviews in 3.8

[Anthony Flury via Python-Dev]

Can anyone enlighten me on what the expected time-line is for reviewing 
pull requests made on 3.8.


I made a few simple fixes in Early March - and I understand everyone is 
busy.


What is the time line and cut off dates for backports to 3.7 and 3.6.

I also made a documentation change (based on a open bug report) into 
2.7, and I am keen to understand the planned time-line for those too.


--
Anthony Flury
email : *anthony.fl...@btinternet.com*
Twitter : *@TonyFlury *
___
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] Are undocumented functions part of the stable ABI?

[Guido van Rossum]

As you may guess from the silence, it may be hard to get a definitive
answer to this question -- PEP 384's author has stopped actively
participating in the Python community and I'm not sure if any core
developers currently consider themselves to be the "guardians of the ABI".

That said, from a quick skim of PEP 384 it seems to be quite strict in its
position that anything not explicitly included by the PEP should be
considered not part of the ABI, which makes me think that only a few
PyCFunction related items are considered part of the ABI (searching for
PyCFunction only finds three hits). OTOH it states that if Py_LIMITED_API
is defined, all definitions that are not part of the ABI will be hidden. So
from that (plus the source code) you should be able to tell which
PyCFunction_* functions are part of the ABI -- again it does not appear the
documentation status of a function matters for this rule.

On the third hand, PEP 384 references a file "python3.def" (
https://www.python.org/dev/peps/pep-0384/#id5) and that file contains
several PyCFunction_* names. Maybe this is the hard rule you're looking
for? Again, being documented is not a requirement.

Another observation would be that (AFAICT) PEP 384 strictly forbids
signature changes, but is mostly silent on semantics.

On Wed, Apr 4, 2018 at 10:34 PM, Jeroen Demeyer  wrote:

> On 2018-04-04 17:56, Guido van Rossum wrote:
>
>> It would be helpful if you explained the context of your request.
>>
>
> The context is PEP 575. I guess my question is mostly about
> PyCFunction_Check(). I will not be able to keep it 100% backwards
> compatible simply because the goal of that PEP is precisely changing the
> classes of some objects.
>
> Now the question is: am I allowed to change the implementation of
> PyCFunction_Check()? If it's considered part of the stable ABI, then the
> answer is immediately "no".
>
> By the way, does anybody happen to know why the PyCFunction_* functions
> are undocumented? Is it just an oversight in the docs or is it intentional?
>
> But regardless of the context, I think that the question "Are undocumented
> functions part of the stable ABI?" should be answered in PEP 384.
>
>
>
> Jeroen.
> ___
> 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/guido%
> 40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
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] Python version numbers

[Stephen J. Turnbull]

Barry Warsaw writes:

 > Python 21.12 anyone? :) 

Well, for one thing we know that version 42 will be perfect!  With
current versioning policy, it will take a loong time to get
there

Steve

-- 
Associate Professor  Division of Policy and Planning Science
http://turnbull/sk.tsukuba.ac.jp/ Faculty of Systems and Information
Email: turnb...@sk.tsukuba.ac.jp   University of Tsukuba
Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN
___
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