Re: [Python-Dev] Python 2.7 patch levels turning two digit

[Donald Stufft]

On Jun 21, 2014, at 6:00 PM, Steve Dower  wrote:

> We can always lie about the version in sys.version. Existing code is 
> unaffected and new code will have to use version_info (Windows developers 
> will know that Windows pulls tricks like this every other version... doesn't 
> make it a great idea, but it works).
> 
> Changing compiler without changing at least the install directory and 
> preventing in place upgrades is a really bad idea, and with those mitigations 
> is only pretty bad. I'm torn here, because I know the current situation 
> hurts, but it'd probably only move to VC10 which will hurt just as much in a 
> few years... there are better tooling solutions (yes, I'm working on some 
> behind the scenes).
> 
> A separate distro of _ssl and _hashlib wouldn't be too hard and has the same 
> effect as a dynamically linked OpenSSL. Maybe we can make these PyPI 
> updateable?

Stuff from PyPI installs later on in the sys.path than the stdlib. I wish it 
were different but it means without sys.path shenanigans you can’t replace the 
stdlib with something from PyPI.

> 
> Top-posted from my Windows Phone
> From: M.-A. Lemburg
> Sent: ‎6/‎21/‎2014 14:38
> To: Chris Angelico
> Cc: Python-Dev
> Subject: Re: [Python-Dev] Python 2.7 patch levels turning two digit
> 
> On 21.06.2014 22:34, Chris Angelico wrote:
> > On Sun, Jun 22, 2014 at 2:57 AM, M.-A. Lemburg  wrote:
> >> On 21.06.2014 12:51, Nick Coghlan wrote:
> >>> Such code has an easy fix available, though, as sys.version_info has
> >>> existed since 2.0, and handles two digit micro releases just fine. The
> >>> docs for sys.version also have this explicit disclaimer: "Do not
> >>> extract version information out of it, rather, use version_info and
> >>> the functions provided by the platform module."
> >>
> >> I don't think that's a good argument. Of course, there are
> >> better ways to figure out the version number, but fact is,
> >> existing code, even in the stdlib, does use and parse
> >> the sys.version string version.
> >>
> >> During Python's lifetime, we've always avoided two digit
> >> version numbers, so people have been relying on this, even
> >> if it was never (AFAIK) documented anywhere.
> > 
> > It's going to be a broken-code-breaking change that's introduced in a
> > point release, but since PEP 404 implicitly says that there won't be a
> > 2.10.0, there's no way around that. Although actually, a glance at the
> > stdlib suggests that 2.10.0 (or 3.10.0) would break a lot more than
> > 2.7.10 would break - there are places where sys.version[:3] is used
> > (or equivalents like "... %.3s ..." % sys.version), or a whole-string
> > comparison is done against a two-part version string (eg: sys.version
> >> = "2.6"), and at least one place that checks sys.version[0] for the
> > major version number, but I didn't find any that look at
> > sys.version[:5] or equivalent. Everything that cares about the
> > three-part version number seems to either look at
> > sys.version.split()[0] or sys.version_info. Do you know where this
> > problematic code is?
> > 
> > I checked this in the 2.7.3 stdlib as packaged on my Debian Wheezy
> > system, for what it's worth.
> 
> There are no places in the stdlib that parse sys.version in a
> way that would break wtih 2.7.10, AFAIK. I was just referring
> to the statement that Nick quoted. sys.version *is* used for
> parsing the Python version or using parts of it to build
> e.g. filenames and that's really no surprise.
> 
> That said, and I also included this in my answers to the questions
> that Nick removed in his reply, I don't think that a lot of
> code would be affected by this. I do believe that we can use
> this potential breakage as a chance for improvement. See the last
> question (listed here again)...
> 
> 1. Is it a good strategy to ship to Python releases for every
>single OpenSSL security release or is there a better way to
>handle these 3rd party issues ?
> 
> 2. Should we try to avoid two digit patch level release numbers
>by using some other mechanism such as e.g. a release date
>after 2.7.9 ?
> 
> 3. Should we make use of the potential breakage with 2.7.10
>to introduce a new Windows compiler version for Python 2.7 ?
> 
> My answers to these are: 1. We should use dynamic linking
> instead and not let OpenSSL bugs trigger Python releases; 2.
> It's not a big problem; 3. Yes, please, since it is difficult
> for people to develop and debug their extensions with a
> 2008 compiler, when the rest of the world has long moved on.
> 
> -- 
> Marc-Andre Lemburg
> eGenix.com
> 
> Professional Python Services directly from the Source  (#1, Jun 21 2014)
> >>> Python Projects, Consulting and Support ...   http://www.egenix.com/
> >>> mxODBC.Zope/Plone.Database.Adapter ...   http://zope.egenix.com/
> >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
> 
> 2014-06-17: Released eGenix PyRu

Re: [Python-Dev] Python 2.7 patch levels turning two digit

[Chris Angelico]

On Sun, Jun 22, 2014 at 8:00 AM, Steve Dower  wrote:
> We can always lie about the version in sys.version. Existing code is
> unaffected and new code will have to use version_info (Windows developers
> will know that Windows pulls tricks like this every other version... doesn't
> make it a great idea, but it works).

I'd prefer a change of format to an outright lie. Something like
"2.7._10" which will sort after "2.7.9". But ideally, nothing at all -
just go smoothly to "2.7.10" and let broken code be broken. It'll
think it's running on 2.7.1, and if anything needs to distinguish
between 2.7.1 and 2.7.x, hopefully it's using version_info.

ChrisA
___
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 2.7 patch levels turning two digit

[Chris Angelico]

On Sun, Jun 22, 2014 at 7:37 AM, M.-A. Lemburg  wrote:
> There are no places in the stdlib that parse sys.version in a
> way that would break wtih 2.7.10, AFAIK. I was just referring
> to the statement that Nick quoted. sys.version *is* used for
> parsing the Python version or using parts of it to build
> e.g. filenames and that's really no surprise.

Right, good to know. I thought you were implying that stuff would
break. Yes, stuff definitely does parse out the version number from
sys.version, lots of that happens.

ChrisA
___
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] Python 2.7 patch levels turning two digit

