[Python-Dev] Reminder: 3.6.0a4 snapshot 2016-08-15 12:00 UTC

2016-08-13 Thread Ned Deily 
The next and final alpha snapshot planned for the 3.6 release cycle is coming 
up soon.  Keep in mind that the feature development phase of the 3.6 release 
cycle is nearing an end.  The next major milestone is a big one: the first beta 
shapshot, 3.6.0b1, scheduled for Monday, 09-12, a little over four weeks from 
now.  That will mark the end of the unrestricted feature development phase and 
the start of the bugfix/stabilization/testing phase.  All feature code for 
3.6.0 should be checked in by b1.  During the beta phase, the emphasis will be 
on fixes for new features, fixes for all categories of bugs and regressions, 
and documentation fixes/updates.  After b1, new features should be targeted for 
3.7; more details will be forthcoming by b1.

As a reminder, alpha releases are intended to make it easier for the wider 
community to test the current state of new features and bug fixes for an 
upcoming Python release as a whole and for us to test the release process.  
During the alpha phase, features may be added, modified, or deleted up until 
the start of the beta phase.  Alpha users beware!

To recap:

2016-08-15 ~12:00 UTC: code snapshot for 3.6.0 alpha 4.

now to 2016-09-12: Alpha phase (unrestricted feature development)

2016-09-12: 3.6.0 feature code freeze, 3.7.0 feature development begins

2016-09-12 to 2016-12-04: 3.6.0 beta phase (bug and regression fixes, no new 
features)

2016-12-04 3.6.0 release candidate 1 (3.6.0 code freeze)

2016-12-16 3.6.0 release (3.6.0rc1 plus, if necessary, any dire emergency fixes)


https://www.python.org/dev/peps/pep-0494/

--Neτ

--
  Ned Deily
  [email protected] -- []

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

[Python-Dev] Issues in Python TLS

2016-08-13 Thread Mauri Miettinen 
Hello,

We are experimenting with a tool for inspecting how well languages and
libraries support server certificate verification when establishing TLS
connections.

We are getting rather confusing results in our first major shootout of
bundled CPython 2 and 3 versions in major, still supported OS
distributions. We would love to get any insight into the test stubs and
results. Maybe we are doing something horribly wrong?

Python 2 and 3 with Requests

Our stub code:
https://github.com/ouspg/trytls/blob/v0.2.1/stubs/python-requests/run.py 


This is good news. All major distributions successfully check the TLS
certificates in all corner cases tested by the TryTLS. It was good news
that most distros also support SNI with this combination, the only
exceptions being CentOS 6.8, Ubuntu 12.04.5 and Ubuntu 14.04.

Python 2 with urllib2

Our stub code:
https://github.com/ouspg/trytls/blob/v0.2.1/stubs/python-urllib2/run.py 


Alpine Edge, Alpine 3.1, Debian 8.5, Fedora 24 and Ubuntu 16.04 pass
with flying colors.

On the other hand on CentOS 7.2 the test code accepts expired certificates,
wrong hostnames, self-signed certificates and incomplete chains of trust.
For CentOS 7.2 results see
https://github.com/ouspg/trytls/tree/shootout-0.2/shootout/centos7#python-urllib2
 


It's worth noting that when any CA-bundle is given the situation improves.
However, since the stub works on the most distributions as expected, this
might be overlooked by the developers?

Python 3 with urllib

Our stub code:
https://github.com/ouspg/trytls/blob/v0.2.1/stubs/python3-urllib/run.py

Alpine Edge, CentOS 6.8, CentOS 7.2 and Ubuntu 16.04 pass with flying
colors.

On Debian 8.5, Ubuntu 14.04 and Ubuntu 12.04 the test code accepts
expired certificates, wrong hostnames, self-signed certificates and
incomplete chains of trust. For Debian 8.5 results see
https://github.com/ouspg/trytls/tree/shootout-0.2/shootout/debian-latest#python3-urllib

Again it is worth noting that if any CA-bundle is given then situation
improves. Some experimentation we did with the test code suggests
that:

