Differences between revisions 109 and 110
Revision 109 as of 2021-05-15 20:49:41
Size: 48451
Editor: vauss
Comment: sync with English version
Revision 110 as of 2021-07-02 20:21:03
Size: 48431
Editor: vauss
Comment: sync with English version
Deletions are marked like this. Additions are marked like this.
Line 318: Line 318:
Question/Réponse : le coordinateur LTS (Lynoure) exécute [[https://salsa.debian.org/webmaster-team/webwml/-/blob/master/english/security/find-missing-advisories|find-missing-advisories]] [[https://lists.debian.org/debian-lts/2020/08/msg00032.html|chaque semaine]]. Question/Réponse : le coordinateur LTS exécute [[https://salsa.debian.org/webmaster-team/webwml/-/blob/master/english/security/find-missing-advisories|find-missing-advisories]] [[https://lists.debian.org/debian-lts/2020/08/msg00032.html|chaque semaine]].
Line 466: Line 466:
Le « guichet » est également en charge de s'assurer que les paquets déclarés dans `data/dla-needed.txt` sont pris en charge. Lorsqu'un paquet sans activité a été déclaré depuis trop longtemps, il doit en notifier le déclarant et, s'il n'y a pas de réponse sous 24 heures, supprimer le verrou. Note : actuellement (avril 2019), le coordinateur LTS (Lynoure) le fait dans le cadre de la coordination LTS. L'historique des déclaration peut être consulté avec : Le « guichet » est également en charge de s'assurer que les paquets déclarés dans `data/dla-needed.txt` sont pris en charge. Lorsqu'un paquet sans activité a été déclaré depuis trop longtemps, il doit en notifier le déclarant et, s'il n'y a pas de réponse sous 24 heures, supprimer le verrou. Note : actuellement (avril 2019), le coordinateur LTS le fait dans le cadre de la coordination LTS. L'historique des déclaration peut être consulté avec :

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

7 étapes pour publier un DLA (Debian Security Advisory - Bulletin d'alerte Debian)

Comment préparer des mises à jour de sécurité pour LTS :

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é.

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é.

Gestionnaire de sécurité de Debian (Debian Security Tracker)

L'équipe Debian LTS utilise intensif du Gestionnaire de sécurité de Debian. Il s'agit d'une base de données de tous les problèmes de sécurité connus dans Debian.

Les développeurs vérifient la source Git (voir les instructions), les changements des commits, et le site web se met automatiquement à jour pour refléter les changements.

Les développeurs LTS sont fortement encouragés à garder à jour les données dans le gestionnaire de sécurité. Cela inclus la mise à jour des fichiers suivants :

  • data/CVE/list : doit être mis à jour avec des informations plus larges qui affectent plus que simplement la LTS (c'est à dire, stable, testing). Par exemple, pensez à ajouter à ce fichier des liens vers des rapports de bogues liés au problème de sécurité, des liens vers des commits ou de nouvelles versions amonts qui traitent de la vulnérabilité, des liens vers des messages sur des listes de diffusion publiques, des rapports amonts, des exploitations de failles de sécurité amonts, des informations qui renseignent si les exploitations de failles fonctionnent ou non, etc. N'importe quelle information qui pourrait être utile à l'équipe en charge de la sécurité et à l'équipe LTS.
  • data/dla-needed.txt: doit être mis à jour pour tenir compte d'informations spécifiques à la LTS, comme qui travaille sur tel paquet, les problèmes potentiels spécifiques à la LTS, les paquets de test disponibles, les demandes d'aide, les problèmes rencontrés, etc.
  • data/DLA/list : dans la plupart des cas il n'est nul besoin de modifier manuellement ce fichier, puisque il est maintenu automatiquement par bin/gen-DLA décrit dans les sections suivantes.

Assurez-vous de consulter sa documentation sur le site web de l'équipe en charge de la sécurité de Debian.

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

Déclarer la prise en charge d'un problème de vulnérabilité dans le gestionnaire de sécurité (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 le fichier data/dla-needed.txt du gestionnaire de sécurité et votre nom à celui-ci. En principe, les problèmes sont d'abord triés par le « guichet » (Front desk) dans dla-needed.txt. Sinon, vous devez ajouter le problème de sécurité vous-même dans dla-needed.txt. Regardez comment cela est fait plus bas avant d'ajouter un problème ou votre nom à un problème.

Nous donnons un délai de 24 à 72 heures aux mainteneurs de paquets avant de prendre en charge nous-mêmes les mises à jour, en fonction de la gravité du problème de sécurité.

Comme mentionné dans la section précédente, assurez-vous d'examiner et mettre à jour les informations pertinentes dans data/CVE/list lors de la déclaration d'un paquet pour le travail de la LTS.

Vous devez ne déclarer cela que pour la durée active de votre travail. Vous êtes censés gérer activement le problème dans les 2 à 3 jours et vous êtes également censés annoncer votre intention de transmettre (uploader) pour que d'autres puissent tester cela durant quelques jours (3 ou 4) supplémentaires. Si vous ne pouvez pas résoudre le problème dans les 2 ou 3 jours, veuillez alors mentionner la raison pour laquelle cela prend plus de temps, jusqu'où vous êtes allés, les résultats préliminaires et/ou laisser cela à quelqu'un d'autre pour y travailler dessus. Vous ne voulons pas que des gens travaillent sur un paquet quelques heures, attendent quelques jours, travaillent à nouveau dessus, attendent encore, et ainsi de suite.

Vérifiez le dépôt git du gestionnaire de sécurité : (Utilisation d'un clone peu profond car sinon l'opération durera une demi-heure. Il faudra toujours quelques minutes au clone.)

{{{
$ git clone --depth 1 git@salsa.debian.org:security-tracker-team/security-tracker
$ cd security-tracker
$ sudo apt install python3-apt
$ bin/setup-repo

setup-repo installe un hook de pré-commit pour vérifier la syntaxe du fichier de données.

Puis éditez le fichier data/dla-needed.txt :

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

Droits d'écriture pour le dépôt security-tracker

Les développeurs Debian disposent automatiquement d'un accès commit vers le dépôt security-tracker. Autrement, vous devez être membre du projet security-tracker sur salsa.debian.org. Dans ce cas, veuillez demander une adhésion via le projet gitlab de l'équipe en charge de la sécurité, la liste de diffusion du gestionnaire de sécurité ou bien la liste de diffusion debian-lts.

Construction de la mise à jour

Rétroportez (backport) les correctifs vers les versions dans LTS (dans la cas où il y aurait déjà eu une mise à jour). Assurez-vous que le correctif a été approuvé par le projet amont (par exemple, soumettre à leur répertoire de développement) : parfois, les premières propositions de correctifs sont erronées ou incomplètes. S'il n'y a rien à corriger, il serait bon de travailler à un autre niveau : contribuer au patch de retour de l'amont et s'assurer que le mainteneur et que les équipes habituelles en charge de la sécurité sont au courant en ajoutant cela à un rapport de bogue pour le paquet et en ajoutant le lien de ce rapport de bogue dans le gestionnaire de sécurité (Si le problème traité nécessite AddressSanitizer afin de reproduire la vulnérabilité et de confirmer le correctif, dans ce cas cette page (en anglais) pourrait vous être utile).

Si le correctif est fourni avec de nouveaux fichiers binaires (par exemple des cas de test), ils ne seront pas acceptés par quilt, mais vous pouvez les référencer dans debian/source/include-binaries et ils seront directement inclus dans le .debian.tar.xz fichier (discussion).

Dans le journal des modifications (changelog), vous devez définir « stretch-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 vous utilisez dch (pre-buster) pour faire l'entrée du changelog, il pourrait inclure le texte Non-maintainer upload by the Security Team. Il est important d'enlever la ligne, ou d'enlever by the Security Team, ou encore de la remplacer avec quelque chose se référant à l'équipe LTS, afin d'éviter de donner l'apparence d'une prise en change par l'équipe en charge de la sécurité. Voir 762715 ((« Non-maintainer upload by the LTS Security Team »).

  • Si un paquet possède déjà par exemple une mise à jour +deb9u1, utilisez +deb9u2 pour la mise à jour suivante.
  • Si un paquet ne s'est pas vu mettre à jour, utilisez +deb9u1 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 stretch. Voir la discussion. N'utilisez simplement pas quelque chose comme +stretchX : 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.

Les numéros du BTS peuvent être référencés mais ne sont actuellement pas traités.

Notez que pour les paquets non natifs, les mises à jour vers security-master nécessitent de fournir l'archive source (même si elle est déjà présente dans la distribution pour laquelle vous faites la mise à jour) en utilisant 'dpkg-buildpackage -sa'.

Assurez-vous que vous avez utilisé un chroot propre pour construire les paquets binaires. L'usage de sbuild/pbuilder est recommandé. Par exemple :

# Init
sudo pbuilder --create --basetgz /var/cache/pbuilder/base-stretch.tgz --distribution stretch --othermirror 'deb http://security.debian.org/ stretch/updates main contrib'
sudo pbuilder --update --basetgz /var/cache/pbuilder/base-stretch.tgz
# Rebuild source and binary packages from Stretch (in extracted source)
export DEB_BUILD_OPTIONS="parallel=$(nproc)"
pdebuild --use-pdebuild-internal --buildresult .. --debbuildopts '-S' -- --basetgz /var/cache/pbuilder/base-stretch.tgz
# Rebuild binary packages from Stretch, reproducing buildd's separate build-indep/build-arch
# - first security upload:
sudo --preserve-env=DEB_BUILD_OPTIONS pbuilder --build --basetgz /var/cache/pbuilder/base-stretch.tgz --source-only-changes --logfile build-indep.log --buildresult . --binary-indep --debbuildopts '-sa' package+deb9u1.dsc
sudo --preserve-env=DEB_BUILD_OPTIONS pbuilder --build --basetgz /var/cache/pbuilder/base-stretch.tgz --source-only-changes --logfile build-arch.log  --buildresult . --binary-arch  --debbuildopts '-sa' package+deb9u1.dsc
# - later uploads:
sudo --preserve-env=DEB_BUILD_OPTIONS pbuilder --build --basetgz /var/cache/pbuilder/base-stretch.tgz --source-only-changes --logfile build-indep.log --buildresult . --binary-indep package+deb9u2.dsc
sudo --preserve-env=DEB_BUILD_OPTIONS pbuilder --build --basetgz /var/cache/pbuilder/base-stretch.tgz --source-only-changes --logfile build-arch.log  --buildresult . --binary-arch  package+deb9u2.dsc

{{{#!wiki tip
Pour construire le paquet binaire, vous pouvez utiliser une « porter box » surtout si vous avez besoin de corriger une régression qui concerne une architecture spécifique à laquelle vous n'avez pas accès. Voir PorterBoxHowToUse pour les instructions d'utilisation des « porterboxes ».

Voir également :

Tester la mise à jour

Consultez suites de test pour des instructions de test spécifique à des paquets.

S'il existe une suite de test déjà faite, assurez-vous qu'elle s'exécute correctement durant la construction dans l'environnement LTS. Il est acceptable d'activer ou même de rétroporter des suites de test à partir de version ultérieures si elles sont disponibles.

Il peut aussi y avoir des tests DEP-8 dans debian/tests, à exécuter avec autopkgtest. Activez par exemple TestSuites/rails pour une exécution directe ou TestSuites/sane-backends pour un environnement LXC complet.

S'il n'y a pas de suites de test disponibles, vous aurez besoin d'exécuter et de tester directement le paquet. Préférez un environnement complet (virtualisé ou même parfois physique).

Vérifiez les dépendances inverses (find-rdeps, apt-rdepends -r), dose-ceve à partir de dose-extra), et installez-en quelques uns pour vérifier si votre paquet s'exécuter correctement avec eux.

Il vaut mieux tester avec à la fois l'architecture 32 bits et l'architecture 64 bits, voir par exemple CVE-2019-14866.

Vérifiez la mise à jour de votre paquet avec des outils génériques :

# check for common packaging issues in last build
# from extracted source after build, stretch host (only check new errors)
lintian -i
# inspect source changes
debdiff package+deb9u3.dsc package+deb9u4.dsc | diffstat
debdiff package+deb9u3.dsc package+deb9u4.dsc | less
# inspect binary changes
debdiff --from deb9u3/*.deb --to deb9u4/*.deb
# test package upgrade
sudo piuparts -d stretch \
  --extra-repo='deb http://security.debian.org/ stretch/updates main contrib' \
  -l piuparts-package.log \
  -I :etc/buggy-dep \
  --single-changes-list package+deb9u4_{all,amd64}.changes \
  | grep -P '(INFO|ERROR):'
# also consider --install-remove-install

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 LTS ;
  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. Quelques lignes directrices pour ces ajouts temporaires :

  • signez les paquets (en utilisant debsign, par exemple), les utilisateurs pourront ainsi en vérifier l'intégrité ;

  • 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

Les uploads vers Debian LTS sont do not wait pour un DLA ou toute autre intervention manuelle avant d'être installés dans l'archive Debian. À cet égard, ils diffèrent des téléchargements de sécurité stables.

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

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

Une fois uploadé, le paquet sera automatiquement compilé pour les architectures non couvertes par votre envoi (si c'est un paquet arch:any). Les architectures actuellement prises en charge sont amd64, i386, armel et armhf. Vérifiez les journaux de compilation à : https://buildd.debian.org/status/package.php?suite=stretch-security&p=SOURCE_PACKAGE

Built-Using fait référence à un paquet source inexistant : si votre paquet est rejeté pour cette raison, ouvrez un rapport de bogue pour le paquet ftp.debian.org demandant l'ajout du paquet manquant. Voir par exemple 974877 ou 974954.

Déclarer un ID DLA dans DLA/list

Lancez bin/gen-DLA dans le dans le répertoire principal du dépôt Git. 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.

$ DEBFULLNAME=xxx bin/gen-DLA --save hello CVE-2014-0666
# OR
$ DEBFULLNAME=xxx bin/gen-DLA --save .../hello_1.2-3+deb9u4_source.changes

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.

Dans data/CVE/list, vous devez supprimer manuellement le triage de la suite précédente pour les vulnérabilités corrigées

  • (par exemple, [stretch] - package <postponed>). Cependant, l'annotation {DLA-XXXX-1} sera ajouté par le cron bi-quotidien, et la version corrigée sera déduite automatiquement (ne l'ajoutez pas).

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. Le robot du système de suivi des bogues (BTS) l'annoncera également dans le canal #debian-devel-changes.

Envoyez un courriel à la liste de diffusion debian-lts-announce. Le courriel doit être signé par une clé GPG dans le trousseau de clés debian.org ou debian-maintainers. Les signature en ligne (inline) fonctionnent toujours (PGP/MIME fonctionne avec mutt mais échoue avec Enigmail.Thunderbird échoue à partir de la version 76). Si vous utilisez mutt, une façon simple d'envoyer cela est d'employer

mutt -e "set signature=/dev/null" -H DLA-123

La commande simple « mail » fonctionne :

cat DLA-XXXX.txt | gpg --clearsign | mail -s "[SECURITY] [DLA XXXX-X] $SOURCEPACKAGENAME security update" -a "From: Max Mustermann <max.mustermann@debian.org>" -r max.mustermann@debian.org debian-lts-announce@lists.debian.org

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        : $LTS_VERSION
CVE ID         : CVE-2014-0001 CVE-2014-0002
Debian Bug     : 12345

DLA text goes here
[...]

En plus de décrire les vulnérabilités, n'oubliez pas d'ajouter une courte description du paquet afin que l'audience puisse mieux comprendre le contexte et savoir si elle est affectée.

Veuillez également ne pas ajouter vos signatures personnelles aux DLA.

Si vous utilisez mutt, une façon simple pour l'envoyer est d'utiliser mutt -e "set signature=/dev/null" -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).

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.

Voir également : Référence du développeur Debian - Annonces de sécurité

Préparer une mise à jours sur le site web

Après avoir envoyé le courriel, vous devez également mettre à jour le site Web principal debian.org avec la nouvelle annonce. Pour cela, vous avez besoin d’une copie de la source du site Web. Avantages :

Pour cela, vous avez besoin d'une copie de la source du site. Ceci est une configuration unique :

/!\ Il est recommandé de demander d'être membre du groupe de webmasters sur Salsa. Autrement vous devez faire une demande de fusion. Ce flux de travail est en cours.

git clone https://salsa.debian.org/webmaster-team/webwml
# or: salsa fork webmaster-team/webwml
# /usr/bin/salsa is part of devscripts in sid and stretch-bpo
cd webwml/

Si vous avez créé un fork salsa, vous pouvez faire ce qui suit (une fois) pour tout préparer afin de pouvoir vous déconnecter de l'équipe webmaster-team/webwml au lieu de votre fork. C'est utile si vous effectuez plusieurs (avec un intervalle de temps) mises à jour de site Web.

git remote add upstream https://salsa.debian.org/webmaster-team/webwml

Ensuite, en supposant que le numéro est DLA-1234-1 et que le modèle de courriel est dans ~-./DLA-1234-1, procédez comme suit :

git checkout -b DLA-1234-1

Ou si vous l'avez préparé pour avoir un amont séparé :

git fetch upstream
git checkout -b DLA-1234-1 upstream/master

Faites la mise à jour

cd english/lts/security
./parse-dla.pl ~/DLA-1234-1
$EDITOR 2020/dla-1234* # make sure everything looks good
                       # Other option is, instead of looking at the html code, doing
                       # $ make -C 2020 dla-123.en.html
# and open the resulting html file with a web browser.
git add 2020/dla-1234.{data,wml}
git commit -m 'DLA-1234-1'

Si vous êtes membre du projet debian-www sur salsa :

git push -u origin

Si vous n'êtes pas membre, vous devez fournir une demande de fusion. Poussez-le d'abord sur votre fork, puis faites la demande de fusion :

git push --set-upstream origin DLA-1234-1
# Do this either one the command-line with 'salsa mr'
salsa mr
# or you need to be logged into the web ui and then go to
# https://salsa.debian.org/webmaster-team/webwml/merge_requests and press the green button labeled "new merge request"

Question/Réponse : le coordinateur LTS exécute find-missing-advisories chaque semaine.

Préparer les mises à jour de régressions pour 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. Assurez-vous que vous avez utilisé un chroot propre pour construire les paquets binaires. L'usage de sbuild/pbuilder est recommandé.

  4. Faites un upload du paquet corrigé vers stretch-security.
  5. 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
      
      
      # /!\ $PREVIOUS_DLA_ID nécessite d'être incrémenté...
  6. Attendez que le paquet uploadé arrive dans le dépôt stretch-security.
  7. Dans le dossier de base du dépôt Git security-tracker, 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 Git(!). 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.

  8. Préparez une mise à jour pour le site web

  9. Note : si un DLA nécessite un correctif dans un autre paquet, utilisez le même nombre majeur du DLA (voir le courriel)

Préparer d'autres mises à jour (non liées à la sécurité) pour la LTS

Étapes pour une mise à jour de correction de bogue

  1. Corrigez le paquet.
  2. Faites un test de construction et testez l'installation. Vérifiez que le problème de régression et le problème d'origine sont désormais vraiment résolus.
  3. Assurez-vous d'utiliser un chroot propre pour la construction. L'utilisation de sbuild/pbuilder est recommandée.

  4. Téléchargez le paquet corrigé vers stretch-security.
  5. Utilisez le script gen-DLA pour ajouter une entrée DLA à data/DLA/list et pour vous fournir un modèle de courriel d'annonce :

    $ bin/gen-DLA  --save $SOURCEPACKAGENAME
  6. Attendez que le paquet téléchargé arrive dans le référentiel stretch-security.
  7. Dans le dossier de base du dépôt Git de security-tracker, vous pouvez trouver un fichier de modèle d'annonce LTS généré automatiquement avec le nom DLA-$DLA-{2,3,4...}. Utilisez ce fichier comme modèle pour votre annonce de correction de bogue. Ne soumettez pas ce fichier à Git(!). Copiez et collez le modèle d'annonce dans votre application de messagerie, complétez ou modifiez-le manuellement et envoyez enfin le courriel DLA de correction de régression à debian-lts-announce@lists.debian.org.

  8. Préparez une mise à jour pour le site Web

  9. Remarque : si un DLA nécessite un correctif dans un autre paquet, utilisez le même numéro majeur DLA (voir le courriel)

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 git security-tracker.

Le triage CVE dans la version LTS

Abordons maintenant le flux de travail additionnel spécifique à LTS. Nous commençons à partir de la liste des problèmes ouverts dans la version LTS.

Vous pouvez démarrer avec la liste suivante : https://security-tracker.debian.org/tracker/status/release/oldstable (cochez « include issues to be checked ») ou bien, vous pouvez lancer le script bin/lts-cve-triage.py (script disponible dans le dépôt security-tracker) 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 ne déclenche pas une mise à jour immédiate du paquet :
    • nous étiquetons « postponed » quand il s'agit d'un problème mineur à corriger mais qui pourrait être corrigé prochainement. Étant donné que LTS n'a pas de points de mise à jour, cela se présente quand il y a un problème plus grave, ou lorsque beaucoup de problèmes mineurs s'accumulent.
    • nous étiquetons « ignored » quand il y a une raison forte/valable de ne *pas* le corriger (par exemple, il ne se trouve que dans les sources non compilées et non expédiées ; il n'est pas critique et trop difficile à rétroporter ; il n'est pas critique et nécessite un changement d'API affectant les dépendances inverses).
    • nous étiquetons « not-affected » quand 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 » quand le paquet n'est pas pris en charge dans la LTS (la liste des paquets non pris en charge pour Stretch est actuellement disponible ici : https://salsa.debian.org/debian/debian-security-support/blob/master/security-support-ended.deb8. 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é était 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é)
    • « no-dsa » est une étiquette plus vague incluant « postponed » and « ignored » documentation du gestionnaire de sécurité. L'équipe Debian Security a tendance à marquer les vulnérabilités non accessibles par Internet comme « minor » (mineures), car elles ne sont pas directement exploitables, mais elles permettent une plus grande pénétration lorsque l'attaquant met un pied dans l'infrastructure de la victime.

Il y a quelques différences entre le tri de LTS et le tri de la sécurité Debian :

  • LTS n'a pas de points de mise à jour
  • Moins de mainteneurs veulent aider avec les correctifs LTS

Cela a principalement une implication sur le moment où les CVE sont marqués comme no-dsa. Si l'équipe en charge la sécurité de Debian marque le paquet comme non-dsa, le responsable du paquet peut décider de le corriger. Cela explique pourquoi certains paquets ont des problèmes mineurs résolus alors que d'autres ne le sont pas. Les vulnérabilités corrigées n'ont pas besoin d'être critiques.

De plus, une mise à jour de sécurité peut avoir un impact sur les services des utilisateurs finaux (par exemple, nécessite le redémarrage d'un démon, ou simplement la supervision d'un administrateur système pour chaque mise à niveau dans un grand réseau), par conséquent grouper les problèmes « postponed » est généralement une bonne idée (ni trop souvent, pour éviter ces impacts, ni trop rares, pour éviter de faire trainer un important arriéré de modifications avec un correctif de sécurité plus important).

Finalement, une partie du travail de triage comprend le classement des bogues non documentés pour les problèmes de sécurité dans le système de suivi de bogues, en utilisant le script bin/report-vuln. Les bogues doivent être classés sauf si le problème est déjà résolu dans unstable, en évitant bien sûr les doublons.

Bonnes pratiques pour le triage CVE

Le « guichet » est responsable pour le triage initial de CVE. Personne ne devrait circonvenir à cette procédure sans une très bonne raison.

Voici deux exceptions raisonnables :

  1. Une vulnérabilité CVE critique qui devrait être corrigée aussi vite que possible. Le problème est souvent sous embargo et affecte un paquet majeur avec une priorité importante et supérieure. Ceux-ci sont rares, donc cela devrait vraiment être une exception.
  2. Un membre de l'équipe est également le mainteneur d'un paquet et il ou elle est déjà au courant de la vulnérabilité et pourrait la confirmer. Veuillez laisser les gens gérer leurs propres paquets s'ils sont le mainteneur du paquet ou un contributeur régulier à un paquet maintenu en équipe.

La première étape du triage CVE est de déterminer si une certaine version du paquet est affectée

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, les problèmes causés par les administrateurs pour appliquer la mise à jour, etc. En cas de doute, vérifiez auprès des autres mainteneurs, du responsable du paquet (le script bin/report-vuln est une bonne façon d'entrer en contact avec le mainteneur) ou de l'équipe en charge de la sécurité.

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 le bug est également présent dans la version LTS du paquet). Si l'équipe en charge de la sécurité a étiqueté le problème « postponed », « ignored » ou « no-dsa » avec une description « Minor issue », vous pouvez alors utiliser habituellement le même statut pour LTS. Une exception est que lorsque la raison choisie par l'équipe de sécurité est « Maintainer will update via stable-proposed-updates », dans ce cas, nous devons préparer une mise à jour pour la version LTS puisqu'il n'y a pas (encore) de lts-proposed-updates. En outre, vous pouvez toujours résoudre les problèmes non-dsa, si vous le souhaitez.

Nous pouvons et voulons corriger les CVE dans Debia. Si un paquet a trop de CVE "postponed" ou "ignored", c'est généralement un signe qu'il est désormais temps de les corriger toutes ensemble.

En cas de doute, ajoutez plutôt un paquet à dla-needed.txt, avec une note sur le doute en question, et laissez un autre membre de l'équipe vérifier la vulnérabilité.

Vous ne devriez pas ajouter de paquets à dla-needed.txt si nous avons systématiquement ignoré certains types de CVE pour un certain paquet dans le passé ou si le CVE est vraiment mineur.

Si vous ajoutez un paquet à dla-needed.txt, vous pouvez ajouter une NOTE optionnelle pour expliquer votre processus de réflexion.

Exemples :

  • 20201124: I believe the issue is severe but patches don't exist yet. (name)
  • 20201124: I believe the issue is minor and can be postponed (name)
  • 20201124: I believe the issue is minor but there are several other ignored and postponed issues already. Let's fix all of them now? (name)

Pour souligner le fait qu'un membre de l'équipe est également le mainteneur d'un paquet.

  • 20201124: Tim is the maintainer. (name)

Si vous traitez un problème qui n'a pas encore été étudié par l'équipe de sécurité et s'il n'est pas évident que le problème justifie un DLA / DSA, il est bon de documenter cela dans une note jointe à l'entrée que vous pouvez ajouter à dla-needed.txt.

S'il n'est pas clair que le problème affecte la version Sid, vous devez également le trier et ouvrir un bogue correspondant dans l'outil de suivi des bogues (BTS) pour informer le responsable (sauf pour les problèmes d'embargo). Les mainteneurs savent souvent à quel point un problème est grave et si une mise à jour immédiate est réellement nécessaire.

Notez que certains paquets ont des instructions spéciales. Vérifiez packages/*.txt dans le dépôt security-tracker. 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 nous aider (ou pas ?). Pour cela, nous utilisons le script bin/contact-maintainers dans le dépôt security-tracker. Ne le faites que si le bug est déjà enregistré dans l'outil de gestion de bogues (BTS). Si ce n'est pas encore le cas, vous pouvez utiliser *bin/report-vuln* pour l'ouvrir. Les discussions sur la sévérité et l'urgence sont les mieux faites dans le rapport de bogue puisque toutes les parties concernées (équipe LTS, équipe en charge de la sécurité et responsables de paquets) peuvent s'impliquer.

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, nous ne communiquons généralement pas avec les responsables. Si c'est cependant nécessaire, un autre modèle est disponible :

  • :

$ 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).

Afin d'éviter au mainteneur de se sentir pressé, il y a quelques exceptions à prendre en compte :

  • si le paquet a été récemment ajouté à dsa-needed.txt, vous voudrez probablement re-formuler le courriel pour préciser que cela concerne la sécurité de long terme et non un courriel habituel de l'équipe en charge de la sécurité ;
  • assurez-vous qu'un rapport de bogue concernant le problème est également en place (si le problème de sécurité est public) avant que ce courriel ne soit envoyé ;
  • vérifiez qui était impliqué dans la communiquation du problème à l'équipe en charge de la sécurité. Si c'était le mainteneur, vous devez reformuler le courriel.

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 le fichier lts-frontdesk.2021.txt.

Le travail du « guichet » concerne actuellement le triage CVE et le fait de s'assurer que les questions sur la liste de diffusion ou sur IRC 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.

Le « guichet » est également en charge de s'assurer que les paquets déclarés dans data/dla-needed.txt sont pris en charge. Lorsqu'un paquet sans activité a été déclaré depuis trop longtemps, il doit en notifier le déclarant et, s'il n'y a pas de réponse sous 24 heures, supprimer le verrou. Note : actuellement (avril 2019), le coordinateur LTS le fait dans le cadre de la coordination LTS. L'historique des déclaration peut être consulté avec :

bin/review-update-needed --lts

Enfin, il devrait toujours y avoir une personne disponible dans une semaine donnée sur le service de guichet. Lorsque vous démarrez le guichet, assurez-vous que les 4 prochaines semaines sont déclarées par quelqu'un dans la liste de réception. Sinon, envoyez un courriel à la liste de diffusion pour demander des volontaires.

Liste de vérification

Voici une liste rapide de vérification récapitulative des tâches ci-dessus :

  • triage CVE, qui comprend :

    • ajouter un paquet à dla-needed.txt ou marquer comme fixed/postponed/ignored/not-affected/end-of-life/unimportant/...

    • signaler les bogues (unfixed dans unstable) dans le système de suivi de bogues (BTS)
    • contacter les responsables de paquet
  • suivre des demandes de parrainage
  • répondre aux questions sans réponse sur la liste de diffusion
  • passer en revue les paquets déclarés sans activité (à moins que le coordinateur LTS (Lynoure) ait déjà fait sa demande hebdomadaire semi-automatique)
  • s'assurer que pour les 4 prochaines semaines, les fonctions de guichet sont attribuées

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é (Exemple1, exemple2).

  • 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.

  • Vérifier/Mettre à jour/Fusionner security-support-ended.debX dans src:debian-security-support
  • Reférencer les proposed-updates en attente dans data/dla-needed.txt pour éviter les conflits.

Travaux d'entretien

Il y a plusieurs tâches où le travail de l'équipe LTS se base sur celui de l'équipe en charge de la sécurité et où l'équipe LTS peut aider cette dernière - spécialement lorsque il n'y a pas de problèmes ouverts dans dla-needed.txt. Ceci conduira à plus de paquets à corriger :

  • facile : ajoutez des références de bogues pour les problèmes non corrigés dans unstable. Vérifiez les problèmes non déclarés dans unstable, re-vérifiez-les et remplissez un rapport de bogue s'il n'est pas déjà présent. Avec cela, on s'assure de ne pas régresser dans unstable avec des bogues corrigés dans stable ou oldstable. Vous pouvez utiliser le script bin/report-vuln pour générer un modèle de rapport qui pourra être édité avec reportbug ou un client de messagerie. Dans le cas où vous n'utilisez pas reportbug pour soumettre par la suite le rapport de bogue, veuillez ajouter X-Debbugs-CC avec team@security.debian.org et secure-testing-team@lists.alioth.debian.org. Cela est fait automatiquement en utilisant reportbug.

  • difficile : vérifiez les éléments à faire à partir de l'outil de suivi. Assurez-vous de marquer les éléments comme « NOT-FOR-US » que lorsque vous êtes sûr que le logiciel n'est en aucune façon contenu dans Debian.

Outils et Astuces


CategoryLts