Ubuntu
libtraceevent package

[MIR] Promote libtraceevent as a dependency of libtracefs

Bug #2009715 reported by Lucas Kanashiro on 2023-03-08

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	libtraceevent (Ubuntu)	Won't Fix	Undecided	Unassigned
	ndctl (Ubuntu)	Fix Released	Undecided	Lukas Märdian

Bug Description

[Availability]

The package libtraceevent is already in Ubuntu universe.
The package libtraceevent build for the architectures it is designed to work on.
It currently builds and works for architetcures: amd64, arm64, armhf, ppc64el, riscv64, s390x.
Link to package [[https://launchpad.net/ubuntu/+source/libtraceevent|libtraceevent]]

[Rationale]

The package libtraceevent is a runtime dependency of libtracefs which is a new dependency of ndctl which is in main (libtracefs MIR bug: LP #2008799).

It would be great and useful to community/processes to have the package libtraceevent (and libtracefs) in Ubuntu main, but there is no hard deadline, hopefully before Lunar release.

[Security]

Nothing was found in the CVE database:

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libtraceevent

Also nothing was found in the OSS security mailing list archive.

No CVE in the Ubuntu security tracker:

https://ubuntu.com/security/cves?package=libtraceevent

Nor in the Debian security tracker:

https://security-tracker.debian.org/tracker/source-package/libtraceevent

- no executables in `/sbin` and `/usr/sbin`
- Package does not install services, timers or recurring jobs
- Packages does not open privileged ports (ports < 1024)
- Packages does not contain extensions to security-sensitive software (filters, scanners, plugins, UI skins, ...)

[Quality assurance - function/usage]

- The package works well right after install

[Quality assurance - maintenance]

- The package is maintained well in Debian/Ubuntu/Upstream and does not have too many, long-term & critical, open bugs
- Ubuntu https://bugs.launchpad.net/ubuntu/+source/libtraceevent/+bug
- Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libtraceevent
- The package does not deal with exotic hardware we cannot support

[Quality assurance - testing]

- The package does not run a test suite on build time right now but I submitted this MP to do that:

https://code.launchpad.net/~lucaskanashiro/ubuntu/+source/libtraceevent/+git/libtraceevent/+merge/438480

Once that is uploaded it will run the upstream tests during build time.

- The package also does not have DEP-8 tests to be executed via autopkgtest but the MP mentioned above is adding a test to have at least a minimal coverage.

Since there is no autopkgtest run against the version in the archive, there is no failure.

[Quality assurance - packaging]

- debian/watch is present and works

- debian/control defines a correct Maintainer field

- This package does not yield massive lintian Warnings, Errors

P: libtraceevent source: no-homepage-field
P: libtraceevent source: rules-requires-root-missing

- Lintian overrides are not present

- This package does not rely on obsolete or about to be demoted packages.

- The package will not be installed by default

- Packaging and build is easy, link to d/rules:

https://git.launchpad.net/ubuntu/+source/libtraceevent/tree/debian/rules

[UI standards]

- Application is not end-user facing (does not need translation)

[Dependencies]

- No further depends or recommends dependencies that are not yet in main

[Standards compliance]

- This package correctly follows FHS and Debian Policy

[Maintenance/Owner]

- Owning Team will be Server

- Team is not yet, but will subscribe to the package before promotion

- This does not use static builds

- This does not use vendored code

- This package is not rust based

- The package has been built in the archive more recently than the last test rebuild

[Background information]

The Package description explains the package well
Upstream Name is libtraceevent
Link to upstream project: https://git.kernel.org/pub/scm/libs/libtrace/libtraceevent.git

Tags:

Lucas Kanashiro (lucaskanashiro) on 2023-03-08

tags:	added: server-todo
Changed in libtraceevent (Ubuntu):
assignee:	nobody → Lucas Kanashiro (lucaskanashiro)
status:	New → In Progress

Revision history for this message

Lucas Kanashiro (lucaskanashiro) wrote on 2023-03-08:

The Server team is subscribed to the package.

Christian Ehrhardt  (paelzer) on 2023-03-14

Changed in libtraceevent (Ubuntu):
assignee:	Lucas Kanashiro (lucaskanashiro) → nobody
status:	In Progress → New
assignee:	nobody → Lukas Märdian (slyon)

Revision history for this message

Lukas Märdian (slyon) wrote on 2023-03-21:

I wonder if the rational is strong enough to support promoting libtracefs & libtraceevent to "main"? Especially now that upstream has made those dependencies optional. Should we rather disable it for the time being?

Revision history for this message

Lukas Märdian (slyon) wrote on 2023-03-21:

no-libtracefs.debdiff Edit (7.5 KiB, text/plain)

Revision history for this message

Lukas Märdian (slyon) wrote on 2023-03-21:

What's the exact usecase for "cxl monitor" (outside of cxl-monitor.servce, which is currently disabled in Debian anyway)?

Revision history for this message

Lukas Märdian (slyon) wrote on 2023-03-21:

Download full text (6.0 KiB)

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: <NONE>

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)

Review for Package: src:libtraceevent

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: <NONE>

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

[Duplication]
There is no other package in main providing the same functionality.
Other Linux tracers include: sysprof, bpftrace, lttng, dtrace (all in universe)

Problems: None

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

Changed in libtraceevent (Ubuntu):
status:	New → Incomplete
assignee:	Lukas Märdian (slyon) → Lucas Kanashiro (lucaskanashiro)
status:	Incomplete → Won't Fix
assignee:	Lucas Kanashiro (lucaskanashiro) → nobody

Lukas Märdian (slyon) on 2023-03-21

Changed in ndctl (Ubuntu):
status:	New → In Progress
assignee:	nobody → Lukas Märdian (slyon)

Revision history for this message

Launchpad Janitor (janitor) wrote on 2023-03-21:

This bug was fixed in the package ndctl - 76-1ubuntu1

---------------
ndctl (76-1ubuntu1) lunar; urgency=medium

  * Avoid optional dependency MIRs: libtracefs & libtraceevent.
    Upstream cherry-pick https://github.com/pmem/ndctl/commit/82884ee
  * d/rules: disabled (new) libtracefs meson option
  * d/control: drop libtracesfs & libtraceevent (LP: #2009715, LP: #2008799)

-- Lukas Märdian <email address hidden> Tue, 21 Mar 2023 14:08:28 +0100