<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 8 Mar 2024 at 23:52, Karl Berry <<a href="mailto:karl@freefriends.org">karl@freefriends.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I think that's the wrong behaviour to be honest: I think that files<br>
should be listed but not opened<br>
<br>
What good can come of being able to list dot files in restricted mode?<br>
Just seems like it makes it easier for bad guys.<br></blockquote><div><br></div><div>well it's just that we added a --all option and if documenting it it would be nice to say its</div><div>like ls and ls -a but if the .files have to vanish depending on openin_any documenting that's a bit weird</div><div>I suppose it could work to say if openin_any is not a then --all is no-op so perhaps that's OK</div><div>There's probably not any actual use case for listing such a file from tex if you have configured tex not to read</div><div>them so it doesn't really matter much in practice, as long as the end result is documentable</div><div>(except I think reading . should always be allowed)<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
But I don't feel absolutist about it. I won't reject adding l3sys-query<br>
to shell_escape_commands if you allow listing dot files :).<br>
<br>
always \input ./foo.tex<br>
. isn't a "dotfile" in that sense.<br>
<br>
No argument. Up to Nicola if she wants to change anything.<br>
Lacking user requests, if it were me, I probably wouldn't :).<br>
<br>
to allow \input{|ls "*.tex"} at least. <br>
<br>
Agreed in theory, but I'm not sure if there's any practical way for the<br>
quoting code to know the input is coming from a braced argument. <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Or in fact _any_ syntax that<br>
worked the same way in restricted and unrestricted shell escape.<br>
<br>
Agreed in theory, but the quoting code around shell escape is so<br>
tangled, and with so many Windows vs. Unix vs. engine special cases,<br>
that I fear to make any changes to it, ever.<br></blockquote><div><br></div><div>Yes I thought you'd say that, it's been that way for ages and changing things </div><div>would be tricky (certainly I wouldn't suggest you change anything for 2024).</div><div>We can probably work around it but as you might guess trying to package a command<br></div><div>for a user specified file listing that works reasonably plausibly in windows and linux and</div><div>restricted and unrestricted mode is "interesting". I had read those quoting rules in a previous lifetime</div><div>but still developing the script using --shell-escape until we were happy with it, then locally adding it</div><div>to the safe list and finding it doesn't work _at all_ in restricted mode as all the quotes vanished</div><div>was somewhat frustrating:-) But it mostly works again now so it's just a bit weird not a show stopper</div><div>and we are not asking for tl2024 engine changes to argument quoting</div><div> (Although there's a separate related question re texlua file globbing Joseph asked on the luatex list)<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
(web2c/lib/texmfmp.c, shell_cmd_is_allowed, normalize_quotes, etc.)<br>
<br>
Definitely can't make any changes in this area for this year, anyway.<br>
Any changes would have to start by making a comprehensive test suite for<br>
it, which would take considerable time in itself. (And which "should"<br>
have been done during development of the feature, but ... you know ...)<br>
<br>
Thanks/sorry,<br></blockquote><div><br></div><div>No need to apologise, I think it can all be made to work, and possibly even be useful it's just tex being tex:-)<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Karl<br>
</blockquote></div></div>