gsendmailの認証情報をどこに保持するべきか考える

gsendmailというsendmailぽいツールを実装した。これは標準入力からMIME形 式のデータ(つまりEメール)を受け取り、Gmail APIを利用してEメールを送信 する。Gmail APIはOAuth2の認可の仕組みを使用するため、アクセストークン やシークレットトークンをどこかに保持する必要がある。gsendmailはCLIツー ルであるため、クラウド上に保持することはあまり望ましくない。その必要は ないし、インターネットに接続していないと使用できないようなツールはそこ そこクソだ。ではどこかのファイルに保持しておく必要がある。すぐに考えつ くのは独自の設定ファイルをホームディレクトリに配置する方法だ。この場合、 どのような仕様も自分の想いのままになる。ただ設定ファイルがどこにあるの か、どのような記述をするべきなのかを忘れてしまうことはよく発生する。ド キュメントを記述しても保守しないし、またその都度コードを読むということ もしたくない。そして、これが一番問題だと思うのが平文でアクセストークン やシークレットトークンといったとても大切なデータをファイルシステム上に 存在させてしまうことはセキュリティ的に問題がある。そのため今回はこの手 法は採用しなかった。

次にnetrcなどの設定に共存する方法も考えたが、これも先程と同様にセキュ リティの問題は回避できない。また設定を相乗りするというところも違和感を 覚えた。netrcなどはFTPのための仕組みであったはず。複数のツールでその設 定を共存させるということは、意図しない問題を引き起すことに繋がる。その ためこの方法も採用しなかった。

平文の問題についてはGPGなどを用いて暗号化することが、良いシナリオだと 思う。

主な使用環境はmacOS上に限定できる。そのためKeychainが使える。これを使 用する方法も検討した。これを採用すると他のOSでは使用できなくなってしま うが、そのかわり簡易の機密情報のためのデータベースを入手したことになり、 セキュリティ面を考えても一人で頑張るよりも、少しだけ勇気が出た。 Keychainのデータを全て抜き去るという脆弱性に関する怖い記事もあったが、 自分独自でやるよりはマシと判断し今回はKeychainを採用することにした。

複数アカウントに対応するにはいくつか乗り越えるギャップがある。Keychain の値の格納時に指定できる属性を考慮しつつ、複数のアカウントの情報を保持 するようにしたい。なるべくシンプルなデータ構造を持つように以下のように した。

アカウントについてはKeychainのアカウントを踏襲することにした。当然デー タ不整合などの状況を手動で作り出すことができるが、それはもう気にしない ことにした。

Eメールの送信時にはアクセストークンしか使用しない。もしアクセストーク ンが失効していても自動ではリフレッシュしない。なにもかも勝手に行なわれ るという状況はできるかぎり避けるべきであるし、そうしたい人だけが明示的 にそれを行うようにしたほうが、致命的なトラブルを防げると考えた。