GNU Emacsでlsp-modeからEglotへ移行する

 (utcc.utoronto.ca)
1 ポイント 投稿者 GN⁺ 1 시간 전 | 1件のコメント | WhatsAppで共有
  • Wandering Thoughts と CSpace の一部では、古いブラウザの User-Agent がクローラー対策ルールに引っかかるとブロックページが表示される
  • 2025年初頭以降、大量クローラーが増加しており、その一部は LLM 学習用データ収集 を目的としているように見え、古い Chrome User-Agent を使用している
  • サイト負荷を減らすため、古いブラウザの User-Agent をブロックする実験を行っており、正規ユーザーも誤検知される可能性がある
  • 最新ブラウザでもブロックされる場合はトロント大学の個人ページから連絡でき、その際はブラウザ名と正確な User-Agent 文字列 を送る必要がある
  • archive.* 系は古い Chrome User-Agent と分散 IP のため判別が難しく、Wandering Thoughts のアーカイブには archive.org が推奨される

ブロックページが表示される理由

  • Wandering Thoughts や CSpace の一部にアクセスした際、ブラウザのバージョンがサイトのクローラー対策ルールで疑わしいと判定されると、ブロックページが表示される
  • 2025年初頭時点で大量クローラーが増えており、その一部は LLM 学習用データ収集を目的としているように見え、古い Chrome User-Agent を含む複数の古いブラウザ User-Agent を使用している
  • サイト負荷を減らすため、古いブラウザ User-Agent をブロックする実験が進められており、正規ユーザーもこのルールに引っかかる可能性がある
  • 最新ブラウザを使っているのにブロックされる場合は、トロント大学の個人ページ から連絡でき、可能であれば使用中のブラウザ名と正確な User-Agent 文字列 をあわせて送る必要がある

ユーザー別の参考事項

  • Inoreader ユーザー

    • Inoreader のフィード取得機能 自体はブロック対象ではなく、実際にフィードを定期的に取得している
    • Inoreader が古いブラウザの HTTP User-Agent や実際に古いブラウザでフィードまたはページを取得したあと、その結果として受け取ったブロックページをユーザーに表示することがある
    • 最新の HTTP リクエスト結果は使用された HTTP User-Agent によって異なる場合があり、関連内容は HTTPResultsAndUserAgents にある

  • Vivaldi ユーザー

    • 進行中の攻撃のため、最新の Vivaldi であっても Google Chrome と識別されるとブロックされる可能性がある
    • Vivaldi が Google Chrome ではなく Vivaldi と識別されるよう、"User Agent Brand Masking" 設定 を変更する必要があるかもしれない

  • archive.* ユーザー

    • archive.today、archive.ph、archive.is などを通じてこのブロックページを見ることがある
    • archive.* は古い Chrome User-Agent を使い、広く分散した IP ブロックからクロールし、一部の IP は googlebot IP を名乗る偽の逆引き DNS エントリを持っているため、悪意ある行為者と区別しにくい
    • Wandering Thoughts をアーカイブするなら、より適切に動作するアーカイブクローラーである archive.org の利用が推奨される

関連記事

