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

Herbert Schulz herbs at wideopenwest.com
Fri Oct 21 01:07:30 CEST 2011


On Oct 20, 2011, at 5:51 PM, Chris Travers wrote:

> 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


Howdy,

I'm not at all sure I understand what you're getting at but I'm interested in understanding it. Can you give an example where something like what you hypothesize in the last paragraph has happened with the binaries or packages supplied with TeX Live?

Another thing I don't is that you refer to LaTeX as library that one links to while I've always just considered it as a macro packages that builds upon the ~300 or so built-in low level commands supplied by TeX (and other engines that pass the trip test) to build a higher level language closer to the way people deal with documents.

Good Luck,

Herb Schulz
(herbs at wideopenwest dot com)






More information about the XeTeX mailing list