Branches in which to fix the SSL tests
Currently some SSL tests in the test suite are broken by a recent certificate change at https://svn.python.org/; see <https://bugs.python.org/issue25940> for the bug report. The tests are broken when the test suite is run with the “-unetwork” option enabled, and most of the buildbots appear to be affected. (In 3.6 the tests have temporarily been disabled as a workaround.) I have a simple patch that subsitutes the old root certificate for the new which I would like to commit, but I’m not sure which branches to apply it to, or even which branches are open to normal maintainence and bug fixes. According to Larry <https://mail.python.org/pipermail/python-dev/2015-December/142566.html>, 3.4.4 was the last bug fix release for 3.4, so I assumed the 3.4 branch should now be in security-fixes-only mode. However this branch still seems to get a lot of non-security action, for example the most recent bunch of changes were some work on the provisional “pathlib” module. So firstly I would like some clarification on the status of 3.4 and what its future is. Secondly, I would normally say a fix for the test suite isn’t really appropriate for the older security branches. But in the bug report, Koobs specifically requested this be fixed in 3.4 and possibly earlier branches as well. What do others think about this?
On Wed, Jan 6, 2016 at 7:06 PM, Martin Panter <vadmium+py@gmail.com> wrote:
To me Larry's email mainly indicates that we're not going to do more binary releases in the 3.4 branch. The work I did on pathlib is probably never going to be released in that branch -- but since I merged it into 3.5 it's not going to waste, and the effort was pretty minimal. (And people *could* still pick it up from the source.)
It should definitely be fixed in 2.7, 3.5 and 3.6. If you want to do it in 3.4 too that sounds totally fine (it's just one extra merge). Are there still any active buildbots for 3.4? The question is, why? I guess one reason might be to ensure that if we *do* have to do an emergency release of 3.4 (it's always a possibility), it would be easier if the tests were all known to be passing, otherwise doing a release (even a source-only release) would be a big hassle. OTOH if we don't make changes the tests will generally not start failing -- the current issue notwithstanding. :-) So if buildbots are a scarce resource it's fine to repurpose them for more recent releases. Oh, finally. I'm eager to answer this but I'm not actually the best resource here -- I'm pretty rusty where it comes to our build and test practices. -- --Guido van Rossum (python.org/~guido)
On Jan 6, 2016, at 23:17, Guido van Rossum <guido@python.org> wrote:
The Developer's Guide describes current practices for backporting of fixes to security-fix branches (https://docs.python.org/devguide/devcycle.html#security-branches): "The only changes made to a security branch are those fixing issues exploitable by attackers such as crashes, privilege escalation and, optionally, other issues such as denial of service attacks. Any other changes are **not** considered a security risk and thus not backported to a security branch." Benjamin brings up a good point, though, about the importance of fixing hard-failures in the test suite. I've added the following to the above paragraph in the guide: "You should also consider fixing hard-failing tests in open security branches since it is important to be able to run the tests successfully before releasing." Also, I've tried to update the information in the Developer's Guide regarding branches and releases to match the current state of the world, e.g. 3.6 is the feature release under development, 3.5 and 2.7 are the current maintenance branches, and the current security-fix-only branches are 3.4, 3.3, and (for one more month) 3.2. (The web site should update within the next day.) Hope that helps! --Ned -- Ned Deily nad@python.org -- []
On 07.01.2016 04:06, Martin Panter wrote:
As mentioned on the issue tracker I'm not convinced that your patch is a good solution going forward. Rather than basing the test on svn.python.org, which can change again in the future, we should use the domain we have specifically reserved for stdlib tests, namely pythontest.net and get this set up in a way so that we can run SSL tests again. I can help with getting SSL certificates for pythontest.net, since I'm managing the PSF SSL certificates (well, trying to keep those managed anyway ;-) - I was not involved in the choice of new CA for svn.python.org): https://wiki.python.org/psf/PSF%20SSL%20Certificates Regarding which branches to apply the final fix, others have already chimed in. Essentially, any branch which we'll need to run tests on in the foreseeable future will need to be fixed, since the change in svn.python.org's SSL setup (the expired certificate which caused the tests to fail was replaced with a new one from a different CA, again causing tests to fail) affects all released test suites. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Jan 07 2016)
::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/
On 7 January 2016 at 09:57, M.-A. Lemburg <mal@egenix.com> wrote:
I agree my first patch is not really sustainable; I only thought of it as a temporary workaround. If we want to change to pythontest.net, it seems there is already an SSL certificate set up with https://self-signed.pythontest.net, already used by other tests. If people want, I should be able to make a straightforward patch to switch to that. But I would prefer to go with something like my newer local-server.v2.patch, which essentially switches to a local server run for the duration of each test. It is just a question of finding someone to review my changes.
Yes, it seems that is a reasonable conclusion. In this case that would indeed mean all branches including 3.2. Thanks everyone for the input.
On 07.01.2016 17:52, Brett Cannon wrote:
+1
-- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Jan 07 2016)
::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/
On 01/06/2016 10:06 PM, Martin Panter wrote:
You assume correctly.
I haven't looked at the changes you mention (I'm on a trip) but... what am I to do? Beyond tagging all future 3.4 releases from a repository only I have write access to and never pulling from hg.python.org, I don't really have any power to enforce the condition. I'm left trusting the better judgment of the Python core dev community. I feel like a parent who's caught his kid reading after bedtime using a flashlight under the covers. I mean, no, that's not what you should be doing right now. But fixing bugs in Python is hardly the worst thing in the world. //arry/
Hi, 2016-01-07 17:32 GMT+01:00 Larry Hastings <larry@hastings.org>:
Would it be possible to have a (clear and up to date) table like http://docs.openstack.org/releases/ in the Developer Guide? List of Python versions with their status (end of life, security supported, current stable release, under development). Victor
On 8 January 2016 at 05:38, Ned Deily <nad@python.org> wrote:
PHP's support status page is one of the nicest examples of this I've seen (someone mentioned it last time this question came up): http://php.net/supported-versions.php Like a lot of things though, "yes, that's a good idea" is easy, having it actually get to the top of someone's todo list is a different question :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Wed, Jan 6, 2016 at 7:06 PM, Martin Panter <vadmium+py@gmail.com> wrote:
To me Larry's email mainly indicates that we're not going to do more binary releases in the 3.4 branch. The work I did on pathlib is probably never going to be released in that branch -- but since I merged it into 3.5 it's not going to waste, and the effort was pretty minimal. (And people *could* still pick it up from the source.)
It should definitely be fixed in 2.7, 3.5 and 3.6. If you want to do it in 3.4 too that sounds totally fine (it's just one extra merge). Are there still any active buildbots for 3.4? The question is, why? I guess one reason might be to ensure that if we *do* have to do an emergency release of 3.4 (it's always a possibility), it would be easier if the tests were all known to be passing, otherwise doing a release (even a source-only release) would be a big hassle. OTOH if we don't make changes the tests will generally not start failing -- the current issue notwithstanding. :-) So if buildbots are a scarce resource it's fine to repurpose them for more recent releases. Oh, finally. I'm eager to answer this but I'm not actually the best resource here -- I'm pretty rusty where it comes to our build and test practices. -- --Guido van Rossum (python.org/~guido)
On Jan 6, 2016, at 23:17, Guido van Rossum <guido@python.org> wrote:
The Developer's Guide describes current practices for backporting of fixes to security-fix branches (https://docs.python.org/devguide/devcycle.html#security-branches): "The only changes made to a security branch are those fixing issues exploitable by attackers such as crashes, privilege escalation and, optionally, other issues such as denial of service attacks. Any other changes are **not** considered a security risk and thus not backported to a security branch." Benjamin brings up a good point, though, about the importance of fixing hard-failures in the test suite. I've added the following to the above paragraph in the guide: "You should also consider fixing hard-failing tests in open security branches since it is important to be able to run the tests successfully before releasing." Also, I've tried to update the information in the Developer's Guide regarding branches and releases to match the current state of the world, e.g. 3.6 is the feature release under development, 3.5 and 2.7 are the current maintenance branches, and the current security-fix-only branches are 3.4, 3.3, and (for one more month) 3.2. (The web site should update within the next day.) Hope that helps! --Ned -- Ned Deily nad@python.org -- []
On 07.01.2016 04:06, Martin Panter wrote:
As mentioned on the issue tracker I'm not convinced that your patch is a good solution going forward. Rather than basing the test on svn.python.org, which can change again in the future, we should use the domain we have specifically reserved for stdlib tests, namely pythontest.net and get this set up in a way so that we can run SSL tests again. I can help with getting SSL certificates for pythontest.net, since I'm managing the PSF SSL certificates (well, trying to keep those managed anyway ;-) - I was not involved in the choice of new CA for svn.python.org): https://wiki.python.org/psf/PSF%20SSL%20Certificates Regarding which branches to apply the final fix, others have already chimed in. Essentially, any branch which we'll need to run tests on in the foreseeable future will need to be fixed, since the change in svn.python.org's SSL setup (the expired certificate which caused the tests to fail was replaced with a new one from a different CA, again causing tests to fail) affects all released test suites. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Jan 07 2016)
::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/
On 7 January 2016 at 09:57, M.-A. Lemburg <mal@egenix.com> wrote:
I agree my first patch is not really sustainable; I only thought of it as a temporary workaround. If we want to change to pythontest.net, it seems there is already an SSL certificate set up with https://self-signed.pythontest.net, already used by other tests. If people want, I should be able to make a straightforward patch to switch to that. But I would prefer to go with something like my newer local-server.v2.patch, which essentially switches to a local server run for the duration of each test. It is just a question of finding someone to review my changes.
Yes, it seems that is a reasonable conclusion. In this case that would indeed mean all branches including 3.2. Thanks everyone for the input.
On 07.01.2016 17:52, Brett Cannon wrote:
+1
-- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Jan 07 2016)
::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/
On 01/06/2016 10:06 PM, Martin Panter wrote:
You assume correctly.
I haven't looked at the changes you mention (I'm on a trip) but... what am I to do? Beyond tagging all future 3.4 releases from a repository only I have write access to and never pulling from hg.python.org, I don't really have any power to enforce the condition. I'm left trusting the better judgment of the Python core dev community. I feel like a parent who's caught his kid reading after bedtime using a flashlight under the covers. I mean, no, that's not what you should be doing right now. But fixing bugs in Python is hardly the worst thing in the world. //arry/
Hi, 2016-01-07 17:32 GMT+01:00 Larry Hastings <larry@hastings.org>:
Would it be possible to have a (clear and up to date) table like http://docs.openstack.org/releases/ in the Developer Guide? List of Python versions with their status (end of life, security supported, current stable release, under development). Victor
On 8 January 2016 at 05:38, Ned Deily <nad@python.org> wrote:
PHP's support status page is one of the nicest examples of this I've seen (someone mentioned it last time this question came up): http://php.net/supported-versions.php Like a lot of things though, "yes, that's a good idea" is easy, having it actually get to the top of someone's todo list is a different question :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (9)
-
Benjamin Peterson -
Brett Cannon -
Guido van Rossum -
Larry Hastings -
M.-A. Lemburg -
Martin Panter -
Ned Deily -
Nick Coghlan -
Victor Stinner