Differences between revisions 25 and 26
Revision 25 as of 2016-05-31 07:31:48
Size: 18533
Editor: vauss
Comment: sync with English master
Revision 26 as of 2016-06-01 12:48:47
Size: 18533
Editor: vauss
Comment: sync with English master
Deletions are marked like this. Additions are marked like this.
Line 57: Line 57:
Selon l'urgence du correctif de sécurité, vous devez contacter toutes les parties prenantes, telles que les auteurs de l'amont, les responsables de paquet Debian, l'équipe en charge de la sécurité, l'équipe LTS, d'autres personnes impliquées, etc. Prévoyez un maximum de 4 jours pour une réponse. Vous devez fournir les informations suivantes pour une révision : Selon l'urgence du correctif de sécurité, et de votre confiance sur votre propre travail vous pourriez vouloir chercher des retours de la part de parties prenantes (telles que les auteurs de l'amont, les responsables de paquet Debian, l'équipe en charge de la sécurité, l'équipe LTS, etc.). Si vous demandez des revues sur votre travail, vous devez indiquer quand vous prévoyez d'envoyer le paquet mis à jour et vous devez fournir les informations suivantes :
Line 61: Line 62:
Il est courant pour les gens travaillant sur la LTS d'envoyer leurs paquets vers un dépôt personnel dans people.debian.org, mais n'importe quel dépôt publique ou même un simple serveur web peut convenir. Assurez-vous de signer vos paquets avec debsign et d'inclure tous les éléments du paquet (en particulier le fichier .changes) afin que les utilisateurs puissent chercher (et vérifier !) le paquet directement avec dget. Cela supprime la nécessité pour vous de créer un dépôt complet et pour eux d'ajouter et faire confiance à votre dépôt pour *toutes* les mises à jour de paquets. Il est courant pour les gens travaillant sur la LTS d'envoyer leurs paquets vers un dépôt personnel dans people.debian.org, mais n'importe quel dépôt publique ou même un simple serveur web peut convenir. Si vous signez vos paquets (ce qui est pratique pour les utilisateurs qui veulent vérifier l'origine de la mise à jour), assurez-vous d'avoir la distribution cible (« target distribution ») fixée à UNRELEASED, ainsi personne d'autre ne pourra les envoyer avant qu'ils ne soient prêts.

Translation(s): English - Français - Русский

Contribuer au projet Debian Long Term Support

L'équipe Debian LTS est toujours à la recherche de plus de volontaires afin de faire un meilleur travail. Avec plus de ressources, nous pourrions par exemple :

  • prendre en charge des paquets qui ne sont pas actuellement pris en charge ;
  • s'occuper de l'ensemble des paquets Debian et pas seulement des plus populaires ;
  • corriger les problèmes de faible priorité qui sont actuellement ignorés.

Si vous voulez vous impliquer dans l'équipe LTS et ainsi aider à garder sécurisés les paquets Debian pour 5 ans, jetez un coup d’œil à cette page. Nous partons du principe que vous êtes familier avec la structure du dépôt décrite dans la page fr/LTS/Using et que vous êtes inscrit à la liste de diffusion : http://lists.debian.org/debian-lts/.

Vous pouvez aider de plusieurs manières :

Tester les paquets mis à jour et rapporter des bogues de régressions

En tant que simple utilisateur, vous pouvez tester les paquets qui ont été mis à jour (ou qui sont en train d'être mis à jour). Si vous trouvez une régression (c'est à dire quelque chose qui marchait et qui ne fonctionne désormais plus), alors rapportez-la à la liste de diffusion debian-lts@lists.debian.org et mettez en copie la personne qui a préparée la mise à jour (au cas où cette personne ne serait pas à abonnée à cette liste).

De nombreux contributeurs de LTS sont à la recherche de testeurs pour leurs paquets mis à jour. Ils envoient des appels sur la liste de diffusion, alors veuillez vous inscrire à celle-ci et testez quand vous le pouvez les paquets qu'ils fournissent, et faites un rapport si cela fonctionne de votre coté.

Préparer les mises à jour de sécurité pour Wheezy LTS

Déclarer la prise en charge d'un problème de vulnérabilité dans dla-needed.txt

Dans le but d'éviter les doublons dans les travaux fournis, assurez-vous que le problème de vulnérabilité est listé dans data/dla-needed.txt et ajoutez votre nom à celui-ci.

$ svn co svn+ssh://svn.debian.org/svn/secure-testing
$ cd secure-testing
$ editor data/dla-needed.txt
$ svn commit -m "Claim foo in dla-needed.txt"

Droits d'écriture pour le dépôt secure-testing

Les développeurs Debian disposent automatiquement d'un accès commit vers le dépôt secure-testing. Autrement, vous devez être membre du projet Alioth secure-testing. Dans ce cas, veuillez demander une adhésion via la page du projet Alioth ou bien via la liste de diffusion debian-lts.

Construction de la mise à jour

Rétroportez (backport) les correctifs vers les versions dans wheezy (dans la cas où il y aurait déjà eu une mise à jour). Vous devez définir « wheezy-security » comme distribution cible dans debian/changelog. Le versionnage suit les conventions déjà en cours dans security.debian.org. Historiquement, les noms de code ont été utilisés comme numéros de version, mais ceci a été changé depuis quelques temps, les numéros de version étant plus déterministes.

  • Si un paquet possède déjà par exemple une mise à jour +wheezy1, utilisez +wheezy2 pour la mise à jour suivante.
  • Si un paquet ne s'est pas vu mettre à jour, utilisez +deb7u1 pour la mise à jour suivante.
  • Pour de rares cas où une nouvelle version amont a été introduite, assurez-vous d'utiliser une version plus basse que dans jessie. L'usage de ~deb7u1 est une valeur sûre. N'utilisez simplement pas quelque chose comme +wheezyX : cela posera des problèmes !
  • Pour de rares cas où sont requis les backports du paquet entier issu de nouvelles versions de Debian (plutôt que le simple correctif), il est prévu que le changelog ne sera pas dans un ordre de version s'incrémentant.

Tester la mise à jour

Maintenant, construisez le paquet et lancez vos tests.

Selon l'urgence du correctif de sécurité, et de votre confiance sur votre propre travail vous pourriez vouloir chercher des retours de la part de parties prenantes (telles que les auteurs de l'amont, les responsables de paquet Debian, l'équipe en charge de la sécurité, l'équipe LTS, etc.). Si vous demandez des revues sur votre travail, vous devez indiquer quand vous prévoyez d'envoyer le paquet mis à jour et vous devez fournir les informations suivantes :

  1. un debdiff généré sur la version précédente dans wheezy ;
  2. un lien vers un paquet de test qui peut être téléchargé et testé.

Il est courant pour les gens travaillant sur la LTS d'envoyer leurs paquets vers un dépôt personnel dans people.debian.org, mais n'importe quel dépôt publique ou même un simple serveur web peut convenir. Si vous signez vos paquets (ce qui est pratique pour les utilisateurs qui veulent vérifier l'origine de la mise à jour), assurez-vous d'avoir la distribution cible (« target distribution ») fixée à UNRELEASED, ainsi personne d'autre ne pourra les envoyer avant qu'ils ne soient prêts.

Envoyer la mise à jour

Si vous en êtes satisfait, faites un upload vers security-master en utilisant dput ou dput-ng :

dput security-master hello_1.0_amd64.changes

Une fois l'upload terminé, le paquet sera automatiquement compilé pour les architectures amd64, i386, armel et armhf (si c'est un paquet arch:any).

Si vous utilisez dput-ng, vous devez appliquer le patch de 745806. Après ceci, « dput CHANGES file » est suffisant.

Déclarer un ID DLA dans DLA/list

Lancez bin/gen-DLA dans le dans le répertoire principal du dépôt SVN. Ceci génère automatiquement une entrée dans data/DLA/list et vous demande de faire un commit des changements apportés pour faire en sorte qu'aucun ID n'est utilisé deux fois. La commande suivante devrait ajouter une entrée pour src:hello corrigeant le CVE-2014-0666 et créer pour vous une annonce « type » dans le répertoire racine secure-testing.

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

Cette liste de CVE vous assurera que le suivi de la sécurité sera au courant du correctif et marquera les problèmes comme résolus pour ce paquet spécifique.

Annoncer la mise à jour

Maintenant que l'envoi est réalisé, un courriel sera envoyé à la liste de diffusion debian-lts-changes, confirmant que la mise à jour a été publiée dans l'archive de Debian.

Vous devriez normalement recevoir directement un courriel, mais ceci n'est pas encore implémenté, voir 796784.

Envoyez un courriel à la liste de diffusion debian-lts-announce. Le courriel doit être signé par une clé PGP dans le trousseau de clés debian.org ou debian-maintainers. Les signature en ligne (inline) sont obligatoires.

Une annonce « type » a été créée par bin/gen-DLA (voir plus haut) et ressemble généralement à :

Subject: [DLA $DLA-1] $SOURCEPACKAGENAME security update

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

DLA text goes here
[...]

Si vous utilisez mutt, une façon simple pour l'envoyer est d'utiliser mutt -H DLA-123.

Vous devez envoyer le DLA à la liste de diffusion seulement après que vous ayez obtenu confirmation que le paquet a été traité après l'envoi (une fois que vous avez reçu le courriel d'acceptation).

