GitHub：ログインなしではコード検索が不可能に

 (github.com/orgs)
1 ポイント 投稿者 GN⁺ 2023-11-29 | 1件のコメント | WhatsAppで共有
  • GitHub Community のディスカッションで、公開リポジトリのコード検索もログインなしでは使えなくなった点が問題として提起され、質問者は公開コードのアクセシビリティとオープンソースの活用性を損なうと批判
  • GitHub のメンテナーは、リポジトリ全体を対象にした検索は以前からログインが必要で、2023年初めに検索機能を強化した際に個別リポジトリ検索にもログイン要件を拡大したと回答
  • GitHub 側の理由は、開発者向け検索の負荷に対応し、ボットなどによる匿名リクエストでサーバーが圧倒される状況を減らすため
  • ディスカッション参加者は、公開リポジトリは依然として clone 後にローカル検索できるため、ログイン要件がボット対策として十分なのか疑問を呈し、rate limit・CAPTCHA・単純検索の制限といった代替案に言及
  • 実務上は、非ログインユーザーが公開コード検索リンクを直接開けなくなるため、grep.app、github1s、ローカルの grep、一般検索エンジン、複数の Git forge へのミラーリングといった回避策もあわせて議論された

公開コード検索にログイン要件が適用

  • GitHub Community Discussion #77046 は「Can no longer search code without being logged in」というタイトルで、ログインなしではコード検索ができない状況を扱っている
  • 質問者は、古いデバイスで自分たちのリポジトリ内の何かを検索しようとしたが、ログイン要件のため進められなかったと説明
    • パスワードマネージャーにアクセスする必要があり、2FA と YubiKey が必要で、古いノート PC に USB-C ポートがなかったため行き詰まったという
    • 公開リポジトリのコード検索を人々が使えるようにしたかったと述べている
  • 質問者は、公開リポジトリであれば clone 後に専用ツールで検索や分析が可能なので、Web のコード検索にログイン要件を設ける理由は納得しにくいと批判
  • このディスカッションは GitHub 側の回答により Answered として処理され、ページには19件のコメントと58件の返信が表示されている

GitHub 側の回答と公式根拠

  • GitHub メンテナーの martinwoodward は不便を謝罪しつつ、リポジトリ全体を対象にした検索は以前からログインが必要だったと回答
  • 2023年初めに検索機能を強化した際、個別リポジトリ検索にもログイン要件を拡大したと説明
  • 主な目的は、GitHub の開発者向け検索の負荷を支え、ボットなどによる匿名リクエストでサーバーが圧倒されるのを防ぐことだと述べている
  • ディスカッション中、別の参加者は GitHub の新しいコード検索実装を扱った The technology behind GitHub’s new code search のリンクを提示

反発の核心：公開リポジトリとオープンソースのアクセシビリティ

  • 複数の参加者は、公開リポジトリのコードはログインなしで clone できるため、公開コード検索までログインで遮断する措置は過剰だと見ている
  • ある参加者は、外部ユーザーが自分の公開ソースを見るために GitHub へのログインを強制される点が不便だと説明
    • 例として repo:USER/REPO、path:...、AND NOT path:**/_externals のような検索クエリを、単一の URL やボタンで共有したかったという
    • ログイン要件のため、複数の直接ファイル URL の一覧で代替しなければならないと述べている
  • 別の参加者たちは、GitHub が「world's largest open source community」を掲げていることと、公開コード検索の制限との間の緊張を指摘
  • 一部のコメントは、Microsoft による買収前から似た制限があったと記憶しており、この制限が完全に新しいものではないと反論

