[MIR] cpdb-libs

Please address the following issues:

 - add symbols files for the shared libaries

 - consider running an autopkg test, maybe using the included demo?
   upstream doesn't seem to include any tests

 - grepping for sprintf, you only find fixed buffer sizes everywhere.
   Please could you replace these with sensible macros/constants,
   or provide an analysis why these buffers are large enough?

I have now modified the upstream code to use dynanically allocated buffers or snprintf() whatever is more appropriate in each situation.

cpdb-libs 1.1.2 uploaded, with autopkgtest and symbols files added.

cpdb-libs 1.1.2-0ubuntu2 uploaded with all the needed fixes.

Doko pointed out on IRC that the armhf autopkgtest is hitting some failures, https://autopkgtest.ubuntu.com/packages/cpdb-libs/cosmic/armhf which needs to be sorted out

stuck in -proposed for 21 days:
http://autopkgtest.ubuntu.com/packages/c/cpdb-libs/cosmic/arm64

The cpdb-libs is hanging on the autopkgtest for arm64 only (rest OK).

I have tried to get access to an arm64 test machine for debugging this already some days ago but up to know did not get a working setup.

Or can we make an exception as arm64 never worked?

Once the problem solved this package will need seeding as there is no package yet using it.

Till, by the way, are you going to try to get these packages into Debian too? The deadline for new packages to enter Debian for the Buster release is early February.

jbicha, I did not think about that yet, and did not know about the freeze on Debian.

OdyX, could you overtake the Ubuntu packages of cpdb-libs, cpdb-backend-cups, cpdb-backend-gcp, and cpdb-backend-file into Debian?

@Till-kamppeter: yes, but not now. Ideally, could you file ITP's to Debian, mentioning that those should be maintained under the Debian Printing Team umbrella. The best would be if you maintained the packages in Debian yourself, which I could just mentor (upload for you).

Didier, ITPs posted:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911335

Anything missing for a promotion into Main?

Asked for introduction of the CPDB packages in Debian:

https://lists.debian.org/debian-printing/2023/01/msg00001.html

Today the cpdb-libs package got introduced into Debian (unstable):

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911335

It is still version 1.2.0, and update to the current 2.0b1 will follow soon.

Original description completely updated to new MIR scheme:

https://github.com/canonical/ubuntu-mir

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 thi...

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

These are library packages, both to go to main. They implement the CPDB protocol. Frontends (print dialogs) need both, backends need only the first one. As they are libraries they usually do not need to get seeded, they will get pulled in through dependencies of the packages, containing print dialogs of CPDB backend, especially now cpdb-backend-cups and cpdb-backend-file (see the other MIRs) and later also GTK and Qt.

libcpdb-libs-common1
libcpdb-libs-frontend1

These are the headers and other development files, to be treated as usually -dev files of libraries in Main are treated. The third package is for convenience, so that if you want to create/build a frontend, you build-depend only on libcpdb-libs-frontend-dev and if you want to to create/build a backend you simply build-depend on libcpdb-libs-backend-dev.

libcpdb-libs-backend-dev
libcpdb-libs-common-dev
libcpdb-libs-frontend-dev

This is actually only an example/demo frontend. Can stay in Universe. Or should this be merged into the libcpdb-libs-frontend-dev binary package then?

libcpdb-libs-tools

[Security]

- does parse data formats as users print "through" this lib. And files/content
  could come from anywhere - I'd consider this an untrusted source.

It only passes through the actual print job content, it neither parses nor converts it into another format. The library only handles meta data, polling the backend (which in turn polls the print service, like CUPS) to get printer capabilities and options, and passing them on to the print dialog to get displayed there, and passing the user's selections for these options along with the job back to the backend (which in turn adds them to the job as metadata/job ticket, according to the needs of the print service).

[Common blockers]

- This does not need special HW for build or test (only the backends
  might need that)

Theoretically one could create a backend which talks directly with a printer or a print server appliance, having some kind of non-standard printer driver (not endorsed by OpenPrinting, standard are Printer Applications), but such a backend is never required to be able to test this library, as there exist already 2 backends not reqiring special hardware: cpdb-backend-cups and cpdb-backend-file. Especially cpdb-backend-cups should exercise cpdb-libs in practically all aspects.

[Upstream red flags]

- part of the UI, but not an app, so it does not need a desktop file

It does not actually provide a user interface, it only manages data which makes up user interface elements (in the print dialog).

- 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.

It supplies UI strings to the print dialog, translations are currently not supported but will be supported in the 2.0 version. The translation themselves will be provided by the print service (like CUPS) and carried through by the backends and cpdb-libs.

