Wiki

• FrontPage
• RecentChanges
• FindPage
• HelpContents
• es/LTS/Development

Wiki/

Traducción(es): English - español - Français - Русский

---

Contribuir a Debian Long Term Support

El equipo de Debian LTS siempre está buscando mas voluntarios para hacer un mejor trabajo. Con más recursos, podríamos por ejemplo:

• soportar paquetes que actualmente no tengan soporte
• ocuparnos de todos los paquetes de Debian y no solo los más populares
• Arreglar problemas de baja prioridad que actualmente son ignorados

Si quiere involucrarse en el equipo LTS y ayudar a mantener seguros los paquetes de Debian durante 5 años, mire esta página. Asumimos que estás familiarizado con la disposición descritas en Usar LTS y que está subscrito a la lista de correo: http://lists.debian.org/debian-lts/

Puede ayudar de muchos modos:

Pruebe paquetes actualizados e informe regresiones

Como simple usuario, puede probar paquetes que hayan sido actualizados (o que estén en proceso de ser actualizados). Si encuentra una regresión (p.ej.: Algo que solía funcionar pero ahora ya no), entonces por favor informe de ello a debian-lts@lists.debian.org y ponga a la persona que preparó la actualización en copia (en caso de que no estén subscritas a la lista).

Muchos contribuidores de LTS están buscando probadores para sus paquetes actualizados. Envían llamamientos para pruebas a la lista de correo, así pues por favor subscríbase a ella y testee los paquetes que le provean cuando pueda, e infórmeles si funcionaron para usted.

Rastreador de seguridad de Debian

El equipo de Debian LTS hace uso extensivo del rastreador de seguridad o Debian Security Tracker. Esto es un base de datos de todos los problemas de seguridad de conocidos en Debian.

Los desarrolladores sacan el código de SVN (véanse las instrucciones), acometen cambios, y el sitio web actualiza automáticamente para reflejar los cambios.

Se anima fuertemente a los Desarrolladores de LTS a mantener actualizados los datos en el rastreador de seguridad. Esto incluye actualizar los siguientes archivos:

• data/CVE/list: Deberían actualizarse con más amplia información que afecte a más cosas que justo el LTS (p.ej., stable, testing). Por ejemplo, considere añadir a este fichero enlaces a informes de bugs relacionados con el problema de seguridad, enlaces a acometidas ya subidas o nuevas versiones las cuales traten la vulnerabilidad, enlaces a envíos en listas de correo públicas, informes de upstream, exploits de upstream, información relacionada con si los exploits funcionan o no, etc. Cualquier información que pudiera ser útil para el equipo de seguridad tanto como para el equipo de LTS.
• data/dla-needed.txt: Debería actualizarse para reflejar información específica de LTS, tal como quién esta trabajando en un paquete, posibles problemas que sean específicos a LTS, paquetes de pruebas disponibles, peticiones de ayuda, problemas encontrados, etc.
• data/DLA/list: En la mayoría de casos no se necesita cambiar manualmente el fichero, pues se mantiene automáticamente mediante bin/gen-DLA el cual se describe en las siguientes secciones.

Asegúrese de leer su documentación en el sitio del equipo de seguridad de Debian.

Prepare actualizaciones de seguridad para Wheezy LTS

Declare el asunto en el rastreador de seguridad (en dla-needed.txt)

Para prevenir duplicaciones de esfuerzos, asegúrese que el asunto está listado en el fichero data/dla-needed.txt del rastreados de seguridad y añada su nombre a ello. Normalmente, los asuntos son diagnosticados por el frontdesk en dla-needed.txt primero, si no, mire como se hacer abajo antes de añadir un asunto o añadir su nombre a un asunto.

Como se menciona en una sección previa, asegúrese de revisar y actualizar la información relevante en data/CVE/list cuando declare un paquete para trabajo de LTS.

Compruebe el repositorio de subversion del rastreador de seguridad:

$ svn co svn+ssh://svn.debian.org/svn/secure-testing
$ cd secure-testing

Entonces edite el fichero data/dla-needed.txt:

$ editor data/dla-needed.txt
$ svn commit -m "Claim foo in dla-needed.txt"

Construya la actualización

Retroimporte el arreglo para la versión de wheezy (en caso de que ya haya habido una reparación más temprana). Si no hay arreglo, está bien trabajar en uno nuevo: sea buen ciudadano y contribuya a cargar el parche y asegúrese de que el mantenedor y el equipo regular de seguridad estarán al tanto, mediante la adicción de ello al informe de bug contra el paquete y enlazando el informe de bug en el rastreador de seguridad.

En el registro de cambios o changelog, necesita establecer la distribución objetivo en debian/changelog a "wheezy-security". El versionado sigue las convenciones ya usadas en security.debian.org. Históricamente los nombres clave se han usado como números de versión, pero eso cambió hace tiempo ya que los números de versión son más deterministas.

• Si usted usa dch para introducir la entrada enel registro changelog, note que puede incluir el texto Non-maintainer upload by the Security Team. Es importante bien eliminar la línea, eliminar by the Security Team, o reemplazarlo con algo que se refiera al equipo de LTS, para evitar dar la apariencia de soporte por el equipo de seguridad. Cf 762715.

• Si un paquete ya tenía p.ej. una actualización +wheezy1, use +wheezy2 para la siguiente actualización.
• Si un paquete no ha visto una actualización, use +deb7u1 para la siguiente actualización.
• Para los casos raros donde se introduzcan nuevas versiones upstream, asegúrese de que usa una versión menor que en jessie. La apuesta mas segura es ~deb7u1. ¡No use justamente +wheezyX pues esto causará problemas!
• Para el caso raro donde las retroimportaciones del paquete entero desde distribuciones nuevas sea requerido (en oposición a justa el arreglo), se espera que el registro changelog no sea en orden de versión incremental.

Pruebe la actualización

Ahora construya el paquete y ejecute pruebas. Puede hacer esto asegurándose de que se ejecuta un juego incorporado de pruebas en tiempo de construcción en el entorno de LTS.Es aceptable activar o incluso retroimportar juegos de pruebas de publicaciones posteriores si están disponibles.

Si no hay juegos de pruebas disponibles, necesitara ejecutar el paquete directamente. La complejidad de esto variará con el tamaño del paquete: paquetes mas pequeños pueden ejecutarse justo en un chroot, otros necesitarán un entorno de virtualización completo, instalar procedimientos y demás. Puede ser difícil para usted probar el paquete completo, especialmente si usted no está familiarizado con el paquete de primera mano.

Dependiendo de la urgencia del arreglo de seguridad, y su confianza en su propio trabajo, podría querer buscar revisores de las partes interesadas (tales como los autores de lo subido, mantenedores Debian, equipo de seguridad, equipo de LTS, etc.). Si usted pide revisiones, debería proporcionar la siguiente información:

1. Un debdiff generado contra la versión previa en wheezy.
2. Un enlace a un paquete de prueba que pueda descargarse y probarse.

Es común para los trabajadores de LTS que carguen sus paquetes a un repositorio personal en people.debian.org, pero cualquier repositorio público o incluso un servidor web valdrá. Unas pocas pautas para esas cargas temporales:

• firme los paquetes (usando debsign, por ejemplo) para que los usuarios puedan verificar la integridad del paquete

• Asegúrese de tener la distribución objetivo configurada a UNRELEASED así pues nadie mas puede subirlos antes de que estén listos.

Carga la actualización

Asegúrese de que usó un chroot limpio para construir los paquetes binarios porque los paquetes binarios que suba acaban en el repositorio (no se los descarta y reconstruyen). Se recomienda usar sbuild/pbuilder.

Si le satisface, cargue a security-master, usando dput o dput-ng:

dput security-master hello_1.0-1+deb7u1_amd64.changes

Una vez cargado el paquete será autoconstruido para arquitecturas no cubiertas por su carga (si es un arch:any package). Las arquitecturas actualmente soportadas son amd64, i386, armel y armhf.

Pida un DLA ID en DLA/list

