Review for Package: src:libtraceevent [Summary] This is a very specific library to handle events from the kernel's tracefs, mounted at /sys/kernel/tracing (or /sys/kernel/debug/tracing). The libtraceevent (and libtracefs) dependencies are used for the "cxl monitor" command (and systemd cxl-monitor.service, currently disabled in Debian). The rationale for providing "cxl monitor" is still a bit unclear, and I would prefer to keep it disabled, to avoid those MIRs, as is supported by ndctl upstream as of v76.1. MIR team NACK This would (probably?) need a security review. (Not assigning ubuntu-security, due to my NACK) List of specific binary packages to be promoted to main: libtraceevent-dev, libtraceevent-doc, libtraceevent1, libtraceevent1-plugin Specific binary packages built, but NOT to be promoted to main: Notes: #0 This seems mostly OK from a security perspective (AFAICT), but it's closely working with (trusted?) kernel space and using plenty of malloc's, so I'd opt to still have the security team look at it. #1 ubuntu-server is already set-up as a team subscriber Required TODOs: #2 clarify the "#MISSING: ..." entries in .symobls tracking #3 does not have a test suite that runs at build time => Upstream's unit tests from utest/ are being compiled via `make test` but don't seem to be executed. At least I cannot spot any of the CUnit output in the build log. Please clarify. #4 does not have a non-trivial test suite that runs as autopkgtest => the recently added autopkgtest is superficial, checks compilation only, execution of the compiled examples could be an additional test => a non-static build of the unit tests runing against the installed version as autopkgtest would be a nice addition Recommended TODOs: #5 reconsider if we really want/need the static libtraceevent.a library #6 consider fixing some of the lintian remarks (especially using hardening flags) => see [Packaging red flags] below [Duplication] There is no other package in main providing the same functionality. Other Linux tracers include: sysprof, bpftrace, lttng, dtrace (all in universe) [Dependencies] OK: - no other Dependencies to MIR due to this - SRCPKG checked with `check-mir` - all dependencies can be found in `seeded-in-ubuntu` (already in main) - none of the (potentially auto-generated) dependencies (Depends and Recommends) that are present after build are not in main - no -dev/-debug/-doc packages that need exclusion - No dependencies in main that are only superficially tested requiring more tests now. Problems: None [Embedded sources and static linking] OK: - no embedded source present - 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: - A static libtraceevent.a library is being built and shipped in libtraceevent-dev (which seems to be OKish from a MIR perspective) [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 parse data formats (files [images, video, audio, xml, json, asn.1], network packets, structures, ...) from an untrusted source. - 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: - It parses events from the kernel's tracefs, but I'll consider this a trusted source [Common blockers] OK: - does not FTBFS currently - This does not need special HW for build or test - no new python2 dependency Problems: - does not have a test suite that runs at build time => Upstream's unit tests from utest/ are being compiled via `make test` but don't seem to be executed. At least I cannot spot any of the CUnit output in the build log. Please clarify. - does not have a non-trivial test suite that runs as autopkgtest => the recently added autopkgtest is superficial, checks compilation only, execution of the compiled examples could be an additional test => a non-static build of the unit tests runing against the installed version as autopkgtest would be a nice addition [Packaging red flags] OK: - Ubuntu does carry a delta, but it is reasonable and maintenance under control - debian/watch is present and looks ok (if needed, e.g. non-native) - Upstream update history is good - Debian/Ubuntu update history is good - the current release is packaged - promoting this does not seem to cause issues for MOTUs that so far maintained the package - debian/rules is rather clean - It is not on the lto-disabled list Problems: - symbols tracking is in place, but contains several "#MISSING: ..." entries. Please clarify. - no massive Lintian warnings, but a few worth looking at: W: libtraceevent1-plugin: shared-library-lacks-prerequisites (might be due to being a plugin?) I: libtraceevent1[-plugin]: hardening-no-bindnow I: libtraceevent1[-plugin]: hardening-no-fortify-functions I: libtraceevent source: superficial-tests [debian/tests/control] I: libtraceevent1: symbols-file-missing-build-depends-package-field libtraceevent.so.1 [symbols] I: libtraceevent-doc: "spelling-error-in-description" and plenty of "typo-in-manual-page" P: libtraceevent source: no-homepage-field P: libtraceevent source: silent-on-rules-requiring-root [debian/control] [Upstream red flags] OK: - no Errors/warnings during the build - no incautious use of malloc/sprintf (as far as we can check it) - no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH (usage is OK inside tests) - no use of user nobody - no use of setuid - no important open bugs (crashers, etc) in Debian or Ubuntu - no dependency on webkit, qtwebkit, seed or libgoa-* - not part of the UI for extra checks - no translation present, but none needed for this case (user visible)? Problems: None