In GNU Emacs von lsp-mode zu Eglot wechseln

 (utcc.utoronto.ca)
1 Punkte von GN⁺ 1 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Teile von Wandering Thoughts und CSpace zeigen eine Blockierungsseite an, wenn veraltete Browser-User-Agents von Regeln zur Abwehr von Crawlern erfasst werden
  • Anfang 2025 hat die Zahl massenhafter Crawler zugenommen; einige scheinen der Datensammlung für LLM-Training zu dienen und verwenden veraltete Chrome-User-Agents
  • Um die Last auf der Website zu verringern, wird testweise das Blockieren veralteter Browser-User-Agents eingesetzt; dabei kann es auch zu False Positives bei legitimen Nutzern kommen
  • Wenn die Blockierung selbst in einem aktuellen Browser auftritt, kann man über die persönliche Seite der University of Toronto Kontakt aufnehmen und sollte den Browser sowie den genauen User-Agent-String mitsenden
  • Bei Diensten der archive.*-Familie ist wegen veralteter Chrome-User-Agents und verteilter IPs eine Unterscheidung schwierig; für das Archivieren von Wandering Thoughts wird archive.org empfohlen

Warum eine Blockierungsseite angezeigt wird

  • Beim Zugriff auf Wandering Thoughts oder Teile von CSpace wird eine Blockierungsseite angezeigt, wenn die Browserversion von den Anti-Crawler-Regeln der Website als verdächtig eingestuft wird
  • Anfang 2025 hat die Zahl massenhafter Crawler zugenommen; einige scheinen zur Datensammlung für LLM-Training zu dienen und verwenden neben veralteten Chrome-User-Agents auch andere veraltete Browser-User-Agents
  • Um die Last auf der Website zu verringern, läuft ein Experiment zum Blockieren veralteter Browser-User-Agents; dabei können auch legitime Nutzer von diesen Regeln erfasst werden
  • Wer einen aktuellen Browser verwendet und trotzdem blockiert wird, kann über die persönliche Seite der University of Toronto Kontakt aufnehmen und sollte möglichst den verwendeten Browser sowie den genauen User-Agent-String mitsenden

Hinweise für einzelne Nutzergruppen

  • Für Inoreader-Nutzer

    • Der Feed-Abrufdienst von Inoreader selbst ist nicht Ziel der Blockierung und ruft die Feeds tatsächlich regelmäßig ab
    • Inoreader kann Feeds oder Seiten jedoch mit einem veralteten Browser-HTTP-User-Agent oder einem tatsächlich veralteten Browser abrufen und den dabei erhaltenen Blockierungsinhalt anschließend dem Nutzer anzeigen
    • Die Ergebnisse aktueller HTTP-Anfragen können je nach verwendetem HTTP-User-Agent unterschiedlich ausfallen; Details dazu stehen unter HTTPResultsAndUserAgents

  • Für Vivaldi-Nutzer

    • Wegen laufender Angriffe kann auch ein aktueller Vivaldi blockiert werden, wenn er als Google Chrome identifiziert wird
    • Möglicherweise muss die Einstellung "User Agent Brand Masking" geändert werden, damit Vivaldi als Vivaldi und nicht als Google Chrome erkannt wird

  • Für archive.*-Nutzer

    • Über archive.today, archive.ph, archive.is usw. kann diese Blockierungsseite sichtbar werden
    • archive.* verwendet veraltete Chrome-User-Agents, crawlt aus breit verteilten IP-Blöcken, und einige IPs besitzen gefälschte Reverse-DNS-Einträge, die vorgeben, googlebot-IP-Adressen zu sein; dadurch ist eine Abgrenzung zu böswilligen Akteuren schwierig
    • Zum Archivieren von Wandering Thoughts wird die Nutzung von archive.org empfohlen, dessen Archiv-Crawler besser funktioniert

Verwandte Beiträge

1 Kommentare

 
GN⁺ 1 시간 전
Lobste.rs-Kommentare

  • Je nach Sprache kann der Ratschlag, Eglot automatisch zu starten, fatal schlecht sein. Die LSP-Server vieler Sprachen lassen sich nicht sicher mit nicht vertrauenswürdigem Code verwenden, und schon das Öffnen von Dateien in einem von Angreifern kontrollierten Rust- oder Elixir-Projekt kann den eigenen Rechner kompromittieren
    Wenn es sich nicht um eine Sprache mit einem als sicher bekannten LSP-Server handelt, sollte man LSP nicht automatisch aktivieren. Quelle: https://rust-analyzer.github.io/book/security.html

    • Wenn man potenziell feindseligen Code betrachtet, sollte man letztlich die gesamte Arbeit innerhalb einer echten Sicherheitsgrenze erledigen. Selbst git status kann eine Angriffsfläche sein: https://github.com/justinsteven/advisories/…
      Der Unterschied ist, dass im obigen Fall das Exploit im Repository selbst vorhanden sein muss, während bei LSP auch die Abhängigkeitsseite Probleme verursachen kann. Wenn man sich aber daran gewöhnt, LSP gewohnheitsmäßig einzuschalten, dürfte es schwer sein zu verhindern, gegenüber Warnungen abstumpft
    • Ein weiterer Grund, automatischen Start zu vermeiden, sind die hohen Ressourcenanforderungen mancher Sprachserver. Schon wenn man in einem mittelgroßen Rust-Projekt nur kurz eine Datei öffnet, kann ein rust-analyzer-Prozess mit 4 GB mehrere Minuten laufen, und es kann ein target/debug/-Verzeichnis von über 1 GB entstehen
    • Sobald man ohnehin cargo build ausgeführt hat, ist es im Grunde schon vorbei. Natürlich gibt es einen großen Unterschied zwischen automatischem Laden von LSP und einem Befehl, den der Benutzer explizit ausführt, aber in der Praxis könnte der Unterschied kleiner sein als gedacht
    • Wenn man Automatisierung möchte, ist es besser, wie bei lsp-mode vor der Aktivierung zu fragen und das Projekt in eine Allowlist aufzunehmen. Wenn es bereits einen Hook gibt, der etwas „automatisch ausführt“, kann man mit read-from-minibuffer in etwa 10 Zeilen zuerst „Vertrauen Sie diesem Ordner?“ abfragen, und wenn man mit etwas wie projectile ein Basisverzeichnis festlegt, bekommt man den Großteil des Sicherheitsgewinns
      In meiner Konfiguration nutze ich die Allowlist von lsp-mode, lösche sie aber pro Sitzung, sodass ich bei jedem Neustart von Emacs projektspezifisch erneut zustimmen muss. Ursprünglich habe ich das wohl aus Performancegründen so gemacht, und es kam vor, dass lsp-mode mehrere Prozesse startete, noch bevor ein bestimmtes Projekt überhaupt geöffnet war. Das Sicherheitsrisiko ist real, aber einen brauchbaren Workflow zu bauen ist nicht besonders schwer

  • Was an Eglot am meisten stört, ist, dass die meisten Befehle nicht als Funktionen offengelegt werden, sondern über Emacs-Schnittstellen wie xref definiert sind. Wenn es wie bei Clojure sowohl ein xref-Backend von CIDER als auch von clojure-lsp gibt, bevorzuge ich die Seite von CIDER, weil sie den tatsächlichen Laufzeitzustand des geladenen Codes kennt
    Die statische Analyse von clojure-lsp kann besonders in Remote-REPL-Workflows aus dem Tritt geraten. In lsp-mode kann man Funktionen wie „Gehe zu Definition“ direkt als Befehl aufrufen und xref trotzdem weiter nutzen, aber in Eglot ist es ziemlich umständlich, nur ein bestimmtes xref-Backend auszuschließen. Andere Befehle aus lsp-mode fehlen in Eglot ebenfalls, obwohl es eigentlich Funktionen sind, die sich über ähnliche Emacs-Integrationspunkte wie xref bereitstellen ließen

  • Ich habe lsp-mode einmal ausprobiert, aber die verwirrenden Pop-ups und Benachrichtigungen waren so zahlreich, dass ich es sofort wieder gelöscht habe. Eglot bietet eine deutlich ruhigere LSP-Erfahrung
    Man lässt es einfach aktiviert und nutzt die Funktionen, wenn man bereit ist. Interessant ist, wie ~cks aus der entgegengesetzten Richtung an die Sache herangeht und verschiedene Tipps und Alternativen erwähnt

    • Ich verwende lsp-mode, habe aber viele Funktionen abgeschaltet und damit eine ziemlich ruhige Oberfläche. Ich wollte zu Eglot wechseln, habe es dann aber nicht weiter verfolgt, weil die gewünschte Integration zu fehlen schien
      Was ich wirklich suche, ist ein LSP-Server, der sehr große Repositories bewältigen kann. Das war oft die eigentliche Grenze, und ich frage mich, ob ich etwas bauen sollte, das die Quellcode-Indizierung einmalig weitgehend erledigt und dann für verschiedene LSP-artige Aufgaben wiederverwendet, aber ich habe Sorge, damit nur ein weiteres Meer zum Kochen bringen zu wollen

  • Als LSP-Clients für Emacs sind Eglot und lsp-mode die bekanntesten, aber es gibt auch Alternativen wie lspce und lsp-bridge
    Ich nutze Eglot seit einigen Jahren zufrieden, aber es gibt eine architekturbedingte Einschränkung, die künftig problematischer werden könnte. Es geht von einem Client pro Buffer aus; als Eglot entstand, war das plausibel, aber inzwischen wird es immer üblicher, mehrere LSP-Server in einem Buffer laufen lassen zu wollen. Die aktuelle Empfehlung ist, ein separates Programm als LSP-Multiplexer zu verwenden

    • Dafür gibt es this

  • Ich bin vor 4 Tagen für Python von lsp-mode zu Eglot gewechselt und zufrieden
    Hier habe ich die Minimalversion meiner aktuellen Konfiguration veröffentlicht: https://discuss.afpy.org/t/configuration-emacs-minimale-en-2026/3001

    • Vor fast einem Jahr bin ich von elpy zu eglot + basedpyright gewechselt, und ich bin ebenfalls ziemlich zufrieden
      Bei der Vervollständigung gibt es allerdings Unannehmlichkeiten. Wenn ich zum Beispiel foo<tab><tab> drücke, importiert basedpyright manchmal etwas Seltsames automatisch, obwohl es im aktuellen Scope ein passendes Symbol gibt, und ich habe noch keinen Weg gefunden, nur bis zur längsten gemeinsamen Zeichenfolge zu vervollständigen. Davon abgesehen ist es ziemlich gut

  • Ich beneide Leute, die Emacs wie eine moderne IDE nutzen. Ich verwende zwar Emacs-Keybindings, aber selbst nach 6 bis 8 Stunden bekomme ich Emacs nicht dazu, sich wie eine IDE zu verhalten
    Früher wollte ich es für Linux- und FreeBSD-Entwicklungsumgebungen auf FB Flow abstimmen, das ich anstelle von TypeScript genutzt habe, und habe aufgegeben; letztes Wochenende habe ich dann erneut aufgegeben, als ich unter Windows eine voll ausgestattete Python-Umgebung mit tree-sitter aufbauen wollte. Es gibt einfach zu viel zu konfigurieren, und man muss zusätzlich zu viele DLLs wie tree-sitter-Parser herunterladen, sodass der Aufwand bis zu einer richtigen IDE unverhältnismäßig wirkt. Inzwischen möchte ich dafür keine Zeit mehr investieren, aber es ist trotzdem schön, wenn in irgendeinem Terminal nach emacs -nw die vertraute Bearbeitungsumgebung erscheint

    • Für Python kann man schon mit einer Minimal-Konfiguration wie fido-vertical-mode, which-key-mode, global-completion-preview-mode, yasnippet, eglot-ensure und basedpyright gut loslegen
      Wenn basedpyright im Pfad liegt, bekommt man auch ohne tree-sitter-Grammatik ordentliche Vervollständigung und Syntaxhervorhebung. Das ist eine auf das Minimum reduzierte Version meiner Gesamtkonfiguration; die vollständige Konfiguration steht in my full config
    • doom emacs ist einen Blick wert. Die Konfiguration ist sehr einfach, und schon im Standardzustand funktioniert das meiste gut. Wenn einem evil-mode nicht gefällt, kann man auch wieder zu Emacs-Keybindings zurückkehren