[tex-live] [luatex] lltxplatform integration

luigi scarso luigi.scarso at gmail.com
Thu Jun 4 10:34:41 CEST 2015

On Thu, Jun 4, 2015 at 9:25 AM, Élie Roux <elie.roux at telecom-bretagne.eu>

> > Before we include any such .so, there should be an option in luatex
> > about loading .so's (maybe it already exists?), and the default has to
> > be off.  Otherwise our efforts at security are lost, so far as I can see.
> That's a difficult question...
> > Which means, it seems to me, that the feature is only useful for
> > particular users doing particular things, not for shipping stuff to be
> > used by everyone.
> It is useful for Windows users
> > As I understand it, ConTeXt gets the list of OS fonts by running a
> > script at install time, or really mtxrun --generate time.  I expect we
> > could figure out something similar for lualatex.  Ideally even re-using
> > the same file if it exists ...
> Sadly, Windows has a mechanism that stocks some installed fonts only in
> the registry, and not in a standard directory. Fonts installed this way
> are not handled by ConTeXt. There aren't many cases where users install
> fonts this way, but (AFAIK) the mechanism is quite recent and there
> might be more and more demand on this...
> There are currently two ways to access the registry in LuaTeX:
>  - loading a .so file that calls the Windows API (lua-winreg,
> lualatex-platform, etc.)
>  - calling the "reg" command
> The second is already forbidden by shell_escape_commands (which is
> good), and if you forbid the first one, this means that users will never
> be able to have all their fonts found by TeX.
> The only other way this could be dealt with would be through fontconfig,
> but fontconfig doesn't support the fonts in the registry, doesn't plan
> to, and making a patch is not easy (fonts not in a standard directory
> doesn't fit well with fontconfig architecture).[1][2]
> > Overall, I think just about any alternative -- a script, a system call,
> > a whole separate program, whatever -- is preferable to a .so.
> This means that all modules people need will have to be statically
> linked with LuaTeX? This seems a difficult choice, and I'm not sure the
> LuaTeX team is willing to do this... This will also forbid experiments
> with harfbuzz, etc. Maybe there could be a list of allowed extensions,
> that would respect openin_any and openout_any (lualatex-platform does,
> it doesn't read nor write any file), and also removing "." from CLUAINPUTS
> ?
> > They'd only be updated once a year, or more precisely when the binaries
> > are updated.  There is no miracle way to get them compiled on all
> > platforms on demand, and I don't want to impose repeated recompiling on
> > our builders (or manage such an effort).
> Ok
> > I also expect it will take
> > quite some effort to get figure out the first one.
> Indeed, hence my question...
> Thank you!
> --
> Elie
> [1]: http://lists.freedesktop.org/archives/fontconfig/2015-May/005510.html
> [2]: https://bugs.freedesktop.org/show_bug.cgi?id=90813

The swiglib project
tries to address these problems.
My current opinion is to avoid to include dynamic shared object (ie so/dll
files) in TeXLive
and  set  a path inside the TDS .
ConTeXt already has a mechanism to load dso
(see 3.1 Application module location in the TDS
and it works quite well.
A command line switches as  --disable-write18  and --shell-restricted
currently are not implemented
but could be in the future (luajittex is more problematic),
but even in this case loading a dso poses always a security problem.
Another point is that a dso usually it's not available for the all the
and it can depend on lua version of luatex.

if we keep the modules outside the TeXLive
then they are optionals --- i.e. the user chooses to install them ---
and the developer has the responsibility to fix the problems.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/tex-live/attachments/20150604/790e2438/attachment-0001.html>

More information about the tex-live mailing list