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.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1930111

Title:
  [MIR] new dependencies of cherrypy3: jaraco.collections,
  jaraco.classes, jaraco.text, python-cheroot, python-jaraco.functools,
  python-tempora, python-portend, zc.lockfile

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cherrypy3/+bug/1930111/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to