ボット対策とコストをめぐる議論

  • GitHub 側は匿名ボットリクエストによる負荷を理由に挙げたが、一部の参加者はログイン要件では専用ボットの運用者を防ぎにくいと主張
  • 代替案として、まず rate limit を適用し、上限に達した時点で CAPTCHA やログインを求める方式が提案された
  • 公開リポジトリは匿名 clone が可能なため、ボットがローカル検索に切り替えられるという反論も出た
    • これに対し、別の参加者は clone は GitHub の検索コンピューティングを使わないため、サービス拒否ベクトルを減らす趣旨だと反論
    • clone されたデータはすぐに stale になり得るとの指摘もあった
  • 検索コストが大きいなら、単純なクエリはよりシンプルな方式で非ログインユーザーに提供し、複雑なクエリはログインユーザーに提供するという切り分け案も提案された

検索機能自体の制約と比較事例

  • ある参加者は、ログイン状態でも path:contributing.md で全公開リポジトリを検索すると、5ページ分しか結果が出ないと言及
    • 別の参加者は、これは特定クエリだけの問題ではなく現在の検索の制限であり、関連ディスカッションとして GitHub Community Discussion #9868 に言及
  • 別の参加者は SourceForge、Google Code archive、GitLab、Bitbucket の検索動作を比較
    • SourceForge と Google Code archive には検索がないという
    • GitLab は全体検索にログインが必要で、リポジトリ別検索は可能だという
    • Bitbucket の検索はログインへリダイレクトされるが、リポジトリを見つければログインなしで検索可能だという

回避方法と代替サービス

  • 非ログイン状態で単一リポジトリを素早く検索する方法として、ローカルに clone して grep を使う手順が提示された
    • /dev/shm に移動
    • git clone https://github.com/user/repo
    • リポジトリへ移動後、grep -r "pattern" .
    • 検索後にリポジトリを削除
  • GitHub 全体を対象にしたパターン検索には、一般検索エンジンで "pattern" site:github.com を使う方法が言及された
    • ただし GitHub 内蔵検索ほど強力ではなく、一部のコードはインデックスされていない可能性があるという限界も示された
  • 代替または補助ツールとして grep.app が言及され、ログインなしでリポジトリ検索ができると紹介された
  • GitHub URL で github.com の代わりに github1s.com を使うと、オンライン VS Code 形式でリポジトリを開けるという Tips も共有された
  • 代替 Git forge として GitLab、Framagit、Gitea、Forgejo、Codeberg、Gogs などが言及され、一部は self-host 時にコード検索を有効化できるという

プロジェクトのホスティング方法に関する助言

関連記事

