Vulnérabilités dans OpenSSL

Posté par Meister le 01 octobre 2003 à 08:43. Modéré par Benoît Sibaud.

Étiquettes :

oct.

2003

Des problèmes de sécurité viennent d'être révélé par le projet OpenSSL, la bibliothèque de cryptographie. La faille découverte permet un déni de services et une corruption de pile favorisant alors l'exécution de code hostile.

Toutes les versions inférieures à 0.9.6j et 0.9.7b sont affectées.

Il est recommandé de passer à la version 0.9.7c ou 0.9.6k et de recompiler les programmes liés statiquement à OpenSSL.

Aller plus loin

Le site d'OpenSSL (7 clics)
Les vulnérabilités d'OpenSSL (9 clics)

# Re: Vulnérabilités dans OpenSSL

Posté par Boa Treize (site web personnel) le 01 octobre 2003 à 09:01. Évalué à 9.

Des packages OpenSSL 0.9.7c sont disponibles pour Slackware 9.1 et slackware-current depuis 2 heures et demi environ. Par contre, il va falloir attendre plusieurs heures pour que les miroirs se mettent à jour, et vu qu'ils sont surchargés depuis la sortie de Slackware 9.1, je vous suggère de mettre à jour vous-même OpenSSL si votre site est sensible.
- [^] # Re: Vulnérabilités dans OpenSSL
  
  Posté par Rémi Hérilier le 01 octobre 2003 à 14:35. Évalué à 8.
  
  En effet, les ftp sont plutôt encombrés par l'arrivée de la Slackware 9.1 mais bon il n'y a pas que le ftp dans la vie ... ya aussi rsync que moins de monde utilise :-)
  
  Une petite synchro, un coup de upgradepkg et hop !
  
  Il y a deux petits scripts bien sympathiques sur le forum de Slackware Francophone à l'adresse http://slackware.tuxfamily.org/forum/viewtopic.php?t=37(...) (au premier tiers de la page).
  
  À noter que dans slackware-current sont aussi arrivés :
  - perl 5.8.1
  - samba 3.0
  - xfce 4.0
  
  bonheur quand tu nous tiens :-)
  
  bon rsync ;-)
- [^] # Re: Vulnérabilités dans OpenSSL
  
  Posté par Rémi Hérilier le 01 octobre 2003 à 14:53. Évalué à 1.
  
  Avec ma veine légendaire, je viens de répondre à la personne qui a fait les dits scripts :-))
  
  En tout cas, merci beaucoup :-)
# Re: Vulnérabilités dans OpenSSL

Posté par Pascal Terjan (site web personnel) le 01 octobre 2003 à 09:09. Évalué à 7.

Des updates pour la Mandrake 9.2 (qui n'est pas encore disponible) sont aussi déjà la depuis hier soir (cf ftp://ftp.lip6.fr/pub/linux/distributions/mandrake/updates/9.2/RPM(...) par exemple)
- [^] # Re: Vulnérabilités dans OpenSSL
  
  Posté par Paul POULAIN (site web personnel, Mastodon) le 01 octobre 2003 à 10:16. Évalué à 2.
  
  ceux pour la MDK 9.1 & consorts sont aussi sortis.
  - [^] # Re: Vulnérabilités dans OpenSSL
    
    Posté par dawar (site web personnel) le 01 octobre 2003 à 14:01. Évalué à 3.
    
    itoo pour debian : Get:1 http://security.debian.org(...) stable/updates/main libssl0.9.6 0.9.6c-2.woody.4 [462kB]
    - [^] # Re: Vulnérabilités dans OpenSSL
      
      Posté par Pascal Terjan (site web personnel) le 01 octobre 2003 à 16:25. Évalué à 0.
      
      Et en testing ?
      - [^] # unstable si pressé
        
        Posté par free2.org le 02 octobre 2003 à 13:36. Évalué à 1.
        
        il te faudra peut-etre télécharger la version d'unstable si tu es pressé, car il y a une "quarantaine" + ou - longue (écourtée en cas de sécurité) avant qu'un paquet puisse aller dans testing (absence de bug grave à vérifier d'abord, dépendances)
        
        j'ai une page qui explique comment mélanger stable/testing/unstable:
        http://free2.org/d/(...)
        
        [^] # Re: unstable si pressé
        
        Posté par Pascal Terjan (site web personnel) le 05 octobre 2003 à 22:56. Évalué à 1.
        
        Ah et par contre en stable ils sortent le paquet sans test ?
        Je ne comprend pas trop comment ca peut etre systematiquement beaucoup plus rapide pour la version stable que j'aurais jugée ne devoir recevoir des nouveau paquets super testés justement !
        
        [^] # Re: unstable si pressé
        
        Posté par Prosper le 05 octobre 2003 à 23:00. Évalué à 1.
        
        d apres des sources sures , c est parce que y a que la security team qui a fait l'acquisition d une licence IPOT
- [^] # Gentoo, ça criant
  
  Posté par un_brice (site web personnel) le 01 octobre 2003 à 14:53. Évalué à 2.
  
  ~.~
  
  Gentoo est encore à la traine: l'ebuild de la 0.96k est distribué, et depuis hier. Mais marqué instable: pour l'utiliser, il faut l'éditer à la main ou alors spécifier son numèro de version demander à utiliser une version instable... sur le bugzilla ils prévoient le passage à la 0.97c dans quelques jours. Et en attendant, rien.
  
  Je me rappelle que lors des dernières failles du noyau, ils avaient mis 1 mois pour intègrer les patchs à leur noyeau.
  Et après il viennent parler d'une "hardened Gentoo"... ça me fait rire, même en tant qu'adepte de cette distrib.
  
  Vivement Zynot ! (bon, oké, ça à pas l'air d'avancer trop vite en ce moment)
  - [^] # Re: Gentoo, ça criant
    
    Posté par j le 01 octobre 2003 à 16:01. Évalué à 4.
    
    Barf il faut relativiser.
    
    Est-ce-qu'il existe des exploits publics pour ces failles ? Non, aucun à ma connaissance.
    
    Est-ce-que l'on peut être surs, 5 minutes après l'annonce de la nouvelle version, qu'elle peut être immédiatement installée sur tous les serveurs en prod sans rien casser ? Non.
    
    Si tu tiens à passer immédiatement à la nouvelle version sur ta Gentoo, tu peux, le paquetage est prêt. Il suffit d'admettre que tu souhaites installer quelque chose qui n'a pas encore été complétement testé. Un délai de quelques jours avant de marquer ces paquetage "stable" me paraît tout à fait raisonnable.
    - [^] # Re: Gentoo, ça criant
      
      Posté par j le 01 octobre 2003 à 17:15. Évalué à 4.
      
      En plus tu es de mauvaise foi car c'est marqué comme stable depuis ce midi.
      Et l'advisory officiel de Gentoo vient d'être envoyé sur Bugtraq et FD.
      - [^] # Re: Gentoo, ça criant
        
        Posté par un_brice (site web personnel) le 01 octobre 2003 à 17:35. Évalué à 3.
        
        °_°
        
        Je viens de faire un "emerge sync".
        emerge -p openssl
        [ebuild UD] dev-libs/openssl-0.9.6j [0.9.6k]
        ...
        http://www.gentoo.org/cgi-bin/viewcvs.cgi/dev-libs/openssl/openssl-(...)
        ...
        Si je suis de mauvaise fois, les mirroirs sont plus à jour que le CVS.
        Mais non! L'histoire est encore plus drôle.
        Lis l'historique du CVS: ils avaient oublié de spécifier que le package était disponible aussi pour sparc, et du coup ils ont rajoutté le mot clef "sparc" après coup.
        Sans penser à mettre le "~sparc" qui aurait indiqué que c'est une version instable (sur cette architecture) !
        
        Au passage, notte que tu as approuvée l'idée de Gentoo de ne pas mettre à jour la librairie, jusqu'à ce que tu crois qu'elle avait été mise à jour (alors qu'elle l'est par erreur, et seulement sur cette architecture). Dans ces conditions, m'accuser de mauvaise fois...
    - [^] # Re: Gentoo, ça criant
      
      Posté par un_brice (site web personnel) le 01 octobre 2003 à 17:18. Évalué à 3.
      
      Est-ce-qu'il existe des exploits publics pour ces failles ? Non, aucun à ma connaissance.
      
      Merveilleux: on est à l'abris des scripts kiddies ! (à priori)
      Je serais très surpris que personne n'arrive à exploiter cette faille dans les trois prochains jours.
      
      Est-ce-que l'on peut être surs, 5 minutes après l'annonce de la nouvelle version, qu'elle peut être immédiatement installée sur tous les serveurs en prod sans rien casser ? Non.
      
      Passer de la version 0.9.6j à la 0.9.6k, sachant que cette dernière consiste juste en 4 correctifs de sécurité... disons que c'est moins risqué que de garder une version vérolée.
      C'est d'ailleurs ce que se sont dit les mainteneurs des autres distros, semble-t'il.
      
      Si tu tiens à passer immédiatement à la nouvelle version sur ta Gentoo, tu peux, le paquetage est prêt. Il suffit d'admettre que tu souhaites installer quelque chose qui n'a pas encore été complétement testé. Un délai de quelques jours avant de marquer ces paquetage "stable" me paraît tout à fait raisonnable.
      
      Le fait est qu'un type qui fait confiance aux gestionnaires de sa distro (comme moi jusqu'à recement) se trompe.
      
      Un type qui installe un matin une gentoo avec la dernière version des packages doit en plus lire la liste des failles récentes et appliquer les mises à jour manuellement. Ceci requierant la modification/restauration du fichier de conf, pour evitter de se faire jetter comme quoi le package est experimental (ou alors il est habitué aux errements de Gentoo, et il a des scripts ou alias à portée de main).
      Et après, chaque mise à jour automatique essaieras en plus de passer tous ses packages en stable ou instable. Reste la (contraignante) possibilité d'afficher la liste les packages à mettre à jour, puis de les installer un par un. Mais alors ces packages ne seront pas supprimés par depclean, et ce même si ils ne ne sont plus utiles à aucun programe, car ils seront considérés comme utiles par eux mêmes. Jusqu'au prochain formatage.
      
      Pour moi, cet exemple, celui du kernel, et d'autres (pas seulement au niveau des packages) ne relèvent pas de la prudence mais plutôt d'un grave problème d'organisation. Il n'y a même pas de règles régissant le passage d'un package instable en stable !
      - [^] # Re: Gentoo, ça criant
        
        Posté par j le 01 octobre 2003 à 17:26. Évalué à 2.
        
        Pourquoi tu ne postes ceci sur les forums Gentoo ?
        
        [^] # Re: Gentoo, ça criant
        
        Posté par un_brice (site web personnel) le 01 octobre 2003 à 17:41. Évalué à 0.
        
        Parce que les dirigeants de Gentoo ont déjà démontrée leur aptitude à ne pas écoutter la comunautée, et que mon post ne changerais rien.
        Et aussi parce que je prefère pointer du doigt les défaut de l'organisation actuelle, et ainsi pousser à un changement un profondeur, que d'essayer de l'aider à se rendre crédible.
        
        Mais surtout parce que je parle très mal anglais. -_^
      - [^] # Re: Gentoo, ça criant
        
        Posté par GnunuX (site web personnel) le 02 octobre 2003 à 08:37. Évalué à 1.
        
        > C'est d'ailleurs ce que se sont dit les mainteneurs des autres distros, semble-t'il.
        
        Ou les mainteneurs d'autre distros font confiance a ceux qui maintiennent le package. L'instabilité des packages ne vient pas de l'instabilité des logiciels mais du systeme de dépendance ...
  - [^] # Re: Gentoo, ça criant
    
    Posté par Mathieu Pillard (site web personnel) le 02 octobre 2003 à 01:58. Évalué à 1.
    
    > Je me rappelle que lors des dernières failles du noyau, ils avaient mis 1 mois pour intègrer les patchs à leur noyeau.
    
    1/ tu es libre de ne pas prendre gentoo-sources, yen a plein d'autres.
    2/ pour gentoo-sources, il existe pfeifer-sources qui est la version de developpement, bcp plus a jour, pour les pressés.
    3/ gentoo-sources inclus grsecurity
# librairie de cryptographie

Posté par j le 01 octobre 2003 à 09:24. Évalué à 10.

Zut il me semblait que c'était une bibliothèque.

http://www.42-networks.com/faq/library.html(...)
- [^] # Bibliothèque !
  
  Posté par Christophe Morvan (site web personnel) le 01 octobre 2003 à 10:14. Évalué à 1.
  
  \o/ !
  
  Je ne suis pas tout seul !
- [^] # Re: librairie de cryptographie
  
  Posté par Gohar le 01 octobre 2003 à 12:13. Évalué à 10.
  
  Ca deviendra une librairie si les brevets logiciels passent: il faudra payer pour chaque fonction ;-)