I have updated CPDB (cpdb-libs, cpdb-backend-cups, cpdb-backend-file) to the current 2.x versions from upstream, as needed by current GTK (4.9.4). There the binary packages are renamed. Therefore I am updating this part:

List of specific binary packages to be promoted to main:

- libcpdb2
- libcpdb-frontend2

- libcpdb-dev
- libcpdb-frontend-dev
- libcpdb-backend-dev

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

- cpdb-libs-tools

cpdb-libs provides 2 library packages, both should to go to main. They implement the CPDB protocol. Frontends (print dialogs) need both, backends need only the first one. As they are libraries they usually do not need to get seeded, they will get pulled in through dependencies of the packages containing print dialogs or CPDB backends, especially now cpdb-backend-cups and cpdb-backend-file (see the other MIRs) and also GTK (4.9.4+) and later Qt (version TBD).

libcpdb2
libcpdb-frontend2

These are the headers and other development files, to be treated as usually -dev files of libraries in Main are treated. The third package is for convenience, so that if you want to create/build a backend, you build-depend only on libcpdb-backend-dev and if you want to to create/build a frontend you simply build-depend on libcpdb-frontend-dev.

libcpdb-dev
libcpdb-frontend-dev
libcpdb-backend-dev

This is actually only an example/demo frontend, it is actually used by the autopkgtests for this package (cpdb-libs) and for cpdb-backend-file. Can stay in Universe. Or should this be merged into the libcpdb-frontend-dev binary package then?

cpdb-libs-tools

Here is the Launchpad page with the current upload:

https://launchpad.net/ubuntu/+source/cpdb-libs/2.0~b3-0ubuntu2

All builds succeeded and links to the logs are there.

Changes in the debian/rules file and in the debian/ directory are practically only adaptations to the new naming, no more complexity.

There are also no new dependencies, I have even removed the build dependency on libcups2 as this one was wrong (the principle of CPDB of decoupling the print technologies into the backends would even prohibit that this package depends on libcups).

The autopkgtest is adapted to the new output wording of print_frontend.

New upstream release uploaded with "make check" test, a modification to facilitate creating "make check" tests in backends, plus fixes of bugs discovered during the test script development:

https://launchpad.net/ubuntu/+source/cpdb-libs/2.0~b4-0ubuntu1

Version 2.0~b4-0ubuntu2, with both build test and autopkgtest has successfully migrated from -proposed to release.

It will be needed when switching the build of GTK to use CPDB (Common Print Dialog Backends).

I reviewed cpdb-libs 2.0~b4-0ubuntu2 as checked into lunar. This shouldn't be considered a full audit but rather a quick gauge of maintainability.

cpdb-libs: code for frontend and backend libraries for the Common Printing Dialog Backends (CPDB) project. These libraries allow the CPDB frontends (the print dialogs) and backends (the modules communicating with the different printing systems) to communicate with each other via D-Bus.

- CVE History:
  - none
- Build-Depends?
  - debhelper-compat (=13)
  - autoconf
  - pkg-config
  - sharutils
  - libglib2.0-dev
  - libdbus-1-dev
  - dbus-daemon
    - ! note that dbus-broker aims to replace dbus-daemon with LP#2015538
- pre/post inst/rm scripts?
  - none
- init scripts?
  - none
- systemd units?
  - none
- dbus services?
  - no "dbus services" in packaging, but does mediate D-Bus communication
  - cpdb-libs-tools' cpdbPicklePrinterToFile() looks dangerous
  - g_bus_*/g_dbus_* use in cpdb-frontend.c appears fine
- setuid binaries?
  - none
- binaries in PATH?
  - ./usr/bin/cpdb-pickle-print
  - ./usr/bin/cpdb-text-frontend
  - note, binaries come from cpdb-libs-tools which Security NACKs for promotion
- sudo fragments?
  - none
  - false positives from README.md
- polkit files?
  - none
- udev rules?
  - none
- unit tests / autopkgtests?
  - has tests
- cron jobs?
  - none
- Build logs:
  - some lintain warnings

- Processes spawned?
  - none
- Memory management?
  - malloc, sprintf, and strcpy use appears okay
    - unclear what dialog_bus_name does and why it has a fixed buffer
  - cpdb-frontend.c uses g_new/g_new0 for allocation instead
    - possibly missing g_free cases
- File IO?
  - cpdb-frontend.c has heavy goto use for file handling
    - backend_file_name may not be freed etc
  - is log_file closed? is stderr closed?
  - _fine_
- Logging?
  - uses a mix of g_*() and log*()
  - user control of log verbosity
  - appears sane
- Environment variable usage?
  - XDG_CONFIG_HOME and HOME and possible mkdir handled well
  - LANGUAGE for locale
  - setenv("LANGUAGE", lang, 1) used in translation
  - CPDB_DEBUG_LEVEL, CPDB_DEBUG_LOGFILE, and CPDB_BACKEND_INFO_DIR also handled well
- Use of privileged functions?
 - none
- Use of cryptography / random number sources etc?
 - none
- Use of temp files?
  - pickle-printer uses the predictable/constant name /tmp/.printer-pickle
- Use of networking?
  - none
- Use of WebKit?
  - none
- Use of PolicyKit?
  - none

- Any significant cppcheck results?
  - resource leak
- Any significant Coverity results?
  - Upstream dev Michael Sweet determined that many reports were false postiives or negligible
  - some reports lead to fixes, others open
  - suggested https://scan.coverity.com/github to upstream
- Any significant shellcheck results?
  - nothing applicable
- Any significant bandit results?
  - none

Seth Arnold reported https://github.com/OpenPrinting/cpdb-libs/security/advisories/GHSA-25j7-9gfc-f46x (note, this URL may 404 until made public). For this and other reasons, Security NACKs the promotion of cpdb-libs-tools. Till okayed this as these tools are for development and debugging, and non-consequential to this MIR.

Switching from dbus-daemon to dbus...

Thanks, Mark, for the security review.

To get cpdb-libs into Mantic we need to seed cpdb-backend-cups (MIR bug 1747760) and cpdb-backend-file (MIR bug 2003272) now. The MIRs of these packages are only waiting for cpdb-libs to pass as dependency. cpdb-libs then gets pulled in automatically as dependency of the two backend packages.

To make CPDB actually be used in Mantic, GTK (gtk4 source package) needs to be built using CPDB. I have already done such a build for testing and uploaded it into this PPA:

https://launchpad.net/~till-kamppeter/+archive/ubuntu/new-arch-dev

The changes now need to be applied to the regular gtk4 package of Mantic.

The desktop-packages team has been subscribed and Till clarified the binary package to promote which was the other TODO ask from the MIR review, promoting

$ ./change-override -c main -t cpdb-libs
Override component to main
cpdb-libs 2.0~b4-0ubuntu2 in mantic: universe/net -> main
Override [y|N]? y
1 publication overridden.

 ./change-override -c main libcpdb-frontend2 libcpdb2
Override component to main
libcpdb-frontend2 2.0~b4-0ubuntu2 in mantic amd64: universe/libs/optional/100% -> main
libcpdb-frontend2 2.0~b4-0ubuntu2 in mantic arm64: universe/libs/optional/100% -> main
libcpdb-frontend2 2.0~b4-0ubuntu2 in mantic armhf: universe/libs/optional/100% -> main
libcpdb-frontend2 2.0~b4-0ubuntu2 in mantic ppc64el: universe/libs/optional/100% -> main
libcpdb-frontend2 2.0~b4-0ubuntu2 in mantic riscv64: universe/libs/optional/100% -> main
libcpdb-frontend2 2.0~b4-0ubuntu2 in mantic s390x: universe/libs/optional/100% -> main
libcpdb2 2.0~b4-0ubuntu2 in mantic amd64: universe/libs/optional/100% -> main
libcpdb2 2.0~b4-0ubuntu2 in mantic arm64: universe/libs/optional/100% -> main
libcpdb2 2.0~b4-0ubuntu2 in mantic armhf: universe/libs/optional/100% -> main
libcpdb2 2.0~b4-0ubuntu2 in mantic ppc64el: universe/libs/optional/100% -> main
libcpdb2 2.0~b4-0ubuntu2 in mantic riscv64: universe/libs/optional/100% -> main
libcpdb2 2.0~b4-0ubuntu2 in mantic s390x: universe/libs/optional/100% -> main
Override [y|N]? y
12 publications overridden.

Did cpdb-backend-cups and cpdb-backend-file receive MIR acks to be promoted to main?

cpdb-backend-file was approved in April LP: #2003272
cpdb-backend-cups appears to have been approved on September 13, 2018 !! LP: #1747760

The MIR team determined that those 2 packages didn't need a Security review.

Thanks Jeremy. This sounds okay to me.

I suspect that the dbus library will have less security issues than the implementation. OpenPrinting has been extremely responsive to security reports, so I'll just investigate the packages and report anything significant to upstream as to not block promotion.