Stéphane Bortzmeyer a écrit 655 commentaires

Notez qu'il y a une discussion (critique) de cet article et surtout de ses commentaires sur SeenThis http://seenthis.net/messages/154404

Une très bonne analyse juridique, montrant notamment que l'avocate de Linkeo ne s'y connait pas mieux en droit que Linkeo en sites Web.

Non, les URI "ni" ne sont pas forcément des URL. Ils peuvent l'être (si on met l'autorité) mais ce n'est pas obligatoire.

Et le but est justement de faire mieux que les URN. Ceux-ci ne sont pas « actionnables », on ne peut pas s'en servir pour récupérer une ressource. C'est bien pour cela que les URN ont eu peu de succès en pratique. (Avant les "ni", il y avait eu une proposition de faire la même chose avec des URN, draft-thiemann-hash-urn, mais elle n'avait pas abouti.)

L'article de l'Usine Nouvelle est médiocre. Il s'attaque à une exagération (fin de l'Internet, on va tous mourir) pour passer à une autre (il ne s'est rien passé, tout a été inventé, on vous ment).

La réalité est sans doute plus simple mais apparemment trop nuancée pour certains : il y a bien eu une attaque de grande ampleur, elle a impacté Cloudflare et donc ses clients, le reste de l'Internet a continué à vivre. Et le marketeux de Cloudflare a trouvé malin d'exagérer (exagérer, pas inventer) pour rapporter du business à sa boîte.

Google, ce ne sont pas des tanches. Oui, ils connaissaient le problème et ont documenté leurs solutions :

https://developers.google.com/speed/public-dns/docs/security

Et après, il se moque de M. Michu qui a mis son courrier chez Gmail ? Pas très cohérent.

Cf. la discussion sur le DNS dans l'article de départ (très intéressant, cet article). Évidemment, si on active le service de courrier électronique, le logiciel mettra un MX dans la zone. Évidemment, si on active le service de messagerie instantanée, il mettra un SRV dans la zone.

J'ai quand même un peu l'impression (arrêtez-moi si je me trompe) que pas mal de gens qui commentent n'ont pas lu l'article de départ.

Je n'ai jamais envisagé comme unique solution l'hébergement à la maison, avec un ADSL lent et une adresse marquée comme "résidentielle". J'ai au contraire longuement détaillé l'autre possibilité, celle d'un hébergement sur une machine d'un fournisseur IaaS. Le problème de l'adresse IP disparait, dans ce cas (ainsi que plusieurs autres répétés ici).

Il ne fait apparemment que serveur de fichiers et blog (pas courrier ou IM).

Je comprends cette motivation, je suis pareil :-) Mais la fiabilité et la sécurité d'une machine peu administrée nécessitent une politique plus restrictive. (Après, les hackers pourront toujours faire ce qu'ils veulent, c'est du logiciel libre. Mais il faut que ce soit clairement dit que ce n'est pas le fonctionnement normal.)

Non, je ne pense pas qu'il faille connaître la différence entre SMTP et IMAP. On ne parle pas d'apprendre le courrier, ni de fournir un service pour une grosse organisaton dépendant fortement du courrier pour son activité. On parle de permettre à M. Michu d'avoir du courrier électronique sans vendre son âme à Gmail.

Il me semble qu'un bouton « Activer le service de courrier électronique » devrait suffire. Le logiciel doit ensuite démarrer Postfix et Courier, mettre ce qu'il faut dans le DNS. et hop. Bien sûr, ce n'est pas aussi simple, il y a des pièges mais je ne vois pas de raison pour lesquelles il faudrait comprendre SMTP et IMAP.

Faut se demander pourquoi les trucs bâtis par les hackers ne sont pas utilisés, alors…

Pour l'intégration à Debian, je ne suis pas du tout convaincu. Les cahiers des charges sont trop opposés. Par exemple, la solution d'hébergement doit être robuste et cela veut dire qu'il ne faut pas permettre d'installer des programmes supplémentaires (sinon, vous imaginez le cauchemar pour le déboguage).

