[Python-Dev] Remove embedded expat library?

Ned Deily nad at python.org
Fri Jun 9 12:03:26 EDT 2017

On Jun 9, 2017, at 08:43, Victor Stinner <victor.stinner at gmail.com> wrote:
> Python embeds a copy of the expat library which already got two major
> security vulnerabilities:
> "CVE-2016-0718: expat bug #537"
> http://python-security.readthedocs.io/vuln/cve-2016-0718_expat_bug_537.html
> "Issue #26556: Expat 2.1.1"
> http://python-security.readthedocs.io/vuln/issue_26556_expat_2.1.1.html
> Would it be possible to maintain this dependency on an external
> repository which would be easier to maintain? Like
> http://svn.python.org/projects/external/ used to build Python on
> Windows.

Considering how infrequently there have been releases of upstream expat over the past decade or so, even if we had caught every release, I don't see that the benefit to maintaining our embedded copy as a separate repo rather than have to apply the upstreams copies a few time (to each Python branch) is worth the disruptive effort in changing the current Python build process (assuming we don't change the default, see below).  Now, as to whether we should continue to provide our own copy of expat, that's a different question.  Are there differences between our bundled expat and upstream?

> I expect that all Linux distributions build Python using
> --with-system-expat. It may become the default? What about macOS and
> other operating systems?

The current default is --with-system-expat=no so, unless builders of Python take explicit action, the bundled version of expat is used.  Using the bundled version is also currently the case for the python.org macOS installer, no idea what other distributors do.  Apple supplies a version of expat with macOS so we presumably we could use the system version for the installer.  Presumably (Zach?) we would need to continue to supply a version of expat for Windows builds.  But do we need to for others?  If it were only Windows, *then* perhaps it might make sense to make all the changes to move expat out of cpython into the common repo for third-party Windows libs.

> By the way, Zachary Ware is working on converting this repository to
> Git. I don't know his progress:
> - https://github.com/python/cpython-bin-deps
> - https://github.com/python/cpython-source-deps

It appears that the project itself is moving from Sourceforge to Github:


  Ned Deily
  nad at python.org -- []

More information about the Python-Dev mailing list