Ejecute bin/gen-DLA en el directorio primario del repositoiro SVN. Automáticamente genera una entrada en data/DLA/list y le pide que acometa los cambios para asegurar que no se usan IDs duplicados. La siguiente orden añadiría una entrada para src:hello arreglando CVE-2014-0666 y crearía una plantilla de asesoramiento en el directorio primario de secure-testing para usted.

$ bin/gen-DLA --save hello CVE-2014-0666

Esta lista de CVE asegurará que el rastreador de seguridad está al tanto del arregle y marcará las cuestiones como resueltas para ese paquete específico.

Anuncio de la actualización

Una vez que la carga esta completa, se le enviará un correo y a la lista de correo de debian-lts-changes, confirmando que la actualización ha sido publicada al archivo Debian. El bot de BTS también lo anunciará en el canal #debian-devel-changes.

Envie un correo a la lista de correo debian-lts-announce. El correo necesita estar firmado por una clave GPG del anillo de claves de debian o debian-maintainers. Las firmas Inline siempre funcionan (PGP/MIME funciona con mutt pero falla con Enigmail).

La plantilla de asesoramiento ha sido creada por bin/gen-DLA (véase anteriormente) y generalmente parece como esto:

Subject: [SECURITY] [DLA $DLA-1] $NOMBREPAQUETEFUENTE security update

Package        : $NOMBREPAQUETEFUENTE
Version        : $wheezy_VERSION
CVE ID         : CVE-2014-0001 CVE-2014-0002
Debian Bug     : 12345

El texto DLA viene aquí
[...]

Si usa mutt, un simple modo de enviarlo es usar mutt -H DLA-123.

Solamente cuando tenga confirmado que el paquete fue procesado tras la carga (una vez que consiga el corro de aceptación) debería enviar el DLA a la lista de correo.

Cuando todo esté hecho, debería eliminar el paquete de otras ubicaciones a las que se subió en la sección de test, en caso de haberlas.

Prepare actualizaciones de regresión para Wheezy LTS

Si una carga introduce una regresión, necesita ser arreglada lo más pronto posible.

Pasos para una actualización de regresión

1. Arregle el paquete.
2. Haga una prueba de construcción y una prueba de instalación. Verifique que la cuestión de la regresión y también la cuestión original estén resueltas ahora.
3. Asegúrese de que usó un chroot limpio para la construcción de los paquetes binarios porque los paquetes binarios que suba serán los que acaben en el repositorio (no son descartados y reconstruidos). Se recomienda usar sbuild/pbuilder.
4. Cargue el paquete arreglado a wheezy-security.
5. Use el script gen-DLA para añadir una entrada DLA al data/DLA/list y para proveerle con una plantilla de anuncios de correo. Dos posibles opciones:

   1. La regresión arregla la carga previa del paquete:

      $ bin/gen-DLA  --save $SOURCEPACKAGENAME regression

   2. La regresión arregla una carga del paquete más temprana que la previa :

      $ bin/gen-DLA  --save $PREVIOUS_DLA_ID $SOURCEPACKAGENAME regression

6. Acometa el data/DLA/list actualizado al repositorio secure-testing SVN.

7. Espere a que el paquete cargado llegue al repositorio wheezy-security.

8. En la carpeta base del repositorio secure-testing SVN, puede encontrar un fichero de plantilla autogenerada de anuncio de LTS con el nombre DLA-$DLA-{2,3,4...}. Use este fichero como la plantilla para el anuncio de su arreglo de la regresión. No acometa este fichero al SVN(!). Copie+pegue la plantilla del anuncio a su aplicación de correo, complete/edítela manualmente y finalmente envíe el correo DLA del arreglo de la regresión a debian-lts-announce@lists.debian.org.

Diagnóstico de nuevas cuestiones de seguridad

El equipo de seguridad y el equipo LTS cooperan para procesar el flujo de nueva cuestiones de seguridad que sean reportadas. Puesto que cada cuestión de seguridad tiene asignado un número CVE, llamamos normalmente a esto "diagnóstico CVE" o "CVE triage".