Cela peut prendre un certain temps pour que ces courriels vous parviennent : Dak traite la file d'attente des envois toutes les 15 minutes et « dinstall », qui déplace les paquets dans l'archive principale, est lancé seulement 4 fois par jour par Dak. Vous pouvez consulter le marqueur gauche du fichier .upload lorsque dput a envoyé les paquets afin de voir à quel moment les paquets ont été envoyés.

Quand tout cela est fait, vous devez supprimer le paquet dans la section de test des autres emplacements où il a été envoyé, le cas échant.

Préparer les mises à jour de régressions pour Wheezy LTS

Si un upload introduit une régression, celle-ci doit être corrigée aussi vite que possible.

Étapes pour une mise à jour corrigeant une régression

  1. Corrigez le paquet.
  2. Faites un test de construction et un test d'installation. Vérifiez que le problème de régression ainsi que le problème de vulnérabilité original soient tous deux maintenant corrigés.
  3. Faites un upload du paquet corrigé vers wheezy-security.
  4. Utilisez le script gen-DLA pour ajouter une entrée DLA à data/DLA/list et pour vous donner un modèle d'annonce de courriel. Deux possibilités :
    1. La régression corrige l'upload précédent du paquet :

      $ bin/gen-DLA  --save $SOURCEPACKAGENAME regression
    2. La régression corrige une version antérieure à l'upload précédent du paquet :

      $ bin/gen-DLA  --save $PREVIOUS_DLA_ID $SOURCEPACKAGENAME regression
  5. Faites un commit de data/DLA/list mis à jour vers le dépôt SVN secure-testing.

  6. Attendez que le paquet uploadé arrive dans le dépôt wheezy-security.
  7. Dans le dossier de base du dépôt SVN secure-testing, vous pouvez trouver un fichier généré automatiquement de modèle d'annonce LTS ayant comme nom DLA-$DLA-{2,3,4...}. Utilisez ce fichier comme modèle pour votre annonce de correction de régression. Ne faites pas un commit de ce fichier sur le SVN(!). Copiez/collez le modèle d'annonce dans votre application de courriel, complétez/éditez le manuellement et envoyez finalement le courriel de correction de régression DLA à debian-lts-announce@lists.debian.org.

