CUPS 2.2.12: Choice name "custom" not allowed any more

[tillkamppeter]

On Ubuntu I have updated to CUPS 2.2.12 for Eoan (19.10) and found out that the PPD file HP-Color_LaserJet_CM3530_MFP-PDF.ppd of the sample PPDs of cups-filters is not accepted by CUPS any more (also fails cupstestppd) due to the fact that one of the choices of the option "stapleoption" was named "custom".
This case was no big problem as as upstream maintainer of cups-filters I could simply change it to "customsize" (included in the 1.25.3 release of cups-filters) but there seem to be many other PPD files out there in the wild which have an option choice named "custom". For example there are PPD files in HPLIP with this problem, as shown in Debian bug #935918.
Why is "custom" not allowed any more as option choice name from 2.2.12 on? For supporting custom options of CUPS only "custom." is needed, not the simple "custom". Also 2.2.12 is a micro release, it should not have such kind of change.

[michaelrsweet]

Till, "Custom" is the name used for custom options, and the use of "Custom" as a choice in a PPD file turned out to be the cause of many crashes. Since this has been the case for a LONG time (since CUPS 1.2), existing PPD files that relied on using "Custom" as an option keyword wouldn't have worked properly anyways so the issue is just that we stopped loading broken PPD files and causing cupsd to crash.

We might be able to rename the "Custom" option when loading to avoid the memory leak and allow these (non-custom) options to actually work... I will investigate.

[debiantriage]

Debian bug #935918 does not exist. Is there a revised URL?

--
Brian.

[debiantriage]

#935918 does exist but #9359180 is what is given when the link is clicked on.

--
Brian.

[michaelrsweet]

@debiantriage Fixed the link in the original report.

[zdohnal]

Users encountered the issue on Fedora too https://bugzilla.redhat.com/show_bug.cgi?id=1750904 .

[michaelrsweet]

[master 2a06655] PPD files containing custom option keywords did not work (Issue #5639)