On 22 January 2016 at 21:25, Donald Stufft <don...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
