Maintenant que cette fonctionnalité de protection de la pile fait partie intégrante de GCC (ce qui était réclamée à corps et à cris depuis des années ) on peut penser que toutes les distributions vont faire profiter leurs utilisateurs de ce surcroît appréciable de sécurité.
Ça serait formidable !
À ce jour, je n'ai pas eu d'autres echos que de la position de Fedora Core, dont un développeur expliquait sur une mailing-list que les packages sont désormais compilés avec cette option activée (la FC 5 sera donc releasée avec cette protection). Et évidement DragonflyBSD et OpenBSD qui utilisent son équivalent pour gcc3 depuis une paye.
Qu'en est-il des autres distributions ? quelles sont celles qui ont annoncé leur position par rapport à cette option (qu'ils aient décidé de la supporter ou non) ?
Qu'en pensent Debian, Ubuntu, OpenSuse et Mandriva ?
Je suis particulièrement inquiet pour Debian, qui a longtemps tenu le haut du pavé en matière de sécurité, du fait de la très haute exigeance qualité de son équipe de developpeurs. Mais qui semble ne plus tenir le rythme, par exemple par rapport à Fedora (qui intègre maintenant par défaut SELinux , Exec-Shield, fstack-protector , FORTIFY_SOURCE...).
Un grand nombre de ces protections (option /Gs de vc++, ACL ntfs, ...) sont même désormais intégrées dans les dernières releases de windows, cependant que (selon un sondage mené par debian-administration.org) les developpeurs Debian considèrent la sécurisation comme relativement secondaire (et je ne parle pas des couacs comme l'absence de maj sécu de juillet dernier, le temps de réponse aux problèmes de firefox en aout etc. !).
Quel dommage s'il fallait se priver de la qualité et stabilité légendaires de Debian (sur ce plan, Debian ne fléchit pas !) pour avoir un environement sécurisé par défaut, lors de la prochaine release (et non, recompiler toute l'archive avec -fstack-protector, créer les polices SELinux pour les daemons courants et le système de base etc. n'est pas une solution triviale. Et oui, ces protections sont devenues nécéssaire, parceque les pirates ont, eux aussi, progréssé. D'où le besoin du secure "by default").
# Protection de la pile par défaut sur les prochaines releases des distros
Posté par herodiade . En réponse à la dépêche Sortie de la version 4.1 du compilateur GCC. Évalué à 10.
Ça serait formidable !
À ce jour, je n'ai pas eu d'autres echos que de la position de Fedora Core, dont un développeur expliquait sur une mailing-list que les packages sont désormais compilés avec cette option activée (la FC 5 sera donc releasée avec cette protection). Et évidement DragonflyBSD et OpenBSD qui utilisent son équivalent pour gcc3 depuis une paye.
Qu'en est-il des autres distributions ? quelles sont celles qui ont annoncé leur position par rapport à cette option (qu'ils aient décidé de la supporter ou non) ?
Qu'en pensent Debian, Ubuntu, OpenSuse et Mandriva ?
Je suis particulièrement inquiet pour Debian, qui a longtemps tenu le haut du pavé en matière de sécurité, du fait de la très haute exigeance qualité de son équipe de developpeurs. Mais qui semble ne plus tenir le rythme, par exemple par rapport à Fedora (qui intègre maintenant par défaut SELinux , Exec-Shield, fstack-protector , FORTIFY_SOURCE...).
Un grand nombre de ces protections (option /Gs de vc++, ACL ntfs, ...) sont même désormais intégrées dans les dernières releases de windows, cependant que (selon un sondage mené par debian-administration.org) les developpeurs Debian considèrent la sécurisation comme relativement secondaire (et je ne parle pas des couacs comme l'absence de maj sécu de juillet dernier, le temps de réponse aux problèmes de firefox en aout etc. !).
Quel dommage s'il fallait se priver de la qualité et stabilité légendaires de Debian (sur ce plan, Debian ne fléchit pas !) pour avoir un environement sécurisé par défaut, lors de la prochaine release (et non, recompiler toute l'archive avec -fstack-protector, créer les polices SELinux pour les daemons courants et le système de base etc. n'est pas une solution triviale. Et oui, ces protections sont devenues nécéssaire, parceque les pirates ont, eux aussi, progréssé. D'où le besoin du secure "by default").