[M.-A. Lemburg]

With PEP 466 and the constant flow of OpenSSL security fixes
which are currently being handled via Python patch level releases,
we will soon reach 2.7.10 and quickly go beyond that (also see
http://bugs.python.org/issue21308).

This opens up a potential backwards incompatibility with existing
tools that assume the Python release version number to use the
"x.y.z" single digit approach, e.g. code that uses sys.version[:5]
for the Python version or relies on the lexicographic ordering
of the version string (sys.version > '2.7.2').

Some questions we should probably ask ourselves (I've added my
thoughts inline):

 * Is it a good strategy to ship to Python releases for every
   single OpenSSL security release or is there a better way to
   handle these 3rd party issues ?

   I think we should link to the OpenSSL libs dynamically rather
   than statically in Python 2.7 for Windows so that it's possible
   to provide drop-in updates for such issues.

 * Should we try to avoid two digit patch level release numbers
   by using some other mechanism such as e.g. a release date
   after 2.7.9 ?

   Grepping through our code, this will introduce some breakage,
   but not much. Most older code branches on minor versions,
   not patch levels. More recent code uses sys.python_info so
   is not affected.

 * Should we make use of the potential breakage with 2.7.10
   to introduce a new Windows compiler version for Python 2.7 ?

   I think this would be a good chance to update the compiler
   to whatever we use for Python 3 at the time.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 21 2014)
>>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ...   http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

2014-06-17: Released eGenix PyRun 2.0.0 ...   http://egenix.com/go58
2014-06-09: Released eGenix pyOpenSSL 0.13.3 ...  http://egenix.com/go57
2014-07-02: Python Meeting Duesseldorf ... 11 days to go

   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/
___
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 2.7 patch levels turning two digit

[Nick Coghlan]

On 21 June 2014 20:27, M.-A. Lemburg  wrote:
> With PEP 466 and the constant flow of OpenSSL security fixes
> which are currently being handled via Python patch level releases,
> we will soon reach 2.7.10 and quickly go beyond that (also see
> http://bugs.python.org/issue21308).
>
> This opens up a potential backwards incompatibility with existing
> tools that assume the Python release version number to use the
> "x.y.z" single digit approach, e.g. code that uses sys.version[:5]
> for the Python version or relies on the lexicographic ordering
> of the version string (sys.version > '2.7.2').

Such code has an easy fix available, though, as sys.version_info has
existed since 2.0, and handles two digit micro releases just fine. The
docs for sys.version also have this explicit disclaimer: "Do not
extract version information out of it, rather, use version_info and
the functions provided by the platform module."

Making it harder to tell whether or not someone's Python installation
is affected by an OpenSSL CVE is also an undesirable outcome. On a
Linux distro, folks will check the distro package database directly
for the OpenSSL version, but on Windows, no such centralised audit
mechanism is available by default. With OpenSSL statically linked,
Python versions can just be mapped to OpenSSL versions (so, for
example, 2.7.7 has 1.0.1g)

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] Python 2.7 patch levels turning two digit