Utiliser Debian comme base serait certainement un bon choix technique. Mais cela n'implique pas de s'intégrer au Debian « officiel ».

Je suis preneur de plus de détails sur les NAS en question. Sans même parler de leur licence (beaucoup sont des boîtes noires), il y en a vraiment qui font le courrier, la messagerie instantanée, le blog, et tout ce qui fait une "présence en ligne" ?

FreedomBox est loin d'être prête. Et puis, ce n'est pas sur le même créneau : c'est moitié client et moitié serveur, et ça met surtout l'accent sur l'ultra-sécurité (chiffrement, routage en oignon, etc).

NSEC3 est normalisé dans le RFC 5155 et n'est pas du tout un "certificat de révocation". Une introduction en français à NSEC3 : http://www.bortzmeyer.org/5155.html badfe11a n'est pas un hash mais un sel.

Il manque l'URL :-) http://www.redfoxcenter.org/Internet/index.html ?

LISP peut aussi être déployé sur des sites finaux.

Sans tunnels, il existe d'autres solutions, comme ILNP http://www.bortzmeyer.org/6740.html mais qui ne sont pas soutenues par de gros acteurs (ILNP, comme HIP, vient du monde des machines terminales, LISP du monde des routeurs ; pas le même point de vue).

Quant à l'encapsulation dans UDP, on voit bien que vous n'avez jamais essayé de déployer un nouveau protocole de transport (indications : middleboxes, pare-feux).

Il n'y a pas de crypto dans LISP-the-protocol :-)

Si mais s'ils réagissent tous aussi mal que l'auteur de libcurl, ça promet…

Plus précisement (parce que Stenberg nie bêtement le problème, en jouant sur les mots et en prétendant qu'il n'y a pas de paramètres booléens dans libcurl), le paramètre est un long (libcurl n'utilise effectivement pas bool) mais qui prend deux valeurs, 0 pour "non" et 1 pour "oui". C'est donc un quasi-booléen et l'erreur des programmeurs qui ont passé "true" à une autre fonction de libcurl est tout à fait excusable (même si BFG les prend de haut).

Le problème n'est donc pas dans cURL, mais bien chez les développeurs qui ne lisent pas les documentations

Avec une telle mentalité, on aura encore des failles de sécurité pendant longtemps. Peut-être que les abonnés à LinuxFr ne mettent jamais de bogues dans leurs programmes mais, dans le monde réel, avec les contraintes de délai et le PHB qui demande qu'on livre le code avant-hier, les bogues arrivent. Comme le rappelle très justement Gof dans son commentaire, le rôle d'une API n'est pas de tendre des pièges subtils, pour pouvoir ricaner ensuite de l'incompétence des programmeurs qui sont tombés dedans, c'est de rendre l'erreur difficile.

qui à mon avis cherchent à faire du sensationnel plein de superlatifs

Je ne sais pas ce qu'il vous faut : des dizaines de programmes vulnérables à une attaque triviale (et pas des petits scripts PHP écrits par Jean-Kevin Boulet dans son coin pour son usage personnel, non des codes utilisés par des dizaines de milliers de gens pour des usages critiques, par exemple du paiement en ligne), et ça ne vous suffit pas ?

C'est un obstacle qu'on rencontre souvent dans le monde du logiciel privateur, le vendeur qui nie les failles de sécurité parce que cela le gonfle de corriger. Apparemment, ce mal frappe aussi le logiciel libre.

Non, Stenberg ne dit pas ça du tout. Il dit que lui n'a pas été contacté (rappelons que libcurl n'avait pas de faille).

Désolé, mais c'est vrai. Les auteurs de libcurl n'ont pas été contactés tout simplement parce qu'il n'y a pas à proprement parler de faille dans libcurl, juste une API dangereuse.