EM Hernández-Novich

Es una herramienta útil para evaluar la protección de una operación a través de los ojos de un tercero.

---

Hay una proporción increíblemente grande de gente con responsabilidades de operación que cree que la seguridad es un «destino» que se alcanza como una suma de políticas, procedimientos y prácticas sustentadas por aplicaciones. Quienes se dedican a las Pruebas de Penetración no solamente deberían exhibir las debilidades de forma práctica, sino también contribuir a educar a esas personas para que aprendan que la seguridad es un «camino» a lo largo de cual hay que estar consciente de todos los riesgos y detenerse a considerar las vulnerabilidades.

---

Personalmente, me parece un nombre desafortunado pues la definición verdadera de «hacker» sólo está asociada a crear soluciones originales para resolver problemas, y las técnicas para evaluar la protección con estas herramientas requiere romper y causar problemas. Quisiera que la gente no usara «hacker» o «hacking» peyorativamente, y hago un esfuerzo por educar hasta que me dicen «pero todo el mundo lo dice así y hasta sale en la prensa». No se puede contra la mayoría... de las moscas.

View more

El deseo de su diseñador y usuarios de ajustarse a los tiempos modernos y revisar elementos de diseño poco afortunados han llevado a C++ a convertirse en una colección de agregados y «casos especiales» tan extensa, que la cantidad de personas que realmente lo comprenden y dominan es escasa.

---

En cierto modo, C++ se ha convertido en el «Ada del Siglo XXI»: el lenguaje que quiere hacerlo todo, pero que es increíblemente difícil de aprovechar en su totalidad. Mucha gente es capaz de utilizar C++ para lograr cosas interesantes, pero casi nadie aprovecha todo lo que C++ es capaz de hacer, y no estoy seguro que eso sea práctico ni conveniente.

---

A mi me sirve para ilustrar algunas cosas de estilo orientado a objetos, en su mayoría ejemplos nefastos de «privacidad parcial» y lo que ocurre cuando se quieren tener clases y procedimientos independientes que «cooperen». Como lenguaje orientado a objetos lo encuentro incómodo; como lenguaje imperativo lo encuentro anticuado; y los agregados para «felixbilidad» (espacios de nombres, plantillas y lambda) los encuentro terribles.

---

Los tiempos han cambiado, y la excusa de que «C++ produce programas más eficientes» ya no tiene la misma fuerza que hace 20 años.

---

En todo caso, es un lenguaje que todo profesional debería explorar, si acaso para darse cuenta de lo complicado que es trabajar con un lenguaje que trata de estar bien con $DEIDAD y con $CODEIDAD.

View more

Escoge un proyecto en el cual tengas interés, bien sea porque usas la herramienta o porque te interesa el tipo de herramientas. Inscríbete en las listas de correo y *lee*: aprende cómo funciona el grupo, seguro tienen una normativa general. Lee el Netiquette. Lee la documentación del proyecto. Lee el FAQ. Luego, según tus habilidades puedes hacer varias cosas:

---

* Contestar preguntas en las listas de correo. Por favor, no contestes preguntas que están en el FAQ: educa a la gente para que lea el FAQ. Tampoco contestes preguntas que estén en el Manual: cita el Manual e invita a leerlo. Ayuda a reducir la flojera ajena.

---

* Ayuda a mejorar la documentación. Escribir páginas de manual (man pages), recopilar FAQs, construir ejemplos. Si dominas el inglés técnico, ayuda a traducir a tu idioma nativo. Lo que tú quisieras tener, que no existe, haz que exista.

---

* Revisa la lista de defectos. Escoge uno y trata de reproducirlo. Si puedes reproducirlo, trata de encontrar más detalles y agrégalos a la información. Si crees tener una solución, escibe el parche y envíalo.

---

* Algunos proyectos requieren hardware para probar y tienen plataformas distribuidas con máquinas puestas por voluntarios, con acceso remoto, en las cuales construir y probar. Si tienes disponibilidad de hardware, intégralo a la plataforma de pruebas.

---

El poder de uno es hacer algo. No preguntes qué hacer: aprende a identificar lo que hace falta.

View more

No se puede ser papá de todo el mundo. La disciplina es algo que se enseña con el ejemplo, pero se aprende sólo por convicción.

---

