[bug #61423] [libgroff] allow paths in "name" directive of font description file, restoring historical groff behavior

Update of bug #61423 (project groff): Severity: 3 - Normal => 4 - Important Item Group: Feature change => Documentation Status: Need Info => In Progress

[bug #61423] [libgroff] allow paths in "name" directive of font description file, restoring historical groff behavior

Update of bug #61423 (project groff): Severity: 5 - Blocker => 3 - Normal Planned Release:None => 1.23.0 ___ Reply to this item at:

[bug #61423] [libgroff] allow paths in "name" directive of font description file, restoring historical groff behavior

Follow-up Comment #19, bug #61423 (project groff): I'd like to note the following recent commit, which should make it really obvious when shenanigans like my "bogusfont" example are attempted. https://git.savannah.gnu.org/cgit/groff.git/commit/?id=95bff60198eafc9f0ee326ad9f961b0528ec9610 __

[bug #61423] [libgroff] allow paths in "name" directive of font description file, restoring historical groff behavior

Update of bug #61423 (project groff): Severity:1 - Wish => 5 - Blocker ___ Reply to this item at: ___ Messag

[bug #61423] [libgroff] allow paths in "name" directive of font description file, restoring historical groff behavior

Follow-up Comment #18, bug #61423 (project groff): [comment #17 comment #17:] > One question of comment #14--whether the tightening of the scope of the font file's "name" directive should appear in NEWS--is also pending. > > This change could also be highlighted in the next rc announcement as one

[bug #61423] [libgroff] allow paths in "name" directive of font description file, restoring historical groff behavior

Follow-up Comment #17, bug #61423 (project groff): I'm willing to retract the current summary based on subsequent discussion. Comment #13 codifies the decision made of the options outlined in comment #10, and I'm on board with that choice. There still seem to be a design decision and some specif

[bug #61423] [libgroff] allow paths in "name" directive of font description file, restoring historical groff behavior

Update of bug #61423 (project groff): Severity: 2 - Minor => 1 - Wish ___ Follow-up Comment #16: Setting severity to "wish" as the advisability of the change as currently summarized ("allow path

[bug #61423] [libgroff] allow paths in "name" directive of font description file, restoring historical groff behavior

Follow-up Comment #15, bug #61423 (project groff): [comment #12 comment #12:] > So if groff now disallows a path here, afmtodit ought to at > least squawk if the user asks for one, if not omit it entirely. Bug #62150 ___ Reply to this item

[bug #61423] [libgroff] allow paths in "name" directive of font description file, restoring historical groff behavior

Follow-up Comment #14, bug #61423 (project groff): [comment #13 comment #13:] > Would you agree that the present behavior of groff in Git > conforms to your option B? Yes. And, if I'm understanding correctly, also to your option 1. > No one has raised Cain about this (or even uttered a peep in

[bug #61423] [libgroff] allow paths in "name" directive of font description file, restoring historical groff behavior

Follow-up Comment #13, bug #61423 (project groff): [comment #12 comment #12:] > [comment #11 comment #11:] > > if we do, it suggests another bug report needs to be filed > > against whatever tool is putting full paths there. > > The (good? bad?) news is that this tool is part of groff: afmtodit.

[bug #61423] [libgroff] allow paths in "name" directive of font description file, restoring historical groff behavior

Follow-up Comment #12, bug #61423 (project groff): [comment #11 comment #11:] > if we do, it suggests another bug report needs to be filed > against whatever tool is putting full paths there. The (good? bad?) news is that this tool is part of groff: afmtodit. All my font description files produc

[bug #61423] [libgroff] allow paths in "name" directive of font description file, restoring historical groff behavior

Follow-up Comment #11, bug #61423 (project groff): [comment #9 comment #9:] > I think option #2 would be more in line with what Dave was already doing. I wasn't _doing_ anything at all with that directive line. I wasn't supplying a path to any parameter of my .fp calls; the files in question all

[bug #61423] [libgroff] allow paths in "name" directive of font description file, restoring historical groff behavior

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 th

[bug #61423] [libgroff] allow paths in "name" directive of font description file, restoring historical groff behavior

Follow-up Comment #9, bug #61423 (project groff): This ticket appears to have turned over a very old rock with some very ugly creatures living beneath it. It appears that the argument to the `name` directive isn't necessarily a file name. It's an "external name". Both CSTR #54 and existing _gro

[bug #61423] [libgroff] allow paths in "name" directive of font description file, restoring historical groff behavior

Follow-up Comment #8, bug #61423 (project groff): [comment #7 comment #7:] > 61324 concerns changing only a tmac file, so you presumably intended 61424 here? Yes, indeed--thanks, Dave. And in my email to the list I started out okay but then my brain derailed and I started calling the font descr

[bug #61423] [libgroff] allow paths in "name" directive of font description file, restoring historical groff behavior

Follow-up Comment #7, bug #61423 (project groff): [comment #3 comment #3:] > I can do something unpleasant in groff 1.22.4, so I'll open > a separate, higher-severity ticket for that. That's bug #61424, for those following along at home. [comment #4 comment #4:] > So in addressing bug #61324 I'

[bug #61423] [libgroff] allow paths in "name" directive of font description file, restoring historical groff behavior

Follow-up Comment #6, bug #61423 (project groff): Yeah, I also hadn't considered pathnames in .fp requests when I opened this change request. If there's a good security reason to prohibit paths in the "name" directive, editing my handful of nonconforming font files to make them get in line is sim

[bug #61423] [libgroff] allow paths in "name" directive of font description file, restoring historical groff behavior

Follow-up Comment #5, bug #61423 (project groff): Raised for discussion on groff@ . ___ Reply to this item at: __

[bug #61423] [libgroff] allow paths in "name" directive of font description file, restoring historical groff behavior

Update of bug #61423 (project groff): Status: In Progress => Need Info ___ Follow-up Comment #4: Hmm, interestingly, the change being complained about made an _unintended_ directory traversal pre

[bug #61423] [libgroff] allow paths in "name" directive of font description file, restoring historical groff behavior

Update of bug #61423 (project groff): Severity:1 - Wish => 2 - Minor Status:None => In Progress ___ Follow-up Comment #3: Oh, look, there's a d

[bug #61423] [libgroff] allow paths in "name" directive of font description file, restoring historical groff behavior

Follow-up Comment #2, bug #61423 (project groff): The thing I love about making half-informed speculations is how quickly someone thunders to my door to correct me. Sometimes, I even manage to do it to myself. [comment #1 comment #1:] > As tempting as it would be to say that this is why we don'

[bug #61423] [libgroff] allow paths in "name" directive of font description file, restoring historical groff behavior

Update of bug #61423 (project groff): Assigned to:None => gbranden Summary: allow paths in "name" directive of font description file, restoring historical groff behavior => [libgroff] allow paths in "name" directive of font descripti