Estamos en medio de la mayor crisis de seguridad informática en la historia de la informática. La gente que crea el software detrás de cada dispositivo de cierta importancia -la gente que crea Apple, Google, Microsoft, una amalgama de fabricantes miserables de chips que quieren vender cosas, no arreglarlas, y los bien intencionados desarrolladores de Linux que quieren arreglar cosas, no venderlas- están todos contentos de escribir código en lenguajes de programación que sabemos que son inseguros.
|
etiquetas: pegasus , código , internet 
![Snowden: Tenemos que hablar sobre la industria de la inseguridad [inglés]](https://peta.meneame.net/backend/media?type=link&id=3534606&version=0&ts=1627385346&image.jpeg)
Es sobre lo complejo que es todo esto y lo llevo pensando mucho tiempo. Por un lado fabricantes que solo ven su negocio y quieren vender, si es algo inseguro da igual. Gente que quiere programar rápido y el resto le da igual. Consumidores que quieren tal utilidad y el resto le da igual.
Entre ineptitud, consumismo y gente malvada está todo bastante jodido.
Voy, voy.
www.meneame.net/m/tecnología/culpar-rusia-ciberataques-mal-enfoque-pr
Asi que complica bastante las cosas si, por ejemplo, alguien quisiera meter alguna mierda de esas en Linux.
De hecho, el propio Google está pagando a un desarrollador para que se meta Rust como segundo lenguaje en el kernel.
pluralistic.net/2021/07/27/gas-on-the-fire/#a-safe-place-for-dangerous
Snowden describes NSO as part of an "Insecurity Industry" that owes its existence to critical vulnerabilities in digital devices in widespread use. They spend huge sums discovering these vulns – and then, rather than reporting them so they can be fixed, they weaponize them.
As Snowden points out, this is not merely a private sector pathology. Governments – notably the US government, through the NSA's Tailor Access Operations Group – engage in the same conduct.
Otra cosa es que los programadores no entiendan el modelo de memoria de C++, lo cual es culpa del lenguaje (poca broma con esto) porque en fin, buena suerte cuando tengas que:
- Distinguir una referencia de todo lo demás
- Entender qué elementos se pueden pasar a un contenedor de la STL
- Entender qué es el ownership de un puntero
- Sin mencionar concurrencia y paralelismo, que entonces me da la risa
Y el problema también es que -por lo general- quien empezó a programar en C++98 no se va a empapar las plantillas variádicas de C++11 o las maravillosas lambdas, no te digo ya el folding de C++17 o cualquier novedad de C++20. Una pena, porque las novedades del lenguaje son en términos generales una barbaridad.
En general creo que C++ es bastante más polivalente que Rust, pero bastante menos seguro por el gran esfuerzo que supone entender una mínima parte de su modelo de memoria. Los entes del comité ISO de C++ simplemente asumen que el programador sabe lo que hace, y así ha pasado, que la gente intenta sobrevivir a su jefe día sí día también, y parche sobre parche se hace un remierdo.
Es que me hace gracia que han pasado 10 años desde C++11, lo que decía de los smart pointers, y todavía C++ sigue siendo considerado un pozo de problemas de este tipo. En fin.
Aun así, siendo el monstruo que es, a poco que el comité en su torre de marfil tenga a bien quitar la retrocompatibilidad (equivale al "ojalá" de tu comentario :P), es posible que no tenga nada que envidiarle a la seguridad de Rust.
PD: Perdona si te molesté en el primer párrafo, pero quería escribir sobre mi libro
No tengo mucha experiencia práctica con Rust, solo un par de cursos y el famoso The Book que distribuyen de forma libre. Sin embargo, en los últimos 13 o 14 años he trabajado con unos 5 o 6 lenguajes y puedo entender perfectamente el tipo de errores que pretende evitar con cada decisión de diseño (ownership y borrowing checker, lifetimes, panicks, runtime checks cuando no queda más remedio, la gestión de los string en UTF-8, pattern matching exhaustivo, eliminación de los NullPointerException mediante los Options...).
Yo creo que la diferencia de Rust con C/C++ es que el primero desde el principio de su vida (cuando todavía se podía hacer breaking changes) la corrección y la seguridad han sido una consideración de primer nivel y no un parche posterior. Lo cual es normal, porque cada lenguaje es hijo de su tiempo. El frontend del compilador de Rust a mi me parece una maravilla, por la profundidad de las comprobaciones que puede hacer y lo explicativos que son los mensajes (esta claro que, sabiendo la curva de aprendizaje que añade de primeras esa complejidad, han intentado sobrecompesar para entrenar al programador en su modelo de como deben funcionar las cosas).
Pero es que luego hay cosas más sutiles como Cargo. Decía el creador de Node que, por qué usaban diferentes linkers, les suponía menos trabajo reescribir un parser de HTTP que reutilizar uno que estuviera bien probado. Con Deno, directamente usaron el crate público para parser HTTP sin más problemas. Yo veo potencial para bastantes problemas si tienes que reinventar muchas cosas de prisa y corriendo, no me extraña que luego se diga que los tiempos de desarrollo son muy largos con C/C++.
Pero vamos que también le puedes preguntar a Snowden por qué ha escrito lo que ha escrito y por qué ha enlazado a Rust como posible mejora. O leer algunos papers que se publican sobre la corrección de los programas en Rust... Seguro que lo explican mil veces mejor que yo.
Te recomendaría, si me lo permites, que le echaras un vistazo al libro o algún tutorial (los hay enfocados a desarrolladores de C++) y pienses en el efecto que puede tener cada pequeña mejora o restricción, no sólo en la reducción de la polivalencia del lenguaje.
Como habrás podido adivinar, me gano la vida picando para C++ y he saltado
Leeré el libro que me sugieres. Aprender Rust -y quizá Kotlin- es algo que tengo pendiente desde hace tiempo. De Rust hasta ahora solo he leído poco código. No lo entiendo pero se lee fabuloso.
La cosa va a peor, está claro.
Kotlin parece una mejora considerable con respecto a Java, también lo tengo en el punto de mira, quizá algún día... Dentro de la JVM, otra sorpresa para mi ha sido al tener un poco de exposición a Scala y ver que no está nada mal (me pasaba un poco como a ti, que estaba harto de lo evangelistas de ese lenguaje