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

¿Demasiadas capas de abstracción?

Vuelve otra vez uno de mis temas favoritos, el de la complejidad inherente y creciente de los sistemas de información, tratado esta vez por Ian Lance Taylor en Layered Programming. Me permito citraducir un párrafo, un poco al vuelo:

Cada vez es más difícil ser un experto en sistemas. Cuando aprendí a programar, era posible entender todo tu programa, desde el código fuente hasta el código máquina. Sin embargo, cuando escribes una aplicación moderna en Ajax esto es se vuelve imposible. Hay demasiados intérpretes diferentes. Hay demasiado código ejecutándolo. Ni arreglarlo con un nuevo nivel base por encima del procesador (el navegador(?)) ayudaría. Todo esto nos conduce a una pérdida de rendimiento a veces notable y, lo que es a veces más importante, una perdida de seguridad.

No podemos volver atrás. Pero me pregunto si podremos confluir en un modelo de programación que pueda ser comprendido en su totalidad en todas sus capas. O si las cosas simplemente van a ser más complicadas cada vez.[0]

Y no sólo me permito la cita, sino que además respondo :) Y mi respuesta (que me perdonen Alvin y Heidi Toffler) es pesimista, en el sentido de que no hay vuelta atrás al idílico pasado en el era posible comprender completa, local y globalmente un sistema. La tendencia es la de más lenguajes, más plataformas y más capas, incluso dentro de los propios procesadores y nunca la contraria.

Pero no es por los ejemplos concretos que vemos a diario por que creo que esto va a seguir siendo así, sino por el trasfondo. Los sistemas de información van evolucionando unos sobre otros y rara vez se da el caso de retroceso de una paso evolutivo exitoso[1], lo que se conoce como Ley (o hipótesis) de Dollo[2] en evolución biológica, que nos vuelve a dar un ejemplo de uno de mis juegos mentales preferidos, el paralelismo entre sistemas biológicos e informáticos [3]. A quien mejor he leído referirse a este paralelismo es a Richard P. Gabriel en su Objects Have Failed y que explora de nuevo en Design Beyond Human Abilities (pdf)

No obstante, a pesar de la tendencia natural, creo que uno de los deberes de un diseñador, arquitecto, desarrollador, programador o comoquierallamársele es contener en lo posible la complejidad del sistema global [4]


[0] El primer comentario apunta, yo creo que con acierto, a "The Law of Leaky Abstractions" de Spolsky.
[1] Existen sistemas que tienen diversos enfoques o paradigmas, que yo asimilaría a distintas ramas evolutivas. La tesis de Dollo aplicada a los sistemas informáticos sería válida sólo en el progreso de una rama evolutiva. En diversas ramas evolutivas se pueden dar una tendencia y la contraria, claro...
[2] Hablé hace tiempo de esta ley en La ley de Dollo y los sistemas informáticos
[3] Otro ejemplo de dicho paralelismo podría ser el del monocultivo, del que escribí hace ya mucho en Los peligros del monocultivo y Los peligros del monocultivo (de nuevo)
[4] Conviene recordar un par de mantras clásicos: "Controlar la complejidad es la esencia de la programación de ordenadores" de Brian Kernighan y "Cualquier problema de computación puede ser resuelto con un nuevo nivel de indirección, excepto si el problema es que hay demasiados niveles de indirección" de David Wheeler (La exactitud de esta última es dudosa, pero me gusta esa versión)

La misma entrada y más comentarios en ¿Demasiadas capas de abstracción? en barrapunto

Programando con threads: algunos enlaces

Algunos enlaces a tener en cuenta si programas con threads:

• "Avoid Calling Unknown Code While Inside a Critical Section" por Herb Sutter. Como simepre, las secciones críticas cuanto más pequeñas mejor, pero además conviene saber qué es lo que se llama en ellas... (Me recuerda un poco al mantra Trata el código de los demás como si fuese tuyo)
• "Single Threaded Memory Model" de Ian Lance Taylor: como comentaba hace ya mucho en Los peligros de programar con threads el compilador puede llegar a hacer optimizaciones que den al traste con la intuitiva atomicidad de algunas variables cogidas por mutex. Pues bien, aparentemente ese problema que podría parecer remoto se puede reproducir con gcc. La solución, como siempre, conocer bien el estándar y el uso de volatile. De todos modos queda patente que se necesita algo parecido a un modelo de memoria que tenga en cuenta la concurrencia, como se comentaba también en Threads y C++(estándar)

Programando con threads: algunos enlaces 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

¿Testeo o corrección?

