Thomas Frohwein tfrohwein at fastmail.com
Tue Mar 2 01:51:54 GMT 2021
- - - - - - - - - - - - - - - - - - -
On Mon, Mar 01, 2021 at 07:48:56PM -0500, Sean Conner wrote:
It was thus said that the Great Nathan Galt once stated:
On Mon, Mar 1, 2021, at 1:24 PM, Sean Conner wrote:
While I would like to disallow control codes in the specification, that
might be too big of a change, and *will* affect some sites, but adding
verbiage that discourages it can be added.
Perhaps this is the wrong way to frame this, but you're prioritizing
backwards compatibility on a pre-1.0-spec to support an unintended hack
that has security issues?
If I recall, escape codes where *never* in any of the specifications, just
an oversight when documenting the format (aka "loophole").
If I had control codes on my capsule, I'd grumble a bit, sure, but I'd
remove them. I'm not sure it's worth it to shield the tiny handful of
**current** capsule operators from some search-and-delete work compared to
all the future client implementors who'll face at least some pressure to
implement color support (and, if they're actual terminal applications,
open their users to keyboard-reset exploits).
I'd ban control codes in a heartbeat (except for HTAB, CR and LF as
stated), but I'm not sure how popular that decision would be.
I would support it. I think this step would work best if coupled withbest practices or code example for clients to identify and ideallyremove or warn/error if encountered. The client that I'm working on isncurses-based and doesn't support escape codes for that reason. Butmaybe a visible difference to text without escape code would be enoughto weed out existing escape code hacks. A simple way would be to guideclients to how to print the escape codes as plain text rather thanprocessing them. Could probably come up with a simple regex/tr to getstarted...