Let "--disable-foomatic-rip-hplip" be default

Bug #1007367 reported by Till Kamppeter
This bug affects 2 people
Affects Status Importance Assigned to Milestone

Bug Description

Several years ago in the time when foomatic-rip was still 3.0.x, written in Perl, HPLIP started shipping an alternative foomatic-rip, named foomatic-rip-hplip to fix a bug in the opriginal foomatic-rip. This bug got fixed shortly afterwards and in foomatic-rip 4.0.x, written in C, it was fixed from the beginning. Therefore foomatic-rip-hplip is superfluous for most users nowadays, perhaps even for all as current HPLIP does not work any more with Linux distributions of the Foomatic-3.0.x age (not due to Foomatic, but because of other things).

In addition, foomatic-rip-hplip also breaks things. It does not only exclude HPLIP users from the further development of foomatic-rip, but it also is not compatible with modern printing environments, especially the PDF printing workflow for which foomatic-rip was introduced.

Now having several Linux distributions already using the PDF printing workflow (at least Debian, Ubuntu, and derivatives) and the PDF printing workflow getting required by the upstream projects from CUPS 1.6.x (due mid-2012) on building HPLIP with foomatic-rip-hplip breaks printing on most systems.

Therefore I want to ask you to at least make "--disable-foomatic-rip-hplip" the default to make HPLIP working out of the box for most users and allow using foomatic-rip-hplip only via an explicit "--enable-foomatic-rip-hplip" on the "./configure" command line. Or even do completely away with foomatic-rip-hplip.

CVE References

Revision history for this message
Johannes Meixner (jsmeix) wrote :

I suggest to remove foomatic-rip-hplip from HPLIP and
adapt the static PPD files in HPLIP to use foomatic-rip.

Some references:

See the related issue
the "printer prints raw pdf source instead of doc" mail thread on
the cups.general Newsgroup and <email address hidden> mailing list


What we (i.e. SUSE) currently do to get rid of foomatic-rip-hplip
from our RPM hplip.spec file (shortened):
# Because foomatic-rip-hplip has CVE-2011-2697
# plus a leftover in CVE-2004-0801
# foomatic-rip-hplip is no longer installed and foomatic-rip
# from the foomatic-filters RPM is used instead.
Requires: foomatic-filters
# For hpcups static PPD install one needs:
# --enable-hpcups-install enable hpcups install (default=yes)
# --disable-cups-drv-install enable cups dynamic ppd install (default=yes)
# --enable-cups-ppd-install enable cups static ppd install (default=no)
# For both hpcups and hpijs install with static PPDs one needs additionally:
# --enable-hpijs-install enable hpijs install (default=no)
# --disable-foomatic-drv-install enable foomatic dynamic ppd install
# (default=no), uses drvdir and hpppddir
# --enable-foomatic-ppd-install enable foomatic static ppd install
# (default=no), uses hpppddir
# --enable-foomatic-rip-hplip-install enable foomatic-rip-hplip install
# (default=no), uses cupsfilterdir
# ... foomatic-rip from foomatic-filters is used instead so that
# --disable-foomatic-rip-hplip-install is explicitly set and as a consequence
# the "cupsFilter" entries in the static PPDs are changed in the install
# section to use foomatic-rip.
./configure ...
# the "cupsFilter" entries in the static PPDs must be changed accordingly:
echo "Replacing insecure foomatic-rip-hplip with foomatic-rip in the PPDs..."
for p in *.ppd
do sed -i -e 's/foomatic-rip-hplip/foomatic-rip/' $p
# To be backward compatible with PPDs in /etc/cups/ppd/
# for existing print queues a compatibility link
# /usr/lib/cups/filter/foomatic-rip-hplip
# which points to foomatic-rip is installed:
ln -s ../../../bin/foomatic-rip %{buildroot}/usr/lib/cups/filter/foomatic-rip-hplip
An explanation why we use static PPDs:
We use intentionally static PPDs because I prefer when all PPD files
are instantly available radymade on the end-user's disk instead of
having any issue with run-time generation on the end-users system.
I prefer compile-time generation on our package build systems
(so that I can see when it fails) instead of run-time generation
on each particular end-user's system.
Furthermore it seems only static PPDs are future-proof according to
which reads that the concept of PPD files being generated on-the-fly
by programs placed in the /usr/lib/cups/driver/ directory
will be going away in a future release of CUPS.

Changed in hplip:
assignee: nobody → Sanjay Kumar (sanjay-kumar14)
status: New → In Progress
Changed in hplip:
assignee: Sanjay Kumar (sanjay-kumar14) → nobody
status: In Progress → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.