Andaba yo descubriendo otro blog, el de Andrew Koenig, cuando, a raíz de dos post suyos seguidos (uno de aserciones contra excepciones y otro sobre la depuración) he reparado en el tema... últimamente se hace mucho hincapié en el desarrollo guiado por pruebas, pero según se puede ver en el segundo post, hay veces que las pruebas, e incluso el uso, no son garantía de corrección.

Por eso es tan importante que las pruebas sean realistas. Por eso es tan importante extraer información del sistema en todas la etapas del ciclo de vida. Por eso es tan importante un buen sistema de registro del sistema. Pero sobre todo, por eso es importante pensar bien antes de codificar.

También me ha recordado uno esos principios de desarrollo polémicos: Los fallos, cuanto antes mejor (Fail Fast). Es uno de los principios en el diseño de Erlang. Como dice Joe Armstrong en una entrevista reciente:

La filosofía de Erlang fue siempre construir sistemas con un montón de procesadores baratos y permitir que fallen. No prevenimos el fallo; vivimos con él y recuperamos el sistema cuando ocurren.

Hay que recordar que se trata de fallos irrecuperables, no de casos raros dentro de la lógica del programa. Es mejor dejar claro un error fatal que tratar de continuar cuando no se puede y que se pierda el rastro de lo sucedido...

Por supuesto el título es falaz, debería haber sido Testeo y corrección y todos contentos, pero espero que se me permita el recurso :)

¿Testeo o corrección? en barrapunto

El mejor código es el que no existe

Bueno, la frase es demoledora y como toda frase lapidaria, conviene matizarla. Pero contiene tanta sabiduría (pesimista o realista, tu eliges) que creo que debe convertirse en uno de los mantras a repetirse frecuentemente.

Me lo recordó hace unos días la entrada de Jeff Atwood, The Best Code is No Code At All, muy recomendable. Si, antes de codificar, de desplegar miles de millones de líneas de código hay que pensárselo muy bien. Codificar es divertido, es muy estimulante... Pero antes de empezar, antes de abrir siquiera el editor debería pasar por la cabeza, en alguna milésima de segundo, al menos alguna de estas preguntas:

• ¿Debo escribir este código?
• ¿Estaré reinventado alguna rueda?
• ¿Soluciona el problema que quiero solucionar?
• ¿Se puede hacer mejor, más compacto, más legible, solo pensando un poquito antes de teclear?

Ya decía que conviene matizar: el programa vacío no hace nada y parece que es bueno que los programas hagan algo :) Se trata de un un recordatorio ¡Cuidado con el exceso de código! Creo que no hay aberración mayor que valorar la producción por líneas de código; es como si pagaran por bugs cometidos...

Jeff cita otro artículo en el que se exhorta a comenzar con código minimalista y completarlo a través de test. Es una buena idea, pero en estos tiempos de exaltación del Test-driven development conviene recordar también que los test no lo son todo, que pararse a pensar sigue siendo imprescindible.

En resumen serás esclavo de tu código, así que piénsatelo bien ;)

El mejor código es el que no existe, en barrapunto

Programación y mantras

Todos tenemos los nuestros. Bueno, igual todos no. Pero es útil a veces recurrir a mantras, adagios, frases... esto de la programación es un arte, una intuición, una ciencia, un camino hacia la iluminación.. :) en ese camino nos ayudarán dichos que condensan la sabiduría de nuestros predecesores. Frases que sobre todo te avisan de los peligros, que te recuerdan que debes estar alerta y no caer en un descuido, un error de diseño o implementación que deberás mantener y hacer compatible hacia atrás ;)
Un repasillo a las que más me gustan:

• KISS (Keep it Simple Stupid!, mantenlo simple, estúpido)
• DRY, Don't Repeat Yourself, no te repitas
• No hay bala de plata
• Elige la herramienta adecuada a cada tarea
• Las variables (y clases) son sustantivos, las funciones (y métodos) verbos
• Si no está probado, no funciona (If it's not tested, it's broken)
• No escribiré un Daily WTF ;)

Lista actualizada:

• Libera pronto, libera a menudo

Lista actualizada(2):

• Chequea las entradas
• Los fallos, cuanto antes mejor (Fail Fast)(esta más controvertida...)

(Se admiten sugerencias para completar la lista...)

Se pueden encontrar más recomendaciones breves en la lista de reglas de "The Pragmatic Programmer" (libro por cierto muy recomendable)
Ahora sólo hay que ser lo suficientemente listo para saber aplicarlas correctamente ;)

(Actualización: Gracias a Juanjo-Blackshell por el meneo en Menéame: Programación y mantras ;))

La misma entrada en BP