IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Mars 2013
    Messages
    8 914
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Mars 2013
    Messages : 8 914
    Points : 206 635
    Points
    206 635
    Par défaut La Maison Blanche invite les développeurs à abandonner le C et le C++ pour passer à des langages comme le Rust
    La NSA exhorte les organisations à passer à des langages de programmation sécurisés dans la gestion de la mémoire,
    pour éliminer un vecteur d'attaque souvent exploité par les cybercriminels

    La National Security Agency (NSA) a publié des conseils pour aider les développeurs et les opérateurs de logiciels à prévenir et à atténuer les problèmes de sécurité de la mémoire logicielle, qui représentent une grande partie des vulnérabilités exploitables. La fiche d'information sur la cybersécurité « Sécurité de la mémoire logicielle » souligne comment les cyberacteurs malveillants peuvent exploiter les problèmes de mauvaise gestion de la mémoire pour accéder à des informations sensibles, promulguer l'exécution de code non autorisé et causer d'autres impacts négatifs.

    « Les problèmes de gestion de la mémoire sont exploités depuis des décennies et sont encore trop courants aujourd'hui », a déclaré Neal Ziring, directeur technique de la cybersécurité. « Nous devons utiliser systématiquement des langages sécurisés pour la mémoire et d'autres protections lors du développement de logiciels afin d'éliminer ces faiblesses des cyberacteurs malveillants ».


    La société moderne s'appuie fortement sur l'automatisation basée sur les logiciels, faisant implicitement confiance aux développeurs pour écrire des logiciels qui fonctionnent de la manière attendue et ne peuvent pas être compromis à des fins malveillantes. Alors que les développeurs effectuent souvent des tests rigoureux pour préparer la logique des logiciels à des conditions surprenantes, les vulnérabilités logicielles exploitables sont encore souvent basées sur des problèmes de mémoire. Les exemples incluent le débordement d'une mémoire tampon et l'exploitation des problèmes liés à la façon dont le logiciel alloue et désalloue la mémoire.

    Microsoft a révélé lors d'une conférence en 2019 que, de 2006 à 2018, 70 % de leurs vulnérabilités étaient dues à des problèmes de sécurité de la mémoire. Google a également trouvé un pourcentage similaire de vulnérabilités de sécurité de la mémoire sur plusieurs années dans Chrome. Les cyber-acteurs malveillants peuvent exploiter ces vulnérabilités pour l'exécution de code à distance ou d'autres effets indésirables, qui peuvent souvent compromettre un appareil et être la première étape des intrusions réseau à grande échelle. Les langages couramment utilisés, tels que C et C++, offrent une grande liberté et une grande flexibilité dans la gestion de la mémoire tout en s'appuyant fortement sur le développeur pour effectuer les vérifications nécessaires sur les références mémoire.

    De simples erreurs peuvent conduire à des vulnérabilités exploitables basées sur la mémoire. Les outils d'analyse logicielle peuvent détecter de nombreux cas de problèmes de gestion de la mémoire et les options d'environnement d'exploitation peuvent également fournir une certaine protection, mais les protections inhérentes offertes par les langages logiciels sécurisés pour la mémoire peuvent prévenir ou atténuer la plupart des problèmes de gestion de la mémoire.

    La NSA recommande d'utiliser un langage sécurisé pour la mémoire lorsque cela est possible. Bien que l'utilisation de protections supplémentaires pour les langages non sécurisés pour la mémoire et l'utilisation de langages sécurisés pour la mémoire n'offrent pas une protection absolue contre les problèmes de mémoire exploitables, elles offrent une protection considérable.

    Par conséquent, la communauté logicielle globale du secteur privé, du milieu universitaire et du gouvernement américain a lancé des initiatives visant à orienter la culture du développement logiciel vers l'utilisation de langages sécurisés dans la gestion de la mémoire.

    Nom : nsa.png
Affichages : 26471
Taille : 544,8 Ko

    Le problème de la sécurité de la mémoire

    La façon dont un programme logiciel gère la mémoire est essentielle pour prévenir de nombreuses vulnérabilités et garantir la robustesse d'un programme. L'exploitation d'une gestion de la mémoire médiocre ou négligente peut permettre à un cyberacteur malveillant d'accomplir des actes néfastes, tels que planter le programme à volonté ou modifier les instructions du programme en cours d'exécution pour faire ce que l'acteur désire. Même des problèmes inexploitables avec la gestion de la mémoire peuvent entraîner des résultats de programme incorrects, une dégradation des performances du programme au fil du temps ou des plantages de programme apparemment aléatoires.

    La sécurité de la mémoire est une vaste catégorie de problèmes liés à la façon dont un programme gère la mémoire. Un problème courant est appelé « débordement de tampon », où les données sont accessibles en dehors des limites d'un tableau. D'autres problèmes courants concernent l'allocation de mémoire. Les langages peuvent allouer de nouveaux emplacements de mémoire pendant l'exécution d'un programme, puis désallouer la mémoire, également appelée libération ou libération de la mémoire, plus tard lorsque la mémoire n'est plus nécessaire. Mais si cela n'est pas fait avec soin par le développeur, de la nouvelle mémoire peut être allouée encore et encore au fur et à mesure que le programme s'exécute. Par conséquent, la mémoire n'est pas toujours libérée lorsqu'elle n'est plus nécessaire, ce qui entraîne une fuite de mémoire qui pourrait entraîner le programme à manquer de mémoire disponible.

    En raison d'erreurs logiques, les programmes peuvent également tenter d'utiliser la mémoire qui a été libérée, ou même de libérer de la mémoire qui a déjà été libérée. Un autre problème peut survenir lorsque les langages autorisent l'utilisation d'une variable qui n'a pas été initialisée, ce qui fait que la variable utilise la valeur précédemment définie à cet emplacement en mémoire. Enfin, un autre problème difficile est appelé une condition de concurrence. Ce problème peut se produire lorsque les résultats d'un programme dépendent de l'ordre de fonctionnement de deux parties du programme accédant aux mêmes données. Tous ces problèmes de mémoire sont des occurrences beaucoup trop courantes.

    En exploitant ces types de problèmes de mémoire, les acteurs malveillants, qui ne sont pas liés par les attentes normales d'utilisation du logiciel, peuvent découvrir qu'ils peuvent entrer des entrées inhabituelles dans le programme, provoquant l'accès, l'écriture, l'allocation ou la désallocation de la mémoire de manière inattendue. Dans certains cas, un acteur malveillant peut exploiter ces erreurs de gestion de la mémoire pour accéder à des informations sensibles, exécuter du code non autorisé ou provoquer d'autres impacts négatifs. Puisqu'il peut falloir beaucoup d'expérimentation avec des entrées inhabituelles pour en trouver une qui provoque une réponse inattendue, les acteurs peuvent utiliser une technique appelée "fuzzing" pour créer de manière aléatoire ou intelligente une multitude de valeurs d'entrée dans le programme jusqu'à ce qu'on en trouve une qui provoque le plantage du programme.

    Les progrès des outils et des techniques de fuzzing ont facilité la recherche d'entrées problématiques pour les acteurs malveillants ces dernières années. Une fois qu'un acteur découvre qu'il peut faire planter le programme avec une entrée particulière, il examine le code et travaille pour déterminer ce qu'une entrée spécialement conçue pourrait faire. Dans le pire des cas, une telle entrée pourrait permettre à l'acteur de prendre le contrôle du système sur lequel le programme s'exécute.

    Nom : national.png
