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