← 2025-12-18 の一覧へ戻るホーム
How SQLite is tested

2025/12/18 3:15

How SQLite is tested

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

SQLiteのテストインフラは網羅的で、コードベース全体にわたって完全な分岐カバレッジを実現しています。
プロジェクトには約155.8 KSLOCのCソースがありますが、テストコードは92 M KSLOC以上――約590倍の量――で、すべての行が実行されることを保証しています。4つの独立したハーネスがカバレッジを提供します：
• TCL（27.2 KSLOC、1,390個のスクリプトファイル）で51,445件の異なるケースと数百万回の実行があります；
• TH3（1,055.4 KSLOC、約76.9 MBのバイナリ）で50,362件の異なるケース、完全カバレッジに必要な2.4 Mインスタンス、および約248.5 Mテストを実行するソークテストがあります；
• SQL Logic Test (SLT) はSQLiteとPostgreSQL、MySQL、MS SQL Server、Oracle 10gを比較し、7.2 Mクエリと1.12 GBのデータで検証します；
• dbsqlfuzz（libFuzzerベース）はSQLとデータベースファイルの両方を変異させ、約336個のシードファイルから16コアで1日あたり約500 Mテストを提供します。
追加の軽量ハーネスには 

speedtest1.c
、
mptester.c
、
threadtest3.c
、
fuzzershell.c
、およびJSONBファズラ 
jfuzz
が含まれます。
異常テストではメモリ不足、I/O障害、クラッシュ／電源損失、およびカスタムmalloc/VFSフックを使用した複合故障をシミュレートし、各障害後に整合性チェックが実行されます。
ファズリングの歴史はAFL（2014‑2019）からOSS Fuzz（2016年以降）、その後dbsqlfuzz（2018年末）とjfuzz（2024年1月）へ進化しました。
fuzzcheck
スクリプトは毎回ビルド時に興味深いケースを再実行し、新しいバグが自動的にリグレッションテストとして生成されることを保証します。
リソースリーク検出はTCL/TH3ハーネスに組み込まれており、メモリリーク、ファイルディスクリプタ枯渇、および不要なスレッドが自動的に監視されます。
カバレッジは 
gcov
を使用して100 %の分岐カバレッジと変異テストで達成され、マクロ（
ALWAYS
、
NEVER
、
testcase
）がMC/DCを強制し、コメント（
/*OPTIMIZATION‑IF‑TRUE/FALSE*/
）は偽陽性を防ぎます。
結果として、継続的に拡張される高い信頼性のテストスイートが実現し、ユーザーにSQLiteの安定性への確信を提供し、セキュリティ脆弱性から保護し、オープンソースデータベース品質保証のベンチマークとなります。

本文

SQLiteのテスト方法

1. はじめに

SQLite の信頼性と堅牢性は、徹底かつ慎重なテストによって実現されています。

  • バージョン 3.42.0（2023‑05‑16）時点で、SQLite ライブラリは約 155.8 KSLOC の C コードから構成されています。
  • プロジェクト全体では、テストコードとスクリプトが 590 倍に多く – 92,053.1 KSLOC あります。

1.1 エグゼクティブサマリー

機能説明
独立したテストハーネスを4種類配備済み構成で100 %の分岐テストカバレッジ
数百万件のテストケースメモリ不足テスト、I/O エラー テスト、クラッシュ・電源切断テスト、ファズテスト、境界値テスト、最適化無効テスト、回帰テスト、破損データベーステスト
assert()
と実行時チェックを徹底的に利用
Valgrind 分析・未定義動作チェック・チェックリスト

2. テストハーネス

SQLite コアライブラリのテストには、4つの独立したテストハーネスが使用されています。

2.1 TCL Tests

  • 元々 Tcl で書かれたテストです。
  • Tcl インタフェースに関する C コードは 27.2 KSLOC、スクリプトファイルは 1390 件（23.2 MB）。
  • 51,445 のユニークなテストケースがあり、多くはパラメータ化されているため、完全実行時には数百万件の個別テストが生成されます。

2.2 TH3

  • C ベースの独自テストで、100 % 分岐・MC/DC カバレッジを達成します。
  • 約 76.9 MB / 1055.4 KSLOC；50,362 のユニークケース（≈ 2.4 M インスタンス）があります。
  • リリース前のソークテストでは、約 248.5 M テスト が実行されます。

