[bug #66419] [libgroff] seems like fix for bug 61424 was too aggressive

Follow-up Comment #2, bug #66419 (group groff): First of all, thanks for the stunningly fast response to my report. I do appreciate that. Background: I have been using troff and its spawn for over 45 years. I'm getting pretty good at it (e.g., https://rbk.delosent.com/rmc-2024-03c.pdf ). To me, *

[bug #61424] [libgroff] directory traversal in .fp request

Follow-up Comment #7, bug #61424 (group groff): Bug #64577 subsequently revised this change. Bug #66419 constitutes a fairly strenuous objection to this change being made at all, and it is not clear whether the reporter regards the resolution of bug #64577 as any sort of mitigation. ___

[bug #66419] [libgroff] seems like fix for bug 61424 was too aggressive

Follow-up Comment #4, bug #66419 (group groff): Hi Rob, You've given me quite a bit to respond to. A comprehensive response would take a long time, not least because I'm not certain how to proceed with addressing all of your complaints to our mutual satisfaction. [comment #3 comment #3:] > Two

[bug #66419] [libgroff] seems like fix for bug 61424 was too aggressive

Update of bug #66419 (group groff): Status: Need Info => In Progress Assigned to:None => gbranden ___ Follow-up Comment #5: [comment #4 comment #4:] >> = Checking for /'s sh

[bug #66419] [libgroff] seems like fix for bug 61424 was too aggressive

Follow-up Comment #3, bug #66419 (group groff): Two thoughts dawned on me in the shower: = Security is part of an architecture, not part of a patch = Checking for /'s should occur at an appropriate place and emit a reasonable error message: grops: Font file names may not contain a '/'

[bug #66419] [libgroff] seems like fix for bug 61424 was too aggressive

Follow-up Comment #6, bug #66419 (group groff): I realize that checking for '/'s is relatively easy to implement. I do not, however, agree that it's a great idea unless the check is going to be improved to be backward-compatible. I think taking a step back and looking at the big picture of the go

[bug #66419] [libgroff] seems like fix for bug 61424 was too aggressive

Follow-up Comment #7, bug #66419 (group groff): I agree that the basic problem is the re-use of code to access completely different font files. .fp references groff font files which will be parsed (and only "belong" to groff), so there is a potential attack vector, but entries in the download file

[bug #66419] [libgroff] seems like fix for bug 61424 was too aggressive

Follow-up Comment #11, bug #66419 (group groff): I've pushed the commits quoted in comment #8. Their hashes are different. ___ Reply to this item at: _

[bug #64577] [grops] can't embed/download fonts from a subdirectory

Follow-up Comment #17, bug #64577 (group groff): Rob Kolstad points out in bug #66419 that (as I interpret him) supporting an "unsafe mode" in _grops_(1) is another possibility. There is room in its option name space and _groff_(1) could synthesize a `-U` option to _grops_ if it is itself given o

[bug #66419] [libgroff] seems like fix for bug 61424 was too aggressive

Update of bug #66419 (group groff): Severity: 3 - Normal => 4 - Important ___ Follow-up Comment #9: [comment #6 comment #6:] > I realize that checking for '/'s is relatively easy to implement. I do not, > howev

[bug #66419] [libgroff] seems like fix for bug 61424 was too aggressive

Follow-up Comment #10, bug #66419 (group groff): Oh! I missed that I was replying *to* Deri in comment #8. I apologize for my confusion. I'm pretty sure Deri remembers who wrote _gropdf_. 😅 ___ Reply to this item at:

[bug #66419] [libgroff] seems like fix for bug 61424 was too aggressive

Follow-up Comment #8, bug #66419 (group groff): [comment #7 comment #7:] > I agree that the basic problem is the re-use of code to access completely > different font files. .fp references groff font files which will be parsed > (and only "belong" to groff), so there is a potential attack vector,