私の最小・メモリ安全なGo製rsyncが脆弱性を回避する方法

 (michael.stapelberg.ch)
1 ポイント 投稿者 GN⁺ 2 시간 전 | 1件のコメント | WhatsAppで共有
  • gokrazy/rsync は Go で書かれた最小の rsync 実装であり、2025年1月・2026年5月に公開された rsync の脆弱性12件を基準に検証された
  • Go の 境界チェック とゼロ初期化は、ヒープオーバーフローやスタック情報漏えいを panic または無害な値に変えるが、panic は依然としてサービス拒否になりうる
  • パストラバーサルと TOCTOU 系は、Go 1.24 の os.Root のようなトラバーサル耐性のあるファイル API が中核的な防御となり、gokrazy/rsync は全面的に移行済み
  • 最小実装戦略により、--inc-recursive、圧縮、--safe-links、プロキシ、ホスト名 ACL など未実装機能に関する脆弱性を回避でき、攻撃面を縮小する
  • 脆弱性の大半は 検証不足 と過度な複雑性から生じており、単純なユースケースには単純な実装のほうが適している可能性がある

背景と範囲

  • 2025年1月、複数のセキュリティ研究者が upstream Samba rsync で合計 6件のセキュリティ脆弱性 を公開し、その一部は任意コード実行とファイル流出を許していた
  • Go で書かれた互換・最小実装である gokrazy/rsync が、この種の脆弱性群を実際に回避できるかが主要な検討対象である
  • 分析対象は 2025年1月のバッチと2026年5月のバッチ を合わせた12件の脆弱性である
  • upstream rsync を本番環境で実行している場合は 3.4.3 以上 へアップグレードする必要があり、gokrazy/rsync は v0.3.3 以上 に上げる必要がある
  • gokrazy/rsync は、Linux ディストリビューション研究プロジェクト distri のソフトウェアパッケージを router7 で提供するために書かれ、router7 は Go アプライアンスプラットフォーム gokrazy を基盤としている
  • 当初は rsync サーバーだけだったが、現在はあらゆる方向をサポートしており、Go プログラムにリンクできる rsync の基本機能として複数の gokrazy/rsync サーバーで使われている

