bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #61423] [libgroff] allow paths in "name" directive of font descript


From: Dave
Subject: [bug #61423] [libgroff] allow paths in "name" directive of font description file, restoring historical groff behavior
Date: Mon, 8 Nov 2021 18:54:13 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Firefox/45.0

Follow-up Comment #10, bug #61423 (project groff):

[comment #9 comment #9:]
> The scope of _this_ ticket remains deciding between
> the 2 options above in `fp` request handling.
> 
> Whew.  I think I'm going to pour myself a drink.

I poured myself one and then lost the ability to follow 97% of that
explanation.

However, it seems to me the scope of this ticket is even more modest than
what's proposed above.  The resolution of bug #61424 seems to have closed the
security hole.  As long as .fp is disallowed from including pathnames, the
pathname part (if present) of the font description file's "name" directive can
(maybe?) be safely ignored, and only the basename portion compared
against...whatever it ends up getting compared against based on the choice of
the aforementioned option 1 or 2.

So I think for _this_ bug, the options are (I'll letter them so as not to
confuse them with the preexisting options 1 and 2):

A. Ignore the dirname part (if any) of the "name" directive;
B. Disallow a dirname within the "name" directive and (as is presently done)
treat the entire field as the font name to be matched against; or
C. Split the difference, keeping the current behavior but downgrading the
problem from an error to a warning, allowing the file to be processed but
letting the user know that that file no longer comports with the current font
description file spec.

Option B would mildly break back compatibility, but the present wording of the
error makes it easy for the user to zero in on the problem and fix it.  Option
A runs into the problem elucidated in comment #1 of different OSes using
different directory separators.

If there are other issues at play, they're lost in my fuzzy understanding of
the overall situation.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?61423>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]