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 point to actual real postscript fonts (available to all programs on the system) which will either be valid and work, or invalid and fail, but never in a way which could compromise the system. You can of course have valid and malicious postscript fonts which when downloaded to a printer cause it to calculate pi to the nth degree as an actual postscript program, but checking for "/" in the path would not stop that!
The download file for devpdf continues to allow full pathnames, since even a malicious type 1 font will get nowhere, because the PDF spec does not include a postscript interpreter, and an invalid type 1 font file is likely just to make gropdf give up on the document. If you fear a security hole in the .fp request by all means plug it, but it is a poor choice if it prevents paths being included in the grops download file _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?66419> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature