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/