2025年1月の脆弱性

  • CVE-2024-12084: ヒープバッファオーバーフロー、深刻度 9.8

    • rsync はネットワークから受信したチェックサム長を MAX_DIGEST_LEN と比較していたが、内部データ構造では常に 16 バイトのバッファ char sum2[SUM_LENGTH] を使用していた
    • MAX_DIGEST_LEN は SHA256 または SHA512 チェックサム対応付きでコンパイルされるとより大きくなるため、攻撃者は sum2 バッファの上限を最大 48 バイト 超えて書き込めた
    • この問題は、SHA256/SHA512 チェックサム対応を追加した 2022 年 9 月の commit ae16850 で導入された
    • upstream の修正 では sum2 を動的に割り当てられる sum2_array に変更し、転送アルゴリズムのチェックサム長である xfer_sum_len に基づいて割り当て・検査するよう修正した
    • Go では不正な境界チェックがヒープバッファオーバーフローにはつながらず、ランタイム境界チェックによって panic が発生する
    • gokrazy/rsync にも sum header 検証の欠落はあったが、サイズの取り違えではなく、ChecksumLength を 512 に変更すると Go ランタイムが panic: runtime error: slice bounds out of range [:512] with length 16 を発生させる
    • サーバー全体のクラッシュは望ましい失敗モードではないため、欠けていた境界チェックを追加して panic を error に変更した

  • CVE-2024-12085: スタック情報漏えいによる ASLR 回避、深刻度 7.5

    • CVE-2024-12084 と同じ検証漏れにより、攻撃者は短いチェックサムアルゴリズムを選択した後、より長いチェックサムを送ったと主張できた
    • Google Security report によると、ヒープバッファオーバーフローと情報漏えいを組み合わせることで、匿名の読み取りアクセスしか持たないクライアントでも rsync サーバーマシン上で任意コードを実行できる
    • hash_search() はスタック上の char sum2[MAX_DIGEST_LEN] にチャンク digest を作成して memcmp() で比較していたが、ローカルの sum2 スタックバッファが初期化されておらず、残りのバイトにスタック内容が含まれる可能性があった
    • 悪意あるクライアントはファイルダウンロードごとに 1 バイトを漏えいさせることができ、漏えいデータには heap オブジェクトポインタ、stack cookie、ローカル変数、グローバル変数ポインタ、return pointer が含まれ得る
    • “Some checksum buffer fixes” では攻撃者制御の s->s2length が転送チェックサム長より大きくならないようにし、“prevent information leak off the stack” では sum2 メモリを 0 で初期化した
    • Go はすべての変数を zero value で初期化するためこの脆弱性の影響を受けず、gokrazy/rsync は MD4 以外のチェックサム選択が導入されたプロトコルバージョン 30 ではなく、プロトコルバージョン 27 を実装している

  • CVE-2024-12087: シンボリックリンクを用いたパストラバーサル、深刻度 7.5

    • Google Security report によると、-l または -a（--archive）でシンボリックリンク同期が有効になっている場合、悪意あるサーバーがクライアントに対象ディレクトリ外の任意ファイルを書き込ませることができる
    • 攻撃は --inc-recursive モードで複数のファイルリストを送り、最初のリストでは symlink をディレクトリとして、次のリストでは同じ名前を対象ディレクトリ外を指すシンボリックリンクに変えることで成立する
    • Go 自体ではこの脆弱性を防げず、原因は複数のファイルリストをマージした後に再検証しなかったロジックエラーにある
    • upstream の修正 では欠けていた検証を追加した
    • gokrazy/rsync は incremental recursion モード（--inc-recursive）を実装していないため影響を受けない
    • incremental recursion は、転送開始前にファイル集合全体をすべてスキャンせず、「windowed」方式で処理できるようにする一方、実装の複雑さとリソース使用量のトレードオフがある

  • CVE-2024-12088: --safe-links バイパス、深刻度 7.5

    • Google Security report によると、--safe-links はサーバーから受信したシンボリックリンクが対象ディレクトリ内を指すことを検証する機能である
    • バイパスは、シンボリックリンクの対象パスの途中に別のシンボリックリンクがある可能性を考慮していなかったために発生する
    • たとえば {DESTINATION}/a -> . と {DESTINATION}/foo -> a/a/a/a/a/a/../../ がある場合、foo は実際には対象ディレクトリ外を指すが、unsafe_symlink() は a/ をディレクトリと仮定して安全だと判断してしまう
    • upstream の修正 では、パス先頭部分を除く位置の ../ を許可しないよう unsafe_symlink() をより厳格にした
    • Go 自体では不正な検証関数を防げず、gokrazy/rsync はまだ --safe-links 機能を実装していないため脆弱ではない

  • CVE-2024-12086: 任意ファイル漏えい、深刻度 6.8

    • rsync receiver はクライアントモードで rsync sender が提供したファイル名を正規化しておらず、対象ツリー外のファイルを開くことを防げなかった
    • 悪意ある sender は receiver に対象ツリー外の任意ファイルのチェックサムを比較させ、1 バイトチェックサムに対する receiver の反応を観察することで任意ファイルを漏えいできた
    • Google Security report によると、クライアントが悪意あるサーバーに接続すると、サーバーはクライアントマシン上の任意ファイルの内容を漏えいできる
    • upstream の修正 では sender 提供パスを検証し、対象ツリー外のファイルが開かれるのを防止した
    • Go にはこれを防げる API があり、関連する防御策として Go の os.Root が挙げられている
    • gokrazy/rsync は fuzzy matching 機能が導入されたプロトコルバージョン 29 ではなく、プロトコルバージョン 27 を実装しているため脆弱ではない

  • CVE-2024-12747: シンボリックリンク競合状態、深刻度 5.6

    • Red Hat Security Advisory によると、rsync のシンボリックリンク処理中の競合状態で発生した欠陥である
    • rsync の既定動作はシンボリックリンクに遭遇するとスキップすることだが、攻撃者が適切なタイミングで通常ファイルをシンボリックリンクに置き換えると、既定動作を回避してシンボリックリンクをたどらせることができた

  • upstreamの修正では、rsync sender の open() 呼び出しで O_NOFOLLOW オプションを使用するよう変更された

    • gokrazy/rsync は commit 1b1fbf6 以前まで脆弱であり、このコミットで upstream rsync と同じ O_NOFOLLOW による緩和策が導入された
    • Damien Neil は gokrazy の CVE-2024-12747 修正 は不十分だと考えており、O_NOFOLLOW は最後のパス構成要素に対するシンボリックリンクの追跡を防ぐだけだと判断した
    • たとえば os.Open("dir/passwd") では、前段のパス構成要素である dir を /etc を指すシンボリックリンクに置き換えると、依然として回避できてしまう
    • この問題は 2025年4月に rsync のセキュリティ連絡先へ報告され、2026-05-20 に公開された CVE-2026-29518 につながった