- [^] # Re: librairie de cryptographie
  
  Posté par dinomasque le 01 octobre 2003 à 13:47. Évalué à 2.
  
  et moi qu'il s'agissait de chiffrement et non de cryptographie ...
  BeOS le faisait il y a 20 ans !
  - [^] # Re: librairie de cryptographie
    
    Posté par Nap le 01 octobre 2003 à 20:19. Évalué à 5.
    
    raté !
    chiffrement, déchiffrement, gestion de certificats, signature, authentification, choix de divers algorithmes,... c'est l'objet de la cryptographie
    
    l'erreur est de parler de cryptage au lieu de chiffrement ;)
- [^] # Re: librairie de cryptographie
  
  Posté par Salagnac le 01 octobre 2003 à 13:51. Évalué à 4.
  
  Dans une bibliothèque tu empruntes les fonctions et il faut les rendre sous deux semaines sinon tu as des pénalités. Dans une librairie tu peux acheter les fonctions et ensuite elles sont à toi.
# patches "exec shield" et "systrace"

Posté par free2.org le 01 octobre 2003 à 09:47. Évalué à 10.

pour ceux qui aiment modifier leur noyau, c'est le moment de rappeler que la plupart des failles liées à des débordements de tampon (buffer overflow) sont bégnines avec le patch "exec shield" de Ingo Mollnar

