|
|
|
|
|
|
by craigds
2890 days ago
|
|
|
Binary wheels are a nightmare in terms of knowing what you have installed. We disabled them in our builds when we discovered a few packages had vendored old, terribly-insecure static versions of libxml2 (and who knows what else) which silently replaced using the system version (which received OS security updates). We only found out when we hit one of the behavioural quirks of that version and spent ages investigating it with gdb. If you're using manylinux wheels you're probably using static libs you have no idea you're using. That way lies madness. I havent used conda so maybe this doesn't apply there somehow. |
|
|
Another is building that software with good security flags, see: https://www.anaconda.com/blog/developer-blog/improved-securi...
We also keep track of CVEs in our software and actively look for patches (e.g. pycrypto is dead now but Debian maintains patches to fix reported CVEs) or write our own (though usually to fix build-system bugs rather than security issues).
But yes, static linking and leaving software building to non-experts using whatever tools they like (without studying anything to do with low-level binary security or how to achieve that), statically linking insecure (some time to become old) libraries is far from ideal.
Anaconda Distribution strongly prefers dynamic linking and shared package dependencies so we can update to address critical security issues without needing to rebuild significant portions of our stack.