[tex-live] [luatex] lltxplatform integration

[Zdenek Wagner]

2015-06-04 11:12 GMT+02:00 Élie Roux <elie.roux at telecom-bretagne.eu>:
>> The swiglib project
>> swiglib.foundry.supelec.fr <http://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 .
>
> Why not, but this means that if some documents rely on external
> libraries, users won't be able to compile them, especially under Windows
> where it requires very advanced knowledge to compile anything. So this
> means that LuaTeX will never be able to use harfbuzz, etc.  This means
> that if someone wants to experiment on harfbuzz (change harfbuzz for
> anything here) will have to fork LuaTeX, statically compile harfbuzz
> against it, and distribute "luatex-harfbuzz", same for all other useful
> libraries...
>
There are already experiments with luatex and harfbuzz:
https://github.com/michal-h21/luatex-harfbuzz-shaper
https://github.com/michal-h21/luatex-harfbuzz-shaper/blob/master/examples/scripts.pdf

>> 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.
>
> Loading dynamic libraries is currently quite easy indeed.
>
>> A command line switches as  --disable-write18  and --shell-restricted
>> currently are not implemented
>> but could be in the future (luajittex is more problematic),
>
> That would be helpful... But I suppose that mean that you'll have to
> link against -ltexlua (name to be defined) instead of -llua52, because
> linking against -llua52 will never provide kpse-restricted funtions
> right? That sounds reasonable...
>
>> if we keep the modules outside the TeXLive
>
> Does it mean ConTeXt users will have all the nice swig modules, while
> TeXLive users won't? Seems a bit unfair... This also means that TeXLive
> will have a reduced ConTeXt?
>
>> then they are optionals --- i.e. the user chooses to install them ---
>> and the developer has the responsibility to fix the problems.
>
> But this also means that the average user can't install them (installing
> such a thing under Windows is way beyond average Windows user's
> ability). Even distributing shared libaries for LuaTeX through luarocks
> and asking users to install them is, I believe, confusing for the
> average user...
>
The solution is to educate users. All security problems stem from
hiding important knowledge, offering security settings in a not
understandable way and pretending false security. If you offer an easy
access to potentially vulnerable or malicious libraries to uneducated
users, you are doin a misservice. For uneducated users reduced but
safe system is more valuable than a potentially vulnerable systems.
Thos who need higher functionality should understand the risk and
should be educated.

> Thank you,
> --
> Elie


Zdeněk Wagner
http://hroch486.icpf.cas.cz/wagner/
http://icebearsoft.euweb.cz