I reviewed python-cheroot 8.5.2+ds1-1ubuntu2 as checked into jammy. This shouldn't be considered a full audit but rather a quick gauge of maintainability. python-cheroot is a Python library that implements an HTTP server and includes a WSGI module. - CVE History: No CVEs in our UCT database. - The python-cheroot package is a Python library which is mainly used by CherryPy (however, it can be used by other frameworks and applications. It does not import cherrypy in order to allow this). It implements an HTTP server, and includes a WSGI module. - Build-deps: debhelper-compat (= 13), dh-python (>= 2.20160609~), python3-all, python3-packaging, python3-pytest, python3-setuptools, python3-setuptools-scm-git-archive, python3-pytest-cov, python3-pytest-forked, python3-pytest-xdist, python3-pytest-mock, python3-jaraco.functools, python3-jaraco.text, python3-trustme, python3-openssl, python3-portend, python3-requests-unixsocket, - Extensive networking - Depends on the SSL library python3-openssl. - Depends on the networking library python3-requests-unixsocket. - Encryption imports: ssl, OpenSSL (seems to include both for compatibility reasons, if not specified, will use ssl related code by default). - Networking imports: urllib (used mostly for parsing), socket, requests, requests_unixsocket, portend, requests_toolbelt. - pre/post inst/rm scripts automatically generated dh_python* - Does not daemonize. - No init scripts. - No systemd units, although the code seems to allow systemd socket activation. - No dbus services. - No setuid binaries. - No binaries in PATH. - No sudo fragments. - No polkit files. - No udev rules - No cron jobs. - The package contains a test folder with various Python tests specific for usage with python-cheroot (since it uses fixtures). They can be run locally and are included to the system during install. Nothing too alarming was found in the testing code. However, it is expected that this will be maintained together with the rest of the code. FIXME comments in tests indicate that this is the case. - When tests are active for a build, the build hangs with 19% of the tests complete, it being killed with signal TERM after 150 minutes of inactivity. This applies to local builds made. In the test rebuild done in January for this package (more information available at: https://launchpadlibrarian.net/579489603/buildlog_ubuntu-jammy-amd64.python-cheroot_8.5.2+ds1-1ubuntu2_BUILDING.txt.gz and https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20211217-jammy-jammy.html) it is possible to verify that the build also fails due to hanging tests (in this case, however, tests hang at 13%). - A few subprocesses spawned, but the calls are being made in a sufficiently safe manner. - No memory management (Python). No usage of the garbage collection library (gc). - No files written to, only sockets. Certificate files are opened for reading and further processing. No issues related to possible file descriptor exhaustion or buffered file data being available for reading in case of a crash. - Does not log any errors to files. All error messages are sent to stderr or are sent through raised exceptions to the user. Most error messages do not include external data provided by a user, and in the cases that this happens, the string is formatted properly such that it wouldn't cause any errors. There are no mentions of syslog and dbus. - Python-cheroot uses a few environment variables to perform its operations. Most of them do not have their values verified, however, for the variables used, the lack of verification would not cause any relevant issues. No environment variable values are set. - The privileged operation that is used in this library is the chmod operation. In the server.py module of the library, variable fs_permissions is set to 0o777, and there is a TODO comment right next to the line which attributes the permissive value to said variable. This comment says "allow changing mode", which could possibly mean an implementation where the user gets to set the permissions they wish to a socket being created in the server.py file. Setting permissions of the socket to 777 seems like bad security practice. If default is 777, shouldn’t the choice be implemented, so that developers that wish to harden access to the socket can do so? Considering this is a library that implements an HTTP server that will interact with a WSGI server, limiting processes that are able to speak to the socket seems like a good idea (or at least being able to have a choice to define this as a developer). - Python-cheroot uses the ssl or the pyOpenSSL libraries to perform most of its SSL operations, having a few wrappers around those in order to allow easier access to functionalities. The OpenSSL module crypto is used, but not to perform cryptographic operations, only to parse certificates. Usage of this module to perform direct cryptogra phic operations is not recommended by the Python Cryptographic Authority, but the cheroot code seems to follow recommended measures. - Temporary files are created during testing using the safe function mkstemp. - Extensive networking. Most operations involve the opening and closing of sockets and reading and writing from theses sockets. Read and write operations to the socket seem to be performed responsibly, with read functions performing checks on the amount of data that is being read and with write functions respecting upper boundaries for the amount of data to be sent. There seems to be care when reading and writing data to sockets and buffers. Server error messages returned do not do not contain unecessary information, however, they do elaborate on the issue that caused the error. - No WebKit. - No PolicyKit. The code seems to be well commented, with references to previous issues being present in the code so that it is possible to understand the reason behind a certain logic. Issues seem to be well documented as well. There is the current problem with the tests during build. Even though there are a few tiny warning points, it seems like the code is well written and that issues, including security ones, are well addressed. Security team ACK for promoting python-cheroot to main CONTINGENT ON ANSWERS TO QUESTIONS ASKED REGARDING TESTS AND THE 777 SOCKET BE ACCEPTABLE ACCORDING TO SECURITY REVIEW TERMS.