[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 mailing list