Follow-up Comment #12, bug #66419 (group groff): [comment #8 comment #8:]
> $ git diff
> diff --git a/font/devps/download b/font/devps/download
> index 3f77716b6..62d3c012b 100644
> --- a/font/devps/download
> +++ b/font/devps/download
> @@ -2,5 +2,5 @@
> # PostScript-name Filename
>
> Symbol-Slanted symbolsl.pfa
> -ZapfDingbats-Reverse zapfdr.pfa
> +ZapfDingbats-Reverse ./zapfdr.pfa
> FreeEuro freeeuro.pfa
>
> Before:
[...]
>
> Now:
>
> grops:<standard input>: fatal error: a '/' is not allowed in PostScript font
> file name: './zapfdr.pfa'
I am confused now! The ticket is about the restriction of including a path in
the download file, which you say was not intentional but was caused by some
sneakiness in grops, but the above example shows that the path is still being
rejected in the download file.
There is a difference between files which are groff resources, and files which
are system resources, postscript font files in particular are a system
resource and, as such, I don't see why including them in a document should be
considered unsafe and require a -U flag, if that is what is being considered.
The use of the type 3 postscript font as an example is a bit unfortunate,
since Rob has explained that he organises his fonts by project, so each
project has its own groff font directory, which can be specified by the -F
flag, and the download file in each project directory specifies the actual
postscript type 1 fonts required for that project, which are probably held
centrally and the projects which require the particular font have appropriate
entries in their download file. Please forgive me Rob if I have this all
wrong, but it does seem an eminently sensible way of including a system
resource into groff.
I think the proper way to "fix" this is to add a bool to font::open_file,
which, when set, allows paths in the given filename, so that when grops wants
to open the postscript font after reading the download file, it can do the
open call with the bool set, and all other calls to open_file can have the
bool unset. This would restore previous behaviour vis. paths in the download
file, but retain your desire to restrict path traversal when opening groff's
own resources.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66419>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
