Ubuntu logo

Packaging Guide

5. Mises à jour de sécurité et de version stable

5.1. Correction d’un bogue de sécurité dans Ubuntu

5.1.1. Introduction

La résolution de bogues de sécurité dans Ubuntu n’est pas vraiment différente de :doc:` la résolution d’un bogue normal dans Ubuntu<./fixing-a-bug>`, et nous présumons que vous êtes familier avec la correction de bogues normaux. Pour montrer où les choses diffèrent, nous mettrons à jour le paquet dbus dans Ubuntu 12.04 LTS (Precise Pangolin) pour une mise à jour de sécurité.

5.1.2. L’obtention de la source

Dans cet exemple, nous savons déjà que nous souhaitons solutionner le paquet dbus dans Ubuntu 12.04 LTS (Precise Pangolin). Ainsi en premier lieu, vous devez déterminer la version du paquet que vous souhaiter télécharger. Nous pouvons utiliser le rmadison pour y parvenir :

$ rmadison dbus | grep precise
dbus | 1.4.18-1ubuntu1   | precise          | source, amd64, armel, armhf, i386, powerpc
dbus | 1.4.18-1ubuntu1.4 | precise-security | source, amd64, armel, armhf, i386, powerpc
dbus | 1.4.18-1ubuntu1.4 | precise-updates  | source, amd64, armel, armhf, i386, powerpc

Typiquement, vous souhaiterez choisir la plus récente des versions pour la corriger qui n’est ni dans -proposed ni dans -backports. Puisque nous sommes en train de mettre à jour le dbus de Precise, vous téléchargerez 1.4.18-1ubuntu1.4 depuis precise-updates :

$ bzr branch ubuntu:precise-updates/dbus

5.1.3. Correction de la source

Maintenant que nous avons le paquet source, nous avons besoin de le réparer pour corriger la vulnérabilité. Vous pouvez utiliser n’importe quelle méthode de réparation appropriée au paquet, y compris les techniques UDD, mais cet exemple va utiliser edit-patch (du paquet ubuntu-dev-tools). edit-patch est le moyen le plus aisé de corriger les paquets et il est essentiellement une surcouche de chaque système de réparation que vous pouvez imaginer.

Pour créer votre correctif en utilisant edit-patch :

$ cd dbus
$ edit-patch 99-fix-a-vulnerability

Cela appliquera les correctifs existants, et placera l’empaquetage dans un répertoire temporaire. Ensuite, éditez les fichiers nécessaires pour corriger la vulnérabilité. Souvent, l’amont a fourni un correctif afin que vous puissiez l’appliquer :

$ patch -p1 < /home/user/dbus-vulnerability.diff

Après avoir effectué les modifications nécessaires, vous appuyez simplement sur Ctrl-D ou tapez exit pour quitter l’environnement temporaire.

5.1.4. Formatage du changelog et des correctifs

Après avoir appliqué vos correctifs vous devrez mettre à jour le changelog. La commande dch est utilisée pour modifier le fichier debian/changelog et edit-patch lancera automatiquement dch après ne pas avoir appliqué tous les correctifs. Si vous n’utilisez pas edit-patch, vous pouvez lancer manuellement dch -i. Contrairement aux correctifs normaux, vous devrez utiliser le format suivant (notez que le nom de distribution utilise precise-security puisqu’il s’agit d’un mise à jour de sécurité pour Precise) pour les mises à jour de sécurité :

dbus (1.4.18-2ubuntu1.5) precise-security; urgency=low

  * SECURITY UPDATE: [DESCRIBE VULNERABILITY HERE]
    - debian/patches/99-fix-a-vulnerability.patch: [DESCRIBE CHANGES HERE]
    - [CVE IDENTIFIER]
    - [LINK TO UPSTREAM BUG OR SECURITY NOTICE]
    - LP: #[BUG NUMBER]
...

Mettez à jour votre correctif pour utiliser les balises de correctifs appropriées. Votre correctif devrait avoir au minimum les balises Origine, Description et Bug-Ubuntu. Par exemple, éditer debian/patches/99-fix-a-vulnerability.patch pour obtenir quelque chose comme :

## Description: [DESCRIBE VULNERABILITY HERE]
## Origin/Author: [COMMIT ID, URL OR EMAIL ADDRESS OF AUTHOR]
## Bug: [UPSTREAM BUG URL]
## Bug-Ubuntu: https://launchpad.net/bugs/[BUG NUMBER]
Index: dbus-1.4.18/dbus/dbus-marshal-validate.c
...

De multiples vulnérabilités peuvent être corrigées dans le même téléchargement de sécurité ; il suffit de s’assurer d’utiliser des correctifs différents pour les différentes vulnérabilités.

5.1.5. Testez et soumettez votre travail

À ce stade, le processus est le même que pour corriger un bogue normal dans Ubuntu. Plus précisément, vous devrez :

  1. Créer votre paquet et vérifier qu’il se compile sans erreur et sans aucun avertissement additionnel du compilateur

  2. Mettre à niveau vers la nouvelle version du paquet à partir de la version précédente

  3. Vérifier que le nouveau paquet corrige la vulnérabilité et n’introduit pas de régression

  4. Soumettre votre travail par le biais d’une proposition de fusion sur Launchpad et déposer un rapport de bogue Launchpad en vous assurant tout d’abord de marquer le bogue comme étant un bogue de sécurité et ensuite de vous inscrire à ubuntu-security-sponsors

Si le problème de sécurité n’est pas encore public alors ne déposez pas une proposition de fusion mais assurez-vous de marquer le bogue comme privé.

Le bogue déposé doit inclure un cas de test, c’est à dire un commentaire qui explique clairement comment recréer le bogue en exécutant l’ancienne version, puis comment s’assurer que le bogue n’existe plus dans la nouvelle version.

Le rapport de bogue doit également confirmer que le problème est corrigé dans les versions Ubuntu ultérieures à celle proposée à la correction (dans l’exemple ci-dessus, plus récentes que Précise). Si le problème n’est pas corrigé dans les nouvelles versions, vous devrez préparer les mises à jour pour ces versions également.

5.2. Mises à jour vers Version Stable

Nous permettons aussi les mises à jour de versions où un paquet bogué a un lourd impact, comme une régression sévère depuis une version antérieure, ou un bogue qui cause des pertes de données. En raison de la capacité de telles mises à jour à introduire elles-mêmes des bogues, nous ne les autorisons que lorsque les modifications peuvent être facilement comprises et vérifiées.

Le processus des Mises à jour de version stable est exactement le même que celui des bogues de sécurité, hormis que vous devez vous inscrire à ubuntu-sru pour le bogue.

La mise à jour ira dans l’archive proposed (par exemple precise-proposed) où il sera vérifié qu’elle corrige le problème et n’introduit pas de nouveaux problèmes. Après une semaine sans problème rapporté, elle peut être déplacée vers updates.

See the Stable Release Updates wiki page for more information.