2.3 SQL Logic Test (SLT)

  • SQLite と他エンジンに対して大量の SQL 文を実行し比較します。
  • PostgreSQL、MySQL、MS SQL Server、Oracle 10g との比較を行います。
  • 7.2 M クエリ、1.12 GB のテストデータがあります。

2.4 dbsqlfuzz

  • SQL とデータベースファイルの両方を同時に変異させる独自ファズテスターです。
  • LLVM libFuzzer をベースにカスタムミューテーターを使用しています。
  • 336 のシードファイル、1 日あたり約 10億回 のミューテーションが行われます。

2.5 その他専門テスト

  • speedtest1.c
    – パフォーマンス推定
  • mptester.c
    – マルチプロセス ストレステスト
  • threadtest3.c
    – マルチスレッド ストレステスト
  • fuzzershell.c
    – 一部ファズテストを実行
  • jfuzz
    – libFuzzer JSONB ファザー

すべてのテストは、複数プラットフォームとコンパイル時設定で成功しなければリリースできません。

チェックイン前に開発者は veryquick サブセット（約304.7 k 件）を数分で実行します。

3. 異常テスト

3.1 メモリ不足 (OOM)

  • malloc()
    を 
    sqlite3_config(SQLITE_CONFIG_MALLOC, …)
    で置き換え、OOM をシミュレート。
  • インストゥルメンテーション付き malloc は一度だけ失敗させるか継続的に失敗させることが可能。
  • 失敗ポイントを増やしながら操作が OOM シミュレーションなしで完了するまで繰り返します。

3.2 I/O エラー

  • N 回の操作後に I/O エラーを発生させる VFS を挿入。
  • 単一失敗または継続的失敗の二つのモードがあります。
  • シミュレーション停止後、
    PRAGMA integrity_check
    を実行します。

3.3 クラッシュテスト

  • 特殊 VFS（Tcl の子プロセス、TH3 のインメモリスナップショット）でクラッシュをシミュレート。
  • 書き込み中にランダムにクラッシュし、
    PRAGMA integrity_check
    でロールバックまたは完了を検証。
  • スナップショットやランダム損傷を変えて繰り返します。

3.4 複合失敗テスト

  • 前回のクラッシュからリカバリ中に I/O エラーなど複数失敗を重ねてテストします。

4. ファズテスト

ファザー説明
SQL Fuzz構文的には正しいが意味不明な SQL を生成し、エラーまたは妥当な結果を期待する。
AFLプロファイル指向ファザー（3.8.10–3.29.0 で使用）。
OSS FuzzGoogle の AFL スタイルファザーでインフラ上自動実行。
dbsqlfuzz & jfuzzSQL、データベース、JSONB 入力を変異させる独自 libFuzzer ファザー。
その他サードパーティファザーManuel Rigger などの独立ファザーが誤答を発見。

4.1 Fuzzcheck ハーネス

  • 全ファザーから選ばれた「興味深い」ケースを再実行。
  • make test
    のたびに数千件のケースを実行します。

4.2 ファズと MC/DC の緊張関係

  • 完全 MC/DC は防御的コードを抑制するが、ファズはそれを好む。
  • SQLite は両方を維持：100 % MC/DC + 広範なファズサイクル。

5. 回帰テスト

新規バグは TCL または TH3 の回帰スイートに追加され、修正済みとして扱われる前に再導入が防止されます。

6. 自動リソースリーク検出

両ハーネスはシステムリソースを追跡し、メモリリークは即座に失敗します。SQLite は OOM や I/O エラー後でもメモリリークを起こさない。

7. テストカバレッジ

  • 100 % 分岐カバレッジ（TH3、デフォルト設定で gcov による測定）。
  • ステートメント vs. 分岐カバレッジを例とともに解説。
  • ALWAYS()
    / 
    NEVER()
    マクロと 
    testcase()
    で境界チェックを実装。
  • ミューテーションテスト：分岐を無条件ジャンプまたは NOP に置き換えて出力への影響を確認。最適化は 
    /*OPTIMIZATION‑IF‑TRUE*/
    のコメントで除外。

8. 動的解析

