There was a bug report at ghostscript.com: http://bugs.ghostscript.com/show_bug.cgi?id=691339 The problem is (from Use.htm#Finding_files in ghostscript documentation): When looking for initialization files (gs_*.ps, pdf_*.ps), font files, the Fontmap file, files named on the command line, and resource files, Ghostscript first tests whether the file name specifies an absolute path. If the test succeeds, Ghostscript tries to open the file using the name given. Otherwise it tries directories in this order: 1. The current directory (unless disabled by the -P- switch); 2. ... This is the problem, since it'll try to open font files, Fontmap files and etc... in the current directory first. Upstream suggested solution is to add -P- commandline option. It is possible to change default in ghostscript during build (set SEARCH_HERE_FIRST to 0 in Makefile.in), but at least debian went different road: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583183 What will we do? Review all affected packages and open bugs for them or change default. ATM I don't know reasons why people want SEARCH_HERE_FIRST enabled...
Ghostscript has been fixed to not search the current working directory any more and also honor the -P- option as of ghostscript >=9.00, see URL. http://ghostscript.com/doc/9.00/Use.htm#Finding_files If the test succeeds, Ghostscript tries to open the file using the name given. Otherwise it tries directories in this order: 1. The current directory if enabled by the -P switch; 2. ... "By default, Ghostscript no longer searches the current directory first but provides -P switch for a degree of backward compatibility."
@security: this can probably be resolved, see comment #1 and the fact that only version 9.0* is left in the tree...
Thanks, Andreas and Timo. This is CVE-2010-2055, which was already addressed in bug 332061, fixed with app-text/ghostscript-gpl-8.71-r6. *** This bug has been marked as a duplicate of bug 332061 ***
