Omarchy has changed its Kitty configuration after a security issue was identified with allow_remote_control yes.

That setting allows Kitty’s remote-control protocol to accept commands from terminal output, meaning untrusted output could potentially execute commands as the current user. Kitty itself defaults this setting to no; the exposure came from Omarchy explicitly enabling it so other parts of the desktop could query the active terminal’s working directory.

The change disables remote control by default and migrates existing explicit yes settings to no. Users affected by the migration need to fully close and reopen Kitty, as existing processes remain exposed until they exit.

There is a small trade-off: Omarchy can no longer reliably determine the active Kitty tab/pane’s working directory via its socket, so new terminal or Files launches may occasionally fall back to the home directory.

The associated migration tests reportedly pass, although no live Kitty test was run in the test environment.

  • starblursd@lemmy.zip
    link
    fedilink
    English
    arrow-up
    5
    ·
    13 hours ago

    It actually also allows other programs to execute code through Kitty, example if you cat a file that has escapes in it. It would allow Kitty to execute that code when you never intended it… But like why does kitty even have that as a feature? But they’ve since updated the config to be set to socket only instead of yes

    • dizuane@sh.itjust.works
      link
      fedilink
      arrow-up
      4
      ·
      12 hours ago

      Having the feature seems pretty in line with the general Linux philosophy. Let the user decide, even if that means they screw it up. Same reason you can muck up an install by just running updates on storage that doesn’t have enough room to do so. It’s up to the end user to understand, verify, and choose to execute.