| Le kernel de mandrake inclut le patch grsecurity, et la sécurisation se fait via
| msec, qui, par exemple, restorent les permissions, vérifient les logs etc.
Le patch grsecurity est d'ailleurs un vrai régal à appliquer et régler sur Debian.
Le site de grsecurity a des présentations très intéressantes sr le deal perfo/sécurité.
Quand aux autres outils, ils sont présent en abondance dans la Debian normal.
Pour s'en persuader, et puisque personne n'en à parlé, je donne l'URL indispensable pour accompagner cet article : http://www.debian.org/doc/manuals/securing-debian-howto/.(...)
Ne me remerciez pas, tout le plaisir a été pour moi :-)
MDR!
Et pourtant après le premier mail j'aurai parié pour un classique flame emacs/xemacs dans les trois mails qui suivaient!
Tout ca pour savoir si un emacs en mode texte dont tout le monde se fout est dispo dans truc ou dans machin. Ca fait belle lurette que même dans la pire brouette y a de quoi faire tourner 12 emacs sous X. En cas de pb de performances, il s'agit probablement d'autre chose.
Note que des choses intéressante sur l'utilisation de stable/unstable ont été dites (et je vois que tu résiste à participer au débat :), mais ce n'est clairement pas le troll... enfin je veux dire le sujet :-)
Donc, pour envenimmer le flame... pardon : pour recadrer le débat, est-ce que ce emacs avec Gtk est disponible en deb non-officiel quelque part?
Ta phrase commence raisonablement, mais derrière "ou autre" se cache un monde que tu ne sembles pas connaître. Ca n'a pas l'air de te géner pour lancer des phrases définitives.
Il n'est bien sur pas question de Perl.
Ada est un langage compilé. Ce qui fait la différence en terme de sécurité, c'est principalement la qualité de la conception du langage, et tout ce qu'il permet de vérifier à la compilation. Les (très utiles) checks ajouté à l'exécution peuvent être retirés par les options de compilation.
Dans ce cas, tu ne perd rien en performance, mais tu gardes le bénefice des vérifications à la compilation.
C'est probablement essentiellement la même chose pour Eiffel.
Mon trollomètre a frémis :-)
Tu veux savoir si j'imagine d'utiliser un langage qui me permet de développer en 40% moins de temps avec 10 fois moins de défaut trouvé après release?
Tu veux sérieusement que je réponde? :-)
Je parle pour ce que je connais, Ada. Va voir dans http://libre.act-europe.fr/Software_Matters/(...) l'étude Ziegler dans Programming Languages and Software Construction.
Maintenant si je dois développer un serveur SMTP from scratch sans Ada, et qu'on me prouve que Eiffel, Python ou le langage de la mére Denis présentent ne serais-ce qu'un quart de ces avantages, eh ben j'achète le Kernighan & Mère Denis et je m'y met.
Parce que le soir, je préfère passer 1 heure avec mes enfants qu'avec gdb.
Je sais, je sais, je ne suis décidement pas un vrai code warrior :-)
Ce n'est pas repousser le problème, c'est le traiter là ou tu peux.
Il n'y a évidemment pas de solution parfaite, et la faille peut-être dans les librairies appelées, mais tu aura 10 fois moins de problèmes de ce genre.
C'est autant de temps supplémentaire que tu passera sous emacs et non sous gdb. A moins d'être debbugo-dépendant, c'est quand même le but, non?
Effectivement, "buffer overflow" est devenu une news tellement banale...
Je ne sais pas ce que sont ProPolice et StackGuard, mais je pense que le plus simple est quand même de privilégier des applis utilisant un langage de programmation qui empèche ce genre de faille (quand elles existent!).
Le Secure Programming for Linux and Unix HOWTO (http://www.dwheeler.com/secure-programs(...)) a tout un chapitre sur ce sujet.
Après avoir longement parlé de C/C++ (et justement de ProPolice et StackGuard), il termine par :
The problem of buffer overflows is an excellent argument for using other programming languages such as Perl, Python, Java, and Ada95. After all, nearly all other programming languages used today (other than assembly language) protect against buffer overflows.
Je sais bien qu'on ne fait pas toujours ce que l'on veut (le site de mon assoc http://www.ada-france.org/(...) doit bien tourner sur une machine à 95% avec des programmes en C alors qu'il fait la promotion du langage Ada).
Mais bon, il faut quand même rappeller cette évidence de temps en temps, histoire que tout le monde soit conscient que le temps énorme que l'on perd sur ces stupidités est facile à éviter dés le début d'un projet.
Je confirme, je parlais bien des développements répartis sur plusieurs continents.
La programmation répartie est un sujet pasionnant, et très bient traité dans Ada 95, mais ca ne concerne qu'une petite partie des projets "libres".
[^] # Re: Trusted Debian 1.0
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Trusted Debian 1.0. Évalué à 3.
| msec, qui, par exemple, restorent les permissions, vérifient les logs etc.
Le patch grsecurity est d'ailleurs un vrai régal à appliquer et régler sur Debian.
Le site de grsecurity a des présentations très intéressantes sr le deal perfo/sécurité.
Quand aux autres outils, ils sont présent en abondance dans la Debian normal.
Pour s'en persuader, et puisque personne n'en à parlé, je donne l'URL indispensable pour accompagner cet article : http://www.debian.org/doc/manuals/securing-debian-howto/.(...)
Ne me remerciez pas, tout le plaisir a été pour moi :-)
[^] # Re: Parfait !
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Sortie de GNU Emacs 21.3. Évalué à 8.
Et pourtant après le premier mail j'aurai parié pour un classique flame emacs/xemacs dans les trois mails qui suivaient!
Tout ca pour savoir si un emacs en mode texte dont tout le monde se fout est dispo dans truc ou dans machin. Ca fait belle lurette que même dans la pire brouette y a de quoi faire tourner 12 emacs sous X. En cas de pb de performances, il s'agit probablement d'autre chose.
Note que des choses intéressante sur l'utilisation de stable/unstable ont été dites (et je vois que tu résiste à participer au débat :), mais ce n'est clairement pas le troll... enfin je veux dire le sujet :-)
Donc, pour envenimmer le flame... pardon : pour recadrer le débat, est-ce que ce emacs avec Gtk est disponible en deb non-officiel quelque part?
Même pour unstable :-)
[^] # Re: Faille de sécurité importante dans Sendmail
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Faille de sécurité importante dans Sendmail. Évalué à 1.
[^] # Re: Faille de sécurité importante dans Sendmail
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Faille de sécurité importante dans Sendmail. Évalué à 2.
Il n'est bien sur pas question de Perl.
Ada est un langage compilé. Ce qui fait la différence en terme de sécurité, c'est principalement la qualité de la conception du langage, et tout ce qu'il permet de vérifier à la compilation. Les (très utiles) checks ajouté à l'exécution peuvent être retirés par les options de compilation.
Dans ce cas, tu ne perd rien en performance, mais tu gardes le bénefice des vérifications à la compilation.
C'est probablement essentiellement la même chose pour Eiffel.
[^] # Re: Faille de sécurité importante dans Sendmail
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Faille de sécurité importante dans Sendmail. Évalué à 7.
Tu veux savoir si j'imagine d'utiliser un langage qui me permet de développer en 40% moins de temps avec 10 fois moins de défaut trouvé après release?
Tu veux sérieusement que je réponde? :-)
Je parle pour ce que je connais, Ada. Va voir dans http://libre.act-europe.fr/Software_Matters/(...) l'étude Ziegler dans Programming Languages and Software Construction.
Maintenant si je dois développer un serveur SMTP from scratch sans Ada, et qu'on me prouve que Eiffel, Python ou le langage de la mére Denis présentent ne serais-ce qu'un quart de ces avantages, eh ben j'achète le Kernighan & Mère Denis et je m'y met.
Parce que le soir, je préfère passer 1 heure avec mes enfants qu'avec gdb.
Je sais, je sais, je ne suis décidement pas un vrai code warrior :-)
[^] # Re: Faille de sécurité importante dans Sendmail
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Faille de sécurité importante dans Sendmail. Évalué à 1.
Il n'y a évidemment pas de solution parfaite, et la faille peut-être dans les librairies appelées, mais tu aura 10 fois moins de problèmes de ce genre.
C'est autant de temps supplémentaire que tu passera sous emacs et non sous gdb. A moins d'être debbugo-dépendant, c'est quand même le but, non?
# Re: Faille de sécurité importante dans Sendmail
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Faille de sécurité importante dans Sendmail. Évalué à 5.
Je ne sais pas ce que sont ProPolice et StackGuard, mais je pense que le plus simple est quand même de privilégier des applis utilisant un langage de programmation qui empèche ce genre de faille (quand elles existent!).
Le Secure Programming for Linux and Unix HOWTO (http://www.dwheeler.com/secure-programs(...)) a tout un chapitre sur ce sujet.
Après avoir longement parlé de C/C++ (et justement de ProPolice et StackGuard), il termine par :
The problem of buffer overflows is an excellent argument for using other programming languages such as Perl, Python, Java, and Ada95. After all, nearly all other programming languages used today (other than assembly language) protect against buffer overflows.
Je sais bien qu'on ne fait pas toujours ce que l'on veut (le site de mon assoc http://www.ada-france.org/(...) doit bien tourner sur une machine à 95% avec des programmes en C alors qu'il fait la promotion du langage Ada).
Mais bon, il faut quand même rappeller cette évidence de temps en temps, histoire que tout le monde soit conscient que le temps énorme que l'on perd sur ces stupidités est facile à éviter dés le début d'un projet.
Lionel
[^] # Re: Non, il n'y a pas de troll dans la news !
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Conclusion du premier concours logiciel libre d'Ada-France. Évalué à 1.
La programmation répartie est un sujet pasionnant, et très bient traité dans Ada 95, mais ca ne concerne qu'une petite partie des projets "libres".
Je profite de cette réponse pour ajouter une petite référence au "Big Online Book of Linux Ada Programming" :
http://www.vaxxine.com/pegasoft/homes/book.html(...)
A connaitre!