et pour les paranos, la quasi totalité des failles, quelque soit leur nature, sont confinables en lancant chaque programme internet dans une sandbox (interactive donc facile à paramétrer et elle nous alerte en cas d'anomalie) du patch systrace. Le surcout total en CPU est minime (de l'ordre de 1%).

tout ceci n'empeche évidemment pas de mettre à jour dès que possible openssl
- [^] # Re: patches "exec shield" et "systrace"
  
  Posté par FRLinux (site web personnel) le 01 octobre 2003 à 09:54. Évalué à 1.
  
  Petite question par rapport a ce patch, si tu installes des kernels avec grsecurity, il devient pas vraiment necessaire non ?
  
  Steph
  - [^] # grsecurity/execshield
    
    Posté par free2.org le 01 octobre 2003 à 10:08. Évalué à 2.
    
    en ce qui concerne les overflows je crois que exec shield est plus complet: il controle les variables stack, heap et static
    - [^] # Re: grsecurity/execshield
      
      Posté par yoho (site web personnel) le 02 octobre 2003 à 12:30. Évalué à 2.
      
      Non grsec vérifie cela aussi mais ces extensions ne sont pas activées par défaut dans la mandrake : il faut recompiler le noyau. Le BIG inconvénient si on met la sécurité maximale dans GRSec, c'est que certaines applications se plantent (sans dommage pour le système, mais elles ne fonctionnent pas quand même). C'est notamment le cas du X Window System ...
      - [^] # option de recompilation ?
        
        Posté par free2.org le 02 octobre 2003 à 20:43. Évalué à 2.
        
        il me semble qu'il y a une option dans gcc pour lui interdire de mettre du code exécutable dans les même zones mémoires que les variables, ce qui est la principale incompatibilité avec ces patches
- [^] # xsupervisor et fireflier
  
  Posté par free2.org le 01 octobre 2003 à 09:57. Évalué à 5.
  
  pour être complet en matière de sécurité je cite aussi les programmes xsupervisor pour X, et fireflier (firewall interactif) pour iptables
# En Anglais dans le texte

Posté par FRLinux (site web personnel) le 01 octobre 2003 à 09:53. Évalué à 8.

Il y a une petite erreur dans la news, toutes les versions d'OpenSSL sont vulnérables à un des problèmes, je cite : "1. Certain ASN.1 encodings that are rejected as invalid by the parser
... This issue does not affect OpenSSL 0.9.6"

Alors que la seconde affecte bien toutes les versions : "All versions of OpenSSL up to and including 0.9.6j and 0.9.7b and all
versions of SSLeay are affected."

Steph
# Zut encore une faute :o)

