Si puede haber puertas traseras en el hardware y el software comercial, ¿pueden existir agujeros en los lenguajes de programación?

No es raro que los lenguajes de programación tengan fallas.

Un buen ejemplo está en Java: Thread.stop() ahora está en desuso.

En general, no hay una forma segura de implementarlo. No puede funcionar y ha quedado en desuso. No me hagas comenzar (de nuevo) sobre el pobre diseño de concurrencia en Java.

¿Por qué? ¿Qué hacemos con cualquier monitor sostenido por el hilo hecho para parar? Si los liberamos, existe la posibilidad de que cualquier subproceso que esté esperando en esos monitores encuentre inmediatamente un estado de objeto no válido y, si no lo hacemos, esos subprocesos se estancarán. Si adoptamos el enfoque loco de lanzar algún tipo de excepción de ‘hilo esperado detenido’ en cada hilo en ese estado, es probable que estemos lanzando un montón de excepciones inesperadas y generalmente irrecuperables en todo el resto del sistema. Lo único que puede esperar de t.stop() es la corrupción de toda la aplicación. También podría llamarlo System.fubar() (Google ‘fubar’ si no lo sabe).

Otro ejemplo famoso es char * gets(char *); que se lee de la entrada estándar en C. Una vez más, esto es inherentemente inseguro y no hay forma de evitar la sobrescritura del búfer y el comportamiento indefinido cuando se usa esa función.

gets es tan malo que es (creo) la única función completamente eliminada del lenguaje. Algunas cosas pueden quedar obsoletas, pero las implementaciones compatibles no deben proporcionar esa función. Use fgets lugar.

Hay cosas como std::auto_ptr en C ++ que se ven bastante peligrosas hoy en día, pero fueron lo mejor que el lenguaje permitiría antes de que se introdujeran las referencias móviles. Sin embargo, Thread.stop() y char * gets(char *); fueron irreparablemente malos el día que entraron y malos todos los días desde entonces.

En el idioma, no.

En la implementación del lenguaje (compilador, intérprete, tiempo de ejecución, bibliotecas) sí.

Por supuesto, si utiliza compiladores y bibliotecas de código abierto y ha estudiado personalmente su código, es poco probable que algo como una “puerta trasera” esté al acecho allí sin ser notado. Pero la mayoría de las personas no estudian personalmente el código.

En el idioma, no. En el compilador o intérprete que usa, o en algunas de las bibliotecas que usa, sí. Eso le sucedió a Apple no hace mucho tiempo. Alguien modificó una de las bibliotecas y la colocó en uno de los espejos, y luego esto se incluyó en muchas de sus aplicaciones “aprobadas”.

Bueno, los lenguajes de programación (al menos los principales) rara vez están diseñados por unas pocas personas (tal vez algunas personas pueden tener la última palabra en caso de controversia, pero es poco probable que los cambios en un lenguaje de programación no se analicen), por lo que inserta deliberadamente la sintaxis eso por sí mismo constituye una puerta trasera es poco probable.

Tampoco podía imaginar un lenguaje de programación de propósito general en el que las puertas traseras no se pudieran implementar en absoluto (creo que para hacer eso, el alcance del lenguaje debería estar severamente limitado, tal vez hasta el punto de hacerlo prácticamente inútil )

Por supuesto, esa es una cuestión completamente diferente para una implementación de lenguaje de programación (es decir, compiladores e intérpretes). El viejo y conocido artículo de 1984 de Ken Thompson Reflections sobre confiar en la confianza demuestra que es perfectamente posible alterar un compilador para que inserte puertas traseras sin saberlo desde el codificador, y de una manera que es simplemente indetectable con solo mirar el código fuente ( es decir, en el lenguaje de programación ).