A message to the TeX Live list today states that the feature has been disabled (at least for the moment) for the reason you outline (bypassing openout_any-restrictions). So the it looks to me like the TeX Live team do take this kind of concern seriously.

Joseph

Concerning this being “low risk”: I agree that we probably won’t see any worms using this method, TeX is way too small for that. However, it might very well be used to launch an attack against a specific person (researcher). Knowing that only I, or a handful others, were attacked does not comfort me.

Concerning GUIs: it shouldn’t be very hard even now, just Google “name-of-your-gui shell-escape”.

To make it “automatic”, packages that require external binaries should include directives stating whatever they need, in some (yet to be specified) standard fashion. It could be a directive in the source, or a specially formatted error message (“pragma-need-binary: epstopdf OR eps2pdf”). The GUI would then ask the user if they want to allow binary X for this document, and if so recompile with –allowed-shell-commands=X (a new flag).

You seem to think that security issues are not real problems. I beg to differ. Didn’t macros in Microsoft Word teach us anything? Of course we can have both EPS-conversion and security. That’s why it is so very unfortunate that the present change makes TeX worse than the latest verison of Microsoft Word, from a security point of view.

If you look at the commits, you’ll see that the developers actually tried to only include “safe” binaries. Unfortunately, they failed miserably. If we are to allow any automatic execution of external binaries, it should only be for a small subset of binaries that are included in the distribution of TeX. Each program should do only one simple thing, to make it easy to audit.

For a single arbitrary file, you can overwrite with no warning without \write18 at all, just using TeX. After all, this is what LaTeX does with the .aux file (plus others). So there is no real difference in letting other tools that can write to a single file run. The worry is mainly real shell escape, such as “cd .. && rm -rf *” (on Unix, of course).

I’ve said before that the real risk of \write18 is pretty low (people wanting to do evil things usually find rather more general ways than via TeX)! So I personally feel the trade off here is worth it.

On thing you have to remember is most users rely on a GUI, and find it *very* confusing getting instructions like “Change the parameters sent to LaTeX to include -shell-escape”. Arguing that the GUI should add stuff automatically assumes that every GUI is updated to fit the scheme. What list you you go for in any case? One of the key reasons for this change is because using EPS graphics with PDF output is a *real* problem for many users.

Joseph

Looking at http://www.tug.org/svn/texlive/trunk/Master/texmf/web2c/texmf.cnf?view=markup it seems as if the “safe” commands are: bibtex, bibtex8, epstopdf, epspdf, fc-match, kpsewhich, makeindex, ps2pdf, pstopdf, rpdfcrop.

On my system “ps2pdf valid.ps any-file” will happily overwrite “any-file”, negating openout_any-restrictions, epspdf has a –psoptions flag whose argument appears to be added to the system() call unquoted (just had a quick look, might be wrong on that one), …

Instead there should be a flag –allowed-shell-commands=…, with the GUIs providing defaults that they consider sensible (perhaps based on the packages used).