Mon rapport mensuel couvre une grande partie de mes contributions au logiciel libre. Je l’écris pour mes donateurs (merci à eux !) mais aussi pour la communauté Debian au sens large parce que cela peut donner des idées aux nouveaux venus et que c’est également un des moyens les plus effectifs de trouver des volontaires pour travailler sur les projets qui me tiennent à cœur.

Debian LTS

Ce mois-ci ce sont 12 heures de travail sur Debian LTS qui ont été subventionnées. Voici le résumé des tâches qui m’ont occupé :

• Tri de vulnérabilités CVE. J’ai poussé 24 commits vers le suiveur de sécurité. J’ai passé plus de temps que d’habitude à cette tâche ce mois-ci (cf. ci-dessous);
• J’ai publié la DLA-143-1 concernant python-django (corrigeant 3 vulnérabilités CVE). Alors que j’espérais que la mise à jour soit rapide, mes tests ont révélé que, bien que les patchs fussent bien appliqués en majorité, ils ne fonctionnaient pas comme attendu. J’ai du coup passé 4 heures à rétroporter proprement les correctifs et à effectuer les tests correspondants (afin de m’assurer que les patchs fonctionnaient enfin correctement).

Je souhaite expliciter ici un peu plus avant deux cas auxquels j’ai été confronté dans mon tri des vulnérabilités CVE, et qui ont chacun nécessité pas mal de temps d’investigation. Si la description a posteriori que je vais en faire semble logique, simple et directe, il en a été tout autrement pour en venir à bout, ce qui a impliqué beaucoup d’itérations et de collectes de données que je ne mentionnerai pas ici.

Pour commencer, j’étais en train d’investiguer la vulnérabilité CVE-2012-6685 concernant libnokogiri-ruby, et la discussion du bogue upstream a révélé que libxml2 pouvait également être lié au problème. En utilisant les cas de tests soumis, j’ai confirmé que libxml2 était également affecté par un problème qui lui était propre… puis j’ai commencé à analyser l’historique CVE de libxml2 afin de trouver si un numéro CVE lui avait été affecté. Ce qui était le cas, la n°CVE-2014-0191 (bien que la description n’en souffle mot). Ceci étant, cette vulnérabilité était marquée comme corrigée dans toutes les versions. Comment donc ? Il s’est avéré que le correctif fourni par l’amont pour cette CVE était juste le complément d’un autre commit qui fut intégré beaucoup plus tôt (et qui fut utilisé comme base du commit, comme le montre les copier/coller des commentaires). Lorsque l’équipe de sécurité a intégré ce patch dans Wheezy/Squeeze, ils n’étaient probablement pas au courant que le correctif complet requérait également l’inclusion d’autre chose. En conséquence, j’ai réouvert la vulnérabilité CVE-2014-0191 sur notre suiveur (le commit correspondant).

Le second cas problématique fut pound. Thijs Kinkhorst a ajouté des données relatives à pound en relation avec de nombreux soucis SSL. Ce qui fit apparaître pound sur ma liste des nouveaux paquets vulnérables dans Squeeze, car la vulnérabilité CVE-2009-3555 était marquée comme corrigée dans la version 2.6-2, tandis que Squeeze ne dispose que de la version 2.5-1. Il n’y avait aucune référence à un bogue dans le suiveur de sécurité et l’historique des modifications Debian pour cette version ne mentionnait qu’un « patch anti_beast », qui est encore une autre vulnérabilité (CVE-2011-3389). Je devais creuser encore un peu plus profondément…et je découvris in fine que le patch précédent avait également à voir avec la CVE qui m’intéressait. Mais Brian May avait récemment remonté dans le bogue n°765649 que ce paquet était toujours vulnérable à cette faille ! J’ai essayé de comprendre où ce patch était déficient et j’ai remonté mes trouvailles dans le ticket. J’ai mis à jour les données du suiveur avec mes connaissances nouvellement acquises (commit 31751 et 31752).

Tryton

