公開リポジトリに鍵が残っていないか、除外設定を「決めた」だけで済ませず、AIが全履歴を検索して確かめました

転職用のポートフォリオとして、個人でWebアプリ「Hubpin」を作っています。
制作の経緯は「Hubpin 開発記録」に時系列でまとめています。
設計と判断は自分で行い、実装も原則自分で書いています。AIには手順書・レビュー・調査を任せています。

ソースはGitHubで公開しています。

公開するにあたって、接続情報の扱いは最初に決めていました。
本物の鍵を書いたファイルは除外設定で公開対象から外す。
公開するのは、項目名だけを書いた見本ファイルにする。
除外設定は自分で書き、見本ファイルも自分で用意しました。

ただ、決めたことと守れていたことは別です。
公開している以上、過去のコミットに一度でも本物が混ざっていれば、あとで消しても記録には残ります。
除外設定を書いた日より前のコミットがあれば、そこに入っていた可能性もあります。

そこは、記憶ではなく履歴で確かめておきたい箇所でした。

目次

「決めた」で終わらせず、履歴を見る

自分で全ブランチの履歴を追うこともできますが、漏れなく見るならAIに任せたほうが確実です。
公開前のレビューと、検索エンジン向けの確認ファイルを置いてよいかを聞いたときに、AIが全履歴まで検索してくれました。

返ってきたのは、全部の履歴と全部の枝を検索した結果でした。

見たこと 結果
本物の接続情報ファイルが、過去に一度でも入ったか ゼロ
公開対象に入っている接続系のファイル 見本ファイルだけ
その見本の中身 項目名とコメントだけ。値は全部空

「そう決めた」が「そうなっていた」に変わりました。

線引きは「相手が公開するつもりで渡してきたか」

この確認のときにAIが説明した線引きで、腑に落ちたものが1つあります。

判断の基準は、難しさではありません。
その情報を出した側が、公開されることを想定しているかどうかです。

  • 項目名(〇〇_URL のような名前)は公開前提。むしろ他人が同じものを動かすために要る
  • 値(実際の鍵)は非公開前提

確認ファイルも同じで、発行元が「このURLに置け」と言っている以上、公開が前提です。

「隠すべきか」で考えると、境界で迷います。
「相手が公開するつもりで渡してきたか」で考えると、迷う場面がかなり減りました。
見本ファイルを公開してよい理由も、この線引きで説明できます。

知識だと「たぶん」まで、測ると「だった」と言える

除外設定の仕組みは知っているので、「大丈夫なはず」とは確かめる前から言えました。
でも、知識で言えるのはそこまでで、測って初めて「大丈夫だった」になります。

セキュリティに関しては、その差を埋めておきたいと思っています。
かかったのは、数分の検索でした。
その数分を惜しまないかどうかが、公開して大丈夫と言えるかどうかの差でした。

目次