OpenPrinting NEWS from Linux Plumbers 2022 AKA feel free to try driverless printing and printer applications in SNAPs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,

I've virtually attended OpenPrinting Micro Conference on Linux Plumbers 2022 and took notes about our latest development - the notes are in attachment.

From the development field the highlight is that we don't release CUPS 2.5 (and 3.0) until we have full OAuth support, which will replace Kerberos support in CUPS 3.0. Currently we have OAuth requests implemented, but we are missing several fundamental internals to make it properly working.

But the biggest highlight is that all printer driver packages from Debian (we don't have any additional printer driver packages in Fedora in comparison to Debian, so Fedora printer drivers should be covered by them as well) are now covered by printer applications, so you can test how your printer will work with printer application (in case your printer doesn't support driverless standards or driverless standard has missing functionality you need).

Unfortunately there are currently only printer applications in SNAP, because I'm waiting on cups-filters 2.0, which is required for printer applications, but the code base is the same as it will be in RPMs, so it would be great to test the printer applications as soon as possible.

HOW TO TEST:

A) HOW TO TEST A PRINTER via PRINTER APPLICATION

1. install snapd

$ sudo dnf -y install snapd
$ sudo ln -s /var/lib/snapd/snap /snap

2. install the SNAP of printer application and run it - right now you have to choose it by yourself according the driver package you use (ps-printer-app is for postscript printers, which usually live in foomatic and hplip packages, hplip-printer-app is for all printers from hplip package, gutenprint-printer-app for gutenprint, and all others probably by ghostscript-printer-app), but GNOME control center is working on their automatic installation based on your model:

$ sudo snapd install --edge ps-printer-app
$ sudo snapd run ps-printer-app

Then go to its web interface at http://localhost:8000 (https is available as well, but Firefox complains about self signed cert, which is IMO harmless on localhost service)

3. click on 'Add Printer' on the main page,
4. choose the printer's name,
5. select the found device or choose 'Network printer' from 'Device' scroll menu and provide hostname or IP of the device,
6. choose to auto-detect driver or select the driver by yourself,
7. click on 'Add Printer',
8. now the printer should be available at 'avahi-browse -avrt' and 'lpstat -e', but not in 'lpstat -a'

9. check its provided options by 'lpoptions -p <printer_name> -l'

IN CASE OF BUGS/MISSING OPTIONS SO FAR - report to the specific printer application at https://github.com/OpenPrinting

10. try to print via 'lp' command using this new printer and try options you frequently use - the correct option names and values are seen in 'lpoptions' output and you can use it in 'lp' command like this:

```

$ lpoptions -p HP_Laserjet_M1536 -l
PageSize/Media Size: 184.15x260mm 195.09x269.88mm A4 A5 B5 DoublePostcardRotated Env10 EnvC5 EnvDL EnvMonarch Executive
--------                                          --
Duplex/Duplex: *None DuplexNoTumble DuplexTumble
------               --------------
OutputBin/OutputBin: *FaceDown

```

$ lp -d HP_Laserjet_M1536 -o PageSize=A4 -o Duplex=DuplexNoTumble ... <file>

IN CASE OF BUGS/BROKEN FUNCTIONALITY DURING PRINTING VIA LP - report the issue into Fedora bugzilla to cups component

11. try to print via your favorite document viewer or browser using this new printer - choose this new printer which shared from printer application and check the options you use

IN CASE OF BUGS/BROKEN FUNCTIONALITY/MISSING OPTIONS DURING THIS STEP - report issues to the component in bugzilla representing your chosen application


B) HOW TO TEST A DRIVERLESS PRINTER

