[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>
wrote:

> > 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
swiglib.foundry.supelec.fr
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
https://swiglib.foundry.supelec.fr/tb112/tb112scarso.html)
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
platforms
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.


-- 
luigi
-------------- 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