Update of bug #64577 (project groff): Status: In Progress => Fixed Open/Closed: Open => Closed Planned Release: None => 1.24.0
_______________________________________________________ Follow-up Comment #12: commit c08b62fd2a812e4d390ebf65d6c7d337d512d2b4 Author: G. Branden Robinson <g.branden.robin...@gmail.com> Date: Mon Aug 21 06:35:49 2023 -0500 [grops]: Fix Savannah #64577 (file diagnostics). * src/devices/grops/ps.cpp (ps_printer::define_encoding): * src/devices/grops/psrm.cpp (resource_manager::output_prolog) (resource_manager::supply_resource): Report more intelligible diagnostics when libgroff's `font::open_file()` returns a null pointer without setting `errno`. The only way this can happen is if it rejected the file name for containing a slash, thus attempting directory traversal (recall Savannah #61424). Also fix code style nits: explicitly `#include` errno.h C standard library header, align style of null pointer checks, and stop explicitly setting `errno` to zero before (indirectly) calling `fopen()`; we inspect `errno`'s value only under a documented error condition (a null stream pointer). See errno(3). * NEWS: Add item; we should have mentioned this (and produced these better diagnostics) when 1.23.0 was released. Distributors may find this change desirable to backport. Fixes <https://savannah.gnu.org/bugs/?64577>. Thanks to Phil Chadwick for the report and Deri James for swiftly finding a correct workaround that suited the reporter. However, as comment #11 notes, we may not be done here. I'm starting to think a new environment variable, _GROFF_RESOURCE_PATH_, might be necessary to handle the sorts of file system objects that _grops_ and _gropdf_ (and _only_ these output drivers, as far as I know), sometimes require. Whether such a new environment variable should be treated as a counterpart to output drivers' `-I` option as _GROFF_FONT_PATH_ already is for `-F` is an open question. I think we got into trouble in the first place by overloading the semantics of `GROFF_FONT_PATH` (and `-F`) with "embeddable resources". Really, it's better that this overloading _not_ be done, because `font::open_file()` is particularized to the needs of a device-independent _troff_--the reading of device-specific description files (including those for fonts). What PostScript and PDF do with resources is a different kettle of fish, and neither the formatter nor the output driver need to understand them, or not much. I recognize we do have some support for extracting bounding boxes/media boxes and stuff like that. So let us spin this into a new ticket. Phil, do you want to remain CCed on that? _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?64577> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/