Sérieusement remis en cause à la suite du branle-bas de combat causé par la faille Heartbleed qui l'a affecté en avril dernier, le projet OpenSSL prépare différentes modifications pour renforcer la fiabilité de ses fonctions de sécurité. L'équipe qui le suit vient de faire un point sur les problèmes identifiés et ce qu'elle compte faire pour y remédier. Les dates de réalisation indiquées constituent autant d'objectifs à atteindre qui vont primer sur la mise à disposition de nouvelles fonctionnalités. L'équipe précise que cette feuille de route sera régulièrement mise à jour. Â
La bibliothèque OpenSSL, qui chiffre les communications entre un ordinateur et un serveur en utilisant SSL/TLS (Secure Sockets Layer/Transport Layer Security), doit apporter la garantie que les données transitant lors de transactions e-commerce, d'échanges e-mail, etc. ne pourront pas être lues si elles sont interceptées. Après avoir découvert que la faille Heartbleed remontait en fait à deux ans, le projet Open Source s'est retrouvé sous le feu des critiques. Il est notamment apparu que ce projet Open Source disposait en fait de peu de moyens et peu de ressources en dépit du fait qu'il était exploité par des millions d'ordinateurs dans le monde. A la suite de quoi une dizaine de grands noms de l'informatique ont décidé de soutenir financièrement le projet en engageant la Core Infrastructure Initiative.
Un code insuffisamment contrôlé
Parmi les problèmes identifiés, la feuille de route que vient de publier le projet reconnaît clairement un contrôle insuffisant sur le code, ce dernier manquant par ailleurs de cohérence, une documentation également insuffisante, une absence de stratégie du côté plateforme et sur le cycle de mise à jour. Le groupe prévoit aussi de prendre en compte un plus grand nombre de problèmes soulevés dans le système de suivi de bugs, certains de ceux-ci n'ayant jamais été explorés.
La frustration causée par les manques d'OpenSSL a entraîné la création d'un fork, dénommé LibreSSL, qui a corrigé des bugs et réécrit des parties du code posant problème. Ces derniers jours, Google a lui-même annoncé qu'il développait son propre fork du logiciel, présenté sous le nom de BoringSSL, en le décrivant comme plus approprié à ses propres projets. Le groupe californien prévoit aussi d'enlever les API et ABI (application binary interfaces) qu'il juge inutile dans OpenSSL. Il a prévu de partager avec LibreSSL et avec le projet d'origine les informations sur les bugs qu'il aura trouvés dans la bibliothèque.