Aquel que no desarrollo la paciencia, la constancia, la atención al detalle, el estudio de las alternativas, y el pensar en los problemas antes de atacarlos, siempre será un excelente echador de líneas de código en el lenguaje moderno de turno. Y por eso se lo merecen.

---

Programar es fundamentalmente pensar en el problema, diseñar la estructura de datos que lo modela, y luego expresar las relaciones (que serán obvias si el diseño es correcto). Apurarse en el diseño lleva a perder tiempo. Perder tiempo lleva a improvisar. Improvisar lleva a crear nuevos problemas. Y así en el círculo vicioso de «coding». Súmale a ésto la terrible selección de lenguajes de programación típica de la industria moderna, y la necesidad de «tener algo para mostrar» porque la improvisación ajena se convierte en la urgencia del que tiene que hacerlo funcionar.

---

La recomendación que tengo es la misma que hago a estudiantes y colegas: no lo dejes para última hora, no comiences a programar si no comprendes completamente el problema, no escribas ni una sola línea de código hasta que la estructuras de datos representen el problema, y no insistas en arreglar algo que está mal diseñado.

---

Pero todo el mundo es sabio en su propia enciclopedia.

View more

Supongo que con «programación probabilística» te refieres a un tipo de estructura de control en el cual el camino de ejecución se selecciona de manera «no determinística». Por ejemplo, entre varias alternativas viables se escoge una empleando probabilidades (uniforme o sesgada con algún criterio usualmente de retroalimentación). La diferencia importante es que lo hace el ambiente de ejecución del lenguaje — el programador no tiene que expresar el mecanismo de selección, si acaso la política (i.e. no se escribe la «lanzada del dado» ni la «acumulación de historia», eso lo hace el lenguaje).

---

Ese tipo de lenguajes de programación existe hace mucho tiempo y es utilizado para simulación de procesos estocásticos, y también son aplicables a escenarios en los que el backtracking puro (como el de Prolog) es muy oneroso y «poco astuto».. En ese nicho, los conocedores aprenden a usar esos lenguajes en lugar de «reinventar la rueda mal» en cualquier otro lenguaje «popular».

---

Para ese tipo de problemas, ese estilo de programación será necesario, y por eso existen (y seguirán existiendo) los lenguajes especializados para hacerlo. Con un lenguaje de propósito general se puede simular este comportamiento.

---

Ese estilo de programar no sirve para todos los problemas, así que será uno de muchos estilos disponibles.

View more

Eso depende de tus necesidades y el uso del equipo. Yo tengo equipos en los cuales no hay posibilidad de improvisar: corren software estable y no se actualizan hasta que sea realmente comprobable que todo va a funcionar bien. Pero también tengo equipos en los cuales instalo cuanta cosa sale que quiero probar -- si ese equipo se «rompe» usualmente puedo arreglarlo en cuestión de minutos porque sé lo que estoy haciendo y dónde me estoy metiendo, pero no es responsable hacer eso en equipos de producción.

---

¿Cuánto esperar? El tiempo que tus pruebas de regresión que prueban la aplicación como un todo (porque las tienes, ¿no?) corroboran que todo funciona como antes. Eso involucrará usar un «mono de prueba» para replicar la plataforma y verificar la integración de todo. Si tu aplicación depende de cierto lenguaje, librería, servicios adicionales, etc. los pruebas todos antes de migrar, determinas los ajustes que tienes que hacer, y ensayas la migración varias veces antes de hacerlo en donde te dolería que no funcionara.

---

Novedad y estabilidad son dos ejes ortogonales en el plano de la vida del software. La última versión no puede ser la más estable porque aún no ha sido probada fuera del ámbito de los desarrolladores. Dependiendo de la calidad y organización del equipo, puedes tener más confianza o no.

---

El proyecto Debian toma mucho tiempo en producir una distribución, porque se verifica la integración entre todos los paquetes, el proceso de actualización y muchos otros detalles que otras distribuciones hacen de manera menos estricta. Cuando salga Debian 9 (en abril o mayo), vas a poder actualizar desde Debian 8 sin mayores inconvenientes. Eso tiene que ver con la forma en que se lleva el proyecto.

---

Lo mismo pasa con lenguajes de programación en los cuales hay un énfasis en la estabilidad, o con aplicaciones que están alcanzando la «meseta» en que disminuye el «desorden evolutivo».

---

