[sane-devel] Sandboxing scanner applications
till.kamppeter at gmail.com
Thu Sep 17 23:20:23 BST 2020
as leader of the OpenPrinting project and so also the principal
architect of the printing environment of Linux and other POSIX-style
operating systems I have already started to work on sandboxed packaging
for printing (CUPS, printer drivers, applications which print or
administrate printing) and due to multi-function printers also worked on
sandboxed packaging for scanning. The implementation is already in the
works by a student project.
Printer and scanner drivers were added to a system by putting the
driver's files (filters and PPD files for printers, shared libraries for
scanners) into reserved directories of CUPS and SANE.
With sandboxed packages (Snap. flatpak, ...) this does not work as each
package has its own, separate file system. As we are working towards
distros totally based on sandboxed packaging, like an all-Snap Ubuntu.
By the way, I am working for Canonical, doing also the packaging of
printing-related stuff for Ubuntu, therefore I am more familiar with
Snap than with flatpak, but for flatpak it is probably similar.
For solving this problem we did not have to design something new from
the ground up, as the Printer Working Group (PWG, http://www.pwg.org/)
came up with IPP (Internet Printing Protocol) already 20 years ago and
more recently, they add the driverless IPP Everywhere printing and IPP
CUPS which was based on IPP currently uses filters and PPD files as
printer drivers, but due to the fact that PPD files are decades ole,
designed for PostScript printers, and not covering the needs of modern
printers, this concept is deprecated. CUPS should only support
driverless IPP printers in the future, most modern printers are
driverless, and if a driver is needed the driver should be provided as a
Printer Application, an emulated driverless IPP printer on the local
machine, a daemon which behaves as an IPP printer and internally
converts the job to the physical printer's format and sends it off to
the printer. The Printer Application advertises itself via DNS-SD, so
CUPS easily finds it, and via IPP CUPS can poll all capabilities, so no
local data files, like PPDs needed, purely driverless.
The communication between CUPS and the Printer Application is a network
(IP) communication, even if CUPS and the Printer Application are running
on the same machine. It is easy to create sandboxed packages which can
do IP communication, Snap for example has an appropriate interface for
that. So CUPS can be in a Snap and the Printer Application can be in
another Snap, and there can be any number of Printer Applications on the
same machine, for example if you use printers of different manufacturers.
Snaps (and probably flatpak packages, too) are distribution independent.
A Printer Application in the Snap Store should work on all
distributions, so manufacturers have much more ease to create drivers
for their hardware.
Seeing all this and also that the PWG created an IPP Scan standard to
complete IPP for multi-function devices I came up with an extension of
this idea to also allow snadboxed packaging of scanner drivers.
For this we create Scanner Applications, emulation of IPP scanners. The
Scanner Application listens for scan requests via IPP and passes on the
request to the actual scanner, and returns the scanned image, if needed,
converted to the requested data format. A client (a GUI application like
simple-scan for example) simply needs to talk IPP to the scanner (or
better Scanner Application), so it always works driverless.
So the Scanner Application replaces the classic SANE driver but as with
Printer Applications we have again a pure IP communication. So the
client and the drivefr can be in different Snaps (or flatpaks) and
distribution-independent scanner driver packages in the Store.
Naturally a Printer Application can also be an emulation of a
multi-function device, containing both printer and scanner drivers. We
can imaging that HPLIP could for example be provided this way. But this
is not required, the printing part of a multi-function device can be
supported by a Printer Application for Gutenprint and the scanning part
by a Scanner Application for SANE, think about Epson multi-function devices.
Do not think that I want to kill SANE, SANE will still be used but not
be that visible any more. We will create Scanner Applications which use
SANE internally, so that existing SANE drivers stay available in the new
world of IPP Scan, all scanners supported by SANE will also be supported
by a Scanner Application. We will also have an IPP Scan SANE backend, so
that client applications can scan on scanners supported by a Scanner
Application. As CUPS finds printers via DNS-SD, this backend will find
scanners (Scanner Applications) via DNS-SD.
For the sandboxed packaging, if one packages some SANE frontend, an
application which scans, one packages it with the IPP Scan SANE backend.
Then this sandboxed application can scan on all scanners supported by
Scanner Applications. The Scanner Applications get also sandboxed, like
Implementation of all this is already in the works, by two students
working in a Linux Foundation Mentorship Program project One student
expands sane-airscan to support IPP Scan as a client, to be packaged
with SANE frontends, applications which scan. The other student
implements IPP Scan as a server, to have the framework for Scanner
And here are some links for more details about all this:
OpenPrinting Microconference on Linux Plumbers Conference 2019
Here we have started the discussion about the driverless IPP scanning
My monthly news posts about the work at OpenPrinting
Here you can see how the development of driverless scanning and
Printer/Scanner Applications was going
OpenPrinting Microconference on Linux Plumbers Conference 2020
A lot has happened between the two microconferences on Linux Plumbers.
Here you get more concrete information about the new concepts.
Linux Foundation Mentorship Program project "IPP scan (or virtual MF
device) server (Scanner Application)":
The implementation of IPP Scan, extension of sane-airscan for IPP Scan
as a client support and extension of PAPPL for IPP Scan as a server support
Ongoing Google Season of Docs project on designing and packaging printer
and scanner drivers
Guidelines/Tutorial for free software projects and for hardware
manufacturers on creating printer and scanner drivers. It is not yet
complete, we are only one week into the 3 months of GSoD, but already a
lot of interesting info.
PAPPL - Printer Application Support Library
Everything which Printer/Scanner Applications have in common, to emulate
a complete network multi-function device, including DNS-SD advertising,
supply of full capability info via IPP, job handling, and also a web
admin interface, as on a physical printer.
sane-airscan - SANE backend for driverless scanning
Currently it supports the protocols multi-function devices which claim
to do AirPrint use for scanning (AirScan): eSCL and WSD. IPP Scan
support is about to be added.
CUPS Snap - The CUPS printing stack in a Snap
This is the official CUPS Snap, intended to be the standard printing
environment of Ubuntu, but can be used on any distribution with snapd
Bastien, so this is more your second approach of drivers being on the
host side, but we use IPP Scan as IPP is an established standard
protocol and it is used for both printing and scanning, so ideal for
multi-function devices. We get also interoperability between different
operating systems, scanning from mobile devices, ....
On 17/09/2020 11:40, Bastien Nocera wrote:
> I wanted to finally start looking at how to properly integrate SANE-
> based scanning applications into Flatpak.
> I looked at 2 different ways to implement this:
> - either the drivers are bundled with the application itself, and we
> need to punch holes for those drivers to be able to communicate with
> the hardware (eg. network, or USB),
> - or just as for a lot of other drivers, we can expect the drivers to
> live on the host side, with the distribution, and we'd communicate with
> those drivers (free or proprietary, like the ones for Epson V600...)
> through a service that's outside the sandbox.
> I think that the latter is the best one to put in place, especially if
> we want to support more complicated setups like networked scanners,
> multi-function devices, and proprietary drivers.
> The idea would be to reimplement the client (based on the "net" driver)
> to use D-Bus and reimplement or extend the server ("saned") to use D-
> Would the SANE project want to ship those in its own repositories? Are
> there are dependencies that wouldn't be acceptable? I plan on using
> systemd's D-Bus library, sd-bus, as it doesn't require a GLib mainloop
> like the very capable GDBus, so would be less disruptive when loaded
> into apps. Should I extend saned, or write a new daemon?
> : https://github.com/flatpak/xdg-desktop-portal/issues/218
> : https://github.com/flatpak/xdg-desktop-portal/issues/227
More information about the sane-devel