Erwan David , dans le message , a
écrit :J'attends ta soilution où tu ne fais aucune confiance ni à aucune
racine DNS, ni à aucun routage sur internet
Je l'ai déjà donnée : vérification des clefs par des autorités AU CHOIX DE
L'UTILISATEUR.
Et avant ça ton modèle de risque : de quoi exactement tu veux te
protéger. Parceque là vu ce que tu insinue je pense que ton modèle c'est
"personne n'est digne de confiance, touit le monde fait tout et plus
contre moi"
Non, absolument pas. Mon modèle, c'est celui où chacun décide à qui il fait
confiance, tout simplement. Si tu veux faire confiance aux clefs racines du
DNS, c'est ton droit. Mais si le modèle impose que tout le monde fasse
confiance à ces clefs, le modèle est pourri.
Erwan David , dans le message <871tss26ro.fsf@tee.rail.eu.org>, a
écrit :
J'attends ta soilution où tu ne fais aucune confiance ni à aucune
racine DNS, ni à aucun routage sur internet
Je l'ai déjà donnée : vérification des clefs par des autorités AU CHOIX DE
L'UTILISATEUR.
Et avant ça ton modèle de risque : de quoi exactement tu veux te
protéger. Parceque là vu ce que tu insinue je pense que ton modèle c'est
"personne n'est digne de confiance, touit le monde fait tout et plus
contre moi"
Non, absolument pas. Mon modèle, c'est celui où chacun décide à qui il fait
confiance, tout simplement. Si tu veux faire confiance aux clefs racines du
DNS, c'est ton droit. Mais si le modèle impose que tout le monde fasse
confiance à ces clefs, le modèle est pourri.
Erwan David , dans le message , a
écrit :J'attends ta soilution où tu ne fais aucune confiance ni à aucune
racine DNS, ni à aucun routage sur internet
Je l'ai déjà donnée : vérification des clefs par des autorités AU CHOIX DE
L'UTILISATEUR.
Et avant ça ton modèle de risque : de quoi exactement tu veux te
protéger. Parceque là vu ce que tu insinue je pense que ton modèle c'est
"personne n'est digne de confiance, touit le monde fait tout et plus
contre moi"
Non, absolument pas. Mon modèle, c'est celui où chacun décide à qui il fait
confiance, tout simplement. Si tu veux faire confiance aux clefs racines du
DNS, c'est ton droit. Mais si le modèle impose que tout le monde fasse
confiance à ces clefs, le modèle est pourri.
Nicolas George <nicolas$ écrivait :
Non, absolument pas. Mon modèle, c'est celui où chacun décide à qui il fait
confiance, tout simplement. Si tu veux faire confiance aux clefs racines du
DNS, c'est ton droit. Mais si le modèle impose que tout le monde fasse
confiance à ces clefs, le modèle est pourri.
Modèle de RISQUES: quelles menaces veux-tu éviter ?
Ton modèle n'est pas un modèle : ce sqont des idées lancées sans
réflexion sur l'implémentation ni même sur les vrais besoins
Nicolas George <nicolas$george@salle-s.org> écrivait :
Non, absolument pas. Mon modèle, c'est celui où chacun décide à qui il fait
confiance, tout simplement. Si tu veux faire confiance aux clefs racines du
DNS, c'est ton droit. Mais si le modèle impose que tout le monde fasse
confiance à ces clefs, le modèle est pourri.
Modèle de RISQUES: quelles menaces veux-tu éviter ?
Ton modèle n'est pas un modèle : ce sqont des idées lancées sans
réflexion sur l'implémentation ni même sur les vrais besoins
Nicolas George <nicolas$ écrivait :
Non, absolument pas. Mon modèle, c'est celui où chacun décide à qui il fait
confiance, tout simplement. Si tu veux faire confiance aux clefs racines du
DNS, c'est ton droit. Mais si le modèle impose que tout le monde fasse
confiance à ces clefs, le modèle est pourri.
Modèle de RISQUES: quelles menaces veux-tu éviter ?
Ton modèle n'est pas un modèle : ce sqont des idées lancées sans
réflexion sur l'implémentation ni même sur les vrais besoins
Bon jour je voudrais que la claf de ma banque soit véfiée par l'autorité
machin dont ma banque n'a jamais entendu parler.
Tu le fais comment ?
PS: tu es donc autorité, après tout tu me demnades de ne pas faire
confiance au DNS, pourquoi ferais-je confiance à une quelconque autorité ?
Modèle de RISQUES: quelles menaces veux-tu éviter ?
Bon jour je voudrais que la claf de ma banque soit véfiée par l'autorité
machin dont ma banque n'a jamais entendu parler.
Tu le fais comment ?
PS: tu es donc autorité, après tout tu me demnades de ne pas faire
confiance au DNS, pourquoi ferais-je confiance à une quelconque autorité ?
Modèle de RISQUES: quelles menaces veux-tu éviter ?
Bon jour je voudrais que la claf de ma banque soit véfiée par l'autorité
machin dont ma banque n'a jamais entendu parler.
Tu le fais comment ?
PS: tu es donc autorité, après tout tu me demnades de ne pas faire
confiance au DNS, pourquoi ferais-je confiance à une quelconque autorité ?
Modèle de RISQUES: quelles menaces veux-tu éviter ?
Non, absolument pas. Mon modèle, c'est celui où chacun décide à qui il
fait confiance, tout simplement. Si tu veux faire confiance aux clefs
racines du DNS, c'est ton droit. Mais si le modèle impose que tout le
monde fasse confiance à ces clefs, le modèle est pourri.
Non, absolument pas. Mon modèle, c'est celui où chacun décide à qui il
fait confiance, tout simplement. Si tu veux faire confiance aux clefs
racines du DNS, c'est ton droit. Mais si le modèle impose que tout le
monde fasse confiance à ces clefs, le modèle est pourri.
Non, absolument pas. Mon modèle, c'est celui où chacun décide à qui il
fait confiance, tout simplement. Si tu veux faire confiance aux clefs
racines du DNS, c'est ton droit. Mais si le modèle impose que tout le
monde fasse confiance à ces clefs, le modèle est pourri.
Le Thu, 07 Aug 2014 10:02:07 +0000, Nicolas George a écrit :Non, absolument pas. Mon modèle, c'est celui où chacun décide à qui il
fait confiance, tout simplement. Si tu veux faire confiance aux clefs
racines du DNS, c'est ton droit. Mais si le modèle impose que tout le
monde fasse confiance à ces clefs, le modèle est pourri.
Ce que tu préconises, c'est de revenir à l'époque de l'APRANET, de se
fader la maintenance de /etc/hosts et de known_hosts à la pogne... C'est
juste irréaliste en pratique sur un réseau actuel un peu conséquent :
rien que le SI d'une grosse entreprise actuelle est plus complexe est
important que ne l'était ARPANET à ses débuts !
Le Thu, 07 Aug 2014 10:02:07 +0000, Nicolas George a écrit :
Non, absolument pas. Mon modèle, c'est celui où chacun décide à qui il
fait confiance, tout simplement. Si tu veux faire confiance aux clefs
racines du DNS, c'est ton droit. Mais si le modèle impose que tout le
monde fasse confiance à ces clefs, le modèle est pourri.
Ce que tu préconises, c'est de revenir à l'époque de l'APRANET, de se
fader la maintenance de /etc/hosts et de known_hosts à la pogne... C'est
juste irréaliste en pratique sur un réseau actuel un peu conséquent :
rien que le SI d'une grosse entreprise actuelle est plus complexe est
important que ne l'était ARPANET à ses débuts !
Le Thu, 07 Aug 2014 10:02:07 +0000, Nicolas George a écrit :Non, absolument pas. Mon modèle, c'est celui où chacun décide à qui il
fait confiance, tout simplement. Si tu veux faire confiance aux clefs
racines du DNS, c'est ton droit. Mais si le modèle impose que tout le
monde fasse confiance à ces clefs, le modèle est pourri.
Ce que tu préconises, c'est de revenir à l'époque de l'APRANET, de se
fader la maintenance de /etc/hosts et de known_hosts à la pogne... C'est
juste irréaliste en pratique sur un réseau actuel un peu conséquent :
rien que le SI d'une grosse entreprise actuelle est plus complexe est
important que ne l'était ARPANET à ses débuts !
Ce que tu préconises, c'est de revenir à l'époque de l'APRANET, de se
fader la maintenance de /etc/hosts et de known_hosts à la pogne...
Ce que tu préconises, c'est de revenir à l'époque de l'APRANET, de se
fader la maintenance de /etc/hosts et de known_hosts à la pogne...
Ce que tu préconises, c'est de revenir à l'époque de l'APRANET, de se
fader la maintenance de /etc/hosts et de known_hosts à la pogne...
Le 08 Aug 2014 08:44:39 GMT,
Eric Belhomme <rico-{nntp}@ricozome.net> écrivait :
> Le Thu, 07 Aug 2014 10:02:07 +0000, Nicolas George a écrit :
>
>> Non, absolument pas. Mon modèle, c'est celui où chacun décide à qui il
>> fait confiance, tout simplement. Si tu veux faire confiance aux clefs
>> racines du DNS, c'est ton droit. Mais si le modèle impose que tout l e
>> monde fasse confiance à ces clefs, le modèle est pourri.
>
> Ce que tu préconises, c'est de revenir à l'époque de l'APRANET, d e se
> fader la maintenance de /etc/hosts et de known_hosts à la pogne... C' est
> juste irréaliste en pratique sur un réseau actuel un peu conséque nt :
> rien que le SI d'une grosse entreprise actuelle est plus complexe est
> important que ne l'était ARPANET à ses débuts !
Le problème est que tu réagis comme quelqu'un qui se fade les
problèmes pratiques et pas comme un théoricien de génie incompris.
Le 08 Aug 2014 08:44:39 GMT,
Eric Belhomme <rico-{nntp}@ricozome.net> écrivait :
> Le Thu, 07 Aug 2014 10:02:07 +0000, Nicolas George a écrit :
>
>> Non, absolument pas. Mon modèle, c'est celui où chacun décide à qui il
>> fait confiance, tout simplement. Si tu veux faire confiance aux clefs
>> racines du DNS, c'est ton droit. Mais si le modèle impose que tout l e
>> monde fasse confiance à ces clefs, le modèle est pourri.
>
> Ce que tu préconises, c'est de revenir à l'époque de l'APRANET, d e se
> fader la maintenance de /etc/hosts et de known_hosts à la pogne... C' est
> juste irréaliste en pratique sur un réseau actuel un peu conséque nt :
> rien que le SI d'une grosse entreprise actuelle est plus complexe est
> important que ne l'était ARPANET à ses débuts !
Le problème est que tu réagis comme quelqu'un qui se fade les
problèmes pratiques et pas comme un théoricien de génie incompris.
Le 08 Aug 2014 08:44:39 GMT,
Eric Belhomme <rico-{nntp}@ricozome.net> écrivait :
> Le Thu, 07 Aug 2014 10:02:07 +0000, Nicolas George a écrit :
>
>> Non, absolument pas. Mon modèle, c'est celui où chacun décide à qui il
>> fait confiance, tout simplement. Si tu veux faire confiance aux clefs
>> racines du DNS, c'est ton droit. Mais si le modèle impose que tout l e
>> monde fasse confiance à ces clefs, le modèle est pourri.
>
> Ce que tu préconises, c'est de revenir à l'époque de l'APRANET, d e se
> fader la maintenance de /etc/hosts et de known_hosts à la pogne... C' est
> juste irréaliste en pratique sur un réseau actuel un peu conséque nt :
> rien que le SI d'une grosse entreprise actuelle est plus complexe est
> important que ne l'était ARPANET à ses débuts !
Le problème est que tu réagis comme quelqu'un qui se fade les
problèmes pratiques et pas comme un théoricien de génie incompris.
Eric Belhomme , dans le message
<53e48df7$0$2385$, a écrit :
> Ce que tu préconises, c'est de revenir à l'époque de l'APRANET, de
> se fader la maintenance de /etc/hosts et de known_hosts à la
> pogne...
Non, absolument pas. Il vaudrait mieux que tu lises mes propres propos
plutôt que l'interprétation déformée qu'en fait mon anti-fan
auto-proclamé.
Ce que je préconise (dans l'absolu, pas comme plan de transition
depuis la situation actuelle, c'est) :
- Considérer un changement de clef comme un événement notable, que la
nouvelle clef soit certifiée ou non. Si un site change de clef, il
devrait émettre un avis (à un endroit et sous une forme standardisée,
pour que le navigateur sache où la chercher), si possible signé par
l'ancienne et nouvelle clef, expliquant les raisons. Évidemment, si
la raison est une compromission de l'ancienne, la signature n'apporte
aucune sécurité, mais le changement de clef est de toutes façons un
événement qui requiert l'attention d'un utilisateur prudent.
- Ne pas lier la clef à un certificat et une autorité de
certification. Les garanties offertes par les autorités de
certification en place sont dérisoires et essentiellement inutiles,
et pour le visiteur du site, que la clef soit signée par Thawte
plutôt que Verisign parce que Thawte avait une promo intéressante au
moment où le site a été mis en place, ça lui fait une belle jambe.
- À la place, publier la clef sur un ou plusieurs répertires fiables,
calqués sur ceux déjà utilisés actuellement pour détecter les sites
malveillants (le fameux « urlclassifier » de Firefox).
- Permettre aux sites de fournir un miroir de leur entrée ces
répertoires, de manière à éviter le blocage en cas de souci réseau.
Ce que je décris là est strictement supérieur à la situation
actuelle. En effet, toutes les fonctionnalités actuelles restent
possibles : l'achat d'un certificat chez Thawte ou Verisign devient
l'achat d'une place dans le répertoire de Thawte ou Verisign ; la
publication de la clef par le DNS est inchangée. Voilà pour
l'égalité, quant à l'inégalité stricte, voici les avantages de ce que
je décris par rapport à la situation actuelle :
- Réduire le nombre de points uniques de compromission :
actuellement, si on a acheté un certificat à Thawte et que Thawte se
fait compromettre, on est fichu jusqu'à ce que la compromission soit
détectée. Si on a la même clef publiée en même temps sur le
répertoire fiable maintenu par la fondation Mozilla et celui maintenu
par Google, il faudrait que les trois soient compromis en même temps
pour que ce soit un problème. Et ce n'est pas grave si on n'aime pas
la fondation Mozilla ou Google, parce qu'on n'a pas besoin de leur
faire confiance.
- Permettre l'existence de répertoires offrant de meilleures
garanties que la simple correspondance avec le DNS.
Le principe existe déjà de manière artisanale. Je prends un exemple
dont j'ai entendu parler récemment : quelqu'un qui voudrait acheter
quelques microgrammes de dimethylazetidide d'acide lysergique. Malgré
la parfaite légalité de la transaction dans la plupart des pays
civilisés, faire valoir ses droits dans ce genre de situation est
difficile, donc les sites escrocs pullulent. Il existe cependant des
sites spécialisés qui recensent les vendeurs de ce genre de produits,
avec des commentaires des utilisateurs décrivant leur sérieux et leur
honnêteté de manière très systématique.
L'architecture que je préconise permettrait l'apparition de
répertoires crowdsourcés beaucoup plus répandus sur ce modèle.
- Même au niveau commercial, l'architecture que je préconise présente
des avantages. Par exemple, on pourrait imaginer un répertoire qui
fasse office d'assurance : l'inscription pour le consulter est
payante, mais en contrepartie, si on a des problèmes commerciaux avec
un site garanti par ce répertoire, on est dédommagé.
En ce qui concerne une éventuelle transition par rapport à la
situation actuelle, ce n'est pas non plus un gros problème. La
première chose à faire serait de créer des répertoires gratuits ou
crowdsourcés et d'intégrer leur consultation dans les navigateurs en
plus de l'architecture actuelle. C'est quelque chose d'assez facile
pour une entité qui a de la visibilité.
Eric Belhomme , dans le message
<53e48df7$0$2385$426a34cc@news.free.fr>, a écrit :
> Ce que tu préconises, c'est de revenir à l'époque de l'APRANET, de
> se fader la maintenance de /etc/hosts et de known_hosts à la
> pogne...
Non, absolument pas. Il vaudrait mieux que tu lises mes propres propos
plutôt que l'interprétation déformée qu'en fait mon anti-fan
auto-proclamé.
Ce que je préconise (dans l'absolu, pas comme plan de transition
depuis la situation actuelle, c'est) :
- Considérer un changement de clef comme un événement notable, que la
nouvelle clef soit certifiée ou non. Si un site change de clef, il
devrait émettre un avis (à un endroit et sous une forme standardisée,
pour que le navigateur sache où la chercher), si possible signé par
l'ancienne et nouvelle clef, expliquant les raisons. Évidemment, si
la raison est une compromission de l'ancienne, la signature n'apporte
aucune sécurité, mais le changement de clef est de toutes façons un
événement qui requiert l'attention d'un utilisateur prudent.
- Ne pas lier la clef à un certificat et une autorité de
certification. Les garanties offertes par les autorités de
certification en place sont dérisoires et essentiellement inutiles,
et pour le visiteur du site, que la clef soit signée par Thawte
plutôt que Verisign parce que Thawte avait une promo intéressante au
moment où le site a été mis en place, ça lui fait une belle jambe.
- À la place, publier la clef sur un ou plusieurs répertires fiables,
calqués sur ceux déjà utilisés actuellement pour détecter les sites
malveillants (le fameux « urlclassifier » de Firefox).
- Permettre aux sites de fournir un miroir de leur entrée ces
répertoires, de manière à éviter le blocage en cas de souci réseau.
Ce que je décris là est strictement supérieur à la situation
actuelle. En effet, toutes les fonctionnalités actuelles restent
possibles : l'achat d'un certificat chez Thawte ou Verisign devient
l'achat d'une place dans le répertoire de Thawte ou Verisign ; la
publication de la clef par le DNS est inchangée. Voilà pour
l'égalité, quant à l'inégalité stricte, voici les avantages de ce que
je décris par rapport à la situation actuelle :
- Réduire le nombre de points uniques de compromission :
actuellement, si on a acheté un certificat à Thawte et que Thawte se
fait compromettre, on est fichu jusqu'à ce que la compromission soit
détectée. Si on a la même clef publiée en même temps sur le
répertoire fiable maintenu par la fondation Mozilla et celui maintenu
par Google, il faudrait que les trois soient compromis en même temps
pour que ce soit un problème. Et ce n'est pas grave si on n'aime pas
la fondation Mozilla ou Google, parce qu'on n'a pas besoin de leur
faire confiance.
- Permettre l'existence de répertoires offrant de meilleures
garanties que la simple correspondance avec le DNS.
Le principe existe déjà de manière artisanale. Je prends un exemple
dont j'ai entendu parler récemment : quelqu'un qui voudrait acheter
quelques microgrammes de dimethylazetidide d'acide lysergique. Malgré
la parfaite légalité de la transaction dans la plupart des pays
civilisés, faire valoir ses droits dans ce genre de situation est
difficile, donc les sites escrocs pullulent. Il existe cependant des
sites spécialisés qui recensent les vendeurs de ce genre de produits,
avec des commentaires des utilisateurs décrivant leur sérieux et leur
honnêteté de manière très systématique.
L'architecture que je préconise permettrait l'apparition de
répertoires crowdsourcés beaucoup plus répandus sur ce modèle.
- Même au niveau commercial, l'architecture que je préconise présente
des avantages. Par exemple, on pourrait imaginer un répertoire qui
fasse office d'assurance : l'inscription pour le consulter est
payante, mais en contrepartie, si on a des problèmes commerciaux avec
un site garanti par ce répertoire, on est dédommagé.
En ce qui concerne une éventuelle transition par rapport à la
situation actuelle, ce n'est pas non plus un gros problème. La
première chose à faire serait de créer des répertoires gratuits ou
crowdsourcés et d'intégrer leur consultation dans les navigateurs en
plus de l'architecture actuelle. C'est quelque chose d'assez facile
pour une entité qui a de la visibilité.
Eric Belhomme , dans le message
<53e48df7$0$2385$, a écrit :
> Ce que tu préconises, c'est de revenir à l'époque de l'APRANET, de
> se fader la maintenance de /etc/hosts et de known_hosts à la
> pogne...
Non, absolument pas. Il vaudrait mieux que tu lises mes propres propos
plutôt que l'interprétation déformée qu'en fait mon anti-fan
auto-proclamé.
Ce que je préconise (dans l'absolu, pas comme plan de transition
depuis la situation actuelle, c'est) :
- Considérer un changement de clef comme un événement notable, que la
nouvelle clef soit certifiée ou non. Si un site change de clef, il
devrait émettre un avis (à un endroit et sous une forme standardisée,
pour que le navigateur sache où la chercher), si possible signé par
l'ancienne et nouvelle clef, expliquant les raisons. Évidemment, si
la raison est une compromission de l'ancienne, la signature n'apporte
aucune sécurité, mais le changement de clef est de toutes façons un
événement qui requiert l'attention d'un utilisateur prudent.
- Ne pas lier la clef à un certificat et une autorité de
certification. Les garanties offertes par les autorités de
certification en place sont dérisoires et essentiellement inutiles,
et pour le visiteur du site, que la clef soit signée par Thawte
plutôt que Verisign parce que Thawte avait une promo intéressante au
moment où le site a été mis en place, ça lui fait une belle jambe.
- À la place, publier la clef sur un ou plusieurs répertires fiables,
calqués sur ceux déjà utilisés actuellement pour détecter les sites
malveillants (le fameux « urlclassifier » de Firefox).
- Permettre aux sites de fournir un miroir de leur entrée ces
répertoires, de manière à éviter le blocage en cas de souci réseau.
Ce que je décris là est strictement supérieur à la situation
actuelle. En effet, toutes les fonctionnalités actuelles restent
possibles : l'achat d'un certificat chez Thawte ou Verisign devient
l'achat d'une place dans le répertoire de Thawte ou Verisign ; la
publication de la clef par le DNS est inchangée. Voilà pour
l'égalité, quant à l'inégalité stricte, voici les avantages de ce que
je décris par rapport à la situation actuelle :
- Réduire le nombre de points uniques de compromission :
actuellement, si on a acheté un certificat à Thawte et que Thawte se
fait compromettre, on est fichu jusqu'à ce que la compromission soit
détectée. Si on a la même clef publiée en même temps sur le
répertoire fiable maintenu par la fondation Mozilla et celui maintenu
par Google, il faudrait que les trois soient compromis en même temps
pour que ce soit un problème. Et ce n'est pas grave si on n'aime pas
la fondation Mozilla ou Google, parce qu'on n'a pas besoin de leur
faire confiance.
- Permettre l'existence de répertoires offrant de meilleures
garanties que la simple correspondance avec le DNS.
Le principe existe déjà de manière artisanale. Je prends un exemple
dont j'ai entendu parler récemment : quelqu'un qui voudrait acheter
quelques microgrammes de dimethylazetidide d'acide lysergique. Malgré
la parfaite légalité de la transaction dans la plupart des pays
civilisés, faire valoir ses droits dans ce genre de situation est
difficile, donc les sites escrocs pullulent. Il existe cependant des
sites spécialisés qui recensent les vendeurs de ce genre de produits,
avec des commentaires des utilisateurs décrivant leur sérieux et leur
honnêteté de manière très systématique.
L'architecture que je préconise permettrait l'apparition de
répertoires crowdsourcés beaucoup plus répandus sur ce modèle.
- Même au niveau commercial, l'architecture que je préconise présente
des avantages. Par exemple, on pourrait imaginer un répertoire qui
fasse office d'assurance : l'inscription pour le consulter est
payante, mais en contrepartie, si on a des problèmes commerciaux avec
un site garanti par ce répertoire, on est dédommagé.
En ce qui concerne une éventuelle transition par rapport à la
situation actuelle, ce n'est pas non plus un gros problème. La
première chose à faire serait de créer des répertoires gratuits ou
crowdsourcés et d'intégrer leur consultation dans les navigateurs en
plus de l'architecture actuelle. C'est quelque chose d'assez facile
pour une entité qui a de la visibilité.
Ça veut dire que ton navigateur envoie une requête à ces répertoires
pour tous les sites que tu visites, non ?
Ça veut dire que ton navigateur envoie une requête à ces répertoires
pour tous les sites que tu visites, non ?
Ça veut dire que ton navigateur envoie une requête à ces répertoires
pour tous les sites que tu visites, non ?
Bonjour,
Comment contrecarrer cette faille sous Linux ?
http://www.01net.com/editorial/624728/l-usb-victime-d-une-faille-de-securite-beante-et-impossible-a-corriger/
Merci
Ptilou
Bonjour,
Comment contrecarrer cette faille sous Linux ?
http://www.01net.com/editorial/624728/l-usb-victime-d-une-faille-de-securite-beante-et-impossible-a-corriger/
Merci
Ptilou
Bonjour,
Comment contrecarrer cette faille sous Linux ?
http://www.01net.com/editorial/624728/l-usb-victime-d-une-faille-de-securite-beante-et-impossible-a-corriger/
Merci
Ptilou