1. check whether your printer is capable of driverless printing by 'ipptool' for network printers (once you enable IPP on the printer's web interface):

$ ipptool -tv ipp://printer.example.com/ipp/print get-printer-attributes.test

or by 'lsusb -v' - check https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks/#_how_to_find_out_if_my_usb_device_supports_ipp_over_usb for more information

2. if your printer support driverless standard - you know from the previous step, setup your environment according https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks/#_how_to_setup_cups_temporary_queues_with_network_printer for network printer or according https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks/#_how_to_setup_cups_temporary_queues_with_usb_printer for USB printer. Otherwise try the steps for printer applications above.

3. check whether you see the printer in 'avahi-browse -avrt', in 'lpstat -e', but not in 'lpstat -a'

4. check what options are provided by 'lpoptions -p <printer> -l'

5. try to print to the printer via 'lp' command, using the options you frequently use, f.e.

$ lp -d <printer> -o PageSize=A4 -o Duplex=DuplexNoTumble <file>

IN CASE OF BUGS/MISSING IMPORTANT OPTIONS/OTHER PROBLEMS - report the issue to the Fedora bugzilla to component cups - driverless standards sometimes provide less options than classic drivers, because they focus on common options and many users are not aware of driverless printing and use the classic drivers, so I would like to track such models.

6. try to print to found printer via your favorite viewer or browser - check whether the printer is seen and has all the options shown by 'lpoptions'

IN CASE OF BUGS/BROKEN FUNCTIONALITY/MISSING OPTIONS DURING THIS STEP - report issues to the component in bugzilla representing your chosen application


KNOWN BUGS:

Several printer configuration tools (GNOME Control Center, system-config-printer at least, I'm not sure about others) is not able to see temporary queues or they're seen as 'ghost printers'  and don't communicate with printer applications (by communication I mean their installation based on your printer model and providing the link to the printer application Web UI). GNOME Control Center is working on improving IPP support and adding printer application support right now.


Thank you for reading this far and if you are able to test, thank you in advance!


Zdenek

-- 
Zdenek Dohnal
Software Engineer
Red Hat, BRQ-TPBC
Open Printing Mini-conference 2022
==================================

CUPS 2.5 and 3.0 development
-----------------------------
- 2.4.x and printer applications
  - manager Zdenek Dohnal
  - currently on the way for 2.4.3 - color fixes, OpenSSL fixes (cert issues will be fixed soon)
  - printer apps - check OpenPrinting and michaelrsweet repos at Github
- 2.5 and OAuth
  - Till Kamppeter will be the release manager
  - QAuth support will be finished there and tested
  - localization improvements going to happen
  - first beta in March 2023, GA in May 2023
  - OAuth support:
    - protocol work being done in IPP PWG group
    - the current 2.4.x has a WIP OAuth implementation, but it is missing internals of OAuth support
    - we have to implement OAuth callback and Bearer auth method for the cupsd daemon
    - json tickets being added to libcups project
    - we need desktop developer for OAuth UI - synch up with GNOME
      - if they have some OAuth, see if we can use it
      - do we need a separate project for UI and DBUS service?
      - coordinate X509/OAuth functionality with CUPS 3.0 development and provide a clear migration path for the functionality
  - we won't release 2.5 without OAuth support

- don't be afraid of 3.0 and printer applications - we have covered all printer drivers from Debian distro - the schedule is optimistic and you still have 2.5 in the meantime
- new Ubuntu version will include only CUPS SNAP with printer applications, since Ubuntu moves towards SNAP-only distro
- GNOME control center will have support for printer applications - can download the printer app from SNAP and open its web UI

- 3.0
  - manager Michael Sweet
  - mover away from PPD files
  - split between local and sharing servers + libcups + tools
  - splitted projects are getting to beta state - available on OpenPrinting and Mike's github
  - libcups
    - OpenPrinting/libcups
    - removed PPD API and other deprecations
    - using bool and size_t
    - MIGRATING.md and CUPS programming manuals created/updated
    - threading APIs, IPP data file, portable DNS-SD
    - we still have to add DBUS interface, JSON support on the way, ipptool fixes
  - cups-commands
    - lpinfo removed, lpadmin updated for PPD free world
  - cups-local
    - OpenPrinting/cups-local
    - baseline code commited and rebuilt
    - pre-beta - test on your own risk, but any test help is welcome
    - communication with printers, convert to PDF/raster as needed for printer, job his
    - configuration limited to profiles
  - cups-sharing
    - OpenPrinting/cups-sharing
    - rebuilt and base code line in it
    - waiting for OAuth from 2.5
    - printing after swiping the card will be supported, 

  What we need:
    - UI 
      - we have to get rid of PPD API in print dialogs, auth via OAuth in UI and consent for accounting/privacy
        (we have a list of needed info for printer and if user doesn't provide them, the printing won't happen - we need UI for this)
    - CLI auth and API key support
    - profiles in enterprise networks
    - printing via IPPEve/AirPrint/Mopria, Windows/SMB (Postscript/PCL), Printing to file (PDF)

  - we need something else for transformations - PDFio for PDF, Poppler/Xpdf on Linux, CoreGraphics on macOS (Google has a possible candidate, but needs Google buildsystem/looking to Cairo)
    - looking for common graphics library


Testing and CI for OpenPrinting projects
----------------------------------------
- we're moving to CI :)
- mostly via Github Actions - "Build" workflow (classic build on different archs with 'make test'),
  static analyzers ("CodeQL", "Coverity", "LGTM" - lgtm is moved to GitHub default checks), "Docker" (tries to create Docker image)
- we're not doing distro-dependent package testing like DEB or RPM
- defined in yaml under .github/workflows
  - if tests require password/cert, it can be passed via environment defined in workflows
- currently projects using CI - CUPS, ippeveselfcert, ippsample, libcups, LPrint, PAPPL, PDFio
- it would be great to add regression testing, possibly private CVE testing, filter testing via huge amount of files


Restricting access to IPP printers with Oauth2 framework
--------------------------------------------------------
- common OAuth2 use case - browser asks auth.server for code, and then OAuth client asks Authorization server with authorization code, client then work with authorization server until 
  client get access token and gets data from resource server
- IPP case - IPP printer as resource server, OAuth client == IPP client, Authorization server and Browser
- assumptions:
  - IPP printer has only one authorization server and knows URL of author. server
  - IPP client doesn't know of implementation of IPP printer Author. server
  - all communication via https (required by OAuth2 standard)
- security implications:
  - needed for security:
    - protect user data between client and server
    - protect printer resources - have an access list of users for printers
- IPP clients:
  - IPP printers can be found by mDNS, defined by user or queried from print server
  - author. server can be get from IPP Printer or predefined by users (the latter highly preferred)
- TLS pros/cons - protected against man-in-the-middle, encryption, but we don't know what the hostname really is
  - we need to know the other side is really IPP printer
- Authorization server
  - its URL has to be verified
- IPP printer verification
  - verifying its URL
  - we need to ask Authorization server for this information - extending OAuth protocol via Token Exchange (RFC 8693)
    - client sends token exchange to auth. server - has access token and URL, auth. server responds
    - not yet implemented
  - other means? obtaining IPP Printer URLs from trusted source only, different rules for IPP Printers
- current status - ongoing work on protocol in IPP PWG group, OAuth 2.0 requests in CUPS 2.4.x, working on IPP OAuth client in Chrome OS
- TLS minimal version - probably the latest ones, which can be a problem in the future when older printers which can do OAuth now won't be
  to do it due low TLS support - now OAuth2 requires TLS 1.2+ since RFC 6749
- IPP Everywhere 2.0 standard will require TLS1.2 or TLS1.3 or higher - all IPP printers must support TLS and only support TLS1.2 or higher
  - tested in ippeveselfcert


Documentation for OpenPrinting projects
---------------------------------------
- we need 3 kinds of docs:
  - user
  - admin
  - developer
- you can automate the dev docs, but user/admin has to be by 'hand'
- usually write good code and you don't need much docs :) - autoconfiguration, intuitive, readable
- docs has to be easy to access and read as well, but trying to limit this
- CUPS
  - we have html docs generated from man pages, markdown files. Dev docs are generated from API
    via CodeDoc and includes handwritten CUPS Programming Manual
  - docs source format - asciidoc, markdowns (github one, original)
  - tools - doxygen, sphinx, codedoc

- OpenPrinting docs:
  - printer application docs available on OpenPrinting webpage - https://openprinting.github.io
  - docs for wsl-printer-app - printer application for legacy printers on Windows
  - news on our OpenPrinting web site

- what we need?:
  - we can't follow Google Season of Docs due additional bureucracy...
  - follow CUPS DEVELOPING.md in our projects, not just in Mike's projects :)
  - debugging docs - synch with Brian Potkin from Debian


Sandboxing/Containerizing alternatives to Snap for Printer Application and CUPS
-------------------------------------------------------------------------------
- flatpak is not for daemons, appimage is not secure
- maybe docker/podman containers?
- can be run with 'quadlet'

- containers in Ubuntu
  - making a container doesn't solve all security
  - there were several distroless containers - Google Distroless
  - now we have Ubuntu distroless base - no package manager, no shell
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux