> et sur la qualité et la propreté du code ? j'ai souvent entendu dire qu'OpenSSH était très très gruiiik ?
J'ai entendu dire ça ... mais toujours par des developpeurs NetBSD. Quand on connait les rapports conflictuels (c'est peut dire !) des communautés Net et Open, on reste très sceptique sur les propos des afficionados d'un système sur l'autre système. Après je ne suis pas qualifié pour juger de sa qualité malheureusement.
OpenSSH est developpé au coeur d'Open (dans le cvs principal + les ajouts de -portable, mais c'est secondaire). Ce qui signifie qu'il bénéficie d'une politique de developpement solide (très éloignée du "oh, un patch qui marche, hop je le commit"), à savoir les exigences imposés aux devs OpenBSD:
- relecture et validation quasiment systèmatique de tout code par un ou plusieurs autres developpeurs avant commit. Ces developpeurs, avec le temps, sont devenus des spécialistes de l'audit sécurité et de la relecture.
- respect de normes de codage ultra strictes (style(9) mais aussi utilisation de fonctions protégées et banissement des fonctions sensibles comme sprintf/strcpy/strcat/... etc.) sous peine de rejet du commit.
- filtrage sérré des contributeur: seuls ceux qui ont faire leurs preuves, par exemple en trouvant et corrigeant pleins de bugs, en produisant du code très propre ..., sont susceptibles d'être acceptés.
- relecture, grep -r, et modification/protection du code chaque fois qu'une nouveau type générique de faille est découvert, ou par séries thématique (eg, problèmes sur les manips de chaines, sur la gestion des signaux, sur le test des codes de retours de snprintf(3), ...), l'arbre des sources étant régulierement nettoyé de ces "oddities" ou de méthodes de programmations dont on découvre qu'elles étaient imprafaites.
- fonctionnement et tests en environnement protégé (eg. /etc/malloc.conf -> AJFG, propolice etc.) pour detecter rapidement les possibles debordements de mémoire.
- évolution très conservatrice et incrémentale (commits par petits patches, refus des ajouts de fonctionalités trop hardies ...).
- design devant permettre un fonctionnement sécurisé (séparation des privilèges pour les daemons, pas d'IPv6 mappé en IPv4, ...).
Donc il est improbable que le code soit sale ; d'autant que le soft tourne sur un paquet de machines (Linux, *BSD, Cisco et autres unix) depuis longtemps déjà ; les problèmes de sécurité remontent vite dans ces conditions, et ils ont été peut nombreux (on peut imaginer qu'OpenSSH est dans la ligne de mire de la plupart des hackers en herbe, vu son utilité stratégique et sa grande diffusion).
[^] # Re: Sortie d'OpenBSD 3.7
Posté par herodiade . En réponse à la dépêche Sortie d'OpenBSD 3.7. Évalué à 8.
J'ai entendu dire ça ... mais toujours par des developpeurs NetBSD. Quand on connait les rapports conflictuels (c'est peut dire !) des communautés Net et Open, on reste très sceptique sur les propos des afficionados d'un système sur l'autre système. Après je ne suis pas qualifié pour juger de sa qualité malheureusement.
OpenSSH est developpé au coeur d'Open (dans le cvs principal + les ajouts de -portable, mais c'est secondaire). Ce qui signifie qu'il bénéficie d'une politique de developpement solide (très éloignée du "oh, un patch qui marche, hop je le commit"), à savoir les exigences imposés aux devs OpenBSD:
- relecture et validation quasiment systèmatique de tout code par un ou plusieurs autres developpeurs avant commit. Ces developpeurs, avec le temps, sont devenus des spécialistes de l'audit sécurité et de la relecture.
- respect de normes de codage ultra strictes (style(9) mais aussi utilisation de fonctions protégées et banissement des fonctions sensibles comme sprintf/strcpy/strcat/... etc.) sous peine de rejet du commit.
- filtrage sérré des contributeur: seuls ceux qui ont faire leurs preuves, par exemple en trouvant et corrigeant pleins de bugs, en produisant du code très propre ..., sont susceptibles d'être acceptés.
- relecture, grep -r, et modification/protection du code chaque fois qu'une nouveau type générique de faille est découvert, ou par séries thématique (eg, problèmes sur les manips de chaines, sur la gestion des signaux, sur le test des codes de retours de snprintf(3), ...), l'arbre des sources étant régulierement nettoyé de ces "oddities" ou de méthodes de programmations dont on découvre qu'elles étaient imprafaites.
- fonctionnement et tests en environnement protégé (eg. /etc/malloc.conf -> AJFG, propolice etc.) pour detecter rapidement les possibles debordements de mémoire.
- évolution très conservatrice et incrémentale (commits par petits patches, refus des ajouts de fonctionalités trop hardies ...).
- design devant permettre un fonctionnement sécurisé (séparation des privilèges pour les daemons, pas d'IPv6 mappé en IPv4, ...).
Donc il est improbable que le code soit sale ; d'autant que le soft tourne sur un paquet de machines (Linux, *BSD, Cisco et autres unix) depuis longtemps déjà ; les problèmes de sécurité remontent vite dans ces conditions, et ils ont été peut nombreux (on peut imaginer qu'OpenSSH est dans la ligne de mire de la plupart des hackers en herbe, vu son utilité stratégique et sa grande diffusion).