Initial support for IPP / driverless printing

[deeplow]

This PR includes two sets of changes: ( ⚠️ NOTE I originally thought they had to be in the same PR, but I may be able to split them for easier review)

• Print: Find alternative to PPD #2088 Changes export logic (in sd-devices) to be able to detect IPP printers without breaking compatibility with the old system.
  • To achieve this, ipp-usb is used in combination with Avahi. The former detects IPP-compatible printers and creates a local IPP server. Avahi allows for the discovery of these printing servers such that print dialogs can display print information.
  • Contrary to the legacy printer support, for driverless printing, no print queue is setup with lpadmin. Printers are automatically discovered.
• Switch printer front-end for SecureDrop Workstation #2156 Replacing XPP with a more modern alternative

To achieve this, ipp-usb is used in combination with Avahi. The former detects IPP-compatible printers and creates a local IPP server. Avahi allows for the discovery of these printing servers such that print dialogs can display print information.

Contrary to the legacy printer support, for driverless printing, no print queue is setup with lpadmin. Printers are automatically discovered.

Status

Work in progress

Description

Fixes #2088 #2156.

TODO:

• Find a way to have avahi enabled (preset as enabled is not cutting it)
• add print dialog code (and get PyGObject wheels to build) (used system packages in venv instead)
• handle exceptions
• add tests

Test Plan

• add cups and avahi to sd-devices Qubes services or alternative deploy Add avahi service to sd-devices (for driverless printing) securedrop-workstation#1235
• make build-debs
• Install export deb in large template
• in large template: sudo systemctl enable avahi-daemon
• Shut down template and ensure sd-devices is restarted
• Test driverless printing TKTKT

Checklist

If these changes modify code paths involving cryptography, the opening of files in VMs or network (via the RPC service) traffic, Qubes testing in the staging environment is required. For fine tuning of the graphical user interface, testing in any environment in Qubes is required. Please check as applicable:

• I have tested these changes in the appropriate Qubes environment
• I do not have an appropriate Qubes OS workstation set up (the reviewer will need to test these changes)
• These changes should not need testing in Qubes

If these changes add or remove files other than client code, the AppArmor profile may need to be updated. Please check as applicable:

• I have updated the AppArmor profile
• No update to the AppArmor profile is required for these changes
• I don't know and would appreciate guidance

If these changes modify the database schema, you should include a database migration. Please check as applicable:

• I have written a migration and upgraded a test database based on main and confirmed that the migration is self-contained and applies cleanly
• I have written a migration but have not upgraded a test database based on main and would like the reviewer to do so
• I need help writing a database migration
• No database schema changes are needed

[deeplow]

Progress update

I have now added the GTK dialog itself. As you can see it gets information from the printer before it shows the options. It's a bit of downside of driverless printing when the printer was not previously added. The user has to wait a tiny bit until the printer configurations are obtained. There are ways around that (i.e. adding a print queue), but that requires state, which we're avoiding in disposables. (we decided that here)

---

Next steps

I have updated the TODO list on the first post

[deeplow]

@legoktm regarding the following comment:

securedrop-client/export/pyproject.toml

Lines 14 to 21 in bdf52bc

	# In production these two are installed using a system package
	# so match those versions exactly
	pygobject = [
	{version = "=3.42.2", python = ">=3.11"}, # bookworm
	]
	pycairo = [
	{version = "=1.20.1", python = ">=3.11"}, # bookworm
	]

How critical is is that we keep this in sync? Should some sort of CI warning to update this when the debian packages have been updated? How is it handled for Qt in securedrop-client?

Also, do we need it in the root pyproject.toml? It's causing problems in the CI / safety (could be because it's asking for a later version).

[legoktm]

How critical is is that we keep this in sync? Should some sort of CI warning to update this when the debian packages have been updated? How is it handled for Qt in securedrop-client?

Relatively important, mostly so that our local operation and tests are using the same version that the package is. Realistically the version should only change when we switch Debian versions (e.g. bookworm -> trixie), so we can handle it then. It would be pretty rare for a version bump to come out once a version has already been made stable.

Also, do we need it in the root pyproject.toml?

No, just in export's. The only things in the root pyproject.toml should be the various CI tools we run across the whole project.

[deeplow]

How critical is is that we keep this in sync? Should some sort of CI warning to update this when the debian packages have been updated? How is it handled for Qt in securedrop-client?

Relatively important, mostly so that our local operation and tests are using the same version that the package is. Realistically the version should only change when we switch Debian versions (e.g. bookworm -> trixie), so we can handle it then. It would be pretty rare for a version bump to come out once a version has already been made stable.

OK.

Also, do we need it in the root pyproject.toml?

No, just in export's. The only things in the root pyproject.toml should be the various CI tools we run across the whole project.

I have removed it now. I may have added it originally by mistake.

[deeplow]

Challenge: how to access exceptions raised in GTK?

One challenge I was having was that exceptions were getting trapped in the GTK print dialog. But we needed to access those exceptions from non-GTK code (the one which calls GTK). However, GTK does not seem to like this use-case. I looked at a few alternative approaches:

• GTK application exit codes - GTK has a way to return some exit codes, but it requires setting up the GTK application as a CLI one. Ultimately this seemed to be more complex than it should for our case and we'd still need a way to map exit codes to print exceptions for proper handling.

• Modifying excepthook to close the GTK main loop when an exception is raised: Something like this:

    app = PrintDialog()
    def excepthook(type, value, tb):
      if app:
          app.quit()
      sys.__excepthook__(type, value, tb)

  I chose not to go this way given that globals are not ideal and they could introduce other kinds of issues.

• Context manager to keep track of exceptions - this is the option I went for, which piggy backs on the previous one, but does so with a context manager. The context manager returns a function to pass along the expected exception, which is then raised on exit. See the commit message for more details: e9ee2f0

Am I missing something? Are there better ways to approach this? I am not satisfied with the current solution, but strangely enough I couldn't find many attempts online at solving this particular issue.

[deeplow]

I have removed the _wait_for_print() method because the print dialog can already obtains some eventual errors occurred during the print job. So my implementation simply exits the dialog either with some error or success.

Proposed Troubleshooting Workflow

But not all failures were marked as errors by the print dialog. For example, I tried to print with an open tray and both dialogs were closed (PRINT_SUCCESS), but the printer errored out. Luckily, there is some information on the top right-hand corner of the screen:

If I wanted to troubleshoot, I could click on the little "printer" icon in the tray menu and it would open the queued print documents and some actions to troubleshoot:

Instead of waiting for the document to be printed with a spinning icon in the client dialog, I'd propose that we close all dialogs if successfully sent the job to the printer tools. What this means .

I guess ultimately this a UX question. Should I re-implement a way to have the client print dialog hanging / waiting while a document is fully printed, or should all print-related dialogs close as soon as the print is initiated and we let the users troubleshoot via messages in the right-hand corner and the respective print queue utility (accessed from the tray menu)?