2026年5月の脆弱性

  • CVE-2026-29518: シンボリックリンク競合状態、深刻度 7.0

    • rsync 3.4.3 NEWS entryによると、chrootなしの daemon mode においてローカル権限昇格を許す TOCTOU シンボリックリンク競合状態
    • use chroot = no に設定された rsync daemon は、親パス要素に対する time-of-check/time-of-use 競合にさらされる
    • モジュールへの書き込み権限を持つローカル攻撃者は、receiver の検査と open() の間に親ディレクトリ要素をシンボリックリンクへ置き換えることで、読み取りでは basis-file の情報漏えい、書き込みではモジュール外のファイル上書きを引き起こせる
    • デフォルトの use chroot = yes は影響を受けない
    • upstream 修正では、Go の os.Root API に似た secure_relative_open() を使用している
    • gokrazy/rsync は、sender と receiver を traversal 耐性のある os.Root API に切り替えるまでは脆弱だった

  • CVE-2026-43618: 整数オーバーフローによるリモートメモリ漏えい、深刻度 8.1

    • rsync receiver の 圧縮トークンデコーダ が 32 ビット符号付きカウンタをオーバーフロー検査なしで加算し、悪意ある sender がプロセスメモリの内容を漏えいさせる可能性がある
    • 漏えい対象には環境変数、パスワード、ヒープおよびライブラリポインタが含まれ、ASLR を弱体化し、追加のエクスプロイトを容易にしうる
    • 影響範囲は、圧縮が有効な認証済み daemon 接続で、プロトコル 30 以上で両 peer が圧縮を広告するとデフォルトで有効になる
    • 回避策は、rsyncd.conf で refuse options = compress として daemon の圧縮を無効化すること
    • upstream 修正は欠けていた検査を追加している
    • gokrazy/rsync は 圧縮を実装していないため 脆弱ではなく、圧縮サポートが単純そうに見えてもそうではない理由は gokrazy/rsync issue #35 にまとめられている

  • CVE-2026-43620: 範囲外読み取り後のサービス拒否、深刻度 6.5

    • 2025年に send_files() に追加された parent_ndx<0 ガードが、見た目が同一の recv_files() ブロックには適用されていなかったことが原因
    • 悪意ある rsync サーバーが CF_INC_RECURSE 互換フラグと不正な flist を送ると、receiver が dir_flist->files[-1] を読み取って逆参照し、確定的な SIGSEGV につながる可能性がある
    • 影響範囲は、攻撃者が制御する URL から通常の pull を行うすべての rsync クライアントであり、プロトコル 30 以上でデフォルトの inc_recurse のため、被害者側の特別なオプションは不要
    • クライアントで --no-inc-recursive を使うのが回避策であり、upstream 修正は recv_files() にも parent_ndx<0 ガードを追加している
    • gokrazy/rsync は --inc-recursive の 増分再帰モード を実装していないため、CVE-2024-12087 と同様に影響を受けない

  • CVE-2026-43619: 追加のシンボリックリンク競合状態、深刻度 6.3

    • receiver の open() 呼び出しに対するシンボリックリンク競合状態の修正（CVE-2026-29518）は、chmod、lchown、utimes、rename、unlink、mkdir、symlink、mknod、link、rmdir、lstat など、他のパスベースのシステムコールには適用されていなかった
    • use chroot = no に設定された rsync daemon では、ローカル攻撃者が receiver の検査とシステムコールの間に親ディレクトリ要素をシンボリックリンクへ置き換え、エクスポートされたモジュール外へリダイレクトできる
    • デフォルトの use chroot = yes は影響を受けない
    • upstream 修正は、Linux 5.6+ の openat2、FreeBSD 13+ と macOS 15+ の O_RESOLVE_BENEATH、その他の環境では要素ごとの O_NOFOLLOW traversal のような、カーネルが強制する制約の下で開かれた親 dirfd を通じて、影響を受けるパスベースのシステムコールを処理する
    • gokrazy/rsync は Go の os.Root API を全体的に使用しているため影響を受けない

  • CVE-2026-43617: ホスト名ベース ACL の回避、深刻度 4.8

    • グローバルな daemon chroot = /X rsyncd.conf 設定がある rsync daemon では、接続クライアントの逆引き DNS 参照が daemon が /X へ chroot した後に実行されていた
    • /X に glibc の解決に必要な /etc/resolv.conf、/etc/nsswitch.conf、/etc/hosts、NSS サービスモジュールがない場合、参照は失敗し、接続ホスト名は "UNKNOWN" に設定される
    • hosts deny = *.evil.example のような ホスト名ベースの deny ルール がマッチせず、PTR レコードを制御する攻撃者が、管理者が遮断しようとしていたホスト名から接続できてしまう
    • IP ベースの ACL は影響を受けず、モジュールごとの use chroot 設定はこの脆弱性とは無関係
    • upstream 修正は DNS 参照をプロトコルのより早い段階へ移動する
    • gokrazy/rsync はホスト名ベースの allow/deny リストを実装せず、IP ベースの allow/deny リストのみ を実装しているため脆弱ではない

  • CVE-2026-45232: スタック範囲外書き込み、深刻度 3.1

    • rsync クライアントの HTTP CONNECT プロキシサポートには、establish_proxy_connection() に off-by-one のスタック範囲外書き込みがある
    • プロキシまたは中間者攻撃者が、最初の応答行に '\n' を含まない 1023 バイト以上を返すと、後続コードが 1024 バイトのバッファ直後に '\0' を書き込み、隣接するスタックスロットを破損させる可能性がある
    • AddressSanitizer は establish_proxy_connection フレームの socket.c:95 で stack-buffer-overflow を報告する
    • upstream 修正は攻撃者が提供したデータを検証する
    • gokrazy/rsync はこの プロキシサポート を実装していないため脆弱ではない

Goとgokrazy/rsyncが実際に防いだもの

  • Goランタイムの境界チェックは、より深刻なセキュリティ問題をpanicに置き換える。panicも依然としてサービス拒否のリスクではあるが、より望ましい障害モードと評価される
  • Goはメモリを0で初期化するため、CVE-2024-12085のような情報漏えいは不可能になる
  • Goのos.Root APIは、残る脆弱性の大半を防ぐ
  • 12件の脆弱性のうち、CVE-2026-43617のみが、Goの採用では防げないアプリケーションロジックのバグに分類される
  • gokrazy/rsyncと公式upstream rsyncの中核的な違いは、Goで書かれている点に加えて、実装が最小限である点にある
  • gokrazy/rsyncは--inc-recursive、--safe-links、圧縮、プロキシ、ホスト名ACLなど、問題となった多くの機能を実装していないため、複数の脆弱性を回避している
  • すべてのwire protocol互換rsync実装と同様に、gokrazy/rsyncはプロトコルバージョン27を対象としており、それ以降のプロトコルバージョンはかなりの複雑さを導入している
  • 掲載時点におけるCVEごとのgokrazy/rsyncの状態:
    • 2024-12084: 実装は存在し、panicが発生
    • 2024-12085: プロトコル30の機能であり、実装していないため脆弱ではない
    • 2024-12086: プロトコル29の機能であり、実装していないため脆弱ではない
    • 2024-12087: inc-recを実装していないため脆弱ではない
    • 2024-12088: safe-linksを実装していないため脆弱ではない
    • 2024-12747: 実装は存在し、脆弱だった
    • 2026-29518: 実装は存在し、パッチ適用済み
    • 2026-43617: ホストdenyリストを実装していないため脆弱ではない
    • 2026-43618: 圧縮を実装していないため脆弱ではない
    • 2026-43619: 実装は存在し、パッチ適用済み
    • 2026-43620: inc-recを実装していないため脆弱ではない
    • 2026-45232: プロキシを実装していないため脆弱ではない
  • gokrazy/rsyncで既知の脆弱性はすべて修正済みであり、上記の状態は各CVEが公開された時点での状況を示している
  • 2025年1月の脆弱性公開時、gokrazy/rsyncはCVE-2024-12084でpanicが発生し、CVE-2024-12747のTOCTOU競合状態に対して脆弱だった
  • TOCTOU問題の修正過程でCVE-2026-29518が発見され、当該CVEの公開前にgokrazy/rsyncで修正された
  • CVE-2026-43619はさらに後になって発見されたが、Goの**os.Rootの全面採用**という同じ修正によって、すでにgokrazy/rsyncでは解決済みだった

