- Package:
- printer-driver-hpcups
- Source:
- printer-driver-hpcups
- Description:
- HP Linux Printing and Imaging - CUPS Raster driver (hpcups)
- Submitter:
- Marcin Owsiany
- Date:
- 2025-04-22 16:42:03 UTC
- Severity:
- normal
My setup: - headless host A running cups 2.4.2-3+deb12u8, with printer connected via USB, makes the printer available to host B - host B running cups 2.4.2-3+deb12u7, printing from evince. Works like a charm. Then I: - upgrade cups on host B to 2.4.2-3+deb12u8 - restart evince, press CTRL+P, select the printer by clicking on it once in the printing dialog - this hangs displaying a (localized) message that I think might be something like "Retrieving printer information..." in the original. I tried other combination of versions. It seems 2.4.2-3+deb12u8 on host B is what breaks things. I'm more than happy to provide information on the configuration, just please let me know what to provide, printing remains a black magic to me :-( FWIW the printer looks the same in GNOME printer settings dialog on host B whether it works for evince or not - the printer address is "(null)" in both cases.
Hi Marcin, cups now makes more checks with the attributes it gets from the printer, so it would be great to know which printer you are using. Are there any messages in the error log on host A or host B? Are you still able to print on host A? Are you able to try a different printer (maybe even a different manufacturer) and check whether you have the same problems with it? Thorsten
Thanks for the quick response Thorsten!
pt., 4 paź 2024 o 13:15 Thorsten Alteholz <debian@alteholz.de> napisał(a):
It's an HP Smart Tank 720.
Indeed, on host B the following appears at the same time the print dialog
hangs in evince ("piec" is host A):
E [04/Oct/2024:13:29:44 +0200] HP_Smart_Tank_710_720_series_piec: Printer
returned invalid data: \"media-supported\": Bad keyword value \"\" -
invalid character (RFC 8011 section 5.1.4).
I had never tried before, but yes, "lpr -P ... file.pdf" worked! \o/
Are you able to try a different printer (maybe even a different
Sorry, I only have this one printer.
FWIW, I did "sudo grep -R media-supported /etc 2>/dev/null" and that came
back with nothing. So I guess it's a bug in the printer's firmware? Can I
work this around somehow on the cups side?
Marcin
Hi Marcin, yes, this message belongs to the new validation of attributes that was part of the latest patches. Unfortunately this printer does not behave correct, so I think this is rather a feature than a bug. yes, this is a bug in the printer's firmware. cups asks the printer about some properties and one of the answers contains a non RFC-conform character. Other such characters resulted in an RCE, so this check is somewhat important. If there is no other firmware available, I am afraid you have to build your own cups package. The culprit is in 0024-CVE-2024-47175-and-further-hardening.patch for scheduler/ipp.c Thorsten
pt., 4 paź 2024 o 14:05 Thorsten Alteholz <debian@alteholz.de> napisał(a): There is newer firmware, although I do not see a way to apply it from Debian :-( One thing I do not understand is why this invalid input is being accepted over USB, but is a fatal error over TCP? Thanks for the pointer! I'll probably be able to hack around it, but I'm afraid less technically savvy users might not be so lucky. Perhaps there should be a break-glass option to keep being able to use one's hardware? Marcin
I managed to upgrade the printer firmware using its embedded webserver UI (from SAYAWLPP1N001.2137A.00 created 2021-09-06, to SAYAWLPP1N002.2423A.00 to 2024-06-03). Unfortunately this did not help. However, I got my hands on the ipptool utility, and this is where it really gets interesting. I have now made the printer available via two channels: - directly over WiFi - via USB and Debian cups (host A), as before When I invoke the get-printer attributes on the printer directly like this: ipptool -j http://192.168.2.102:631/ipp/print get-printer-attributes.test > direct.json then the "media-supported" key in the output is correct - no empty values. However when I do it through the cups server on host A like this: ipptool -j http://192.168.192.1:631/printers/kotlownia2 get-printer-attributes.test > via-cups.json I get output with empty values, and an error just like the one found earlier in host B's error_log: "media-supported": Bad keyword value "" - invalid character (RFC 8011 section 5.1.4). So it looks like it's cups itself that injects the invalid empty values! The printer's response is (and probably was) correct! The exact difference of the critical part is as follows:--- direct_.json 2024-10-04 16:39:26.402511781 +0200 +++ via-cups_.json 2024-10-04 16:40:06.891135645 +0200 @@ -1,29 +1,36 @@ "media-supported": [ - "na_executive_7.25x10.5in", - "na_letter_8.5x11in", - "na_legal_8.5x14in", + "na_5x7_5x7in", + "oe_photo-l_3.5x5in", + "na_index-4x6_4x6in", + "na_foolscap_8.5x13in", "na_govt-letter_8x10in", - "na_invoice_5.5x8.5in", - "iso_a5_148x210mm", "iso_a4_210x297mm", + "iso_a5_148x210mm", + "iso_a6_105x148mm", "iso_b5_176x250mm", "jis_b5_182x257mm", - "jpn_oufuku_148x200mm", - "jpn_hagaki_100x148mm", - "iso_a6_105x148mm", - "na_index-4x6_4x6in", - "om_small-photo_100x150mm", - "na_5x7_5x7in", - "na_index-5x8_5x8in", + "na_legal_8.5x14in", "na_number-10_4.125x9.5in", - "iso_dl_110x220mm", "iso_c6_114x162mm", + "iso_dl_110x220mm", + "na_executive_7.25x10.5in", + "na_index-5x8_5x8in", + "na_letter_8.5x11in", "jpn_chou3_120x235mm", "jpn_chou4_90x205mm", - "oe_photo-l_3.5x5in", - "jpn_photo-2l_127x177.8mm", - "na_foolscap_8.5x13in", + "jpn_hagaki_100x148mm", + "custom_199.9x151.05mm_199.9x151.05mm", + "na_invoice_5.5x8.5in", + "oe_executive-fb_7.25x10.5in", + "oe_legal-fb_8.5x14in", + "oe_statement-fb_5.5x8.5in", + "om_b-5-fb_175.94x249.94mm", + "", + "om_envelope-dl-fb_109.98x219.96mm", + "om_envelope-c-6-fb_113.96x161.97mm", + "", + "oe_8-5x-13-fb_8.5x13in", "custom_min_3.5x5in", - "custom_max_8.5x14in" + "custom_max_5x14in" ], - "media-default": "iso_a4_210x297mm", + "media-default": "unknown",
Just in case it's useful in determining the cause for the corruption,
here's a diff over sorted lists:
$ diff -U 20 *_.json
--- direct_.json 2024-10-04 16:52:12.750114924 +0200
+++ via-cups_.json 2024-10-04 16:51:59.521916969 +0200
@@ -1,26 +1,33 @@
- "custom_max_8.5x14in",
+ "",
+ "",
+ "custom_199.9x151.05mm_199.9x151.05mm",
+ "custom_max_5x14in",
"custom_min_3.5x5in",
"iso_a4_210x297mm",
"iso_a5_148x210mm",
"iso_a6_105x148mm",
"iso_b5_176x250mm",
"iso_c6_114x162mm",
"iso_dl_110x220mm",
"jis_b5_182x257mm",
"jpn_chou3_120x235mm",
"jpn_chou4_90x205mm",
"jpn_hagaki_100x148mm",
- "jpn_oufuku_148x200mm",
- "jpn_photo-2l_127x177.8mm",
"na_5x7_5x7in",
"na_executive_7.25x10.5in",
"na_foolscap_8.5x13in",
"na_govt-letter_8x10in",
"na_index-4x6_4x6in",
"na_index-5x8_5x8in",
"na_invoice_5.5x8.5in",
"na_legal_8.5x14in",
"na_letter_8.5x11in",
"na_number-10_4.125x9.5in",
+ "oe_8-5x-13-fb_8.5x13in",
+ "oe_executive-fb_7.25x10.5in",
+ "oe_legal-fb_8.5x14in",
"oe_photo-l_3.5x5in",
- "om_small-photo_100x150mm",
+ "oe_statement-fb_5.5x8.5in",
+ "om_b-5-fb_175.94x249.94mm",
+ "om_envelope-c-6-fb_113.96x161.97mm",
+ "om_envelope-dl-fb_109.98x219.96mm",
I reported this issue upstream to https://github.com/OpenPrinting/cups/issues/1078 and it turned out that the root cause was some invalid names in the ppd file. It had an invalid character in some of the size names - the '#' in "Envelope#10", "JapaneseEnvelope#3.FB" and "JapaneseEnvelope#4.FB". I think it's still wrong for cups to respond with a syntactically invalid response to get-printer-attributes in this case, so I'm keeping this bug open for now. I'll clone it into another bug against hpcups which I think is responsible for the PPD file.
[resending to hplip 1085142, where it was supposed to go, instead of cups] Hi, cups 2.4.11 (not yet packaged for Debian) is said in above issues/1078 to have a workaround for this. Regarding hplip, I looked at 3.24.4 upstream release (not yet packaged for Debian) and seems it still has the same problem. Looking at https://github.com/OpenPrinting/cups/issues/1078 I wonder if attached sed script acting on ppd files under ppd dir does fix this issue (I am a complete newbie to this and I do not have access to affected printer nor know at all about ppd format). Another thing, has this been reported to hplip upstream? Regards,
Control: forwarded -1 https://bugs.launchpad.net/hplip/+bug/2097381 ... Reported upstream and tagged as such.
Hi, I have been looking at the result of running sed with the previously attached sed file. diff with the result is attached. As mentioned before, I am not familiar with ppd files, so take with care. Below goes the list of affected files. Seems that only a few ppd files are affected, so I do not think this bug should be considered RC. Applying patch ppd_media-no-hash-symbol.diff patching file ppd/classppd/hpcups/hp-Mimas17-Normal.ppd patching file ppd/classppd/hpcups/hp-P15-CISS-Normal.ppd patching file ppd/classppd/hpcups/hp-Peaks-mod-mech-Normal.ppd patching file ppd/classppd/hpcups/hp-SPDOfficejetProBsize-Normal.ppd patching file ppd/hpcups/hp-deskjet_5000_series.ppd patching file ppd/hpcups/hp-deskjet_5200_series.ppd patching file ppd/hpcups/hp-envy_5000_series.ppd patching file ppd/hpcups/hp-ink_tank_110_series.ppd patching file ppd/hpcups/hp-ink_tank_310_series.ppd patching file ppd/hpcups/hp-ink_tank_wireless_410_series.ppd patching file ppd/hpcups/hp-officejet_5200_series.ppd patching file ppd/hpcups/hp-officejet_pro_7720_series.ppd patching file ppd/hpcups/hp-officejet_pro_7730_series.ppd patching file ppd/hpcups/hp-officejet_pro_7740_series.ppd patching file ppd/hpcups/hp-smart_tank_350_series.ppd patching file ppd/hpcups/hp-smart_tank_500_series.ppd patching file ppd/hpcups/hp-smart_tank_510_series.ppd patching file ppd/hpcups/hp-smart_tank_530_series.ppd patching file ppd/hpcups/hp-smart_tank_6000_series.ppd patching file ppd/hpcups/hp-smart_tank_610_series.ppd patching file ppd/hpcups/hp-smart_tank_660-670_series.ppd patching file ppd/hpcups/hp-smart_tank_7000_series.ppd patching file ppd/hpcups/hp-smart_tank_710-720_series.ppd patching file ppd/hpcups/hp-smart_tank_7300_series.ppd patching file ppd/hpcups/hp-smart_tank_750_series.ppd patching file ppd/hpcups/hp-smart_tank_7600_series.ppd patching file ppd/hpcups/hp-smart_tank_790_series.ppd patching file ppd/hpcups/hp-smart_tank_plus_550_series.ppd patching file ppd/hpcups/hp-smart_tank_plus_570_series.ppd patching file ppd/hpcups/hp-smart_tank_plus_650_series.ppd patching file ppd/hpcups/hp-smart_tank_wireless_450_series.ppd
Hi Agustin, thanks a lot for taking care of this1 @Marcin: did you try the patch from Agustin and does it help with your problem? Thorsten
Sorry for the late reply. I had already edited my ppd file a while ago, and I'm not sure I made a backup of the original. I'm still clueless about how these files are generated and installed exactly. So I cannot promise I can try the sed script at this point. But if someone sends me a ppd file to try out I can certainly test it on my system. I can attach the file as I'm using it now later today, if that's helpful. Marcin wt., 11 lut 2025, 01:31 użytkownik Thorsten Alteholz <debian@alteholz.de> napisał:
śr., 12 lut 2025 o 13:25 Marcin Owsiany <porridge@debian.org> napisał(a): Attached is my original (-a) PPD file and the modified one (-b, which works for me). Turns out the changes are the same as in the diff attached earlied by Agustin, except I used the FB suffix rather than Fullbleed. Not sure whether it matters, I don't have that paper format anyway :-) Marcin
Hi, Names I used are those pointed out in https://github.com/OpenPrinting/cups/issues/1078 ... WARN Size “Envelope#10.FB” should be the Adobe standard name “Env10.Fullbleed”. ... WARN Size “JapaneseEnvelope#4.FB” should be the Adobe standard name “EnvChou4.Fullbleed”. ... I thing that is some sort of internal key name for page sizes, so both FB and Fullbleed might work well, as long as they do not contain forbidden chars. If something is to be changed, even locally in Debian, I would go for the standards Adobe names, just in case.
... Seems that what is shipped, /usr/share/cups/drv/hpcups.drv, is not refreshed after changed ppd files. Not sure what is the right way to proceed here.
We believe that the bug you reported is fixed in the latest version of
hplip, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1085142@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Thorsten Alteholz <debian@alteholz.de> (supplier of updated hplip package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sat, 15 Feb 2025 22:39:02 +0100
Source: hplip
Architecture: source
Version: 3.22.10+dfsg0-8
Distribution: unstable
Urgency: medium
Maintainer: Debian Printing Team <debian-printing@lists.debian.org>
Changed-By: Thorsten Alteholz <debian@alteholz.de>
Closes: 1040918 1085142
Changes:
hplip (3.22.10+dfsg0-8) unstable; urgency=medium
.
* add patch to remove # from ppd files (Closes: #1085142)
(thanks to Agustin Martin for the patch)
(thanks to Marcin Owsiany for testing the fix)
* D-Bus policy should be installed in /usr (Closes: #1040918)
(thanks to Gioele Barabucci for the MR that I manually merged)
Checksums-Sha1:
6db317023e738f1e832730395df4d5827b624d17 3216 hplip_3.22.10+dfsg0-8.dsc
6b3376a010a79dbaead1969484e9d759a3e5c3ca 147320 hplip_3.22.10+dfsg0-8.debian.tar.xz
e47606524dca652912cb1a50d68e8d118f77f969 20840 hplip_3.22.10+dfsg0-8_amd64.buildinfo
Checksums-Sha256:
e1bc06ac5023f7b3a34cd1854f6b5417651322924df8d084deb21bc825ee6093 3216 hplip_3.22.10+dfsg0-8.dsc
6adabfd43c6f0e818bd993b2ffc7564a0bbe19cffd4ed19657e93a2bd681bca7 147320 hplip_3.22.10+dfsg0-8.debian.tar.xz
215d6f383dbc5dfa209fb47ae19d35506ca7c5a40d817b46edb95baad95d7e55 20840 hplip_3.22.10+dfsg0-8_amd64.buildinfo
Files:
0b3f51c8e3da3b1a535e1bcfbf58b2c9 3216 utils optional hplip_3.22.10+dfsg0-8.dsc
f7fdd958319ba684fdc1135246c39493 147320 utils optional hplip_3.22.10+dfsg0-8.debian.tar.xz
e738ba48e09f22363eb38996cd330314 20840 utils optional hplip_3.22.10+dfsg0-8_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----
iQKnBAEBCgCRFiEEYgH7/9u94Hgi6ruWlvysDTh7WEcFAmexJd9fFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDYy
MDFGQkZGREJCREUwNzgyMkVBQkI5Njk2RkNBQzBEMzg3QjU4NDcTHGRlYmlhbkBh
bHRlaG9sei5kZQAKCRCW/KwNOHtYR9f9D/9AVaaiQISD0LEVBNDaCeaKkCKN9XmM
sTVxq15FZRafyIqaY8zN1xlIK90+4Hh5QoTQJiRjTl/c1Wbzv5NOi+znBowjYES2
owG6K1cEJbEfBVRYd5z4akC2Xmhz06j0MyAsQK9gPmueuL0YVMQQ3X1uqv5h9wDe
wcJVMqjsM+e4/37ySeZOyYO843Oqxa6brYYInpIsRda/izCzVQsmNNUnezRPAGUp
F7rocUbWg/A034cKK3tCONfyqrX+17Spw5Cji1LFv14JSgNM+tBYrphY9BmuM0Oc
vNdLXZ3DyT18EhKnVJ2gDzDxrgwk1z+ouIhZ5XODAfD04PgQSOa1F2AgbOizhnEn
vBCVU/a8xIqj92+EV1ws2oIG/+KrDe4nWABYqn9UIb6YJ0wylgGsyC91wuwWZBtY
T3Dq4dZojjBGPkPxsMMUKC1KOIYYVbHQaIHZkpscl0PNaqK8Ytmo1yfJegyjuV4k
DpbtfFBqs33LtTZqOGPyjmPujRlO/pePzilGIzq+Li2noM7XexFQc2jkdqUKbxGG
6FbOSyN+mtNdTmHx9K10eIRIbYLJk4aLIAe3lz1qretgVZ8yD8SVQ5SNJPDGrGkc
gjPuFMehYTfb4AaSMaATi1ERLt70XmNPrFYmhYFpx001ki5BVSPmuEVBoK+HuOnz
SwN5254/KGDmsQ==
=QpLU
-----END PGP SIGNATURE-----
Hi, Thorsten and debian-printing team. I am attaching an updated patch for 3.24.4+dfsg0. When upgrading a personal repo following the git-debrebase procedure described in dgit-maint-debrebase the worst problem happened when merging changes in this patch. I think trying this merge is not worth the effort and is much better and simpler to skip this commit when (deb)rebasing and commit fixed stuff as a new commit on top of previous commits. Regards,