 |
|
| |
 |
Damien Miller
Développeur
Projet OpenBSD |
|
Damien Miller (OpenBSD)
"Les lois européennes en faveur du reverse-engineering se montrent très utiles"
Popularité, défis, sécurité du code, financement : développeur OpenBSD et OpenSSH, Damien Miller répond aux questions qui entourent ces deux fameux projets Open Source.
19/04/2006 |
| |
 |
|
JDN
Développeurs. Comment êtes-vous entré dans la communauté Open Source ?
Damien Miller. En 1999, quand OpenBSD a annoncé le projet OpenSSH, j'ai immédiatement vu qu'il serait utile, donc j'ai lancé le projet Portable OpenSSH, pour rendre OpenSSH disponible sur les plates-formes autres qu'OpenBSD... sans demander la permission de mon patron.
J'ai depuis travaillé de plus en plus sur le cœur d'OpenSSH, et diverses parties d'OpenBSD.
OpenSSH est aujourd'hui plus ou moins un standard de la sécurité système. Comment expliquez-vous un tel succès pour un projet Open Source ?
Nous ne sommes pas la seule implémentation SSH gratuite disponible, et même pas la première. Je pense qu'OpenSSH est la plus populaire parce qu'elle offre une migration facile depuis les outils SSH hérités, et que nous avons prouvé que nous étions dignes de confiance.
|
|
 Nous n'avons jamais cherché à implémenter des fonctionnalités avant les autres" |
|
Dès que nous avions des bugs de sécurité, nous avons ainsi attiré l'attention sur eux lors de nos annonces de nouvelle version. Nous avons également appris à avoir une approche défensive, qui se retrouve dans les audits continus que nous réalisons.
Nous savons par ailleurs résister à la tentation d'implémenter trop vite de nouvelles fonctionnalités. Nous n'avons jamais cherché à implémenter des fonctionnalités avant les autres.
Quels sont les principaux défis de la maintenance et du développement d'un système d'authentification multiplates-formes ?
Il y deux défis majeurs auxquels fait face le projet Portable OpenSSH. Tout d'abord, le fait que presque tous les éditeurs abordent les choses de manière légèrement différente. C'est ennuyeux, car nous devons prendre en compte les myriades de différences idiotes qui ont été implémentées.
Le second problème, c'est le standard d'authentification le plus populaire, PAM (pluggable authentication modules), très brouillon et mal conçu pour les applications modernes comme OpenSSH. De fait, nous recommandons à nos utilisateurs de ne l'utiliser qu'en dernier recours.
En tant que système Open Source, comment faites-vous pour éviter que les hackers se servent de votre code pour le contourner plus facilement ?
Quand nous écrivons du code, nous tentons de suivre les bons principes de conception. Plutôt que de vous les répéter, je vous renvoie vers l'excellent article de Saltzer et Schroeder, "The Protection of Infomation in Computer Systems", écrit il y a trente ans, et toujours considéré comme le meilleur et le plus concis des jeux de principes de conception en matière de sécurité.
Ces principes de conception et notre approche proactive sont appliqués non seulement au code que nous écrivons, mais également à nos vérifications des patches des autres développeurs. Voir notre code lu et approuvé par au moins un autre développeur nous protège des erreurs humaines.
|
|
Le développement de OpenSSH et OpenBSD sont plus ou moins inséparables" |
|
Quels sont les outils, langages et méthodes de développement que vous utilisez régulièrement ?
OpenBSD est quasiment entièrement écrit en langage C, donc c'est avec lui que je passe le plus clair de mon temps. Si je dois réaliser un prototype, ou si j'ai besoin rapidement d'un outil, je le fais généralement en Python, en Perl, ou avec un script shell.
OpenSSH et OpenBSD sont plus ou moins inséparables, les deux projets utilisent les mêmes méthodes de développement, basé sur les incréments et l'arbitrage des pairs.
Par "incréments", je veux dire que les modifications énormes et les réécritures massives sont généralement écartées en faveur de plus petits changements, plus faciles à vérifier, tester et corriger si besoin est. Les changements majeurs doivent être vraiment justifiés.
L'arbitrage des pairs tient essentiellement à obtenir une validation de la part des développeurs pour une modification.
En quoi une équipe de développeurs Open Source peut-elle être fiable face à une problématique aussi complexe que la cryptographie ?
OpenSSH ne tient pas de la recherche en cryptographie. Nous utilisons des fondations éprouvées et bien comprises en la matière. Le plus gros du code de cryptage provient de la bibliothèque libcrypto dont dépend OpenSSH. Dans les cas où une question de cryptologie survient, nous utilisons l'expérience de l'un des cryptographes que nous connaissons.
Votre projet est-il ouvert aux idées et patches de développeurs tiers ?
Oui, nous acceptons les patches de la communauté, et certaines personnes ont eu un impact inestimable dans l'identification et la correction des bugs d'OpenSSH. Nous acceptons avec plus de réticence les grosses modifications qui ajoutent de nouvelles fonctionnalités.
|
|
Nous refusons clairement le code binaire opaque" |
|
OpenBSD est lui-même un système très sécurisé, la dernière version mettant en avant son refus des "blobs", ces pilotes propriétaires. Comment remplacez-vous ces éléments opaques de manière ouverte et légale ?
Nous refusons clairement le code binaire opaque. En leur absence, nous avons les options suivantes : ne pas reconnaître le matériel en question, ou créer un pilote non-blob, par le biais de reverse-engineering que nous réalisons dans un pays où cela est légal. Les lois européennes en faveur du reverse-engineering dans le cadre de compatibilité se montrent ici très utiles.
Prendre le parti de ne pas reconnaître le matériel sans pilote ouvert n'est pas une décision populaire. Mais honnêtement, on ne peut faire un système sécurisé si on accepte des morceaux de codes inconnus dans le programme.
OpenSSH est un résultat direct des travaux du projet OpenBSD. Vu les récent problèmes financiers de ce dernier, quel peut être l'impact de l'absence de fonds sur le développement d'OpenSSH ?
Sans source financière, le développement ralentit considérablement. Cela n'affecte pas la correction de bugs ou l'addition de petites fonctionnalités, mais les prévisions de gros travaux, qui requièrent l'attention soutenue d'un ou plusieurs développeurs, sont affectées. Ces gros travaux se font soit en payant l'un des développeurs à plein temps, soit en organisant un hackathon.
Lors d'un hackathon, un groupe de développeur se retrouve dans une même pièce avec accès réseau, et travaille seulement sur OpenBSD pendant une semaine. Les développeurs étant éparpillés au travers du globe sont alors réunis, et les améliorations se font beaucoup plus rapidement. |
| |
Propos recueillis par Xavier Borderie, JDN Développeurs |
|
|
PARCOURS
|
|
 |
| |
Damien Miller, 33 ans, est consultant en sécurité chez Sensis (Australie).
2005 Sensis, security consultant
2003 Netstar Networks, consultant
sécurité
2002 Fortress Networks, développeur
lead
2000 IOCom, développeur
1998 Internet Business Solutions, développeur
|
|
|
|
|
|
|
Dossier 
