- комментарий 0:
From: kmeaw
Date: 2020-10-08 07:58:00Z
Я был удивлён, когда обнаружил, что Zsh знает про это.
То есть если вставить в интерактивный шелл пачку команд, то он не начнёт
их немедленно выполнять, как только дочитает первую строку, а будет
считать всё встравленное одним большим блоком, ожидая, когда я
по-настоящему нажму Enter, чтобы дать мне шанс отредактировать
вставленное.
И, одновременно, есть сценарий, который у меня ломается от такого
поведения. Когда я по ssh подключаюсь к удалённой машине с Zsh, и хочу
допробросить какой-нибудь порт, то делаю это через command line,
встроенный в ssh ("ssh> "). В ней я печатаю "-L1234:", например, а
потом, если хочу вставить из X11 selection назначение, то получается не
то, чего я хочу на самом деле, так как помимо "host:port" вокруг
вставляемой строки добавляются те самые brackets.
Видимо, придётся патчить ssh, чтобы просить его временно отключать этот
режим работы терминала, когда я открываю command line, и возвращать
состояние обратно, когда возвращаюсь к pty.
- комментарий 1:
From: Sergey Matveev
Date: 2020-10-08 08:23:34Z
*** kmeaw [2020-10-08 10:38]:
>То есть если вставить в интерактивный шелл пачку команд, то он не начнёт
>их немедленно выполнять, как только дочитает первую строку, а будет
>считать всё встравленное одним большим блоком
Пока вы это не написали, то я даже не обращал на это внимание. А ведь
действительно: он даже отдельно у меня (курсивом) подсвечивает этот
вставленный блок, показывая что его ещё можно отредактировать. Но это у
меня, получается, с самого начала так было и поэтому просто принимал как
есть, как данность.
>допробросить какой-нибудь порт, то делаю это через command line,
>встроенный в ssh ("ssh> ")
Даже не замечал его command line :-) и никогда не пользовался. Но да,
бывают что какие-то программы не понимают этот bracketed paste, хотя я с
ходу и не вспомню где на своей практике встречался с непонимающими его.
- комментарий 2:
From: kmeaw
Date: 2021-05-14 09:35:55Z
Сегодня показывал коллегам, как копировать имя ветки в pull-request из
браузера и вставить его в command-line git'а, чтобы не получалось
такого:
% git checkout foo-bar
Branch 'foo-bar' set up to track remote branch 'foo-bar' from 'origin'.
Switched to a new branch 'foo-bar'.
% to master
to: command not found
%
И обнаружил проблему (уязвимость?) - копируемый в буфер фрагмент может
содержать строку "\033[201~", из-за чего шелл не может определить
границу встравляемого фрагмента, что может вызвать выполнение кода.
Средства CSS достаточно богаты, чтобы визуально скрыть наличие этих
спецсимволов.
Воспроизводится в zsh 5.8 и GNU bash, version 4.4.23(1)-release с
GNU Readline 7.0p5 в urxvt v9.22. В xterm и vte не воспроизводится,
потому что там нельзя вставить ^[.
Так что не стоит воспринимать эту фичу, как security measure, а лишь как
удобный способ вставлять данные из доверенных источников.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787628
- комментарий 3:
From: Sergey Matveev
Date: 2021-05-14 09:44:07Z
*** kmeaw [2021-05-14 12:34]:
>Так что не стоит воспринимать эту фичу, как security measure, а лишь как
>удобный способ вставлять данные из доверенных источников.
Безусловно к security тут отношения никакого. Согласен с комментариями в
bugtracker-е поясняюшими что это не задача терминала и в целом не
выполнима, ибо он не знает про приложение ничего в нём запущенное.
Когда-то ещё видел примеры атак когда CSS-ом, если не ошибаюсь, скрывают
текст, который при бездумной вставке через буфер обмена может содержать
всякую зловредную бяку. Так что да -- уже не в первый раз показывают что
нельзя просто так брать и копировать текст для выполнения в shell-е.