Como la mayoría de nuestros usuarios son de habla hispana, se que muchos me agradecerán que por fin Tucan este en castellano.
El soporte para i18n esta completo y por ahora esta localizado en ingles y castellano, pero se irán añadiendo lenguajes proximamente.
Además se han mejorado el reconocimiento de captchas y solucionado algunos bugs, así que he preparado la versión 0.3.1. ¡Disfrutadla!
Finalmente una buena noticia para los usuarios de Microsoft Windows, y es que Tucan pronto tendrá un ejecutable en esta plataforma.
PD: Si os da problemas al arrancar, borrad el .tucan de vuestro home.
Un saludo, Crak.
Según mi planificación inicial debería haber llegado a este punto hace ya algún tiempo, pero entre unas cosas y otras pues llego ahora. De todas formas la parte más compleja, ya sea diseño y arquitectura del sistema, está al 80%, es una versión funcional y a partir de este punto voy a iterar hacia la perfección.
¿A dónde he llegado? Ya tengo un gestor de contraseñas basado en el sistema de cliente servidor funcional. Tengo un servidor que exporta una interfaz xmlrpc (gecod) y un cliente para terminal (gecoc) que basandose en esta interfaz te da la funcionalidad esperada.
La funcionalidad implementada es:
Esta funcionalidad es más que suficiente para un gestor de contraseñas, teniendo en cuenta que la creación de contraseñas incluye la generación de contraseñas aleatorias y que también se hace uso de cifrado para mayor seguridad.
Sin embargo GECO está pensado para gestionar, además de contraseñas, ficheros de configuración, pero esto lo implementaré más tarde, aunque lo he tenido en cuenta a la hora de crear la base de datos.
Con respecto al cliente he creado un cliente interactivo con una serie de ordenes, con ayuda y demás cosas, se puede ver cómo lo he hecho aquí. Lo he hecho de tal manera que cada función definida es un nuevo comando y se utilizan las cadenas de documentación de python para mostrar la ayuda.
Usabilidad:
Al basarme en el modelo cliente servidor estoy metiendo un poco de complejidad a la forma de llegar hasta la información almacenada ya que es necesario recordar al menos dos contraseñas "seguras" para poder acceder al resto.
Al estar la información almacenada en un servidor externo, es necesario tener un usuario y contraseña en ese servidor para poder gestionar todas las contraseñas que se almacenen, por lo tanto tendremos que tener un usuario y contraseña para acceder desde las diferentes interfaces a un servidor geco.
Por otra parte como las contraseñas pueden almacenarse en un servidor que no controlemos es necesario cifrarlas con un algoritmo simétrico, para lo cual hace falta usar una clave maestra de cifrado de passwords (esta nunca llegará a ningún servidor).
Supongo que para servidores locales se puede evitar el paso de la autenticación y proteger la base de datos basandose en el sistema de ficheros, así actuaría como un gestor de contraseñas tradicional, pero en cuanto implemente la posibilidad de sincronizar diferentes servidores le dará mucha más potencia.
A partir del cliente para terminal se puede empezar a trabajar en diferentes clientes (web, gtk, qt, etc).
Algoritmos de cifrado
Como tengo pensado hacer un cliente web es necesario que las contraseñas se cifren con un algoritmo que tenga una implementación en javascript y en python, así pues me he basado en SlowAES para cifrar y descifrar y así tener asegurado que es posible descifrar y cifrar desde el navegador. Esta librería también incluye una implementación en ruby por lo que es posible crear un cliente basandose en ruby. Por supuesto también he tenido en cuenta que el metodo de cifrado puede ser variable por lo que intentaré añadir más sistemas de cifrado.
Nada más por hoy, yo voy a empezar a utilizarlo y a tener una contraseña aleatoria para cada servicio web.
Es hora de decir que tenemos y hacía donde vamos.
Hasta ahora he conseguido estudiar el protocolo X10 con una profundidad suficiente, por lo que ha llegado el momento de empezar a estudiar Perl y familiarizarme con Arduino, las bases de nuestro sistema domótico. Para ello he aprovechado estas 2 semanas.
En primer lugar he leido un [...]
“I was born under unusual circumstances”
“And so begins “The Curious Case of Benjamin Button,” adapted from the 1920s story by F. Scott Fitzgerald about a man who is born in his eighties and ages backwards. A man, like any of us, unable to stop time. We follow his story set in New Orleans from the [...]
Hoy he creado una lista de distribución de e-mail para el proyecto. Está pensada para los colaboradores del proyecto y cualquier persona que esté interesada en llevar al día la evolución del mismo.
Cualquier persona que quiera suscribirse a la lista debe ponerse en contacto conmigo (mi dirección de e-mail está publicada en la sección Acerca De).
Esta ultima semana ha sido una locura, mas de 1000 visitas al blog desde el ultimo post y mas de 350 descargas de Tucan 0.3.
Quiero hacer referencia a las reviews hasta la fecha y espero no olvidar ninguna:
Gracias a todos por vuestro interés en el proyecto.
Un saludo, Crak.
Dada la investigación que estoy llevando a cabo sobre el manejo de e-mail en Python y las dificultades que me he encontrado (sobre todo la falta de documentación), me estoy planteando crear en el futuro un proyecto de software libre que sea una librería en Python para manejar el e-mail de forma fácil. Seguro que ayuda a mucha gente que, como yo, necesita manejar el e-mail sin mucha complicación pero no encuentra documentación fácil de entender.
Esto no tiene nada que ver con el proyecto Unimail, pero me ha parecido interesante comentarlo. En cualquier caso, si, finalmente, decido realizar dicha librería, os lo anunciaré por aquí.
Quiero hacer un pequeño resumen de todo aquello que he ido haciendo desde que empecé con la idea del proyecto. No quiero extenderme mucho asi simplficare las cosas para ver todo lo que he estado haciendo hasta hoy.
Cuando empecé con la idea de realizar el proyecto en Android todo parecía muy bonito:
La tecnología utilizada estaba [...]
Después de haber investigado un poco, he decidido usar el protocolo IMAP en lugar del POP, que es el que estaba utilizando hasta ahora. Para esto tendré que usar la librería estandar de Python “imaplib”, en vez de “poplib”, por lo que voy a tener que reescribir una parte importante del código.
¿Merece la pena este cambio?. Pues la verdad es que sí. La razón principal para el cambio es que IMAP permite hacer búsquedas en el servidor, de forma que éste te devuelva los índices de los mensajes que coincidan con el criterio de búsqueda. Este descubrimiento que he hecho sobre IMAP es importantísimo para mí, ya que ahora los problemas que me han ido surgiendo con las búsquedas desaparecerán automáticamente, ya que las búsquedas son prácticamente instantáneas para el usuario, y no va a ser necesario esperar a que se complete un proceso de búsqueda que descargaba información de todos y cada uno de los mensajes, proceso que era lentísimo. Otro problema que tenía POP, al menos con Gmail (que es donde he hecho hasta ahora las pruebas) era que había que activar el servicio POP cada vez que se recibía un archivo con Unimail (aunque ya estuviera activado), si no, Unimail no detectaba dicho archivo; ahora con IMAP se supone que sólo hay que activarlo una vez, y Gmail sólo tiene 2 opciones para IMAP: activarlo o desactivarlo. Debido a esto, ahora el usuario sólo se preocupará de activar IMAP 1 vez, instalarse Unimail 1 vez y usar Unimail tantas veces quiera sin tener que hacer ningún proceso previo.
Estoy trabajando ya en la versión 0.5, y espero tenerla en breve. La única novedad que tendrá será el cambio de POP a IMAP, aunque se trata de una novedad importantísima. A partir de la publicación de dicha versión, lo que habrá que hacer es realizar un montón de pruebas, para verificar su buen funcionamiento y para ver que realmente IMAP es mejor que POP.
Una cuestión que podría presentarse al lector sería la siguiente: ¿por qué no haber usado IMAP desde el principio?. Bueno, las respuesta es que no lo he usado desde el principio básicamente por desconocimiento mío de este protocolo/tecnología. Sólo sabía que IMAP era más avanzado que POP y que POP era más básico o “primitivo”. Aunque, al principio, no tenía ni idea de ninguno de los protocolos, decidí usar POP porque al ser más básico mi programa podría usarse con un mayor número de servicios de e-mail y además me sería más fácil escribir código, ya que POP está mejor documentado que IMAP, al menos en la información de Python que existe en Internet y en los libros de la biblioteca de mi facultad (mis dos fuentes a la hora de investigar).
El descubrimiento de IMAP ha sido algo tardío para mí, pero ha merecido la pena. Supongo que es consecuencia de mi condición: comencé el proyecto sin tener ni idea de Python, ni del e-mail, ni de POP, ni de IMAP. Ahora, gracias a que he estado haciendo una labor más o menos de investigación, he ido aprendiendo cosas, lo cual es gratificante.
Después de publicar la versión 0.5, trabajaré en la 0.6, la cual tendrá opciones para guardar la configuración de las cuentas de e-mail usadas y esas cosas, y ya después, intentaré que la versión 0.7 disponga ya de una interfaz de usuario gráfica, lo cual quedaría muy, pero que muy, bien.
El proyecto cuenta oficialmente con un nuevo colaborador, Javier Jesús Salmerón García.
Es un compañero y amigo mío de la facultad, el cual ha estado probando de vez en cuando el proyecto y quiere seguir haciéndolo para ayudarme a hacer que Unimail sea toda una realidad.
Agradezco a Javier su colaboración con el proyecto, lo cual significa mucho para mí.