Mouais, enfin, quand même, on ne va pas sur linuxfr se mettre à vanter les mérites de la duplication du travail et à la liaison statique des bibliothèques... Le fait est qu'il existe peut-être des raisons très particulières sur ce genre d'exemples où il n'est pas insensé d'avoir une certaine redondance, mais il faut quand même des arguments un peu plus poussés que "it is insane". D'un point de vue extérieur et complètement ignorant, il peut semble "insane" de devoir maintenir plusieurs implémentations indépendantes du même algorithme, surtout quand il s'agit d'un algo super-sensible pour la sécurité. Est-ce que le risque de laisser une faille qui permette de faire tomber à la fois SSH et le noyau est plus important que de doubler le risque d'avoir une faille soit dans SSH, soit dans le noyau?
[^] # Re: l'algo du noyau ?
Posté par arnaudus . En réponse au journal High performance SSH. Évalué à 6.
Mouais, enfin, quand même, on ne va pas sur linuxfr se mettre à vanter les mérites de la duplication du travail et à la liaison statique des bibliothèques... Le fait est qu'il existe peut-être des raisons très particulières sur ce genre d'exemples où il n'est pas insensé d'avoir une certaine redondance, mais il faut quand même des arguments un peu plus poussés que "it is insane". D'un point de vue extérieur et complètement ignorant, il peut semble "insane" de devoir maintenir plusieurs implémentations indépendantes du même algorithme, surtout quand il s'agit d'un algo super-sensible pour la sécurité. Est-ce que le risque de laisser une faille qui permette de faire tomber à la fois SSH et le noyau est plus important que de doubler le risque d'avoir une faille soit dans SSH, soit dans le noyau?