Re: [Printing-architecture] RFC: Pantum M7300FDW and similar

Re: [Printing-architecture] RFC: Pantum M7300FDW and similar

[Alexander Pevzner]

Hi,

Due to my mistake our communication with Michael was not copied to the 
list, so I fix it by forwarding his reply here.

-------- Forwarded Message --------
Subject: Re: [Printing-architecture] RFC: Pantum M7300FDW and similar
Date: Wed, 13 Dec 2023 11:37:19 -0500
From: Michael Sweet <msweet@msweet.org>
To: Alexander Pevzner <pzz@apevzner.com>

Alexander,

> On Dec 13, 2023, at 10:06 AM, Alexander Pevzner <pzz@apevzner.com> wrote:
> 
> Michael,
> 
> thank you very much for your response!
> 
> On 12/10/23 18:11, Michael Sweet wrote:
>> This code has been the focus of *six* CVEs since the move to Git in 2015 - not quite one CVE a year, but enough to be concerning.  More specifically, commit 5754bccee (https://github.com/apple/cups/issues/5630) addressed the code that allowed "alternate" encodings of member attributes that was causing interoperability issues.
> 
> CVE is about security, not about interoperability. You told several times that you are concerned about security risks associated with my patch, so it sounds like some kind if security review could be useful here.

Um, did you remember the *6* CVEs in this code alone that I mentioned, 
one of which was concerned with member attributes in collections?  And 
that the various security reviews have resulted in the changes that are 
now in place?

> BTW, where do you see security risk, in the changed (relaxed) IPP "syntactical" rules by itself or in my implementation (code modifications) made to implement this change?

If *any* collection in an IPP message contains a memberAttrName tag, 
then the remainder of the message will allow for invalid encoding of 
member attributes.  That allows an attacker to bypass a validation check...

> Regarding interoperatibily, issue #5630, as I understand it, means that some clients that were able to speak with CUPS were not able to speak with real printers, because CUPS was too forgiving while printers were not.

The immediate issue was that CUPS would pass on a poorly encoded value, 
causing problems.

> First of all, I don't agree that this is about interoperatibility. This is about applicability of CUPS as strong testing/diagnostics tool. Being too forgiving, CUPS by itself still remains compatible with invalid implementations, but becomes not very useful to test these implementations for correctness (which is not primary purpose of CUPS, BTW).

Um, the primary purpose of CUPS is to provide a reliable, 
fully-functional print service.  It can't do that and accept garbage. 
Interoperability requires consistency.  Security requires consistency. 
Reliability requires consistency.  Accepting garbage does not provide 
consistency (or not the right kind, at least).

> Second, if I relax parsing of IPP responses, but not of incoming IPP requests, looks like we can achieve two goals: to be strict enough for testing of clients and to be compatible with broken hardware as well, isn't it?

And open the code up to all sorts of weird bugs.  Not going to happen.

> And I know that the same IPP parser is used as a part of IPP self-certifications tools. If I will implement "relaxed IPP parsing" as an option, disabled by default, and will only enable it where CUPS interprets responses from printers, it will not change CUPS behavior as server and will not change IPP tools behavior, at this case will it look good enough for you?

No.  Still adding a special case to code that needs to work as perfectly 
and consistently as possible.

>>> 1. I agree, that following specification is very important, and, where possible, trying to do so.
>> IPP started in the IETF and the PWG has continued the IETF's goals for conformance terminology: any requirements are there to ensure interoperability and proper functionality.  Postel's Law doesn't apply when it breaks interoperability and potentially has bad side effects.  See the following for some applicable reading/links:
> 
> I agree that interoperability should not be broken, but I don't see how my (updated) proposal, explained above, can break interoperability with anything.
> 
> Please, correct me, if I wrong.

*You* haven't explained how, if we accept broken data from a printer, we 
will be able to successfully communicate with that broken printer and 
get the correctly output.

>> They already won't be able to print from iOS or macOS, and probably not from Windows (IPP class driver) or Android (Mopria print provider) because the Get-Printer-Attributes response cannot be parsed.  And if they actually ask someone about the problem they can be pointed to Pantum to get a firmware update.
> 
> Interesting that this device included into the Apple's list of supported AirPrint devices: https://support.apple.com/en-us/HT201311

I'm not sure *when* it was certified (I can ask) but assuming the bug 
still exists in current firmware then it would fail certification on the 
first test.

> ...
> Device has offline/online upgrade options. For offline upgdade, I was not able to find firmware image for this model (and other member of this discussion writes the same). Online upgrade claims that the newest version of firmware already installed.

OK, so that is at least tells us we need to notify PANTUM of the bug...

>> You need to notify PANTUM that they have an issue.  Regardless of whether you believe that a user will update the firmware, they don't even have an opportunity unless you report the issue to the manufacturer.  And in fact, you don't even know whether PANTUM has already fixed the issue!?!
> 
> I'm doing my best to reach them, but didn't succeed so far. If and when I'll get any feedback, I'll notify you (I mean all readers of this discussion).

Thank you.

>> Let's say we accept invalid collection attribute values.  We get the media-col-database and media-col-ready values from the printer, and then send it a media-col collection to specify printing from tray 2 on cardstock: will the printer be able to understand a correctly encoded collection value for media-col if it doesn't return valid collection values for media-col-database/ready?  (probably not)
> 
> I wrote the test. Printer correctly mirrors media-col parameters in the Print-Job response (and my test encodes requests correctly) but I don't see any change of the printed image when I play with these parameters.

Which probably means the printer is ignoring the media-col values you 
are sending - "media-col" and any other Job Template attributes are only 
returned if rejected.  Can you send me a tcpdump/Wireshark of a print 
request to this printer?

>> Did you fix the problem for the user?  Is this better?
> 
> In general yes, because actually all printer functionality is available for user.
> 
> Regarding tray selection, printer chooses paper from the manual tray if it is not empty or from the automatic tray otherwise, and I'm not sure if it can be changed programmatically. In any case, it is reasonable behavior.

No, actually not.  I want to print an envelope, so I print it with the 
manual feed tray selected and the corresponding envelope size.  If the 
printer works correctly, it should pause until the envelope is inserted. 
  If the printer ignores media-col (likely based on your info above) 
then it will print the envelope on the paper in the tray...  Not so 
reasonable or functional...

>>> I'd prefer to make it even more precious, affection only communication with Pantum devices. But in that places of the CUPS code where responses are parsed there is no information what kind devices we are speaking with.
>> And I would be even more opposed to such a change.  At that point you have created a printer driver...
> 
> Printer driver may be a way to ho, though at this case it is 1000x bigger effort.
> 
> But at this case we need to provide a mechanism to disable auto-discovered printer in a favor of device instance, found and handled by the driver.
> 
> And another thing, we loose IPP over USB functionality (or ipp-usb must mimic their printer in enough details to fool the driver that it speaks with actual hardware printer).

The IPP-USB daemon only needs to understand HTTP.

________________________
Michael Sweet

Re: [Printing-architecture] RFC: Pantum M7300FDW and similar

[Till Kamppeter]

On 13/12/2023 19:57, Alexander Pevzner wrote:
>>> They already won't be able to print from iOS or macOS, and probably 
>>> not from Windows (IPP class driver) or Android (Mopria print 
>>> provider) because the Get-Printer-Attributes response cannot be 
>>> parsed.  And if they actually ask someone about the problem they can 
>>> be pointed to Pantum to get a firmware update.
>>
>> Interesting that this device included into the Apple's list of 
>> supported AirPrint devices: https://support.apple.com/en-us/HT201311
> 
> I'm not sure *when* it was certified (I can ask) but assuming the bug 
> still exists in current firmware then it would fail certification on the 
> first test.
>

Alex, Could you install and run the self-certification software from the 
PWG (should be available as source code) to check whether this printer 
is still passing certification?

    Till

Re: [Printing-architecture] RFC: Pantum M7300FDW and similar

[Alexander Pevzner]

On 12/13/23 23:37, Till Kamppeter wrote:

> Alex, Could you install and run the self-certification software from the 
> PWG (should be available as source code) to check whether this printer 
> is still passing certification?

I did. With the current version of this software, the printer doesn't 
pass certification, because IPP parser rejects Get-Printer-Attributes 
response.

BTW, my Kyocera also doesn't pass certification (for some different 
reason), but still prints (and claims to be Mopria/AirPrint-certified).

-- 

	Wishes, Alexander Pevzner (pzz@apevzner.com)

Re: [Printing-architecture] RFC: Pantum M7300FDW and similar

[Zdenek Dohnal]

Hi all,

I'm sorry for reviving this thread now - I haven't answered in the past 
because I agree here with Mike - if the scope/change/workaround opens 
the program for more CVEs, and this part of code was subject for CVEs in 
the past, I would be extra careful, didn't add a such workaround and 
pursue the fix at manufacturer, if I have the printer.