Hay casos interesantes, como PostgreSQL, que entre sus versiones «mayores» no tiene actualización automática, y el DBA tiene que hacer las cosas con cuidado. Al mismo tiempo, PostgreSQL produce nuevas versiones con bastante frecuencia, y es normal que existan varias versiones mayores (9.4.x, 9.5.x, 9.6.x) al mismo tiempo. En concreto, Debian 8 provee Pg 9.4.x y hoy en día existe 9.6. ¿Debo migrar inmediatamente sólo porque el proyecto PostgreSQL dice que «es bueno para mi»? Lo primero que hago es determinar si las cosas nuevas que tiene 9.6 *realmente* son necesarias *YA*; si no lo son, no hay urgencia.

---

Sólo el que conoce a fondo sus herramientas puede determinar el tiempo que necesita para pasar de una versión a otra, si es que necesita hacerlo. Por eso, ni hay una respuesta precisa para todos, ni específica para ninguno.

---

La única forma es conocer muy bien las herramientas que usas, y seguir la evolución de las nuevas versiones *mientras* se desarrollan, para que cuando sean declaradas estables, ya estés al tanto si te convienen o no.

View more

Esa es la arquitectura cliente-servidor, que funciona muy bien porque favorece la separación de preocupaciones. Independientemente del nivel de la aplicación en el modelo OSI, si el servidor es stateless, el cliente no hace procesamiento de reglas de negocio, y los mensajes son autocontenidos, va a funcionar bien -- el asunto es que los diseñadores e implantadores tienen que tomarse su tiempo en hacer el trabajo correctamente.

---

Los «millenials» hablan de Front-End y Back-End usando servicios web, pero antes se hablaba de la Presentación y el Procesamiento usando un «Object Exchange Bus» (que era más general que servicios web, pero que pocos sabían aprovechar). Antes de eso se hablaba de «cliente-servidor» sin tanto adorno, porque eso es lo que es. Y mucho antes de eso, los «melenials» hablaban del «Terminal Inteligente» (un 3270 o 5250) que capturaba una «pantalla de datos» y la enviaba hacia el «mainframe» para su procesamiento.

---

Mismo musiú con diferente cachimbo.

View more

El manejo de excepciones existe como una solución a la necesidad de escribir programas robustos que reaccionen correctamente ante situaciones anómales (síncronas o asíncronas), separando el «flujo normal» del «flujo excepcional». Más aún, tiene propiedades sintaćticas verificables a tiempo de compilación que son muy útiles.

---

Antes de tener excepciones, los programas robustos estaban salpicados de if-then-else: un bloque para verificar «todo bien» y otro para «todos vamos a morir». Las llamadas a librería que podían fallar, tenían que devolver «valores mágicos» para indicar si hubo error o no, y el invocante tiene que verificarlos. Si has programado en C y no verificas los open(), close(), read(), write(), malloc(), free() (si, free(), no es un error) tu programa no es muy robusto — estrellita si sabes usar errno y lo haces con elegancia y categoría.

---

Un lenguaje que no tenga excepciones no es mejor que C en ese aspecto. En Go, para «mejorar» el asunto, las funciones pueden retornar dos valores: el que se supone que es el valor de retorno, y otro para «indicar cosas», en particular errores. Nefasto.

---

La aritmética de apuntadores existe en C como un artefacto para poder sacar provecho de los modos de direccionamiento de los procesadores. Surgió en una época en que se sabía poco sobre mejoramiento de código, los compiladores eran más artesanales que ahora, y satisfacían la necesidad de expresar transformaciones de manera sucinta. Se pueden hacer cosas maravillosas con aritmética de apuntadores, al igual que con una motosierra y una panela de hielo. No son malos, son «distintos». De ahí el dicho que «en C no hay arreglos» que perturba mucho a los estudiantes que creen saber C.

---

Go no incluye aritmética de apuntadores, porque todo lo que se hacía truculentamente de esa forma ya puede ser producido por cualquier generador de código moderno. Tener aritmética de apuntadores sería incivilizado.

---

Si sumamos las dos cosas que acabamos de describir, con otros pro (expresión de co-rutinas, algunas optimizaciones en el generador) y muchos contra que tiene Go (simulación de objetos, despacho simple sin posibilidad de indirecto, «tooling», distribución de software), se puede medir objetivamente que desde el punto de vista de diseño e implantación de lenguajes de programación, es un poco mejor que C99, pero no pasa de ser lo mejor que los 80 puede ofrecer.

