KLayout
Potential secutiry vulnerabilities in the shared libraries which klayout depends on. Can you help upgrade to patch versions?
Hi, @klayoutmatthias , @thomaslima , I'd like to report a vulnerability issue in klayout_0.27.8.
Dependency Graph between Python and Shared Libraries
Issue Description
As shown in the above dependency graph(here shows part of the dependency graph, which depends on vulnerable shared libraries), klayout_0.27.8 directly or transitively depends on 41 C libraries (.so). However, I noticed that some C libraries are vulnerable, containing the following CVEs:
libgssapi_krb5-497db0c6.so.2.2
libk5crypto-b1f99d5c.so.3.1
libkrb5-fc820a1d.so.3.3
libkrb5support-04204f6a.so.0.1
from C project krb5(version:1.16) exposed 2 vulnerabilities:
CVE-2021-37750, CVE-2021-36222
libidn-97d26f25.so.11.6.11 from C project libidn(version:1.28) exposed 3 vulnerabilities:
CVE-2015-8948, CVE-2016-6261, CVE-2016-6262
Suggested Vulnerability Patch Versions
krb5 has fixed the vulnerabilities in versions >=1.19.3 libidn has fixed the vulnerabilities in versions >=1.33
Python build tools cannot report vulnerable C libraries, which may induce potential security issues to many downstream Python projects. As a popular python package, could you please upgrade the above shared libraries to their patch versions?
Thanks for your help~ Best regards, Andy
The PyPI package build is based on the quay.io/pypa/manylinux2014_x86_64 Docker image. Despite the name, this is the current version based on CentOS7 (https://github.com/pypa/manylinux). CentOS7 itself still features krb5 1.15 for example, so updating does not help. I'm afraid that patching is not an easy thing to do.
Package maintenance is a tedious job which already eats too much of my time. I'm already compromising feature development. This is a spare time project and there is no funding, so please do not expect extra service. Popular or not, I'd rather delete the package binaries if you think this is a severe threat.
Otherwise, if you need compliance with your own security standards, you can always build from source.
Matthias
You welcome (although I feel that I didn't do much) :)
Basically: if there is a chance to switch, I am absolutely willing to do so. But it should be possible with a reasonable effort. If anyone knows about of more modern alternative for manylinux deployment of Python packages, let me know.
Even more, if someone wants to help setting up a CI job this.
Best regards,
Matthias
As far as I remember, we need to use their manylinux docker image to produce a compatible wheel. I think the first thing that needs to be done is to forward this Issue to the manylinux project and see what they say. Perhaps they can just update their Docker image. Otherwise, they'll tell us what to do.
These vulnerabilities are coming from libcurl "only" right?
My understanding is that this vulnerability is inherited from CentOS7 which manylinux2014 is based upon.
I wonder if there is an alternative. On https://github.com/pypa/manylinux there is manylinux_2_24 which is based on Debian:9 - still that features krb5 1.15.
The project states this:
Building manylinux-compatible wheels is not trivial; as a general rule, binaries built on one Linux distro will only work on other Linux distros that are the same age or newer. Therefore, if we want to make binaries that run on most Linux distros, we have to use an old enough distro.
In other words: compatibility or security?
Matthias
@andy201709 Can you check if this issue has been resolved in the latest wheels? We are using a standard process with https://github.com/pypa/cibuildwheel which I think will resolve itself once the manylinux docker uses a more modern image. I am not sure whether these vulnerabilities impact klayout's use case.
There is no easy fix. I'd say let's close this. Unless of course we remove the dependency of curl for python packages. Indeed I'm not sure why it's necessary.
Thanks. I'll close it for now. I hope that at some point the manylinux image gets updated.
Matthias