[Kde-print-devel] [Bug 149546] New: KDEPrint should get into sync with CUPS 1.3.x developments and add support for all new 1.3.x features

[Kurt Pfeifle]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=149546         
           Summary: KDEPrint should get into sync with CUPS 1.3.x
                    developments and add support for all new 1.3.x features
           Product: kdeprint
           Version: unspecified
          Platform: SuSE RPMs
        OS/Version: other
            Status: NEW
          Severity: wishlist
          Priority: NOR
         Component: general
        AssignedTo: kde-print-devel kde org
        ReportedBy: pfeifle kde org


Version:            (using KDE KDE 3.5.7)
Installed from:    SuSE RPMs
Compiler:          irrelevant irrelevant
OS:                I Don't Know

[ This bug report should be seen in context with bug #13023 
                              (dealing with how KDEPrint is out of sync with CUPS 1.1.x) 
                              and bug #130425 (how KDEPrint is out of sync with CUPS 1.2.x)]
----------

KDEPrint has come totally out of sync with CUPS, which is now in its 1.3.x development circle. The cupsd.conf GUI control module is barely functional for admin purposes, and kprinter seems also suffering from heavy bit rotting, where users sometimes can't print without leaving their KDE environment....

Should at all anything happen with this bug report during the KDE4.x development cycle, it is desirable that the most important things be backported to 3.5.7+ (which may be used for still another 2-3 years in environments with large KDE rollouts).

Details
-------
There are 3 currently unsupported cupsd.conf 1.3.x parameters in KDEPrint:

  - ErrorPolicy       
  - GSSServiceName         # This means Kerberos support
  - DefaultAuthType

(You can read about their meaning if you install CUPS 1.3.x and visit http://localhost:631/help/ref-cupsd-conf.html?TOPIC=References&QUERY= )


Other important changes/additions to CUPS 1.3.x:
------------------------------------------------
  - DNS-SD (Bonjour/Zeroconf) Support: CUPS supports printer sharing via DNS service 
       discovery
  - Mac OS X Authorization Services: CUPS now supports the Authorization Services framework,
       providing role-based access control in addition to the tradition UNIX model (hey, 
       KDE4 is mean to play well with Mac OS X too, isn't it? I don't assume the KDE apps
       running on OS X are ported to use the OS X native print dialog, or are they?)
  - LDAP w/SSL: CUPS now supports also encrypted LDAP sessions
  - New CUPS_GET_PPD operation: allows to retrieve PPD files from the scheduler
  - Printer Defaults: attributs notify-lease-duration-default, document-forma-default, 
       notify-events-default can be set separately for each printer and class
  - Localized, multilanguage PPDs: CUPS introduced an extension to the PPD specification,
       where one and the same PPD can support/embed multiple languages and the user can
       be shown the language of his locale (not just English, as with most available PPDs
       right now)
  - New API functions: cupsAdminGetServerSettings() and cupsAdminSetServerSettings() [would
       be useful for "kcmshell printers"]


The most important single hole is this, IMNSHO (and it started to open with CUPS 1.2):
--------------------------------------------------------------------------------------

 * In CUPS 1.1.x you could only have cupsd.conf (one or more) statements like this (for 
   TCP/IP + UDP socket connections):

     Listen localhost:631
     Listen 10.162.7.8:21631
     Listen [::1]:631
     Listen *:631         # This one only, while no other is present


 * In CUPS 1.2.x support for unix domain socket connections was added (these ones work for 
   local printing only of course, and do speed it up, make it more comfortable, and more 
   secure), where you can add (or exclusively use) one statement like this:

     Listen /var/run/cups/cups.sock
     Listen /var/run/cups/whatevername.cupssock

   The socket device file will be automatically created by cupsd upon starting up, with the 
   correct permissions. Local authentication can then also be handled by automatically 
   generated certificates (something kprinter also doesn't seem to understand).

Unix domain socket will be used by any local printsystem client (these are, in the first place, the CUPS commanline utilities like lp, lpr, lpstat, lpoptions, lpadmin...) to connect to the local CUPS server if the env var CUPS_SERVER does not contain "localhost" or "10.162.7.8", but "/var/run/cups/cups.sock".

Now, users (or their admins) can of course configure their cupsd to *exclusively* use a unix socket (and hence, disallow any remote connection from *any* possible remote client, effectively blocking any possible DoS attack or worse. That may also disable the CUPS web interface, of course).

I dunno how current 3.5.7 kprinter and kjobviewer are behaving. Last I could look, it was completely non-functional for printing or job management if cupsd was set up like this.

At the very least, the KDEPrint UI should support the making a connection to a local cupsd via a domain socket. Look at the interface of

      kaddprinterwizard --kdeconfig
  --> go to "CUPS Server"

and notice how you can only set "host" and "port" (i.e. TCP/IP socket). This should have *both*, a "host:port" part and a "/path/to/whatever/sockfile" (unix domain socket) part to use (mutually exclusive, of course). When I tried to put the socket file path into the host field and keep the "port" field empty in the past (different consecutive releases of KDE 3.5.x), kprinter crashed...., or it interpreted the path as a hostname...., or it auto_added a port "0" or "631" to the env var (it tried to use CUPS_SERVER=/path/to/whatever/sockfile:631")...  In any case, it didn't print  :-(

I don't know if any of the more "security conscious" distros do use this setting as their installation defaults yet... but it would break KDE Printing completely.