Re: [bug-gv] Re: Security issues

[paul . szabo]

Bernhard R. Link <address@hidden> wrote:

> There might be issues with the pdf2dsc script, but gv is not using it,
> gv is giving gs the pdf2dsc.ps file without path. This is an issue of
> gv.

Should not gv use the provided pdf2dsc script, instead of relying on
"internal" gs bits? (The gs people might re-design the whole thing, not
use a single pdf2dsc.ps file or just rename that.) If gv relies on
internals, then it might as well keep track of installed gs version.

>> Is not it sufficient to ...
>> exec "$GS_EXECUTABLE" -q -P- -dNODISPLAY -dSAFER -dDELAYSAFER\
>>     -sPDFname="$pdffile" -sDSCname="$dscfile"\
>>     /usr/share/ghostscript/8.62/lib/pdf2dsc.ps -c quit
>> (or somesuch)?
>
> If you give an explicit path to the pdf2dsc.ps then it makes no sense to
> have "$GS_EXECUTEABLE" configurable. ...

Yes, that is exactly what I meant by "somesuch".

> ... Even worse, you need to get that
> path at runtime, otherwise gv will not longer work when you upgrade
> ghostscript. Thus I think it might be better to have some
> GV_LIBDIR/pdf2dsc.ps which simply contains something like
> | % find pdf2dsc.ps installed and execute that.
> | % This way the correct one for the running gs is used...
> | (pdf2dsc.ps) runlibfile
> Which should always get the pdf2dsc.ps that belong to the ghostscript
> interpreter used. Though someone with working -P- should test that.

Yes, it would be good if gs was "properly" designed. Still, gv should
not use "gs internals" but only provided/supported interfaces. (Maybe
copy/steal that file, and have it as part of gv?)

Cheers, Paul

Paul Szabo   address@hidden   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of Sydney    Australia