From: Ingo Schwarze <schwarze@usta.de>
Subject: Re: ksh: add OSC7 support
To: ori@eigenstate.org
Cc: tech@openbsd.org
Date: Fri, 7 Nov 2025 20:32:37 +0100

Hi Ori,

ori@eigenstate.org wrote on Thu, Nov 06, 2025 at 08:23:26PM -0500:

> I use OSC7 in order to advertise the working directory to the
> terminal emulator I use. While I can hack this together in ksh
> with some scripts, it feels like it would be a better fit to
> have directly in the shell, though I'm uncertain about that.

I strongly object to any of our core base system software, and in
particular ksh(1), encouraging use of OSC (OSC in general, not just
OSC7 or OSC8) for any purpose whatsoever.  I consider OSC an utterly
terrible idea in the first place.  It is a bottomless pit of a
security nightmare.  We want software designs that are tailored to
one particular purpose and serve that one purpose in a simple and
reliable manner.  OSC is basically designed as a general-purpose
in-band vulnerability injector with no constraints on functionality
and exploitability.  We want designs that support multi-layer
security.  OSC promotes Swiss Cheese security approaches and
encourages people to argue "sure, this slice of cheese has several
holes here and there are there and there ... but i have this other
slice of cheese that also has various holes in it and i place both
slices behind each other and i make sure that none of the holes
align."  That's just naive.  Sooner or later, the holes *will* align
and the bullet will travel through and hit your butt.

I would be significantly more sympathetic to the idea of
deleting \e support completely from PS1 in ksh(1) than to add
any new escape sequence that involves printing '\033'.
For details of what i'm talking about, see

  https://man.openbsd.org/ksh.1#PS1

> It seems a bit odd to have support for this in tmux, but not
> emit it in our own shell.

Well, tmux(1) is known for being an all-in-one solution in search
of a problem that suffers extremely badly from rampant featuritis,
so much so that i have so far refused ever using it for anything.
The only redeeming quality is that the main tmux(1) developer nicm@
is among our most careful developers and codes with an extremely
low error density that i would never be able to reach - but still,
while a program suffering from featuritis might not pose a significant
security risk when it is coded in such exceptional quality, exhibiting
featurities should not be considered exemplary, so please do not
take the high feature density of tmux(1) as a model for OpenBSD
software in general.

> The patch below adds a '\O' option to PS1. It needs to be
> enabled explicitly, as:
> 
> 	PS1=\O\h\$

That would have to be documented, because it would be a user-visible
feature.  I consider documenting such a thing a unacceptable, simply
because documenting it would encourage people to use it, and we
should not promote such a bad idea.

> I'd also considered printing it after every 'cd' command,
> either unconditionally or behind a knob.

Doing anything of the kind is out of the question, even when hidden
behind some knob.  It would violate POSIX:

  https://pubs.opengroup.org/onlinepubs/9799919799/utilities/cd.html

  STDOUT
  [...]
  If a non-empty directory name from CDPATH is not used,
  and the directory argument is not '-', there shall be no output.

  STDERR
  The standard error shall be used only for diagnostic messages.

> Is there interest in this?

No interest, but strong opposition.

There is lots of work to do in ksh(1), and it is already hard enough
to get reviews and OKs for ksh(1) patches, but this is not one of the
subjects that need to be addressed.

Yours,
  Ingo