Bug#1033616: cups prepends job number to job-name so job names near 255 characters may be too long

[John Hughes]

Package: cups
Version: 2.3.3op2-3+deb11u2
Severity: normal

Dear Maintainer,

* What led up to the situation?

I printed a page from firefox with a very, very long URL. Firefox used the first 255 bytes of the URL as the job name.

* What was the outcome of this action?

The job mysteriously didn't print. Lookin in the cups log (with debug on) I found the lines:

D [28/Mar/2023:18:14:44 +0200] [Job 365] job-name nameWithoutLanguage 365 - https://xxxxxxxxxxx/xxxxxxxx/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

D [28/Mar/2023:18:27:36 +0200] [Job 369] Validate-Job: client-error-request-value-too-long (client-error-request-value-too-long)

notice how the job name passed to cups ("https://xxx...") is shorter than 255 characters, but when the job number "365 - " is prepended it is longer tnan 255 characters and so overflows.

* What outcome did you expect instead?

That my print job be printed rather than just geting stuck in the print queue forever.

How to reproduce:

lp -o 'job-name=https://xxxxxxxxxxx/xxxxxxxx/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'


-- System Information:
Debian Release: 11.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-21-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cups depends on:
ii cups-client 2.3.3op2-3+deb11u2
ii cups-common 2.3.3op2-3+deb11u2
ii cups-core-drivers 2.3.3op2-3+deb11u2
ii cups-daemon 2.3.3op2-3+deb11u2
ii cups-filters 1.28.7-1+deb11u1
ii cups-ppdc 2.3.3op2-3+deb11u2
ii cups-server-common 2.3.3op2-3+deb11u2
ii debconf [debconf-2.0] 1.5.77
ii ghostscript 9.53.3~dfsg-7+deb11u2
ii libavahi-client3 0.8-5+deb11u1
ii libavahi-common3 0.8-5+deb11u1
ii libc6 2.31-13+deb11u5
ii libcups2 2.3.3op2-3+deb11u2
ii libgcc-s1 10.2.1-6
ii libstdc++6 10.2.1-6
ii libusb-1.0-0 2:1.0.24-3
ii poppler-utils 20.09.0-3.1+deb11u1
ii procps 2:3.3.17-5

Versions of packages cups recommends:
ii avahi-daemon 0.8-5+deb11u1
ii colord 1.4.5-3

Versions of packages cups suggests:
ii cups-bsd 2.3.3op2-3+deb11u2
pn cups-pdf <none>
ii foomatic-db-compressed-ppds [foomatic-db] 20200820-1
ii smbclient 2:4.13.13+dfsg-1~deb11u5
ii udev 247.3-7+deb11u1

-- debconf information:
cupsys/backend: lpd, socket, usb, snmp, dnssd
cupsys/raw-print: true

[Brian Potkin]

On Tue 28 Mar 2023 at 18:45:02 +0200, John Hughes wrote:

> Package: cups
> Version: 2.3.3op2-3+deb11u2
> Severity: normal
>
> Dear Maintainer,
>
> * What led up to the situation?
>
> I printed a page from firefox with a very, very long URL. Firefox used the first 255 bytes of the URL as the job name.
>
> * What was the outcome of this action?
>
> The job mysteriously didn't print. Lookin in the cups log (with debug on) I found the lines:
>
> D [28/Mar/2023:18:14:44 +0200] [Job 365] job-name nameWithoutLanguage 365 - https://xxxxxxxxxxx/xxxxxxxx/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> D [28/Mar/2023:18:27:36 +0200] [Job 369] Validate-Job: client-error-request-value-too-long (client-error-request-value-too-long)
>
> notice how the job name passed to cups ("https://xxx...") is shorter than 255 characters, but when the job number "365 - " is prepended it is longer tnan 255 characters and so overflows.
>
> * What outcome did you expect instead?
>
> That my print job be printed rather than just geting stuck in the print queue forever.
>
> How to reproduce:
>
> lp -o 'job-name=https://xxxxxxxxxxx/xxxxxxxx/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

Thank you for your report, John.

I think it would be better if you took this upstream:

https://github.com/OpenPrinting/cups/issues

Regards,

Brian.