Follow-up Comment #2, bug #66419 (group groff): First of all, thanks for the stunningly fast response to my report. I do appreciate that.
Background: I have been using troff and its spawn for over 45 years. I'm getting pretty good at it (e.g., https://rbk.delosent.com/rmc-2024-03c.pdf ). To me, *backward compatibility is very important*. By actual count, I have 41 font directories for various projects. Each has a DESC file, font metrics, and a font directory. The font directory for the magazine in the URL above has over 80 fonts in it (no, I don't use them all at once). A project to re-typeset the 1624AD book _Hunting, Hawking, and Blasing of Arms_ has but six fonts (none of them is TimesRoman). These live in user space in my home directory and have worked reliably year after year, upgrade after upgrade. Now comes version 1.23.0 which would have me not only repair the 'download' file (that specifies where the font files live) but also move them and their non-mnenomic names into the same directory. Here's a sample of some worthless names: Humanist521BT-Bold fontdir/0292a___.ps Humanist521BT-RomanCondensed fontdir/0495a___.ps Humanist521BT-Light fontdir/0288a___.ps Humanist521BT-LightItalic fontdir/0289a___.ps but that's what I'm stuck with. I have about 250,000 fonts online (collecting such things was a long-term hobby). Now, under the guise of increased security, we have a new file layout that is quite incompatible and demanding. I'd like to suggest that this is not a forward-looking upgrade and, in fact, should be eschewed completely. The motivation, as I understand it, for changing whether certain filenames & paths are valid is that some commands accept file paths that could include such sneaky inputs as: ../../../../../../../etc/passwd Bug 61424 asserted that this is an unacceptable state of affairs as it could enable a 'security problem'. My first thought was, 'well, how are we doing on tight security?' so I tried: .so /etc/passwd and was instantly rewarded with a typeset version of the password file, for what it's worth. I mentioned 61424 and its fix to my buddy the release engineer for Wind River who was responsible for building and distributing the system on 26 architectures (and use continuous daily builds to do so). He was aghast: "It's not roff's job to provide security! It's the job of the surrounding system." The general thought, with which I agree, is that any file that the 'user' of *roff might have access to is probably fair game for any user program that executes using that user's credentials. If the program is exposed, e.g., to the outside world (i.e., random users of the internet can submit files for formatting), then the surrounding system should be run in a container or sandbox or somesuch with known file contents that can be exposed with no harm. I have experience with this sort of thing, having run the first programming contest interface where random internet users could submit code in a variety of languages to the contest system that would then run those programs. Of course, folks tried to circumvent security, but a nice sandboxing mechanism checked every system call to ensure it was within parameters (e.g., the 'open' call had a list of files available for opening; not on the list? no open.). The task of 'securing groff & friends' would complicate the code, perhaps introduce the sort of bad compatibility issues we are currently saddled with, and -- in general -- be about impossible to get right. Not impossible, 'about' impossible. Along the way, there will be errors and embarrassments as the 'we are secure now' mantra is shared. Personally, I think it's a waste of resources -- it surely doesn't make the tools more usable or helpful. May I suggest taking a more enlightened approach to security and abandoning filename checking? Absent the will to do that, perhaps rules like 'only one non-leading slash and no ".."s are allowed' would be a bit more useful than "sorry, no slashes in one particular case that will cause you to reorganize all your private font directories". The execution time for checking such things is negligible, though the idea of finding all the places to perform such checking will provide a bit more challenge. UUCP tried to do this back in about 1988, and some clever programmer optimized a '..' check so that ..//..//..//..//etc//passwd got through the check. Security at this level is not for the faint of heart. Of course, qualifying such opens with a -U requirement is entirely acceptable. Thanks for your patience. I currently have to rebuild troff when I get a new copy in order to add a single new command required to make the macros work for the magazine (as shown in the URL above). I'd hate to have to find all the security enhancements that cause trouble for my work flow and have to disable them for each release. Took me a full person-day this time. Please do share your thoughts. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?66419> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
