Bug in luatex handling of hidden dirs in TEXMFVAR

[Vincenzo Mantova]

Hi all,

Wouldn't it make sense for LuaTeX, or kpathsea in general, to convert
the paths in the various TEXMF* variables to absolute paths before
actually using them?

If I understand the security model, the variables are trusted, so this
would be fine to do, and it would resolve the issue without
introducing special cases.

Best,
Vincenzo


On Mon, 10 Nov 2025 at 18:01, Carlos <linguafalsa at gmail.com> wrote:
>
> On Sat, Nov 08, 2025 at 02:03:19PM +0000, Ben Price via tex-live wrote:
> > Thanks both,
> >
> > On Thu, Nov 06, 2025 at 05:26:07AM -0700, Max Chernoff wrote:
> > > This is caused by a LuaTeX engine change in TeX Live 2024. This is
> > > documented in the TeX Live change log with the rather cryptic
> > > description
> > >
> > >     LuaTeX:
> > >     - Lua-level checks for writing to files now similar to the TeX-level
> > >       checks.
> > >   ...
> > > §7.3 of the kpathsea manual expands on this a little more:
> > >   ...
> >
> > Oh I see, that is a bit cryptic!
> >
> > > If you've explicitly set $TEXMFVAR to a value beginning with a dot,
> > > arguably, that should override the "no filenames beginning with a dot"
> > > security restriction. But this is a fairly uncommon configuration, so
> >
> > Probably explicitly setting $TEXMFVAR is uncommon, but when restricting
> > to these cases, I expect setting it to a filename beginning with a dot
> > to be fairly common. It is pretty standard for cache directories to be
> > named `.cache` or similar;
>
> > indeed, the default luatex-cache directory
> > lives under (the absolute path) `$HOME/.texlive2025/texmf-var` (at least
> The more I try to wrap my head around it, the less and less I seem to understand the so called cache directories. Since when is it the above an absolute path to TEXMFSYSVAR? Quick answer: nunca, never, jamás. To a variable named $HOME? That's certainly far from being absolute.  Relative? sure. But I never bothered (except maybe while doing a standalone context installation on setting up the cache directory. It defaults to a subdiretory under a variable at all times. Defaults.
>
> The real work is being done by the SYSVAR and not the VAR regardless. And it all boils down to TEXMFDBS So to to that extent is not important really. And as far as I can understand this issue,  it seems to revolve around a dot filename here, but I have to admit I can't get to comprehend what the underlying problem here is especially since the main cause lies on an sty file spitting up an error?
>
> anyway. Never mind. I just read the part about the absolute path and couldn't hold it up. So I replied. It ain't absolute.
>
> > on my system).
> >
> > > while I'm pretty sure that making this change wouldn't cause any
> > > security issues, it might not be worth the risk of accidentally
> > > introducing another security vulnerability when modifying the filename
> > > parsing code.
> >
> > On Thu, Nov 06, 2025 at 03:31:54PM -0700, Karl Berry wrote:
> > >     If you've explicitly set $TEXMFVAR to a value beginning with a dot,
> > >     arguably, that should override the "no filenames beginning with a dot"
> > >
> > > Arguably. But since the workarounds are so easy, I don't much want to
> > > make yet another special case in the code for it and, as you say, risk
> > > introducing bugs. --thanks, karl.
> >
> > I agree that it is not worth introducing a special case here.
> > I do wonder whether it would be easy to improve the error message here
> > to reference the documentation.
> >
>
> --
> Even bytes get lonely for a little bit.
>