Posté par asailor le 01 octobre 2003 à 10:58. Évalué à 5.

Je cite :

All versions of OpenSSL up to and including 0.9.6j and 0.9.7b and all
versions of SSLeay are affected

On doit donc lire dans la news :

Toutes les versions inférieures ou égales à 0.9.6k et 0.9.7c sont affectées.

Sinon la phrase suivante :

Il est recommandé de passer à la version 0.9.7c ou 0.9.6k

n'a plus de sens !
- [^] # Re: Zut encore une faute :o)
  
  Posté par Meister le 01 octobre 2003 à 13:36. Évalué à 1.
  
  La logique a du me faire encore un tour.
  - [^] # Re: Zut encore une faute :o)
    
    Posté par asailor le 02 octobre 2003 à 09:35. Évalué à 1.
    
    Mais que fait la police ?
    
    Maintenant c'est « corrigé » comme cela :
    
    Toutes les versions inférieures à 0.9.6j et 0.9.7b sont affectées.
    
    Alors que ça devrait être :
    
    Toutes les versions inférieures ou égales à 0.9.6j et 0.9.7b sont affectées.
    
    Ok, je vais faire simple, tu choisis :
    
    1/
    Toutes les versions inférieures à 0.9.6k et 0.9.7c sont affectées.
    
    2/
    Toutes les versions inférieures ou égales à 0.9.6j et 0.9.7b sont affectées.
    
    Copier-coller et hop !
    
    ;-)
    - [^] # Re: Zut encore une faute :o)
      
      Posté par Nap le 02 octobre 2003 à 09:56. Évalué à 0.
      
      ça dépend si on prend le terme "inférieur" comme inférieur strict ou pas... dans les maths francaises il y a toujours l'ambiguïté
      
      en revanche chez les anglais elle n'y est pas, et pour dire "inférieur ou égal" ils disent "non supérieur" je crois
# Re: Vulnérabilités dans OpenSSL

Posté par cedricv le 01 octobre 2003 à 10:59. Évalué à 3.

Toutes les versions inférieures ou égales à 0.9.6k et 0.9.7c sont affectées.
(...)
Il est recommandé de passer à la version 0.9.7c ou 0.9.6k

le "ou égales" n'est t-il pas de trop dans la phrase? ou est-il conseilllé de mettre à jour sur une version affectée?
# Soyons précis dans nos traductions, merci.

Posté par AP le 01 octobre 2003 à 11:08. Évalué à 10.

Je suis exaspéré de voir partout "malicioux" traduit en "malicieux". "malicious" est un faux-ami qui se traduit par "méchant" ou "malveillant" et surtout pas par "malicieux". Désolé mais un ver, un virus... c'est pas franchement malicieux.

Dans la même série (un peu plus discutable peut-être), il y a "to forge" qui certes peut se traduire par "forger" (du métal) mais qu'on devrait plutôt traduire par "contrefaire". Pour moi "forged IP packets" se traduit par "paquets IP contrefaits" et non "forgés"...