---

I wouldn't go there.

View more

No se trata de lo que yo crea, sino de lo que es económica y evolutivamente razonable.

---

Aquellos componentes de software que son «mercancía simple» («commodities» en inglés) eventualmente se vuelven Software Libre, y sus versiones no libres desaparecen o son dramáticamente inferiores. Por ejemplo, servicios DNS (BIND9, PowerDNS y unbound dominan, siendo todos libres), MTAs (postfix, sendmail, hasta exim que es una farsa, son superiores al MTA de Exchange), y podemos buscar otros más, pero no hay espacio aquí.

---

Aquellos componentes que son de «plataforma» usualmente van a la par de sus equivalentes no libres. Por ejemplo, PostgreSQL no es menos que Oracle, y a veces es bastante más; con las herramientas de oficina, de procesamiento de imágenes, de audio y música digital la brecha es algo mayor. En estos casos, la escogencia entre uno y otro usualmente tiene que ver con las competencias del usuario y su habilidad para resolver problemas por su cuenta. A medida que aumenta la gente que «sabe lo que hace», escoger el Software Libre es más frecuente, con lo que se perfecciona a menor costo que lo que requiere el no libre. A la larga, el no libre pierde fuerza.

---

Aquellos componentes que son muy especializados rara vez son Software Libre (aunque muy probablemente están construidos con Software Libre). Por un lado, porque las organizaciones que los crean están interesadas en su explotación, quizás como servicio, en lugar de su distribución. Por otro lado, porque es muy poca la audiencia especializada que comprendería lo que hace y que podría ponerlo en uso — al menos en el presente de la tecnología. Ante la disyuntiva de hacerlo abierto o no, la Teoría de Juegos te permite demostrar que lo mejor es no hacerlo abierto, y eso hacen las organizaciones — porque el usuario recibe menos beneficio.

---

Y finalmente llego al punto de mi argumento. Para que un componente de software necesariamente sea libre, tiene que maximizar el beneficio para el usuario final, con el mínimo camino de esfuerzo para el productor. Así, los «commodities» son necesariamente libres, porque la mayoría de usuarios (muchos de ellos sin conocimientos sobre la tecnología) se benefician con mínimo esfuerzo; los de plataforma se hacen libres (hasta volverse «commodities») a medida que crece el número de usuarios interesados en aprovecharlos. Los «especializados» se mantienen cerrados hasta que haya suficientes usuarios interesados como para que el creador del software deje ir su «ventaja de oportunidad».

---

Transversal a todo esto están las herramientas de desarrollo (lenguajes, «toolchain», editores, construcción de documentos). Histórica y factualmente, todas las herramientas de desarrollo fabricadas como Software Libre son en promedio más exitosas, consistentes, y flexibles, que aquellas fabricadas como software no libre. Creo que puedo contar las excepciones con los dedos de una mano, y todas son en nichos de desarrollo muy especializados que para el usuario frecuente son irrelevantes.

View more

Si.

---

Perl es la mejor implantación de LISP imperativa que vas a encontrar. Si no sabes programar en LISP, te estás perdiendo de una de las experiencias más alucinantes y transformadoras en la vida de un programador. Además, Perl tiene una comunidad de usuarios particularmente creativa, que pone a disposición una biblioteca de soluciones sumamente interesante. Más aún, Perl 5 (que es lo que usarías en «producción») se ha nutrido de las invenciones y cultura de Perl 6, así que se ha mantenido pertinente. Finalmente, el diseño de Perl incluye aspectos de lingüística que son muy sutiles de percibir para el que no es cuidadoso en el uso del lenguaje; no es un lenguaje confuso, sino que confunde al desprevenido y poco detallista.

---

No obstante, Perl tiene un problema de consumo de memoria asociado a algunas de sus librerías de más alto nivel (DBIx::Class, Catalyst) que te puede afectar en aplicaciones que mueven muchos datos o que tienen tiempo de vida en ejecución (demonios o servidores de aplicación semi-persistentes). Eso es derivado de la cantidad de capas de abstracción involucradas. Afortunadamente, las herramientas para hacer análisis de desempeño y «profiling» son de la mejor calidad, llevándote rápidamente a encontrar la causa y (posiblemente) permitir la mejora de la aplicación.

---

