Programación, seguridad, software libre ...
Aunque en Answering the Critical Question: Can You Get Private SSL Keys Using Heartbleed? tratan de resolver esta pregunta y el mensaje es tranquilizador, lo más interesante es el análisis del código responsable del problema, los detalles de la pila y ese tipo de análisis más técnicos que nos gusta referenciar por aquí.
No se si el año pasado fue el de la aleatoriedad, o que por casualidad yo encontré más lectura sobre el tema. O, a lo mejor, simplemente estaba prestando más atención.
En Myths about /dev/urandom una buena lectura sobre el tema, donde se habla de /dev/urandom, sus parecidos y diferencias con /dev/random y, al final, algunas discusiones sobre “aletaoriedad verdadera”.
I don’t want to dive into that issue too deep, because it quickly gets philosophical. Discussions have been known to unravel fast, because everyone can wax about their favorite model of randomness, without paying attention to anyone else. Or even making himself understood.
Lectura recomendable.
Podemos recomendar también la lectura de How do you know if an RNG is working? donde se aborda justamente ese tema: mucho se habla de números aleatorios y generadores. Pero cuando se piensa en la calidad de lo que se obtiene se dice que hay que medirla y poco más. Aquí da ideas, algún recordatorio interesante y, en definitiva, nos recuerda que el diablo está en (todos) los detalles.
Más sobre aleatoriedad y generadores
Interesante documento en Are We Shooting Ourselves in the Foot with Stack Overflow? donde se hace un resumen de los problemas con los aceleradores de algunos modelos de Toyota. El fallo se atribuye a un desbordamiento de memoria (concretamente en la pila) y cómo esto podía producir que determinadas variables (del sistema) se vieran alteradas, con consecuencias.
De hecho, parece ser uno de los peores casos de corrupción de variables por desbordamiento de memoria, porque en lugar de manifestarse inmediatamente (en este caso, probablemente a baja velocidad todavía) aparecía algo más tarde con las consecuencias ya conocidas.
Luego propone algunas medidas que podrían mejorar la situacion, tanto desde el punto de vista de la gestión de memoria como del sistema operativo y las pruebas (tests).
En The Toyota Owners Left Holding the Bag podemos leer una descripción que simplemente habla de ‘código espagueti’, algunas consecuencias legales, los seguros…
Actualización (2015-03-01) Nos enlazó Juanjo Navarro fernand0 @ GitHub.io y recursividad y lo agradecemos aquí. Casi seguro que volveremos sobre este enlace acerca de nuestros sesgos y enfoques. Y también que hablaremos alguna vez de lo que Juanjo hable en su sitio. ¡Gracias!
Mantengo una página web con las cosas del trabajo desde hace bastante tiempo (la primera versión que hay en archive.org tiene una página que pone 1996, pero la verdad es que no recuerdo la fecha exacta, podría ser un poco antes).
Se puede ver en Fernando Tricas WWW Homepage.
Entonces no había sistemas de gestión de contenidos ni nada parecido y la manera en que hacíamos las páginas era copiando alguna que nos gustaba y poniendo nuestro contenido.
En algún momento empecé a gestionarla de la siguiente manera: mantenía una copia local donde editaba; cuando estaba satisfecho (o quería ver los cambios) copiaba los ficheros cambiados al servidor (con un programita que busca los ficheros que han sufrido cambios desde la última versión y scp).
El objetivo era doble: evitar editar en el servidor, y tener una copia de seguridad local (que se sumaría a la que nos hacen en el servidor).
En su momento (allá por el 2004) integré un blog con la página (esencialmente publico en la página los titulares de mi blog docente -por cierto, por si alguien le interesa lo mantengo con PyBlosxom-). La página web sigo usándola para información más permanente (aunque tengo compañeros que han dado el salto a blogs o wikis con páginas concretas dedicadas a eso mismo).
Evalué en algún momento manejar la página con un sistema de control de versiones (CVS era lo que se usaba entonces) pero no me decidí. Últimamente estoy re-pensando un poco algunos flujos de trabajo para tener un sistema mejor de copias de seguridad, con control de versiones. Además estoy trabajando bastante con git y he ido añadiendo partes de mi trabajo que están controladas con ese sistema, así que pensé que era el momento de mi página web.
Hice una búsqueda rápida en internet y encontré Using Git to manage a web site. Aunque hay alguna pequeña diferencia, me ha servido como guía.
Lo primero que quería hacer era pasar la copia local de mi ordenador de trabajo (que ya no está encendido tanto tiempo como solía) a otro que actúa como servidor para otras cosas y que siempre suele estar en marcha. Para ello, lo primero es crear un directorio:
ftricas@localServer:~/Documents$ mkdir www && cd wwwDespués, lo inicializamos como repositorio git y copiamos el contenido de la webdesde donde la teníamos.
ftricas@localServer:~/Documents$ git init
ftricas@localServer:~/Documents$ ssh ftricas@webServer "tar cpf - /home/ftricas/directorioWeb/* " | tar xpf - -C .Añadimos a git estos ficheros
ftricas@localServer:~/Documents$ git add .
ftricas@localServer:~/Documents$ git commit -am"Primera versión de la web"En el servidor donde se aloja la web necesitamos crear otro repositorio git:
ftricas@webServer:~/git-backup$ mkdir www.git && cd www.git
ftricas@webServer:~/git-backup$ git init --bareAhora en el servidor que vamos a usar como copia local de trabajo, ponemos este como remoto
ftricas@localServer:~/git-backup$ git remote add www ssh://webServer/home/ftricas/git-backup/www.git
ftricas@localServer:~/git-backup$ git push www +master:refs/head/masterEn mi caso además hizo falta decirle a git dónde están algunos programas auxiliares de git en el servidor (seguramente esto no es necesario en muchos servidores):
ftricas@localServer:~/Documents$ git config remote.www.receivepack /donde/esta/git-receive-pack
ftricas@localServer:~/Documents$ git config remote.www.uploadpack /donde/esta/git-upload-packY ya podemos sincronizar los repositorios:
ftricas@localServer:~/Documents$ git push www +master:refs/head/masterEste paso era para tener la primera versión, que ya estaba en el servidor en la web. Ahora necesitamos un paso más, para que podamos automatizar un poco la subida de los ficheros cuando hagamos cambios. Para ello utilizamos un hook y la variable GIT_WORK_TREE que permite tener la parte de control en el directorio que hemos creado antes y los ficheros en otro directorio diferente: no me gustaba la idea de tener mezclada la parte del control de versiones con los ficheros de la web y esto soluciona ese problema.
Para esto hacemos en el servidor web:
ftricas@webServer:~/git-backup$ cat > hooks/post-receive
#!/bin/sh
GIT_WORK_TREE=/var/www/miWeb git checkout -f
ftricas@webServer:~/git-backup$ chmod +x hooks/post-receiveO sea, copiamos esas dos líneas en el fichero post-receive y le damos permiso de ejecución.
La idea es que este programita se ejecuta cada vez que hacemos una petición push con los ficheros que hayan cambiado.
Si cambiamos algo, habrá que hacer el correspondiente commit, si añadimos ficheros o directorios habrá que utilizar las instrucciones correspondientes add y luego enviarlas al servidor:
ftricas@localServer:~/Documents$ git push wwwCon versiones modernas de git puede ser necesario tener en cuenta que puede ser necesario fijar el comportamiento por defecto del push. Yo elegí:
ftricas@localServer:~/Documents$ git config --global push.default simpleLo explican, por ejemplo, en Warning: push.default is unset; its implicit value is changing in Git 2.0 aunque el propio git nos avisa de lo que podríamos hacer.
A partir de este momento, cada vez que editamos en local la web y ya estamos satisfechos (o simplemente queremos subir algo al servidor web para ver cómo queda9 podemos hacer el commit correspondiente y después el push.
La web se irá actualizando, y tendremos las versiones controladas para el caso de que queramos recuperar la evolución de nuestra página web.
Algunos recursos adicionales:
Seguimos con las tarjetas.
Ya hemos hablado alguna vez del estándar PCI pero no teníamos muchos datos sobre Europa. En Survey: Just 1 in 3 Euro biz slackers meets card security standards se habla de un informe de Verizon sobre el tema y Europa no sale bien parada. Como dicel titular sólo un tercio de los negocios europeos examinados cumplen el 80 por ciento o más de los requisitos de PCI Data Security Standard (DSS).
Se le echa la culpa a las diferentes regulaciones locales y también a las diferencias culturales.
La última vez que hablamos de PCI fue en PCI y desarrollo seguro
En Why the US Doesn’t have Chip-and-PIN Credit Cards Yet nos recordaban que la seguridad no sólo se basa en tecnología o en recursos disponibles, sino que muchas veces se trata de una cuestión relacionada con los incentivos, amenazas, riesgos, costes…
Se habla del caso de la utilización de tarjetas con banda magnética en EEUU en lugar de las más modernas (y seguras) tarjetas con chip.
Y también los usos y costumbres de la gente. El ejemplo es Europa (territorios pequeños, con dificultades para perseguir a los defraudadores cuando cruzan la frontera) vs EEUU (un país grande, con ciudadanos que no salen tanto fuera) y las costumbres (y necesidades) de sus ciudadanos, las características de movimientos y viajes…
Esta entrada es más una ‘nota para mi mismo’ (note to self) que algo de valor real. Pero me encuentro con algunos pequeños avances, unas cuantas pestañas abiertas en el navegador y creo que es mejor compartirlo aquí para futura referencia que esperar a una (eventual) finalización de algo más avanzado. Quién sabe si puede servirle a alguien para algo.
En Una cámara móvil ya anticipábamos la posibilidad de hacer algo que se moviera. De hecho, ya se sugería la inspiración en Stubby. Full featured, miniature hexapod. También se puede ver información en Stubby the (Teaching) Hexapod.
Mi único problema con ese diseño eran las habilidades y herramientas necesarias: corte de madera, mecanizado… Estuve dándole vueltas a las alternativas realizables y pensé en tubos de madera. Con la idea de que sólo sería necesario cortarlos a la medida adecuada, perforarlos y montar el armazón adecuado.
También descubrí otros proyectos interesantes como A spider called “Chopsticks” que utilizaba palillos orientales para las patas y Popsicle Stick Hexapod R.I.P. que utiliza palos de helado, lo que iba más en la línea de lo que estaba pensando y me animó bastante. También había visto Build a 12-Servo Hexapod que tiene menos posibilidades pero que también es muy interesante.
Buscando en la red hay un montón de proyectos más, como Hexpider que sigue otro tipo de diseño (y es capaz hasta de escribir) y este otro 6-legged robot project que me han servido para tener algunas ideas sobre movimiento y configuración de las articulaciones (a nivel básico, todavía no he estado pensando demasiado en esa parte).
Con estas ideas me fui a la tienda de bricolaje más cercana a ver qué tenían. Aunque llevaba en la cabeza la idea de los tubos de madera allí encontré un tubo de plástico que me pareció muy adecuado: pensé allí mismo que sería más fácil de cortar y más ligero. También tenían tubos de aluminio que quedarían mucho más impactantes a la vista, pero de momento ese no es el objetivo.
Como suponía, el tubo de plástico es fácil de trabajar y podemos hacerle un agujero y poner un tornillo para sujetar un servo sin complicarnos mucho la vida, como puede verse en esta foto:
La fotografía no es muy buena, pero creo que es suficiente para hacerse una idea de cómo se pueden unir las partes, es lo que más he agradecido ver en los proyectos de otra gente para copiar/inspirarme. Como puede verse, he elegido un diseño con tres servos
También podemos poner bridas de plástico para fijar una articulación con otra, aunque imagino que hará falta una sujección más sólida cuando llegue el momento de que todo esto se mueva. Pero nuevamente parece sencillo hacer rebajes y pegar unas piezas con otras cuando tengamos una idea más clara del proyecto.
Ha sido sorprendente para mi ver lo rápido que he podido llegar a tener esta configuración, ya veremos si después sigo avanzando tan rápido (con el inconveniente de que no tengo suficientes motores, así que hacen falta algunas compras y esas cosas).
Para el movimiento de las articulaciones ya teníamos la experiencia de Añadiendo movimiento: servos , si bien es cierto es que re-escribí casi todo el código siguiendo las ideas de PiCam; al fijar mejor la cámara (que es algo que no conté por aquí), el movimiento suave ya no era tan necesario.
En la parte de los programas, por ahora, he hecho un par de programitas que están en servo.
El primero sirve para mover cada articulación de manera independiente desde la línea de órdenes (para poder establecer los puntos de referencia fácilmente): legOneMove.py.
Tenemos las tres articulaciones en los puertos GPIO correspondientes:
servoGPIO=[17, 23,15]y utilizamos una función para transformar un ángulo en el pulso necesario para mover el servo:
def angleMap(angle):
return int((round((1950.0/180.0),0)*angle)/10)*10+550Y la función que mueve el motor es muy sencilla:
def movePos(art, pos):
servo = PWM.Servo()
print art
servo.set_servo(art, angleMap(pos))
time.sleep(VEL)Para mi vergüenza, notar sólo recientemente descubrí la necesidad del temporizador final, porque si no el programa no da tiempo a que el movimiento se complete. Finalmente, en
movePos(servoGPIO[int(sys.argv[1])], int(sys.argv[2]))Directamente pasamos el primer argumento de la llamada como articulación que hay que mover (que se corresponderá, recordemos, con el GPIO adecuado) y el segundo es el ángulo de movimiento. No lo hagáis así, amiguitos: no os olvidéis nunca añadir en proyectos ‘reales’ los límites y comprobaciones adecuadas para no llevarnos más tarde sorpresas desagradables.
El segundo programa sería legServo.py que no es más que una simulación de lo que podrían ser los movimientos necesarios para que el hipotético robot ande: levantar un poco la pata, moverla hacia adelante, bajar la pata, moverla hacia atrás, … Y así sucesivamente. Seguro que hay que hacer ajustes después pero nos da una cierta idea de que hemos llegado a algún sitio.
A continuación podemos ver un vídeo de estos movimientos repetidos varias veces, que he grabado con ayuda de mi hijo
También podemos ver en el siguiente vídeo algunas pruebas previas, aprovechando el sensacional editor de vídeos de YouTube, con dos articulaciones y con tres:
Los siguientes pasos deberían ser hacer el resto de las patas (como mínimo cuatro, aunque creo que quedará mejor con seis) y ver si será necesario algún hardware adicional (para controlar los 18 motores y, tal vez, algo más las salidas dela Raspberry podrían ser insuficientes) y alguna idea adicional para el ‘cuerpo’ del robot. Seguiremos informando.
Es difícil estar al día de todos los cambios que van añadiendo los diferentes sistemas con los que interactúan las aplicaciones (en este caso web). Por eso vienen bien recordatorios como el de 4 HTTP Security headers you should always be using donde se habla justamente de eso, de algunas cabeceras de seguridad que deberíamos añadir:
Naturalmente, también conscientes de que es posible que el navegador de nuestro usuario no los conozca/use/respete/tenga en cuenta.
En Every Bug Has a Sad, Sad Song un comentario interesante sobre la relación entre bugs (fallos de programación) y fallos de seguridad.
Suele decirse que cuando un programa tiene bugs es posible que estos den lugar a vulnerabilidades, y a problemas de seguridad.
Pero el autor se queja del abuso que se hace de este ‘deslizamiento’ y que los que señalan esos fallos deberían ayudar a los desarrolladores a aprender sobre seguridad y no criticarlos sin más.
Ya hemos hablado algunas veces de aleatoriedad desde el punto de vista de la seguridad. En algunos casos, la aleatoriedad necesaria tiene que ver con producir resultados suficientemente diversos, pero en otros casos hay que pensar en más cosas. En “Not So Random Randomness” in Game Design and Programming discuten sobre el tema y cómo puede ser interesante influir en la ‘aleatoriedad’ para tener un juego más interesante.