Re: F38 proposal: IPP-USB as a weak dependency of CUPS and sane-airscan (Self-Contained Change proposal)
Zdenek Dohnal wrote: > On 1/16/23 12:31, Björn Persson wrote: > > Robert Marcano via devel wrote: > >> The admin can implement CUPS > >> authentication but an ipp://localhost:6 open port entirely open to > >> anyone on the local machine to submit print jobs directly bypassing CUPS. > > > > In that case it's also accessible to all the untrusted Javascript junk > > that regularly runs in the user's browser. Because IPP is built on HTTP, > > a Javascript program can tell the browser to send an IPP request. What > > has been done to secure those "virtual printer devices" against DNS > > rebinding attacks? > > https://en.wikipedia.org/wiki/DNS_rebinding > > I'll ask IPP-USB upstream about it, stay tuned. What did upstream answer? Björn Persson pgp52ZeVNAUhQ.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: IPP-USB as a weak dependency of CUPS and sane-airscan (Self-Contained Change proposal)
On 1/18/23 2:46 PM, Robert Marcano wrote: On 1/17/23 8:19 AM, Zdenek Dohnal wrote: Well in a matter of speaking this is doable even without IPP-USB advertised device. Every application can just send data to printer's port and IP or get USB interface handler and talk with the device via USB. Even an application which implements IPP client can omit CUPS and talk with IPP printer directly. In cases where application generates a printer ready file (f.e. in PCL format) which have all user's option applied already is desired to bypass CUPS and talk with the printer - I've heard there are such applications already bypassing CUPS, because they want to pass such a file. So it is not something uncommon in my opinion. Forgot to add this: USB device access can be protected with filesystems permissions, so it is possible to protect direct access if some installation requires it. Way easier than firewall rules IMHO. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: IPP-USB as a weak dependency of CUPS and sane-airscan (Self-Contained Change proposal)
On 1/17/23 8:19 AM, Zdenek Dohnal wrote: Hi Robert, On 1/13/23 15:12, Robert Marcano via devel wrote: Nothing against driverless printing, this is something I really like, bit I think all the move to HTTP is ignoring the feature that is being removed, and that I have an use for. There is not possible to have a printer connected to a computer that can't be restricted by CUPS to be used by only a few authorized users. The admin can implement CUPS authentication but an ipp://localhost:6 open port entirely open to anyone on the local machine to submit print jobs directly bypassing CUPS. Well in a matter of speaking this is doable even without IPP-USB advertised device. Every application can just send data to printer's port and IP or get USB interface handler and talk with the device via USB. Even an application which implements IPP client can omit CUPS and talk with IPP printer directly. In cases where application generates a printer ready file (f.e. in PCL format) which have all user's option applied already is desired to bypass CUPS and talk with the printer - I've heard there are such applications already bypassing CUPS, because they want to pass such a file. So it is not something uncommon in my opinion. There are many other reasons to disallow direct access to the printer application, like wanting to do printing accounting with CUPS, for example. If an application uses CUPS API, the communication will go via CUPS daemon (CUPS Local daemon in CUPS 3.x) which will do a printing accounting (in CUPS 3.x it will be in CUPS sharing daemon). We can't forbid the application to bypass CUPS if it is its developer's will, as we can't now. Unless every printer application support some kind of authentication mechanism over their HTTP server, controlling direct access to the printers is not possible. Do ipp-usb support at least basic authentication so a permanent queue could be setup with these credentials? IPP-USB currently does not provide authentication functionality AFAIK and how it looks from the code, but I've asked upstream. According IPP-USB man page you can turn off mDNS advertising to don't share the port existence on your localhost, or probably create a firewall rule Chris mentioned. The ticket is here https://github.com/OpenPrinting/ipp-usb/issues/61 Commented there, thanks. Note: I really wish CUPS supported some kind of IPP over Unix domain sockets so file system restrictions could be used to control access to locally installed printer applications, but the last time I mentioned that on a CUPS issue, sadly it was plainly rejected. Do you have a link to the ticket? AFAIK Unix domain socket is one of the features which is planned for CUPS 3.x, but it might not be the one you mean. It was all before the OpenPrinting fork, beware, hidden inside the Load More (comments) actions: https://github.com/apple/cups/issues/5271#issuecomment-630905653 https://github.com/apple/cups/issues/5271#issuecomment-630929217 Notice I wanted Unix domain socket support because of another use case. Application provided virtual printer, I mean, an application running on the user session being able to function as a printer to receive a document for archival purposes. Currently with printer driver, the print output is redirected from CUPS to the application on the user session, with proper identification of the user that requested the virtual print operation. With everything moved to HTTP, the virtual printer being run on the user session is now open to documents being printed by everyone and no way to identify the originating connection uid. The originating connection can be obtained for Unix sockets on Linux, so identifying it comes from CUPS then the printer applications can now trust the information sent via IPP about the user that is printing. Zdenek [https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks/#_how_to_install_a_permanent_print_queue here] is the manual. However if mDNS is enabled, the virtual device shared by `ipp-usb` can be automatically picked up by other services (as `cups` or `sane-airscan`), so no further configuration is required to get the device installed. The feature is called ''temporary queue'' in CUPS and it is supported in applications using the up-to-date CUPS API or toolkits using up-to-date CUPS API - f.e. GTK3+ based applications, Libreoffice and Firefox. The fax functionality is available at URI `ipp://localhost:6/ipp/faxout`, but the automatic installation doesn't work for it and it has to be installed manually. As mentioned above, the `ipp-usb` daemon claims the USB interface of the device which supports IPP over USB standard. This behavior conflicts with the previous driver approach, where the discovery mechanism only scans USB ports for available devices, but doesn't try to claim the USB interface, which is unavailable because `ipp-usb` has claimed it already. The result is the device
Re: F38 proposal: IPP-USB as a weak dependency of CUPS and sane-airscan (Self-Contained Change proposal)
On 1/16/23 12:31, Björn Persson wrote: Robert Marcano via devel wrote: The admin can implement CUPS authentication but an ipp://localhost:6 open port entirely open to anyone on the local machine to submit print jobs directly bypassing CUPS. In that case it's also accessible to all the untrusted Javascript junk that regularly runs in the user's browser. Because IPP is built on HTTP, a Javascript program can tell the browser to send an IPP request. What has been done to secure those "virtual printer devices" against DNS rebinding attacks? https://en.wikipedia.org/wiki/DNS_rebinding I'll ask IPP-USB upstream about it, stay tuned. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- Zdenek Dohnal Software Engineer Red Hat, BRQ-TPBC ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: IPP-USB as a weak dependency of CUPS and sane-airscan (Self-Contained Change proposal)
Hi Robert, On 1/13/23 15:12, Robert Marcano via devel wrote: Nothing against driverless printing, this is something I really like, bit I think all the move to HTTP is ignoring the feature that is being removed, and that I have an use for. There is not possible to have a printer connected to a computer that can't be restricted by CUPS to be used by only a few authorized users. The admin can implement CUPS authentication but an ipp://localhost:6 open port entirely open to anyone on the local machine to submit print jobs directly bypassing CUPS. Well in a matter of speaking this is doable even without IPP-USB advertised device. Every application can just send data to printer's port and IP or get USB interface handler and talk with the device via USB. Even an application which implements IPP client can omit CUPS and talk with IPP printer directly. In cases where application generates a printer ready file (f.e. in PCL format) which have all user's option applied already is desired to bypass CUPS and talk with the printer - I've heard there are such applications already bypassing CUPS, because they want to pass such a file. So it is not something uncommon in my opinion. There are many other reasons to disallow direct access to the printer application, like wanting to do printing accounting with CUPS, for example. If an application uses CUPS API, the communication will go via CUPS daemon (CUPS Local daemon in CUPS 3.x) which will do a printing accounting (in CUPS 3.x it will be in CUPS sharing daemon). We can't forbid the application to bypass CUPS if it is its developer's will, as we can't now. Unless every printer application support some kind of authentication mechanism over their HTTP server, controlling direct access to the printers is not possible. Do ipp-usb support at least basic authentication so a permanent queue could be setup with these credentials? IPP-USB currently does not provide authentication functionality AFAIK and how it looks from the code, but I've asked upstream. According IPP-USB man page you can turn off mDNS advertising to don't share the port existence on your localhost, or probably create a firewall rule Chris mentioned. The ticket is here https://github.com/OpenPrinting/ipp-usb/issues/61 Note: I really wish CUPS supported some kind of IPP over Unix domain sockets so file system restrictions could be used to control access to locally installed printer applications, but the last time I mentioned that on a CUPS issue, sadly it was plainly rejected. Do you have a link to the ticket? AFAIK Unix domain socket is one of the features which is planned for CUPS 3.x, but it might not be the one you mean. Zdenek [https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks/#_how_to_install_a_permanent_print_queue here] is the manual. However if mDNS is enabled, the virtual device shared by `ipp-usb` can be automatically picked up by other services (as `cups` or `sane-airscan`), so no further configuration is required to get the device installed. The feature is called ''temporary queue'' in CUPS and it is supported in applications using the up-to-date CUPS API or toolkits using up-to-date CUPS API - f.e. GTK3+ based applications, Libreoffice and Firefox. The fax functionality is available at URI `ipp://localhost:6/ipp/faxout`, but the automatic installation doesn't work for it and it has to be installed manually. As mentioned above, the `ipp-usb` daemon claims the USB interface of the device which supports IPP over USB standard. This behavior conflicts with the previous driver approach, where the discovery mechanism only scans USB ports for available devices, but doesn't try to claim the USB interface, which is unavailable because `ipp-usb` has claimed it already. The result is the device can be discovered by classic driver tools, but it won't work once user wants to print, scan or fax. In such cases user intervention is needed, where user has to make a decision whether to use driverless USB support or classic support with drivers. The way how to do it will be explained later in this proposal. Based on the current `ipp-usb` design the following specific setups aren't expected to work, because they are not common with USB device usage: * combining driverless and classic driver's support doesn't work on the same device - driverless or classic driver has to be used for whole device's functionality. * if user has several devices of the same model, all of them has to be supported by a single solution - driverless or classic driver - because quirks and SANE backends use model name, vendor ID or product ID, which are the same for all devices of the same model, for denying the support. * if scanner backend does not support disabling support for a specific device (f.e. `hpaio`, `pixma` are such backends), the whole backend can be disabled to prevent discovering broken scanners - it results in the scanner support provided by the
Re: F38 proposal: IPP-USB as a weak dependency of CUPS and sane-airscan (Self-Contained Change proposal)
Robert Marcano via devel wrote: > The admin can implement CUPS > authentication but an ipp://localhost:6 open port entirely open to > anyone on the local machine to submit print jobs directly bypassing CUPS. In that case it's also accessible to all the untrusted Javascript junk that regularly runs in the user's browser. Because IPP is built on HTTP, a Javascript program can tell the browser to send an IPP request. What has been done to secure those "virtual printer devices" against DNS rebinding attacks? https://en.wikipedia.org/wiki/DNS_rebinding Considering the attitude to security I've seen from CUPS before, I won't be surprised if they just assume that someone else will protect them from DNS rebinding attacks. Björn Persson pgpUOI2iQT6TU.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: IPP-USB as a weak dependency of CUPS and sane-airscan (Self-Contained Change proposal)
On 1/13/23 8:53 PM, Chris Adams wrote: Once upon a time, Robert Marcano said: Nothing against driverless printing, this is something I really like, bit I think all the move to HTTP is ignoring the feature that is being removed, and that I have an use for. There is not possible to have a printer connected to a computer that can't be restricted by CUPS to be used by only a few authorized users. The admin can implement CUPS authentication but an ipp://localhost:6 open port entirely open to anyone on the local machine to submit print jobs directly bypassing CUPS. I haven't tried it with firewalld or the newer nftables, but old iptables could set rules based on user ID. I'd expect nftables also implemented that, and firewalld could handle it in some fashion (possibly a rich rule). With that, you could limit HTTP access to root (I think cups runs as root). Sounds like an ugly workaround, but betther than nothing. Looks possible with nftables, it can even be possible to match the CUPS cgroup. But there isn't anything for UID or cgroups on firewalld rich language syntax. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: IPP-USB as a weak dependency of CUPS and sane-airscan (Self-Contained Change proposal)
Once upon a time, Robert Marcano said: > Nothing against driverless printing, this is something I really > like, bit I think all the move to HTTP is ignoring the feature that > is being removed, and that I have an use for. There is not possible > to have a printer connected to a computer that can't be restricted > by CUPS to be used by only a few authorized users. The admin can > implement CUPS authentication but an ipp://localhost:6 open port > entirely open to anyone on the local machine to submit print jobs > directly bypassing CUPS. I haven't tried it with firewalld or the newer nftables, but old iptables could set rules based on user ID. I'd expect nftables also implemented that, and firewalld could handle it in some fashion (possibly a rich rule). With that, you could limit HTTP access to root (I think cups runs as root). -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: IPP-USB as a weak dependency of CUPS and sane-airscan (Self-Contained Change proposal)
On 1/12/23 1:15 PM, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/IPPUSBasPrintScanDependency This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Add `ipp-usb` as a weak dependency of packages which provide support for driverless printing (`cups`), driverless scanning (`sane-airscan`) and driverless fax for USB devices capable of using driverless functionality (how to find out whether your USB device is driverless [https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks/#_how_to_find_out_if_my_usb_device_supports_ipp_over_usb here]), so such devices will work without a specific driver. `ipp-usb` design conflicts with the way how drivers work with the device, so a user intervention is required after upgrade. == Owner == * Name: [[User:Zdohnal | Zdenek Dohnal]] * Email: zdoh...@redhat.com == Detailed Description == Nowadays most printers and scanners from common vendors provide a way how to work without a specific driver. This way relies on driverless standards implemented in device's firmware and their support in the operating system user has. At first (in 2010) network driverless standards were implemented in devices and widely spread, such as AirPrint, [https://www.pwg.org/ipp/everywhere.html IPP Everywhere] for printers or eSCL (sometimes called AirScan) and WSD (Windows Service Discovery) for scanners. Those network driverless standards and others are already supported in `cups` (for printing) and `sane-airscan` packages. Two years later USB devices got their own driverless standard - [https://robots.org.uk/IPPOverUSB?action=AttachFile=view=IPP+USB+Specification.pdf IPP over USB] - which is now implemented by `ipp-usb`. The package itself has been in Fedora for more than two years available for users to opt-in USB driverless support. The `ipp-usb` package contains `ipp-usb` daemon, which works as an HTTP proxy over the claimed USB devices, provides printing (via [http://ftp.pwg.org/pub/pwg/standards/std-ipp20-20151030-5100.12.pdf IPP 2.0+] protocol), scanning (via eSCL) and fax (via [http://ftp.pwg.org/pub/pwg/candidates/cs-ippfaxout10-20140618-5100.15.pdf IPP Faxout]) support and advertises them on localhost by mDNS protocol. mDNS is the key feature for automatic discovery, but it is not required to use it - the virtual printer device provided by `ipp-usb` can be accessed at URI `ipp://localhost:6/ipp/print` and the URI can be used for permanent queue installation - Nothing against driverless printing, this is something I really like, bit I think all the move to HTTP is ignoring the feature that is being removed, and that I have an use for. There is not possible to have a printer connected to a computer that can't be restricted by CUPS to be used by only a few authorized users. The admin can implement CUPS authentication but an ipp://localhost:6 open port entirely open to anyone on the local machine to submit print jobs directly bypassing CUPS. There are many other reasons to disallow direct access to the printer application, like wanting to do printing accounting with CUPS, for example. Unless every printer application support some kind of authentication mechanism over their HTTP server, controlling direct access to the printers is not possible. Do ipp-usb support at least basic authentication so a permanent queue could be setup with these credentials? Note: I really wish CUPS supported some kind of IPP over Unix domain sockets so file system restrictions could be used to control access to locally installed printer applications, but the last time I mentioned that on a CUPS issue, sadly it was plainly rejected. [https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks/#_how_to_install_a_permanent_print_queue here] is the manual. However if mDNS is enabled, the virtual device shared by `ipp-usb` can be automatically picked up by other services (as `cups` or `sane-airscan`), so no further configuration is required to get the device installed. The feature is called ''temporary queue'' in CUPS and it is supported in applications using the up-to-date CUPS API or toolkits using up-to-date CUPS API - f.e. GTK3+ based applications, Libreoffice and Firefox. The fax functionality is available at URI `ipp://localhost:6/ipp/faxout`, but the automatic installation doesn't work for it and it has to be installed manually. As mentioned above, the `ipp-usb` daemon claims the USB interface of the device which supports IPP over USB standard. This behavior conflicts with the previous driver approach, where the discovery mechanism only scans USB ports for available devices, but doesn't try to claim the USB interface, which is unavailable because `ipp-usb` has claimed it already. The result is the device can be discovered by classic driver
F38 proposal: IPP-USB as a weak dependency of CUPS and sane-airscan (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/IPPUSBasPrintScanDependency This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Add `ipp-usb` as a weak dependency of packages which provide support for driverless printing (`cups`), driverless scanning (`sane-airscan`) and driverless fax for USB devices capable of using driverless functionality (how to find out whether your USB device is driverless [https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks/#_how_to_find_out_if_my_usb_device_supports_ipp_over_usb here]), so such devices will work without a specific driver. `ipp-usb` design conflicts with the way how drivers work with the device, so a user intervention is required after upgrade. == Owner == * Name: [[User:Zdohnal | Zdenek Dohnal]] * Email: zdoh...@redhat.com == Detailed Description == Nowadays most printers and scanners from common vendors provide a way how to work without a specific driver. This way relies on driverless standards implemented in device's firmware and their support in the operating system user has. At first (in 2010) network driverless standards were implemented in devices and widely spread, such as AirPrint, [https://www.pwg.org/ipp/everywhere.html IPP Everywhere] for printers or eSCL (sometimes called AirScan) and WSD (Windows Service Discovery) for scanners. Those network driverless standards and others are already supported in `cups` (for printing) and `sane-airscan` packages. Two years later USB devices got their own driverless standard - [https://robots.org.uk/IPPOverUSB?action=AttachFile=view=IPP+USB+Specification.pdf IPP over USB] - which is now implemented by `ipp-usb`. The package itself has been in Fedora for more than two years available for users to opt-in USB driverless support. The `ipp-usb` package contains `ipp-usb` daemon, which works as an HTTP proxy over the claimed USB devices, provides printing (via [http://ftp.pwg.org/pub/pwg/standards/std-ipp20-20151030-5100.12.pdf IPP 2.0+] protocol), scanning (via eSCL) and fax (via [http://ftp.pwg.org/pub/pwg/candidates/cs-ippfaxout10-20140618-5100.15.pdf IPP Faxout]) support and advertises them on localhost by mDNS protocol. mDNS is the key feature for automatic discovery, but it is not required to use it - the virtual printer device provided by `ipp-usb` can be accessed at URI `ipp://localhost:6/ipp/print` and the URI can be used for permanent queue installation - [https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks/#_how_to_install_a_permanent_print_queue here] is the manual. However if mDNS is enabled, the virtual device shared by `ipp-usb` can be automatically picked up by other services (as `cups` or `sane-airscan`), so no further configuration is required to get the device installed. The feature is called ''temporary queue'' in CUPS and it is supported in applications using the up-to-date CUPS API or toolkits using up-to-date CUPS API - f.e. GTK3+ based applications, Libreoffice and Firefox. The fax functionality is available at URI `ipp://localhost:6/ipp/faxout`, but the automatic installation doesn't work for it and it has to be installed manually. As mentioned above, the `ipp-usb` daemon claims the USB interface of the device which supports IPP over USB standard. This behavior conflicts with the previous driver approach, where the discovery mechanism only scans USB ports for available devices, but doesn't try to claim the USB interface, which is unavailable because `ipp-usb` has claimed it already. The result is the device can be discovered by classic driver tools, but it won't work once user wants to print, scan or fax. In such cases user intervention is needed, where user has to make a decision whether to use driverless USB support or classic support with drivers. The way how to do it will be explained later in this proposal. Based on the current `ipp-usb` design the following specific setups aren't expected to work, because they are not common with USB device usage: * combining driverless and classic driver's support doesn't work on the same device - driverless or classic driver has to be used for whole device's functionality. * if user has several devices of the same model, all of them has to be supported by a single solution - driverless or classic driver - because quirks and SANE backends use model name, vendor ID or product ID, which are the same for all devices of the same model, for denying the support. * if scanner backend does not support disabling support for a specific device (f.e. `hpaio`, `pixma` are such backends), the whole backend can be disabled to prevent discovering broken scanners - it results in the scanner support provided by the backend will be disabled for all other devices which are in the user's environment - both network and USB. To
F38 proposal: IPP-USB as a weak dependency of CUPS and sane-airscan (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/IPPUSBasPrintScanDependency This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Add `ipp-usb` as a weak dependency of packages which provide support for driverless printing (`cups`), driverless scanning (`sane-airscan`) and driverless fax for USB devices capable of using driverless functionality (how to find out whether your USB device is driverless [https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks/#_how_to_find_out_if_my_usb_device_supports_ipp_over_usb here]), so such devices will work without a specific driver. `ipp-usb` design conflicts with the way how drivers work with the device, so a user intervention is required after upgrade. == Owner == * Name: [[User:Zdohnal | Zdenek Dohnal]] * Email: zdoh...@redhat.com == Detailed Description == Nowadays most printers and scanners from common vendors provide a way how to work without a specific driver. This way relies on driverless standards implemented in device's firmware and their support in the operating system user has. At first (in 2010) network driverless standards were implemented in devices and widely spread, such as AirPrint, [https://www.pwg.org/ipp/everywhere.html IPP Everywhere] for printers or eSCL (sometimes called AirScan) and WSD (Windows Service Discovery) for scanners. Those network driverless standards and others are already supported in `cups` (for printing) and `sane-airscan` packages. Two years later USB devices got their own driverless standard - [https://robots.org.uk/IPPOverUSB?action=AttachFile=view=IPP+USB+Specification.pdf IPP over USB] - which is now implemented by `ipp-usb`. The package itself has been in Fedora for more than two years available for users to opt-in USB driverless support. The `ipp-usb` package contains `ipp-usb` daemon, which works as an HTTP proxy over the claimed USB devices, provides printing (via [http://ftp.pwg.org/pub/pwg/standards/std-ipp20-20151030-5100.12.pdf IPP 2.0+] protocol), scanning (via eSCL) and fax (via [http://ftp.pwg.org/pub/pwg/candidates/cs-ippfaxout10-20140618-5100.15.pdf IPP Faxout]) support and advertises them on localhost by mDNS protocol. mDNS is the key feature for automatic discovery, but it is not required to use it - the virtual printer device provided by `ipp-usb` can be accessed at URI `ipp://localhost:6/ipp/print` and the URI can be used for permanent queue installation - [https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks/#_how_to_install_a_permanent_print_queue here] is the manual. However if mDNS is enabled, the virtual device shared by `ipp-usb` can be automatically picked up by other services (as `cups` or `sane-airscan`), so no further configuration is required to get the device installed. The feature is called ''temporary queue'' in CUPS and it is supported in applications using the up-to-date CUPS API or toolkits using up-to-date CUPS API - f.e. GTK3+ based applications, Libreoffice and Firefox. The fax functionality is available at URI `ipp://localhost:6/ipp/faxout`, but the automatic installation doesn't work for it and it has to be installed manually. As mentioned above, the `ipp-usb` daemon claims the USB interface of the device which supports IPP over USB standard. This behavior conflicts with the previous driver approach, where the discovery mechanism only scans USB ports for available devices, but doesn't try to claim the USB interface, which is unavailable because `ipp-usb` has claimed it already. The result is the device can be discovered by classic driver tools, but it won't work once user wants to print, scan or fax. In such cases user intervention is needed, where user has to make a decision whether to use driverless USB support or classic support with drivers. The way how to do it will be explained later in this proposal. Based on the current `ipp-usb` design the following specific setups aren't expected to work, because they are not common with USB device usage: * combining driverless and classic driver's support doesn't work on the same device - driverless or classic driver has to be used for whole device's functionality. * if user has several devices of the same model, all of them has to be supported by a single solution - driverless or classic driver - because quirks and SANE backends use model name, vendor ID or product ID, which are the same for all devices of the same model, for denying the support. * if scanner backend does not support disabling support for a specific device (f.e. `hpaio`, `pixma` are such backends), the whole backend can be disabled to prevent discovering broken scanners - it results in the scanner support provided by the backend will be disabled for all other devices which are in the user's environment - both network and USB. To
