ハクソク

世界を動かす技術を、日本語で。

ダニエル・ステンバーグがAIによって発見され修正された22のcurlバグについて

235日前原文(mastodon.social)

概要

  • Mastodon のWebアプリ利用時の JavaScript有効化 の必要性
  • JavaScript が使えない場合の 代替案
  • ネイティブアプリ の利用推奨
  • 各 プラットフォーム 向けのアプリ案内
  • ユーザーへの 利用方法 の選択肢提示

Mastodon Webアプリ利用時の注意点

  • Mastodon のWebアプリを利用するには、 JavaScriptの有効化 が必須
  • ブラウザ設定で JavaScriptを有効 にする必要
  • JavaScript が無効の場合、Webアプリの機能制限

JavaScriptが利用できない場合の代替案

  • JavaScript を有効にできない場合、 ネイティブアプリ の利用を推奨
  • 各種プラットフォーム（ iOS、Android、Windows、macOS、Linux）向けに公式・非公式の Mastodonアプリ が存在
  • App Store や Google Play などの公式ストアでアプリ検索・インストール
  • ネイティブアプリは Webアプリ同様の主要機能 をサポート

利用方法の選択肢

  • Webブラウザ での利用： JavaScript有効化 が必要
  • ネイティブアプリ での利用： 各プラットフォーム対応アプリ のインストール
  • 利用環境やセキュリティポリシーに合わせた 最適な方法の選択

Hackerたちの意見

curlリポジトリには「sarifデータ」とクレジットされた55件のクローズドPRがあるよ。これがダニエルが言ってるやつだと思う。https://github.com/curl/curl/pulls?q=is%3Apr+sarif+is%3Aclos... ダニエル・ステンバーグが過去にAI生成の偽のセキュリティ問題に悩まされていたことを考えると、これは注目に値するね。https://www.linkedin.com/posts/danielstenberg_hackerone-curl... HackerOneに関しては、「我々はAIのゴミだと判断した報告を提出した報告者を即座に禁止します。閾値に達しました。実質的にDDoS攻撃を受けています。もしできるなら、この時間の無駄に対して彼らに料金を請求したいです。」 それから2024年1月のこれもね。https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-f...

└

その後、使われているモデルはかなり改善されたと思う。彼の意見の変化がそれを示してるね。

└

サイズ_tに対して間違ったprintf指定子を使うようなバグは、適切な警告フラグを設定すればコンパイラに指摘されるよね。「あなたのプロジェクトには重要なバグキャッチ用のコンパイラ警告フラグが欠けてます」って教えてくれるAIオラクルがあれば、かなり役立つと思う。これらのPRのいくつかはdependabotのPRで、「sarif」にマッチしてるのは、プロジェクトの依存リストのどこかにその文字列が出てくるからだと思う。「Joshua sarif data」でより具体的な閉じたPRのセットが返ってくるよ。 https://github.com/curl/curl/pulls?q=is%3Apr+Joshua+sarif+da...

これが「AIコーディングコンパニオン」に求めるものだな。コードを書いたり直したりしてくれなくていいから（ありがとう、でもそれは自分でやれるから）、どの部分が怪しいか、どこを詳しく見た方がいいか教えてほしい。Claudeに20klocのCライブラリのバグを探させると、ほぼファイルを小さく分けて特定のコードパターンをgrepして、最終的には自分のFIXMEコメントのリストをくれるだけなんだよね（笑）。正直言って、ちょっと期待外れだな。単純なbashスクリプトでもできることだし。ChatGPTはさらに役に立たない。結局「すべて素晴らしいよ、いい仕事だ！ハイタッチ！」って言うだけで、時間を無駄にしてる感じ。今のところ、従来の静的コード分析の方が実際のバグを見つけるのにずっと役立ってる。でも、静的分析がクリーンだからといって論理バグがないわけじゃないし、こここそLLMが輝くべきところだと思う。LLMからより有用な潜在的バグ情報を得るために、かなりカスタマイズされた設定が必要なら、そのアイデア自体があまり役に立たなくなっちゃう。静的コード分析も、手間のかかる設定や手動のビルドシステム統合が必要なら使われないのと似たような状況だよね。IDEのボタンやメニュー項目で簡単に使えるか、各ビルドでデフォルトで有効になっている場合じゃないと。

└

Cursor BugBotはこれに関してかなり良いよ。無料トライアルをやってみたら、開発者たちに大人気で、結局使い続けることになった。たまに誤検知はあるけど、すごく役立ってる。PR提出者とレビュアーの両方の時間を節約してくれる。

└

提案なんだけど、まずFIXMEコメントを削除するためにregexを実行してから、もう一度実験してみて。私はよくClaudeやGPT-5などを使って、既存のリポジトリを分析するけど、テストやドキュメントフォルダを意図的に省いてるんだ。なぜなら、それらがコードに関する答えに影響を与えてほしくないから。質問してる時点で、ドキュメントがすでに答えてない可能性が高いからね！

└

これにはZedの「Ask」モードをいつも使ってるよ。これは読み取り専用モードで、LLMがコードベースを理解することに集中するんだ。会話の途中で自由に切り替えられるよ。

└

GPT-5はこの手のことに関して、他のモデルよりもずっとお世辞を言わない印象があるから、「全部素晴らしい、やったね、ハイタッチ」っていうのには驚いたよ。Codex CLIを通して使うと、よく疑問を投げかけてくるしね。Gemini 2.5 Proもこの点では良いよ。

└

最近、Claude Codeを使って長年の複雑なバグを見つける作業をしてたんだけど、ほんとに色々できるんだよね。仮説を立てて、それをテストして、仮説が失敗した時にはgdbをバッチモードで使ってアセンブリレベルで何が起こったかを追跡したり、問題のコードのasmダンプと比較したりしてる。まだ指導が必要だけど、昨日は何日もかけても解決できなかったバグを潰してくれた。ちょっと厄介なところもあるけど、非常に複雑なバグに対してもかなりの助けになると思う。

└

これについてあまり話されてないのが意外だね。多くのプログラマー（ほとんど？）はコードの設計や作成が好きで、コードレビューはあまり楽しんでないから、AIにコードを書かせてプログラマーをレビューに回すのは逆な気がするよね。（もちろん、全体が「LoCマシンがバリバリ動く」ってステークホルダーに売られてるのは知ってるけどさ。コードレビュー？それ何？）

└

今作ってるアプリでは、gpt-oss-20Bを使ってるよ。プロンプトにはOWASPのトップ10ウェブ脆弱性を入れて、「確定的な脆弱性」についてだけコメントするように指示してる。自分が書いたコードの脆弱性を見つけるのにかなり効果的だったよ（コメントを見ると評価はあまり良くないモデルなんだけど）。これをもっと拡張する必要があるのは、「疑問がある」時にフローの中で関数呼び出しを導入することかな。そういう時に、他のファイルを引っ張ってきたりして、作業しているコンテキストを広げるツールを呼び出すのが良さそう。

└

Claudeに20klocのCライブラリのバグを見つけてって頼むと、ファイルを小さなチャンクに分けて特定のコードパターンをgrepして、最終的には自分のFIXMEコメントのリストをくれるだけなんだよね（笑）。正直言って、ちょっと物足りないな。シンプルなbashスクリプトでもできることだし。よくうまくいくテクニックがあるんだけど、予想外に悪い結果が出た時には、LLMに効果的なプロンプトがどんなものか聞いてみるといいよ。例えば、「Claude Codeに論理バグを効果的にレビューする計画を作成させるためのプロンプトはどうなる？」みたいな感じ。結果のプロンプトは長すぎて引用できないけど、ここで生の結果が見れるよ：https://gist.github.com/CharlesWiltgen/ef21b97fd4ffc2f08560f... そこから必要な改善を加えたり、エージェントにしたりできる。

└

確かに、多くの機械学習モデルでは、分類は生成よりも常に簡単だよね。これってchatgptの知能レベルとも一致してるかも。

└

「これがどうダメなのか教えて」とか「なんでこれがクソなのか」といったプロンプトで、chatGPTとClaudeの両方でかなり成功してるよ。ちょっと下品にすることで、媚びへつらうモードから抜け出せるみたいだし、解決してほしい問題のタイプをもう少しオープンにすると、より良い結果が得られる気がする。ただ、20,000行以下に制限してるから、チャットウィンドウにそのまま貼り付けられるものにしてる。

curlとAIの話が今回はポジティブだとは思わなかったな。ちょっとした歴史を知りたい人はここを見てね。https://hn.algolia.com/?q=curl+AI

└

そうだね、ダニエル・ステンバーグがこれまでの問題を乗り越えて、AI生成のバグ報告にオープンマインドで接しているのは本当にフェアなことだと思う。

「一連のツール」って言ってたのに気づいた？彼らは正しく使ってるよ。これはツールのシステムであって、自動操縦じゃない。

└

ステンバーグさんはそう説明してたけど、実際に使ってたのは彼じゃないからね。寄稿者がそのAIツールについてどう思ってるのかはわからないな。

└

議論が「オートパイロット」対「自制」に縮小しちゃったのは変だよね。むしろ「自分が何をしようとしてるか理解してる人たち」対「雰囲気コーダー」っていう理解に向かってるのが嬉しい。

└

読んでないけど、寄稿者の記事にはもっと詳しい情報が載ってるはずだよね：https://joshua.hu/llm-engineer-review-sast-security-ai-tools... （https://mastodon.social/@bagder/115241413210606972で言及されてた）。

これ、ジョシュア・ロジャースの元のブログ記事にリンクするべきだね： https://joshua.hu/llm-engineer-review-sast-security-ai-tools... （「AI SASTを使ったハッキング：ペネトレーションテスターとセキュリティチームのための『AIセキュリティエンジニア』／『LLMセキュリティスキャナー』の概要」）

└

その投稿に付随するPDFスライドデッキには、使われたツールのスクリーンショットが含まれてるよ： https://joshua.hu/files/AI_SAST_PRESENTATION.pdf

これ、めっちゃ好き！: https://mastodon.social/@icing@chaos.social/1152440641434357... >tldr >コードは正しかったけど、名前が間違ってた。

これのおかげで22(!)のバグ修正を達成したんだけど、まだその2倍以上の問題が残ってる。 22以上の数だったみたいだね、ほとんどが有効だと仮定すると。

おお、AIの利用ニュースは意外とポジティブかもしれないね。スロップレポートのスパム問題を軽視するつもりはないけど、ドゥーマリズム以外の何かを見ることができて嬉しいよ。

私にとってもっと興味深いのは、そもそもこれらのバグが発生しないようにする方法だね。このスレッドで挙げられている例は、C（とミューテーション）が得意とするバグのタイプだよ。