1件のコメント

 
GN⁺ 1 시간 전
Lobste.rsの意見

  • 言語によっては、Eglot を自動起動する助言は 致命的に危険になりうる。多くの言語の LSP サーバーは信頼できないコードに対して安全に使えるようにはできておらず、攻撃者が制御する Rust や Elixir のプロジェクトのファイルを開いただけでマシンが侵害される可能性がある
    安全だと知られている LSP サーバーがある言語でない限り、LSP の自動有効化は避けるべき。根拠: https://rust-analyzer.github.io/book/security.html

    • 悪意がありうるコードを見るなら、結局は作業全体を 実際のセキュリティ境界 の内側で行う必要がある。git status でさえ攻撃対象領域になりうる: https://github.com/justinsteven/advisories/…
      違いは、上の事例ではリポジトリ自体にエクスプロイトが存在する必要があるのに対し、LSP では依存関係側でも問題が起きうる点。それでも、習慣的に LSP を有効にすることに慣れてしまうと、警告に鈍感になるのを防ぐのは難しそうだ
    • 自動起動を避けるべきもう一つの理由は、一部の言語サーバーの リソース要求量 が大きいこと。中規模の Rust プロジェクトでファイルを少し開いただけでも、4GB の rust-analyzer プロセスが数分間動作し、1GB を超える target/debug/ ディレクトリが作られることがある
    • どうせ cargo build を実行した時点で、もう同じようなものではある。もちろん LSP の自動ロード と、ユーザーが明示的に実行したコマンドには大きな違いがあるが、実際の利用では思ったより差が小さいかもしれない
    • 自動化したいなら、lsp-mode のように有効化前に確認し、プロジェクトを 許可リスト に追加する方式のほうがよい。すでに「自動実行」するフックがあるなら、read-from-minibuffer で先に「このフォルダを信頼しますか？」と尋ねるようにするのは 10 行程度ででき、projectile のようなもので基準ディレクトリを決めればセキュリティ上の利点の大半を得られる
      自分の設定では lsp-mode の許可リストを使いつつセッションごとに消去しており、Emacs を再起動するたびにプロジェクトごとに再同意が必要になる。もともとは性能のためにそうしていた気がする。lsp-mode が特定のプロジェクトを開く前から複数のプロセスを立ち上げることがあったからだ。セキュリティ上のリスクは現実的だが、妥当なワークフローを作るのはそれほど難しくない

  • Eglot でいちばん気になるのは、大半のコマンドを関数として公開せず、xref のような Emacs インターフェース の上に定義していること。Clojure のように CIDER と clojure-lsp の両方の xref バックエンドがある場合、読み込まれたコードの実際のランタイム状態を知っている CIDER 側を優先したくなる
    clojure-lsp の静的解析は、とくにリモート REPL ワークフローでは同期がずれることがある。lsp-mode では定義ジャンプのような機能をコマンドとして直接呼び出しつつ xref も使い続けられるが、Eglot では特定の xref バックエンドだけを外すのがかなり面倒だ。lsp-mode にある他のコマンドも Eglot には欠けているが、実際には xref に似た Emacs 統合ポイントを通じて提供できる機能だ

  • lsp-mode を一度使ってみたが、ややこしいポップアップや通知が多すぎてすぐ消した。Eglot はずっと 静かな LSP 体験 を提供してくれる
    有効にしておいて、準備ができた時に機能を使えばいい。~cks が逆方向からアプローチしつつ、いろいろなヒントや代案に触れているのが興味深い

    • lsp-mode では多くの機能をオフにして、かなり静かなインターフェースとして使っている。Eglot へ移ろうとしたが、欲しい統合機能がなさそうに見えたので、その時はそれ以上試さなかった
      本当に探したいのは 非常に大きなリポジトリ を扱える LSP サーバーだ。これがしばしば限界として現れ、ソースの索引付けを一度に大半処理してから複数の LSP 的な作業に再利用するものを作るべきかと思うが、また別の大海を沸かそうとしているのではないかと心配になる

  • Emacs 用 LSP クライアントとしては Eglot と lsp-mode が最も有名だが、lspce や lsp-bridge のような代替もある
    Eglot を数年間満足して使ってきたが、今後さらに問題になりうる 設計上の限界 がある。バッファごとにクライアント 1 つを前提としているのだが、Eglot が作られた当時は妥当でも、今では 1 つのバッファで複数の LSP サーバーを動かしたいケースがますます一般的になっている。現在の recommendation は、別プログラムを LSP マルチプレクサのように使うことだ

    • その用途には this がある

  • 4 日前に Python 用として lsp-mode から Eglot に移行し、満足している
    現在の設定の最小版をここで公開した: https://discuss.afpy.org/t/configuration-emacs-minimale-en-2026/3001

    • ほぼ 1 年前に elpy から eglot + basedpyright に切り替えた が、自分もかなり満足している
      ただし補完まわりには不満がある。たとえば foo<tab><tab> を押すと、現在のスコープに合うシンボルがあるのに basedpyright が妙なものを自動 import してしまうことがあり、最長共通文字列までだけ補完する方法もまだ見つけられていない。それ以外はかなり良い

  • Emacs をモダンな IDE のように使える人たちがうらやましい。Emacs キーバインドは使っているが、6〜8 時間かけても Emacs を IDE のように動かせなかった
    昔、Linux と FreeBSD の開発環境で TypeScript の代わりに使っていた FB Flow に合わせようとして諦め、先週末には Windows で tree-sitter を添えたフル機能の Python 環境を作ろうとしてまた諦めた。設定することが多すぎるし、tree-sitter パーサーのような DLL も別途たくさん入手しなければならず、まともな IDE のようにするまでに必要なものが多すぎる。もう時間を投資したくはないが、ときどきどの端末でも emacs -nw と打てば慣れた編集環境が出てくるのは良い

    • Python なら、fido-vertical-mode、which-key-mode、global-completion-preview-mode、yasnippet、eglot-ensure、basedpyright くらいの 最小構成 で十分に始められる
      basedpyright がパスに入っていれば、tree-sitter の文法なしでもちゃんとした補完と構文ハイライトが得られる。全体設定から最小限に削った版で、完全な設定は my full config にある
    • doom emacs を試してみるといい。設定がとても簡単で、デフォルト状態でも大半がうまく動く。evil-mode が気に入らなければ Emacs キーバインド に戻すこともできる