On Wed, Sep 23, 2026 at 09:01:58PM +0100, Gavin Smith wrote: > On Wed, Sep 23, 2026 at 09:32:11PM +0200, Patrice Dumas wrote: > Could texi2any issue a warning if there is a directory component in the > @setfilename argument?
I would be ok in principle, but not if it is used by the emacs manuals. > Do you know if the Emacs build system relies on > @setfilename (you said in another email it was "unused") or do they use -o? They use -o systemactically in their build system, both in the Makefile.in and in the code generating the online manuals. Therefore, the build system does not rely on the path in @setfilename. However, having the same leading directory used in the Makefile like "-o dir/file" as in "@setfilename dir/file" ensures that a plain makeinfo manual.texi puts the Info file in the same place as the Makefile use would do. > There could be a valid reason to have a directory component, but file names > beginning with .. or which are absolute (beginning with /) do seem dangerous > (as I said in the recent email thread about copying images for HTML output) > -- this could be used by a malicious actor to overwrite files, for example. > (I'm not aware of this happening in practice or any specific exploit, though.) In my opinion, it would be better if a directory component in @setfilename was ignored. In my opinion, it would be ideal if @setfilename was ignored unless the Texinfo file is read from standard input. We have to maintain backward compatibility, but I would be in favor of deprecating @setfilename except for that specific use. -- Pat
