[tex-live] epstopdf.sty 2008 vs 2009

Heiko Oberdiek oberdiek at uni-freiburg.de
Fri Aug 14 13:14:06 CEST 2009

On Fri, Aug 14, 2009 at 11:00:50AM +0200, Manuel Pégourié-Gonnard wrote:

> Heiko Oberdiek a écrit :
> > 
> > If theses programs should be part of the list, then
> > the code that checks the program call could add a check
> > for (Perl pattern):
> >   \w--?shell-e
> > * Options can start with one or two hyphens.
> > * Options can be abbreviated. Because of "-shell-restricted"
> >   the shortest variant is "-shell-e".
> > * -no-shell-escape is ok.
> I was think of using a small Perl wrapper called rtex for restricted TeX, which
> would do the necessary checks and launch the engine. We could either create
> symlinks rpdftex, etc to it of make it use a syntaxe like
> rtex pdftex -options file

Good idea.

> The drawback (with both approaches btw) is that it requires changes at the macro
> level.

At macro level there are many open issues:
* How does a macro knows, whether a program is available and
  is allowed to be executed?

  In case of (r)pdfcrop I solved it by adding a new option --version to
  (r)pdfcrop and calling the program:

  % find pdfcrop
    \endlinechar=-1 %
    \openin\@unused="|rpdfcrop --version"\relax
      \read\@unused to \x
    \ifnum\pdfmatch{^[0-9]+\string\.[0-9]+$}{\x}=1 %
      \openin\@unused="|pdfcrop --version"\relax
        \read\@unused to \x
      \ifnum\pdfmatch{^[0-9]+\string\.[0-9]+$}{\x}=1 %
        \ifx\x\@empty % old version of pdfcrop
          \@latex at error{Cannot find or execute (r)pdfcrop}\@ehc

  But each program needs different treatment.
  Also many programs don't have a nice --version or --help option.
  Or they print on STDERR.

* How to catch STDERR (independent from OS)?
* Or how to detect OS?

With a sufficient solution a package could be written that
hides the low level trouble from package authors and users.

> > b) Arbitrary command calls must not be allowed. That requires
> >    that each program that wants to be added to the allowed list
> >    must be checked/audited/discussed, whether this is possible.
> Except for the various TeX engines, are their other programs in the list
> likely to allow execution of arbitrary commands in any way to the best of
> your knowledge?

* dvips allows the execution of external commands, intended for
  image conversions. At least -R1 is needed.
* mkgrkindex because of the two argument form of function "open".
  The input file name can be misused as pipe for example.
  AFAIK these calls should be replaced by the three argument form
  or at least use "<" in front of the input file name.
* imgconvert/ImageMagick. Programs can be configured using
  a delegates.mgk file. It would be found in
  $HOME/.magick/delegates.mgk or ./delegates.mgk
* ps4pdf: It calls an unrestricted "latex", for example.
* pygmentize?: What about the filter feature?
* texindy, xindy?: What about their module feature?
* epstopdf, epspdf, rpdfcrop must at least guess the
  ghostscript name and rpdfcrop allows many ghostscript names
  that matches a pattern.
BTW, I still get an error calling `ulqda':
Can't locate Digest/SHA1.pm in @INC

> > c) Writing files: Except for TeX programs external programs
> >    don't know about `openout_any' or `openin_any'. Thus they
> >    are able to write their results in any place that the
> >    operating system permits. This is the price of restricted
> >    mode. At least it should be impossible to write arbitrary
> >    files. Settings of openout_any or openout_in aren't
> >    necessarily inherited. Care is necessary, e.g.
> >    texmf.cnf allows "openout_any=a", but `etex' is called
> >    with environment variable "openout_any.etex=p", but the
> >    called program is `pdfluatex' ...
> > 
> I think we should just accept and document that. I can't see any realistic way
> to circumvent it.

At least it shouldn't be possible to write arbitrary files.

Yours sincerely
  Heiko <oberdiek at uni-freiburg.de>

More information about the tex-live mailing list