Si quiere ayudarnos con esto, debe primero familiarizarse con el rastreador de seguridad. Es la infraestructura que usamos para rastrear como afectan las cuestiones de seguridad a los paquetes Debian. Por favor lea cuidadosamente esta página: http://security-team.debian.org/security_tracker.html

Necesitará acceso de escritura al repositorio secure-testing.

Diagnosticar CVE en la publicación LTS

Ahora vayamos al detalle con el trabajo concerniente a LTS en particular. Empecemos por la lista de cuestiones abiertas en la publicación LTS.

Puede comenzar con la lista de la web en esta url: https://security-tracker.debian.org/tracker/status/release/oldstable O puede ejecutar bin/lts-cve-triage.py (un script del repo secure-testing) para obtener una lista prefiltrada (se excluyen paquetes de dla-needed.txt, y las cuestiones se agrupan por "status").

Para cada CVE/paquete listado en esta página, solo hay dos resultados deseables:

• Se añade el paquete al dla-needed.txt tal que alguien más tendrá que preparar y actualizar el paquete y cerrar la(s) cuestión(es) de seguridad
• Se ignora el CVE por alguna razón:
  • lo etiquetamos "no-dsa" porque es una cuestión menor de seguridad y no merece la pena actualizarlo
  • lo etiquetamos "not-affected" porque la versión de la publicación LTS no está afectada (usualmente porque el código vulnerable no está presente en la versión)

  • lo etiquetamos "end-of-life" porque el paquete nose soporta en la publicación LTS (la lista de paquetes no soportados para Wheezy está actualmente disponible aquí: http://anonscm.debian.org/cgit/collab-maint/debian-security-support.git/tree/security-support-ended.deb7. Este archivo y el paquete de debian-security-support deberían actualizarse si es necesario.)

  • lo etiquetamos como arreglado en una versión específica (asumiendo que la versión de la publicación LTS es mayor o igual, será automáticamente asumido como que está arreglado también)
  • la severidad se establece como no importante "unimportant" (que debería usarse raramente y generalmente se hace por el equipo de seguridad de todos modos)

Pautas para el diagnóstico de CVE

Ahora la parte compleja. ¿Cómo decidir si una cuestión debería añadirse al dla-needed.txt o si debería marcarse de otro modo? No existe la respuesta correcta, debería usar su mejor criterio tras haber analizado cuidadosamente la cuestión, los riesgos que involucra, etc.

Dihcho eso, el equipo de seguridad está tomando decisiones similares todo el tiempo y nosotros seguimos sus decisiones habitualmente. Si el equipo de seguridad ha añadido un paquete vulnerable a "data/dsa-needed.txt", puede usted añadirlo habitualmente con seguridad a "data/dla-needed.txt". Si el equipo de seguridad ha marcado la cuestión "no-dsa" con la descripción "Minor issue", puede con seguridad hacer lo mismo. Note que cuando la razón sea "Maintainer will update via stable-proposed-updates" seguir ciegamente no es siempre la mejor idea...

Note que algunos paquetes tienen instrucciones especiales. Haga checkout de packages/*.txt en el repositorio secure-testing. Esto podría influenciar su decisión y posiblemente impulsarle a comportarse diferentemente (por ejemplo: por no contactar al mantenedor ya que cierto acuerdo predeterminado está ya vigente).

Contacte con el mantenedor

Cuando quiera que tome una decisión para un a nueva cuestión (que sea real u afecte a la publicación LTS) debería informar a los correspondientes mantenedores del paquete para ofrecerles una oportunidad de ayudarnos. Usamos el script bin/contact-maintainers en el repositorio secure-testing para este fin.

Cuando añadimos un paquete al dla-needed.txt, puede usarlo de este modo por ejemplo:

$ bin/contact-maintainers --lts sudo CVE-2014-9680 CVE-2014-0106

Cuando marcamos las cuestiones como "no-dsa", y no planeamos encargarnos de las actualizaciones por nosotros mismos, entonces lo usamos de esta manera:

$ bin/contact-maintainers --lts --no-dsa sudo CVE-2014-9680 CVE-2014-0106

Note que la lista de CVE es opcional y que este script asumes que usted usa mutt para enviar correos. Si no, debería considerar usar la opcion --mailer para usar otra cosa (véase bin/contact-maintainer --help para más detalles). Usted debe personalizar el correo enviado (al menos para dejar de lado la lista de uploaders y posiblemente para ajustar la lista de receptores).

Obligaciones de Frontdesk

Como se describe en este correo, hay una persona asignada para el "LTS frontdesk". Las asignaciones se gestionan en la página de lts-frontdesk.2017.txt.

EL trabajo del Frontdesk actualmente incluye Diagnóstico CVE y asegurarse de que las peticiones en al lista de correo tienen una respuesta. En particular, asegurarse del seguimiento de las peticiones de patrocinio de carga de paquetes desde los nuevos contribuidores para asegurar que las cosas fluyan suavemente. Es una buena idea el seguimiento de cuestiones rancias y estancadas. Los contribuidores deben sentirse libres de para contactar al frontdesk para cualquier duda referente al LTS.

Frontdesk es también responsable de asegurar que lospaquetes revindicados en data/dla-needed.txt son cuidados. Cuando un paquete ha sido pedido durante demasiado tiempo sin actividad, notifique al peticionario y, si no hay respuesta en 24 horas, elimine el bloqueo. Se puede inspeccionar la historioa de las peticiones con:

bin/review-update-needed --lts

Mantener restreo de bugs relacionados con LTS

Estamos rastreando bugs relacionados con LTS en el rastreador de bugs de Debian usando dos etiquetas de usuario:

• ease-lts: Bugs quefacilitan el soporte a largo plazo como activar autopkgtests o juegos de pruebas internos

• infrastructure: cuestiones relacionadas con LTS de la infraestructura de Debian.

Para añadir cierta etiqueta de usuario a un bug puede usar la orden bts:

bts user debian-lts@lists.debian.org , usertags <bugnumber> ease-lts

Cambiar a la siguiente distribucion LTS

• Envíe un aviso a debian-lts-announce@lists.debian.org dos meses antes de que el soporte oficial para la ultima LTS se acabe.

• Contacte con el ?equipo de publicidad y esboce un ?anuncio de que el ciclo de vida de la vieja LTS ha llegado a su fin y uno nuevo ha comenzado. Ejemplo

• Asegúrese de que la infraestructura ya está lista para la nueva publicación LTS.
• Contacte con el equipo FTP y pídales que esperen 4 semanas con el archivado de la vieja publicación LTS para dar a los usuarios un "periodo de gracia" para que actualicen sus sistemas.
• Contacte con los Gestores de la publicación estable para coordinar el último punto de publicación (asi que ellos puedan limpiar las colas de actualizaciones propuestas).

• Actualice todas las páginas wiki relevantes especialmente Usar LTS y esta misma Desarrollo de LTS.

Tareas domésticas

Existen varias tareas en las cuales basamos nuestra labor pertenecientes al trabajo del equipo de seguridad y donde podemos ayudarles - especialmente cuando no hay cuestiones abiertas en dla-needed.txt. Esto llevará a que haya mas paquetes para arreglas:

• Fácil: Añadir referencias de bug para cuestiones no arregladas en inestable. Compruebek cuestiones no reportadas en inestable, recompruébelas y cree un bug si aun no se ha hecho. Esto asegura que no regresemos en inestable con errores corregidos en stable, oldstable. Puede usar el script bin/report-vuln para generar una plantilla de informe que será editada con el reportbug o un MUA. En caso de que usted no use reportbug para posteriormente mandar el informe de bug, porfavor X-Debbugs-CC al team@security.debian.org y a secure-testing-team@lists.alioth.debian.org. Esto se hace automáticamente si se usa reportbug.

• Difícil: Compruebe los items TODO del reastreador. Asegurese de que solo marca los items como no para nosotros, NOT-FOR-US, cuando esté seguro de que el software no está contenido en Debian bajo ninguna forma.

---

CategoryLts CategoryXWindowSystem .