I just wanted to mention that since we started to discuss AirPrint as 
well, our office Canon printers experience probably the similar issue - 
a different type of attribute value is encoded under attribute keyword, 
which expected a different type (I don't recall the exact attribute 
name, but the attribute expected values as 1set of keyword, but values 
were in collection...), which breaks driverless support for them. I 
don't have full access to them - our IT does. I have tried to report 
this to them, but they prefer using Uniflow solution from Canon (so IPP 
port gets disabled) and our previous communication with Canon support 
was difficult, so I was not able ensure the firmware fix for them. And 
IIRC IPP Get-Printer-Attribute response was parsed before, so there 
might be a change in firmware, or the model was affected by the CVE fix.

My key point is there seem to be several models from different 
manufacturers, which were affected by a CVE fix in this part of code, 
which are certified as AirPrint in shops, but cannot send a valid IPP 
response in the end - manufacturers probably do the certification only 
once when the product is released and then do not do re-evaluation. So 
we will have to report such printers to manufacturers where is possible 
to get them fixed.

Regarding workaround in goipp and ipp-usb, I will revert the workaround 
for now.


Zdenek

On 12/10/23 16:11, Michael Sweet via Printing-architecture wrote:
> Alexander,
>
>> On Dec 10, 2023, at 2:08 AM, Alexander Pevzner <pzz@apevzner.com> wrote:
>> ...
>> Michael's position, as I hear it, is following:
>> - device violates IPP specs, so problems is on device, and device must be fixed
>> - IPP parser is a quite complex stuff. Touching it is dangerous and may open a way to security vulnerabilities
> This code has been the focus of *six* CVEs since the move to Git in 2015 - not quite one CVE a year, but enough to be concerning.  More specifically, commit 5754bccee (https://github.com/apple/cups/issues/5630) addressed the code that allowed "alternate" encodings of member attributes that was causing interoperability issues.
>
>> ...
>> My position is following:
>> 1. I agree, that following specification is very important, and, where possible, trying to do so.
> IPP started in the IETF and the PWG has continued the IETF's goals for conformance terminology: any requirements are there to ensure interoperability and proper functionality.  Postel's Law doesn't apply when it breaks interoperability and potentially has bad side effects.  See the following for some applicable reading/links:
>
>      https://en.wikipedia.org/wiki/Robustness_principle
>
>> 2. But being practical engineers, we know that sometimes we have to carefully violate rules. cups/ipp.c already has an exception for Brother devices that use some IPP tags incorrectly.
> This was a case where allowing a non-zero length value (typically the keyword string for the given out-of-band tag) did not cause interoperability issues with other printers and also did not pose any security issues.
>
> Looking at the history of this change (and had to dig into the original SVN repository for this - r7847 on August 19, 2008), back in 2007/2008 when Brother first started making IPP-capable printers (and this was before AirPrint or IPP Everywhere), their implementation had a bug that returned the string "no-value" with the 'no-value' out-of-band syntax (which should have a value length of 0).  Brother was notified and current printers no longer do this...
>
>> sane-airscan, ipp-usb contains many quirks that make incorrectly behaving devices full-functional. Without these quirks, many devices will not work.
>> 3. Even if Pantum will fix their firmware, 50% of users of already purchased devices will not upgrade.
> They already won't be able to print from iOS or macOS, and probably not from Windows (IPP class driver) or Android (Mopria print provider) because the Get-Printer-Attributes response cannot be parsed.  And if they actually ask someone about the problem they can be pointed to Pantum to get a firmware update.
>
> Firmware update capability is required for both AirPrint and Mopria, and at least the AirPrint folks require the ability to upgrade without special software and highly recommend automatic firmware updates over the Internet whenever possible...  Pantum is an AirPrint licensee...
>
>> 4. I understand the complexity of IPP decoder, because I'm the author of alternative, independent implementation in Go (https://github.com/OpenPrinting/goipp). I believe my implementation is similar to CUPS's on its level of correctness and strictness. And has near 100% test coverage, BTW.
> As does the CUPS implementation, which Google and others have put through the wringer with long-term fuzzing projects...
>
>> 5. My patch is simple and observable. It is only few lines of code (see https://github.com/OpenPrinting/cups/pull/826 for details). It doesn't change any assumptions of the upper-level code about the parsed IPP message. It only slightly relaxes decoding rules. Honestly, I don't see how it can expose any vulnerability.
> It was causing problems before I fixed it, mainly because the returned values made no sense - basically
>
>> 6. My patch is not "just a quick hack". I understand that this is very important part of the CUPS code, so I've spent more that 2 weeks, thinking about it correctness and modelling various corner cases, using my goipp library.
> I don't think I ever called it a quick hack.  No matter how well-tested/reasoned, you are creating an edge-case for allowing invalid collection values as long as a single memberName value is seen in an IPP message.
>
> You need to notify PANTUM that they have an issue.  Regardless of whether you believe that a user will update the firmware, they don't even have an opportunity unless you report the issue to the manufacturer.  And in fact, you don't even know whether PANTUM has already fixed the issue!?!
>
>> 7. We are doing our work for people, for our end users. And actual tradeoff here is between user's needs to have reliable and secure software (technical "purism" helps as here) and user's needs to have their device supported out of box (here "purism" sometimes works against us).
> So we should provide them with intentionally defective software so that they don't need to press a button on their printer to update the firmware?  How far down the slippery slope of "we'll just add a workaround for this printer" do you want to go?
>
> I can speak from 30 years of experience doing printing software - that is not a path you want to go down.  The number of variables in printing configurations is *immense*, and you do not want to bring back vendor printer drivers - that is the end game if you allow for too many "workarounds".
>
>> 8. If we will eventually rich the Pantum representative, good discussion with weighted arguments can help to convince them to implement some improvements at their side, while aborted discussion will not help a lot.
> "Your printers don't work with iOS" should be enough.  They probably won't care about Linux.
>
>> If my patch looks "too wide", I can do it more precious, by affecting only behavior of parsing IPP responses received from devices, not received requests. At this case it looks even safer.
> Let's say we accept invalid collection attribute values.  We get the media-col-database and media-col-ready values from the printer, and then send it a media-col collection to specify printing from tray 2 on cardstock: will the printer be able to understand a correctly encoded collection value for media-col if it doesn't return valid collection values for media-col-database/ready?  (probably not)
>
> Then you get a support request from a user saying, "I can't print from tray 2."
>
> Did you fix the problem for the user?  Is this better?
>
>> I'd prefer to make it even more precious, affection only communication with Pantum devices. But in that places of the CUPS code where responses are parsed there is no information what kind devices we are speaking with.
> And I would be even more opposed to such a change.  At that point you have created a printer driver...
>
>> ...
>> P.S. I remember a while ago we were in the similar discussion with Trent Lloyd, author of Avahi. He didn't want to include localhost support because it violates (according to him) mDNS RFC, and it took about 3 years to convince him to make an exception (according to Till, it was me who has reached out to him, https://openprinting.github.io/OpenPrinting-News-February-2020/#avahi-local-service-support)
> Not at all the same issue, and honestly he was wrong that you can't support multicast over the loopback interface (there is just nobody else to talk to, so multicast becomes broadcast to the local host...)
>
> ________________________
> Michael Sweet
>
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture

-- 
Zdenek Dohnal
Senior Software Engineer
Red Hat, BRQ-TPBC

Re: [Printing-architecture] RFC: Pantum M7300FDW and similar

[Douglas Kosovic]

Hi,

Just a few more comments to add about the Mopria-based IPP class driver, you can manually add an IPP 2.0 or later printer from the command-line with either of the following.

From an administrator PowerShell command line, run something similar to the following PowerShell comandlet :

    Add-Printer -IppURL ipp://xxx.xxx.xxx.xxx/ipp/print


Alternatively you can do the following on a regular command prompt or from PowerShell (and you don't even need admin privileges to add a driverless printer):

    rundll32 printui.dll,PrintUIEntry /ip

then click Next and enter the IPP URL...


Comes in handy if the printer can't be discovered with mDNS (Bonjoiur).



Cheers,
Doug
-----Original Message-----
From: Printing-architecture <printing-architecture-bounces@lists.linux-foundation.org> On Behalf Of Michael Sweet via Printing-architecture
Sent: Thursday, December 14, 2023 8:40 AM
To: Alexander Pevzner <pzz@apevzner.com>
Cc: printing-architecture@lists.linux-foundation.org; Till Kamppeter <till.kamppeter@gmail.com>
Subject: Re: [Printing-architecture] RFC: Pantum M7300FDW and similar

Alex,

Windows 10 is the first version of Windows with the (Mopria-based) IPP class driver.  Earlier versions of Windows only supported the experimental IPP/1.0 (!) and relied on drivers to send data to IPP printers...


> On Dec 13, 2023, at 4:22 PM, Alexander Pevzner <pzz@apevzner.com> wrote:
> 
> Till, I will try.
> 
> I already tried with Windows 7 that I have running in VM and didn't succeed (it wants to install Pantum drivers).
> 
> I'll try to install Windows 10 or 11 into VM and will see how it will work. However, it will take some time.
> 
> I'll return with results when results will be available.
> 
> On 12/13/23 20:31, Till Kamppeter wrote:
>> Alex, I will perhaps reply in more detail later, but I would like you to test something:
>> You say that Windows always wants you to install a driver.
>> Windows principally supports driverless printing. Have a look at 
>> https://openprinting.github.io/wsl-printer-app/
>> This is a HOWTO to eun a Printer Application (= emulation of driverless printer) under WSL and Windows sees this as a driverless printer.
>> So now click "Cancel" in any pop-up of Windows telling you to install a printer driver.
>> Now go to the HOWTO and only see the steps to set up a driverless printer (you will not need WSL nor a Printer Application).
>> So you start in the section which starts with "Add the printer to Windows".
>> Look in the "Bluetooth & devices > Printers & scanners" whether there is an entry which could represent your printer. Select it, finish the setup and test.
>> Is your printer working at all?
>> Is it completely working?
>> Does it show the same problems as under Linux?
>> If it works under Windows we will need to reverse-engineer what Windows is doing and compare it to what CUPS is doing.
>>    Till
>> On 13/12/2023 16:08, Alexander Pevzner wrote:
>>> Michael,
>>> 
>>> thank you very much for your response!
>>> 
>>> On 12/10/23 18:11, Michael Sweet wrote:
>>>> This code has been the focus of *six* CVEs since the move to Git in 2015 - not quite one CVE a year, but enough to be concerning.  More specifically, commit 5754bccee (https://github.com/apple/cups/issues/5630) addressed the code that allowed "alternate" encodings of member attributes that was causing interoperability issues.
>>> 
>>> CVE is about security, not about interoperability. You told several times that you are concerned about security risks associated with my patch, so it sounds like some kind if security review could be useful here.
>>> 
>>> BTW, where do you see security risk, in the changed (relaxed) IPP "syntactical" rules by itself or in my implementation (code modifications) made to implement this change?
>>> 
>>> Regarding interoperatibily, issue #5630, as I understand it, means that some clients that were able to speak with CUPS were not able to speak with real printers, because CUPS was too forgiving while printers were not.
>>> 
>>> First of all, I don't agree that this is about interoperatibility. This is about applicability of CUPS as strong testing/diagnostics tool. Being too forgiving, CUPS by itself still remains compatible with invalid implementations, but becomes not very useful to test these implementations for correctness (which is not primary purpose of CUPS, BTW).
>>> 
>>> Second, if I relax parsing of IPP responses, but not of incoming IPP requests, looks like we can achieve two goals: to be strict enough for testing of clients and to be compatible with broken hardware as well, isn't it?
>>> 
>>> And I know that the same IPP parser is used as a part of IPP self-certifications tools. If I will implement "relaxed IPP parsing" as an option, disabled by default, and will only enable it where CUPS interprets responses from printers, it will not change CUPS behavior as server and will not change IPP tools behavior, at this case will it look good enough for you?
>>> 
>>>>> 1. I agree, that following specification is very important, and, where possible, trying to do so.
>>>> 
>>>> IPP started in the IETF and the PWG has continued the IETF's goals for conformance terminology: any requirements are there to ensure interoperability and proper functionality.  Postel's Law doesn't apply when it breaks interoperability and potentially has bad side effects. See the following for some applicable reading/links:
>>> 
>>> I agree that interoperability should not be broken, but I don't see how my (updated) proposal, explained above, can break interoperability with anything.
>>> 
>>> Please, correct me, if I wrong.
>>> 
>>>> They already won't be able to print from iOS or macOS, and probably not from Windows (IPP class driver) or Android (Mopria print provider) because the Get-Printer-Attributes response cannot be parsed.  And if they actually ask someone about the problem they can be pointed to Pantum to get a firmware update.
>>> 
>>> Interesting that this device included into the Apple's list of 
>>> supported AirPrint devices: https://support.apple.com/en-us/HT201311
>>> 
>>> Unfortunately, I don't have any iOS/macOS device to test by myself. Regarding Windows, Windows wants to install vendor driver (which is known to work) and I don't know is it any way to force Windows to print "driverlessly".
>>> 
>>>> Firmware update capability is required for both AirPrint and Mopria, and at least the AirPrint folks require the ability to upgrade without special software and highly recommend automatic firmware updates over the Internet whenever possible...  Pantum is an AirPrint licensee...
>>> 
>>> Device has offline/online upgrade options. For offline upgdade, I was not able to find firmware image for this model (and other member of this discussion writes the same). Online upgrade claims that the newest version of firmware already installed.
>>> 
>>>> You need to notify PANTUM that they have an issue.  Regardless of whether you believe that a user will update the firmware, they don't even have an opportunity unless you report the issue to the manufacturer.  And in fact, you don't even know whether PANTUM has already fixed the issue!?!
>>> 
>>> I'm doing my best to reach them, but didn't succeed so far. If and when I'll get any feedback, I'll notify you (I mean all readers of this discussion).
>>> 
>>>> Let's say we accept invalid collection attribute values.  We get 
>>>> the media-col-database and media-col-ready values from the printer, 
>>>> and then send it a media-col collection to specify printing from 
>>>> tray 2 on cardstock: will the printer be able to understand a 
>>>> correctly encoded collection value for media-col if it doesn't 
>>>> return valid collection values for media-col-database/ready?  
>>>> (probably not)
>>> 
>>> I wrote the test. Printer correctly mirrors media-col parameters in the Print-Job response (and my test encodes requests correctly) but I don't see any change of the printed image when I play with these parameters.
>>> 
>>>> Did you fix the problem for the user?  Is this better?
>>> 
>>> In general yes, because actually all printer functionality is available for user.
>>> 
>>> Regarding tray selection, printer chooses paper from the manual tray if it is not empty or from the automatic tray otherwise, and I'm not sure if it can be changed programmatically. In any case, it is reasonable behavior.
>>> 
>>>>> I'd prefer to make it even more precious, affection only communication with Pantum devices. But in that places of the CUPS code where responses are parsed there is no information what kind devices we are speaking with.
>>>> 
>>>> And I would be even more opposed to such a change.  At that point you have created a printer driver...
>>> 
>>> Printer driver may be a way to ho, though at this case it is 1000x bigger effort.
>>> 
>>> But at this case we need to provide a mechanism to disable auto-discovered printer in a favor of device instance, found and handled by the driver.
>>> 
>>> And another thing, we loose IPP over USB functionality (or ipp-usb must mimic their printer in enough details to fool the driver that it speaks with actual hardware printer).
>>> 
> 
> --
> 
> Wishes, Alexander Pevzner (pzz@apevzner.com)
> 

________________________
Michael Sweet

_______________________________________________
Printing-architecture mailing list
Printing-architecture@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture

Re: [Printing-architecture] RFC: Pantum M7300FDW and similar

[Michael Sweet]

Alex,

Windows 10 is the first version of Windows with the (Mopria-based) IPP class driver.  Earlier versions of Windows only supported the experimental IPP/1.0 (!) and relied on drivers to send data to IPP printers...


> On Dec 13, 2023, at 4:22 PM, Alexander Pevzner <pzz@apevzner.com> wrote:
> 
> Till, I will try.
> 
> I already tried with Windows 7 that I have running in VM and didn't succeed (it wants to install Pantum drivers).
> 
> I'll try to install Windows 10 or 11 into VM and will see how it will work. However, it will take some time.
> 
> I'll return with results when results will be available.
> 
> On 12/13/23 20:31, Till Kamppeter wrote:
>> Alex, I will perhaps reply in more detail later, but I would like you to test something:
>> You say that Windows always wants you to install a driver.
>> Windows principally supports driverless printing. Have a look at
>> https://openprinting.github.io/wsl-printer-app/
>> This is a HOWTO to eun a Printer Application (= emulation of driverless printer) under WSL and Windows sees this as a driverless printer.
>> So now click "Cancel" in any pop-up of Windows telling you to install a printer driver.
>> Now go to the HOWTO and only see the steps to set up a driverless printer (you will not need WSL nor a Printer Application).
>> So you start in the section which starts with "Add the printer to Windows".
>> Look in the "Bluetooth & devices > Printers & scanners" whether there is an entry which could represent your printer. Select it, finish the setup and test.
>> Is your printer working at all?
>> Is it completely working?
>> Does it show the same problems as under Linux?
>> If it works under Windows we will need to reverse-engineer what Windows is doing and compare it to what CUPS is doing.
>>    Till
>> On 13/12/2023 16:08, Alexander Pevzner wrote:
>>> Michael,
>>> 
>>> thank you very much for your response!
>>> 
>>> On 12/10/23 18:11, Michael Sweet wrote:
>>>> This code has been the focus of *six* CVEs since the move to Git in 2015 - not quite one CVE a year, but enough to be concerning.  More specifically, commit 5754bccee (https://github.com/apple/cups/issues/5630) addressed the code that allowed "alternate" encodings of member attributes that was causing interoperability issues.
>>> 
>>> CVE is about security, not about interoperability. You told several times that you are concerned about security risks associated with my patch, so it sounds like some kind if security review could be useful here.
>>> 
>>> BTW, where do you see security risk, in the changed (relaxed) IPP "syntactical" rules by itself or in my implementation (code modifications) made to implement this change?
>>> 
>>> Regarding interoperatibily, issue #5630, as I understand it, means that some clients that were able to speak with CUPS were not able to speak with real printers, because CUPS was too forgiving while printers were not.
>>> 
>>> First of all, I don't agree that this is about interoperatibility. This is about applicability of CUPS as strong testing/diagnostics tool. Being too forgiving, CUPS by itself still remains compatible with invalid implementations, but becomes not very useful to test these implementations for correctness (which is not primary purpose of CUPS, BTW).
>>> 
>>> Second, if I relax parsing of IPP responses, but not of incoming IPP requests, looks like we can achieve two goals: to be strict enough for testing of clients and to be compatible with broken hardware as well, isn't it?
>>> 
>>> And I know that the same IPP parser is used as a part of IPP self-certifications tools. If I will implement "relaxed IPP parsing" as an option, disabled by default, and will only enable it where CUPS interprets responses from printers, it will not change CUPS behavior as server and will not change IPP tools behavior, at this case will it look good enough for you?
>>> 
>>>>> 1. I agree, that following specification is very important, and, where possible, trying to do so.
>>>> 
>>>> IPP started in the IETF and the PWG has continued the IETF's goals for conformance terminology: any requirements are there to ensure interoperability and proper functionality.  Postel's Law doesn't apply when it breaks interoperability and potentially has bad side effects. See the following for some applicable reading/links:
>>> 
>>> I agree that interoperability should not be broken, but I don't see how my (updated) proposal, explained above, can break interoperability with anything.
>>> 
>>> Please, correct me, if I wrong.
>>> 
>>>> They already won't be able to print from iOS or macOS, and probably not from Windows (IPP class driver) or Android (Mopria print provider) because the Get-Printer-Attributes response cannot be parsed.  And if they actually ask someone about the problem they can be pointed to Pantum to get a firmware update.
>>> 
>>> Interesting that this device included into the Apple's list of supported AirPrint devices: https://support.apple.com/en-us/HT201311
>>> 
>>> Unfortunately, I don't have any iOS/macOS device to test by myself. Regarding Windows, Windows wants to install vendor driver (which is known to work) and I don't know is it any way to force Windows to print "driverlessly".
>>> 
>>>> Firmware update capability is required for both AirPrint and Mopria, and at least the AirPrint folks require the ability to upgrade without special software and highly recommend automatic firmware updates over the Internet whenever possible...  Pantum is an AirPrint licensee...
>>> 
>>> Device has offline/online upgrade options. For offline upgdade, I was not able to find firmware image for this model (and other member of this discussion writes the same). Online upgrade claims that the newest version of firmware already installed.
>>> 
>>>> You need to notify PANTUM that they have an issue.  Regardless of whether you believe that a user will update the firmware, they don't even have an opportunity unless you report the issue to the manufacturer.  And in fact, you don't even know whether PANTUM has already fixed the issue!?!
>>> 
>>> I'm doing my best to reach them, but didn't succeed so far. If and when I'll get any feedback, I'll notify you (I mean all readers of this discussion).
>>> 
>>>> Let's say we accept invalid collection attribute values.  We get the media-col-database and media-col-ready values from the printer, and then send it a media-col collection to specify printing from tray 2 on cardstock: will the printer be able to understand a correctly encoded collection value for media-col if it doesn't return valid collection values for media-col-database/ready?  (probably not)
>>> 
>>> I wrote the test. Printer correctly mirrors media-col parameters in the Print-Job response (and my test encodes requests correctly) but I don't see any change of the printed image when I play with these parameters.
>>> 
>>>> Did you fix the problem for the user?  Is this better?
>>> 
>>> In general yes, because actually all printer functionality is available for user.
>>> 
>>> Regarding tray selection, printer chooses paper from the manual tray if it is not empty or from the automatic tray otherwise, and I'm not sure if it can be changed programmatically. In any case, it is reasonable behavior.
>>> 
>>>>> I'd prefer to make it even more precious, affection only communication with Pantum devices. But in that places of the CUPS code where responses are parsed there is no information what kind devices we are speaking with.
>>>> 
>>>> And I would be even more opposed to such a change.  At that point you have created a printer driver...
>>> 
>>> Printer driver may be a way to ho, though at this case it is 1000x bigger effort.
>>> 
>>> But at this case we need to provide a mechanism to disable auto-discovered printer in a favor of device instance, found and handled by the driver.
>>> 
>>> And another thing, we loose IPP over USB functionality (or ipp-usb must mimic their printer in enough details to fool the driver that it speaks with actual hardware printer).
>>> 
> 
> -- 
> 
> Wishes, Alexander Pevzner (pzz@apevzner.com)
> 

________________________
Michael Sweet

Re: [Printing-architecture] RFC: Pantum M7300FDW and similar

[Alexander Pevzner]

Till, I will try.

I already tried with Windows 7 that I have running in VM and didn't 
succeed (it wants to install Pantum drivers).

I'll try to install Windows 10 or 11 into VM and will see how it will 
work. However, it will take some time.

I'll return with results when results will be available.

On 12/13/23 20:31, Till Kamppeter wrote:
> Alex, I will perhaps reply in more detail later, but I would like you to 
> test something:
> 
> You say that Windows always wants you to install a driver.
> 
> Windows principally supports driverless printing. Have a look at
> 
> https://openprinting.github.io/wsl-printer-app/
> 
> This is a HOWTO to eun a Printer Application (= emulation of driverless 
> printer) under WSL and Windows sees this as a driverless printer.
> 
> So now click "Cancel" in any pop-up of Windows telling you to install a 
> printer driver.
> 
> Now go to the HOWTO and only see the steps to set up a driverless 
> printer (you will not need WSL nor a Printer Application).
> 
> So you start in the section which starts with "Add the printer to Windows".
> 
> Look in the "Bluetooth & devices > Printers & scanners" whether there is 
> an entry which could represent your printer. Select it, finish the setup 
> and test.
> 
> Is your printer working at all?
> 
> Is it completely working?
> 
> Does it show the same problems as under Linux?
> 
> If it works under Windows we will need to reverse-engineer what Windows 
> is doing and compare it to what CUPS is doing.
> 
>     Till
> 
> 
> On 13/12/2023 16:08, Alexander Pevzner wrote:
>> Michael,
>>
>> thank you very much for your response!
>>
>> On 12/10/23 18:11, Michael Sweet wrote:
>>> This code has been the focus of *six* CVEs since the move to Git in 
>>> 2015 - not quite one CVE a year, but enough to be concerning.  More 
>>> specifically, commit 5754bccee 
>>> (https://github.com/apple/cups/issues/5630) addressed the code that 
>>> allowed "alternate" encodings of member attributes that was causing 
>>> interoperability issues.
>>
>> CVE is about security, not about interoperability. You told several 
>> times that you are concerned about security risks associated with my 
>> patch, so it sounds like some kind if security review could be useful 
>> here.
>>
>> BTW, where do you see security risk, in the changed (relaxed) IPP 
>> "syntactical" rules by itself or in my implementation (code 
>> modifications) made to implement this change?
>>
>> Regarding interoperatibily, issue #5630, as I understand it, means 
>> that some clients that were able to speak with CUPS were not able to 
>> speak with real printers, because CUPS was too forgiving while 
>> printers were not.
>>
>> First of all, I don't agree that this is about interoperatibility. 
>> This is about applicability of CUPS as strong testing/diagnostics 
>> tool. Being too forgiving, CUPS by itself still remains compatible 
>> with invalid implementations, but becomes not very useful to test 
>> these implementations for correctness (which is not primary purpose of 
>> CUPS, BTW).
>>
>> Second, if I relax parsing of IPP responses, but not of incoming IPP 
>> requests, looks like we can achieve two goals: to be strict enough for 
>> testing of clients and to be compatible with broken hardware as well, 
>> isn't it?
>>
>> And I know that the same IPP parser is used as a part of IPP 
>> self-certifications tools. If I will implement "relaxed IPP parsing" 
>> as an option, disabled by default, and will only enable it where CUPS 
>> interprets responses from printers, it will not change CUPS behavior 
>> as server and will not change IPP tools behavior, at this case will it 
>> look good enough for you?
>>
>>>> 1. I agree, that following specification is very important, and, 
>>>> where possible, trying to do so.
>>>
>>> IPP started in the IETF and the PWG has continued the IETF's goals 
>>> for conformance terminology: any requirements are there to ensure 
>>> interoperability and proper functionality.  Postel's Law doesn't 
>>> apply when it breaks interoperability and potentially has bad side 
>>> effects. See the following for some applicable reading/links:
>>
>> I agree that interoperability should not be broken, but I don't see 
>> how my (updated) proposal, explained above, can break interoperability 
>> with anything.
>>
>> Please, correct me, if I wrong.
>>
>>> They already won't be able to print from iOS or macOS, and probably 
>>> not from Windows (IPP class driver) or Android (Mopria print 
>>> provider) because the Get-Printer-Attributes response cannot be 
>>> parsed.  And if they actually ask someone about the problem they can 
>>> be pointed to Pantum to get a firmware update.
>>
>> Interesting that this device included into the Apple's list of 
>> supported AirPrint devices: https://support.apple.com/en-us/HT201311
>>
>> Unfortunately, I don't have any iOS/macOS device to test by myself. 
>> Regarding Windows, Windows wants to install vendor driver (which is 
>> known to work) and I don't know is it any way to force Windows to 
>> print "driverlessly".
>>
>>> Firmware update capability is required for both AirPrint and Mopria, 
>>> and at least the AirPrint folks require the ability to upgrade 
>>> without special software and highly recommend automatic firmware 
>>> updates over the Internet whenever possible...  Pantum is an AirPrint 
>>> licensee...
>>
>> Device has offline/online upgrade options. For offline upgdade, I was 
>> not able to find firmware image for this model (and other member of 
>> this discussion writes the same). Online upgrade claims that the 
>> newest version of firmware already installed.
>>
>>> You need to notify PANTUM that they have an issue.  Regardless of 
>>> whether you believe that a user will update the firmware, they don't 
>>> even have an opportunity unless you report the issue to the 
>>> manufacturer.  And in fact, you don't even know whether PANTUM has 
>>> already fixed the issue!?!
>>
>> I'm doing my best to reach them, but didn't succeed so far. If and 
>> when I'll get any feedback, I'll notify you (I mean all readers of 
>> this discussion).
>>
>>> Let's say we accept invalid collection attribute values.  We get the 
>>> media-col-database and media-col-ready values from the printer, and 
>>> then send it a media-col collection to specify printing from tray 2 
>>> on cardstock: will the printer be able to understand a correctly 
>>> encoded collection value for media-col if it doesn't return valid 
>>> collection values for media-col-database/ready?  (probably not)
>>
>> I wrote the test. Printer correctly mirrors media-col parameters in 
>> the Print-Job response (and my test encodes requests correctly) but I 
>> don't see any change of the printed image when I play with these 
>> parameters.
>>
>>> Did you fix the problem for the user?  Is this better?
>>
>> In general yes, because actually all printer functionality is 
>> available for user.
>>
>> Regarding tray selection, printer chooses paper from the manual tray 
>> if it is not empty or from the automatic tray otherwise, and I'm not 
>> sure if it can be changed programmatically. In any case, it is 
>> reasonable behavior.
>>
>>>> I'd prefer to make it even more precious, affection only 
>>>> communication with Pantum devices. But in that places of the CUPS 
>>>> code where responses are parsed there is no information what kind 
>>>> devices we are speaking with.
>>>
>>> And I would be even more opposed to such a change.  At that point you 
>>> have created a printer driver...
>>
>> Printer driver may be a way to ho, though at this case it is 1000x 
>> bigger effort.
>>
>> But at this case we need to provide a mechanism to disable 
>> auto-discovered printer in a favor of device instance, found and 
>> handled by the driver.
>>
>> And another thing, we loose IPP over USB functionality (or ipp-usb 
>> must mimic their printer in enough details to fool the driver that it 
>> speaks with actual hardware printer).
>>

-- 

	Wishes, Alexander Pevzner (pzz@apevzner.com)

Re: [Printing-architecture] RFC: Pantum M7300FDW and similar

[Till Kamppeter]

Alex, I will perhaps reply in more detail later, but I would like you to 
test something:

You say that Windows always wants you to install a driver.

Windows principally supports driverless printing. Have a look at

https://openprinting.github.io/wsl-printer-app/

This is a HOWTO to eun a Printer Application (= emulation of driverless 
printer) under WSL and Windows sees this as a driverless printer.

So now click "Cancel" in any pop-up of Windows telling you to install a 
printer driver.

Now go to the HOWTO and only see the steps to set up a driverless 
printer (you will not need WSL nor a Printer Application).

So you start in the section which starts with "Add the printer to Windows".

Look in the "Bluetooth & devices > Printers & scanners" whether there is 
an entry which could represent your printer. Select it, finish the setup 
and test.

Is your printer working at all?

Is it completely working?

Does it show the same problems as under Linux?

If it works under Windows we will need to reverse-engineer what Windows 
is doing and compare it to what CUPS is doing.

    Till


On 13/12/2023 16:08, Alexander Pevzner wrote:
> Michael,
> 
> thank you very much for your response!
> 
> On 12/10/23 18:11, Michael Sweet wrote:
>> This code has been the focus of *six* CVEs since the move to Git in 
>> 2015 - not quite one CVE a year, but enough to be concerning.  More 
>> specifically, commit 5754bccee 
>> (https://github.com/apple/cups/issues/5630) addressed the code that 
>> allowed "alternate" encodings of member attributes that was causing 
>> interoperability issues.
> 
> CVE is about security, not about interoperability. You told several 
> times that you are concerned about security risks associated with my 
> patch, so it sounds like some kind if security review could be useful here.
> 
> BTW, where do you see security risk, in the changed (relaxed) IPP 
> "syntactical" rules by itself or in my implementation (code 
> modifications) made to implement this change?
> 
> Regarding interoperatibily, issue #5630, as I understand it, means that 
> some clients that were able to speak with CUPS were not able to speak 
> with real printers, because CUPS was too forgiving while printers were not.
> 
> First of all, I don't agree that this is about interoperatibility. This 
> is about applicability of CUPS as strong testing/diagnostics tool. Being 
> too forgiving, CUPS by itself still remains compatible with invalid 
> implementations, but becomes not very useful to test these 
> implementations for correctness (which is not primary purpose of CUPS, 
> BTW).
> 
> Second, if I relax parsing of IPP responses, but not of incoming IPP 
> requests, looks like we can achieve two goals: to be strict enough for 
> testing of clients and to be compatible with broken hardware as well, 
> isn't it?
> 
> And I know that the same IPP parser is used as a part of IPP 
> self-certifications tools. If I will implement "relaxed IPP parsing" as 
> an option, disabled by default, and will only enable it where CUPS 
> interprets responses from printers, it will not change CUPS behavior as 
> server and will not change IPP tools behavior, at this case will it look 
> good enough for you?
> 
>>> 1. I agree, that following specification is very important, and, 
>>> where possible, trying to do so.
>>
>> IPP started in the IETF and the PWG has continued the IETF's goals for 
>> conformance terminology: any requirements are there to ensure 
>> interoperability and proper functionality.  Postel's Law doesn't apply 
>> when it breaks interoperability and potentially has bad side effects.  
>> See the following for some applicable reading/links:
> 
> I agree that interoperability should not be broken, but I don't see how 
> my (updated) proposal, explained above, can break interoperability with 
> anything.
> 
> Please, correct me, if I wrong.
> 
>> They already won't be able to print from iOS or macOS, and probably 
>> not from Windows (IPP class driver) or Android (Mopria print provider) 
>> because the Get-Printer-Attributes response cannot be parsed.  And if 
>> they actually ask someone about the problem they can be pointed to 
>> Pantum to get a firmware update.
> 
> Interesting that this device included into the Apple's list of supported 
> AirPrint devices: https://support.apple.com/en-us/HT201311
> 
> Unfortunately, I don't have any iOS/macOS device to test by myself. 
> Regarding Windows, Windows wants to install vendor driver (which is 
> known to work) and I don't know is it any way to force Windows to print 
> "driverlessly".
> 
>> Firmware update capability is required for both AirPrint and Mopria, 
>> and at least the AirPrint folks require the ability to upgrade without 
>> special software and highly recommend automatic firmware updates over 
>> the Internet whenever possible...  Pantum is an AirPrint licensee...
> 
> Device has offline/online upgrade options. For offline upgdade, I was 
> not able to find firmware image for this model (and other member of this 
> discussion writes the same). Online upgrade claims that the newest 
> version of firmware already installed.
> 
>> You need to notify PANTUM that they have an issue.  Regardless of 
>> whether you believe that a user will update the firmware, they don't 
>> even have an opportunity unless you report the issue to the 
>> manufacturer.  And in fact, you don't even know whether PANTUM has 
>> already fixed the issue!?!
> 
> I'm doing my best to reach them, but didn't succeed so far. If and when 
> I'll get any feedback, I'll notify you (I mean all readers of this 
> discussion).
> 
>> Let's say we accept invalid collection attribute values.  We get the 
>> media-col-database and media-col-ready values from the printer, and 
>> then send it a media-col collection to specify printing from tray 2 on 
>> cardstock: will the printer be able to understand a correctly encoded 
>> collection value for media-col if it doesn't return valid collection 
>> values for media-col-database/ready?  (probably not)
> 
> I wrote the test. Printer correctly mirrors media-col parameters in the 
> Print-Job response (and my test encodes requests correctly) but I don't 
> see any change of the printed image when I play with these parameters.
> 
>> Did you fix the problem for the user?  Is this better?
> 
> In general yes, because actually all printer functionality is available 
> for user.
> 
> Regarding tray selection, printer chooses paper from the manual tray if 
> it is not empty or from the automatic tray otherwise, and I'm not sure 
> if it can be changed programmatically. In any case, it is reasonable 
> behavior.
> 
>>> I'd prefer to make it even more precious, affection only 
>>> communication with Pantum devices. But in that places of the CUPS 
>>> code where responses are parsed there is no information what kind 
>>> devices we are speaking with.
>>
>> And I would be even more opposed to such a change.  At that point you 
>> have created a printer driver...
> 
> Printer driver may be a way to ho, though at this case it is 1000x 
> bigger effort.
> 
> But at this case we need to provide a mechanism to disable 
> auto-discovered printer in a favor of device instance, found and handled 
> by the driver.
> 
> And another thing, we loose IPP over USB functionality (or ipp-usb must 
> mimic their printer in enough details to fool the driver that it speaks 
> with actual hardware printer).
> 

Re: [Printing-architecture] RFC: Pantum M7300FDW and similar

[Alexander Pevzner]

Michael,

On 12/11/23 01:38, Michael Sweet via Printing-architecture wrote:

> First, we really don't know whether the customer has the most recent version of the firmware.  Second, we don't know whether the printer works with any of those other OS's.  Finally, this particular issue might not manifest as a "problem" (one that prevents printing) unless you tried to print something that doesn't match the media in the printer...

The printer is currently in my home lab, so I can try anything. As I 
already told, to the best of my knowledge, the printer has a latest 
firmware.

And yes, this issue is a "problem" that prevents printing - CUPS can't 
parse Get-Printer-Attributes response, so it even doesn't attempt to print.

-- 

	Wishes, Alexander Pevzner (pzz@apevzner.com)

Re: [Printing-architecture] RFC: Pantum M7300FDW and similar

[Alexander Pevzner]

Michael,

thank you very much for your response!

On 12/10/23 18:11, Michael Sweet wrote:
> This code has been the focus of *six* CVEs since the move to Git in 2015 - not quite one CVE a year, but enough to be concerning.  More specifically, commit 5754bccee (https://github.com/apple/cups/issues/5630) addressed the code that allowed "alternate" encodings of member attributes that was causing interoperability issues.

CVE is about security, not about interoperability. You told several 
times that you are concerned about security risks associated with my 
patch, so it sounds like some kind if security review could be useful here.

BTW, where do you see security risk, in the changed (relaxed) IPP 
"syntactical" rules by itself or in my implementation (code 
modifications) made to implement this change?

Regarding interoperatibily, issue #5630, as I understand it, means that 
some clients that were able to speak with CUPS were not able to speak 
with real printers, because CUPS was too forgiving while printers were not.

First of all, I don't agree that this is about interoperatibility. This 
is about applicability of CUPS as strong testing/diagnostics tool. Being 
too forgiving, CUPS by itself still remains compatible with invalid 
implementations, but becomes not very useful to test these 
implementations for correctness (which is not primary purpose of CUPS, BTW).

Second, if I relax parsing of IPP responses, but not of incoming IPP 
requests, looks like we can achieve two goals: to be strict enough for 
testing of clients and to be compatible with broken hardware as well, 
isn't it?

And I know that the same IPP parser is used as a part of IPP 
self-certifications tools. If I will implement "relaxed IPP parsing" as 
an option, disabled by default, and will only enable it where CUPS 
interprets responses from printers, it will not change CUPS behavior as 
server and will not change IPP tools behavior, at this case will it look 
good enough for you?

>> 1. I agree, that following specification is very important, and, where possible, trying to do so.
> 
> IPP started in the IETF and the PWG has continued the IETF's goals for conformance terminology: any requirements are there to ensure interoperability and proper functionality.  Postel's Law doesn't apply when it breaks interoperability and potentially has bad side effects.  See the following for some applicable reading/links:

I agree that interoperability should not be broken, but I don't see how 
my (updated) proposal, explained above, can break interoperability with 
anything.

Please, correct me, if I wrong.

> They already won't be able to print from iOS or macOS, and probably not from Windows (IPP class driver) or Android (Mopria print provider) because the Get-Printer-Attributes response cannot be parsed.  And if they actually ask someone about the problem they can be pointed to Pantum to get a firmware update.

Interesting that this device included into the Apple's list of supported 
AirPrint devices: https://support.apple.com/en-us/HT201311

Unfortunately, I don't have any iOS/macOS device to test by myself. 
Regarding Windows, Windows wants to install vendor driver (which is 
known to work) and I don't know is it any way to force Windows to print 
"driverlessly".

> Firmware update capability is required for both AirPrint and Mopria, and at least the AirPrint folks require the ability to upgrade without special software and highly recommend automatic firmware updates over the Internet whenever possible...  Pantum is an AirPrint licensee...

Device has offline/online upgrade options. For offline upgdade, I was 
not able to find firmware image for this model (and other member of this 
discussion writes the same). Online upgrade claims that the newest 
version of firmware already installed.

> You need to notify PANTUM that they have an issue.  Regardless of whether you believe that a user will update the firmware, they don't even have an opportunity unless you report the issue to the manufacturer.  And in fact, you don't even know whether PANTUM has already fixed the issue!?!

I'm doing my best to reach them, but didn't succeed so far. If and when 
I'll get any feedback, I'll notify you (I mean all readers of this 
discussion).

> Let's say we accept invalid collection attribute values.  We get the media-col-database and media-col-ready values from the printer, and then send it a media-col collection to specify printing from tray 2 on cardstock: will the printer be able to understand a correctly encoded collection value for media-col if it doesn't return valid collection values for media-col-database/ready?  (probably not)

I wrote the test. Printer correctly mirrors media-col parameters in the 
Print-Job response (and my test encodes requests correctly) but I don't 
see any change of the printed image when I play with these parameters.

> Did you fix the problem for the user?  Is this better?

In general yes, because actually all printer functionality is available 
for user.

Regarding tray selection, printer chooses paper from the manual tray if 
it is not empty or from the automatic tray otherwise, and I'm not sure 
if it can be changed programmatically. In any case, it is reasonable 
behavior.

>> I'd prefer to make it even more precious, affection only communication with Pantum devices. But in that places of the CUPS code where responses are parsed there is no information what kind devices we are speaking with.
> 
> And I would be even more opposed to such a change.  At that point you have created a printer driver...

Printer driver may be a way to ho, though at this case it is 1000x 
bigger effort.

But at this case we need to provide a mechanism to disable 
auto-discovered printer in a favor of device instance, found and handled 
by the driver.

And another thing, we loose IPP over USB functionality (or ipp-usb must 
mimic their printer in enough details to fool the driver that it speaks 
with actual hardware printer).

-- 

	Wishes, Alexander Pevzner (pzz@apevzner.com)

Re: [Printing-architecture] RFC: Pantum M7300FDW and similar

[Solomon Peachy]

[-- Attachment #1: Type: text/plain, Size: 2895 bytes --]

On Sun, Dec 10, 2023 at 05:38:04PM -0500, Michael Sweet wrote:
> What you might be running into is that AirPrint from iOS/iPadOS often 
> exercises a different part of the IPP stack than CUPS 1.x/2.x.

Heh, that reminds me of the quip "The United States and England are two 
countries sparated by a common language".

(But whatever the cause the net result is the same...)

> First, we really don't know whether the customer has the most recent 
> version of the firmware.  Second, we don't know whether the printer 
> works with any of those other OS's.  Finally, this particular issue 
> might not manifest as a "problem" (one that prevents printing) unless 
> you tried to print something that doesn't match the media in the 
> printer...

Pantum doesn't list any firmware updates for public download but that 
doesn't mean anything if the printers expect to have its own always-on 
connection to the internet.

Given that all of "those other OS's" come are provided a traditional 
native driver, and that Pantum emphasizes use of their own app for the 
mobile platforms, I think it's safe to say that yes, the printer is 
fully functional _unless_ you're using a spec-compliant driverless 
IPP-based path.

(Okay, min-rant time)

Of my printer fleet, only a handful support driverless IPP. None of 
them reliably work [1] with Linux/CUPS, iOS, or MacOS.

I have a Brother HL-L2370DW and several different Canon Selpy models.  
The latter have received firmware updates that fixed some of the IPP 
problems, but Canon still heavily pushes their own app that _doesn't_ 
use IPP. The fully-up-to-date Brother works well with Linux/CUPS 
(driverless) clients, But MacOS/iOS clients remain a crapshoot.  
Ironically, I found that [re-]exporting a traditional CUPS queue that talks 
to the printer via PCL6-over-JetDirect is the most reliable way to print 
from iOS clients. (Happy printing, happy wife. Happy wife, happy life!)

The promise/potential of driverless IPP keeps clashing with the 
experience of dealing with real-world printers/manufacturers, I find 
this both _incredibly_ frustrating and... par for the course. 

I guess if I have a point in all of this, it's that printer makers (in 
the mass market/consumer space, at least) are incentivized to 
discourage/deemphasize driverless printing, and instead funnel them into 
using a native driver or printing app, as this lets them datamine their 
users and provide opportunities to advertise/monetize/upsell/whatever. 

ANYway.  Back to my usual duct tape and bailing wire.

[1] As in "I can expect something to be waiting on the printer when I 
    get there" 

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
Dowling Park, FL                      speachy (libera.chat)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Printing-architecture] RFC: Pantum M7300FDW and similar

[Michael Sweet]

Solomon,

> On Dec 10, 2023, at 4:41 PM, Solomon Peachy via Printing-architecture <printing-architecture@lists.linux-foundation.org> wrote:
> ...
> So assuming that getting certified/listed means demonstrating that you 
> pass some sort of compliance suite, this means that the Mopria and 
> AirPrint clients don't actually care about these printers violating the 
> IPP specification.

I can't speak for Mopria, but for AirPrint the printer MUST pass a fairly strict set of tests.  If the printer was tested prior to 2019 it might have avoided a hard fail since the member attribute security fix wasn't yet in place, but it definitely would not be able to support media selection.

> Over the years, Airprint's not-quite-IPP-compliant nature has caused 
> quite a bit of grief in my little niche.  This may be another one of 
> those "We support Airprint, not IPP" impedence mismatches.

AirPrint is absolutely IPP-compliant - I know because I wrote the spec and much of the software.  What you might be running into is that AirPrint from iOS/iPadOS often exercises a different part of the IPP stack than CUPS 1.x/2.x.

> One would think Pantum could be made to care, but given that this 
> printer family apparently already works with Windows, Macs, Android, 
> iOS, and even Linux, this is just some geeks being overly pedantic about 
> something (ie IPP) that Pantum never claimed to support to begin with.

First, we really don't know whether the customer has the most recent version of the firmware.  Second, we don't know whether the printer works with any of those other OS's.  Finally, this particular issue might not manifest as a "problem" (one that prevents printing) unless you tried to print something that doesn't match the media in the printer...

________________________
Michael Sweet

Re: [Printing-architecture] RFC: Pantum M7300FDW and similar

[Solomon Peachy]

[-- Attachment #1: Type: text/plain, Size: 811 bytes --]

On Sun, Dec 10, 2023 at 04:41:21PM -0500, Solomon Peachy via Printing-architecture wrote:
> The extent of the AirPrint in their documentation is about how to 
> enable Airprint sharing for a locally-connected printer.
> [...]
> A little digging shows that Apple lists this printer model on their web
> site as supporting AirPrint; I presume this would mean the printer "natively"
> supports it.

Correction:  Their manual also documents using the standard iOS AirPrint client.

So the printer presumably works with both Mopria and Airprint, despite 
its violations of the IPP spec.

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
Dowling Park, FL                      speachy (libera.chat)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Printing-architecture] RFC: Pantum M7300FDW and similar

[Solomon Peachy]

[-- Attachment #1: Type: text/plain, Size: 2020 bytes --]

On Sun, Dec 10, 2023 at 10:11:05AM -0500, Michael Sweet via Printing-architecture wrote:
> They already won't be able to print from iOS or macOS, and probably 
> not from Windows (IPP class driver) or Android (Mopria print provider) 
> because the Get-Printer-Attributes response cannot be parsed.  And if 
> they actually ask someone about the problem they can be pointed to 
> Pantum to get a firmware update.

I should point out that Pantum seems to make no mention of IPP in the 
documentation for this printer. They provide Windows, MacOS, and (x86) 
Linux drivers for direct USB attachment, and state iOS and Android 
printing is supported via "the Pantum APP".  The extent of the AirPrint 
in their documentation is about how to enable Airprint sharing for a 
locally-connected printer.

A little digging shows that Apple lists this printer model on their web 
site as supporting AirPrint; I presume this would mean the printer "natively"
supports it.

With regards to Mopria, Pantum documents using the Mopria Print Service 
on Android devices.

So assuming that getting certified/listed means demonstrating that you 
pass some sort of compliance suite, this means that the Mopria and 
AirPrint clients don't actually care about these printers violating the 
IPP specification.

Over the years, Airprint's not-quite-IPP-compliant nature has caused 
quite a bit of grief in my little niche.  This may be another one of 
those "We support Airprint, not IPP" impedence mismatches.

One would think Pantum could be made to care, but given that this 
printer family apparently already works with Windows, Macs, Android, 
iOS, and even Linux, this is just some geeks being overly pedantic about 
something (ie IPP) that Pantum never claimed to support to begin with.

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
Dowling Park, FL                      speachy (libera.chat)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Printing-architecture] RFC: Pantum M7300FDW and similar

[Thorsten Alteholz]

Hi everybody,

On 10.12.23 08:08, Alexander Pevzner wrote:
>
> My position is following:
> 1. I agree, that following specification is very important, and, where 
> possible, trying to do so.

 From my experience companies don't follow specs because development 
costs for doing things right, are higher than doing just things to keep 
up appearances. So if the marketing department wants to advertise with 
IPP, they should not trying to follow a spec but the spec must be 
followed. As others show, the IPP spec is not that complicated or 
ambiguous that it would not be possible to do so.

> 2. But being practical engineers, we know that sometimes we have to 
> carefully violate rules. 

Being practical engineers we also know that adding exceptions to the 
code will add technical debt. After a while nobody still knows why this 
code was added and maintenance will become hell. This should not be 
dumped onto the shoulders of the cups maintainers. This must be handled 
by the printer companies.
Also I would prefer to tell the Debian users that Pantum printers don't 
work instead of working on bug reports that release A of cups works but 
release B suddenly stops working because there is this special case that 
breaks things.

> cups/ipp.c already has an exception for Brother devices that use some 
> IPP tags incorrectly. sane-airscan, ipp-usb contains many quirks that 
> make incorrectly behaving devices full-functional. Without these 
> quirks, many devices will not work.

... and this is bad and should not be used as an excuse to make things 
worse.

> 3. Even if Pantum will fix their firmware, 50% of users of already 
> purchased devices will not upgrade.

But this is a problem of the QA department of Pantum. My network 
connected printer always bugs me when new software is available. In the 
end I give in and install the software. So why should there be only 50% 
of users having the new software?

> 7. We are doing our work for people, for our end users. And actual 
> tradeoff here is between user's needs to have reliable and secure 
> software (technical "purism" helps as here) and user's needs to have 
> their device supported out of box (here "purism" sometimes works 
> against us).

I know my argument is far-fetched, but part of working for end users is 
also to show them how bad a product actually is. It makes no sense to 
hide any faults.

> 8. If we will eventually rich the Pantum representative, good 
> discussion with weighted arguments can help to convince them to 
> implement some improvements at their side, while aborted discussion 
> will not help a lot.

 From my experience the only argument that is relevant for companies is 
the amount of money they will loose.

>
> Looking forward for your feedback, dear colleagues.

 From my point of view it is fine to not introduce special cases into cups.

    Thorsten

Re: [Printing-architecture] RFC: Pantum M7300FDW and similar

[Michael Sweet]

Alexander,

> On Dec 10, 2023, at 2:08 AM, Alexander Pevzner <pzz@apevzner.com> wrote:
> ...
> Michael's position, as I hear it, is following:
> - device violates IPP specs, so problems is on device, and device must be fixed
> - IPP parser is a quite complex stuff. Touching it is dangerous and may open a way to security vulnerabilities

This code has been the focus of *six* CVEs since the move to Git in 2015 - not quite one CVE a year, but enough to be concerning.  More specifically, commit 5754bccee (https://github.com/apple/cups/issues/5630) addressed the code that allowed "alternate" encodings of member attributes that was causing interoperability issues.

> ...
> My position is following:
> 1. I agree, that following specification is very important, and, where possible, trying to do so.

IPP started in the IETF and the PWG has continued the IETF's goals for conformance terminology: any requirements are there to ensure interoperability and proper functionality.  Postel's Law doesn't apply when it breaks interoperability and potentially has bad side effects.  See the following for some applicable reading/links:

    https://en.wikipedia.org/wiki/Robustness_principle

> 2. But being practical engineers, we know that sometimes we have to carefully violate rules. cups/ipp.c already has an exception for Brother devices that use some IPP tags incorrectly.

This was a case where allowing a non-zero length value (typically the keyword string for the given out-of-band tag) did not cause interoperability issues with other printers and also did not pose any security issues.

Looking at the history of this change (and had to dig into the original SVN repository for this - r7847 on August 19, 2008), back in 2007/2008 when Brother first started making IPP-capable printers (and this was before AirPrint or IPP Everywhere), their implementation had a bug that returned the string "no-value" with the 'no-value' out-of-band syntax (which should have a value length of 0).  Brother was notified and current printers no longer do this...

> sane-airscan, ipp-usb contains many quirks that make incorrectly behaving devices full-functional. Without these quirks, many devices will not work.
> 3. Even if Pantum will fix their firmware, 50% of users of already purchased devices will not upgrade.

They already won't be able to print from iOS or macOS, and probably not from Windows (IPP class driver) or Android (Mopria print provider) because the Get-Printer-Attributes response cannot be parsed.  And if they actually ask someone about the problem they can be pointed to Pantum to get a firmware update.

Firmware update capability is required for both AirPrint and Mopria, and at least the AirPrint folks require the ability to upgrade without special software and highly recommend automatic firmware updates over the Internet whenever possible...  Pantum is an AirPrint licensee...

> 4. I understand the complexity of IPP decoder, because I'm the author of alternative, independent implementation in Go (https://github.com/OpenPrinting/goipp). I believe my implementation is similar to CUPS's on its level of correctness and strictness. And has near 100% test coverage, BTW.

As does the CUPS implementation, which Google and others have put through the wringer with long-term fuzzing projects...

> 5. My patch is simple and observable. It is only few lines of code (see https://github.com/OpenPrinting/cups/pull/826 for details). It doesn't change any assumptions of the upper-level code about the parsed IPP message. It only slightly relaxes decoding rules. Honestly, I don't see how it can expose any vulnerability.

It was causing problems before I fixed it, mainly because the returned values made no sense - basically 

> 6. My patch is not "just a quick hack". I understand that this is very important part of the CUPS code, so I've spent more that 2 weeks, thinking about it correctness and modelling various corner cases, using my goipp library.

I don't think I ever called it a quick hack.  No matter how well-tested/reasoned, you are creating an edge-case for allowing invalid collection values as long as a single memberName value is seen in an IPP message.

You need to notify PANTUM that they have an issue.  Regardless of whether you believe that a user will update the firmware, they don't even have an opportunity unless you report the issue to the manufacturer.  And in fact, you don't even know whether PANTUM has already fixed the issue!?!

> 7. We are doing our work for people, for our end users. And actual tradeoff here is between user's needs to have reliable and secure software (technical "purism" helps as here) and user's needs to have their device supported out of box (here "purism" sometimes works against us).

So we should provide them with intentionally defective software so that they don't need to press a button on their printer to update the firmware?  How far down the slippery slope of "we'll just add a workaround for this printer" do you want to go?

I can speak from 30 years of experience doing printing software - that is not a path you want to go down.  The number of variables in printing configurations is *immense*, and you do not want to bring back vendor printer drivers - that is the end game if you allow for too many "workarounds".

> 8. If we will eventually rich the Pantum representative, good discussion with weighted arguments can help to convince them to implement some improvements at their side, while aborted discussion will not help a lot.

"Your printers don't work with iOS" should be enough.  They probably won't care about Linux.

> If my patch looks "too wide", I can do it more precious, by affecting only behavior of parsing IPP responses received from devices, not received requests. At this case it looks even safer.

Let's say we accept invalid collection attribute values.  We get the media-col-database and media-col-ready values from the printer, and then send it a media-col collection to specify printing from tray 2 on cardstock: will the printer be able to understand a correctly encoded collection value for media-col if it doesn't return valid collection values for media-col-database/ready?  (probably not)

Then you get a support request from a user saying, "I can't print from tray 2."

Did you fix the problem for the user?  Is this better?

> I'd prefer to make it even more precious, affection only communication with Pantum devices. But in that places of the CUPS code where responses are parsed there is no information what kind devices we are speaking with.

And I would be even more opposed to such a change.  At that point you have created a printer driver...

> ...
> P.S. I remember a while ago we were in the similar discussion with Trent Lloyd, author of Avahi. He didn't want to include localhost support because it violates (according to him) mDNS RFC, and it took about 3 years to convince him to make an exception (according to Till, it was me who has reached out to him, https://openprinting.github.io/OpenPrinting-News-February-2020/#avahi-local-service-support)

Not at all the same issue, and honestly he was wrong that you can't support multicast over the loopback interface (there is just nobody else to talk to, so multicast becomes broadcast to the local host...)

________________________
Michael Sweet

[Printing-architecture] RFC: Pantum M7300FDW and similar

[Alexander Pevzner]

Hi!

recently I was focused on getting some devices that supposed to work 
driverlessly to be actually functional.

I was able to get working at least half-dozen various devices from 
Canon, HP, Lexmark and Pantum.

Although some problems were caused by bugs in printing software (see 
https://github.com/OpenPrinting/libcupsfilters/issues/38, for example), 
in most cases problems were caused by buggy firmware that violates 
specs, so "fixes" are actually workarounds that allows system software, 
that was working correctly (i.e., according the written specification) 
before that workaround to work with some particular device or class of 
devices by carefully adding some specs violation to make this device happy.

Here I want to discuss the situation with Pantum M7300FDW. Pantum is not 
some exotic unknown trademark, these devices are inexpensive, quite 
functional and become popular. I believe, they will be as popular as 
Brother devices. And most likely, the problem that I want to speak about 
affects many Pantum models.

This device has a serious violation of the IPP protocol: it encodes 
members of collections using attributes with names instead of using 
memberAttrName to represent attributes names within the collection.

Which is interesting, the devise is listed here as supported: 
https://openprinting.github.io/printers/

Mopria also lists device as certified 
(https://mopria.org/certified-products, sorry, I can't create a direct 
list to device).

I have proposed a workaround by patching IPP parser in CUPS 
(https://github.com/OpenPrinting/cups/pull/826) but it was rejected by 
Michael Sweet.

However, upon Till's advice, I don't give up and trying to discuss it 
here :-)

First of all, I want to say, that I'm looking for a technical 
discussion, not for any kind of confrontation. I greatly respect 
Michael, his work and his expertise and really impressed how one man in 
one pair of hands can drive printing software of entire (non-Windows) 
world. But regardless of that I feel not quite comfortable when 
technical discussions ends in so abortive way as in this case.

Michael's position, as I hear it, is following:
- device violates IPP specs, so problems is on device, and device must 
be fixed
- IPP parser is a quite complex stuff. Touching it is dangerous and may 
open a way to security vulnerabilities

(please correct me, if I've missed something).

My position is following:
1. I agree, that following specification is very important, and, where 
possible, trying to do so.
2. But being practical engineers, we know that sometimes we have to 
carefully violate rules. cups/ipp.c already has an exception for Brother 
devices that use some IPP tags incorrectly. sane-airscan, ipp-usb 
contains many quirks that make incorrectly behaving devices 
full-functional. Without these quirks, many devices will not work.
3. Even if Pantum will fix their firmware, 50% of users of already 
purchased devices will not upgrade.
4. I understand the complexity of IPP decoder, because I'm the author of 
alternative, independent implementation in Go 
(https://github.com/OpenPrinting/goipp). I believe my implementation is 
similar to CUPS's on its level of correctness and strictness. And has 
near 100% test coverage, BTW.
5. My patch is simple and observable. It is only few lines of code (see 
https://github.com/OpenPrinting/cups/pull/826 for details). It doesn't 
change any assumptions of the upper-level code about the parsed IPP 
message. It only slightly relaxes decoding rules. Honestly, I don't see 
how it can expose any vulnerability.
6. My patch is not "just a quick hack". I understand that this is very 
important part of the CUPS code, so I've spent more that 2 weeks, 
thinking about it correctness and modelling various corner cases, using 
my goipp library.
7. We are doing our work for people, for our end users. And actual 
tradeoff here is between user's needs to have reliable and secure 
software (technical "purism" helps as here) and user's needs to have 
their device supported out of box (here "purism" sometimes works against 
us).
8. If we will eventually rich the Pantum representative, good discussion 
with weighted arguments can help to convince them to implement some 
improvements at their side, while aborted discussion will not help a lot.

If my patch looks "too wide", I can do it more precious, by affecting 
only behavior of parsing IPP responses received from devices, not 
received requests. At this case it looks even safer.

I'd prefer to make it even more precious, affection only communication 
with Pantum devices. But in that places of the CUPS code where responses 
are parsed there is no information what kind devices we are speaking with.

Please note that with my patch the device prints and scans driverlessly, 
and does it perfectly well.

And I really see no danger associated with this change.

Looking forward for your feedback, dear colleagues.

P.S. I remember a while ago we were in the similar discussion with Trent 
Lloyd, author of Avahi. He didn't want to include localhost support 
because it violates (according to him) mDNS RFC, and it took about 3 
years to convince him to make an exception (according to Till, it was me 
who has reached out to him, 
https://openprinting.github.io/OpenPrinting-News-February-2020/#avahi-local-service-support)

-- 

	Wishes, Alexander Pevzner (pzz@apevzner.com)