[Distutils] draft PEP: manylinux1

[Nick Coghlan]

On 22 January 2016 at 21:25, Donald Stufft <donald at stufft.io> wrote:
> Thinking of it in terms of a C like "undefined behavior" is probably a
> reasonable way of doing it. Linking against a system provided library that is
> on this list is a defined behavior of the manylinux "platform", linking against
> something else is undefined and may or may not work. At some level, once you've
> gotten to the point you're using pip to manage some set of your packages it
> doesn't really matter if that set of things you're pulling from PyPI includes
> a C library or not. If you're relying on say psycopg2 it's not clear to me that
> libpq *needs* to be getting security any more than psycopg2 itself does and so
> you'll need some method of solving that problem for your Python level
> dependencies anyways.

It also wouldn't surprise me if CVE trackers like requires.io and
versioneye.com gained the ability to search wheel files for embedded
dependencies and flag outdated and vulnerable ones.

However, it's a good point that PyPI won't be running auditwheel to
*force* compliance with the "no external dependencies outside the
defined set" guideline - while a service like pythonwheels.com could
potentially be set up independently of PyPI to run auditwheel on
manylinux wheels, PyPI itself wouldn't do it.

An external scan like that could actually be a useful way of defining
manylinux2 in the future - scanning popular manylinux wheel downloads
for both embedded libraries and for external dependencies outside the
defined set.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia