URL: <https://savannah.gnu.org/bugs/?66419>
Summary: seems like fix for bug 61424 was too aggressive
Group: GNU roff
Submitter: rbkdelos
Submitted: Wed 06 Nov 2024 11:17:55 PM UTC
Category: Font devps
Severity: 3 - Normal
Item Group: Incorrect behaviour
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Planned Release: None
_______________________________________________________
Follow-up Comments:
-------------------------------------------------------
Date: Wed 06 Nov 2024 11:17:55 PM UTC By: Rob Kolstad <rbkdelos>
From 'ChangeLog' for [downloaded source] version 1.23.0:
2021-11-07 G. Branden Robinson <g.branden.robin...@gmail.com>
* src/libs/libgroff/fontfile.cpp (font::open_file): Don't open
user-specified font file names with slashes in them; i.e., don't
traverse directories outside the configured font path. Also
refuse to open the file if the `sprintf()` used to construct its
file name doesn't write the expected quantity of bytes to the
destination buffer.
Fixes <https://savannah.gnu.org/bugs/?61424>. Thanks to Ingo
Schwarze for feedback.
2021-11-07 G. Branden Robinson <g.branden.robin...@gmail.com>
* src/libs/libgroff/fontfile.cpp (font::open_file): Don't open
user-specified font file names with slashes in them; i.e., don't
traverse directories outside the configured font path. Also
refuse to open the file if the `sprintf()` used to construct its
file name doesn't write the expected quantity of bytes to the
destination buffer.
Fixes <https://savannah.gnu.org/bugs/?61424>. Thanks to Ingo
Schwarze for feedback.
----------------------------
The key point is that calling font::open_file in
src/libs/libgroff/fontfile.cpp with a filename containing a
slash causes the open_file function to punt and return a
NULL for the open file pointer named 'fp'. However, all the
devps directories I've worked with have a file named 'download'
with lines like this:
Arial fontdir/arial.ps
where the second field indicates the actual postscript fontfile
to be downloaded. Such entries *always* (in my experience) have
a slash in them.
I run into problems when I use a font directory specified with
-F instead of the standard directories of the system. The problem
reported is that the file 'download/postscriptfilename.ps' can't be found:
grops:<standard input>:(main):20114: error: failed to open
PostScript resource 'fontdir/ARIALNB.TTF.ps': Success
[the 'error' suggesting Success is a side-effect of not having
called the open routine at all]
The 'fix' is simple, but it undoes the fix for bug 61424:
// Do not traverse user-specified directories; Savannah #61424.
if (1 || 0 /* nullptr */ == strchr(nm, '/')) { // <---- NEW
// if (0 /* nullptr */ == strchr(nm, '/')) { // <---- OLD
// Allocate enough for nm + device + 'dev' '/' '\0'.
int expected_size = strlen(nm) + strlen(device) + 5;
char *filename = new char[expected_size];
const int actual_size = sprintf(filename, "dev%s/%s", device, nm);
expected_size--; // sprintf() doesn't count the null terminator.
if (actual_size == expected_size)
fp = font_path.open_file(filename, pathp);
delete[] filename;
}
return fp;
}
The proper way to fix this is to remove the if statement and
braces altogether.
Fixing 61424 is going to require a bit more work, I fear.
How to reproduce:
create file 'in':
.sp 1i
.ft Marlboro \" any non-traditional font in a custom font dir
Hello World!
then:
groff -F myfontdir in > out
yields:
grops:<standard input>:19: error: failed to open PostScript resource
'fontdir/Marlboro.ps': Success
Removing the 'if' logic in open_file() seems to fix this issue.
Of course, it reinstates bug 61424.
I have not tested this in extensive production, but the fix gets me back onto
the path. Output seems to look right now.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66419>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
