GPGキーのパスフレーズをお漏らししたお話

はじめに

割とちゃらけながら書いてますが、普通に良くないことなのでみなさんはパスフレーズの取り扱いに十分気をつけてください。

本題

まあ、久々に開発しようと思ってプライベートリポジトリのコードを弄って遊んでいたんですが、「よしっある程度できたしコミットしよう」となり適当にコミットを押し、Pin entryにパスフレーズを打ったつもりだったんです...実はコードに書いてたっていう ＼(^o^)／

何してんねんお前はっていう話は置いといて、私は基本的にパスフレーズはコピペで貼り付ける人なので(そもそもあんまりよくないだろうけど)Pin entryが出てくる前に要は貼り付けちゃったわけですね、はい。んでもってコミットするタイミングでなんか変更あるけど、これもステージングするの？って言われて何も考えずにYesを押したんですね。（これもよくない）結果的に無事にGitHubにプライベートリポジトリとはいえGPGキーのパスフレーズが無事公開されたと.....

対応

まあ、やっちゃったもんはもう仕方ないので、自分ができることから始めました。GitHubのコミット署名は失効証明書を登録したらいいぞ！みたいな話を昔 @aki に聞いていたので、試してみたんですが失効してるぞゴラァ！みたいなこと言われてそもそもアップロードできなかったので、GitHubのドキュメントを漁ってたらこんなものがありました。

GitHub Docs

コミット署名の検証について - GitHub ドキュメント

GPG、SSH、または S/MIME を使用して、ローカルでタグとコミットに署名できます。 これらのタグまたはコミットは、GitHub で検証済みとマークされるため、他のユーザーはその変更が信頼できるソースから行われたものであると確信できます。

永続的コミット署名の検証には、検証の時点でのコミットの検証済み状態が反映されます。 つまり、後で署名キーが取り消されたり、期限切れになったり、変更されたりした場合、以前に検証されたコミットは、最初の検証中に作成されたレコードに基づいて、検証済みの状態を維持します。 GitHub では、以前に署名されたコミットの再検証や、キーの状態の変化に応じた検証状態の遡及的調整は行われません。 Organization では、セキュリティ ポリシーに合わせてキーの状態を直接管理することが必要になる場合があり、キーのローテーションや取り消しが頻繁に計画されている場合は特にそうです。

とのことで、GitHubからは対象のGPGキーを削除するだけでいいみたいです。

@aki に漏洩したーみたいな話をしたらGitLabでの対処を調べてくれて、GitHubと同様で消すだけでいいみたいです。なんかGitHubと違ってGitLabはRevokeとか言うのがありましたが、多分今までのも含めて信用しないみたいな感じにできるのかな?まあ詳しく見てないのでよくわからないですけど :D

あとは実機にインポート済みの秘密鍵とか、バックアップしてある秘密鍵とかを削除して失効証明書だけ手元と適当な場所に公開しとくつもりです。

お裾分け(失効証明書)

まあ、あとはいつもどおり(6年ぶり)にGPGキーを作ってGitHubやらGitLabやらに再登録しときました。

〆

初めて失効証明書とか作って案外楽しかったってのは否めないです(´ε｀ )

でも普通によくないことなので再発防止に努めようと思います...。