Question ouverte aux modérateurs : ne pourrait-on pas mettre en place un système permettant de proposer des corrections sur le style ou l'orthographe ? Ceci délesterait les forums des messages sybillins du style "s/malicieux/malveillant/g"...
- [^] # Re: Soyons précis dans nos traductions, merci.
  
  Posté par AP le 01 octobre 2003 à 11:11. Évalué à 3.
  
  Vous aurez corrigé : s/malicioux/malicious/.
  Dans la même veine il serait sympathique de pouvoir corriger/supprimer ses propres contributions... :) Rien de plus horrible qu'un pinailleur tel que moi qui par étourderie s'expose au feu nourri d'autre pinailleurs (pires, sans doute :).
  - [^] # Re: Soyons précis dans nos traductions, merci.
    
    Posté par asailor le 01 octobre 2003 à 11:14. Évalué à 2.
    
    il serait sympathique de pouvoir corriger/supprimer ses propres contributions
    
    100% ok, mais ça pose un problème de cohérence avec le thread...
    (imagine que tu retires ce que d'autes ont commenté)
    - [^] # Re: Soyons précis dans nos traductions, merci.
      
      Posté par tene le 01 octobre 2003 à 11:23. Évalué à 2.
      
      Et un truc genre, le commentaire avec en dessous la liste des correctinons appliquées?
      
      Ceci dit, le problème est toujours le même, le site ne bouge pas des masses, et il semble pas que les admins soit super réactif... de là à dire qu'il s'en foute de leur communauté, je ne franchirai pas ce pas... mais je finis par me poser des questions....
    - [^] # Re: Soyons précis dans nos traductions, merci.
      
      Posté par a_jr le 01 octobre 2003 à 12:15. Évalué à 1.
      
      On peut peut-etre contourner cela en gardant l'historique du post, visible par tous.
      Ainsi, si qq dit "machin c'est genial" et qu'il change en "machin c'est nul", on verra tout de suite que le gars n'est pas fiable.
      
      On peut aussi rajouter un truc dans le genre ou une correction coute un [-], mais je ne sais pas si l'effet serait benefique (ca peut faire reflechir avant de poster) ou nefaste (du coup, on eviterait de corriger, pour ceux qui font gaffe a leux XP)
      
      On peut aussi rajouter un truc qui me semble important avec l'historique: mettre en evidence qu'il y a un historique sur le post, combien il y a eu de modifs, et quelle taille fait la modif. 2 lettres modifiees signifient generalement une correction orthographique, alors que 2 paragraphes changes, supprimes ou rajoutes signifient un changement majeur de signification du post.
      
      Il faudrait aussi peut-etre mettre en evidence qu'un post qui repond a un autre qui a ete modifie, repond a une ancienne version du post et non pas a celle visible.
      
      Bref, ca necessite beaucoup de modifs. Et comme d'hab, y'a qu'a, mais faut qq pour le faire.
      
      Le bonjour chez vous,
      Yves
    - [^] # Re: Soyons précis dans nos traductions, merci.
      
      Posté par Benjamin Michotte le 01 octobre 2003 à 15:00. Évalué à 1.
      
      ce qu'il faudrait, c'est un systeme de news à la wiki ;)
      
      (comment ca, c'est pas faisable ?)
- [^] # Re: Soyons précis dans nos traductions, merci.
  
  Posté par Anonyme le 01 octobre 2003 à 11:15. Évalué à 8.
  
  En fait l'origine du terme malicieux est la même : le malin, le diable, est malfaisant... et malicieux.
  
  Etre malicieux dans un sens plus ancien, c'était donc associé à une certaine malfaisance -- quoi que pas nécessairement si péjorativement connoté. Mais cette connotation péjorative est moindre en Français, de nos jours.
  - [^] # Re: Soyons précis dans nos traductions, merci.
    
    Posté par dinomasque le 01 octobre 2003 à 13:49. Évalué à 2.
    
    "cette connotation péjorative est moindre en Français, de nos jours."
    
    Je trouve que c'est donc une bonne idée de parler de "programmes malicieux" pour remettre ce terme au goût du jour.
    BeOS le faisait il y a 20 ans !
    - [^] # Re: Soyons précis dans nos traductions, merci.
      
      Posté par imr le 01 octobre 2003 à 16:16. Évalué à 2.
      
      A la vérité, c'est raison qu'on fasse grande différence entre les fautes qui viennent de notre faiblesse, et celles qui viennent de notre malice.
      
      |\/|0N7A19N3, m4d sk1ll3D h4x0r'Z w1k1 4b0u7 b4k4^2 14m3rz & 814cK H47
# en passant

Posté par passant·e le 01 octobre 2003 à 15:20. Évalué à 3.

éxécuter ça le fait pas trop... exécuter c'est plus mieux...
Je trolle dès quand ça parle business, sécurité et sciences sociales
# Re: Vulnérabilités dans OpenSSL

Posté par yoho (site web personnel) le 02 octobre 2003 à 12:33. Évalué à 1.

Et FreeS/WAN dépend-il d'OpenSSL ? Si c'est le cas, c'est super grave pour mon réseau !
- [^] # Re: Vulnérabilités dans OpenSSL
  
  Posté par Moby-Dik le 03 octobre 2003 à 01:47. Évalué à 2.
  
  Et FreeS/WAN dépend-il d'OpenSSL ?
  
  Un petit ldd devrait te donner la réponse.
  
  Si c'est le cas, c'est super grave pour mon réseau !
  
  Quoi, t'as encore tâché ton kimono, et t'as une compète demain ?

Suivre le flux des commentaires

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