1件のコメント

 
GN⁺ 2023-11-29
Hacker Newsの意見

  • この件を最大限好意的に見るなら、新しい GitHub Code Search は実際に使ってみると非常に優れていて、一般的な検索エンジンよりも内部でずっと多くの処理を行うため、リソースを大量に消費する機能なのかもしれない
    ログイン済みアカウントに制限すれば、クローラー処理に使われていたはずのサーバーリソースを大幅に節約できる。ここでのトレードオフは、検索インフラのコストを3〜4倍以上かけるのか、それともログイン必須にして非難を浴びるのか、というものに近く見える。自分でも GitHub リポジトリ向けのコード検索ツールを作ったが、標準の GitHub Code Search があまりに便利なので、ほとんど使わなくなった: https://simonwillison.net/2020/Nov/28/datasette-ripgrep/

    • 最も現実的な理由は、人々がいら立ちながらも結局アカウントを作り、GitHub が 新規ユーザー増加 をアピールできる、という方向に見える
      逆に既存ユーザーは、ログインなしでは検索すらできず腹を立てる可能性がある。他人のPC、共用PC、シークレットタブ、2段階認証にかかる時間といった状況ではかなり面倒だ。GitHub はログインしていないユーザー向けに安価で高速な基本検索を残すこともできたはずだが、そうしなかった
    • 技術的な理由は興味深いが、本質ではない
      結果として GitHubに登録しない限り、「GitHubでホストされているオープンソース」に参加できなくなった
    • いろいろな理由が挙がっているが、実際には AI関連企業や研究者によるコンテンツのスクレイピング を避けたい、あるいは避けなければならないからである可能性が高そうだ
    • 意図的にやっているのだとしたら Microsoft は本当に最悪だし、単なる無能なら、こんな簡単なことすら台無しにしたのは驚きではない
      grep は50年前のツールであり、テキスト検索のために自前でコードを書く必要もなく、自由ソフトウェアを使えばよい。CRUDアプリ1つと開発者3人のアマチュアスタートアップでもあるまいし、世界で最も大きく裕福なテクノロジー企業の1つが、ログインなしではテキスト検索すらまともにできないというのは情けない。3つ目の説明があるなら聞いてみたい
    • 内部のコード検索は単なる Elasticsearch なので、特別なものではない
      GitHub の説明はおおむねナンセンスに聞こえる。公開エンドポイントに認証を強制するのは、彼らが主張する問題に対する適切な解決策ではない。このエンドポイントに関心のあるボット作者は無料アカウントでログインさせれば済むので、サーバー負荷を意味のある形で防ぐこともできない

  • 少なくとも6か月前から始まっており、変更ログでも告知されていた: https://github.blog/changelog/2023-06-07-code-search-now-req...
    HNでの議論: https://news.ycombinator.com/item?id=36230929

    • これが新しいニュースのように投稿されたのは意外だ。もう何年も前のことのように感じるし、ログインせずに最後に検索したのがいつだったか、よく思い出せないほどだ
      ビジネスの観点では、なぜそうしたのかは完全に理解できる。人々を文字通りユーザーにしつつ、ユーザーエンゲージメント を高められるからだ

  • そろそろ GitHub を オープンなプラットフォーム のように扱うのはやめるべきだ
    GitHub は他のサービスと同じく、閉じた壁に囲まれた庭だ。私たちが使うオープンソースプロジェクトを数多くホストしているからといって、それがより良いわけではなく、むしろ悪い場合すらある。これらのプロジェクトの貢献インフラの一部を、企業アカウントの鍵の向こう側へ押し込む手助けをしてきたからだ

    • 「企業アカウント」に登録しようが、任意のセルフホスト GitLab アカウントに登録しようが、Bugzilla や Wiki や何らかの git に登録しようが、ユーザーから見ればどれも同じだ
      むしろその中では GitHubアカウント の方がよいと思う。新しいアカウントを作り続けたり、ログインしなかったりせずに、ほぼ無数のプロジェクトに参加できるからだ。GitHub がこの領域の他の選択肢と実質的に異なる形で何かを妨げたとは言いにくい。GitHub は優れたソフトウェアを作って無料で提供し、かなりオープンでアクセスしやすい状態を保ち、標準があるところでは標準に従い、それ以外には API を提供し、オープンソースプロジェクトに莫大なストレージとコンピューティングを無料で提供してきた
    • GitHub が数多くのオープンソースプロジェクトの成長を助けてきたことも言うべきだ
      Gitホスティング、Wikiホスティング、Issue、GitHub Actions、GitHub Pages、まともな API まである。オープンソースプロジェクトを GitHub に置く理由は非常に多い

  • 2023年にウェブは本当に閉じられた。StackOverflow、Reddit、GitHub、TwitterがいずれもスクレイピングとAPIアクセスにブレーキをかけた
    きっかけは、AI学習の防止と収益性への圧力が重なったことだった。テック不況、StackとXの新しい所有者、RedditのIPO推進といった商業上の現実もあった。長期的には、独占的データ市場が大きくなると見ている。検索エンジン、AIツール、データを必要とする誰もが、元データのストリームやAPIアクセスに費用を払うことになり、最も裕福な企業だけがそのデータを買えるなら、独占禁止法上の問題につながる可能性もある

    • 結局、誰もが「StackOverflow、Reddit、GitHub、Twitter」が、他人が作成し所有するコンテンツへのアクセス権を売ることを当然のように受け入れるようになりそうだ
      何かが本当に独占的データなら、報酬は任意のGitサーバー運営者ではなく所有者に行くべきだ。価格や条件も、サーバー運営者ではなく所有者が決めるべきだ。サーバーが収益を上げる必要があるなら、基本サービス自体に料金を課せばよい。逆に、誰かが何かを共有しようとして作り、当時のプラットフォームがそうした配布に有効なチャネルを提供し、自らも配布に適していると宣伝していたなら、途中でルールを変えるのは道徳的にはその人の成果物に対する海賊行為だ。そうしたプラットフォーム上の資料のかなりの部分は、実際の所有者たちが恣意的な制限やアクセス料金を予想していたなら、そもそも投稿されなかった可能性が高い。ルールを抜本的に書き換えるなら、既存コンテンツは原作者が明示的に同意した場合にのみ販売すべきだ。ところがRedditは、そうした乱用を防ごうとして投稿者が大量削除した投稿まで積極的に復元した
    • この流れはもっと以前からあったが、今年は特に多くがロックされた
      https://theoatmeal.com/comics/reaching_people
    • 公平に見ると、GitHubはコード検索を除くほとんどの機能を今でも公開の匿名APIエンドポイントとして提供している
      ただしレート制限ははるかに強い。GitHubアカウントの作成は無料で、侵害的でもないほうだ。ログインしてもサーバーを落とせないよう、どのみちすべてのAPIにはレート制限がある。そのため https://gitstar-ranking.com/ のようなツールは、無料アカウントで全リポジトリのGitHubスターをかき集めようとして苦労している。実際に重要なデータであるソースコードは、HTTPSエンドポイントから匿名でcloneすればよく、その中でコード検索をすればよい。https://grep.app/ のようなサードパーティサイトもこの方式で実現できる。Reddit/Twitterの場合、元データである投稿、コメント、推薦、ツイートがAPIで提供されなくなり、サードパーティツールを作るのが難しいか不可能になったが、GitHubは元データには容易にアクセスでき、検索という補助レイヤーだけが未ログインユーザーに閉ざされているため、状況はかなり違う
    • 正しくもあり、そうでなくもある。ExpertsExchangeは回答を「壁の向こう」に置いたことで有名で、StackOverflowと似ていた
      StackOverflowがローンチされたとき、expertsexchangeと比較されながらも「開かれている」と評価されていた記憶がある。そろそろ中央集権型サービスから、より分散されマイクロトランザクション基盤の構造へ移る時期だ。HNの多くの人は嫌がるだろうが、Q&Aフォーラム、ニュースリンクとコメントの集約、Gitホスティングと承認フロー、Wiki、チケットシステムは完全に分散した方式で実装できるし、そうすべきだ。Kademlia/BitTorrent技術、IPFS、マイクロトランザクション決済用CryptoTokensのような方式が考えられる。100%分散に向かうことだけが、こうしたものを引き続き「開かれた」状態に保ち、企業の強欲から自由にする道だ。創業者が善意で始めても、長期的には製品が売却され、会計担当者たちが主導権を握ることが繰り返されてきた

  • 善意に解釈すれば、検索にはかなり多くの計算資源が必要で、そのため大きなサービス拒否攻撃ベクトルになり得る
    ログインユーザーからGitHubがどれほど多くの行動データを集められるのか、またそれが既に公開されているコードと比べてどれほど有用なのかはよく分からない。コードのどの部分が重要かを把握するのに使えるかもしれないが、それはユーザー別の情報とは見なしにくい

    • 検索機能を提供する誰にとっても実際の問題だ
      私の検索エンジンのトラフィックのうち、約0.5%だけが人間だ。似たような統計を持たない検索エンジンはあまり知らない
    • この行動データ収集はまさにMicrosoft流のやり方なので、善意の解釈を適用する必要はない
      MSによる買収日以降、どのオープンソースプロジェクトにもそのプラットフォームに残る正当な理由はないと思う。git clone一回で移れる良い代替手段がないわけでもない
    • もう一つの要因として、巨大なコード全体に対して匿名でファセット付き正規表現検索を許すと、悪意あるユーザーがハードコードされた認証情報を探して追加のシステムにアクセスでき、適切な監査証跡も残しにくい
      だからAPIをロックダウンする説明はいくつもある

  • ログインしていないときはSourcegraphを使っている。既存の検索と比べるとはるかに良いという利点もある
    github.comから始まるリポジトリURLを貼ればいい程度に簡単だ。例えば sourcegraph.com/github.com/rust-lang/rust/ でこのリポジトリの unit を検索できる

  • MicrosoftのAIの堀の一部は、競合がGitHubの情報を使う能力をコントロールすることにある
    次に git clone まで制限し始めても驚かない気がする

    • git clone を制限したら壊れるCIシステムが多すぎるので、驚くだろう
      NPMの大部分、Goのパッケージ管理、Jenkinsスクリプトなどに別れを告げることになる
    • コードがログインの後ろ、あるいは有料サブスクリプションの後ろにあっても、リポジトリのライセンスに従ってオープンソースと呼べるのか気になる
      記憶では、GitHubはすでに過剰なcloneやAPI利用を遅くするためにレート制限をしている

  • 質問を投稿した人の立場に同意するとしても、あえてそんな言い方をする必要があるのか分からない
    検索は必ずしも安価ではなく、DoS的な攻撃に使われ得るという点で、その立場にも完全には同意しない。「排便の一つひとつまで収益化するだけでは足りず、今度は自分がどのコード行を見ているかまで追跡しようとしているのか」といった言葉が、何の役に立つのか分からない。落ち着くべきだ。根本的な主張もそれほど良くない。リポジトリ自体はログインでブロックされているわけではなく、公開リポジトリは clone を含めて公開アクセス可能だ。作者が自分のリポジトリやコードを一般の人に役立ててほしいと思っているなら、単なるダウンロードや検索を超えて issue を作成したり PR を送ったりする時点で、貢献者はいずれにせよログインする必要がある

    • ソースコードを素早く検索する必要は非常によくある
      何かがどう動くのかを把握したり、GitHub issue ではない場所で議論したりするときに必要になる。clone はたいてい速いが、非常に大きなリポジトリではそうではないし、今使っている端末に clone する空き容量がないこともある。しかも多くの人がログインの代わりに毎回 clone するようになったら、特に GitHub のログインは二要素認証のせいで面倒なのに、システム負荷が減るのかも疑問だ。誰もが GitHub アカウントを持ちたいわけでもない

  • HackerNews: ログインしていないユーザーに無料で広告なしのサービスが提供されないという不満を見ずには、トップページを見られなくなってしまった

    • 無料ならあなたが商品だ、という格言はたいていの場合正しい
      この場合は、あなたのコードが Copilot の学習などに使われている。仮にそうではなく、そのサービスがあなたの信じるように本当に善意に基づくものだとしても、かなり多くのユーザーにとってサービスが悪化していくのを見て拍手できるのか。それは興味深く、わくわくすることなのか？
    • その主張には根拠があるのか？ ほぼ毎日 HN を見ているが、「ログインなしでは X ができない」タイプの投稿が人気になっているようには見えない
      思い浮かぶ唯一の例は Reddit の API 変更だが、それはかなり前の話で、ログインとは緩やかにしか関係していない

  • オープンソース検索を続けたいなら、https://sourcegraph.com/search はログイン不要で、GitHub にない主要プロジェクトも含まれている
    ちなみに私は Sourcegraph CTO です

    • 個人の GitHub アカウントで会社のコンピュータにログインしたくないので、リポジトリ検索が必要なときはいつも Sourcegraph を使っている
      以前は GitHub 検索が git clone + grep に匹敵するようになればと期待していたが、その代償としてログインの壁が付くとは思わなかった。記憶では、ベータ機能だからログインの壁があるだけで、標準検索になれば取り除かれるだろうと予想していた
    • 検索はログインなしで許可している一方で、なぜ Cody にはログイン要求を設けることにしたのか気になる