Passer de lsp-mode à Eglot dans GNU Emacs

 (utcc.utoronto.ca)
1 points par GN⁺ 2 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Certaines parties de Wandering Thoughts et de CSpace affichent une page de blocage si un User-Agent de navigateur obsolète déclenche les règles anti-crawler
  • Début 2025, le nombre de crawlers massifs a augmenté ; certains semblent destinés à la collecte de données pour l’entraînement de LLM et utilisent d’anciens User-Agent de Chrome
  • Pour réduire la charge sur le site, un test de blocage des User-Agent de navigateurs obsolètes est en cours, et des utilisateurs légitimes peuvent aussi être bloqués par erreur
  • Si le blocage se produit même avec un navigateur récent, il est possible de contacter l’auteur via sa page personnelle à l’Université de Toronto, en envoyant le navigateur utilisé et la chaîne exacte du User-Agent
  • La famille archive.* est difficile à distinguer en raison d’anciens User-Agent de Chrome et d’IP distribuées ; pour les archives de Wandering Thoughts, archive.org est recommandé

Pourquoi la page de blocage s’affiche

  • Lors de l’accès à Wandering Thoughts ou à certaines parties de CSpace, une page de blocage s’affiche si la version du navigateur est classée comme suspecte par les règles anti-crawler du site
  • Début 2025, les crawlers massifs se sont multipliés ; certains semblent destinés à la collecte de données pour l’entraînement de LLM et utilisent plusieurs anciens User-Agent de navigateur, dont d’anciens User-Agent de Chrome
  • Une expérimentation de blocage des User-Agent de navigateurs obsolètes est en cours pour réduire la charge du site, mais des utilisateurs légitimes peuvent aussi être touchés par cette règle
  • Si vous utilisez un navigateur récent et êtes tout de même bloqué, vous pouvez prendre contact via la page personnelle à l’Université de Toronto et, si possible, indiquer le navigateur utilisé ainsi que la chaîne exacte du User-Agent

Informations selon les utilisateurs

  • Utilisateurs d’Inoreader

    • Le collecteur de flux d’Inoreader n’est pas lui-même visé par le blocage et récupère bien les flux régulièrement
    • Inoreader peut toutefois récupérer un flux ou une page avec un ancien User-Agent HTTP de navigateur, ou avec un navigateur réellement obsolète, puis afficher à l’utilisateur la page de blocage obtenue en résultat
    • Le résultat des requêtes HTTP récentes peut varier selon le User-Agent HTTP utilisé ; plus d’informations ici : HTTPResultsAndUserAgents

  • Utilisateurs de Vivaldi

    • En raison de l’attaque en cours, même la version récente de Vivaldi peut être bloquée si elle est identifiée comme Google Chrome
    • Il peut être nécessaire de modifier le paramètre "User Agent Brand Masking" pour que Vivaldi soit identifié comme Vivaldi et non comme Google Chrome

  • Utilisateurs de archive.*

    • Cette page de blocage peut apparaître via archive.today, archive.ph, archive.is, etc.
    • archive.* utilise d’anciens User-Agent de Chrome, explore depuis de larges plages d’IP distribuées, et certaines IP disposent d’entrées DNS inversées falsifiées prétendant être des IP de googlebot, ce qui rend la distinction difficile avec des acteurs malveillants
    • Pour archiver Wandering Thoughts, il est recommandé d’utiliser archive.org, dont le crawler d’archivage fonctionne mieux

À lire aussi