ツール用途
assert()6,754 個のアサーション（デフォルトでは 
NDEBUG
により無効化）。
Valgrindメモリリーク、オーバーラン、未初期化読み取りなどを検出。veryquick と TH3 をリリース前に実行。
memsys2
SQLITE_MEMDEBUG
時の代替アロケータ（Valgrind より高速）。
Mutex Asserts
sqlite3_mutex_held()
/ 
_notheld()
で正しいミューテックス使用を検証。
Journal TestsVFS がデータベースとロールバックジャーナル間の I/O を監視。
Undefined Behavior Checks
-ftrapv
、
-fsanitize=undefined
、
/RTC1
でコンパイルし、複数アーキテクチャで実行。意図的な UB テスト（例：
SELECT -1*(-9223372036854775808)
）も含む。

9. 最適化無効テスト

最適化を有効にした状態と 

SQLITE_TESTCTRL_OPTIMIZATIONS
で無効化した状態の両方でフルスイートを実行し、出力が同一であることを確認。

10. チェックリスト

  • オンラインチェックリスト（約200項目）を手動でリリース前に検証。
  • 人間の監視により自動テストでは捉えきれない微妙な問題も捕捉。

11. 静的解析

  • GCC、Clang (
    -Wall -Wextra
    ) と MSVC で警告なしでコンパイル。
  • scan-build
    は有効な警告を出さず、稀にバグを検出。
  • 実際には警告抑制の過程でバグが導入されるケースが多い。

12. 要約

SQLite の信頼性は、綿密なコード設計と徹底したテスト によって支えられています：

  • TCL、TH3、SLT、dbsqlfuzz といった複数の独立ハーネス
  • 異常・ファズ・回帰・リソースリークテストを網羅
  • 100 % 分岐カバレッジ、ミューテーションテスト、動的解析、静的チェック
  • 継続的に人間が確認するチェックリスト

この厳格なプロセスにより、SQLite はミッション・クリティカルアプリケーションでの信頼性を維持しています。

同じ日のほかのニュース

一覧に戻る →

2025/12/18 1:42

Gemini 3 Flash: Frontier intelligence built for speed

## Japanese Translation: > **概要：** > Google は、低コストで高速な AI モデル Gemini 3 Flash をリリースしました。これは Flash レベルのレイテンシーでプロ級の推論性能を提供します。Gemini アプリと Search の AI Mode では既にデフォルトエンジンとなり、Gemini 2.5 Flash は世界中で追加料金なしで即座に置き換えられます（Gemini 3 Pro が公開された直後）。ベンチマーク結果では、GPQA Diamond で 90.4 %、Humanity’s Last Exam（ツール無し）で 33.7 %、MMMU Pro で 81.2 %、SWE‑bench Verified で 78 % を獲得し、より大きなフロンティアモデルを上回ります。Gemini 3 Flash は Gemini 2.5 Pro より約30 %少ないトークン数で同等以上の性能を発揮します。価格は入力トークンあたり 0.50 USD、出力トークンあたり 3 USD（音声入力は 1 USD/百万トークン）です。JetBrains、Bridgewater Associates、Figma など多くの企業がこのモデルを活用し、コーディング、データ分析、設計ワークフローの高速化に役立てています。開発者は Gemini API（Google AI Studio）、Antigravity、Gemini CLI、Android Studio、Vertex AI、および Gemini Enterprise を通じて Gemini 3 Flash にアクセスできます。このモデルは Gemini アプリと Search 経由で全ユーザーへ展開されるほか、プレビュー API でも利用可能です。

2025/12/18 6:13

I got hacked: My Hetzner server started mining Monero

## Japanese Translation: ヘツナー VPS 上で Coolify をホストし、Next.js ベースの Umami アナリティクスを含む複数コンテナを実行していた。12 月 7 日に、Umami コンテナ内に Monero マイニングボット（`javae`/`xmrig`）が出現し、CPU スパイクが約 15 倍に増大した。著者はマイナーをコンテナに追跡し、CVE‑2025‑66478 ― Next.js の React Server Components “Flight” プロトコルにおける不安全なデシリアライゼーション（Puppeteer を介さずリモートコード実行が可能）を特定した。HTTP リクエストを巧妙に作成することで RCE が発動し、マイナーがインストールされた。ホストファイルシステムのチェック（`/tmp/.XIN-unix/javae`）ではエスケープは確認できず、コンテナは非 root の `nextjs` ユーザーとして実行され、特権モードやボリュームマウントも無いため、すべての悪意あるプロセスは名前空間内に留まった。 著者は侵害されたコンテナを停止・削除し、CPU 負荷を通常状態へ戻した。UFW をデフォルトで受信トラフィックを拒否するよう設定し、SSH、HTTP、および HTTPS のみ許可することで、オープンな PostgreSQL / RabbitMQ ポートを効果的に遮断した。ヘツナーは 2025‑12‑17 にネットワークスキャン検知後、アブズケース警告を送付し、著者が侵害と対策を説明するとともにチケットはクローズされた。 重要な教訓として、十分に隔離されているコンテナでも基盤フレームワークに脆弱性がある場合は突破可能であり、「Next.js を使っていない」状態が第三者ツールの依存関係によって偽りになるケースがあることを指摘した。この事例は、ファイアウォールルール、非 root ユーザー設定、特権モード無し、監視・ fail2ban の導入、およびタイムリーなパッチ適用という防御層の重要性を強調した。 ## 行動計画 - Umami を廃止する - すべてのコンテナに対してユーザー権限とマウントを監査する - SSH アクセスを強化し、アラートを設定する - セキュリティパッチを定期的に適用し、将来のインシデントを防止する ---

2025/12/18 5:50

Inside PostHog: SSRF, ClickHouse SQL Escape and Default Postgres Creds to RCE

## Japanese Translation: 記事は、PostHog のサーバー側リクエストフォージェリ（SSRF）欠陥を複数段階の攻撃チェーンに変えて、PostgreSQL データベースでリモートコード実行を可能にする方法を説明しています。研究者は 24 時間を費やしてソースレベルで手動調査を行い、その結果、オープンソース性と高速 Docker 配備が特徴の自己ホスト型分析プラットフォームとして PostHog を選択しました。 PostHog の Rust Webhook ハンドラー、`database_schema`、および `slack_incoming_webhook` で三つの SSRF 脆弱性（CVE‑2024‑9710、CVE‑2025‑1522、CVE‑2025‑1521）が特定されました。`test_slack_webhook` エンドポイントは URL を検証しますが、`save` エンドポイントでは検証が行われません；PATCH リクエストでこのチェックを回避し、`localhost` のような内部アドレスを保存できます。その後 Rust Webhook ワーカーがこれらの保存された URL に対して再検証なしに POST を送信し、HTTP リダイレクトを追跡して内部的に POST を GET に変換します。 PostHog の ClickHouse バックエンドはポート 8123 上で認証不要な HTTP API を公開しています。GET 要求は読み取り専用ですが、テーブル関数 `postgresql()` はリモート PostgreSQL クエリを許可します。ClickHouse はこの関数内のシングルクォートをバックスラッシュ（`\`）で誤ってエスケープし、テーブル名にエスケープされていない引用符が含まれると SQL インジェクションベクトルを作成します。 COPY 文を閉じ、`;END;` でトランザクションを終了し、ドル引用符で囲まれた PostgreSQL の `COPY FROM PROGRAM` 構文を使用したペイロードを構築することで、攻撃者はリモート PostgreSQL サーバー上で任意の OS コマンドを実行できます。完全なエクスプロイトチェーンは次の通りです： (1) PATCH による Webhook URL 検証回避、 (2) Rust ワーカー内の SSRF、 (3) POST‑to‑GET リダイレクト変換、 (4) ClickHouse SQL インジェクション、 (5) `;END;` と `COPY FROM PROGRAM` を含むペイロード構造、 (6) 追加エスケープを避けるためのドル引用符、 (7) 静的 Docker 名称/認証情報への依存。 研究者は Python スクリプト（`rust-webhook-ssrf-rce.py`）で脆弱性を実演しました。脚本は認証し、`localhost` を指す悪意ある Webhook を作成してトリガーし、PostgreSQL コンテナ内にリバースシェルを取得します。彼らは 2024‑10‑03 に ZDI 経由で責任ある報告を行い、アドバイザリーが公開され 2025‑02‑25 に更新されました。 自己ホスト型 PostHog ユーザーおよび ClickHouse を分析に利用している企業は、これらの脆弱性をパッチしない場合深刻なリスクに直面します。この事件は Webhook URL の検証、内部 API の保護、およびデータベース関数でのユーザー入力の正しいエスケープの重要性を強調しています。