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"
--------------------------------------------------
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
