Update of bug #64577 (project groff):
Status: None => Need Info
Assigned to: None => gbranden
_______________________________________________________
Follow-up Comment #1:
Hi Phil,
Thank you for this excellently documented bug report. Please follow up to the
Savannah bug tracker at <https://savannah.gnu.org/bugs/?64577>.
[comment #0 original submission:]
> [strand.488] $ groff -Tps e.nr >e.ps
> grops:<standard input>:(e.nr):20: error: failed to open PostScript
resource
> 'Type1Fonts/Dot-Matrix.ps': No error: 0
An error message that looks like this always means a programmer goof, so at
the very least we have a defective diagnostic.
> That error message is new to groff version 1.23.0.
[...]
> I think it's a bug. Sincerely hoping it's not a "feature".
It is fallout from a different change that was deliberate, and documented, but
which understandably you would likely not have seen coming even with a careful
reading of our NEWS file and release notes.
o The `fp` request no longer accepts file or font names with slashes in
them as arguments. All font description files are expected to be
accessible within the directory of the output device for which they
were prepared.
o afmtodit no longer writes file names with directory information in
them to the "name" directives of the font descriptions it generates.
(The `fp` request no longer accepts such names; see "troff" above.)
We made this change because we were concerned about the security implications
of directory traversal. See bug #61424.
The missing information is that the `fp` formatter request uses a function
from an internal library, `font::open_file()`, to locate and access a font
description file.
Something I missed was that _grops_ (and _only grops_) uses it too.
src/devices/grops/ps.cpp: FILE *fp = font::open_file(encoding, &path);
src/devices/grops/psrm.cpp: FILE *fp = font::open_file(prologue, &path);
src/devices/grops/psrm.cpp: fp = font::open_file(r->filename, &path);
src/devices/grops/psrm.cpp: FILE *fp = font::open_file("download", &path);
As a workaround and test, please move your Dot-Matrix.ps file into
/usr/local/share/groff/1.23.0/font/devps (or make a symlink), retry, and let
us know if that solves the problem.
If it does, and that is satisfactory for you, then I will confine the scope of
this ticket to the unhelpful diagnostic message.
Please also test adding your Type1 subdirectory to _groff_'s font search path.
There are a couple of ways of doing that.
export GROFF_FONT_PATH=/usr/local/share/groff/1.23.0/font/devps/Type1
groff -F /usr/local/share/groff/1.23.0/font/devps/Type1 -Tps e.nr >e.ps
(Or as a variant on the first, you could set the environment variable at the
beginning of the command-line to confine its scope, rather than exporting it
into your shell's environment.)
This/these should also work, and I definitely want to know if it/they don't.
If the foregoing is not satisfactory, and you want _grops_ to be able to
access arbitrary directories relative to its "home" in
$DESTDIR/share/groff/1.23.0/font/devps, then I will need to consult with my
fellow _groff_ developers for perspectives on the wisdom and security
implications of doing so. This might mean adding a `-U` ("unsafe") flag to
_grops_ and would then _still_ require a change to your workflow, because
you'd then need to pass it. This can be done with the `-P -U` option sequence
to the _groff_ command.
One of the reasons I think it likely that we won't go back to groff 1.22.4
behavior here is that the formatter both permits arbitrary PostScript to be
injected into an input document (via the `device` and `devicem` requests and
`\X` and `\Y` escape sequences). So we probably don't want to ship a _grops_
that will grub around in arbitrary places on the file system. Even though
it's not privileged anyway. roff documents have a MIME type and it's no fun
for people to open attachments in their mailer and get a pop-up PostScript
renderer exclaiming "im in ur /etc readin ur passwd" and *seeing your actual
/etc/passwd file contents* subsequently.
Please let me know what you discover with respect to the workarounds, and
share your perspective on the safety issue.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?64577>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