[Barry Warsaw]

On Jun 21, 2014, at 12:27 PM, M.-A. Lemburg wrote:

>This opens up a potential backwards incompatibility with existing
>tools that assume the Python release version number to use the
>"x.y.z" single digit approach, e.g. code that uses sys.version[:5]
>for the Python version or relies on the lexicographic ordering
>of the version string (sys.version > '2.7.2').

Patient: Doctor, it hurts when I do this.
Doctor: Don't do that!

> * Should we try to avoid two digit patch level release numbers
>   by using some other mechanism such as e.g. a release date
>   after 2.7.9 ?
>
>   Grepping through our code, this will introduce some breakage,
>   but not much. Most older code branches on minor versions,
>   not patch levels. More recent code uses sys.python_info so
>   is not affected.

s/sys.python_info/sys.version_info/ and yes the latter has been preferred for
a long time now.

Given that 2.7 is a long term support release, it's inevitable that we'll
break the 2-digit micro release number barrier.  So be it.  A 2.7.10 isn't the
end of the world.

-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] Python 2.7 patch levels turning two digit

[M.-A. Lemburg]

On 21.06.2014 12:51, Nick Coghlan wrote:
> On 21 June 2014 20:27, M.-A. Lemburg  wrote:
>> With PEP 466 and the constant flow of OpenSSL security fixes
>> which are currently being handled via Python patch level releases,
>> we will soon reach 2.7.10 and quickly go beyond that (also see
>> http://bugs.python.org/issue21308).
>>
>> This opens up a potential backwards incompatibility with existing
>> tools that assume the Python release version number to use the
>> "x.y.z" single digit approach, e.g. code that uses sys.version[:5]
>> for the Python version or relies on the lexicographic ordering
>> of the version string (sys.version > '2.7.2').
> 
> Such code has an easy fix available, though, as sys.version_info has
> existed since 2.0, and handles two digit micro releases just fine. The
> docs for sys.version also have this explicit disclaimer: "Do not
> extract version information out of it, rather, use version_info and
> the functions provided by the platform module."

I don't think that's a good argument. Of course, there are
better ways to figure out the version number, but fact is,
existing code, even in the stdlib, does use and parse
the sys.version string version.

During Python's lifetime, we've always avoided two digit
version numbers, so people have been relying on this, even
if it was never (AFAIK) documented anywhere.

> Making it harder to tell whether or not someone's Python installation
> is affected by an OpenSSL CVE is also an undesirable outcome. On a
> Linux distro, folks will check the distro package database directly
> for the OpenSSL version, but on Windows, no such centralised audit
> mechanism is available by default. With OpenSSL statically linked,
> Python versions can just be mapped to OpenSSL versions (so, for
> example, 2.7.7 has 1.0.1g)

I have to disagree here as well :-)

If people cannot upgrade to a higher patch level for whatever
reason (say a patch level release introduced some other bugs),
but still need to upgrade to the current OpenSSL version, they'd
be stuck if we continue to bind the Python version number to
some OpenSSL release version.

We should definitely make it possible to address OpenSSL
bugs without having to upgrade Python and it's not hard to
do: just replace the static binding with dynamic binding
and include the two OpenSSL DLLs with the Windows installer.

People can then drop in new versions of those DLLs
as needed, without having the core devs do a complete
new release every time someone finds a new problem those
libs. Security libs simply have a much higher release
rate (if they are well maintained) than most other
software.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 21 2014)
>>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ...   http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

2014-06-17: Released eGenix PyRun 2.0.0 ...   http://egenix.com/go58
2014-06-09: Released eGenix pyOpenSSL 0.13.3 ...  http://egenix.com/go57
2014-07-02: Python Meeting Duesseldorf ... 11 days to go

   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/
___
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 2.7 patch levels turning two digit

[Ned Deily]

