{"action":"created","issue":{"url":"https://api.github.com/repos/WebAssembly/WASI/issues/162","repository_url":"https://api.github.com/repos/WebAssembly/WASI","labels_url":"https://api.github.com/repos/WebAssembly/WASI/issues/162/labels{/name}","comments_url":"https://api.github.com/repos/WebAssembly/WASI/issues/162/comments","events_url":"https://api.github.com/repos/WebAssembly/WASI/issues/162/events","html_url":"https://github.com/WebAssembly/WASI/issues/162","id":529433510,"node_id":"MDU6SXNzdWU1Mjk0MzM1MTA=","number":162,"title":"ANSI escape sequences: a possible path forward","user":{"login":"sunfishcode","id":4503403,"node_id":"MDQ6VXNlcjQ1MDM0MDM=","avatar_url":"https://avatars1.githubusercontent.com/u/4503403?v=4","gravatar_id":"","url":"https://api.github.com/users/sunfishcode","html_url":"https://github.com/sunfishcode","followers_url":"https://api.github.com/users/sunfishcode/followers","following_url":"https://api.github.com/users/sunfishcode/following{/other_user}","gists_url":"https://api.github.com/users/sunfishcode/gists{/gist_id}","starred_url":"https://api.github.com/users/sunfishcode/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sunfishcode/subscriptions","organizations_url":"https://api.github.com/users/sunfishcode/orgs","repos_url":"https://api.github.com/users/sunfishcode/repos","events_url":"https://api.github.com/users/sunfishcode/events{/privacy}","received_events_url":"https://api.github.com/users/sunfishcode/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":4,"created_at":"2019-11-27T15:53:39Z","updated_at":"2019-11-29T05:50:36Z","closed_at":null,"author_association":"MEMBER","body":"ANSI escape sequences are really useful, but we need a plan, both for portability and security, as escape sequences can cause a [variety of havoc](https://www.batterystapl.es/2018/01/security-implications-of-ansi-escape.html). Here's a skeleton of a plan; feedback welcome!\r\n\r\nWhen output is connected to a terminal, by default:\r\n - With only a few exceptions, control characters should be sanitized, perhaps replaced by [control pictures](https://en.wikipedia.org/wiki/Unicode_control_characters#Control_pictures).\r\n - Control characters which are permitted are:\r\n   - LF, but with the \"newline\" interpretation\r\n   - BS, CR (for pretty progress indicators etc.). Output devices that don't support these may interpret `CR` the same as `LF` above, and emit `␈` (or `⌫`?) in place of BS. Applications should avoid displaying progress indicators when the libc function `isatty` returns false (TODO: this isn't a simple topic), and should prefer `CR` to `BS` for progress indicators in general as CR translates better to log output.\r\n   - HT (aka TAB).\r\n\r\n(One could argue BEL could be included here too; I omitted it for aesthetic reasons. Feel free to disagree!). VT and FF are omitted because they aren't very useful and would add complexity.\r\n\r\nNotably, this would neutralize ESC and thus ANSI escape sequences.\r\n\r\nThen, we add a `rights` flag on a file descriptor indicating the right to use these features. When WASI gains the ability for programs to request capabilities (some early discussion [here](https://github.com/WebAssembly/WASI/issues/5)), programs could then request the ability to use ANSI escape sequences. And implementations should reset the terminal to normal settings when the program starts and terminates.\r\n\r\nThen, we identify the escape sequences that are the most useful -- color, cursor positioning, and possibly other things. Then we have a choice -- either:\r\n - Add an explicit API for those things, with functions that change the current color, set the cursor position, etc., or\r\n - Allow applications to write ANSI escape sequences and interpret those that are recognized, and continue suppress those that are not. Platforms whose terminal applications don't natively support ANSI escape sequences would have to emulate them.\r\n\r\nAn API is simpler, and it makes it straightforward for applications to feature-detect which functions are available. And it makes a clean break from the ANSI escape sequence encoding, freeing us from some legacy concerns. On the other hand, just allowing select ANSI codes to go through would be better for compatibility.\r\n\r\nAs for TERM, terminfo, termcap, there's a lot of legacy there that it'd be nice to avoid carrying forward. If we define the semantics of output to a terminal, it seems like it ought to be possible to avoid supporting these interfaces at the WASI level (they could still be emulated in libc for compatibility).\r\n\r\nFor [`NO_COLOR`](https://no-color.org/), this could be implemented by wasm engines rather than by applications, either by making color a distinct rights flag, or by just stripping (or translating to gray-scale, if the output supports that) color.\r\n\r\nThere are surely a lot more details to be figured out, but I wanted to put some ideas out there to start a discussion.\r\n\r\n[Edits: add HT (TAB), discuss VT and FF, mention that implementations should reset the terminal on startup, and add some advice for applications implementing progress bars.]"},"comment":{"url":"https://api.github.com/repos/WebAssembly/WASI/issues/comments/559667661","html_url":"https://github.com/WebAssembly/WASI/issues/162#issuecomment-559667661","issue_url":"https://api.github.com/repos/WebAssembly/WASI/issues/162","id":559667661,"node_id":"MDEyOklzc3VlQ29tbWVudDU1OTY2NzY2MQ==","user":{"login":"mash-graz","id":13013641,"node_id":"MDQ6VXNlcjEzMDEzNjQx","avatar_url":"https://avatars2.githubusercontent.com/u/13013641?v=4","gravatar_id":"","url":"https://api.github.com/users/mash-graz","html_url":"https://github.com/mash-graz","followers_url":"https://api.github.com/users/mash-graz/followers","following_url":"https://api.github.com/users/mash-graz/following{/other_user}","gists_url":"https://api.github.com/users/mash-graz/gists{/gist_id}","starred_url":"https://api.github.com/users/mash-graz/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mash-graz/subscriptions","organizations_url":"https://api.github.com/users/mash-graz/orgs","repos_url":"https://api.github.com/users/mash-graz/repos","events_url":"https://api.github.com/users/mash-graz/events{/privacy}","received_events_url":"https://api.github.com/users/mash-graz/received_events","type":"User","site_admin":false},"created_at":"2019-11-29T05:50:36Z","updated_at":"2019-11-29T05:50:36Z","author_association":"NONE","body":"i don't think, the dangers of escape sequences resp. stdio filtering can/should be manged by WASM. **if this kind of risc can be managed at all, it has to be done on the side of the actual used virtual terminal applications.** otherwise it will just lead to unnecessary restrictions and a multitude of hard foreseeable side effects -- i.e. incompatibilities with mature terminal handling libraries etc.  but that's just my amateurish privat opinion about this question.\r\n"}}
{"actor":{"display_login":"mash-graz"}}