En el software libre, existe una continua barrera muy fina entre las discusiones p�ramente internas y las declaraciones de relaciones p�blicas. Esto es parcialmente as� porque la audiencia objetivo no esta muy-definida: dado que la mayor�a o todos los posts son accesibles p�blicamente, el proyecto no tiene control sobre la impresi�n que de �l tiene la gente. Alguien; digamos, un slashdot.org editor; puede arrastrar la atencion de millones de lectores' a un post sobre el que nadie esperaba que fuera visto fuera del proyecto. Este es un hecho real con el que todos los proyectos open source viven, pero en la pr�ctica, el riesgo es normalmente peque�o. En general, los anuncios que el proyecto m�s quiere publicitar ser�n los que m�s se publicitar�n, asumiendo que usas los mecanismos correctos para indicar los valores m�s relativos al mundo exterior.
Para grandes comunicados, suele haber cuatro o cinco canales principales de distribuci�n, en cuales los anuncios deben ser hechos lo m�s simult�neamente posible.:
Probablemente la p�gina principal de tu proyecto es la p�gina m�s vista de tu proyecto. Si tienes un gran comunicado, pon la propaganda ah�. La propaganda deber�a ser un peque�o resumen que enlace a la noticia de prensa (ver abajo) para m�s informaci�n.
Al mismo tiempo, debes tener una parte del sitio web denominada "Noticias" o "Notas de prensa" donde los anuncios se describan en detalle. Parte del prop�sito de las notas de prensa es proporcionar un simple objeto de anuncio can�nico al que otros sitios puedan enlazar, por lo que hay que asegurarse que est� correctamente estructurado: tanto con una nueva p�gina por release, como una entrada discreta de blog, o cualquier otro tipo de entidad que pueda ser enlazada manteni�ndose todav�a a parte de otras notas de prensa en la misma �rea.
Si tu proyecto tiene un feed RSS, aseg�rate de que el anuncio tamb�en ir� por �l. Esto puede ocurrir autom�ticamente al crear la nota de prensa, dependiendo de como est� configurado tu sitio web. (RSS es un mecanismo para distribuir sumarios de noticias a trav�s de meta-datos-enriquecidos a subscriptores, esto es, a gente que ha indicado un inter�s en recibir esos sumarios. Mira http://www.xml.com/pub/a/2002/12/18/dive-into-xml.html para m�s informaci�n sobre RSS.)
Si el anuncio va a ser sobre una nueva versi�n de el software, entonces actualiza la entrada de tu proyecto en http://freshmeat.net/ (mira “Anunciando” sobre crear entradas en primer lugar). Cada vez que actualices una entrada de Freshmeat, esta entrada ir� a la lista de cambios de Freshmeat del d�a. Esta lista de cambios se actualiza no s�lo en el propio Freshmeat, sino tambi�n en varios sitios de portales (incluyendo slashdot.org) el cual es visto tempranamente por hordas de gente. Freshmeat tambi�n ofrece la misma v�a de datos a trav�s de feed RSS, de tal manera que la gente que no est� subscrita al RSS de tu proyecto todav�a puede ver el anuncio v�a el RSS de Freshmeat.
Env�a un mail a t� lista de correo de anuncios del proyecto.
Este nombre de lista actualmente debe ser algo como "anuncios", esto es,
announce@yourprojectdomain.org,
ya que es una convenci�n muy est�ndar actualmente, y en la definici�n
de la lista debe indicarse claramente que se trata de una lista con un
tr�fico muy bajo, reservada para anuncios internos del proyecto.
La mayor�a de esos anuncios ser�n sobre nuevas releases de software, y
ocasionalmente de otros eventos, tales como fundraising drive, o sobre
descubrimientos de vulnerabilidades de seguridad (ver
“Anunciando Vulnerabilidades de Seguridad”)
despu�s en este cap�tulo, tambi�n puede enviarse
un cambio de rumbo en la direcci�n del proyecto. Al tratarse de una
lista de tr�fico bajo y usada s�lo para cosas importantes, la
lista de anuncios tiene t�picamente el mayor
n�mero de subscriptores de cualquier lista de correo del proyecto
(por supuesto, esto significa que no deber�as abusar de ella- consideralo
cuidadosamente antes de utilizarla). Para evitar que gente al azar
env�e anuncios, o lo que es peor, que llegue spam a trav�s de ella,
la lista de anuncios debe ser siempre moderada.
Intenta realizar los anuncios en todos esos sitios al mismo tiempo , tanto como sea posible. A la gente puede confundirle si ven un anuncio en la lista de correo pero no lo ven reflejado en la p�gina principal del proyecto o en su �rea de anuncios de prensa. Si tienes los diversos cambios (correos, ediciones de p�gina web, etc.) encolados y preparados para enviarlos de una vez, podr�s mantener la ventana de inconsistencia al m�nimo.
Para un evento poco importante, puedes prescindir de alguno o todos los consejos de arriba. El evento todav�a ser� conocido por el mundo exterior en proporci�n directa a su importancia. Por ejemplo, cuando una nueva liberaci�n de software es un gran evento, marcar meramente la fecha de la siguiente liberaci�n tambi�n debe tenerse en cuenta, aunque no sea tan importante como la liberaci�n del software. Marcar la fecha merece un correo a la lista de correo diario (no a la lista de anuncios), y una actualizaci�n en la ruta del proyecto o del estado en la p�gina web, pero no m�s.
Sin embargo, todav�a puedes ver que las fechas aparecen en otros sitios de Internet, donde hay gente interesada en el proyecto. La gente suele actuar como lurkers en tus listas de correo, simplmente escuchando y sin decir nunca nada, no son necesariamente silenciosos en otros sitios. El boca a boca da una amplia distribuci�n; deber�as contar con ello, y construir incluso los anuncios menores de tal manera para la transmisi�n informal exacta. Espec�ficamente, posts, que esperas que sean citados deber�an tener una parte tiene-que-ser-citada, as� como t� escribiste el anuncio formal. Por ejemplo:
Simplemente una actualizaci�n de progreso: estamos planeando liberar una versi�n 2.0 de Scanley a mediados de agosto de 2005. Siempre puedes revisar http://www.scanley.org/status.html en busca de actualizaciones. La principal nueva caracter�stica ser� b�squedas con expresiones regulares.
Otras nuevas caracter�sticas incluyen:�... Tambi�n habr� varias correciones de bugs, incluyendo:�...
El primer p�rrafo es corto, da las dos piezas m�s importantes de informaci�n (la fecha de liberaci�n y las principales nuevas caracter�sticas), y una URL para visitar en busca de m�s noticias. S� este p�rrafo es la �nica cosa que se muestra en la pantalla de alguien, todav�a lo estas haciendo muy bien. El resto del correo podr�a perderse sin afectar a la esencia del contenido. Por supuesto, en ocasiones la gente enlazar� al correo completo, pero a menudo, citar�n s�lamente una parte. Dado que esto es una posibilidad, querr�s poder hacerlo f�cil para ellos, y conseguir alguna influencia sobre lo que se citar�.
Manejar una vulnerabilidad de seguridad es diferente del manejo de cualquier otro tipo de reporte de error. En el software libre, hacer las cosas de manera abierta y transparente es normalmente casi como un credo religioso. Cada paso del proceso est�ndar de manejo de errores es visible a todo aquel que le preocupe verlo: la llegada del informe inicial, la consiguiente discusi�n, y la correci�n eventual.
Los errores de Seguridad son diferentes. Estos pueden comprometer datos de usuarios, y posiblemente ordenadores completos de usuarios. Para discutir tales problemas de manera abierta tiene que anunciarse su existencia a todo el mundo—incluyendo a todas las partes que pueden hacer un uso malicioso de la vulnerabilidad. Incluso realizando meramente el commit de una soluci�n se anuncia efectivamente la existencia de la vulnerabilidad (existen atacantes potenciales que pueden buscar los logs de commits en proyectos p�blicos, buscando sistem�ticamente cambios que indiquen problemas de seguridad en el c�digo antes del cambio). La mayor�a de proyectos open source han resuelto aproximadamente de la misma manera estos conflictos entre el secretismo y la abertura, bas�ndose en estas gu�as b�sicas:
No hables sobre la vulnerabilidad de manera p�blica hasta que una soluci�n est� disponible; entonces proporciona la soluci�n al mismo tiempo exactamente que anuncias la vulnerabilidad.
Busca una soluci�n tan r�pido como puedas— especialmente si alguien externo al proyecto informo de la vulnerabilidad, porque sabes entonces que hay al menos una persona de fuera del proyecto que es capaz de explotar esa vulnerabilidad.
En la pr�ctica, estos principios nos llevan a una serie de principios bastante estandarizados, los cuales se describen en la siguiente secci�n.
Obviamente, un proyecto necesita la caracter�stica de que cualquiera pueda informar sobre un error de seguridad. Pero la direcci�n regular para informar de errores no ser�, porque tambi�n puede ser vista por cualquiera. Por ello, tendr� que haber una lista de correo separada para recibir informes de errores de seguridad. Esta lista de correo no debe tener los archivos de manera que se puedan leer p�blicamente, y debe controlarse estrictamente a los subscriptores de la misma— s�lo los desarrolladores de confianza y que lleven tiempo en el proyecto, podr�n estar en la lista. Si necesitas una definici�n formal de "confianza", puedes orientarte con "cualquiera que ha tenido acceso para realizar commits desde hace dos a�os o m�s" o algo similar, para evitar favoritismos. Este es el grupo que manejar� los errores de seguridad.
Idealmente, la lista de seguridad no deber�a estar moderada o protegida contra el spam, ya que no querremos que un informe importante pueda filtrarse o se retrase simplemente porque los moderadores no estuvieron online aquel fin de semana. Si usas software autom�tica de protecci�n de spam, intenta realizar una configuraci�n con caracter�sticas de gran tolerancia; es mejor dejar pasar unos cuantos correos spam que perder un informe. Para que la lista sea efectiva, por supuesto que debes informar de su direcci�n; pero dado que no estar� moderada, y en gran parte, ligeramente protegida de spam, intenta no publicar su direcci�n sin algun tipo de transformaci�n y ocultaci�n de la direcci�n, tal y como se describe en “Ocultar las direcciones en los archivos” en Cap�tulo�3, Infraestructura T�cnica. Afortunadamente, el ocultar la direcci�n de correo no significa que �sta sea ilegible; echa un vistazo a http://subversion.tigris.org/security.html, y mira el c�digo HTML de esta p�gina, para ver un ejemplo.
�Qu� hace la lista de seguridad cuando recibe un informe? La primera tarea es evaluar la urgencia y severidad del problema. :
�C�mo de seria es la vulnerabilidad? Permite que un atacante malicioso tome la computadora de alguien que utiliza tu sofware? o �nicamente hay una fuga de informaci�n sobre el tama�o de algounos de sus archivos?
�C�mo de f�cil es explotar la vulnerabilidad? Se puede realizar el ataque con scripts, o hacerlo requiere un conocimiento circunstancial, suposiciones y suerte?
�Qui�n te inform� del problema?
La respuesta a esta pregunta, por supuesto que no cambia
la naturaleza de la vulnerabilidad, pero te da una idea de
c�mo otras personas pueden conocerla. Si el informe viene de
uno de los desarrolladores del propio proyecto, puedes respirar
algo tranquilo (pero s�lo un poco), porque puedes confiar en
que ellos no se lo dir�n a nadie m�s. Por otra parte, si viene
de una direcci�n de correo como anonymous14@globalhackerz.net,
entonces lo mejor ser� que act�es tan r�pido como puedas. Despu�s de todo
la persona te hizo un favor informando del problema, pero no tienes idea
de a cuanta gente m�s se lo ha contado, o cuanto tiempo esperar� antes
de explotar la vulnerabilidad en instalaciones en producci�n.
Nota que la diferencia que estamos hablando aqu� es un rango estrecho entre urgente y extremadamente�urgente. Incluso cuando el informe viene de una fuente conocida, puede haber otra gente en la red que descubrieron el bug hace tiempo y no han informado de ello. La �nica vez que las cosas no son urgentes es cuando el bug inherentemente no compromente la seguridad muy severamente.
El ejemplo de "anonymous14@globalhackerz.net" por
cierto, no es burl�n. Realmente puedes obtener informes de gente con
identidades-encubiertas que, por sus palabras y comportamiento, nunca
clarifican si estan de tu parte o no. No importa: si te han informado de el
agujero de seguridad, ellos sienten que te han hecho un buen favor, y
t� deber�as responderles de la misma manera. Agredeci�ndoles el informe,
facilit�ndoles una fecha antes de la cual planeas liberar un parche p�blico,
y mantenlo al tanto. Algunas veces ellos pueden darte una fecha—que
es, una amenaza impl�cita de publicar el bug en una fecha dada, si est�s preparado o no.
Esto puede parecer un juego de poder de intimidaci�n, pero es m�s una acci�n
preferente resultado de decepciones anteriores con productores de software
que no respond�an y no se tomaban los informes de seguridad en serio.
This may feel like a bullying power play, but it's more likely a
pre�mptive action resulting from past disappointment with
unresponsive software producers who didn't take security reports
seriously enough. De todas maneras, no puedes permitirte ignorar a esta persona.
Despu�s de todo, si el bug es severo, el tiene conocimiento que podr�a causar grandes
problemas a tus usuarios. Trata a estos informadores bien, y espera que ellos tambien
te traten bien a t�.
Otro informador frecuente de agujeros de seguridad es el profesional de la seguridad, alguien que audita c�digo c�mo parte de su trabajo y se mantiene al d�a con las �ltimas noticias en las vulnerabilidades de software. Esta gente normalmente tiene experiencia en ambos lados de la vallya—ellos tanto han recibido como enviado informes, probablemente m�s que la mayor�a los desarrolladores de tu proyecto tengan. Ellos normalmente tambi�n te dar�n una fecha fija para solucionar la vulnerabilidad antes de hacerla p�blica. Esta fecha puede ser negociable, pero esto depender� del informador; las fechas fijadas han sido reconocidas entre los profesionales de la seguridad como la �nica v�a fiable para que las organizaciones solucionen los problemas de seguridad puntualmente. Por lo que no trates la fecha fijada como algo grosero; es una larga tradici�n, y hay buenas razones para ello.
Una vez que conozcas la severidad y urgencia, puedes empezar a trabajar en la soluci�n. A veces hay un sacrificio entre hacer una soluci�n elegante y hacerla r�pida; por esto, debeis acordar la urgencia antes de empezar. Manten la discusi�n de la soluci�n restringida �nicamente a los miembros de la lista, por supuesto tambi�n al informador original (si el quiere estar involucrado) y con cualquier desarrollador que se necesite contactar por razones t�cnicas.
No hagas el commit de la soluci�n en el repositorio. Mantelo en forma de parche hasta la fecha de ir al p�blico. Si fueras a hacer el commit, incluso con un mensaje de log aparentemente inocnete, algui�n puede darse cuenta y comprender el cambio. Nunca sabes qui�n est� observando tu repositorio y porque estos pueden estar interesados. Deshabilitar los correos del commit no ayudar�; primero de todo, el intervalo en la secuencia del mail del commit resultar�a sospechoso, y de cualquier manera, los datos todav�a estar�an disponibles en el repositorio. Simplmente haz todo el desarrollo en un parche y mant�n el parche en alg�n lugar privado, quiz�s un repositorio privado y separado que s�lo lo conozca la gente que est� al tanto del bug. (Si usas un sistema de control de versiones descentralizado tal como Arch o SVK, puedes hacer el trabajo bajo el control de versi�n completo, y mantener simplemente el repositorio inaccesible a los desconocidos.)
Puedes haber visto un n�mero CAN o un n�mero CVE asociados con problemas de seguridad. Estos n�meros son del tipo "CAN-2004-0397" o "CVE-2002-0092", por ejemplo.
Ambos tipos de n�meros representan el mismo tipo de entidad: una entrada en la lista de "Exposiciones y Vulnerabilidades Comunes" mantenida en http://cve.mitre.org/. El prop�sito de esta lista es proporcionar nombres estandarizados para todos los problemas de seguridad conocidos, de tal forma que todo el mundo tenga un �nico, nombre can�nico que usar cuando se discuta una, y un sitio central para encontrar m�s informaci�n. La �nica diferencia entre n�mero "CAN" y n�mero "CVE" es que el primero representa una entrada candidata, pero todav�a no aprobada para incluirse en la lista oficial de la junta editorial CVE, y el �ltimo representa una entrada aprobada. Sin embargo, ambos tipos de entradas son visibles al p�blico, y un n�mero de entrada no cambia cuando es aprobado—el prefijo "CAN" es reemplazado simplmente con "CVE".
Una entrada CAN/CVE no contiene en s� misma una descripci�n completa del bug y como protegerse contra el. En lugar de eso, contiene un breve sumario, y una lista de referencias a recursos externos (tal como archivos de listas de correo) donde la gente puede ir para conseguir informaci�n m�s detallada. El prop�sito real de http://cve.mitre.org/ es proporcionar un espacio bien organizado en el cual cada vulnerabilidad pueda tener un nombre y una ruta clara a m�s datos. Mira http://cve.mitre.org/cgi-bin/cvename.cgi?name=2002-0092 c�mo un ejemplo de una entrada. Observa que las referencias pueden ser muy secas, con fuentes apareciendo como abreviaciones cr�pticas. Note that the references can be very terse, with sources appearing as cryptic abbreviations. Una clave a estas abreviaciones est� en http://cve.mitre.org/cve/refs/refkey.html.
Si tu vulnerabilidad cumple los criterios de CVE, puedes adquirir un n�mero CAN. El proceso para hacer esto es deliberadamente por ingreso: b�sicamente tienes que conocer a alguien, o conocer a alguien que conozca a alguien. Esto no es tan disparatado como pueda sonar. Con el fin de evitar que la Junta Editorial de CVE este abrumada con falsos o env�os pobremente escritos, reciben los env�os s�lo de fuentes de las que ya conf�an. Con el fin de conseguir listar tu vulnerabilidad , por lo tanto, necesitas encontrar un camino de conocimiento de tu proyecto al Consejo Editorial de CVE. Pregunta entre tus desarrolladores; alguno de ellos probablemente conocer� a alguien que haya realizado previamente el proceso de CAN, o conoce a alguien que lo ha hecho, etc. La ventaja de hacerlo de esta manera es tambien que en alg�n lugar a trav�s de la cadena, alguien puede saber lo suficiente para decirte que a) no contar� como una vulnerabilidad o exposici�n de acuerdo a los criterios de MITRE, por lo que no es necesario enviarlo, o b) la vulnerabilidad ya tiene un n�mero CAN o. Lo �ltimo puede ocurrir si el bug ya ha sido publicado en otra lista de avisos de seguridad, por ejemplo en http://www.cert.org/ o en la lista de correo BugTraq en http://www.securityfocus.com/. (Si esto ha ocurrido y tu proyecto no se ha enterado, entonces deber�as preocuparte por quien m�s puede saber algo que todav�a no sabes.)
Si despu�s de todo consigues un n�mero CAN/CVE, normalmente querr�s conseguirlo en la primera etapa de la investigaci�n del bug, para que todas las comunicaciones consiguientes puedan referirse con ese n�mero. Las entradas CAN est�n embargadas hasta la fecha de publicaci�n; la entrada existir� como una reserva vac�a (para que no pierdas el nombre), pero no revelar� ninguna informaci�n sobre la vulnerabilidad hasta la fecha en la cual anunciar�s el bug y la soluci�n.
M�s informaci�n sobre el proceso CAN/CVE puede encontrase en http://cve.mitre.org/about/candidates.html, y una exposici�n particularmente clara de el uso de los n�meros CAN/CVE de un proyecto open source en http://www.debian.org/security/cve-compatibility.
Una vez que tu equipo de respuesta a seguridad (este es, aquellos desarrolladores que est�n en la lista de correo de seguridad, o quien ha estado involucrado con un informe particular) tienen un arreglo listo, necesitas decidir como distribuirlo.
Si simplemente realizas un commit con el arreglo en tu repositorio, o de lo contrario lo anuncias al mundo, efectivamente estar�s forzando a todo el mundo que use tu software a actualizarse inmediatamente o estar�n en riesgo de ser hackeados. A veces es apropiado, por lo tanto, hacer pre-notificaciones para ciertos usuarios importantes. Esto es particularmente cierto con software cliente/servidor , donde puede haber servidores bien conocidos que ser�n objetivos tentadores para atacantes. Los administradores de estos servidores apreciar�n el tener un d�a o dos extra para realizar la actualizaci�n, de tal manera que ya est�n protegidos una vez que el exploit sea de conocimiento p�blico.
La Pre-notificaci�n simplemente significa enviar correos a esos administradores antes de la fecha de publicaci�n, avis�ndoles de la vulnerabilidad y de c�mo solucionarla. Deber�as enviar pre-notificaciones s�lo a gente en la que conf�es que ser�n discretos con la informaci�n. Esto es, la cualificaci�n para recibir pre-notificaciones es doble: el destinatario debe administrar un gran e importante servidor donde un compromiso ser�a un asunto serio, y el emisor debe saber que no cotorrear� sobre el problema de seguridad antes de la fecha de publicaci�n.
Env�a cada correo de pre-notificaci�n individualmente (de uno en uno) a cada receptor. No env�es a la lista completa de receptores de una vez, porque podr�n verse los nombres de cada uno; lo que significa que esencialmente est�s alertando a cada receptor con el hecho de que cada uno de los otros receptores pueden tener un agujero de seguridad en su servidor. Enviarselo a todos v�a CC ciegas (BCC) tampoco es una buena soluci�n, porque algunos administradores protegen sus bandejas con filtros de spam tanto bloquean como reducen la prioridad de los correos con BCC, ya que mucho spam es enviado v�a BCC actualmente.
Este es un correo de ejemplo de pre-notificaci�n:
De: T� nombre aqu� A: admin@large-famous-server.com Responder-A: T� nombre aqu� (no la direcci�n de la lista de seguridad) Asunto: Notificaci�n confidencial de vulnerabilidad Scanley. Este correo es una pre-notificaci�n confidencial de una alerta de seguridad en el servidor Scanley. Por favor *no reenv�es* ninguna parte de este correo a nadie. El anuncio p�blico no se har� hasta el 19 de Mayo, y nos gustar�a mantener la informaci�n en secreto hasta entonces. Estas recibiendo este correo porque (pensamos) que administras un servidor Scanley, y quierr�as tenerlo parcheado antes de que este agujero de seguridad sea p�blico el 19 de Mayo. Referencias: =========== CAN-2004-1771: Desbordamiento de pila en consultas de Scanley Vulnerabilidad: ============== Se puede conseguir que el servidor ejecute comandos arbitrarios si la configuraci�n local esta mal configurada y el cliente env�a una consulta malformada. Severidad: ========= Muy severa, puede involucrar la ejecuci�n de c�digo arbitrario en el servidor. Soluci�n alternativa: ============ Configurando la opci�n 'natural-language-processing' a 'off' en scanley.conf cierra esta vulnerabilidad. Parche: ====== El parche de abajo se aplica a Scanley 3.0, 3.1, y 3.2. Una nueva distribuci�n p�blica (Scanley 3.2.1) se har� el 19 de Mayo o un poco antes, de tal manera que est� disponible al mismo tiempo que esta vulnerabilidad se haga p�blica. La �nica diferencia entre 3.2 y 3.2.1 ser� este parche. [...el parche viene aqu�...]
Si tienes un n�mero CAN, incl�yelo en la pre-notificaci�n (c�mo se muestra arriba), incluso aunque la informaci�n est� todav�a oculta y de ah� que la p�gina de MITRE no mostrar� nada. Incluyendo el n�mero CAN permite al receptor conocer con certeza que el bug con el que han sido pre-notificados es el mismo que luego oir�n hablar en los canales p�blicos, por lo que no tendr�n que preocuparse si es necesario realizar alguna acci�n, qu� es precisamente el objetivo de los n�meros CAN/CVE.
El �ltimo paso en el manejo de un bug de seguridad es distribuir la soluci�n p�blicamente. En un �nico y comprensivo anuncio, deber�as describir el problema, dar los n�meros CAN/CVE si los tiene, describir alguna soluci�n temporal, y c�mo solucionarlo permanentemente. Normalmente "fix" significa actualizar a una nueva versi�n del software, aunque algunas veces puede significar aplicar un parche, particularmente si el software normalmente es ejecutado desde las fuentes. Si creas una nueva versi�n disponible, debe diferenciarse de las versiones existentes en �nicamente el parche de seguridad. De esta manera, admins conservadores podr�n actualizar sin preocuparse sobre a que m�s puede afectarle; tampoco tendr�n que preocuparse de futuras actualizaciones, porque la soluci�n del fallo de seguridad vendr� integrado en todas las futuras versiones (Detalles de procedimientos de liberaci�n de versiones discutidos en “Security Releases” en Cap�tulo�7, Empaquetado, Liberaci�n, y Desarrollo diario.)
Al margen de que la soluci�n p�blica al bug de seguridad conlleve una
nueva versi�n, haz el anuncio con aproximadamente con la misma prioridad con
la que har�as una nueva liberaci�n de versi�n: env�a un mail a la lista de
anuncios del proyecto, crea una nueva nota de prensa de la
liberaci�n, actualiza la entreada de Freshmeat, etc.
Mientras t� nunca deber�as restar importancia a la existencia de un bug
de seguridad por asuntos de la reputaci�n del proyecto, ciertamente puedes
definir un tono de la importancia del anuncio de seguridad que coincida
con la severidad actual del problema. Si el agujero de seguridad es simplemente
una exposici�n de informaci�n menor, y no existe un exploit que permita tomar
un control total de la computadora del usuario, entonces no puede justificar
mucha preocupaci�n. Puedes incluso decidir el no distraer a la lista de
anuncios con �l. Despu�s de todo, si el proyecto empieza
con este tipo de anuncios cada cierto tiempo, los usuarios pueden empezar a
pensar que el software es menos seguro de lo que actualmente es, y tambi�n
pueden dejar de creerte cuando exista un problema realmente grave que deba
anunciarse. Mira
http://cve.mitre.org/about/terminology.html c�mo una buena
introducci�n al problema de judgar la severidad.
En general, si no est�s seguro en como tratar un problema de seguridad, encuentra a alguien con experiencia y habla con �l sobre ello. Evaluar y manejar vulnerabilidades es en gran parte una destreza adquirida, y es f�cil cometer fallos las primeras veces.