<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 4, 2015 at 9:25 AM, Élie Roux <span dir="ltr"><<a href="mailto:elie.roux@telecom-bretagne.eu" target="_blank">elie.roux@telecom-bretagne.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">> Before we include any such .so, there should be an option in luatex<br>
> about loading .so's (maybe it already exists?), and the default has to<br>
> be off.  Otherwise our efforts at security are lost, so far as I can see.<br>
<br>
That's a difficult question...<br>
<br>
> Which means, it seems to me, that the feature is only useful for<br>
> particular users doing particular things, not for shipping stuff to be<br>
> used by everyone.<br>
<br>
It is useful for Windows users<br>
<br>
> As I understand it, ConTeXt gets the list of OS fonts by running a<br>
> script at install time, or really mtxrun --generate time.  I expect we<br>
> could figure out something similar for lualatex.  Ideally even re-using<br>
> the same file if it exists ...<br>
<br>
Sadly, Windows has a mechanism that stocks some installed fonts only in<br>
the registry, and not in a standard directory. Fonts installed this way<br>
are not handled by ConTeXt. There aren't many cases where users install<br>
fonts this way, but (AFAIK) the mechanism is quite recent and there<br>
might be more and more demand on this...<br>
<br>
There are currently two ways to access the registry in LuaTeX:<br>
 - loading a .so file that calls the Windows API (lua-winreg,<br>
lualatex-platform, etc.)<br>
 - calling the "reg" command<br>
<br>
The second is already forbidden by shell_escape_commands (which is<br>
good), and if you forbid the first one, this means that users will never<br>
be able to have all their fonts found by TeX.<br>
<br>
The only other way this could be dealt with would be through fontconfig,<br>
but fontconfig doesn't support the fonts in the registry, doesn't plan<br>
to, and making a patch is not easy (fonts not in a standard directory<br>
doesn't fit well with fontconfig architecture).[1][2]<br>
<br>
> Overall, I think just about any alternative -- a script, a system call,<br>
> a whole separate program, whatever -- is preferable to a .so.<br>
<br>
This means that all modules people need will have to be statically<br>
linked with LuaTeX? This seems a difficult choice, and I'm not sure the<br>
LuaTeX team is willing to do this... This will also forbid experiments<br>
with harfbuzz, etc. Maybe there could be a list of allowed extensions,<br>
that would respect openin_any and openout_any (lualatex-platform does,<br>
it doesn't read nor write any file), and also removing "." from CLUAINPUTS ?<br>
<br>
> They'd only be updated once a year, or more precisely when the binaries<br>
> are updated.  There is no miracle way to get them compiled on all<br>
> platforms on demand, and I don't want to impose repeated recompiling on<br>
> our builders (or manage such an effort).<br>
<br>
Ok<br>
<br>
> I also expect it will take<br>
> quite some effort to get figure out the first one.<br>
<br>
Indeed, hence my question...<br>
<br>
Thank you!<br>
<span><font color="#888888">--<br>
Elie<br>
<br>
[1]: <a href="http://lists.freedesktop.org/archives/fontconfig/2015-May/005510.html" target="_blank">http://lists.freedesktop.org/archives/fontconfig/2015-May/005510.html</a><br>
[2]: <a href="https://bugs.freedesktop.org/show_bug.cgi?id=90813" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=90813</a><br>
</font></span></blockquote></div><div class="gmail_extra"><br></div>The swiglib project <br><a href="http://swiglib.foundry.supelec.fr" target="_blank">swiglib.foundry.supelec.fr</a><br clear="all"><div>tries to address these problems.<br></div><div>My current opinion is to avoid to include dynamic shared object (ie so/dll files) in TeXLive</div><div>and  set  a path inside the TDS .</div><div>ConTeXt already has a mechanism to load dso</div><div>(see 3.1 Application module location in the TDS <a href="https://swiglib.foundry.supelec.fr/tb112/tb112scarso.html" target="_blank">https://swiglib.foundry.supelec.fr/tb112/tb112scarso.html</a>)</div><div class="gmail_extra">and it works quite well.</div><div class="gmail_extra">A command line switches as  --disable-write18  and --shell-restricted currently are not implemented </div><div class="gmail_extra">but could be in the future (luajittex is more problematic), </div><div class="gmail_extra">but even in this case loading a dso poses always a security problem.</div><div class="gmail_extra">Another point is that a dso usually it's not available for the all the platforms<br></div><div class="gmail_extra">and it can depend on lua version of luatex.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">if we keep the modules outside the TeXLive <br></div><div class="gmail_extra">then they are optionals --- i.e. the user chooses to install them --- </div><div class="gmail_extra">and the developer has the responsibility to fix the problems.</div><div><br></div></div><div class="gmail_extra"><br></div>-- <br><div>luigi<br></div>
</div></div>