Some TeX Developments

Security in computer programs is always an issue, with the balance between ease of use and security never being a simple black and white line. There’s a very interesting paper, being presented at an upcoming conference, about TeX security issues. This is particularly significant to MiKTeX users, as it’s led to a change in how MiKTeX implements certain features.

One of the well-known security questions with TeX is whether to enable \write18, and as a result this is off by default in TeX Live and MiKTeX. Another area that is of obvious concern is the \openout primitive, which allows writing a new file and could therefore be used for undesirable purposes. Of course, this functionality is also important: writing to files is how LaTeX manages a whole range of automated cross-referencing. So there is a balance to be struck: we need \openout, but not at any cost.

The TeX Live team have taken the attitude that \openout should be able to write within the current directory structure but not outside of it. This can be seen with a couple of very similar plain TeX test files. If you try

\newwrite\mywrite
\immediate\openout\mywrite test/test.xxx
\bye

then everything will be fine and the test file will be created. On the other hand

\newwrite\mywrite
\immediate\openout\mywrite ../test.xxx
\bye

will raise an error. The behaviour with MiKTeX was to allow both (and also absolute paths, etc.). That has now been altered, so that MiKTeX behaves in the same way as TeX Live (at least, that’s what it looks like in my tests).

Reading the MiKTeX lists, the new behaviour is causing issues because LaTeX’s \include relies on \openout. Quite a lot of MiKTeX users have been doing things like:

\include{C:/Users/<user>/My Documents/Chapters/chapter1.tex}

or

\include{../Chapters/chapter1.tex}

which used to work and now does not. There is a setting which enables the old behaviour, but it’s not really to be recommended, I think. So users will have to rearrange their input a bit to reflect the new more secure approach.

There are some other interesting points in the paper on TeX security. One is that making a truly secure LaTeX implementation (to use as a web service) is basically impossible. The MathTran site gets mentioned as the most secure TeX web service: it uses a specially hardened version of plain TeX, with no access to things like \csname, \catcode and so on to make it secure. For LaTeX, that is probably not possible (at least with LaTeX2e). Worth reading, but for those of us who just use TeX on our own computers not quite so immediately relevant.

I was talking to someone at work recently, and the topic of whether to choose MiKTeX or TeX Live on Windows came up. With MiKTeX 2.8 released and TeX Live 2009 due out any day, I thought I’d make a few comments.

First, both systems are very capable, so there is not really a “wrong” decision. However, when installing you do have to pick one. In the past, MiKTeX was the best choice for Windows by a distance, but recent work on TeX Live has altered this. So I’d say there are some factors to balance against each other.

• If you work on Windows and on Unix, then TeX Live is the system to favour. It preforms essentially in the same way across platforms, whereas you’ll get some minor differences if you use MiKTeX on Windows and TeX Live on Unix.
• If you want to only install what you use, go for MiKTeX. TeX Live doesn’t have anything to match the auto-installation system in MiKTeX.
• On the other hand, if your happiest installing everything in one go, go for TeX Live. It does this by default, and includes any new packages when you do an update. For MiKTeX, a full installation is something you have to do deliberately.

As you’ll see, there is not much in it! I’m mainly using TeX Live, but still have MiKTeX around as well.

One issue a lot of people find confusing with (La)TeX is the rules about which types of graphic files work with which engines. EPS files are fine when going via the DVI route, but do not work with direct PDF creation. The solution is to turn the EPS files in PDFs, and the problem goes away. However, there is then the question of how to do the conversion.

For most documents, having to convert every file by hand is not a sensible choice. The next nearest thing is the epstopdf package, which will do the same thing but from within a LaTeX run. However, it needs \write18 enabled, and this is not always desirable. More importantly, a lot of people who struggle with the graphics problem do not know how to turn on \write18 anyway. A good way around has been added to the latest version of TeX Live, which is currently in the final testing stages. TeX Live 2009 has some restricted \write18 functions enabled as standard, and also has a version of epstopdf “built in”. The result is that EPS files are automatically converted to PDF files, in a transparent manner. Of course, this only happens if the PDF does not also exist! At the moment, this feature is not in MiKTeX 2.8, so it is one reason to favour TeX Live 2009 even on Windows.

There are places where epstopdf will not help: for example, when using psfrag or pstricks. There, the best solution will either be auto-pst-pdf or pstool. Both are written by Will Robertson, and both need \write18 enabled to work. pstool is more efficient (it only re-creates graphics as needed), but for some cases on auto-pst-pdt will work. Will has documented both packages very well, so the best way to learn about them is to have a read of the documentation.

A quick note to say that MiKTeX 2.8 was released on Tuesday. As I’ve already posted, the two points to note in the new version are the inclusion of TeXworks and better support for multi-user systems. There seem to be one or two teething issues, but I’m sure they’ll soon be solved.

As I posted earlier, the upcoming releases of both MiKTeX and TeX Live have very similar sets of features on Windows. I’ve just stumbled upon something that points up the slight differences that exist, even though this one is a bit complicated.

To detect what system is being used, for things like shell escape tricks, there is a LaTeX package called ifplatform. However, this only works on Windows if MiKTeX is being used. The reason is that while TeX Live aims to be as similar as possible across platforms, MiKTeX can adopt a different approach and stick to Windows conventions. Most of the time, this is transparent but it shows up if you use the -shell-escape option for either system and try to do some testing. Inside ifplatform, you’ll find the lines:

\edef\ip@sig{write18-test-\the\year\the\month\the\day\the\time}
\edef\ip@win{'\ip@sig'}
\immediate\write18{echo \ip@win >"\ip@file"}

The idea is that the text written to the temporary file will be different on Windows to on a Unix-like system. MiKTeX will retain the single quotes around the test data:

'write18-test-20098231074'

whereas Unix-like systems will not:

write18-test-20098231074

But try using ifplatform with TeX Live on Windows and the test fails. First, no test file gets written at all: a bit of hacking leads to the change of the write line to

\immediate\write18{echo \ip@win > \ip@file}

and then at least the first step works. However, the test file now looks like a Unix one (with no quote marks), and ifplatform gets things wrong. So for the moment the only thing to do is create a stub package file and use it, something like:

\ProvidesPackage{ifplatform}[2007/11/18 v0.2  Testing for the operating system]
\newif\ifshellescape\shellescapetrue
\newif\ifwindows\windowstrue
\newif\ifmacosx
\newif\iflinux

I’ve reported the problem to Will Robertson, and hopefully a solution which really tests the OS rather than the TeX system can be found. However, it is a reminder that even with very general feature sets, the two major TeX distributions still act differently in some respects when used on Windows.

Both MiKTeX and TeX Live have new versions in the offing. I’ve been testing out both MiKTeX 2.8 and TeX Live 2009, to keep up to date with what is happening. In the past, I’ve tended to stick with MiKTeX as it is designed for Windows, and so can make some platform-specific decisions and be more focussed. However, the TeX Live team have done a lot of work to make TeX Live usable across platforms, and there are advantages to that approach.

Looking through the feature lists, a lot of the new features are common to the two systems, for example:

• TeXworks installed as a distribution-maintained editor.
• XeTeX version 0.9995 (which includes the new primitives that the LaTeX3 team asked for).
• Some \write18 functions enabled without turning on full \write18 support: this is used to allow “safe” functions.

There are, of course, also differences. For example, only TeX Live includes LuaTeX at present. I also notice that MiKTeX 2.8 is adding the full path of files to the log, whereas in the past you got the relative path. I’m not so sure this is a good idea: it makes things rather wordy, and also the log will vary between systems: not so great. On the other hand, MiKTeX 2.8 does provide user-specific texmf directories. For multi-user systems, this is a real bonus: you can use the auto-install system without needing to be the Administrator.

As I said, I’ve tended to use MiKTeX to date as it’s been the best “fit” on Windows. The latest version of TeX Live makes this a pretty tight call, I think. If you are happy installing a full TeX system (which I do), then there is very little in it. MiKTeX still has the edge for small installations, as the auto-install system really pays off there.

Jonathan Kew has produced new binaries for TeXworks for both both Windows and MacOS X. The ZIP file now contains everything you need to download in one place, which makes installation that bit easier.

On a somewhat related matter, I see that MiKTeX 2.8 is going to include TeXworks, including setting up file associations (.tex and .sty). As TeX Live 2009 is also coming with TeXworks, getting hold of the programme should become very easy for end users. This can only be a good thing.