In article <53a5b995.6040...@egenix.com>,
 "M.-A. Lemburg"  wrote:
> > Making it harder to tell whether or not someone's Python installation
> > is affected by an OpenSSL CVE is also an undesirable outcome. On a
> > Linux distro, folks will check the distro package database directly
> > for the OpenSSL version, but on Windows, no such centralised audit
> > mechanism is available by default. With OpenSSL statically linked,
> > Python versions can just be mapped to OpenSSL versions (so, for
> > example, 2.7.7 has 1.0.1g)
> 
> I have to disagree here as well :-)
> 
> If people cannot upgrade to a higher patch level for whatever
> reason (say a patch level release introduced some other bugs),
> but still need to upgrade to the current OpenSSL version, they'd
> be stuck if we continue to bind the Python version number to
> some OpenSSL release version.
> 
> We should definitely make it possible to address OpenSSL
> bugs without having to upgrade Python and it's not hard to
> do: just replace the static binding with dynamic binding
> and include the two OpenSSL DLLs with the Windows installer.
> 
> People can then drop in new versions of those DLLs
> as needed, without having the core devs do a complete
> new release every time someone finds a new problem those
> libs. Security libs simply have a much higher release
> rate (if they are well maintained) than most other
> software.

I agree that with Nick and Barry that, due to the extended support 
period for 2.7, we have no choice but to bite the bullet and deal with 
micro levels exceeding 9.  On the other hand, it would also be good to 
be better able to deal with third-party library revisions that only 
affect the Windows or OS X binary installers we supply.  I don't know 
that we've ever had a process/policy in place to do that, certainly not 
recently.  Even for statically linked libraries, we presumably could 
supply replacement re-linked files or even carefully repacked installers 
with the updated files.  This might be something to discuss and add to 
PEP 101 or a new PEP.

Up to now, this hasn't been a major concern since there have usually 
been other reasons to do full releases as well, e.g. source regressions.  
Given the still relatively high churn rate for changes going into 2.7 
and the growing distance between the 2.7 and 3.x code bases (among other 
things, leading to more frequent inadvertent backporting errors), we'll 
probably need to keep making relatively frequent 2.7 releases unless we 
can further slow down the 2.7 change rate.

-- 
 Ned Deily,
 n...@acm.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] Python 2.7 patch levels turning two digit

[Chris Angelico]

On Sun, Jun 22, 2014 at 2:57 AM, M.-A. Lemburg  wrote:
> On 21.06.2014 12:51, Nick Coghlan wrote:
>> Such code has an easy fix available, though, as sys.version_info has
>> existed since 2.0, and handles two digit micro releases just fine. The
>> docs for sys.version also have this explicit disclaimer: "Do not
>> extract version information out of it, rather, use version_info and
>> the functions provided by the platform module."
>
> I don't think that's a good argument. Of course, there are
> better ways to figure out the version number, but fact is,
> existing code, even in the stdlib, does use and parse
> the sys.version string version.
>
> During Python's lifetime, we've always avoided two digit
> version numbers, so people have been relying on this, even
> if it was never (AFAIK) documented anywhere.

It's going to be a broken-code-breaking change that's introduced in a
point release, but since PEP 404 implicitly says that there won't be a
2.10.0, there's no way around that. Although actually, a glance at the
stdlib suggests that 2.10.0 (or 3.10.0) would break a lot more than
2.7.10 would break - there are places where sys.version[:3] is used
(or equivalents like "... %.3s ..." % sys.version), or a whole-string
comparison is done against a two-part version string (eg: sys.version
>= "2.6"), and at least one place that checks sys.version[0] for the
major version number, but I didn't find any that look at
sys.version[:5] or equivalent. Everything that cares about the
three-part version number seems to either look at
sys.version.split()[0] or sys.version_info. Do you know where this
problematic code is?

I checked this in the 2.7.3 stdlib as packaged on my Debian Wheezy
system, for what it's worth.

ChrisA
___
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 2.7 patch levels turning two digit

[Oleg Broytman]

On Sun, Jun 22, 2014 at 06:34:23AM +1000, Chris Angelico  
wrote:
> Do you know where this problematic code is?

   In many places:

https://encrypted.google.com/search?q=%22sys.version[%3A3]%22

https://encrypted.google.com/search?q=%22sys.version[%3A5]%22

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
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 2.7 patch levels turning two digit

