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

[Chris Travers]

On Thu, Oct 20, 2011 at 8:25 AM, Peter Dyballa <Peter_Dyballa at web.de> wrote:
>
> Am 20.10.2011 um 16:54 schrieb Chris Travers:
>
>> One of the other commentors talks about documents that don't render on
>> all versions of TexLive.  If a client of mine is depending on this
>> working, upgrading the various stuff from CTAN in order to get a
>> security fix in an underlying program is a non-starter because it may
>> break things, just as it breaks other documents.
>
You wrote:
>> You're mixing up things! TeX is a set of a few binaries, some of them are the TeX engines (pdfTeX, XeTeX, LuaTeX, conTeXt). The majority of the TeX software are text files. If a change in a library is breaking the TeX engine, then the change itself is faulty. If you're using a TeX function (library call) of a future version of that software, then something has to fail. If you're using an old function (library call) that has been changed, then you can't assume something useful will happen to come out.<<

My reply:
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.

Think about it this way.  Suppose you are doing magazine layout in
LaTeX.....  You start with open ended problems.  You can pursue all
sorts of courses in solving them.  You want up to date packages which
have as few bugs that other people have run into as possible.  I think
we all agree on that.

However, suppose you have a piece of software that generates documents
in LaTeX.  This design is done once and thereafter it is run in a
predictable fashion.  Once you have done your testing, you can assume
that barring unexpected and invalid inputs on the part of a user, it
will function correctly forever.  Note the user here isn't writing
LaTeX documents.  The user is just doing data entry, so all input can
be sanitized of LaTeX commands.  Consequently, predictability is key
here, and the last thing you want done is to change the behavior
under the program just because another more important upgrade needs
it.  The needs in this environment are completely different from the
needs of the LaTeX user.

So what sorts of fixes does the latter environment need?  Well, let me
make up a hypthetical security vulnerability-- keep in mind this
software is not running on the user's system.  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.  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.

Hope this helps,
Chris Travers