.gitlocal：Gitでの機密ファイルのデフォルト無視を提案する新概念

私は、ドットフォルダに機密情報を記録するCLIツールを開発しており、そのフォルダが誤ってgitにコミットされないようにするためのベストプラクティスを探していました。驚いたことに、gitはツール開発者が「このファイルはコミットすべきでない」と宣言する方法を、実際には提供していなかったのです。そこで私は考えました。もし、ドットフォルダ内に置くだけで、あるいはファイルの先頭に一行追加するだけで、あるいは特定の命名規則を使うだけで、gitがデフォルトでそのファイルを無視してくれるような仕組みがあればどうだろうか、と。 現在、ツール作者ができる最善の方法は、.gitignoreに行を一つ追加することです。 Gitの既存の無視メカニズムはすべて、ツール以外の誰か（ユーザー）が行動を起こす必要があります。.gitignore --assume-unchanged --skip-worktree .git/info/exclude .sometool/config.json .sometool/credentials.json credentials.json 機密ファイルを書き込むツールは通常、独自の設定ディレクトリにファイルを書き込むため、ディレクトリマーカーがあればほとんどのケースをカバーできます。スタンドアロンファイルを書き込み、かつファイル名を制御できるツールは、.local.jsonという拡張子を利用できます。 .sometool/credentials.local.json .sometool/credentials.json 新しいツールは日々リリースされていますが、その作者は現在、ユーザーの.gitignoreを変更するか、ユーザー自身に追加してもらうよう依頼するかの選択を迫られています。 ツールの動作を変えるマーカーファイルという発想は目新しいものではありません。Androidの.nomediaファイルは、メディアスキャナーにそのディレクトリをスキップするよう指示します。rsyncには--exclude-if-presentオプションがあります。 明らかな反論は、不可視の挙動という点です。自身の追跡を抑制するファイルは、ユーザーを驚かせる可能性があります。しかし私は、秘密漏洩問題の深刻さが、その懸念を上回る段階に来ていると考えます。GitHubは年間数百万ものトークンを失効させており、それは検知できたものに過ぎません。セマンティクス（動作規則）を厳密に定義すれば、予期せぬ事態は避けられます。例えば.gitlocalファイルは、`git check-ignore`コマンドで問い合わせ可能であるべきです。 この機能をgit本体に組み込むには、gitメーリングリストを通じてパッチを提出し、メンテナーにコア機能として相応しいと納得してもらう必要があり、そのハードルは高いものです。そこで当面、私は3つの規約（マーカーファイル、ファイル拡張子、先頭行コメント）をすべてチェックする概念実証のpre-commitフックを構築しました。gitが自動的に認識してくれる体験は失われますが、ツール作者は今すぐこの規約を使い始め、本体への提案の根拠となる実績を積むことができます。これは、空のディレクトリをコミット可能にする.gitkeepファイルが普及した経緯とほぼ同じです。 確かに、増え続けるドットファイルの一つにまた加わることになります。しかし、秘密が一つ漏れるごとに、認証情報の更新や監査済みアクセスログの調査が必要となり、時にはさらに深刻な事態を招きます。ツールの設定ディレクトリに空のマーカーファイルを一つ置くことは、特に、どのファイルが機密であるかを正確に把握していながら、それを防ぐ有効な手段を持たない開発者が「今まさに」書いているツールにとっては、合理的な代償と言えるでしょう。

.gitlocal：Gitでの機密ファイルのデフォルト無視を提案する新概念

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト