Re: [Printing-architecture] OpenPrinting MC from Linux Plumber 2022

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