> > I don't think they're stripped for security reasons, but because groff > repurposes chunks of the control-character code space for its own uses.
Oh. Erh, I didn't know that... I kind of assumed that, being the escape character, it was filtered for the reasons I described earlier. Is this really our problem to solve? Nope. Pretend this thread never happened. On Fri, 7 Aug 2020 at 00:29, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > At 2020-07-28T00:26:49+1000, John Gardner wrote: > > Hi folks, > > > > Raw escape characters (U+001B) get stripped from source-code during > > formatting, but inserting one is still possible using \N'27': > > I don't think they're stripped for security reasons, but because groff > repurposes chunks of the control-character code space for its own uses. > > I've updated our documentation recently with respect to this issue. > > https://git.savannah.gnu.org/cgit/groff.git/commit/ > ?id=6353ceb8b92e8e9fe927e5c93ceef1be6f54067c > > > \N'27'[4mI don't remember underlining this.\N'27'[0m > > > > This has potential security implications for people using `less -R` > > (and can still mess up terminal output for those who don't). > > I suppose this is possible but you're probably not casting your net wide > enough. We'd also have to block CSI 0x9B and OSC 0x9D as well. > > xterm's ctlseqs.ms document should probably be reviewed. > > But consider this too. > > People can also have groff documents that deplete the paper trays: > > .while 1 .bp > > Or, even worse, which recreate the "black fax" DoS attack of yesteryear. > > How shall we guard against this sort of problem in documents destined > for physical printing? > > For some years, xterm has had runtime-configurable options to suppress > controls and information leaks, and the really dangerous ones default > off. > > Is this really our problem to solve? > > Regards, > Branden >