```
urllib.request.urlopen("https://"; + host + ":" + port, cafile=None) -> 
DANGEROUS?
urllib.request.urlopen("https://"; + host + ":" + port) -> DANGEROUS?
urllib.request.urlopen("https://"; + host + ":" + port, cafile=None, 
cadefault=False) -> DANGEROUS?
urllib.request.urlopen("https://"; + host + ":" + port, cafile="/anyfile", 
cadefault=False) -> SAFE
urllib.request.urlopen("https://"; + host + ":" + port, cafile=None, 
cadefault=True) -> SAFE
urllib.request.urlopen("https://"; + host + ":" + port, cadefault=True) -> SAFE
urllib.request.urlopen("https://"; + host + ":" + port, cafile="/anyfile") -> 
SAFE
```

Summary

Our results overview is available from:
https://github.com/ouspg/trytls/tree/shootout-0.2/shootout 


People developing Python code that uses TLS might bump into nasty
surprises with how differently bundled Python versions behave between modern 
and supported distributions. Or are we just simply doing something horribly 
wrong?

Any feedback would be very welcome, as will try to do an updated
shootout with new TryTLS version next week. We would love to get
as fair, clean and comparable results as possible. Moreover, if you
can recommend any docs on proper "Do's and Don'ts" we'd love a link
to them.

Thank you very much,

Mauri Miettinen

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

Re: [Python-Dev] Issues in Python TLS

2016-08-13 Thread Benjamin Peterson 
Correctness of TLS certificate verification is known to depend deeply on
distribution. Python began to verify certificates by default only in in
version 2.7.9. Many OS distributions (in particular, Ubuntu) did not
enable verification for their stable distributions for backwards
compatibility reasons. You might find looking at distro bugs for
CVE-2014-9365 edifying.

Thank you for your work.

On Sat, Aug 13, 2016, at 03:56, Mauri Miettinen wrote:
> Hello,
> 
> We are experimenting with a tool for inspecting how well languages and
> libraries support server certificate verification when establishing TLS
> connections.
> 
> We are getting rather confusing results in our first major shootout of
> bundled CPython 2 and 3 versions in major, still supported OS
> distributions. We would love to get any insight into the test stubs and
> results. Maybe we are doing something horribly wrong?
> 
> Python 2 and 3 with Requests
> 
> Our stub code:
> https://github.com/ouspg/trytls/blob/v0.2.1/stubs/python-requests/run.py
> 
> 
> This is good news. All major distributions successfully check the TLS
> certificates in all corner cases tested by the TryTLS. It was good news
> that most distros also support SNI with this combination, the only
> exceptions being CentOS 6.8, Ubuntu 12.04.5 and Ubuntu 14.04.
> 
> Python 2 with urllib2
> 
> Our stub code:
> https://github.com/ouspg/trytls/blob/v0.2.1/stubs/python-urllib2/run.py
> 
> 
> Alpine Edge, Alpine 3.1, Debian 8.5, Fedora 24 and Ubuntu 16.04 pass
> with flying colors.
> 
> On the other hand on CentOS 7.2 the test code accepts expired
> certificates,
> wrong hostnames, self-signed certificates and incomplete chains of trust.
> For CentOS 7.2 results see
> https://github.com/ouspg/trytls/tree/shootout-0.2/shootout/centos7#python-urllib2
> 
> 
> It's worth noting that when any CA-bundle is given the situation
> improves.
> However, since the stub works on the most distributions as expected, this
> might be overlooked by the developers?
> 
> Python 3 with urllib
> 
> Our stub code:
> https://github.com/ouspg/trytls/blob/v0.2.1/stubs/python3-urllib/run.py
> 
> Alpine Edge, CentOS 6.8, CentOS 7.2 and Ubuntu 16.04 pass with flying
> colors.
> 
> On Debian 8.5, Ubuntu 14.04 and Ubuntu 12.04 the test code accepts
> expired certificates, wrong hostnames, self-signed certificates and
> incomplete chains of trust. For Debian 8.5 results see
> https://github.com/ouspg/trytls/tree/shootout-0.2/shootout/debian-latest#python3-urllib
> 
> Again it is worth noting that if any CA-bundle is given then situation
> improves. Some experimentation we did with the test code suggests
> that:
> 
> ```
> urllib.request.urlopen("https://"; + host + ":" + port, cafile=None) ->
> DANGEROUS?
> urllib.request.urlopen("https://"; + host + ":" + port) -> DANGEROUS?
> urllib.request.urlopen("https://"; + host + ":" + port, cafile=None,
> cadefault=False) -> DANGEROUS?
> urllib.request.urlopen("https://"; + host + ":" + port, cafile="/anyfile",
> cadefault=False) -> SAFE
> urllib.request.urlopen("https://"; + host + ":" + port, cafile=None,
> cadefault=True) -> SAFE
> urllib.request.urlopen("https://"; + host + ":" + port, cadefault=True) ->
> SAFE
> urllib.request.urlopen("https://"; + host + ":" + port, cafile="/anyfile")
> -> SAFE
> ```
> 
> Summary
> 
> Our results overview is available from:
> https://github.com/ouspg/trytls/tree/shootout-0.2/shootout
> 
> 
> People developing Python code that uses TLS might bump into nasty
> surprises with how differently bundled Python versions behave between
> modern and supported distributions. Or are we just simply doing something
> horribly wrong?
> 
> Any feedback would be very welcome, as will try to do an updated
> shootout with new TryTLS version next week. We would love to get
> as fair, clean and comparable results as possible. Moreover, if you
> can recommend any docs on proper "Do's and Don'ts" we'd love a link
> to them.
> 
> Thank you very much,
> 
> Mauri Miettinen
> 
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/benjamin%40python.org
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Changing the licence of statistics.py

