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

[Camila Camargo de Matos]

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
OpenStack, which is subscribed to jaraco.collections in 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

Status in cherrypy3 package in Ubuntu:
  In Progress
Status in jaraco.classes package in Ubuntu:
  Fix Released
Status in jaraco.collections package in Ubuntu:
  Fix Released
Status in jaraco.text package in Ubuntu:
  Fix Released
Status in python-cheroot package in Ubuntu:
  Incomplete
Status in python-jaraco.functools package in Ubuntu:
  Fix Released
Status in python-portend package in Ubuntu:
  Fix Released
Status in python-tempora package in Ubuntu:
  Fix Released
Status in zc.lockfile package in Ubuntu:
  Fix Released

Bug description:
  [Availability]
  All packages are already in universe, and in sync with Debian.
  They are all architecture independent.
  jaraco.classes, jaraco.collections is new to Debian & Ubuntu (currently only in experimental), and portend and jaraco.functools are relatively new, since 2019
  cheroot and zc.lockfile have been in Debian & Ubuntu for many years.

  [Rationale]
  Dependencies of the new cherrypy3 18.6.0-1 release.

  [Security]
  No security issues ever reported for any of these libraries.

  [Quality assurance]
  All the packages are simple Python libraries, no configuration or debconf questions.
  No open bugs in Debian or Ubuntu.
  jaraco.classes, jaraco.collections, jaraco.functools, jaraco.text, portend, tempora, and zc.lockfiles's test suites are run at build time.
  cheroot's test suite is not run at build time, due to missing dependencies in the archive (jaraco.context).
  No significant lintian issues, although jaraco.functools, portend, tempora and zc.lockfile could fix some obvious trivial issues.

  [Dependencies]
  This issue is for a set of dependencies for cherrypy3

  [Standards compliance]
  Packages are simple python libraries, installed to the correct locations, and lintian clean (except old standards versions, compats, etc.)

  [Maintenance]
  All packages seem relatively well maintained upstream, and are a few years old at this point.
  jaraco.classes, jaraco.collections, jaraco.functools, ported, and tempora have 0 open issues and pull requests, upstream.
  chreroot has tens of open issues and pull requests, but the project hasn't stagnated, it just seems to be being actively developed.
  zc.lockfile has seen no commits since 2019, but doesn't have issues and PRs piling up.

  [Background information]

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