[M.-A. Lemburg]

On 21.06.2014 22:34, Chris Angelico wrote:
> On Sun, Jun 22, 2014 at 2:57 AM, M.-A. Lemburg  wrote:
>> On 21.06.2014 12:51, Nick Coghlan wrote:
>>> Such code has an easy fix available, though, as sys.version_info has
>>> existed since 2.0, and handles two digit micro releases just fine. The
>>> docs for sys.version also have this explicit disclaimer: "Do not
>>> extract version information out of it, rather, use version_info and
>>> the functions provided by the platform module."
>>
>> I don't think that's a good argument. Of course, there are
>> better ways to figure out the version number, but fact is,
>> existing code, even in the stdlib, does use and parse
>> the sys.version string version.
>>
>> During Python's lifetime, we've always avoided two digit
>> version numbers, so people have been relying on this, even
>> if it was never (AFAIK) documented anywhere.
> 
> It's going to be a broken-code-breaking change that's introduced in a
> point release, but since PEP 404 implicitly says that there won't be a
> 2.10.0, there's no way around that. Although actually, a glance at the
> stdlib suggests that 2.10.0 (or 3.10.0) would break a lot more than
> 2.7.10 would break - there are places where sys.version[:3] is used
> (or equivalents like "... %.3s ..." % sys.version), or a whole-string
> comparison is done against a two-part version string (eg: sys.version
>> = "2.6"), and at least one place that checks sys.version[0] for the
> major version number, but I didn't find any that look at
> sys.version[:5] or equivalent. Everything that cares about the
> three-part version number seems to either look at
> sys.version.split()[0] or sys.version_info. Do you know where this
> problematic code is?
> 
> I checked this in the 2.7.3 stdlib as packaged on my Debian Wheezy
> system, for what it's worth.

There are no places in the stdlib that parse sys.version in a
way that would break wtih 2.7.10, AFAIK. I was just referring
to the statement that Nick quoted. sys.version *is* used for
parsing the Python version or using parts of it to build
e.g. filenames and that's really no surprise.

That said, and I also included this in my answers to the questions
that Nick removed in his reply, I don't think that a lot of
code would be affected by this. I do believe that we can use
this potential breakage as a chance for improvement. See the last
question (listed here again)...

1. Is it a good strategy to ship to Python releases for every
   single OpenSSL security release or is there a better way to
   handle these 3rd party issues ?

2. Should we try to avoid two digit patch level release numbers
   by using some other mechanism such as e.g. a release date
   after 2.7.9 ?

3. Should we make use of the potential breakage with 2.7.10
   to introduce a new Windows compiler version for Python 2.7 ?

My answers to these are: 1. We should use dynamic linking
instead and not let OpenSSL bugs trigger Python releases; 2.
It's not a big problem; 3. Yes, please, since it is difficult
for people to develop and debug their extensions with a
2008 compiler, when the rest of the world has long moved on.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 21 2014)
>>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ...   http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

2014-06-17: Released eGenix PyRun 2.0.0 ...   http://egenix.com/go58
2014-06-09: Released eGenix pyOpenSSL 0.13.3 ...  http://egenix.com/go57
2014-07-02: Python Meeting Duesseldorf ... 11 days to go

   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/
___
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 2.7 patch levels turning two digit

[Phil Thompson]

On 21/06/2014 10:37 pm, M.-A. Lemburg wrote:

That said, and I also included this in my answers to the questions
that Nick removed in his reply, I don't think that a lot of
code would be affected by this. I do believe that we can use
this potential breakage as a chance for improvement. See the last
question (listed here again)...

1. Is it a good strategy to ship to Python releases for every
   single OpenSSL security release or is there a better way to
   handle these 3rd party issues ?


Isn't this only a packaging issue? There is no change to the Python API 
or implementation, so there is no need to change the version number. So 
just make new Windows packages.


The precedent is to add a dash and a package number. I can't remember 
what version this was applied to before - but I got a +1 from Guido for 
suggesting it :)


Phil
___
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 2.7 patch levels turning two digit

[Ethan Furman]

On 06/21/2014 02:37 PM, M.-A. Lemburg wrote:


My answers to these are: 1. We should use dynamic linking
instead and not let OpenSSL bugs trigger Python releases; 2.
It's not a big problem; 3. Yes, please, since it is difficult
for people to develop and debug their extensions with a
2008 compiler, when the rest of the world has long moved on.


