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

Update of bug #66419 (group groff): Status: In Progress => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #19: commit f2f0b8e1f7e1edbf63239107bdcce65a8fdeca24 Author:

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

Update of bug #66419 (group groff): Status:None => In Progress ___ Reply to this item at: ___ Message sent via Sav

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

Update of bug #66419 (group groff): Status: Fixed => None Open/Closed: Closed => Open ___ Follow-up Comment #18: 1.23.0's behavior was noted in the NEWS file, so the partial

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

Follow-up Comment #17, bug #66419 (group groff): Thanks so much for the stunningly prompt action to address my report. ___ Reply to this item at: ___ Me

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

Update of bug #66419 (group groff): Status: In Progress => Fixed Open/Closed:Open => Closed Planned Release:None => 1.24.0 ___ Follow-up Comment #16

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

Follow-up Comment #15, bug #66419 (group groff): I haven't heard anything more from Rob about the shape of my proposed fix (comment #13). > I think I'd prefer instead to have a new entry point in libgroff called > `font::open_resource()` to make it clearer what's going on at the call site, > and

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

Follow-up Comment #14, bug #66419 (group groff): [comment #9 comment #9:] > If you'd like to propose its reconsideration, please post a > comment to bug #61424 so that the other _groff_ developers who > opined on it (Dave Kemper and Deri James) are aware of your > perspective and can weigh in. I

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

Follow-up Comment #13, bug #66419 (group groff): Hi Deri, [comment #12 comment #12:] > I am confused now! The ticket is about the restriction of including a path in > the download file, It's actually about several things, in my view, which I think is the only thing confusing you. > which you s

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

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 > > Symb

[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 #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

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 #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,

[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 #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

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 #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

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 #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 #66419] [libgroff] seems like fix for bug 61424 was too aggressive

Update of bug #66419 (group groff): Category: Font devps => Core Status:None => Need Info Summary: seems like fix for bug 61424 was too aggressive => [libgroff] seems like fix for bug 61424 was too aggressive