1 commentaires

 
GN⁺ 2 시간 전
Commentaires de Lobste.rs

  • Selon le langage, conseiller de lancer Eglot automatiquement peut être dangereux au plus haut point. Les serveurs LSP de nombreux langages ne peuvent pas être utilisés en toute sécurité avec du code non fiable, et le simple fait d’ouvrir les fichiers d’un projet Rust ou Elixir contrôlé par un attaquant peut compromettre la machine
    À moins qu’il s’agisse d’un langage dont le serveur LSP est connu pour être sûr, il faut éviter l’activation automatique du LSP. Référence : https://rust-analyzer.github.io/book/security.html

    • Si l’on examine du code potentiellement hostile, il faut au final faire tout le travail à l’intérieur d’une véritable frontière de sécurité. Même git status peut constituer une surface d’attaque : https://github.com/justinsteven/advisories/…
      La différence est que, dans ce cas, l’exploit doit être présent dans le dépôt lui-même, alors qu’avec le LSP, le problème peut aussi venir des dépendances. Cela dit, si on s’habitue à activer le LSP par réflexe, il semble difficile d’éviter de devenir moins sensible aux avertissements
    • Une autre raison d’éviter le démarrage automatique est que certains serveurs de langage ont des exigences élevées en ressources. Sur un projet Rust de taille moyenne, le simple fait d’ouvrir brièvement un fichier peut lancer un processus rust-analyzer de 4 Go pendant plusieurs minutes et créer un répertoire target/debug/ de plus de 1 Go
    • De toute façon, à partir du moment où on exécute cargo build, c’est déjà plié. Bien sûr, il y a une grande différence entre le chargement automatique du LSP et une commande lancée explicitement par l’utilisateur, mais en pratique l’écart est parfois plus faible qu’on ne l’imagine
    • Si l’on veut de l’automatisation, il vaut mieux adopter l’approche de lsp-mode : demander avant l’activation et ajouter le projet à une liste d’autorisation. S’il existe déjà un hook qui « exécute automatiquement », il suffit d’une dizaine de lignes avec read-from-minibuffer pour demander d’abord « Faites-vous confiance à ce dossier ? », et en prenant un répertoire de référence avec quelque chose comme projectile, on obtient l’essentiel des bénéfices en matière de sécurité
      Dans ma configuration, j’utilise la liste d’autorisation de lsp-mode, mais je l’efface à chaque session, de sorte qu’il faut redonner son accord projet par projet à chaque redémarrage d’Emacs. Au départ, je crois que j’ai fait ça pour des raisons de performance, car lsp-mode lançait parfois plusieurs processus avant même d’ouvrir un projet donné. Le risque de sécurité est réel, mais mettre en place un workflow correct n’est pas si difficile

  • Ce qui m’agace le plus dans Eglot, c’est qu’il n’expose pas la plupart de ses commandes comme fonctions et les définit plutôt sur des interfaces Emacs comme xref. Quand on a deux backends xref, par exemple CIDER et clojure-lsp en Clojure, on a tendance à préférer CIDER, qui connaît l’état d’exécution réel du code chargé
    L’analyse statique de clojure-lsp peut notamment être désynchronisée, surtout dans un workflow REPL distant. Avec lsp-mode, on peut appeler directement des fonctionnalités comme aller à la définition tout en continuant à utiliser xref, mais avec Eglot, exclure seulement un backend xref particulier est assez pénible. D’autres commandes présentes dans lsp-mode manquent aussi dans Eglot, alors qu’en réalité ce sont des fonctionnalités qui pourraient être fournies via des points d’intégration Emacs similaires à xref

  • J’ai essayé lsp-mode une fois, mais je l’ai supprimé immédiatement à cause du trop grand nombre de pop-ups et de notifications confuses. Eglot offre une expérience LSP bien plus discrète
    On peut le laisser activé et utiliser les fonctionnalités quand on est prêt. Il est intéressant de voir ~cks adopter l’approche inverse tout en mentionnant divers conseils et alternatives

    • J’utilise lsp-mode avec beaucoup de fonctionnalités désactivées, ce qui donne une interface assez discrète. J’ai envisagé de passer à Eglot, mais il ne semblait pas offrir les intégrations que je voulais, donc je n’ai pas poussé plus loin à l’époque
      Ce que je cherche vraiment, c’est un serveur LSP capable de gérer des dépôts très volumineux. C’est souvent là que j’atteins la limite, et je me demande parfois s’il ne faudrait pas créer quelque chose qui fasse l’essentiel de l’indexation du code source en une fois pour le réutiliser dans diverses opérations de type LSP, mais j’ai peur de vouloir encore faire bouillir l’océan

  • Eglot et lsp-mode sont les clients LSP les plus connus pour Emacs, mais il existe aussi des alternatives comme lspce et lsp-bridge
    J’utilise Eglot avec satisfaction depuis plusieurs années, mais il présente une limite de conception qui pourrait devenir plus problématique à l’avenir. Il part du principe qu’il n’y a qu’un client par buffer ; c’était raisonnable au moment de sa création, mais aujourd’hui il devient de plus en plus courant de vouloir faire tourner plusieurs serveurs LSP dans un même buffer. La [recommandation] actuelle est d’utiliser un programme séparé comme multiplexeur LSP

    • Il y a aussi this pour ça

  • Je suis passé de lsp-mode à Eglot pour Python il y a 4 jours, et j’en suis satisfait
    J’ai publié ici une version minimale de ma configuration actuelle : https://discuss.afpy.org/t/configuration-emacs-minimale-en-2026/3001

    • Il y a presque un an, je suis passé d’elpy à eglot + basedpyright, et j’en suis aussi plutôt content
      J’ai tout de même quelques frustrations côté complétion. Par exemple, quand j’appuie sur foo<tab><tab>, basedpyright auto-importe parfois quelque chose d’étrange alors qu’un symbole pertinent existe déjà dans la portée actuelle, et je n’ai pas encore trouvé comment ne compléter que jusqu’à la plus longue sous-chaîne commune. À part ça, c’est plutôt bien

  • J’envie les gens qui arrivent à faire d’Emacs un IDE moderne. J’utilise les raccourcis Emacs, mais même en y consacrant 6 à 8 heures, je n’arrive pas à transformer Emacs en IDE
    J’avais déjà renoncé autrefois en essayant de l’adapter à FB Flow, que j’utilisais à la place de TypeScript dans des environnements de développement Linux et FreeBSD, et le week-end dernier j’ai encore abandonné en tentant de monter sous Windows un environnement Python complet avec tree-sitter. Il y a trop de choses à configurer, et il faut aussi récupérer séparément trop de DLL, comme les parseurs tree-sitter, si bien que l’effort requis pour obtenir quelque chose d’équivalent à un vrai IDE est excessif. Je n’ai plus envie d’y consacrer du temps, mais j’aime toujours le fait qu’en tapant emacs -nw dans n’importe quel terminal, je retrouve un environnement d’édition familier

    • Pour Python, une configuration minimale avec fido-vertical-mode, which-key-mode, global-completion-preview-mode, yasnippet, eglot-ensure et basedpyright suffit largement pour démarrer
      Si basedpyright est présent dans le PATH, on obtient une vraie complétion et une coloration syntaxique correcte même sans grammaire tree-sitter. C’est une version réduite au minimum de ma configuration complète, et celle-ci est disponible dans my full config
    • doom emacs vaut le coup d’œil. La configuration est très simple et, même par défaut, la plupart des choses fonctionnent bien. Si evil-mode ne vous convient pas, vous pouvez aussi revenir aux raccourcis Emacs