Runtime permissons request text could be hidden using iTerm custom escape codes

[GoldsteinE]

Script to reproduce:

console.log("\x1b[38;2;255;0;0mPlease, enter 'g' now");
console.log("\x1b]1337;SetColors=fg=fff\x1b\\\x1b]1337;SetColors=bg=fff\x1b\\");
await Deno.permissions.request({ name: "env" });

When running this on iTerm, the only thing visible on the screen is Please, enter 'g' now (and also emoji), and it's not clear that script is actually asking for permissions.

[satyarohith]

How can it be solved?

[GoldsteinE]

Setting explicit text color would work, but may be kinda ugly. If we know that we're on iTerm, it's quite simple to reset these settings, but this would require terminal detection. OSC 4 on iTerm reports bg/fg colors, so it's possible to just check that they're not the same / too similar.

It also could be considered a problem with iTerm: maybe iTerm could show confirmation window on changing profile colors.

[cd-work]

I think the prompting for permissions on the CLI has some broader problems than just proprietary iTerm escape sequences.

Even scrolling regions (CSI r) and cursor motion (CSI H) can easily move the prompt to the top of the screen, which is trivial to miss when you're at the bottom and just hammering away at your keyboard.

[GoldsteinE]

I think the general issue is that STDIN can’t be trusted. It can be fabricated or user can be fooled with hiding the prompt one way or another. Script controlling STDOUT has limited control over STDIN which can be potentially used to get more permissions.

[bartlomieju]

I just tested provided example on latest Deno (1.30.3) and this is what I get:

While the screen has turned white and there's "Please, enter 'g' now", the permission prompt is still somewhat visible (at least the emoji). I guess we should put some escape sequences to reset the color before printing the permission prompt.