From Mageia wiki
Jump to: navigation, search


Drakconf multiflag.png
Autres langues
Deutsch ; English ; Français ;

Aperçu général

Il s’agit d’une première étape pour formaliser une politique de mise à jour de la distribution publiée. Les choses ne sont pas gravées dans le marbre, mais nous avons besoin d’une stratégie pour aller de l’avant avec la publication des mises à jour pour Mga-current, et nous pouvons affiner le processus au fur et à mesure que nous trouvons des enjeux ou des lacunes. À mon avis, il y a au moins deux caractéristiques de la distribution que nous voulons « éviter absolument » :

  • Mageia tarde à corriger les bogues et les mises à jour de version
  • Mageia publie régulièrement des mises à jour non testées qui cassent des choses

Bien que nous sachions tous que « des choses arrivent » et que de mauvaises mises à jour occasionnelles sortent, nous devons tous faire preuve de diligence raisonnable pour publier des mises à jour opportunes et entièrement conformes à l’Assurance Qualité.

Finalité

Une mise à jour doit être émise soit pour corriger un défaut dans une application ou un paquet (bogue), soit pour corriger une vulnérabilité de sécurité. Ref: Bug Policy

Stratégie en matière de création de version

Pour la plupart, une mise à jour devrait être constituée de correctifs de la même version du paquet publié avec la distribution, à quelques exceptions près :

  • Correction d’un bogue uniquement. Il ne sert à rien d’envoyer toutes les corrections sous forme de correctifs si la nouvelle version ne contient aucune nouvelle fonctionnalité.
  • Les versions de logiciels qui ne sont plus supportées en amont avec les mises à jour (Firefox et Thunderbird semblent actuellement faire partie de cette catégorie).
  • Logiciel qui est lié à la version d’un service en ligne (jeux, antivirus ?) et qui fonctionne uniquement avec la version la plus récente.
  • Nous ferons des exceptions pour les paquets qui ne sont pas entrés dans Mga-current et qui sont des ajouts à la distribution, à condition qu’ils n’aient pas d’impact sur les autres paquets et qu’ils puissent passer l’Assurance Qualité dans leur intégralité.

Les dépôts Updates sont inappropriés pour satisfaire les envies de certains utilisateurs en matière de « nouveautés ». À la place, il y a les dépôts Backports pour inclure ces paquets.

Roles

Plusieurs groupes sont impliqués dans la création, le test et la publication des mises à jour :

Communauté (toute personne)

Remarque :
Plus nous sommes exhaustifs dans ce qui suit, plus nous pouvons publier des mises à jour à temps.
  • Identifiez le problème.
  • Signalez les bogues
  • Trouvez les correctifs et les joindre au bogue
  • identifiez les entrées pertinentes dans d’autres bases de données de bogues, bases de données sur les problèmes de sécurité
  • Joignez le POC (démonstration de faisabilité). Soyez capable de reproduite le bogue pour démontrer la vulnérabilité et l’attacher au bogue.
  • Testez et commentez au fur et à mesure que les paquets mis à jour apparaissent dans les dépôts Testing.

Équipe de triage des bogues

  • Vérifier le caractère exhaustif des bogues.
  • Demander des informations supplémentaires si cela s’avère nécessaire
  • Assigner le bogue au mainteneur

Mainteneur (ou tout empaqueteur intéressé)

  • Construire un paquet mis à jour avec des correctifs (si le bogue ne vous est pas déjà attribué, assignez ce dernier à votre nom, pour que les autres personnes sachent que vous êtes en train de le traiter.)
    • Si la version n’a pas changé, laissez mkrel tel quelle et '%define subrel 1'
    • S’il s’agit d’une mise à jour vers une nouvelle version : utilisez '%mkrel 1' sans subrel

IMPORTANT : subrel doit être défini ci-dessus/avant mkrel pour travailler

  • Effectuez au moins quelques contrôles de qualité initiaux pour vérifier que l’application/la correction fonctionne, pour une mise à jour de sécurité, un lien vers l’annonce de sécurité en amont ou le CVE correspondant doit être fourni, également une démonstration de faisabilité (POC aussi connu sous le nom d’exploit) doit être fournie si elle est disponible pour vérifier si la mise à jour corrige le problème de sécurité de manière reproductible.
  • Soumettre le paquet à updates testing. Consultez la page mgarepo pour connaître la procédure à suivre pour soumettre le paquet.
  • Rédiger l’avis de mise à jour dans le rapport de bogue utilisé pour valider cette mise à jour (Example update advisory announcement)
  • Réaffecter le bogue à qa-bugs@ml.mageia.org (ajoutez un commentaire dans le bogue avec la version/release du paquet au moment de la réaffectation, devrait déjà figurer dans l’avis ou l’annonce en question). Si la mise à jour corrige plusieurs bogues, réassignez un seul d’entre eux.
  • Liste TOUS les SRPMS nécessaires à la mise à jour (voir pourquoi dans le rapport de bogue 3949) et aussi tous les RPMs pour l’assurance qualité qui a besoin de savoir ce qu’il faut tester.

Équipe assurance qualité (Comment vérifier et valider une mise à jour)

  • Tester que le ou les paquet(s) s'installeront sur toutes les architectures prises en charge
  • S'assurer que le ou les paquets peuvent être mis à jour à partir de la ou des version(s) précédente(s)
  • S'assurer que le point spécifique a été résolu et que l'application fonctionne toujours comme prévu.
  • Pour une vulnérabilité de sécurité, si un POC est disponible et dans les limites des compétences de l'AssuranceQualité pour le test, tester que la nouvelle version est immunisée contre la vulnérabilité (L'AssuranceQualité peut s'en remettre au mainteneur ou à l'équipe de sécurité pour obtenir des conseils ou de l'aide.)
  • Si un paquet ne passe pas le contrôle d'assurance qualité, reprenez le bogue avec des commentaires et répétez le cycle fix/paquet/test jusqu'à ce que nous obtenions les résultats souhaités.

Équipe de sécurité

  • Surveiller les listes de diffusion et les autres sources d’information sur la sécurité pour les questions touchant les versions prises en charge, ainsi que pour Cauldron.
  • Ouvrez un rapport de bogue ou avertissez le mainteneur du paquet du problème (comme toujours, une entrée dans Bugzilla est quelque chose de concret sur lequel les développeurs peuvent travailler et garantit que « rien ne passera entre les mailles du filet »)
  • Établisser un POC (démonstration de faisabilité) si nécessaire/possible pour tester si le correctif mis à jour est immunisé contre le problème.
  • Travaillez avec le responsable des paquets et l’Assurance Qualité pour chaque problème de sécurité afin de vérifier le comportement des correctifs et de l’application.
  • Participer à des listes de sécurité fermées en coopération avec les fournisseurs et s’assurer que nous respectons les accords d’embargo. Maintenir une présence telle que nous devenions un membre de confiance de la communauté de la sécurité.

Équipe administrateurs système

  • Déplacer le paquet de updates_testing vers updates, au moyen d’un script
  • Envoyer un courriel sur la liste (au moyen d’un script)
  • FIXME publie les annonces de mise à jour sur les pages web
  • FIXME délègue cette tâche à quelqu’un d’autre (bonne configuration de sudo, etc.)

Références

Retour vers le Portail de l’équipe AQ