On 6/4/2015 9:25 AM, Élie Roux 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...
Speaking for context, I am not that interested in fonts that are
installed in fuzzy locations. When I use font from the system (which is
rare) I copy it to the tex/texmf-fonts tree of context so that I can be
sure that it only changes when I want that. When I need fonts for a
project I tend to buy the official versions (often one can then use some
5 copies on different machines i.e. other operating systems). I make
sure that my stuff works on windows (that I use on workstations) as well
as linux (on the servers that we use for running services).
So, it is quite unlikely that the file locator that context uses will
consult the registry. If I really have to I'd probably use the
commandline method and not a library (for which i need to keep up with
some api).
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.
Afaik users can configure what programs can run.
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 ?
In fact, we might make some of the current modules dynamic loaded.
Personally I will only rely on an as small as possible set of libraries,
basically the tex kernel (luatex 2 might even be a real small kernel.)
With the swiglib project we aim at a predictable mechanism that can be
used for all platforms.
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!
--
-----------------------------------------------------------------
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
| www.pragma-pod.nl
-----------------------------------------------------------------
