Journal Programmation robuste

Posté par .
Tags : aucun
0
7
mar.
2007
Salut mon cher journal.
Je t'écris parce que je recherche des liens vers des documents traitant de la programmation robuste, ou plus spécialement des problèmes de sécurité avec le langage C.
J'ai été faire un tour sur le site du CERT,
https://www.securecoding.cert.org/confluence/display/seccode(...)

Mais je suis vraiment déçu, il y a pas mal de conneries et d'inexactitudes.
Donc, ce serait génial si tu pouvais me donner des liens vers des documents donnant des conseils pour écrire du code robuste/sûr (fonctions, gestion mémoire, environnement, race condition, etc) en C.

Merci!
  • # libapr

    Posté par (page perso) . Évalué à 1.

    personnellement j'utilise libapr ....
    ca permet d'avoir un code plus lisible, plus simple et plus robuste. les pools permettent d'éviter bcp de leaks, de depassements de buffer etc.
  • # Je n'aurais qu'un mot ...

    Posté par (page perso) . Évalué à 1.

  • # Un livre ca va ?

    Posté par . Évalué à 9.

    http://www.microsoft.com/mspress/books/5957.aspx

    Oui je sais c'est MS c'est le mal absolu, mais le bouquin contient plein d'infos utiles et explications sur quoi faire/ne pas faire.
    • [^] # Re: Un livre ca va ?

      Posté par . Évalué à 10.

      Le « mal absolu », surement pas, mais un bouquin sur la programmation sécurisé édité par MS, c'est tout à fait cocasse :)
    • [^] # Re: Un livre ca va ?

      Posté par . Évalué à 2.

      Ah, tu l'avous enfin, et tu le dis toi même :
      MS c'est le mal absolu, et c'est pBpG qui le dit !
    • [^] # Re: Un livre ca va ?

      Posté par (page perso) . Évalué à 3.

      Oui je sais c'est MS c'est le mal absolu

      Oui, MS est le mal absolu mais pour moi MS Press ne l'est pas du tout.
      Il existe plusieurs bouquins pas trop mal chez eux et que ce soit marqué crosoft ou non, cela ne change rien à la qualité pour une fois ;)

      note : je n'ai pas celui dont tu parle (d'ailleurs pour ceux qui cherchent, l'isbn de l'édition française est : 2 10 006750 8) mais celui-ci : http://www.amazon.fr/Tout-sur-code-concevoir-logiciel/dp/210(...) et j'avoue avoir été très agréablement surpris ;-)
    • [^] # Re: Un livre ca va ?

      Posté par (page perso) . Évalué à 4.

      D'ailleur en parlant de bouquin sur le code sur et micorsoft press, j'avais trouver dans la BU de mon universitée il y a quelques années un bouquin (de chez microsoft press donc) ecirt par un employé de microsoft chef de projet word ou un truc comme ça si mes souvenirs sont bon. Sur la quatrième de couverture il prétendait que "écrire du code sans bug c'est possible, et ce livre va vous dire comment".
      Je dois avouer que j'avais éclaté de rire en voyant code sans bug et chef de projet à microsoft cote-à-cote, et sa m'avait poussé à emprunter et lire le bouquin.
      Ce fut la lecture la plus interessante que j'ai jamais eu sur le sujet. Le bouquin était vraiment bon et traitait bien le sujet, avec du code très propre qui marchait bien.
      Depuis je me dit que chez microsoft, soit il ne savent pas exploité les talents qu'ils on chez eux, soit ils font exprès de rajouter des bugs... (phrase gratuite je le sais...)
      Bref, chez microsoft press il y a de très bon bouquins, et même si le sujet peut preter à rire par rapport au logiciel rééllement produit, lisez le bouquin avant de vous faire une opinion.
      (si quelqu'un connait le titre du bouquin en question, sa m'interesserais de le relire)
      • [^] # Re: Un livre ca va ?

        Posté par (page perso) . Évalué à 4.

        Il ne faut pas oublier le vieil adage populaire: "Faites ce que je dis pas ce que je fais".
      • [^] # Re: Un livre ca va ?

        Posté par (page perso) . Évalué à 2.

        Peut-être Steve Maguire ? C'est le nom qui me reviens de mémoire. Je me souviens d'un bouquin comme ça, où l'auteur explique que quand il est arrivé chez microsoft, en tant que responsable d'une lib, il a fait mettre un tas de contrôles sur les paramètres d'entrée en mode débug... et que tous les utilisateurs ont été fort mécontents (obligés de nettoyer leur code et de faire attention à ce qu'ils passaient...) + tout plein de petites annecdotes et de bons conseils.

        http://www.google.fr/search?q=Steve+Maguire

        Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

    • [^] # Re: Un livre ca va ?

      Posté par . Évalué à 2.

      J'ai toujours eu une bonne appréciation des livres édités par Microsoft Press, (à l'exception des bouquins parlant de produits ou «technologies» spécifiques Microsoft, mais là le débat n'était pas sur les qualités du bouquin)
  • # Vu sur securecoding.org

    Posté par . Évalué à 5.

    Vu en suivant ton lien :


    Documentations
    Programmation securisée

    Warning: array_merge() [function.array-merge]: Argument #1 is not an array in /mnt/116/sdb/6/c/linuxprocess/documentXML.php on line 41

    Warning: array_merge() [function.array-merge]: Argument #1 is not an array in /mnt/116/sdb/6/c/linuxprocess/documentXML.php on line 41

    Warning: array_merge() [function.array-merge]: Argument #1 is not an array in /mnt/116/sdb/6/c/linuxprocess/documentXML.php on line 41

    [Y'en a BEAUCOUP...]

    Warning: array_merge() [function.array-merge]: Argument #1 is not an array in /mnt/116/sdb/6/c/linuxprocess/documentXML.php on line 41

    Warning: array_merge() [function.array-merge]: Argument #1 is not an array in /mnt/116/sdb/6/c/linuxprocess/documentXML.php on line 41

    Warning: array_flip() [function.array-flip]: The argument should be an array in /mnt/116/sdb/6/c/linuxprocess/documentXML.php on line 109

    Warning: array_flip() [function.array-flip]: The argument should be an array in /mnt/116/sdb/6/c/linuxprocess/documentXML.php on line 109

    Warning: sort() expects parameter 1 to be array, boolean given in /mnt/116/sdb/6/c/linuxprocess/documentXML.php on line 110

    Warning: Invalid argument supplied for foreach() in /mnt/116/sdb/6/c/linuxprocess/documents.php


    Ca inspire confiance ! :)
    • [^] # Re: Vu sur securecoding.org

      Posté par (page perso) . Évalué à 2.

      Résumé a mon avis...

      Il récupère des données de la base de donnée, et ne vérifie pas ce qui est retourné ;)

      Bref, ça pue le code porky pas E_STRICT ready...
  • # Tu a faim de liens coquin...? (Vu sur @NetBSD-help)

    Posté par . Évalué à 10.

    Vu sur la mailling de NetBSD-help il y a peu :

    Je resume en français:

    Un Monsieur, George Georgalis, se pose des questions pour ces codeurs:

    http://mail-index.netbsd.org/netbsd-help/2007/01/23/0000.htm(...)

    Le monsieur, qui ne pose jamais de questions sans s'etre posé
    de questions fournit quelque reponse avec la question:

    http://www.soberit.hut.fi/mmantyla/BadCodeSmellsTaxonomy.htm
    [http://www.dwheeler.com/secure-programs/ Secure Programming for Linux and Unix HOWTO -- Creating Secure Software]
    [http://www.faqs.org/docs/artu/ch01s06.html Basics of the Unix Philosophy]
    [http://www.shelldorado.com/ good coding practices for Bourne Shell and Korn Shell script programmers.]
    [http://www-128.ibm.com/developerworks/aix/library/au-hook_du(...) Best practices for programming in C]
    [http://stommel.tamu.edu/~baum/programming.html Programming Texts and Tutorials] -- meta site
    [http://mindprod.com/jgloss/unmain.html unmaintainable code]


    Il s'en suit un echange tres interessant:

    http://thread.gmane.org/gmane.os.netbsd.help/15970/focus=159(...)

    Le monsieur, qui etait apparement tres content d'avoir reçut
    quelque reponse sur differente list il me semble, nous gratifie
    d'un resume :

    == Near Term Programming and Unix Operating Systems ==
    Overview of techniques and strategies -- when and why they are useful

    * [http://cm.bell-labs.com/cm/cs/who/dmr/cacm.html The UNIX Time-Sharing System] -- D. M. Ritchie and K. Thompson
    * [http://www.dwheeler.com/secure-programs/ Secure Programming for Linux and Unix HOWTO -- Creating Secure Software]
    * [http://www.faqs.org/docs/artu/ch01s06.html Basics of the Unix Philosophy] from [http://www.faqs.org/docs/artu/ The Art of Unix Programming]
    * [http://www.shelldorado.com/ good coding practices for Bourne Shell and Korn Shell script programmers.]
    * [http://www-128.ibm.com/developerworks/aix/library/au-hook_du(...) Best practices for programming in C]
    * [http://www.hacknot.info/hacknot/action/showEntry?eid=85 Debugging 101]

    == What not to do ==
    * [http://www.soberit.hut.fi/mmantyla/BadCodeSmellsTaxonomy.htm A Taxonomy for "Bad Code Smells"]
    * [http://mindprod.com/jgloss/unmain.html unmaintainable code]

    == Alternate Technique ==
    * [http://www.methodsandtools.com/archive/archive.php?id=10 Will Pair Programming Really Improve Your Project?]
    * [http://c2.com/doc/oopsla89/paper.html A Laboratory For Teaching Object-Oriented Thinking]
    * [http://www.extremeprogramming.org/ Extreme Programming] -- a deliberate and disciplined approach

    == Reference ==
    * [http://www.nrbook.com/a/bookfpdf.html Numerical Recipes in Fortran 77]
    * [http://www.nrbook.com/a/bookf90pdf.html Numerical Recipes in Fortran 90]
    * [http://www.nrbook.com/abramowitz_and_stegun/ Abramowitz and Stegun: Handbook of Mathematical Functions]

    == Abstract ==
    * [http://www.ibiblio.org/obp/thinkCS/cpp/english/index.htm How To Think Like A Computer Scientist]
    * [http://www.theserverside.com/tt/articles/content/BuildManage(...) Best Practices for Risk-Free Deployment]
    * [http://en.wikipedia.org/wiki/Design_Patterns Design Patterns: Elements of Reusable Object-Oriented Software] (also the [http://www.tml.tkk.fi/~pnr/GoF-models/html/ GoF Patterns])
    * [http://www.cs.wustl.edu/~schmidt/tutorials-patterns.html Design Pattern Tutorials] (see [http://www.cs.wustl.edu/~schmidt/PDF/patterns-intro4.pdf Introduction to Design Patterns]
    * [http://www.datingdesignpatterns.com/intro.html Dating Design Patterns] -- a tangible implementation
    * [http://www.maplefish.com/todd/papers/Experiences.html Experiences] -- A Pattern Language for User Interface Design

    == The Lighter Side ==
    * [http://www.cryptonomicon.com/beginning.html In the Beginning was the Command Line] by Neal Stephenson
    * [http://research.microsoft.com/~daniel/unix-haters.html The UNIX-HATERS Handbook]
    * [http://kuoi.asui.uidaho.edu/~kamikaze/doc/kvik.html The Kvikkalkul Programming Language]
    * a [http://www.cadenhead.org/book/homepage24/kvikkalkul/kvik2c.h(...) Kvikkalkul to C Translator]
    * a Kvikkalkul version of [http://www.99-bottles-of-beer.net/k.html#Kvikkalkul 99 bottles of beer]

    == Meta Resource ==
    * [http://www.softdevarticles.com/ Software Development Articles Directory]
    * [http://stommel.tamu.edu/~baum/programming.html Programming Texts and Tutorials]

    == Books ==
    * [http://www-cs-faculty.stanford.edu/~knuth/taocp.html The Art of Computer Programming (TAOCP)]



    Certain liens archi sont connu, d'autre moins, certain sont même rigolo.
    Faite chauffer les imprimante.
    Bonne lecture. ( je conseille aussi de lire l'echange de mail )
  • # Mon expérience

    Posté par (page perso) . Évalué à 7.

    Rendre un logiciel existant robuste se fait en plusieurs étapes.

    #1 : Une compilation sans avertissement

    Un avertissement est souvent un bug potentiel. Un comparaison nombre entier naturel et nombre entier relatif peut être une source de bug (integer overflow). => gcc -Wall -Wextra. Je trouve ça complètement débile que "-Wall" n'affiche pas ALL (tous) les avertissements... (avec gcc < 4 : -Wall -W). Pour les fanatiques : -Werror bloque la compilation à chaque avertissement.

    #2 : Valgrind

    Il faut que le programme ait zéro erreur dans Valgrind.

    #3 : Analyse statique du code

    Utiliser SPlint, Rats, Flawfinder, etc. pour trouver les portes d'entrées possible pour des failles.
    http://www.haypocalc.com/wiki/Analyse_statique_de_code

    ### Fin de la partie basique ###

    Maintenant il faut revoir le programme pour limiter les dégats. Ca peut être :

    - Vérifier strictement toutes les entrées utilisateurs : clavier, réseau, variable d'environnement, fichier de configuration, fichier en entrée, événement X11, etc.

    Voir les dégats que ça peut faire :
    http://sam.zoy.org/zzuf/
    http://www.haypocalc.com/wiki/Injection_de_code
    http://www.haypocalc.com/wiki/Injection_de_SQL
    http://www.haypocalc.com/wiki/Format_string_attack

    - Vérifiez aussi le code de retour des fonctions, et particulier les fonctions systèmes (fopen, chdir, fork, etc.).

    - Séparation des privilèges : séparer et limiter au maximum le code exécuté avec des privilèges elevés

    - etc.
    • [^] # Re: Mon expérience

      Posté par . Évalué à 1.

      Un avertissement est souvent un bug potentiel. Un comparaison nombre entier naturel et nombre entier relatif peut être une source de bug (integer overflow). => gcc -Wall -Wextra. Je trouve ça complètement débile que "-Wall" n'affiche pas ALL (tous) les avertissements... (avec gcc < 4 : -Wall -W). Pour les fanatiques : -Werror bloque la compilation à chaque avertissement.


      Moi aussi.
      Mais la logique de la gcc team c'est qu'ils considèrent qu'un programme peut parfaitement être correct même s'il se mange des warnings avec les options qui ne sont pas activées par -Wall.
      En gros, si tu as des warnings avec -Wall, tu sais (a priori) que tu as un problème. Avec ls autres options, il y a des chances que ça te fasse perdre ton temps. Ca dépend de ton degré d'extrêmisme...
      • [^] # Re: Mon expérience

        Posté par . Évalué à 2.

        Et des soft comme le kernel se retrouve noyé par des warning sans interret.

        "La première sécurité est la liberté"

  • # Change de langage

    Posté par . Évalué à 2.

    Je ne sais pas ce que tu souhaites programmer et je sais bien qu'on ne peut pas toujours se passer du C, mais une chose est sûre : le C (et tous ses dérivés dont le C++) est un langage catastrophique au niveau de la robustesse et de la sécurité de programmation. Même en étant extrêmement rigoureux, on n'est jamais complètement à l'abri des nombreux problèmes "intrinsèques" au langage.

    Je ne dis pas ça parce que je n'aime pas le C. Je programme presque exclusivement en C++, mais c'est justement cette expérience-là qui me fait dire : aucun programme écrit en C n'est robuste ou sécurisé. Il y a trop de failles intrinsèques au langage lui-même.

    Je suis loin d'être un expert dans le domaine, mais voilà une petite recette personnelle pour éviter une grande partie des problèmes classiques :
    * n'utilise aucun pointeur C. Elimine les * partout où c'est possible.
    * ne gère jamais la mémoire toi-même.
    * bannis toutes les fonctions d'entrée/sortie standards du C (genre printf)
    * n'utilise jamais de tableaux en C.

    C'est sûr. Quand on s'interdit tout ça, on se demande à quoi bon rester en C. Disons que ça doit servir de signal d'alerte. Dès qu'il y a une * ou des [ ] dans un code, il faut se poser la question de tous les cas particuliers. Une solution intermédiaire minimale, c'est d'utiliser une bibliothèque externe pour toutes ces notions.

    Mais bon, ça reste des rustines collées sur un langage non fiable. Le fameux "bufferoverflow ", qui est le vice profond du C, est à l'origine de sans doute 95% des failles des logiciels actuels. Le C a été inventé à une époque où l'idée de robustesse n'avait pas encore percé. Conséquence : la sécurité en langage C est tout simplement une chimère.

    La seule raison pour laquelle on reste sous ce langage, c'est la grande base de code existant, et le grand nombre de bibliothèques disponibles. Heureusement, ça change petit à petit. De moins en moins de programmeurs savent ce qu'est un pointeur, ni même ce que le terme de "gestion de la mémoire" peut signifier. Et je m'en réjouis.

    Ah oui, juste pour la petite note : les outils comme valgrind sont très bons pour détecter certains types de problèmes précis, mais ils ne remplaceront jamais l'analyse détaillée par le programmeur de tous les cas particulier de son code. ça implique notamment de vérifier toutes les possibilités de pointeur qui ne sont pas à jour, de division par zéro, d'indice incorrect dans un tableau, etc. Une bonne pratique est de mettre des vérifications dans le code lui-même (par exemple sur tous les indices de tableau). Le gros piège, c'est de se dire : ah mais y'a de problème. L'indice est toujours inférieur à telle valeur parce que gnagnagna. Il vaut mieux mettre un bon gros test if sur l'indice pour être certain qu'il se comporte comme prévu.

    D'ailleurs le problème de fond de la robustesse/sécurité, à mon avis, n'est pas de savoir quoi faire, mais de savoir si on est prêt à le faire : le coût à payer en temps supplémentaire de codage et en pollution du code est très élevé pour sécuriser vraiment un programme en C.
    • [^] # Re: Change de langage

      Posté par (page perso) . Évalué à 0.

      T'es un marrant toi : tu parles du C++ comme du C.
      Sauf qu'en C++, si tu programme sans l'héritage du C, c'est comme Java : jamais de pointeur.
      Le code est aussi sûr entre un language C++ (voire C) codé avec les meme precautions (donc test si tu es a un buffer overflow automatique) qu'avec n'importe quel language.
      Un exemple? En C++ ou Java (et bcp d'autres langauges), tu as une exception si tu demandes un index en dehors du tableau. Si tu ne sais pas gérer l'exception en C++ et que ton programme fait n'importe quoi, ben ce serap areil avec Java ou autre.

      Maintenant que tu as fait ton argumentation, tu préconises quel langauge où ta critique du C++ n'est pas adaptable?
      • [^] # Re: Change de langage

        Posté par . Évalué à 6.

        En C++ ou Java (et bcp d'autres langauges), tu as une exception si tu demandes un index en dehors du tableau.


        Euuuuuuuuh...

        bash-3.1$ cat test.cpp
        /* test.cpp */
        int main() {
        int *arr = new int[10];
        arr[10] = 1;
        delete []arr;
        return 0;
        }
        bash-3.1$ g++ test.cpp
        bash-3.1$ ./a.out
        bash-3.1$ cat Test.java
        /* Test.java */
        public class Test {
        public static void main(String args[]) {
        int arr[] = new int[10];
        arr[10] = 1;
        }
        }
        bash-3.1$ javac Test.java
        bash-3.1$ java Test
        Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 10
        at Test.main(Test.java:4)

        Tu vois pas de différence ?
        • [^] # Re: Change de langage

          Posté par . Évalué à 6.

          Il a dit sans utiliser les pointeurs, donc en utilisant un tableau de la STL.
          • [^] # Re: Change de langage

            Posté par (page perso) . Évalué à 5.

            Dans ce cas la personne à l'initiative de ce fil avait raison :
            Une solution intermédiaire minimale, c'est d'utiliser une bibliothèque externe pour toutes ces notions.
          • [^] # Re: Change de langage

            Posté par (page perso) . Évalué à 3.

            Mais les tableaux de la stl ne lancent pas plus d'exceptions quand on fait un accès en dehors du tableau via l'operateur [] ( c'est la fonction at() qui lance une exception )
    • [^] # Re: Change de langage

      Posté par . Évalué à 10.

      La seule raison pour laquelle on reste sous ce langage, c'est la grande base de code existant, et le grand nombre de bibliothèques disponibles.

      Tu as deja entendu parler de l'embarqué ?

      De moins en moins de programmeurs savent ce qu'est un pointeur, ni même ce que le terme de "gestion de la mémoire" peut signifier. Et je m'en réjouis.

      Perso ca me désole. Et encore plus de voir des gens qui s'en réjouissent.
      • [^] # Re: Change de langage

        Posté par . Évalué à 1.

        Euh... Je dirais surtout que C est une grosse bouse mais qu'il n'y a rien pour le remplacer dans pas mal de cas d'utilisation. (d'habitude je place lisaac à ce moment là, mais j'ai la flemme)

        "La première sécurité est la liberté"

        • [^] # Re: Change de langage

          Posté par (page perso) . Évalué à 2.

          Surtout que lisaac, c'est génial sauf que buggé et pas fini. En gros ce n'est pas sur le point de remplacer le C (et cela me désole).

          C'est quand la version 0.2 du compilateur ? De préférence une version qui ne quitte pas sans explication sur le code que j'écris :)
      • [^] # Re: Change de langage

        Posté par . Évalué à 2.

        Tu as deja entendu parler de l'embarqué ?
        Y a aussi ada qui est (etait) utiliser dans les applis embarquées critiques.

        Mais bon meme si le language genere des exceptions en cas de problème (debordement, ...), si elle ne sont pas correctement gerer par le programme le resultat est le meme : ca plante. Cf ariane 5
    • [^] # Re: Change de langage

      Posté par . Évalué à 5.

      Le C, c'est, après l'assembleur, le langage qui permet d'être au plus près de la machine. Et donc d'optimiser au mieux ses programmes pour les rendre le plus performant possible. Alors oui c'est plus dur à coder, y'a pas de ramasse miettes et de gros filet pour rattraper toutes les erreurs potentielles du programmeur, mais c'est pas plus mal.

      Ce qui me désole, c'est justement que beaucoup de nouveaux programmeurs ne sachent plus utiliser les pointeurs. Maintenant, on code dans des langages super sécurisés à la base, mais au final tellement plus lents à l'exécution... Et avec tout ce travail prémaché, on en perd justement toutes les habitudes et les concepts qui font qu'on se soucie de l'aspect sécurité.
      • [^] # Re: Change de langage

        Posté par (page perso) . Évalué à 3.

        Maintenant, on code dans des langages super sécurisés à la base, mais au final tellement plus lents à l'exécution...


        Bon, je ne connais pas trop, mais il y a quand même des langages sécurisés qui sont rapides. Je pense notament à Eiffel ou Lisaac qui permettent une programmation par contrats (Lisaac, ce n'est pas encore je crois) ... et compilent le code en C

        Le C c'est bien car c'st un espèce d'assembleur portable. Mais a mon avis, c'est plus intéressant de programmer dans un langage de plus haut niveau qui traduit le code en C par la suite.
    • [^] # Re: Change de langage

      Posté par . Évalué à 6.

      avec ce genre de réserves et de raisonnement, ne prends plus jamais la voiture : même si tu conduis bien, il y aura toujours un risque de tomber sur un con bourré en face
    • [^] # Re: Change de langage

      Posté par . Évalué à 6.

      Je ne dis pas ça parce que je n'aime pas le C. Je programme presque exclusivement en C++, mais c'est justement cette expérience-là qui me fait dire : aucun programme écrit en C n'est robuste ou sécurisé. Il y a trop de failles intrinsèques au langage lui-même.
      Et pourtant y a des logiciels en C qui ne sont pas codé avec les pieds qui on tres peu de faille : par exemple http://vsftpd.beasts.org/

      n'utilise aucun pointeur C. Elimine les * partout où c'est possible.
      Tu passes comment les parametres dans tes fonctions ?
      En copiant tout sur la stack ?
      Et les valeurs de retour, en utilisant des variables globales ?


      * ne gère jamais la mémoire toi-même.
      * bannis toutes les fonctions d'entrée/sortie standards du C (genre printf)
      * n'utilise jamais de tableaux en C.

      T'as des exemples de code C avec tes regles ?
      Je serais curieux de voir ce que ca donne :)
      (Il est bien entendu qu'il est hors de question d'utiliser des libs qui ne respectent pas ses regles, et que tu as donc recoder ta libc...)
      • [^] # Re: Change de langage

        Posté par . Évalué à 2.

        "Une solution intermédiaire minimale, c'est d'utiliser une bibliothèque externe pour toutes ces notions."

        Il faut tout lire ...

        "La première sécurité est la liberté"

      • [^] # Re: Change de langage

        Posté par . Évalué à 1.

        Je ne dis pas ça parce que je n'aime pas le C. Je programme presque exclusivement en C++, mais c'est justement cette expérience-là qui me fait dire : aucun programme écrit en C n'est robuste ou sécurisé. Il y a trop de failles intrinsèques au langage lui-même.


        Et pourtant y a des logiciels en C qui ne sont pas codé avec les pieds qui on tres peu de faille : par exemple http://vsftpd.beasts.org/


        A cela on ajoute qmail, lighttpd, dovecot ... Et des applis qui n'ont pas le droit a l'erreur (validees par Astree http://www.astree.ens.fr/ par exemple!!)
  • # Doc: eviter les failles de securité

    Posté par . Évalué à 2.

    http://www.blaess.fr/christophe/publications/articles/index.(...)

    Il y a de la doc en quatre partie, ce sont des articles parut dans linuxmag, sur la programmation en C. Assez instructif.

    Allez tous vous faire spéculer.

  • # Coding Standard

    Posté par (page perso) . Évalué à 2.

    Mais je suis vraiment déçu, il y a pas mal de conneries et d'inexactitudes.

    Qu'est-ce qu'il y a comme conneries/inexactitudes ?
    • [^] # Re: Coding Standard

      Posté par . Évalué à 1.

      J'aimerais bien aussi savoir quelles sont ces "conneries/inexactitues" ... C'est un peu nul de critiquer ce genre d'initiative sans aucun argument ni exemple.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.