Thank you both, Simon for the initial discussion and Benjamin for the updated reasoning. And also to sync the newer version which also has more testing \o/
Going back to a full review ... Review for Source Package: python-invoke Launchpad bug: https://bugs.launchpad.net/bugs/2138736 Target series: devel Analysed source version: 3.0.3+ds-1 (release pocket) Binary packages: python3-invoke [Summary] OK: - Review for Source Package: python-invoke - Reporter MIR content found and used as context. - Package has team subscriber(s): ubuntu-openstack *well, see below* - A dedicated security review does not appear to be needed for this package. (All security checks returned ok, with zero CVEs recorded in both the Ubuntu CVE tracker and NVD. The package does not parse untrusted data, expose endpoints, handle authentication, or deal with cryptography, so no security-sensitive triggers fire under the MIR policy.) => MIR team ACK under the constraint to resolve the listed tasks Required TODOs: - #1 Please sort out who will own the package going on :-) The package is no more in main in any active release. ubuntu-openstack owns it, probably from a long long time ago. I doubt that they want to take it over for another decade. I'd ask you to contact them and most likely drop their structural subscription while adding the one of debcrafters. [Rationale, Duplication and Ownership] OK: - There is no other package in main providing the same functionality. (The dup-search results identified python3-taskipy (universe) as a task runner, but no packages in main provide equivalent Python task execution functionality.) - A team is committed to own long term maintenance of this package. (The team mapping identifies ubuntu-openstack as a subscribed team for python-invoke, which per policy satisfies the ownership check. The bug report additionally states that debcrafters has acknowledged ownership commitment, though they are not yet subscribed.) - The rational is now given and makes sense Problems: none [Dependencies] OK: - no runtime dependencies outside main needing MIR - no other build-time Dependencies with active code in the final binaries to MIR due to this (The package builds with standard Python tooling (debhelper, dh-python, setuptools) and no Built-Using, Static-Built-Using, or static-link hints were observed. A vendor/ directory is shipped in the final package containing the fluidity and lexicon Python modules, but these are part of the upstream source tree rather than build-time dependencies, and are properly documented in the copyright file; the reviewer should confirm this is acceptable under the relevant bundled-code policy.) - no -dev/-debug/-doc packages that need exclusion - No dependencies in main that are only superficially tested requiring more tests now. (The dependency python3-yaml has passing autopkgtests on major architectures, and python3 is the core interpreter which is implicitly tested by the archive.) Problems: none [Embedded sources and static linking] OK: - 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 Problems: - Includes vendored code, the package has documented how to refresh this code at <TBD> (The source tree contains a vendor directory under invoke/vendor with bundled copies of the lexicon and fluidity libraries (including their LICENSE files), and this directory is not confined to test or example paths. However, debian/README.source is absent and debian/rules contains no vendor-refresh targets, so there is no documented procedure for updating the vendored code.) As you also mentioned it includes vendored code. I agree that in this case, the history, structure and Debian packaging of it suggest that keeping this as-is for now is the better approach. I pondered if I shoudl ask for a description how to update these as we'd do in more real external vendored libs. AFAICS the fluidity vendored is newer than the real one - upstream didn't release a version in 14 years and so it is more active in the subdir of invoke than there. See: https://github.com/pyinvoke/invoke/issues/4 And lexicon is from the same author and could also be considered a internal utility tool. Neither of them seem to have much attack surface, operate strictly internally and never had a security history. AFAICS since https://github.com/pyinvoke/invoke/issues/204 it is possible to have them external, but I think we can follow Debian in this case. So after pondering I think this is fine as-is without extra action. [Security] OK: - history of CVEs does not look concerning (Both the Ubuntu CVE tracker and NVD enrichment data report zero total CVEs, including zero historical or high-severity issues.) - does not run a daemon as root - does not use webkit1,2 - does not use lib*v8 directly - does not parse data formats (files [images, video, audio, xml, json, asn.1], network packets, structures, ...) from an untrusted source. (The runtime dependency on python3-yaml (a main-component YAML parser) confirms that YAML configuration parsing occurs, and the source tree contains JSON and YAML configuration test fixtures consistent with a CLI task runner reading user-authored config files. The vendored YAML copy was excluded from the Debian source (per Files-Excluded), so the well-maintained system library is used instead; no evidence of image, video, audio, ASN.1, or network-packet parsing was found.) - does not expose any external endpoint (port/socket/... or similar) (No systemd service files, socket units, or AppArmor profiles were found in the package. The source tree contains a Python CLI/task framework with no apparent network server modules, and no bind/listen/socket patterns were surfaced by the evidence.) - does not process arbitrary web content (The package's runtime dependencies are limited to python3 and python3-yaml, neither of which is web-content-related, and the source tree contains task-running, terminal-handling, configuration, and parser modules with no HTTP client, web server, or HTML/XML parsing logic. The vendored code consists of lexicon (a dictionary type) and fluidity (a state machine), neither of which processes web content.) - does not use centralized online accounts - does not integrate arbitrary javascript into the desktop (The package's runtime dependencies are limited to python3 and python3-yaml, with no WebKit or JavaScript engine packages. No desktop file is shipped, the binary section is 'python', and the source tree contains only Python modules, documentation, and shell completion scripts — no JavaScript or HTML files that could embed arbitrary JS.) - does not deal with system authentication (eg, pam), etc) - does not deal with security attestation (secure boot, tpm, signatures) (The package is a Python task execution/automation library whose runtime dependencies are only python3 and python3-yaml, and no crypto, TPM, secure-boot, PKCS#11, or signature patterns were found in the source tree or vendored libraries. The vendored code (lexicon and fluidity) provides dictionary and state-machine utilities, none of which relate to security attestation.) - does not deal with cryptography (en-/decryption, certificates, signing, ...) (Runtime dependencies are limited to python3 and python3-yaml, neither of which is a cryptography library, and no crypto-related source patterns were detected in the package source. The vendored code under the vendor directory consists of lexicon (dict-like data structures) and fluidity (state machine utilities), not cryptographic implementations.) - this makes appropriate (for its exposure) use of established risk mitigation features (dropping permissions, using temporary environments, restricted users/groups, seccomp, systemd isolation features, apparmor, ...) (The package provides only a Python library and CLI tool with no systemd units, no AppArmor profiles, no setuid/setgid binaries, no sbin executables, and no cron jobs, indicating a low exposure level where mitigation features are not applicable. The reporter also confirms no privileged ports, external endpoints, or services are installed.) Problems: none [Common blockers] OK: - does not FTBFS currently; Launchpad build records pass for arches: amd64, amd64v3, arm64, armhf, i386, ppc64el, riscv64, s390x - A build-time test suite exists and runs during the build via pytest through pybuild; test failures gate the build. Some pty-related tests are deselected due to a known upstream issue (#933), but the remaining tests run and their failures would fail the build. (The build log shows pytest executing at build time with PYBUILD_TEST_ARGS configured in debian/rules, and the build succeeded with tests running. No evidence of failure-swallowing was found — the analysis indicates tests run and failures are not ignored.) - does have a non-trivial test suite that runs as autopkgtest (The Ubuntu autopkgtest infrastructure shows passing results on six architectures with no failures, which is authoritative evidence that non-trivial tests exist and run. The source tree also contains a substantial test suite (unit tests and integration tests) executed via pytest, and the build rules configure test execution through pybuild.) - This does not need special HW for build or test (The reporter explicitly states the package does not deal with exotic hardware, and the build dependencies are standard Python tooling with no hardware-specific requirements. The package is architecture: all (pure Python) and its test suite runs via pytest during build with no indication of dedicated hardware needs.) - no special hardware needed, so there is no compromise to accept - if a non-trivial test on this level does not make sense..., is the overall solution (app+libs) extensively covered i.e. via end to end autopkgtest ? (The autopkgtest database shows python-invoke has passing tests on amd64, arm64, armhf, ppc64el, s390x, and amd64v3. Since the package itself has a non-trivial test suite, indirect coverage via reverse dependencies is not necessary.) - no new python2 dependency - Python package, but using dh_python - not a go package, no extra constraints to consider in that regard Problems: none [Packaging red flags] OK: - Ubuntu does not carry a delta (The git-ubuntu delta adapter reports delta_kind as sync with delta_present false and an empty diffstat, confirming version 3.0.3+ds-1 has no Ubuntu revision and is a direct sync from Debian.) - symbols tracking not applicable for this kind of code (the package ships no shared library (.so), so ABI symbol tracking does not apply) - debian/watch is present and looks ok - Upstream update history is (good/slow/sporadic) (Upstream has released versions 2.1.x through 3.0.3 with an average interval of approximately 8 months, and the current Ubuntu package aligns with the latest upstream release.) - Debian/Ubuntu update history is (good/slow/sporadic) (The computed release cadence descriptor is 'slow' (average interval ~250 days). The package is currently at the latest upstream version (3.0.3), so the slow cadence is acceptable.) - the current release is packaged - promoting this does not seem to cause issues for MOTUs that so far maintained the package (The package currently has no specific team or individual uploaders listed in upload permissions, and recent upload history shows no specific MOTU uploader who would lose access.) - no excessive lintian warnings - debian/rules is rather clean (The rules file consists of a shebang, a single environment variable exporting PYBUILD_TEST_ARGS to skip a known set of pty-related tests (referencing upstream issue #933), and a bare `%: dh $@ --buildsystem=pybuild` target — no overrides, no hardening disabled, no fragile file manipulation. The test filtering is selection/parametrisation (the suite still runs) rather than wholesale disabling, which the policy permits at ok severity.) - It is not on the lto-disabled list - debian/control defines a correct Maintainer field Problems: none [Upstream red flags] OK: - no incautious use of malloc/sprintf (the language has no direct MM) (The build log shows a standard Python/pybuild build with pytest, and the installed artefacts are all .py modules under the Python dist-packages tree with no compiled extensions.) - no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH (usage is OK inside tests) - no use of user 'nobody' outside of tests - no use of setuid / setgid - no important open bugs (crashers, etc) in Debian or Ubuntu (The only open Ubuntu bug is the MIR request itself, while Debian and upstream report zero open issues.) - no dependency on webkit, qtwebkit or libseed - not part of the UI for extra checks (The package is in the python section with runtime dependencies limited to python3 and python3-yaml — no GUI toolkits are present. The binary package python3-invoke provides a command-line task runner, not a graphical application launched from a desktop menu.) - no critical Errors/warnings during the build The few found in the build log were not a problem. - not end user-visible, ok to have no translations present Problems: none ** Bug watch added: github.com/pyinvoke/invoke/issues #4 https://github.com/pyinvoke/invoke/issues/4 ** Bug watch added: github.com/pyinvoke/invoke/issues #204 https://github.com/pyinvoke/invoke/issues/204 ** Changed in: python-invoke (Ubuntu) Assignee: Christian Ehrhardt (paelzer) => Benjamin Drung (bdrung) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2138736 Title: [MIR] python-invoke (paramiko dependency) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-invoke/+bug/2138736/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
