[MIR] rich

$ lintian --pedantic
E: rich changes: bad-distribution-in-changes-file unstable

Review for Package: rich

[Summary]
MIR team ACK under the constraint to resolve the below listed
required TODOs and as much as possible having a look at the
recommended TODOs.
This does need a security review, so I'll assign ubuntu-security after the
required TODOs are addresed.
List of specific binary packages to be promoted to main: python3-rich

Notes:
Required TODOs:
1. MIR dependencies, all under the process
 1a. https://bugs.launchpad.net/ubuntu/+source/markdown-it-py/+bug/2003568
 1b. https://bugs.launchpad.net/ubuntu/+source/mdurl/+bug/2002818
 1c. https://bugs.launchpad.net/ubuntu/+source/python-typing-extensions/+bug/2002821

2. Autopackage testing. The package has a test suite that used to run as autopkg until
   kinetic (see https://autopkgtest.ubuntu.com/packages/rich). At version 13.0.0-1 the
   autopkgtest are run via autopkgtest-pkg-pybuild (see debian/changelog). I guess that
   from a package perspective it is ok, the test are supposed to run but for some reason
   they don't. Maybe because of this bug : https://bugs.launchpad.net/auto-package-testing/+bug/2003981
   Could you please look further into it and confirm it is indeed a autodep8 problem and
   rich problem ?

Recommended TODOs:
3. The current release 13.3.1 is not package. It was released a couple of day ago, so
   it should be a matter of days for debian to bump to the new version and then
   ubuntu can pull from there.

- The package should get a team bug subscriber before being promoted

[Duplication]
Package is required in main as a new dependency of netplan.

[Dependencies]
OK:
- no -dev/-debug/-doc packages that need exclusion
- No dependencies in main that are only superficially tested requiring
  more tests now.

Problems:
- 3 dependenices to MIR, all under MIR process
  1. https://bugs.launchpad.net/ubuntu/+source/markdown-it-py/+bug/2003568
  2. https://bugs.launchpad.net/ubuntu/+source/mdurl/+bug/2002818
  3. https://bugs.launchpad.net/ubuntu/+source/python-typing-extensions/+bug/2002821

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
- does not have unexpected Built-Using entries
- not a go package, no extra constraints to consider in that regard
- not a rust package, no extra constraints to consider in that regard
- Does not include vendored code

Problems: None

[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not open a port/socket
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)
- does not deal with security attestation (secure boot, tpm, signatures)
- does not deal with cryptography (en-/decryption, certificates, signing, ...)

Problems:
- does parse data formats (files [images, video, audio,
  xml, json, asn.1], network packets, structures, ...) from
  an untrusted source.

[Common blockers]
OK:
- does not FTBFS currently
- does have a test suite that runs at build time
  - test suite fails will fail the build upon error.
- This does not need spe...

I just subscribed foundations-bugs

Status update:
1a: markdown-it-py is MIR ACK, pending security review
1b: mdurl is MIR ACK, pending security review
1c: python-typing-extensions is MIR ACK and ready to be promoted

2: bug #2003981 got resolved on Ubuntu' autopkgtest infrastructure and pytests are now running properly (but the queues are very full and it takes a while for all those tests to be re-executed). It already passed on amd64: https://autopkgtest.ubuntu.com/packages/rich/lunar/amd64 (without changes to the packaging)

3: v3.3.1 got uploaded into Debian unstable and should be auto-synced into Ubuntu soon: https://tracker.debian.org/pkg/rich

So I feel like the required TODOs are resolved and this is ready for security review. Assigning ~ubuntu-security.

I reviewed rich 13.2.0-2 as checked into lunar. This shouldn't be considered a full audit but rather a quick gauge of maintainability.

> Rich is a Python library for rich text and beautiful formatting in the terminal.

- CVE History:
  - none
  - upstream bug tracker is fairly well maintained
    - no security concerns
    - except https://github.com/Textualize/rich/issues/1903
- Build-Depends?
  - lunar main
    - debhelper-compat (debhelper)
    - python3-all (python3-defaults)
    - python3-setuptools (setuptools)
  - lunar universe
    - flit
    - pybuild-plugin-pyproject
    - python3-pytest (dh-python)
    - python3-markdown-it (active MIR)
    - python3-mypy (mypy)
    - python3-poetry-core (poetry)
    - python3-pygments
    - python3-pytest (pytest)
    - python3-typing-extensions (active MIR)
- pre/post inst/rm scripts?
  - yes, standard prerm and postinst generated by dh-python
  - dh-python is required, but missing from d/controls !?
- init scripts?
  - none
- systemd units?
  - none
- dbus services?
  - none
- setuid binaries?
  - none
- binaries in PATH?
  - none
- sudo fragments?
  - none
- polkit files?
  - none
- udev rules?
  - none
- unit tests / autopkgtests?
  - has build tests and autopkgtests
  - recent lunar autopkgtests result in "neutral"
    - likely fine--see mdurl MIR notes
- cron jobs?
  - none
- Build logs:
  - nothing concerning

- Processes spawned?
  - only in helper tool, see bandit reports
- Memory management?
  - standard python
- File IO?
  - file IO exceptions uncaught
  - progress.py overloads IO open() for accounting
- Logging?
  - responds to interactive console input being invalid
  - raises errors, prints warnings, etc. Not the most consistent, but reasonable for _trusted_ input
  - logging.py handles logs _being parsed by_ rich
- Environment variable usage?
  - console.py makes a copy of all env variables
    - Console._environ
    - only a few specific env variables actually used
  - diagnose.py prints a limited set of env variables
- Use of privileged functions?
  - none
- Use of cryptography / random number sources etc?
  - trivial
    - rand 1:1e6 chance of link_id collision
- Use of temp files?
  - none
- Use of networking?
  - none
- Use of WebKit?
  - none
- Use of PolicyKit?
  - none

- Any significant cppcheck results?
  - none
- Any significant Coverity results?
  - not significant
  - reported https://github.com/Textualize/rich/issues/2813
- Any significant shellcheck results?
  - none
- Any significant bandit results?
  - not too significant
  - several cases of Try, Except, Continue
  - ./tools/make_terminal_widths.py contains subprocess shell with runtime dependency on black

Rich has a large userbase with many downstream projects.

This MIR does not apply to kinetic, which requires python3-commonmark instead of markdown-it-py.

Rich is a relatively heavy and inefficient library, but has pretty results. Use of rich in netplan's is isolated to netplan's status (and status is not called by other netplan components). Therefore, Security is not too concerned about adding this.

./tools/ can be removed to avoid runtime dependency on black. The directory ./benchmarks/results/ can also be...

Thanks for the review!

Rich has pybuild-plugin-pyproject as a build dependency and pybuild-plugin-pyproject is built from src:dh-python. Do we still need to define dh-python explicitly as a build dependency?

Thanks a lot for the security review!

Not sure if we need/want an explicit dh-python build-dependency... The package build-depends on pybuild-plugin-pyproject already, which is a binary from the src:dh-python source and build depends on dh-python itself.

I think we should rather try to avoid introducing delta against Debian, which does not want to add an explicit dh-python B-D: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031703

Wrt removal of ./tools/ (and ./benchmarks/results/): I think we shouldn't diverge from Debian's orig tarball here, without consensus, as that would introduce a significant delta in Ubuntu which is kind of hard to maintain. As ./tools/README.md states those files are only used for development and are not part of any of the built binary packages. So is the runtime dependency of "black" (not part of the packaging, not a .deb dependency). Those directories only affect the orig tarball and source package size, as such we should not touch those IMO.

Thanks for the feedback. Security is dropping the dh-python requirement.

Thank you! With this I think it is ready for promotion, after all of its dependencies are looking good, too:
* python-typing extensions (LP: #2002821), promoted
* mdurl (LP: #2002818), promoted
* markdown-it-py (LP: #2003568), ready for promotion.

Override component to main
rich 13.3.1-1 in lunar: universe/misc -> main
python3-rich 13.3.1-1 in lunar amd64: universe/python/optional/100% -> main
python3-rich 13.3.1-1 in lunar arm64: universe/python/optional/100% -> main
python3-rich 13.3.1-1 in lunar armhf: universe/python/optional/100% -> main
python3-rich 13.3.1-1 in lunar i386: universe/python/optional/100% -> main
python3-rich 13.3.1-1 in lunar ppc64el: universe/python/optional/100% -> main
python3-rich 13.3.1-1 in lunar riscv64: universe/python/optional/100% -> main
python3-rich 13.3.1-1 in lunar s390x: universe/python/optional/100% -> main
8 publications overridden.