Du côté de mes contributions au logiciel libre, l’année 2009 commence assez fort. Il semble que j’ai réussi à déclencher une petite révolution.
Le système de test de NuFW avait mis en évidence un crash rare, non reproductible facilement dans nuauth, le serveur d’authentification de NuFW. Les sorties de gdb ou valgrind révélaient un problème absurde dans la bibliothèque cyrus-sasl. NuFW l’utilise pour réaliser la phase d’authentification des utilisateurs. Le crash apparaissait lors d’un appel à sasl_dispose() qui est la fonction à appeler lorsque l’on a terminé la phase d’authentification. Après maintes vérifications et plusieurs dizaines d’heures de debug, j’étais convaincu que nuauth, le serveur d’authentification de NuFW, utilisait la bibliothèque de manière correcte et que le code environnant était correct.
Lorsque l’utilisation d’une bibliothèque est légitime et que l’on obtient un plantage, c’est que l’on a trouvé un bug. J’ai donc alors commencé à enquêter sur Cyrus-sasl. Cette bibliothèque est développée dans le cadre du projet cyrus (serveur de mail imap) par la Carnegie Mellon University. Elle est utilisée par un nombre conséquent de logiciels libres fameux (dont openldap, sendmail). Même si sendmail a une réputation sulfureuse de sécurité, il est connu pour sa stabilité. Et donc, en me lançant dans le debug de ce problème début septembre 2008, je savais que je m’attaquais à quelque chose de robuste car très utilisé. Le bug allait donc être complexe à trouver.
J’enchainais alors des séances de deboguage plus ou moins longues passant à certain moment plusieurs longues journées de travail (lire 14 ou 15 heures) sur ce problème. Je sortais tout de même victorieux de la confrontation et le 20 septembre 2008, j’envoyais un message à la liste de diffusion cyrus-sasl : [PATCH] Fix problem with sasl_set_mutex
NuFW utilise les bibliothèques cyrus-sasl et libldap_r et libldap_r utilise lui aussi cyrus-sasl. Elle s’en sert lors de la phase d’authentification sur la base LDAP. Comme, et libldap_r et NuFW sont multithreadés ou multithreadable, ils initient tous les deux la bibliothèque cyrus-sasl pour le support des threads. Il y a notamment un appel à sasl_set_mutex() qui définit l’implémentation de mutex à utiliser. NuFW appelle cette fonction avec ses propres paramètres et libldap_r fait de même (même lorsque l’on fait un bind simple, les connaisseurs apprécieront). Or sasl_set_mutex() ne détectait pas qu’une initilisation avait déjà été faite. On avait donc un conflit possible. Les fonctions de mutex sasl prennent des paramètres void* en entrée et travaille sur ces pointeurs. Il y donc potentiellement des casts dangereux.
Dans le cas de NuFW, le problème était beaucoup plus radical. L’initialisation de libldap_r se fait lors du chargement du module ldap de nuauth. Par conséquent, c’est la fonction ldap qui est utilisée après chargement du module. Or, nuauth peut changer de configuration et donc de modules à chaud. Il réalise notamment un déchargement des modules. Or, cela ne met pas à jour la fonction mutex de sasl qui appelle donc une fonction déchargée. Ceci conduit immanquablement au crash. Cette fonctionnalité de modification de configuration à chaud est massivement utilisé dans le système de tests de NuFW et c’est donc pour cette raison que le crash ne se produisait qu’à cet endroit.
J’aurais du déboguer plus rapidement ce problème. La piste que j’aurais du voir plus tôt était l’utilisation de fonctions stockées à des emplacements mémoires non valides. Cette information était donnée par gdb et j’aurais du lui faire d’avantage confiance.
Ma remontée de bug et mon patch ont rapidement été pris au sérieux et un patch implémentant mon idée a été commité dans les sources : Fixed sasl_set_mutex() to disallow changing mutex management functions once sasl_server_init/sasl_client_init is called
J’étais content de voir ce correctif appliqué, mais vu la criticité pour NuFW, j’aurais été satisfait de voir arriver une nouvelle version de cyrus-sasl fixant ce bug. Le problème étant déclenché par une utilisation précise de la bibliothèque, je n’étais pas en droit de remonter mon exigence. De plus, la dernière version de cyrus-sasl date du 19 mai 2006 et je me doutais donc que je n’allais pas être entendu.
Début janvier, un mail envoyé sur la liste a pointé le fait que le bug était reproductible en utilisant le stockage des mots de passe sasl dans ldap : En utilisant lui aussi la bibliothèque libldap_r cyrus-sasl se mordait la queue. Le bug était donc aussi interne à cyrus-sasl. Fort de cette conclusion, j’envoyais une réponse au message signalant le problème :
This made the bug self contained and not dependant of other applications. Given the fact that the effect of this bug is a crash of the calling program, it could be interesting to release a new version of the sasl library. (my 0.02$)
J’avais ainsi osé demandé une nouvelle version sur un logiciel où je n’avais pas écrit une ligne de code. À ma surprise, cela s’est conclu par ce message : Next release of CMU SASL – call for favorite bugfixes où un membre de l’équipe de développement annonce l’arrivée probable, aux alentours du 15 février, d’une nouvelle version de la bibliothèque et demande quels sont les corrections de bugs que les utilisateurs voudraient voir figurer dans cette version.
Je commence donc l’année 2009, en réussissant à déclencher la sortie d’une nouvelle version d’une bibliothèque qui n’avait pas eu de nouvelles versions depuis près de trois ans !
Je conclus ce poste en plagiant pollux et en revoyant mes objectifs de contributions à la hausse pour l’an prochain :
En 2010, je déclenche une sortie de Debian.