+1  (assuming not incredibly difficult and those that can are willing ;)

--
~Ethan~
___
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 2.7 patch levels turning two digit

[Steve Dower]

We can always lie about the version in sys.version. Existing code is unaffected 
and new code will have to use version_info (Windows developers will know that 
Windows pulls tricks like this every other version... doesn't make it a great 
idea, but it works).

Changing compiler without changing at least the install directory and 
preventing in place upgrades is a really bad idea, and with those mitigations 
is only pretty bad. I'm torn here, because I know the current situation hurts, 
but it'd probably only move to VC10 which will hurt just as much in a few 
years... there are better tooling solutions (yes, I'm working on some behind 
the scenes).

A separate distro of _ssl and _hashlib wouldn't be too hard and has the same 
effect as a dynamically linked OpenSSL. Maybe we can make these PyPI updateable?

Top-posted from my Windows Phone

From: M.-A. Lemburg
Sent: ‎6/‎21/‎2014 14:38
To: Chris Angelico
Cc: Python-Dev
Subject: Re: [Python-Dev] Python 2.7 patch levels turning two digit

On 21.06.2014 22:34, Chris Angelico wrote:
> On Sun, Jun 22, 2014 at 2:57 AM, M.-A. Lemburg  wrote:
>> On 21.06.2014 12:51, Nick Coghlan wrote:
>>> Such code has an easy fix available, though, as sys.version_info has
>>> existed since 2.0, and handles two digit micro releases just fine. The
>>> docs for sys.version also have this explicit disclaimer: "Do not
>>> extract version information out of it, rather, use version_info and
>>> the functions provided by the platform module."
>>
>> I don't think that's a good argument. Of course, there are
>> better ways to figure out the version number, but fact is,
>> existing code, even in the stdlib, does use and parse
>> the sys.version string version.
>>
>> During Python's lifetime, we've always avoided two digit
>> version numbers, so people have been relying on this, even
>> if it was never (AFAIK) documented anywhere.
>
> It's going to be a broken-code-breaking change that's introduced in a
> point release, but since PEP 404 implicitly says that there won't be a
> 2.10.0, there's no way around that. Although actually, a glance at the
> stdlib suggests that 2.10.0 (or 3.10.0) would break a lot more than
> 2.7.10 would break - there are places where sys.version[:3] is used
> (or equivalents like "... %.3s ..." % sys.version), or a whole-string
> comparison is done against a two-part version string (eg: sys.version
>> = "2.6"), and at least one place that checks sys.version[0] for the
> major version number, but I didn't find any that look at
> sys.version[:5] or equivalent. Everything that cares about the
> three-part version number seems to either look at
> sys.version.split()[0] or sys.version_info. Do you know where this
> problematic code is?
>
> I checked this in the 2.7.3 stdlib as packaged on my Debian Wheezy
> system, for what it's worth.

There are no places in the stdlib that parse sys.version in a
way that would break wtih 2.7.10, AFAIK. I was just referring
to the statement that Nick quoted. sys.version *is* used for
parsing the Python version or using parts of it to build
e.g. filenames and that's really no surprise.

That said, and I also included this in my answers to the questions
that Nick removed in his reply, I don't think that a lot of
code would be affected by this. I do believe that we can use
this potential breakage as a chance for improvement. See the last
question (listed here again)...

1. Is it a good strategy to ship to Python releases for every
   single OpenSSL security release or is there a better way to
   handle these 3rd party issues ?

2. Should we try to avoid two digit patch level release numbers
   by using some other mechanism such as e.g. a release date
   after 2.7.9 ?

3. Should we make use of the potential breakage with 2.7.10
   to introduce a new Windows compiler version for Python 2.7 ?

My answers to these are: 1. We should use dynamic linking
instead and not let OpenSSL bugs trigger Python releases; 2.
It's not a big problem; 3. Yes, please, since it is difficult
for people to develop and debug their extensions with a
2008 compiler, when the rest of the world has long moved on.

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 21 2014)
>>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ...   http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

2014-06-17: Released eGenix PyRun 2.0.0 ...   http://egenix.com/go58
2014-06-09: Released eGenix pyOpenSSL 0.13.3 ...  http://egenix.com/go57
2014-07-02: Python Meeting Duesseldorf ... 11 days to go

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg