2012-02-06 9 views
0

私たちは、すべての単一ソースファイルを(GPGで)暗号化し、make(具体的にはGNU Make)をシームレスに動作させるC/C++プロジェクトを持っています暗号化されていないソース)。C++プロジェクトで暗号化された個別ファイルをセットアップする

我々は唯一のCまたはC++ファイルを暗号化した場合、これはこのようなルールを達成するためにかなり簡単そうです:

%.o : %.cc.gpg %.hh                
    $(GPG) --decrypt $< | $(CXX) $(CFLAGS) -x c++ -c -o [email protected] - 

我々はヘッダファイルを暗号化する起動した場合しかし、それは、多くのトリッキー取得しますCファイルには、任意の数のヘッダを#includeすることができます。最初は依存関係リストを生成し、暗号化されたすべてのものを復号化してコンパイルする必要があるようです。理想的には、コンパイルが行われている間に解読されたファイルを置いておくのではなく、メモリ内で解読が行われるのが理想的です。

いくつかの注意、コメントを見越して私が買ってあげる:(

  • ユーザーのワークフローはそのエディタのGPGプラグインを必要とするだろうが、残りの部分は、可能な限りシームレスにする必要がありますすなわち、従来のコマンドラインベースのLinux svn + make + gccワークフロー)
  • 私たちはソース管理のためにSubversionを使用しています。私たちは知っていると(例えば破壊のsvn diffのと同様に、この場合の影響)、暗号化ファイルシステム(LUKS)の
  • subversionのレポ生活源でOKバイナリ・ブロブとして格納されており、アクセスはHTTPS経由
  • ですこれは管理の必要条件です
  • この問題に関する私のウェブ調査では、多くの人がすべてのソースファイルを暗号化しないと主張しているのを見てきました。私が言ったように、それは管理要件です。しかし、これらの議論によって対処されていないことの1つは、システム管理者からソースを安全に保つことです。はい、いくつかの点であなたは人々を信頼しなければなりませんが、ソースはコークのレシピのようなものです。制御できないと文字通り会社を台無しにする可能性があります。だからなぜチャンスを取る?
+4

新しい管理をオプションにしていますか? :-) –

+0

復号鍵をビルドプロセスにどのように取り入れる予定ですか?パスフレーズファイル経由の場合は、暗号化されたファイルシステムを使用してデベロッパーワークステーションを設定してください。 –

+0

Linuxシステムで作業する場合、「すべてをメモリ内で実行する必要があります」という点は無視できます。ファイルに書き込む必要があるソリューションがあれば、そのファイルをメモリにマウントされたパーティション(例:/ tmp)に保存するだけです。それで、*ディスク上に*終わるべきではありません。 – Darhuuk

答えて

1

2つの問題があります:1)ビルドプロセスでファイルを復号化し、2)クリアテキストをRAMに保持します。二番目は私のフィールドの少しです。私は夜間のディスクスクラビングと本当に良い監査システムとエアギャップのワークステーションをお勧めします、セキュリティの欠陥を指摘する人は報酬、罰せずにを取得します。とにかく、あなたがその問題を解決したと仮定しましょう。 (この時点で、コードベース全体を解読して正常に動作することができますが、より厳密な解を見つけようとします)。

解読のために、あなたは途中です。代わりに、私は別のルールにそれを破るだろう%.oルールで復号化する:今、あなたが言うように

%.cc : %.cc.gpg                
    $(GPG) --decrypt $< 

%.o : %.cc %.hh                
    $(CXX) $(CFLAGS) -x c++ -c -o [email protected] - 

、あなたがしなければならないすべては、依存関係のリストを生成しています。その後、最初のルールを拡張して暗号化されたヘッダーをカバーすることができます。

あなたがG ++のような文明のコンパイラを使用している場合、あなたは(一般的に)g++ -Mに依存リストを生成し、すべての依存関係の問題を処理するように記述さhereなどの「スマート」%.oルールを書くためにそれを使用することができます自動的かつ目立たない。

問題があるのは、粘性円であるため、最初はg++ -Mを使用できないということです。すべてのヘッダーを復号化する必要はなく、必要なものだけを復号化したくないためですどのヘッダが必要かを知るまで解読しますが、g ++を実行することを意味する依存関係ファイルを生成するまではそれを知ることはできませんが、g ++はエラーを投げて、必要なヘッダーがない場合に終了します。

だから私たちは不正行為をするでしょう。実際のヘッダーファイルと同じ名前の空のヘッダーファイルで完全な別のディレクトリがあるとします(Makeで構築/維持するのは簡単です)。私たちは、g ++(とMake)が通常の場所で見つけることができないヘッダーを探すように指示することができます。オブジェクトを実際にコンパイルするには不十分ですが、で、エラーなしでg++ -Mを実行するのに十分です。実際のヘッダが互いに#includeである可能性があるため、それが構成する依存関係リストは不完全ですが、の場合はで十分です。 makeはそれらのヘッダを解読してからやり直すことができます。 g++ -Mの結果が以前の反復のリストと同じ場合、プロセスは完了し、必要なすべてのヘッダーが復号化され、コンパイルが開始されます。

この輪郭は十分ですか、あるいはナットとボルトで助けが必要ですか?

+0

これは非常に役に立ちます!私は今、十分な詳細を持っていると思う、ありがとう。 – Matt

関連する問題