Inquiry regarding contributing a Rust-based package to TeX Live

luigi scarso <[email protected]> Sat, 7 Mar 2026 20:49:03 +0100
Newsgroups gmane.comp.tex.live
Message-ID <CAG5iGsASfY7HMcoL0-AKw0h02wY0Jz7CcpKm4eGjPaDv4PJHBw@mail.gmail.com>
While it's always possible to upload a package to CTAN that requires
--shell-escape and provides instructions on where to find
the other necessary resources,
I think that we're essentially talking about shared object plugins and
TeXLive.

This isn't new; many programs have plugins
or rely on external shared objects to add functionality or enhance existing
ones, and the advantages and disadvantages are well known.

Based on Karl's considerations, my own are:
1) It's possible to provide plugin management (e.g., a reference directory,
how to load a plugin, etc.)
-- in short, an infrastructure -- but this shouldn't force TexLive to
provide plugins, nor change its security approach;
2) It makes sense to consider a TexLive "affiliate" site, a plugin
repository that follows TexLive's evolution.

Speaking only of luatex /luahbtex, and from a plugin perspective, there are
two options:

1) luaffi:
Pros: a lua binding file
Cons: luaffi is not officially supported by Lua, and I personally recommend
it only in specific cases. Furthermore, it presents the security issues
already mentioned;

2) the canonical route (hence  two shared objects: the binding and the
plugin) :
Pros: It's the most secure route
Cons: It requires compiling the binding
In this case, even if it were possible to modify luatex to load a plugin
without enabling --shell-escape, the security issues remain (bugs that
create
segment faults, malicious plugins, etc.) -- common to all programs that use
plugins, and a problem with a plugin is not a problem with the program
unless it is officially distributed with the program itself.

I think bugs can be reduced if the binding is compiled using SWIG (which
handles the Lua <-> C part) and if the plugin is in Rust and pays
particular attention to the Rust <-> C part. Rust should have the advantage
of making it (much?) easier to compile the plugin for multiple platforms,
but if the binding is in C, this advantage is not exploited (with luaffi,
however, it is).

For the record: in TexLive 2026, ConTeXt Mkiv still features some plugin
examples with luaffi (sqlite) and swig. The latter was archived 10 years
ago and is no longer supported by Mkiv, but the concept remains valid.


--
luigi