Mi estado actual en Jabber/XMPP: - jabberES - jabber.org

IRC-DEV

PaginaDeEntrada ParchesIRCD ParchesIRCDAgo2003

Usuario: Anonymous User

• 23/May/03: Soporte MOTD por BDD. Asignado: NiKoLaS

  Analizar el impacto de este parche con las líneas T y con la variable "NODEFAULTMOTD" del "make config".

  • http://mailman.argo.es/pipermail/irc-dev/2003-May/002742.html
  • http://mailman.argo.es/pipermail/irc-dev/2003-June/002777.html

• 30/May/03: Los jupes/links de nodos se controlan por BDD. Asignado: NiKoLaS
• DONE 18/Ago/03 - 09/Jul/03: Dado que solo se guardan los "invites" de los usuarios locales, esta información debe almacenarse en la zona "local" de los usuarios. Asignado: Abba
• DONE 22/Ago/03 - 10/Jul/03: Verificación de la existencia del usuario/grupo en el "make config". Asignado: mount
• DONE 04/Ago/03 - 01/Ago/03: Reducir el conjunto de caracteres válidos en las masks de los ban a los ascii > 32. Asignado: NiKoLaS
• 03/Ago/03: Determinados datos de configuración del IRCD deberían ser actualizables por BDD. Por ejemplo, las líneas "U". Asignado: Amn3S1A (Parche heredado de NiKoLaS 05/May/03)

  • http://mailman.argo.es/pipermail/irc-dev/2003-May/002744.html

• DONE 24/Ago/03 - 04/Ago/03: Si se responde negativamente a "Do you want the daemon set its own uid/gid", el "make install" fallará al hacer chown/chgrp. Asignado: mount

  • Log de #irc-dev del 25 de Julio de 2003

• DONE 01/Sep/03 - 05/Ago/03: Bajo Red Hat 9, entre otros, no se reconoce automáticamente la necesidad de incluir las librerías "-lresolv" y "-lcrypt". Asignado: Amn3S1A

  • Log de #irc-dev del 25 de Julio de 2003

• 06/Ago/03: Documentar en "ejemplo.conf" el uso de líneas T para mostrar MOTDs distintos dependiendo del cliente o de la hora. Asignado: NiKoLaS
• DONE 20/Ago/03 - 14/Ago/03: Se debe extender el uso de "nick changed too fast" incluso aunque la clave especificada por el usuario no coincida (nicks registrados), para reducir la velocidad de un posible ataque de fuerza bruta. Asignado: ^hPmK^
• DONE 14/Ago/03 - 14/Ago/03: "userhost" e "userip" a un Oper. Asignado: ^hPmK^

  • http://mailman.argo.es/pipermail/irc-dev/2002-September/001746.html

• 20/Ago/03: La penalización de cambio de nick debe aplicarse si la clave indicada es incorrecta, pero NO si el nick intentado está en uso, o si el nick está registrado pero el usuario no indica una clave. Cuidado también con los ghost. Asignado: ^hPmK^
• DONE 25/Ago/03 - 24/Ago/03: En "users", cuando se muestra el record de usuarios debería mostrarse desde cuándo se comprueba ese valor (típicamente, desde el arranque del IRCD). Asignado: mount
• DONE 27/Ago/03 - 27/Ago/03: Cuando hay un "netride", eliminar el "topic" del canal más moderno. Asignado: mount

  • https://sourceforge.net/tracker/?func=detail&atid=504082&aid=760425&group_id=63470
  • http://mailman.argo.es/pipermail/irc-dev/2003-August/003064.html

• DONE 28/Ago/03 - 27/Ago/03: Igual que no se deja entrar en un canal "+#canal", tampoco se debería poder entrar en "+@canal" o "+@#canal". Asignado: mount
• DONE 29/Ago/03 - 28/Ago/03: La compilacion de la libreria ZLIB integrada en el IRCD no usa el compilador de C configurado en el "make config". Asignado: mount
• DONE 31/Ago/03 - 29/Ago/03: - Un "make clean" debe eliminar también los objetos compilados, la librería y el "Makefile2" de la "zlib". Asignado: mount
• 31/Ago/03: Cuando hacemos un "make install", crea el fichero MMAP de persistencia en el directorio "ircd" de los fuentes, no en el directorio destino, si no se ha especificado un path completo donde dejar el MMAP. Ver parche u2.10.H.07.02. Hay que ponerlo en el lugar correcto. Hay que hacer un "touch", pero hacerlo SOLO si NO existe el fichero MMAP, ya que sino el IRCD se caería por modificación no autorizada. Asignado: mount

Parches pendientes de asignar

• Ampliación de tamaño de nicks a 15 caracteres.
• Eliminación de la verificación de SOCKS4.
• Volver a incluir la IP cifrada en las IPs Virtuales definidas en la tabla "w".
• Si alguien entra en un canal con baneos y se cambia de nick a uno "baneado", puede hablar en el canal con normalidad.
• Si se nos invita a un canal, debemos poder entrar en él sin afectar ni verse afectado por el control de "targets".

CambiosRecientes VerAyuda

editar esta página (requiere autentificación)