Stéphane Bortzmeyer a écrit 690 commentaires

Des exemples du HOSTS.TXT de l'époque sont cités en https://www.bortzmeyer.org/608.html

J'ai demandé à la BnF, qui me confirme que LinuxFr est bien archivé au titre du dépôt légal du Web, et depuis 2005.

Je retrouve cet article, qui a l'air assez WTF https://linuxfr.org/users/gniarf/journaux/souriez-cest-archiv%C3%A9-long

personne ou presque ne code de logiciel utile avec ça

Marrant, j'avais justement cité des exemples.

Oui, si quelqu'un prétend que tous les langages sont équivalents, je vais lui demander de recoder un programme Lisp en Rust… (Ou un programme en langage d'assemblage vers Prolog, si je suis de mauvaise humeur.) Par exemple, si on écrit un programme qui doit traiter beaucoup de requêtes réseau (un serveur DNS faisant autorité, par exemple), on ne gérera pas du tout pareil en C (où on fera sans doute par événements, par exemple avec libevent) et en Elixir (où on utilisera les processus de la VM Erlang - qui n'ont rien à voir avec les processus du système d'exploitation). Les deux programmes seront alors radicalement différents. (Et je ne parle pas de la gestion des erreurs, qui est là aussi sans comparaison possible entre C et Elixir.)

En effet, cela vaut la peine de parler de programmation parallèle car c'est une des grandes forces d'Elixir.

Des exemples de programmes réels écrits en Elixir : Pleroma, Mobilizon, CertStream…

Et on peut aussi faire du DNS (là, le parallélisme est crucial, sans lui, Elixir a nettement moins d'intérêt).

Une des idées à l'origine d'Elixir est en effet de faire du Erlang (pour profiter de son parallélisme et de sa machine virtuelle) mais avec une syntaxe proche de Ruby (celle d'Erlang est horrible).

Projet abandonné.

me demandais d'ailleurs si unbound avait hard-codé la liste des serveurs de .org, .net et autres, en oubliant les serveurs racines).

Non (et ce serait une drôle d'idée, ce ne sont pas ces TLD qui sont menacés par une éventuelle redélégation hostile).

Plus clairement, dans la config de la carte réseau, on peut indiquer plusieurs serveurs DNS.

Résolveurs (il faut éviter de dire « serveur DNS » tout court, les résolveurs et les serveurs faisant autorité sont deux bêtes très différentes).

Est-ce que ça marcherait d'indiquer l'adresse du Pi-Hole en premier puis celui du fournisseur d'accès en second au cas où le premier est hors-service ?

Non. Le timeout de la glibc est beaucoup trop long. Il faudrait plutôt un relais local, avec répartition des requêtes (par exemple dnsdist) qui est justement conçu pour cela.

La Freebox, oui mais, à ma connaissance, la Livebox d'Orange et sans doute d'autres ne permettent pas de changer de résolveur (« c'est pour la sécuritay ! »).

C'est même pas écrit en Rust, ce truc.

LATIN SMALL LIGATURE LONG S WITH DESCENDER S (U+1DF95) ? Je ne comprends pas le drama.

Et il faut toujours rappeler un principe de base d'Unicode : la priorité n'est pas de faciliter la vie des programmeurs mais de respecter les écritures existantes, même si les informaticiens auraient tout voulu réformer.

Non, pas supprimé (cf. mon article).

Comme l'explique mon article, ce sont les serveurs faisant autorité pour autistici.org qui ne donnent plus la réponse, changer de résolveur ne change donc rien.

« Le NDD c'est un détail, ça se change. »

Ben voyons. Il faut juste faire corriger tous les liens hypertexte qui sont partout sur le Web et dans les articles, tous les signets dans tous les navigateurs qui l'ont enregistré, tous les carnets d'adresses pour le courrier…

Je suis étonné qu'il n'y ait encore aucune faille nommée Hantavirus.

Sauf que des gens ont supprimé le contournement (le dirtyfrag.conf) une fois le noyau mis à jour (par exemple les gens qui avaient besoin d'IPsec).

Notez que le POC ne marche ni avec Debian, ni avec Kali. https://www.bortzmeyer.org/fragnesia.html

Et rappelons-le un million de fois : CopyFrag et DirtyFail ne nécessitent PAS de shell pour être exploités.

Attention, accès local ne veut pas dire un compte avec un shell et un mot de passe et qu'on se connecte en SSH. Ça peut vouloir dire aussi un démon non privilégié mais bogué (comme Apache cette semaine ou comme certainement beaucoup de scripts PHP).

Attention, c'est faux. Même si les modules ne sont pas chargés, la machine est vulnérable. (Ils sont chargés par le programme d'exploitation.)

https://dirtyflag.io/

Si on veut des explications techniques détaillées : https://thecybersecguru.com/news/dirty-frag-linux-kernel-root-vulnerability/

Les noyaux mis à jour viennent d'arriver dans Debian.

Encore mieux, appliquer le contournement documenté par les découvreurs de la faille, 'echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf'

https://wiki.debian.org/fr/KernelModuleBlacklisting explique bien pourquoi blacklist ne marche pas.

L'une des meilleures est la contribution commune CZ-NIC/ISC/NLnetLabs (et un quatrième que je ne connais pas) : https://www.isc.org/blogs/open-digital-ecosystem-response/