2016-08-13 Thread Steven D'Aprano 
I'm the author of statistics.py, and for historical reasons it was 
originally included in the standard library under the Apache licence.

I now wish to change that and have it licenced under Python's standard 
licence. Is there anything I need to do other than just remove the 
Apache licence boilerplate from the file?

(Yes, I've signed the contributor form.)


-- 
Steve
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Changing the licence of statistics.py

2016-08-13 Thread Brett Cannon 
Are you the sole author of the statistics module prior to contributing it,
Steve?

On Sat, Aug 13, 2016, 21:21 Steven D'Aprano  wrote:

> I'm the author of statistics.py, and for historical reasons it was
> originally included in the standard library under the Apache licence.
>
> I now wish to change that and have it licenced under Python's standard
> licence. Is there anything I need to do other than just remove the
> Apache licence boilerplate from the file?
>
> (Yes, I've signed the contributor form.)
>
>
> --
> Steve
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Changing the licence of statistics.py

2016-08-13 Thread Ned Deily 
On Aug 14, 2016, at 00:20, Steven D'Aprano  wrote:
> I'm the author of statistics.py, and for historical reasons it was 
> originally included in the standard library under the Apache licence.
> 
> I now wish to change that and have it licenced under Python's standard 
> licence. Is there anything I need to do other than just remove the 
> Apache licence boilerplate from the file?

I am not a lawyer nor an expert on this but you should read the following 
pages.  It's explained there that the standard licenses for code contributed to 
Python itself *should* be either the Apache 2.0 License or the Academic Free 
License v2.1.

https://www.python.org/psf/contrib/
https://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq

--
  Ned Deily
  [email protected] -- []

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

Re: [Python-Dev] Changing the licence of statistics.py

2016-08-13 Thread Steven D'Aprano 
On Sun, Aug 14, 2016 at 04:27:21AM +, Brett Cannon wrote:

> Are you the sole author of the statistics module prior to contributing it,
> Steve?

Yes.

There has been at least one patch to the module as part of the 
standard library by someone else:

http://bugs.python.org/issue26002

but prior to it hitting the stdlib it was all mine.

-- 
Steve
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com