Review for Package: cpdb-libs

[Summary]
MIR team ACK

This does need a security review, so I'll assign ubuntu-security

List of specific binary packages to be promoted to main: TBD
Specific binary packages built, but NOT to be promoted to main: TBD

TODO:
Till could you let us know which packages will be seeded or dependet upon
once this goes live? I assume libcpdb-libs-frontend1 and due to that also
libcpdb-libs-common1 will be depended on and go to main. But do you plan
to seed or depend on others as well?

[Duplication]
There is no other package in main providing the same functionality.

Also your plan, dedication and timing is really great.
You have packaged this since Bionic, now got Debian involved and due to
GSoC projects and such get the related applications to use it.
I like the outlining of merging it in 23.04 / 23.10 depending on how the
changes to support it land. Thanks for that level of detail.

[Dependencies]
OK:
- no other Dependencies to MIR due to this (adding more backends might
  cause some, but architecture wise that isn't the same binary - nothing for now.
- no -dev/-debug/-doc packages that need exclusion (libcpdb-libs-backend-dev,
  libcpdb-libs-frontend-dev libcpdb-libs-common-dev exist, but have no
  problematic dependencies themselve)
- 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
- no static linking, well the build actually sets --enable-static
  and it provides .a files libcpdb-libs-frontend.a libcpdb-libs-common.a in
  libcpdb-libs-common-dev libcpdb-libs-frontend-dev. But that is not providing
  a solution using static linking. It only allows to use the lib this way
  but IMHO is not yet a violation. It only follows [1]

[1]: https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-static

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
  - It used dbus instead, but not as a service which is ok
- 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:
- While not running a daemon, being a lib it might be used by any software
  including one with rather elevated permissions
- does parse data formats as users print "through" this lib. And files/content
  could come from anywhere - I'd consider this an untrusted source.


[Common blockers]
OK:
- does not FTBFS currently
- does have a non-trivial test suite that runs as autopkgtest
- This does not need special HW for build or test (only the backends
  might need that)
- if a non-trivial test on this level does not make sense (the lib alone
  is only doing rather simple things), is the overall solution (app+libs)
  extensively covered i.e. via end to end autopkgtest ?
- no new python2 dependency

Problems:
- does not have a test suite that runs at build time. That should be ok as it
  has at least an autopkgtest that will print through the lib to cups.
  This fillows the guidance given by the upstream lib [2] and should be ok.

[2]: https://github.com/OpenPrinting/cpdb-libs#testing-the-library

[Packaging red flags]
OK:
O-A: - Ubuntu does not carry a delta (in fact Debian = former Ubuntu)
- symbols tracking is in place
- d/watch is present and looks ok
- Upstream update history is ok
- Debian/Ubuntu update history is ok (It was ok in Ubuntu and now
  picked up by Debian)
- the current release is packaged (2.0 is still in beta, so 1.2 is the latest)
  And Till is already aware and will update once available.
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
  newer-standards-version isn#t evil and print_frontend is a test debug tool
  only which can survive without a man page.
- d/rules isn't as clean as some other packages overriding many stages.
  But what it does there is all reasonable and understandable and should not
  inhibit future servicing of the package.
- It is not on the lto-disabled list

Problems: None

[Upstream red flags]
OK:
- no Errors/warnings during the build
  There is a set like "symbol print_backend_call_get_active_jobs_count_sync used
  by debian/libcpdb-libs-frontend1/usr/lib/x86_64-linux-gnu/libcpdb-libs-frontend.so.1.0.0
  found in none of the libraries" but those are fine as it will load and work
  vice versa than what the check assumes. Most of them are callbacks which
  show up here.
  There are also a few "-Wunused-result" but none seem too bad.
- no incautious use of malloc/sprintf (as far as I 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-*
- part of the UI, but not an app, so it does not need a desktop file
- no translation present, interestingly given that it is meant to be helping
  wit hprint dialogs. But it is really just a man in the middle. Providing
  interfaces and a connection between frontends (have the translations) and
  back ends (have the functionality). So this should be no problem.

Problems: None