役割の区別と脆弱性の命名

  • 複数の脆弱性レポートでは「server」と「client」という表現が使われていたが、rsync転送ではrsyncクライアントとサーバーの双方が、送信者（sender、ファイルアップロード）または受信者（receiver、ファイルダウンロード）の役割を担いうる
  • デーモンモードでは、ファイルシステムアクセスを事前設定されたモジュールパスに制限できるが、command modeではそうではない
  • 4つの構成と役割/プロトコル階層は、rsync combinationsの図で確認できる
  • Arbitrary File Leak脆弱性（CVE-2024-12086）の元のタイトルである「Server leaks arbitrary client files」は誤解を招きやすい
  • より正確には、rsync受信者が悪意ある送信者に任意のファイルを漏えいするということだ
  • 悪意あるクライアント送信者は、SSH経由のcommand modeのような環境で、未パッチのリモートrsyncに対象ツリー外のファイル、たとえば/etc/shadowのシステムパスワードデータベースを開かせることができる
  • デーモンモードでは、サーバーが追加のパス正規化（path sanitization）を有効にすることで、この攻撃を防ぐ
  • Symlink Path Traversal脆弱性（CVE-2024-12087）も「malicious server」と表現されるが、正確にはクライアントまたはサーバーのいずれにもなりうる悪意ある送信者である

OpenBSD openrsyncとの比較

  • OpenBSDプロジェクトはセキュリティ重視で知られており、openrsyncはチェックサム長を検証し、チェックサムサイズ/アルゴリズムとしてMD4のみをサポートするため、Heap Buffer Overflow（CVE-2024-12084）とStack Info Leak（CVE-2024-12085）の影響を受けない
  • openrsyncはgokrazy/rsyncと同様に関連機能を実装していないため、CVE-2024-12086、CVE-2024-12087、CVE-2024-12088の影響を受けない
  • たとえ脆弱であったとしても、OpenBSD上で動作する場合は、OpenBSD unveil(2)とpledge(2)によってファイルシステムアクセスを制限する多層防御が、攻撃の成功を防いだ可能性がある
  • openrsyncはシンボリックリンク対応を実装した時点からO_NOFOLLOWを使用していたため、CVE-2024-12747の影響を受けない
  • ただし、O_NOFOLLOWはこの問題に対する十分な修正ではないため、openrsyncはCVE-2026-29518の影響を受ける
  • 2026年5月の一連の脆弱性についても、関連機能の大半を実装していないという点で同様である
  • openrsyncは検証を適切に実装し、攻撃対象領域を制限し、多層防御を適用することで、報告された脆弱性の大半の影響を受けていない

