Dear Maintainer,

On trixie, CUPS cannot create a driverless (IPP Everywhere) queue for a
printer whose only raster format is PWG Raster. Both

  lpadmin -p test -v ipp://<printer>:631/ipp/print -m everywhere

and the temporary queues that print dialogs create through
CUPS-Create-Local-Printer fail with:

  Printer does not support required IPP attributes or document formats.

The printer here is a Canon G3010 series on Wi-Fi. It answers
Get-Printer-Attributes normally over ipp and ipps; the relevant
attributes are:

  document-format-supported = application/octet-stream,image/pwg-raster
  pwg-raster-document-resolution-supported = 600dpi
  pwg-raster-document-type-supported = srgb_8,sgray_8

Cause: _ppdCreateFromIPP2() in cups/ppd-cache.c looks up
pwg-raster-document-resolution-supported with IPP_TAG_KEYWORD, but the
attribute has resolution syntax, so is_pwg is always false and the
function gives up. The check came in with upstream 2.4.8 and was fixed
in 2.4.12 by commit 63f5c71f (PR #1140). The 2.4.12 release notes do
not mention this fix, which may be why it was not picked up for trixie:
https://github.com/OpenPrinting/cups/pull/1140
https://github.com/OpenPrinting/cups/commit/63f5c71f0bd4ec1692162e153f033c120417c6af

With that fixed, a second bug shows: the make-and-model whitespace
trimming that came with the CVE-2024-47175 hardening
(debian/patches/0014) does not stop at the first non-space character,
so every space becomes a NUL and the PPD is named "Printer - IPP
Everywhere". Fixed upstream in 2.4.12 by commit 5cc470c8 (upstream
issue #1096):
https://github.com/OpenPrinting/cups/commit/5cc470c8d95df40f32e8a401b2946886c91b03d1

forky (2.4.18) and unstable (2.4.20) have both fixes, and no trixie
update carries them yet. bookworm (2.4.2-3+deb12u9) has only
the trimming bug, through its own CVE-2024-47175 backport
(0024-CVE-2024-47175-and-further-hardening.patch), so 5cc470c8 would
apply there too.

The attached debdiff adds both upstream commits as 0019 and 0020 and
bumps the version to 2.4.10-3+deb13u3. The same change is available as
a git branch on top of salsa's debian/trixie (which first needs the
deb13u2 upload imported; that is the first of the two commits):
https://github.com/lukacajnkar/cups-debian/compare/debian/trixie...fix/everywhere-ppd-pwg-raster

Testing done:

- dpkg-source -b and a fresh dpkg-source -x: all 20 patches apply
  cleanly; the only source change is cups/ppd-cache.c.
- libcups built from the patched source, calling _ppdCreateFromIPP()
  on the live printer's Get-Printer-Attributes response: the PPD is
  generated, passes cupstestppd, and is named "G3010 series - IPP
  Everywhere". The same build without 0020 fails with the error above.

I have not run a full dpkg-buildpackage or the test suite, because the
build dependencies are not installed here.

Workaround for affected users: create the queue with the cups-filters
PPD generator instead, for example

  lpadmin -p NAME -v <device-uri> -m 'driverless:<printer-uri>' -E

Could this go into the next trixie point release?

Thanks,
lukacajnkar