> Llegados a ese punto, se me ocurre una gestion de usuarios,
> aunque ésto implica también la gestión de sus respectivas
> claves... Me parece que ésto ya se sale un poco del objetivo
> primordial del bulletproof, y se encaminaría más bien hacia un
> bouncer que implementa encryptación de datos.
En versiones futuras (las 2.x) BulletProof implementará cifrado directo
y transparente entre el cliente y el servidor IRC, si éste lo soporta.
El objetivo será el poder tener una sesión IRC segura *AUNQUE* estés en
una red "hostil", como puede ser un cibercafé o una universidad. El
proyecto engrana con dos proyectos más en la parte servidor de IRC, que
estoy ultimando. No hay fechas de implantación, eso sí.
En cuanto a la gestión de claves que mencionas.. yo no veo ninguna
necesidad de ello. Ahora mismo cada sesión BP arranca sin ninguna clave
activa, y es el clietne IRC (típicamente a mano o a través de un script)
quien "alimenta" las claves a usar a BP. BP no guarda las claves en
ninguna parte, así que cuando arranca una sesión nueva es el cliente
quien debe proporcionárselas.
En cuanto al tema que comentas, de poner claves de "acceso" cuando
abrimos el "bouncer" al mundo mundial, yo sugeriría deshabilitar el "por
forwarding" directo del puerto 6667 y limitarnos a hacer "forwarding"
vía SOCKS. Y el protocolo SOCKS permite autentificación...
--
Jesus Cea Avion _/_/ _/_/_/ _/_/_/
jcea at argo.es http://www.argo.es/~jcea/ _/_/ _/_/ _/_/ _/_/ _/_/
_/_/ _/_/ _/_/_/_/_/
PGP Key Available at KeyServ _/_/ _/_/ _/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/
"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz