Review for Source Package: sysprof

[Summary]
MIR team ACK

While not the biggest attack surface, it could get crafted external data
which is a common way. Hence IMHO this does need a security review,
I'll assign ubuntu-security.

List of specific binary packages to be promoted to main: sysprof, libsysprof-6-6, libsysprof-6-modules, libsysprof-capture-4-dev, libsysprof-6-dev

Specific binary packages built, but NOT to be promoted to main: n/a

Notes:
Required TODOs:
- none
Recommended TODOs:
- #1 The package should get a team bug subscriber before being promoted
  as you know and already wrote, but as usual that can be done once it
  is supposed to be promoted.

[Rationale, Duplication and Ownership]
- There is no other package in main providing the same functionality.
  It is augmenting the console use cases of perf, but there is nothing in main
  that has the same workflow and visualization.
- A team is committed to own long term maintenance of this package.
- The rationale given in the report seems valid and useful for Ubuntu

[Dependencies]
OK:
- no other Dependencies to MIR due to this (libdex and libpanel already filed)
- no -dev/-debug/-doc packages that need exclusion
  - libsysprof-6-dev has dependencies, but they are all in main
  - libsysprof-capture-4-dev only has internal dependencies
- 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
- 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: 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 expose any external endpoint (port/socket/... or similar)
- 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, ...)
- this makes appropriate (for its exposure) use of established risk
  mitigation features

Problems:
- Does parse data formats (files [images, video, audio,
  xml, json, asn.1], network packets, structures, ...) from
  an untrusted source. An explicit use case mentioned is people attaching
  such profiles to bugs.

[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.
- does have a test suite that runs as autopkgtest
  while the tests are superficial, they cover reverse dep failures
- In addition you have already defined [1] which covers for what is left
  like how things "look like".
  [1]: https://wiki.ubuntu.com/DesktopTeam/TestPlans/Sysprof
- The manual test might in the future be automated, but all together are a
  great set of tests and satisfies what we look for as a minimum
- This does not need special HW for build or test
- no new python2 dependency

Problems: None

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking is in place.
- debian/watch is present and looks ok
- Upstream update history is ok
- Debian/Ubuntu update history is ok
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings (the few we have are resonable IMHO)
- debian/rules are rather clean
- It is not on the lto-disabled list

Problems: None

[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 user nobody
- no use of setuid / setgid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit or libseed
- part of the UI, desktop file is ok
- translation (of the help AFAICS) is present

Problems:
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH.
  This is not so much of a problem as it would usually be, as it is a
  conceptual part of the design. It needs to peload to insert mem tracking
  (just like other memory profilers). It needs to get root permissions
  to ptrace.
  But that is not unexpected and asks the user about granting permissison.
  The only drawback is that therefore the attack severity (if there is one)
  is higher.
  Gladly for the most likely attack surface (manipulated profile data) there
  is no elevated permission needed (that is only for profiling)