Index | Thread | Search

From:
Ingo Schwarze <schwarze@usta.de>
Subject:
Re: ksh: add OSC7 support
To:
obsd@mulh.net
Cc:
tech@openbsd.org
Date:
Sat, 8 Nov 2025 10:52:06 +0100

Download raw body.

Thread
  • obsd@mulh.net:

    ksh: add OSC7 support

    • Ingo Schwarze:

      ksh: add OSC7 support

Hi,

obsd@mulh.net wrote on Fri, Nov 07, 2025 at 04:58:57PM -0500:

> My response was just to show how a user who really wanted to do this
> how it can be done without changing openbsd (and on their own system).

Sure, and your example how one can already use OSC7 in the shell prompt
looked sufficiently scary that people in their right mind are unlikely
to be encouraged by it.

> As a side note my updated solution is broke, incorrect quoting in PS1.

Whithout intending disrespect, if that is true, i don't think it is
a coincidence.  On the one hand, creating complicated output syntax
that, in and of itself, is highly obfuscated is very prone to error
even when done by a competent programmer.  On the other hand, the
sh(1) programming language is quite prone to quoting mistakes even
when used in ordinary ways; that risk certainly gets worse in a
complicated situation like this.

> My question:
> Having PS1 being able to run arbitrary commands is that a security risk
> needing fixed?

I don't think it is.  Letting the user run arbitrary commands is the
whole point of the shell.  Using command substitution is PS1 assignments
isn't much different from using command substitution in other shell
variable assignments, and it is obviously prone to similar kinds of
quoting and metacharacter issues.  I'm not objecting to the user
running arbitrary commands, but to encouraging them to use crazy
in-band signalling misfeatures of terminal emulators that risk terminal
corruption up to and including arbitrary command execution *in the
terminal program* - which, in contrast to the shell, is not designed
or intended as a tool to let the user run arbitrary commands.

A reasonable user will readily understand that running

  sh $ . ./untrusted_file
  sh $ sh ./untrusted_file
  sh $ sh -c ./untrusted_file

is a bad idea.  On the other hand, judging under which circumstances
and in which ways running

  sh $ cat ./untrusted_file

may be dangerous is much harder to wrap your head around.

> (or if the user wants to shoot their own foot, let em!)

Kind of.  Personally, i'm sometimes using

  PS1="\u@\h $ "

but have mostly moved on to just

  PS1=' $ '

these days which provides the benefit of more horiontal space to type
commands before the shell starts scrolling horizontally.  If people
want to assign crazy stuff to PS1, that's not my problem, as long as
the ksh(1) manual doesn't encourage it too much.  I don't
particularly like the second example that the ksh(1) manual
provides for PS1 (the one with tput so), but it's not emphasized
so much that i feel like advocating for its deletion either;
besides, at least that example is using facilities *intended* for
portable terminal control and doesn't use anything as crazy as OSC.

Yours,
  Ingo