Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CUPS derives broken IPP attribute names from PPD option/choice names #5740

Open
tillkamppeter opened this issue Feb 16, 2020 · 5 comments
Open

CUPS derives broken IPP attribute names from PPD option/choice names #5740

tillkamppeter opened this issue Feb 16, 2020 · 5 comments
Assignees

Comments

@tillkamppeter
Copy link

@tillkamppeter tillkamppeter commented Feb 16, 2020

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

@tillkamppeter

This comment has been minimized.

Copy link
Author

@tillkamppeter tillkamppeter commented Feb 16, 2020

Following issues and bug reports made me aware of this: OpenPrinting/cups-filters#193, OpenPrinting/cups-filters#201, Debian bug #949315.

@salgernon

This comment has been minimized.

Copy link
Collaborator

@salgernon salgernon commented Mar 17, 2020

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 )

@salgernon salgernon self-assigned this Mar 18, 2020
@tillkamppeter

This comment has been minimized.

Copy link
Author

@tillkamppeter tillkamppeter commented Mar 19, 2020

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", ...
@michaelrsweet, as creator of IPP you know probably best, am I right with my assumptions?

@michaelrsweet

This comment has been minimized.

Copy link
Collaborator

@michaelrsweet michaelrsweet commented Mar 19, 2020

@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):

The 'keyword' attribute syntax is a sequence of characters, of length 1 to 255, containing only the US-ASCII [RFC20] encoded values for lowercase letters ("a"-"z"), digits ("0"-"9"), hyphen ("-"), dot ("."), and underscore ("_"). The first character MUST be a lowercase letter. Furthermore, keywords MUST be in US English.

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.

@tillkamppeter

This comment has been minimized.

Copy link
Author

@tillkamppeter tillkamppeter commented Mar 19, 2020

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?
In general there should be a safe two-way translation between PPD files and IPP attributes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.