Affichages : 5732
Taille : 94,2 Ko

    Langages sécurisés dans la gestion de la mémoire

    L'utilisation d'un langage sécurisé pour la mémoire peut aider à empêcher les programmeurs d'introduire certains types de problèmes liés à la mémoire. La mémoire est gérée automatiquement dans le cadre du langage informatique ; il ne repose pas sur l'ajout de code par le programmeur pour implémenter des protections de mémoire. Le langage institue des protections automatiques en utilisant une combinaison de vérifications au moment de la compilation et de l'exécution. Ces fonctionnalités inhérentes au langage protègent le programmeur contre l'introduction involontaire d'erreurs de gestion de la mémoire. C#, Go, Java, Ruby, Rust et Swift sont des exemples de langage sécurisé pour la mémoire.

    Même avec un langage sécurisé pour la mémoire, la gestion de la mémoire n'est pas entièrement sécurisée pour la mémoire. La plupart des langages de mémoire sécurisés reconnaissent que les logiciels doivent parfois exécuter une fonction de gestion de mémoire non sécurisée pour accomplir certaines tâches. En conséquence, des classes ou des fonctions sont disponibles qui sont reconnues comme non sécurisées pour la mémoire et permettent au développeur d'effectuer une tâche de gestion de la mémoire potentiellement dangereuse. Certains langages exigent que tout ce qui n'est pas sûr en mémoire soit explicitement annoté comme tel pour que le développeur et tous les réviseurs du programme sachent qu'il n'est pas sûr. Les langages sécurisés pour la mémoire peuvent également utiliser des bibliothèques écrites dans des langages non sécurisés pour la mémoire et peuvent donc contenir des fonctionnalités de mémoire non sécurisées. Bien que ces façons d'inclure la mémoire ne soient pas sûres et subvertissent la sécurité inhérente à la mémoire, elles aident à localiser où des problèmes de mémoire pourraient exister, permettant un examen plus approfondi de ces sections de code.

    Les langages varient dans leur degré de sécurité de la mémoire institué par des protections et des atténuations inhérentes. Certains langages n'offrent qu'une sécurité de mémoire relativement minimale alors que certains langages sont très stricts et offrent des protections considérables en contrôlant la manière dont la mémoire est allouée, accessible et gérée. Pour les langages avec un niveau extrême de protection inhérente, un travail considérable peut être nécessaire pour obtenir simplement le programme à compiler en raison des vérifications et des protections.

    La sécurité de la mémoire peut être coûteuse en matière de performances et de flexibilité. La plupart des langages mémoire sécurisés nécessitent une sorte de récupération de place pour récupérer la mémoire qui a été allouée, mais qui n'est plus nécessaire au programme. Il existe également une surcharge de performances considérable associée à la vérification des limites de chaque accès à la baie qui pourrait potentiellement se trouver en dehors de la baie.

    Alternativement, un impact similaire sur les performances peut exister dans un langage non sécurisé en mémoire en raison des vérifications qu'un développeur ajoute au programme pour effectuer la vérification des limites et d'autres protections de gestion de la mémoire. Les coûts supplémentaires liés à l'utilisation de langages non sécurisés pour la mémoire incluent une corruption de mémoire difficile à diagnostiquer et des plantages occasionnels des programmes ainsi que de potentielles exploitations des vulnérabilités d'accès à la mémoire. Il n'est pas anodin de faire passer une infrastructure de développement logiciel mature d'un langage informatique à un autre. Les développeurs qualifiés doivent être formés dans un nouveau langage et il y a un coup d'efficacité lors de l'utilisation d'un nouveau langage.

    Les développeurs doivent endurer une courbe d'apprentissage et se frayer un chemin à travers toutes les erreurs de « débutant ». Alors qu'une autre approche consiste à embaucher des développeurs compétents dans un langage sécurisé pour la mémoire, ils auront eux aussi leur propre courbe d'apprentissage pour comprendre la base de code existante et le domaine dans lequel le logiciel fonctionnera.

    Source : NSA

    Et vous ?

    Que pensez-vous des conseils de la NSA ? Y en a-t-il que vous appliquez déjà ?
    Que pensez-vous du fait que l'agence préconise l'utilisation des langages de programmation sécurisés pour la mémoire comme C#, Go, Java, Ruby, Rust et Swift ?
    « Les développeurs qualifiés doivent être formés dans un nouveau langage et il y a un coup d'efficacité lors de l'utilisation d'un nouveau langage. Les développeurs doivent endurer une courbe d'apprentissage et se frayer un chemin à travers toutes les erreurs de « débutant ». Alors qu'une autre approche consiste à embaucher des développeurs compétents dans un langage sécurisé pour la mémoire, ils auront eux aussi leur propre courbe d'apprentissage pour comprendre la base de code existante et le domaine dans lequel le logiciel fonctionnera ». Qu'en pensez-vous ? Êtes-vous d'accord avec l'agence ?

  2. #2
    Membre expert Avatar de KiLVaiDeN
    Profil pro
    Inscrit en
    Octobre 2003
    Messages
    2 864
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2003
    Messages : 2 864
    Points : 3 438
    Points
    3 438
    Par défaut
    Utiliser un container ou une sandbox peut aussi permettre d'isoler un programme de son environnement, ce qui me semble être une bonne solution pour éviter les "débordements".

    Je suis étonné que dans la liste des langages de programmation "sécurisés dans l'utilisation de la mémoire" Python et Javascript(Typescript) ne soient pas mentionnés, alors qu'ils sont largement utilisés et "memory-safe" me semble-t-il. PHP aussi, de part sa nature interprétée pourrait faire partie de cette liste. Ou Perl. Les exemples sont nombreux.

  3. #3
    Membre régulier
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2015
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Août 2015
    Messages : 16
    Points : 76
    Points
    76
    Par défaut
    Utiliser un container ou une sandbox peut aussi permettre d'isoler un programme de son environnement, ce qui me semble être une bonne solution pour éviter les "débordements".
    C'est une barrière de sécurité supplémentaire, mais certainement pas une solution.

    Python et php ne sont pas exempts de bufferoverflow non plus.
    Et a vrai dire, du C++ moderne est aussi plutôt bien calé sur le "memory safety", par contre il continue a autoriser des constructions bien barbares complètements unsafe.
    Entre le legacy et les codeurs mal formés (faudrait déjà des formateurs bien formés...), on comprend l'intérêt de language "paranoïdes" tel que Rust.

  4. #4
    Membre habitué Avatar de vivid
    Profil pro
    Inscrit en
    Février 2006
    Messages
    176
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 176
    Points : 140
    Points
    140
    Par défaut
    faire confiance a la NSA... Sécuriser=>bien contrôler. De la part d'une organisation qui espionne le monde entier

  5. #5
    Nouveau membre du Club
    Homme Profil pro
    Retraité
    Inscrit en
    Février 2009
    Messages
    22
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Retraité
    Secteur : Enseignement

    Informations forums :
    Inscription : Février 2009
    Messages : 22
    Points : 26
    Points
    26
    Par défaut C'est pas nouveau
    Plus de 20 ans que j'avertis mes étudiants des risques liés à la gestion mémoire par C et que je les pousse à la POO et plus particulièrement à Java

  6. #6
    Membre régulier
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2015
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Août 2015
    Messages : 16
    Points : 76
    Points
    76
    Par défaut
    Citation Envoyé par vivid Voir le message
    faire confiance a la NSA... Sécuriser=>bien contrôler. De la part d'une organisation qui espionne le monde entier
    Bein ils s'y connaissent pour le coup. J'utilise Ghidra (un outil créé par la NSA) assez régulièrement.
    Bon, y'avait une petite backdoor qui trainait mais elle a été fixée.

  7. #7
    Membre confirmé
    Homme Profil pro
    autre
    Inscrit en
    Septembre 2015
    Messages
    271
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : autre

    Informations forums :
    Inscription : Septembre 2015
    Messages : 271
    Points : 600
    Points
    600
    Par défaut
    Citation Envoyé par KiLVaiDeN Voir le message
    Je suis étonné que dans la liste des langages de programmation "sécurisés dans l'utilisation de la mémoire" Python et Javascript(Typescript) ne soient pas mentionnés, alors qu'ils sont largement utilisés et "memory-safe" me semble-t-il. PHP aussi, de part sa nature interprétée pourrait faire partie de cette liste. Ou Perl. Les exemples sont nombreux.
    Il n’y a pas de quoi l’être, ce ne sont que des exemples illustratifs qui n’ont pas vocation à être exhaustifs. On pourrait aussi ajouter Ruby (utilisé pour développer GitLab), erlang, et plein plein d’autres !

    Il est écrit : C#, Go, Java, Ruby, Rust et Swift sont des exemples de langage sécurisé pour la mémoire.

    Perl a une mention particulière en terme de sécurité : ses variables teintées (mais on s’écarte du sujet).

  8. #8
    Membre habitué Avatar de vivid
    Profil pro
    Inscrit en
    Février 2006
    Messages
    176
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 176
    Points : 140
    Points
    140
    Par défaut
    "Plus de 20 ans que j'avertis mes étudiants des risques liés à la gestion mémoire par C et que je les pousse à la POO et plus particulièrement à Java "

    un bon nivellement par le bas, bravo

  9. #9
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par vivid Voir le message
    "Plus de 20 ans que j'avertis mes étudiants des risques liés à la gestion mémoire par C et que je les pousse à la POO et plus particulièrement à Java "

    un bon nivellement par le bas, bravo
    Le nivellement par le bas c'est de rester sur des vieux langages et ne pas évoluer.

  10. #10
    Membre habitué Avatar de vivid
    Profil pro
    Inscrit en
    Février 2006
    Messages
    176
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 176
    Points : 140
    Points
    140
    Par défaut
    Citation Envoyé par Erviewthink Voir le message
    Le nivellement par le bas c'est de rester sur des vieux langages et ne pas évoluer.
    Ce serait un commercial qui me disait çà..., ce sont dans les vieux pots que l'on fait les meilleures soupes.

    Dans les écoles de cuisine une nouvelle spécialité (véridique); décongeler les plats préparés !



  11. #11
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par vivid Voir le message
    Ce serait un commercial qui me disait çà..., ce sont dans les vieux pots que l'on fait les meilleures soupes.

    Dans les écoles de cuisine une nouvelle spécialité (véridique); décongeler les plats préparés !


    Perdre son temps à gérer de la mémoire plutôt que coder j'appelle ça une perte de temps.

  12. #12
    Membre habitué Avatar de vivid
    Profil pro
    Inscrit en
    Février 2006
    Messages
    176
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 176
    Points : 140
    Points
    140
    Par défaut
    Citation Envoyé par Erviewthink Voir le message
    Perdre son temps à gérer de la mémoire plutôt que coder j'appelle ça une perte de temps.
    faut poursuivre dans cette philosophie !! un seul type de variable etc etc... on est plus niveau ingénieur, mais conducteur de ligne automatisé.

  13. #13
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par vivid Voir le message
    faut poursuivre dans cette philosophie !! un seul type de variable etc etc... on est plus niveau ingénieur, mais conducteur de ligne automatisé.
    Pourquoi tu codes pas en assembleur ou même en binaire vu que t'es un "ingénieur" ?

  14. #14
    Membre habitué Avatar de vivid
    Profil pro
    Inscrit en
    Février 2006
    Messages
    176
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 176
    Points : 140
    Points
    140
    Par défaut
    Citation Envoyé par Erviewthink Voir le message
    Pourquoi tu codes pas en assembleur ou même en binaire vu que t'es un "ingénieur" ?
    justement C et asm

  15. #15
    Invité
    Invité(e)
    Par défaut
    Oui tu codes pas tout en assembleur ou en binaire t'es donc un assisté

  16. #16
    Membre habitué Avatar de vivid
    Profil pro
    Inscrit en
    Février 2006
    Messages
    176
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 176
    Points : 140
    Points
    140
    Par défaut
    Citation Envoyé par Erviewthink Voir le message
    Oui tu codes pas tout en assembleur ou en binaire t'es donc un assisté
    de la part de quelqu'un qui préconise le JAVA... l’hôpital qui se fout de la charité.
    Ne vous faite pas mal, rester en JAVA.

    Cordialement.

  17. #17
    Invité
    Invité(e)
    Par défaut
    Pendant que tu galères avec tes segment default moi mon application tourne pépère.

    J'espère que tu maîtrises mieux le c et l'assembleur que le français.

  18. #18
    Membre habitué Avatar de vivid
    Profil pro
    Inscrit en
    Février 2006
    Messages
    176
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 176
    Points : 140
    Points
    140
    Par défaut
    Citation Envoyé par Erviewthink Voir le message
    Pendant que tu galères avec tes segment default moi mon application tourne pépère.

    J'espère que tu maîtrises mieux le c et l'assembleur que le français.
    Si tu galère comme tu dis c'est que tu as encore à apprendre.

    'ton application qui tourne pépère', tu m’étonne ! l’équivalent de tuer une mouche au lance flamme. Oui on le demande partout ce langage, faut pas demander aux sociétés l’épanouissement intellectuel de leur employés collaborateurs mais du rendement, logique. On rajoutera des baby foot... . Mais cela reste un nivellement par le bas.

    Je possède une licence poétique, si si ! je m'excuse auprès de ta rigueur plus en verve sur l'orthographe que sur la logique d'un langage dit de bas niveaux. Mais voilà je préfère la créativité que me procure la programmation et si je veux, je peux même changer les règles. Cordialement.

  19. #19
    Invité
    Invité(e)
    Par défaut
    En plus de ne pas savoir écrire tu ne sais pas lire, j'espère que tu ne travailles pas sur des systèmes critiques. Vu ton niveau j'en doute mais sait-on jamais.

  20. #20
    Membre confirmé
    Homme Profil pro
    autre
    Inscrit en
    Septembre 2015
    Messages
    271
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : autre

    Informations forums :
    Inscription : Septembre 2015
    Messages : 271
    Points : 600
    Points
    600
    Par défaut
    Vivid : tu critiquerais le rendement de Java qui serait trop élevé ? Je prendrais cela comme un avantage. Par ailleurs, je trouve plus épanouissant de coder des fonctions qui servent plutôt qu’à chercher des bugs de pointeurs ou d’allocations mémoire. Ou ne pas réinventer telle ou telle structure de données (dictionnaires…). Question de point de vue.

Discussions similaires

  1. Parts de marchés des langages de programmation
    Par Marc Lussac dans le forum Langages de programmation
    Réponses: 51
    Dernier message: 21/05/2013, 13h51
  2. Index TIOBE du classement des langages de programmation
    Par Gordon Fowler dans le forum Actualités
    Réponses: 564
    Dernier message: 13/01/2013, 18h51
  3. Passer des paramètres à un programme
    Par Cravis dans le forum VB 6 et antérieur
    Réponses: 4
    Dernier message: 08/11/2007, 14h32
  4. L'avenir des langages de programmation
    Par LordBob dans le forum Langages de programmation
    Réponses: 14
    Dernier message: 02/04/2006, 23h03

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo