Oui, certes, et je ne le conteste pas une seconde, maintenir un paquetage pour une distribution majeure n'est pas une sinécure. Loin de là. Faire entrer le paquetage dans le moule, satisfaire les dépendances, mettre à jour, etc. C'est du boulot. Certes, certains développeurs ne sont pas spécialement réactifs. On pourrait en avoir autant au service de certains mainteneurs cependant... Et je ne parle même pas des problèmes de licences particulièrement chers aux équipes Debian. À tort ou à raison, c'est un autre débat. C'est comme ça, on fait avec ou on passe à Ubuntu. Bref, ce que je veux dire, c'est que cette tâche est assez difficile et ingrate comme cela pour ne pas la surcharger en plus avec la gestion des bugs des logiciels eux-mêmes. C'est d'ailleurs la politique de la plupart des grosses distributions.

Le fond de l'affaire ici tiendrait apparemment à une variable non initialisée, servant apparemment[1] à ajouter de l'entropie. Sauf que cette dernière fait couiner Valgrind sur tout programme utilisant de près ou de loin le générateur de nombres aléatoires d'OpenSSL. Du coup, Valgrind qui se plaint, c'est pas propre, on regarde, on trouve le truc, on patche d'abord et, enfin, on upload dans l'unstable. Roh, le méchant mainteneur Debian qui a patché sans prévenir personne ! Il n'en fallait pas plus pour que la horde sorte le goudron et les plumes...

Sauf qu'en fait, il se trouve qu'il a demandé sur la liste openssl-dev ce que les gens en pensaient. Et les réponses sont tout ce qu'on veut sauf négatives. Globalement, c'est même plutôt OK, de la part de membres de l'équipe de développement. On est donc loin des gens qui se marrent un bon coup et le descendent en flamme mentionnés par Ben Laurie. Ah oui, mais sauf qu'il parait que openssl-dev, la Developers list for the OpenSSL Project, n'est en fait pas la liste des développeurs OpenSSL, mais la liste des gens qui développent des logiciels basés sur OpenSSL[2]. La liste des développeurs, ça serait openssl-team. Gni ? Si on va sur la page Support de OpenSSL, on peut trouver les listes de diffusion officielles :

  • openssl-announce : Official Project Announcements ;
  • openssl-cvs : CVS Repository Messages ;
  • openssl-dev : Discussions on development of the OpenSSL library. Not for application development questions!
  • openssl-users : Application Development, OpenSSL Usage, Installation Problems, etc.

Aucune mention d'une quelconque liste openssl-team[3] d'une part, et surtout la mention très claire que openssl-dev est dédiée au développement de OpenSSL et pas au développement d'applications s'appuyant sur OpenSSL. Dans la FAQ, on peut également lire :

3. How can I contact the OpenSSL developers?
The README file describes how to submit bug reports and
patches to OpenSSL. Information on the OpenSSL mailing lists
is available from http://www.openssl.org.

Comme les listes de diffusion indiquent openssl-dev, peut-être le README est-il différent ? Et bien non :

HOW TO CONTRIBUTE TO OpenSSL

Development is coordinated on the openssl-dev mailing list
(see http://www.openssl.org for information on subscribing).
If you would like to submit a patch, send it to
openssl-dev@openssl.org with the string "[PATCH]" in the
subject. Please be sure to include a textual explanation of
what your patch does.

Autant dire que l'argumentaire lapidaire du "vous ne nous avez pas prévenus'' en prend un sacré coup dans les roublignoles.

Donc, si on résume. Debian veut corriger ce qui semble être un bug et le fait. Debian contacte les développeurs OpenSSL, obtient des réponses plutôt positives et continue sur sa lancée. Malheureusement, aucun patch n'est soumis et la modification n'est pas incluse upstream. Bref, et malgré toute l'agitation qui règne autour de cette histoire, on a bien un problème de part et d'autre. Debian qui forke OpenSSL dans une version spécifique, et OpenSSL qui évalue mal les modifications proposées par un mainteneur de paquetage. Mais dans le monde merveilleux du logiciel libre, entre les mainteneurs et les développeurs qui n'en font chacuns qu'à leur tête, il ne reste souvent que les utilisateurs pour assister impuissants aux duels de mauvaise foi.

Mais plus important je pense, cette histoire soulève la question majeure du rôle des mainteneurs de paquetage, et surtout de leur relation avec les développeurs de logiciels. Je ne veux pas polémiquer ici sur les torts de chacun, mais il y a clairement des efforts à faire[4] de part et d'autre pour sensiblement améliorer la situation et faire en sorte que ce genre de boulette(s) ne se reproduise plus. Certaines équipes travaillent ensembles par exemple. Certains développeurs examinent les bugs remontés, voire les modifications faites dans certaines distributions majeures. Mais la vraie question de fond, c'est de savoir si un mainteneur peut, ou non, se permettre de d'inclure dans sa distribution des patches qui ne sont pas dans le code upstream. Je pense que ce ne devrait pas être le cas. Savoir si c'est un bien ou un mal pour l'utilisateur final est une autre question qui ne fait que compliquer la question et in fine augmenter le risque de couacs grossiers comme celui-ci. Parce que malheureusement, la réalité est loin d'être aussi simple. La différence entre la théorie et la pratique... Aussi, autant pouvoir se raccrocher à quelques règles simples pour sauver la situation. Comme par exemple ne pas forker le code upstream. Ce qui n'empêche nullement le mainteneur de contribuer en envoyant des patches. Juste de les inclure avant qu'ils soient inclus upstream.

Car quand il s'agit de sécurité, et tout spécialement de crypto, il est très difficile de comprendre toutes les implications des modifications qu'on introduit. Comme le dit un des commentaires au billet de Ben Laurie, certes on ne devrait pas toucher ce qu'on ne comprend pas, mais il arrive souvent qu'on ne comprenne pas qu'on ne comprend pas. C'est que j'essaye modestement de démontrer aux étudiants que j'ai en cours en leur demandant s'ils voient des failles dans WEP juste après leur avoir décrit son fonctionnement. À de très rares exceptions, j'ai droit à un silence total, ce qui me permet de leur expliquer qu'on ne s'improvise pas cryptographe et que vouloir toucher à ce genre de choses demande certes de fortes compétences, mais aussi d'énormément d'expérience.


Ceci étant, tout béotien que je suis en crypto, je me pose tout de même une question. Une vraie question parce que je n'ai pas regardé très loin. Utiliser de la mémoire non initialisée pour ajouter de l'entropie n'est-il pas pour le moins... original ? De prime abord, il ne me semble pas qu'il s'agisse d'une source d'entropie très fiable, en ce qu'on va y trouver essentiellement des zéros. Non ? Et plus largement, il sert à quoi /dev/random ?...

Mais de que ce qu'il a pu en déduire des sources, mon petit doigt me dit que ça n'est pas aussi simple que ça. En fait, c'est clairement beaucoup plus compliqué. Que la vérité est ailleurs en quelque sorte...

Notes

[1] Encore une fois...

[2] Mais alors quid de openssl-users ?

[3] Nulle part ailleurs, d'ailleurs...

[4] À consentir ?