Erlang 5.7/OTP R13A: soporte para Unicode, mejoras en multicore y SSL

Acaba de salir la nueva versión del conjunto Erlang/OTP, en concreto la versión Erlang 5.7/OTP R13A. La nueva versión de un lenguaje y sus librerías no tiene por qué ser gran noticia, pero en este caso las novedades son tan notables que creo que merece una mención. Entre ellas se encuentran importantes mejoras de rendimiento en entornos multicore y SMP, que es especialmente importante teniendo en cuenta que una de las grandes bazas del lenguaje es su tratamiento de la concurrencia. Además destacan también el soporte para Unicode, posibilidad de usar WxWidgets a través del WxErlang (de momento en beta) y reescritura del soporte para SSL. Muchas de estas características eran necesarias para la introducción de este lenguaje más allá del entorno de las telecomunicaciones que históricamente ha sido su nicho natural. Más comentarios en reddit y Hacker News

La misma entrada y más comentarios en Erlang 5.7/OTP R13A: soporte para Unicode, mejoras en multicore y SSL en barrapunto

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