Aprendiendo de los errores (II)

Dan J. Berstein reconoció una vulnerabilidad en djbdns y la recompensó con mil dólares y por supuesto no se han hecho esperar reflexiones acerca de la seguridad informática, su (im)posibilidad y su relación con lo disponible del código.

Entonces leo con interés, vía el nuevo subarrapunto de fernand0, un comentario en hispasec que no por evidente debe dejar de repetirse: no existe software sin fallos de seguridad, pero los que menos tienen son aquellos que han sido diseñados y programados desde su inicio con la seguridad y la simplicidad como guía.

Y ello descarta a casi todo el software y probablemente más al comercial, que tiene más presiones para añadir más y más cosas. Recordemos, que como decía Alan J. Perlis A la larga cualquier programa se vuelve rococó. Después escombros. Lo de siempre, funcionalidad contra robustez y simplicidad :)

De todos modos el caso de djbdns es también interesante por el tipo de fallo encontrado. En Hacker News comentaban que el problema era en la implementación de la compresión que usa en el protocolo DNS para sus paquetes, para eliminar redundancias. Y precisamente Bernstein había hablado negativamente del método de compresión (descrito, claro, en el RFC 1035, 4.1.4, página 30) Extractando de la crítica de Bernstein:

Un problema con la compresión DNS es la cantidad de código necesario para analizarla. Localizar de modo fiable los nombres lleva un trabajo que habría sido evitable para una caché DNS. La compresión LZ77 habría sido mucho más fácil de implementar.

Otro problema con la compresión DNS es la cantidad de código necesario para generarlo correctamente. [...]

Otro problema con la compresión DNS es que no es particularmente efectiva. LZ77 habría funcionado mejor en esos tipos de datos y funcionaría mejor con los tipos de registros que se popularizarían en el futuro [...](Y aquí habla de incompatibilidades de algunas versiones de BIND con el RFC)

Muy interesante todo el texto original, incluidas las elipsis ;) anque bastante específicas del caso DNS. Lo que no me ha quedado claro es la razón de no usar LZ77, si fue un caso de Síndrome NIH, de hackerismo o tenía algo que ver con las patentes sobre estos tipos de compresión que llevaban haciéndose desde 1984 como la del LZ78. Pero vamos como regla general parece mucho mejor usar un algoritmo conocido que inventar uno nuevo, a no ser que trabajes en eso, en innovar...

Creo que la moraleja es clara, como se dice a veces exagerando el mejor código es el que no existe sobre todo desde el punto de vista de la reducción de bugs y aún más si se trata de seguridad.

(Esto se llama Aprendiendo de los errores (II) porque ya escribí en su día Bugs antiguos y moralejas , que iba sobre lo mismo, también salía DJB y el DNS, en aquel caso con el bug/error de diseño que explotó Kaminsky)


La misma entrada y más comentarios en Aprendiendo de los errores (II) en barrapunto

Varios sobre concurrencia: los peligros de 'Lock-Free' y JVM

Ración de varios sobre concurrencia:

• "Lock-Free Code: A False Sense of Security" de Herb Sutter que viene a decir algo que por aquí intuíamos:

  [Lock-free code is] hard even for experts. It’s easy to write lock-free code that appears to work, but it’s very difficult to write lock-free code that is correct and performs well. Even good magazines and refereed journals have published a substantial amount of lock-free code that was actually broken in subtle ways and needed correction.

  es decir, entre otras cosas, recordar ser humildes.
• Si aún siendo humildes queremos saber más sobre estos temas podemos echarle un vistazo a "Just What-the-Heck is a 'wait-free' algorithm?" de Cliff Click en el que repasa este tipo de algoritmos que según los que saben de ésto aún son más difíciles de codificar que los 'lock-free' (son un subconjunto de ellos no obstante)
• The Java Memory Model in 500 Words Un breve resumen, casi chuleta, del modelo de memoria en Java.
• Si lo que nos interesa son más las implementaciones que las especificaciones podemos echar un vistazo a The Hotspot Java Virtual Machine, una completa presentación con detalles de implementación de dicha máquina virtual. Repasa compilación, sincronización, recolección de basura y posibles direcciones de investigación.

La misma entrada y más comentarios en Varios sobre concurrencia: los peligros de 'Lock-Free' y JVM en barrapunto

La humildad como virtud del programador

Y no me refiero a modestia frente a los otros (que también puede ser una buena cualidad) sino humildad con uno mismo y con lo difícil de hacer realmente bien este trabajo. En este sentido, sin más, le cedo la palabra a Jonathan Edwards, quien en Beautiful Code dice:

Una lección que he aprendido por la vía difícil es que no somos lo suficientemente listos. Incluso los programadores más brillantes cometen errores estúpidos con frecuencia. No solo errores de tecleo (typos) sino errores básicos de diseño que ponen en una situación difícil al código, y que a posteriori deberían haber sido obvios. La mente humana no es capaz de comprender en su conjunto la complejidad de un programa de tamaño moderado, mucho menos los sistemas monstruosos que construimos hoy en día. Esta es la amarga pastilla que nos tenemos que tragar, porque programar atrae y recompensa al inteligente, y su cultura fomenta la arrogancia intelectual. Me ha ha sido de inmensa ayuda trabajar con el supuesto de que soy demasiado estúpido para hacer las cosas correctamente. Esto me hacer usar de modo conservador aquello que ha funcionado, testear cautelosamente las nuevas ideas antes de confiar en ellas y por encima de todo, apreciar la simplicidad.

Curiosamente habla de un libro que me gustaría mucho adquirir y cuya existencia comenté por aquí.

Sobre el mismo tema, me gustaría recordar una famosísima cita de Brian Kernighan:

Depurar es el doble de difícil que escribir el código por primera vez. Entonces, si escribes código tan inteligentemente como te sea posible, no vas a ser, por definición, suficientemente listo para depurarlo.

Actualización: Creo que no ha quedado claro (he escrito la entrada demasiado rápido), pero lo que me parece curioso del comentario de Jonathan Edwards, es que es una justificación de porqué no escribió en Beautiful Code a pesar de estar invitado para ello, con una explicación tan inspirada que irónicamente merecería estar en el libro... :)

La humildad como virtud del programador en barrapunto