CUPS derives broken IPP attribute names from PPD option/choice names #5740
Comments
|
Following issues and bug reports made me aware of this: OpenPrinting/cups-filters#193, OpenPrinting/cups-filters#201, Debian bug #949315. |
|
Your patch also fixes a buffer overflow when nameLength is too short. But is there a description of what the canonicalization here should mean? My concern is that this changes something in way incompatible with existing installations. Is it possible for someone to have had depended on the double dash, or is that disallowed in an RFC (that I've been unable to locate ) |
|
AFAIK there are no IPP attributes with double dashes or leading or trailing dashes, at least I did not see that in the answers to get-printer-attributes IPP requests of 20+ different printer models. AFAIK there are also standard names for InputSlot/media-source choices, including "tray-1", "tray-2", ... and no "tray--1", "tray--2", ... |
|
@tillkamppeter I'm not the only person that created IPP - dozens of really smart people from different PWG companies contributed to the development of IPP in the late 90's, and I'm just one of several people continuing the evolution of IPP (now 22 years old!) To answer your question, RFC 8011 says the following about the 'keyword' syntax (which is used for attribute names and keyword string values):
CUPS has historically relaxed the requirement for lowercase letters because of PPDs, but really the only hard requirement is that the string start with a letter. Double-dashes are not normally used but are not prohibited either. |
|
At least "Tray-1", "Tray-2", ... in PPD files should not translate to "tray--1", "tray--2", ... in IPP attributes. Am I right with that? |
1. Fix conversion of PPD option choice names to IPP attributes When I create a CUPS queue with a PPD file with choice names "Tray-1", "Tray-2", ... in the InputSlot option CUPS translates these names to double-dashed IPP attribute names: "tray--1", "tray--2", ... in the "media-source" attribute, both when passing a job to the printer with the IPP backend, making the printer ignore the tray choice, and also when answering a get-printer-attributes IPP request from a client. This happens when in the PPD a dash is followed by a digit, as the pwg_unppdize_name() function in cups/ppd-cache.c inserts a dash whenever a non-digit is followed by a digit in the PPD name. As IPP attribute names generally never have double-dashes and also no dashes in the beginning or the end of the name, I have modified the pwg_unppdize_name() function appropriately. Upstream bug: apple/cups#5740 Debian bug: https://bugs.debian.org/949315 2. Fix scheduler's cupsd.conf load (triggered by cupsctl and web interface) When running it without arguments it is supposed to read the local CUPS's cupsd.conf and show a summary of the setting. in CUPS 2.3.1 it shows a mess with a lot of HTML inside and this is due to the fact that when loading the file via HTTP using the /admin/cups/cupsd.conf path the scheduler calls the admin.cgi program which returns the admin front page of the web admin interface. cupsctl then tries to interpret that as the config file and displays garbage. Even worse is if you run cupsctl with command line argument (one of the five switches or a key=value pair) to change a setting. It seems to load cupsd.conf again and gets again the HTML code of the web interface page. cupsctl tries to interpret this again, producing garbage, adds the user-supplied setting and writes all this back into cupsd.conf. Then it tries to restart the scheduler which fails due to the broken config file. The problem is that in the file scheduler/client.conf, in the function get_file() the URI from the client is at first checked whether it begins with "/admin/" and in this case the CGI program admin.cgi is responsible. Only after that the check for "/admin/conf/cupsd.conf" comes and is never reached. I have changed the order now appropriately and this way cupsctl works again. Note that the problem only occurs if the web interface is active and the cupsctl command is issued by a non-root user. This is a regression caused by issue Upstream bug: apple/cups#5744
|
This is fixed in OpenPrinting CUPS. |
When I create a CUPS queue with a PPD file with choice names "Tray-1", "Tray-2", ... in the InputSlot option CUPS translates these names to double-dashed IPP attribute names: "tray--1", "tray--2", ... in the "media-source" attribute, both when passing a job to the printer with the IPP backend, making the printer ignore the tray choice, and also when answering a get-printer-attributes IPP request from a client.
This happens when in the PPD a dash is followed by a digit, as the pwg_unppdize_name() function in cups/ppd-cache.c inserts a dash whenever a non-digit is followed by a digit in the PPD name.
As IPP attribute names generally never have double-dashes and also no dashes in the beginning or the end of the name, I have modified the pwg_unppdize_name() function appropriately. Patch atrtached.
I know that PPDs are deprecated, but we should fix this at least for the 2.3.x series of CUPS.
pwg_unppdize_name_double_dash_fix.patch.txt
The text was updated successfully, but these errors were encountered: