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.
Bloody typos! (When can we ever get a preview before finally committing a report or a comment to bugzilla?) Above first paragraph had a typo with a bug number. I should read: [ This bug report should be seen in context with bug #130423 (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 is obsolete, unmaintained and will never be revived. Closing all open bugs.