多層防御とos.Root

  • Linux mount namespace

    • gokrazy/rsyncプロジェクトを始めて数週間以内に、ファイルシステムオブジェクトへのアクセスを制限するため、Linuxで権限降格とmount/pid namespaceの使用をサポートする機能が追加された
    • このアプローチはパストラバーサル攻撃の緩和には有効だが、権限が必要なため、rootで実行するか、ディストリビューション/システムで有効化されている場合はLinux user namespace内で実行する必要がある
    • mount namespaceはサーバー構成には適しているが、一般ユーザーのアカウントで実行される対話的な単発転送では使えないことが多い

  • systemdハードニング

    • Linux mount/pid namespaceサポートを導入した同じコミットには、ホームディレクトリへのファイルシステムアクセスを制限するsystemdサービスファイルも含まれており、READMEではユースケースに応じてファイルシステムアクセスをさらに制限するよう推奨している
    • こうしたファイルシステム制限が正しく構成されていれば、File Leak(CVE-2024-12086)とPath Traversal(CVE-2024-12087)の脆弱性を緩和できる
    • Symlink Race Condition(CVE-2024-12747)はrsyncプロセスを通じた権限昇格に依存するが、DynamicUser機能により、そのプロセスは他のユーザーよりも権限が少ない
    • mount namespaceと同様に、サーバー構成には向いているが、対話的な単発利用向けに設定するには煩雑である

  • Linux Landlock

    • Porting OpenBSD pledge() to Linux (2022)を通じて、LinuxにもOpenBSDのunveil(2)に似た、非特権・プロセス単位のアクセス制御であるLandlock APIがあることを思い出した
    • 基本的なアイデアは、プログラムが作業対象のディレクトリを把握したら、unveil("/home/michael/backups", "rw");のような呼び出しで、そのパス以外のファイルシステム上の場所に以後アクセスできなくすることだ
    • 2025年3月、ファイルシステムアクセスを制限するためのLandlockサポートが実装された
    • 設定完了後は、非特権のgokrazy/rsync実行でも、rsync転送をソースには読み取り専用、宛先ディレクトリには読み取り・書き込み権限に制限できる
    • 欠点は、Landlockがプロセスレベルで動作する点だ
    • Landlockポリシーにはプログラムに必要なファイルも含める必要があり、たとえばgokrazy/rsyncはユーザーIDの参照のために/etc/passwdを読めなければならないので、攻撃者が/etc/passwdを狙う場合、Landlockは役に立たない

  • Goのos.Root

    • 2025年2月、Go 1.24はパストラバーサルに強いos.Root APIを導入し、関連する背景はDamien NeilのThe Go Blog: Traversal-resistant file APIsにまとめられている
    • os.RootはLandlockと比べて、ファイルシステム操作ごとにより細かな制御を提供する
    • 2025年8月にリリースされたGo 1.25ではos.Rootにさらに多くのメソッドが追加され、ほとんどのファイルシステム利用で便利な選択肢になった
    • gokrazy/rsyncのすべてのファイルシステム利用はos.Rootへ移行されており、ユーザーが入出力ディレクトリを設定する一方で、ネットワーク経由で受信したファイル名は信頼できないというモデルによく適合する
    • mknod(2)のように、APIから直接は作れなさそうなシステムコールでも安全に利用できる
    • Damien Neilは、os.Root.OpenFileで宛先の親ディレクトリを開き、File.Fdでそのディレクトリのファイルディスクリプタを取得したうえで、golang.org/x/sys/unix#Mknodatでファイルを作成できると説明している
    • 実際の使用例はinternal/receiver/generatormknod_linux.go, line 15-29にある
    • Linuxにはmknodat(2)はあるが、Linux 7.0時点でbind(2)に対応するbindatはない
    • Lennart Poetteringは、bindatなしでもパス解決を回避するトリックとして、/proc/self/<fd>/foobarにbindできると提案している
    • 既知の安全な/proc/self/<fd>の後ろにパスではなくbasename、つまり最後のパス要素だけを指定すれば、パス解決はスキップされる。関連コードはline 49-56にある
    • この2つのヒントにより、gokrazy/rsync v0.3.1以降はos.Rootを完全に使用し、すべてのファイルシステムアクセスがパストラバーサル安全性を備えるようになった

重要な教訓

  • TOCTOU脆弱性(CVE-2024-12747、CVE-2026-29518、CVE-2026-43619)を除くすべての脆弱性は、入力検証の欠如または誤った入力検証に起因している
  • 3件ではそもそも検証がなく、CVE-2024-12088はファイルシステムのパス解決というテーマが難しく、既存の検証ではすべての境界ケースを扱い切れなかったケースである
  • 最も価値のある構造的修正は、境界チェックのような常時有効な検証と、Goのos.Rootのような安全性をデフォルトにしたAPIを提供することだ
  • 一部の脆弱性はrsyncプロトコルの進化の中で生じたもので、もともとは十分な検証を行っていたコードに新機能が追加された際、検証が適切に更新されなかった
  • チェックサムアルゴリズム交渉とインクリメンタル再帰はプロトコルバージョン30で追加されたが、既存の検証は新機能の処理方法に合わせて更新されなかった
  • gokrazy/rsyncとopenrsyncは、脆弱な機能を実装していなかったという理由だけで、12件のセキュリティ脆弱性のうち8件の影響を受けなかった
  • それらの機能は、ある時点で誰かにとって価値があったからこそrsyncに追加されたのであり、ソフトウェア開発を止めるべきだという意味ではない
  • 理想的な選択は、ユースケースの複雑さに見合った、比例した複雑さの実装を使うことであり、単純なユースケースには単純な実装を選び、必要なときだけフル機能の実装を選ぶことだ

関連記事

1件のコメント

 
GN⁺ 2 시간 전
Lobste.rsのコメント
  • 素晴らしい記事。どの言語も標準ライブラリに os.Root のような API を入れるべきなくらい良い
    SecureDropで何度か パストラバーサル脆弱性 を経験したあと、とても単純化した版を書いたが、今では正しいAPIを使えば脆弱性の一類型が丸ごと消える
    • その通り。このブログ記事の主役はGoというより os.Root のように思える