Perl 6 todavía es muy lento para ser práctico. No obstante, ha cambiado el enfoque en los elementos superficiales del lenguaje (la sintaxis) que confundían a mucha gente. Así mismo, incluye un sistema de objetos más avanzado (el mismo de Moose en Perl 5, sólo que «en core») que casi cualquier otro disponible (con la excepción de Common LISP Object System y Smalltalk con Traits). Me preocupa que las «expresiones regulares» hayan aumentado de poder y expresividad, y las personas que no están preparadas no las puedan usar efectivamente o se disparen en el pie al hacerlo.

---

Ambos son lenguajes con verificación dinámica o parcialmente estática (muy pocas partes) y eso requiere muchísima competencia por parte del programador para no cometer errores tontos. Hoy en día prefiero un lenguaje con un sistema de tipo de datos estático como Haskell. Perl seguirá siendo uno de mis favoritos pues dadas mis competencias, rara vez meto la pata y muchas tareas (de administración de sistemas y operaciones) se resuelven mucho más rápido.

View more

Las dos cosas.

---

Si te van a contratar para usar el lenguaje X y no lo sabes usar, o lo quieres usar como otro lenguaje que conoces, lo estás haciendo mal. No hay nada de malo en decir que no sabes usar X pero lo vas a aprender a usar correctamente. Si sólo sabes el lenguaje P y quieres usar todos los demás lenguajes como si fuera P, no estás siendo un profesional competente ni tampoco inteligente.

---

Por otro lado, para tener destrezas en resolver problemas correctamente es necesario dominar varios lenguajes de programación y los diferentes estilos de programación (imperativa, orientada a objetos, por eventos, reactiva, funcional, lógica, concurrente, paralela), y para cada problema hay un lenguaje adecuado. Este es el escenario cuando te contratan para resolver un problema particular con el lenguaje P, y tienes la habilidad para explicar por qué el lenguaje P es una mala idea, y el problema en particular se resuelve mejor con otro lenguaje.

---

Eso no se puede lograr a menos que estudies muchos lenguajes y estilos de programación.

View more

Muchos lenguajes tienen un manual que describe el léxico y la sintaxis claramente. La mayoría también incluye una descripción general de la semántica de las instrucciones, generalmente operacional expresada en lenguaje coloquial. Allí encontrarías respuesta a esas preguntas de alcance, secuencia de llamada, excepciones síncronas, excepciones asíncronas y las generalidades. Son muy pocos los lenguajes que incluyen todo eso, y además incluyen descripciones matemáticas completas de la semántica de todas y cada una de las instrucciones, usando semántica denotacional -- eso no quiere decir que el lenguaje sea bueno, sólo que sus diseñadores e implantadores se tomaron la molestia (o los molestaron) en hacerlo. Aunque un lenguaje bueno tendría todo eso, porque haría que su implantación no tuviera ningún elemento discrecional ni ambiguo.

---

El problema es que la mayoría de la gente no lee los manuales. Otro problema es la gente que viene a preguntar, le preguntas si leyó el manual, y se ofende porque uno se pone a leer el manual delante de ellos. Se ha perdido el aprecio por la cantidad de cosas maravillosas que uno puede aprender leyendo los manuales...

---

Muchos lenguajes, sobre todo modernos y «populares», usan terminología formal de manera muy informal y a veces de manera aventurada o francamente propagandística. En estos casos, tienes que saber escribir programas de prueba para comprobar si los «iteradores» que te ofrecen son iteradores de verdad o no; lo mismo para las clausuras. Para escribir esos programas de prueba, tienes que haber estudiado la teoría de lenguajes de programación, haber experimentado con otros y comparar los resultados.

---

Si alguna vez escribes un interpretador o un compilador para un lenguaje, tienes experiencia de primera mano en lo que «se puede» y lo que «no se puede» hacer en un lenguaje, así como las cosas plausibles o no. Y en estos casos ni siquiera vas a tener que leer un manual para poder decir «embuste» cuando PonyScript te diga que tiene true recursive continuation-based iterators o un tipo de datos general para representar conjuntos y sus operaciones.

---

El papel lo aguanta todo. Los wikis de lenguajes aguantan todo y además hay montones de manos metidas. Después de cierto tiempo practicando, cuando sale un lenguaje nuevo, basta uno o dos programas de prueba para golpearlo dónde le duele y poder concluir si es uno más del montón o si tiene realmente algo interesante.

---

Requiere práctica y curiosidad.

View more