Vulnerable shared libraries might make pygit2 vulnerable. Can you help upgrade to patch versions?

[MikeWazoWski123]

Hi, @jdavid , @carlosmn , I'd like to report a vulnerability issue in pygit2_1.9.1.

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), pygit2_1.9.1 directly or transitively depends on 15 C libraries (.so). However, I noticed that some C libraries are vulnerable, containing the following CVEs: libcrypto-17bcacf6.so.1.0.2k and libssl-53a623ad.so.1.0.2k from C project openssl(version:1.0.2k) exposed 11 vulnerabilities: CVE-2018-0732, CVE-2019-1559, CVE-2019-1547, CVE-2019-1563, CVE-2019-1551, CVE-2020-1971, CVE-2021-23841, CVE-2020-1968, CVE-2018-0734, CVE-2017-3736, CVE-2019-1552 libgssapi_krb5-497db0c6.so.2.2, libk5crypto-b1f99d5c.so.3.1 and libkrb5-fc820a1d.so.3.3 from C project krb5(version:1.16) exposed 2 vulnerabilities: CVE-2021-37750,CVE-2021-36222

Suggested Vulnerability Patch Versions

openssl has fixed the vulnerabilities in versions >=1.1.1l krb5 has fixed the vulnerabilities in versions >=1.19.3

Python build tools cannot report vulnerable C libraries, which may induce potential security issues to many downstream Python projects. As a popular python package (pygit2 has 630,559 downloads per month), could you please upgrade the above shared libraries to their patch versions?

Thanks for your help~ Best regards, MikeWazowski

[jdavid]

The version of openssl in the wheel is the one from Centos 7, which already has some security patches, specifically the latest release includes https://centos.pkgs.org/7/centos-updates-x86_64/openssl-1.0.2k-24.el7_9.x86_64.rpm.html

If this is not enough we could switch from manylinux2014 to manylinux_2_24 wheels, which is based on Debian 9 and has a more recent version of the libraries. This would however make it harder to install pygit2 wheels, since it would require a more recent version of pip.

[MikeWazoWski123]

@jdavid, thanks for your help and feedback.

This would however make it harder to install pygit2 wheels, since it would require a more recent version of pip.

Compatibility or security? It is really hard to chose. By the way, is the diagnosis information useful to you? I am happy to know that :)

Best regards, MikeWazowski

[jdavid]

Yes it's useful.

So there are some vulnerabilities not addressed by the Centos package, yet Centos 7 is still maintained, and the package maintainers decided not to patch those vulnerabilities. Upgrading to manylinux_2_24 should address some issues, but probably not all. For reference these are the versions in the latest pygit2 release:

• openssl 1.0.2k-24.el7_9
• krb5 1.15.1-51.el7_9

In Debian 9 we have:

• openssl 1.1.0l-1~deb9u5
• krb5 1.15-1+deb9u3

[4a6f656c]

@jdavid (cc @howbazaar) security issues from bundling a CentOS patched version of an EOL security library aside, this is also a regression from a functional perspective - there are numerous features and bug fixes that exist in OpenSSL 1.1.x that are not present in OpenSSL 1.0.2. This includes certificate chain verification fixes (https://github.com/libgit2/pygit2/issues/1115) and support for ed25519 (https://github.com/libgit2/pygit2/issues/1143). Bundling OpenSSL 1.0.2 is effectively taking the lowest common denominator and forcing it upon everyone who uses these wheels, even if they are being used on a modern system that has better functionality and security maintenance available.

[jdavid]

Yes, OpenSSL should not be included in the wheels, and instead the system library should be used. PRs welcome.

[jdavid]

The latest release v1.11.1 is based on manylinux 2_24 and includes openssl 1.1

[chet-manley]

Just an FYI, switching to manylinux_2_24 broke wheel compatibility with RHEL 7, which uses glibc 2.17. I now have to manually build openssl11, libssh2, libgit2, & pygit2 wheels in manylinux2014 to maintain pygit2 for our internal projects that are deployed to OEL7 hosts.