2015-06-04 11:12 GMT+02:00 Élie Roux <[email protected]>: >> 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