Triage de nouveaux problèmes de sécurité

L'équipe en charge de la sécurité et l'équipe LTS coopèrent pour traiter le flux de nouveaux problèmes de sécurité qui sont signalés. Depuis qu'est assigné un numéro CVE à chaque problème de sécurité, nous appelons souvent cela « triage CVE ».

Si vous voulez nous aider avec ceci, vous devez d'abord vous familiariser avec le tracker de sécurité. C'est l'infrastructure que vous utilisons pour suivre la façon dont les problèmes de sécurité affectent les paquets Debian. Veuillez lire avec attention cette page : http://security-team.debian.org/security_tracker.html.

Vous aurez besoin de droits d'écriture pour le dépôt secure-testing.

Le triage CVE dans la version LTS

Abordons maintenant en détail le travail concernant LTS en particulier. Nous commençons à partir de la liste des problèmes ouvert dans la version LTS.

Vous pouvez démarrer avec la liste suivante : https://security-tracker.debian.org/tracker/status/release/oldstable ou bien, vous pouvez lancer le script bin/lts-cve-triage.py (script disponible dans le dépôt secure-testing) afin d'obtenir une liste pré-filtrée (les paquets dans dla-needed.txt sont exclus et les problèmes sont regroupés par « statut »).

Pour chaque CVE/paquet listé sur cette page, il y a seulement 2 résultats souhaitables :

  • le paquet est ajouté à dla-needed.txt, par conséquent quelqu'un d'autre devra préparer un paquet mis à jour et clore le(s) problème(s) de sécurité correspondant(s)
  • le CVE est ignoré pour certaines raisons :
    • nous étiquetons « no-dsa » car c'est un problème de sécurité mineur qui ne mérite pas une mise à jour
    • nous étiquetons « not-affected » car la version disponible dans la LTS n'est pas affectée (généralement parce que le code vulnérable n'est pas présent dans cette version)
    • nous étiquetons « end-of-life » car le paquet n'est pas pris en charge dans la LTS (la liste des paquets non pris en charge pour Wheezy est actuellement disponible ici : http://anonscm.debian.org/cgit/collab-maint/debian-security-support.git/tree/security-support-ended.deb7. Ce fichier et le paquet debian-security-support doivent être mis à jour si nécessaire.)

    • nous étiquetons comme corrigé dans une version spécifique (partant du principe que la version disponible dans la LTS est supérieure ou égale, on suppose qu'elle a aussi été automatiquement corrigée)
    • la sévérité est définie sans importance (« unimportant ») (ceci devrait rarement être utilisé et sera en principe réalisé par l'équipe en charge de la sécurité)

Bonnes pratiques pour le triage CVE

Voici maintenant la partie délicate. Comment décider si un problème doit être ajouté au fichier dla-needed.txt ou bien s'il doit être étiqueté d'une autre manière ? Il n'y a pas de réponse parfaite. Vous devrez user de votre meilleur jugement après avoir analysé le problème avec soin, les risques encourus, etc.

Ceci étant, l'équipe en charge de la sécurité prend ce genre de décisions tout le temps, et nous les suivons. Si l'équipe en charge de la sécurité a ajouté un paquet vulnérable à « data/dsa-needed.txt », vous pouvez généralement l'ajouter sans risque à « data/dla-needed.txt ». Si l'équipe en charge de la sécurité a étiqueté le problème « no-dsa » avec une description « Minor issue », vous pouvez faire de même en toute sureté. Notez que quand la raison est « Maintainer will update via stable-proposed-updates » suivre aveuglément n'est pas toujours la meilleure idée...

Notez que certains paquets ont des instructions spéciales. Vérifiez packages/*.txt dans le dépôt secure-testing. Ceci pourrait influencer votre décision et possiblement vous inciter à vous comporter différemment (par exemple, en ne contactant pas le mainteneur puisque certains accords prédéterminés sont déjà mis en place).

Contacter le mainteneur

Chaque fois que vous prenez une décision pour un nouveau problème (qui est réel et affecte la version LTS), vous devez en informer les mainteneurs du paquet correspondant pour leur offrir l'opportunité de vous aider. Pour cela, nous utilisons le script bin/contact-maintainers dans le dépôt secure-testing.

Lorsque nous ajoutons un paquet à dla-needed.txt, vous pouvez par exemple utiliser ce script de la façon suivante :

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

Lorsque nous étiquetons « no-dsa » et que nous ne prévoyons pas de nous occuper nous-mêmes des mises à jour, alors nous utilisons ce script comme ceci :

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

Notez que la liste de CVE est optionnelle et que ce script suppose que vous utilisez mutt pour envoyer des courriels. Si ce n'est pas le cas, vous pouvez envisager l'utilisation de l'option --mailer afin de l'utiliser avec quelque chose d'autre (voir bin/contact-maintainer --help pour plus de détails). Vous devez personnaliser le courriel envoyé (au moins laisser la liste des uploaders et éventuellement ajuster la liste des destinataires).

Fonctionnalités « de guichet »

Comme décrit dans ce courriel, il y a une personne attitrée pour tenir un « guichet » pour le projet LTS. Les répartitions des personnes au guichet sont gérées dans la page lts-frontdesk.2016.txt.

Le travail du « guichet » concerne actuellement le triage CVE et le fait de s'assurer que les questions sur la liste de diffusion obtiennent une réponse. Il s'assure en particulier du suivi des questions et requêtes de parrainage sur l'envoi des paquets auprès des nouveaux contributeurs pour faire en sorte que tout ceci se réalise de manière fluide. Le suivi des problèmes anciens ou au point mort est également une bonne idée. Le guichet est à l'écoute de toute question des contributeurs concernant la LTS.

Garder une trace des bogues en relation avec la LTS

L'utilisation de deux « usertags » dans le système de suivi des bogues de Debian permet de garder une trace des bogues en relation avec la LTS :

  • ease-lts : les bogues qui concernent la facilitation de la prise en charge à long terme telles que l'activation de autopkgtests ou des suites de tests internes ;

  • infrastructure : problèmes liés à la LTS dans l'infrastructure Debian.

Pour ajouter un « usertag » spécifique à un bogue, vous pouvez utiliser la commande bts :

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

Passer à la version LTS suivante

  • Envoyer un rappel à debian-lts-announce@lists.debian.or deux mois avant la fin de la prise en charge officielle de la dernière version LTS.

  • Contacter l'équipe Publicity et rédiger une annonce selon laquelle le cycle de l'ancienne version LTS touche à sa fin et qu'un nouveau cycle a commencé (exemple).

  • S'assurer que l'infrastructure est prête pour la nouvelle version LTS.
  • Contacter l'équipe FTP et leur demander d'attendre 4 semaines pour archiver l'ancienne version LTS afin de donner un délai aux utilisateurs pour mettre à jour leurs systèmes.
  • Contacter les responsables de la version « stable » afin de coordonner la dernière version intermédiaire (et ils pourront ainsi nettoyer les files d'attente des mises à jour proposées).
  • Mettre à jour toutes les pages du wiki, spécialement LTS/Using et cette page LTS/Development.


CategoryLts CategoryXWindowSystem