[cups.bugs] [LOW] STR #2537: cupsd does not reject requests using invalid character sets
Jerome Alet
alet at librelogiciel.com
Thu Oct 11 04:31:43 PDT 2007
Hi,
On Wed, Oct 10, 2007 at 03:00:19PM -0700, Michael Sweet wrote:
> [STR Closed w/Resolution]
>
> Fixed in Subversion repository.
>
> As part of the fix, all of the convenience functions now use
> ippNewRequest(), which passes the locale language with UTF-8 for the
> charset. I've also removed all of the text filter's legacy character set
> files since no jobs will come in with anything other than US-ASCII or
> UTF-8...
I fear there's a mistake somewhere.
In your second comment about #2537 you wrote that "all command line
strings are transcoded on the client side from the locale charset
to utf-8 as needed".
By reading berkeley/lpr.c then cups/ipp.c (ippNewRequest and
ippAddString) I think it's wrong : the charset is FORCED to utf-8 in
ippNewRequest but the title is NEVER translated from user's charset
to utf-8.
This means that for example :
$ export LANG=fr_FR.ISO-8859-15
$ export LC_ALL=fr_FR.ISO-8859-15
$ lpr -t "ééé" myfile.ps
will be accepted by CUPS, despite both the user's and title's charset
(ISO-8859-15) being unsupported by CUPS. From what I understand from
my quick reading of the code, CUPS will receive the IPP request
from the lpr command with charset set to UTF-8, but the original
untranscoded title still in ISO-8859-15. With your recent changes
CUPS will check that the charset is supported and reject the job
if this isn't the case : this is GOOD ! But, the test will fail
because the title's charset and charset "forced" don't match : the
request charset will be correct from CUPS' point of view, but the
title won't be in that charset.
Am I wrong ?
bye
Jerome Alet
More information about the cups-devel
mailing list