En ce qui me concerne, janvier est toujours le mois où j’essaye de clôturer les comptes de Freexian. Cette année ne fait pas exception à la règle, bien que ce soit la première fois où j’accomplis cette tâche avec Tryton. J’ai en premier lieu mis à niveau vers la version 3.4 afin de profiter de la dernière version de Tryton.

Malgré cela, j’ai découvert de multiples problèmes lors de la clôture…et comme je ne veux pas être confronté aux mêmes problèmes l’année prochaine, je les ai remontés et ai préparé des correctifs pour ceux concernant le plan comptable français :

• n°4464: l’export CSV des vues hiérarchiques est inutilisable;
• n°4466: ajout des propriétés de report manquantes des comptes;
• n°4468: suppression de propriétés abusives de réconciliation sur certains comptes;
• n°4469: conversion du compte 6354 en un vrai compte;
• n°4479: la balance des comptes non reportables ne marche pas avec certains comptes parents.

Saltstack

J’ai mentionné cette idée le mois dernier : mettre en place et maintenir de nombreux chroots sbuild peut être fastidieux, et j’ai donc souhaité l’automatiser le plus possible. A cette fin, j’ai créé trois formules Salt et les ai fait ajouter au dépôt officiel Saltstack :

• debootstrap-formula;
• schroot-formula;
• sbuild-formula.

Chacune est construite par-dessus la précédente. debootstrap-formula crée des chroots avec debootstrap ou cdebootstrap. schroot-formula fait la même chose et enregistre ces chroots dans schroot. sbuild-formula fait la même chose que schroot-formula mais avec différents paramètres par défaut qui sont plus adaptés aux chroots sbuild (et bien entendu contrôle que sbuild est installé et que les chroots générés sont des chroots buildd).

Avec la formule sbuild je peux ajouter ceci aux données pilier :

sbuild:
  chroots:
    wheezy:
      architectures: [amd64, i386]
      extra_dists:
        - wheezy-backports
        - wheezy-security
      extra_aliases:
        - wheezy-backports
        - stable-security
        - wheezy-security
    jessie:
    [...]

Et ensuite un simple salt-call state.highstate (je fonctionne en mode standalone) permettra de contrôler que tous les chroots sont correctement paramétrés.

Empaquetage divers

J’ai empaqueté de nouvelles versions amont de Python dans experimental et ouvert une requête de pré-approbation afin d’avoir la dernière 1.7.x dans Jessie (n°775892). Il semble que cela soit un choix cornélien pour l’équipe en charge de la publication, ce qui est bien dommage : nous avons des développeurs Debian actifs, des développeurs amont actifs, et chacun est parfaitement au courant de la règle « pas de nouvelles fonctionnalités » afin d’éviter les régressions. Que risque-t-on ?

J’ai également créé une requête de déblocage pour Dolibarr (à la demande de l’équipe de sécurité qui souhaite voir le correctif CVE atteindre Jessie). J’ai contribué modestement à deux bogues qui étaient d’un intérêt particulier pour certains de mes donateurs (n°751339 et n°774811). Ils n’étaient pas sous ma responsabilité, mais j’ai essayé de les faire avancer en contactant les bonnes personnes.

J’ai préparé un patch de sécurité pour Django dans Wheezy (python-django_1.4.5-1+deb7u9) et l’ai envoyé à l’équipe chargée de la sécurité. En faisant cela j’ai découvert un petit problème dans leur patch rétroporté que j’ai remonté à l’amont dans le ticket Django n°24239.

Debian France

Avec la nouvelle année vient le temps d’organiser l’assemblée générale avec le renouvellement d’un tiers de son Bureau. Nous avons donc appelé les membres à candidater et j’ai été heureux de voir que nous avons 6 candidatures pour 3 sièges. C’est un signe positif, montrant que nous avons assez de personnes impliquées dans l’association. L’une d’entre elle évoque même une Debconf 17 en France… de grands projets !

De mon côté, j’ai annoncé que je ne concourrai pas pour le poste de président l’année prochaine. Ceci étant, je resterai au Bureau afin d’assurer une transition en douceur.

Merci

Rendez-vous au mois prochain pour un nouveau résumé de mes activités !

Ceci est une traduction de mon article My Free Software Activities for January 2015; contribuée par Weierstrass01.