On Thursday OpenSSL will disclose some security issues and issue new releases: https://mta.openssl.org/pipermail/openssl-announce/2015-March/000020.html

When that happens, Python's that bundle an OpenSSL should be upgraded.

New changeset 447794596266 by Ned Deily in branch '2.7':
Issue #23686: Update OS X 10.5 installer build to use OpenSSL 1.0.2a.
https://hg.python.org/cpython/rev/447794596266

New changeset 59b8a83ea50b by Ned Deily in branch '3.4':
Issue #23686: Update OS X 10.5 installer build to use OpenSSL 1.0.2a.
https://hg.python.org/cpython/rev/59b8a83ea50b

New changeset e43e5cc887fe by Ned Deily in branch 'default':
Issue #23686: Update OS X 10.5 installer build to use OpenSSL 1.0.2a.
https://hg.python.org/cpython/rev/e43e5cc887fe

1.0.2a is now available.
https://www.openssl.org/source/openssl-1.0.2a.tar.gz

The OS X 10.5 installer builds are now updated.  Leaving the issue open for updates to the Windows installers.

New changeset 05a502da108f by Zachary Ware in branch '2.7':
Issue #23686: Update Windows build to use OpenSSL 1.0.2a
https://hg.python.org/cpython/rev/05a502da108f

New changeset 404e4adf492c by Zachary Ware in branch '3.4':
Issue #23686: Update Windows build to use OpenSSL 1.0.2a.
https://hg.python.org/cpython/rev/404e4adf492c

I've updated 2.7 and 3.4, but 3.5 is a different matter.  Steve, I'll want to take a look at it with you at the sprints; 1.0.2 changed enough that the projects you wrote for OpenSSL broke.

It looks like this killed the AMD64 Windows 7 bots, but everything else is fine (including the 64bit build on my 8.1 box).

I'm suspicious of the version of NASM installed on the bot; Jeremy, can you tell me what version is on there, or if there's anything wonky with externals\openssl-1.0.2a\tmp64\x86_64-mont.asm:866?  If NASM is any older than 2.11.06, it would be best to just uninstall it and let the build use the version it pulls from svn.python.org.

Attached a patch that updates 3.5. Zach - please let me know if I missed something you'd normally do for this.

Looks like that covers it.  The one thing I'm concerned about is that, historically, we've always said "you can point our build system at whatever version of OpenSSL you want and it should work", but obviously this locks us in to 1.0.2+.  Really, there shouldn't be much reason to use anything else, but I'm not sure we want to give up that ability.  I have no idea if anybody actually relies on it though; we could just commit it and backpedal later if anybody complains.

New changeset 1e64d57422ee by Steve Dower in branch 'default':
Closes #23686: Update Windows installer OpenSSL to 1.0.2a
https://hg.python.org/cpython/rev/1e64d57422ee

The ability was already gone with the first round of project changes (hence why we needed more changes for 1.0.2a). Worth keeping in mind, but I certainly appreciate the significantly reduced build time.

Maybe when/if people complain, we can add a switch that lets you link to a prebuilt OpenSSL but won't try and build it.

That works for me.

Of course, the thing we both forgot was NEWS.

Are you sure you want to go with OpenSSL 1.0.2a ? It typically takes a few patch level releases for them to clear out all the major bugs (including security relevant ones).

For egenix-pyopenssl, we've chose to stay with 1.0.1 for the time being until the dust settles on the 1.0.2 branch.

For what it's worth, the resolution of Issue23476 uses an API that was added in OpenSSL 1.0.2.

On 14.04.2015 00:29, Ned Deily wrote:
> 
> For what it's worth, the resolution of Issue23476 uses an API that was added in OpenSSL 1.0.2.

Hmm, I don't think that's a good move at this time.

Most Linux users won't benefit from this since their system OpenSSL
will be 1.0.1 and 1.0.2 still has major security bugs being resolved:

https://www.openssl.org/news/secadv_20150319.txt
(look at the number of 1.0.2 only security bugs)

apart from 1.0.2a being the first 1.0.2 version which works at all:

https://github.com/openssl/openssl/pull/218
(certificate expiry checks not working)

I don't have a really strong feeling one way or the other.  It's not a big issue for the OS X installers as this only affects the much-less-used 32-bit-only installer for old systems.  So this is really primarily an issue affecting the Windows installers.  I guess one could argue that 1.0.2 is the current path forward for OpenSSL particularly over the support lifetime of 3.5.0 and there will be ample opportunity to update as necessary whatever version of the OpenSSL is included, both prior to the 3.5.0 release date and afterwards but there is something to be said for being a bit conservative wrt new OpenSSL release branches.  I think it would be good to solicit the opinion of the other core developers interested in security and the Windows installers and let Larry make the call, if necessary.

Alex, Donald, Antoine, Steve: any comments on shipping 1.0.1x vs 1.0.2x? 


> https://github.com/openssl/openssl/pull/218
> (certificate expiry checks not working)

That issue appears to have been fixed in 1.0.2a, no?

I think 1.0.2 is the only version of OpenSSL that has the ability to short circuit the chain validation which is something that makes it easier for libraries like requests to remove the weak 1024 bit roots from their SSL certificate store.

It's also needed for ALPN support which libraries like hyper will need in order to support HTTP/2.

I'm pretty massively +1 in Python shipping 1.0.2 (or really, whatever the latest OpenSSL is) wherever it can, including the OSX installers even on systems where Apple ships it's ancient OpenSSL.

On 14.04.2015 01:41, Donald Stufft wrote:
> 
> I'm pretty massively +1 in Python shipping 1.0.2 (or really, whatever the latest OpenSSL is) wherever it can, including the OSX installers even on systems where Apple ships it's ancient OpenSSL.

Eventually, yes, but the question is: is jumping on such an early
release of a new OpenSSL branch a good idea.

On 14.04.2015 01:36, Ned Deily wrote:
> 
>> https://github.com/openssl/openssl/pull/218
>> (certificate expiry checks not working)
> 
> That issue appears to have been fixed in 1.0.2a, no?

Yes, but it shows the kind of errors to expect in the early
stages of a new branch. The above was a complete bummer.

However, I'm more concerned about the security issues that
were found so far in the 1.0.2 release. IMO, we should at least
wait for a 1.0.2b or 1.0.2c release before pushing 1.0.2 to
the users - at least for patch level releases of stable Python
versions such as Python 2.7 or 3.4.