Update of bug #64612 (project groff):
Status: None => Need Info
_______________________________________________________
Follow-up Comment #5:
Hi Deri,
[comment #4 comment #4:]
> I was not aware that a change proposed to forbid paths in .fp third
parameter and the "name" written by afmtodit, had also (unintentionally)
prevented paths in the grops download file,
Right. No one was aware of that. As implementor of the change, I bear the
chief blame for overlooking it; I should have checked all call sites of
font::open_file(), but either didn't, or did but failed to completely
understand the consequences.
> with no diagnostic message.
That part's not true. A diagnostic _was_ generated, albeit not a very helpful
one. See bug #64577, reported by Phil.
grops:<standard input>:(e.nr):20: error: failed to open PostScript resource
'Type1Fonts/Dot-Matrix.ps': No error: 0
> The proposed "fix" seems to be addition of a diagnostic message
...the replacement of an semi-scrutable diagnostic message with a
comprehensible one...
> and a discussion on what to call a new environment variable!
Well, we could do without the environment variable and rely solely upon people
passing `-I` options to the preprocessor, or requiring the user to stick
symbolic links in various places on the file system. The last is the solution
Phil adopted while we work out a long-term fix.
Let's recall what `font::open_file()` is for. It is for opening files
relative to the device-specific directory housing device and font description
files: "DESC", "TR", "ZCMI", "EURO", and so on.
If a file lives in, say, /usr/local/share/groff/1.23.0/font/devps/, then
`font::open_file()` is what should be used to open it. We can quibble about
the PostScript "prologue" file and/or "text.enc" but I don't see a reason to
as long as the default versions of these are adequate to most users' purposes,
and this seems to be the case.
> My preference would be to find a safe way to restore the previous behaviour
re. download paths, given the change is unintentional in the first place.
Is the "download" file materially different than "DESC", font description
files, "prologue", and "text.enc"?
I submit that it *is* materially different, because a normal, expected use
case is for people to have Type 1 fonts in arbitrary places on the file system
and for the contents of "download" to (ideally) be updated synchronously with
changes in the populations of those locations.
> If the download file containing the path to the postscript font is only
writeable by root I think we can trust the path.
That seems unnecessarily restrictive to me. A user might have a "local" font
directory under their $HOME. Consider:
/home/branden/share/font/type1/mince.pfa
/home/branden/share/groff/font/devps/MINCE
Many programs I run might use the Type 1 PostScript font "mince.pfa", but only
_groff_ programs (really just _troff_, _grops_, and _gropdf_) are going to
care about its description in _groff_font_(5) format.
> Further, for the users safety, it would make sense to always search for a
groff font in the system directories first before directories provided by the
user, this would prevent masking a system font with a nefarious font from
somewhere else.
I think this is a separate issue. Yes, the present issue arose because of
security concerns, but I am dubious of accepting a file specification
containing "../../../../../../../../" just because it's resolved _relative_ to
a directory that is writable only by root (or the invoking user, who might
have downloaded an untrusted attachment). That is the concern of bug #61424.
> Fortunately, the bug only affects grops, not gropdf, so paths are not
forbidden in the its own download file.
I think _grops_ and _gropdf_ should behave similarly. I admit that _grops_'s
lack of a "foundry" feature and supported extension to the Foundry file issue
is a defect, bug #58969.
It seems to me that this issue is entangled like the dickens with the
long-standing and notorious bug #60930. Perhaps one reason that issue has
proven challenging to resolve by volunteers is the amount of conceptual murk
and quantity of implementation gaps surrounding it. (1) People confuse
_groff_ font description files with PostScript font files. (2) People confuse
$GROFF_FONT_PATH with a search path for arbitrary PostScript resources. (3)
Whatever best practices exist for storage locations of PostScript font files
are insufficiently socialized. (4) Apparently no one has ever written a tool
for management of "download" files with awareness of the preceding point. If
_I_ understand the role of "download" correctly, there's no reason at all for
it to be _groff_'s bailiwick. One might have PostScript fonts one wants to
manage (and embed in PostScript documents) without having _groff_ installed at
all. I would have thought that some distribution of TeX solved this problem,
but maybe not given the popularity of gigantic, batteries-included,
everything-you'll-ever-need distributions of it. Still, it's a point worth
looking into.
So my questions for Deri (and any developer who wants to speak up) are (a) if
you regard the "download" file as materially different than "DESC", font
description files, "prologue", and "text.enc"; (b) if you regard the
PostScript font files as materially different from their corresponding _groff_
font descriptions; (c) whether it is likely that any of these files will be
found in different locations; and (d) whether it is desirable for any of them
to be, given _groff_'s role in a larger operating system.
Putting into "Need Info" status.
While we're mulling these issues, I notice that
`search_path::open_file_cautious()` _also_ *seems* to have no protection
against directory traversal. This should be tested.
https://git.savannah.gnu.org/cgit/groff.git/tree/src/libs/libgroff/searchpath.cpp?h=1.23.0#n147
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?64612>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
