[XeTeX] How to manually create the xelatex.fmt?

Peter Dyballa Peter_Dyballa at Web.DE
Fri Oct 21 15:44:05 CEST 2011


Am 21.10.2011 um 00:51 schrieb Chris Travers:

> I'm not the one mixing things up.  What I am saying is perhaps a bit
> different.  If you are tying the .sty upgrades to binary upgrades,
> then an upgrade in a binary requires .sty upgrades, and these can
> break document generation systems.

Neither me nor other TeX users are doing this. TeX is not producing more functions, eTeX, kind on an 8-bit extension of TeX, is stable, XeTeX the same. Only LuaTeX is in rapid development. And the macro (STY or CLS) text files.

> Suppose a vulnerability
> is found where if a user sends in a specific UTF-16 string and the
> software expects UTF-8, that it causes a buffer overflow somewhere
> (this can happen because UTF-16 strings sometimes contain null bytes
> while UTF-8 can still use null bytes as string terminators), and this
> allows an attacker to now run arbitrary code on the server.

In that case I'd use reasonable hardware. For example PowerPC based. Its stack is not executable. Or AMD hardware. Using a particular switch makes the stack unexec. I seem to remember that modern, maybe less stable versions of GCC allow this as well. They allow it in that very special case when *all* used dynamic libraries are compiled that way. (Is there any Linux offering this feature?) So also a little utility to check whether some eMail has arrived on my private IMAP or POP server would have to be compiled like this.

Or I'd use a reasonable OS, one with role based access control and without an almighty super-user. This means that would have to be a modern OS from this millennium.

>  Let's say
> furthermore that the problem isn't with LaTeX but with some other
> library it is linked to.  Now, if you are a LaTeX user, and on a
> workstation, then this is an important security fix, and there is
> little harm in updating everything in TexLive.  But if you are doing
> stuff on a server, this is a critical fix, and you definitely don't
> want to be updating unrelated stuff at the same time.

Here you can see how good it is that TeX, that not packaged by Linux distributors, uses static libraries and is self-contained. (Ex)Changing it has no impact on the system. It can continue to use the shared libraries with all the critical securities holes.

> 
> Hope this helps,

I hope the same.


BTW, it's usually possible to keep private copies of TeX in one's private area. Not the binaries, there really is no need doing so, only a few text files, some font files I bought, their MAP file fragments, and my MAP files. The search algorithm of TeX first looks into that private area, then it starts, if necessary, searching the system. And it does not search "the system" at once, it first looks whether there is a local preference, then it looks, if still necessary, into the chosen year's edition of TeX Live. That's the sane behaviour of TeX Live, similar the PATH variable of UNIX shells. I don't know how packaged Linux TeX works, whether it's possible to edit texmf.cnf files to alter this TeX's behaviour.

--
Greetings

  Pete

November, n.:
	The eleventh twelfth of a weariness.
		– Ambrose Bierce, "The Devil's Dictionary"




More information about the XeTeX mailing list