¿Por qué los terminales GUI permiten el pegado de caracteres de control?

Terminales anteriores a la fecha de copiar y pegar. Por lo tanto, dentro del protocolo del terminal, no hay distinción entre pegar y escribir. La idea de pegar contenido en una ventana de emulador de terminal se adaptó al sistema simulando la escritura rápida de caracteres cuando el terminal cuando la función "pegar" está activada. Esto simplemente descarga el contenido exactamente como aparece en el portapapeles.

En cuanto a pegar caracteres de control: la respuesta del programador del emulador de terminal sería algo como: "¿Por qué incluso haces eso?" Presenta un argumento convincente de que esto podría ser realmente una vulnerabilidad de inyección en el propio programa de terminal.

Como tal, no está fuera de la cuestión sugerir que los programas como PuTTY y GNOME Terminal deberían tener una configuración en algún lugar que le permita especificar si pegar o no los caracteres de control es algo que desea para habilitar. Quizás esté desactivado por defecto.

Creo que esta es una buena pregunta, ya que tiene muchos sistemas involucrados. ¿En qué corte está la pelota? ¿Es esto realmente un problema? Nunca he pensado en esto, pero déjame escupir algunos pensamientos.

1. Creo que copiar y pegar es una herramienta, y como es una herramienta, creo que puede ser útil para copiar y pegar caracteres de control de un lugar a otro. Tal vez, por ejemplo, desee copiar una receta de shell shell y pegarla en su terminal o en su "aplicación de notas".

2. Sobre las implicaciones de seguridad. Por supuesto, puede que esté copiando algo que no sabe si está dañando y, de hecho, está oculto, por lo que puede engañar a los usuarios avanzados. ¿Es esto tan simple como agregar una advertencia al copiar / pegar caracteres de control? ¿Debería pintarse una cuerda especial cada vez que encuentra un personaje de control? Bueno, supongo que dependerá de la aplicación que consideremos.

Espero que esta respuesta inspire a alguien más a expresar pensamientos internos. Estaré actualizando esta respuesta si siento que puedo agregar algunos pensamientos más valiosos.

Los terminales permiten una entrada arbitraria porque son exactamente eso: terminales . Emulan dispositivos físicos antiguos que funcionan sobre una línea serie. Copiar y pegar se introdujo con fuerza en ese modelo, sin ningún pensamiento real sobre la seguridad.

De hecho, en el antiguo modelo Unix + X11, la seguridad se garantizaba al evitar que personas externas enviaran eventos sintéticos. Que el propio usuario esté copiando y pegando fragmentos de datos malvados no se consideró una amenaza.

Los terminales comenzarán a tener cuidado si ocurre algún ataque real, lo que obligará a los desarrolladores a tomar medidas para evitar el ridículo absoluto.

En cuanto a:

  

¿Existen casos de uso para poder pegar caracteres de control (que no sean \ t, \ r, \ n) en un terminal?

Su interacción con TUI s es a través de estos caracteres de control. Poder pegarlos significa que puedes usar esta función para semiautomatizar tu interacción con los programas TUI.

Hace algún tiempo, ahorré a mi departamento muchas horas de trabajo apresurado al ingresar manualmente cientos de registros de múltiples campos en formularios TUI, al tomar los datos que necesitábamos para ingresar desde un CSV, interpolando los caracteres de control necesarios para navegar por el TUI (a través de sed creo), validando el resultado y pegándolo en el terminal. Todo toma unos minutos.

Mostrarles esto fue como agregar una función de importación a cada forma del programa TUI. Descubrieron que era una técnica muy útil, un verdadero ahorrador de tiempo.

Sin embargo, dependiendo del caso, esto podría ser algo peligroso. Si un valor de entrada no es válido o si la secuencia de control es incorrecta y el programa TUI responde de forma inesperada, el pegado no se cerrará; continuará y hará quién sabe qué con el programa TUI.

En nuestro caso, fue sencillo garantizar que las entradas fueran válidas, probar un ciclo (suficiente de pegar para ingresar 1 registro y regresar a la posición inicial) fue suficiente para asegurar también que los caracteres de control estuvieran bien, y También se tomó un momento para considerar lo peor que podría pasar si en algún momento esta pasta en particular pudiera interpretarse fuera de contexto.

Esta fue una solución ad hoc rápida y sucia para un problema un tanto raro. Dado más tiempo, podría haber sido mejor aprender a escribir expect primero para al menos salir del Primer error detectado e informe donde se atascó. Sin embargo, teníamos algo de prisa, por lo que no podíamos considerar algo que necesitábamos para invertir tiempo en aprender primero, especialmente cuando ya aceptamos cuánto demoraría hacerlo manualmente. La simplicidad y la facilidad de pegar nuestra interacción con un TUI en unos pocos minutos es lo que proporcionó valor sobre el uso de un script expect .