バイナリを実行するよりも、オープンソースコードをコンパイルする方が安全ですか？
オープンソースソフトウェアを使用する場合、筆者の信頼と、使用する配布プラットフォーム（Codeplex、Git、またはプライベートサーバー）によって、マイレージが異なる場合があることを理解しています。
多くの場合、FOSS Webサイトには、バイナリをダウンロードするためのリンクと、ソースコードをダウンロードするための別のリンクが表示されます。
どのような状況でexeをダウンロードできますか？ （そしてチェックサムを確認し、ルートキットなどがないことを期待しています）
ソースからバイナリをコンパイルする必要があるときはありますか？
この質問に答えるのに役立つのは、コンパイル済みのEXEがウイルスやその他の悪意のあるコードに感染した場合のよく知られた問題に関する情報です。 （等）もしあなたがそのような事件を知っているなら、私もその情報に感謝します。
ほとんどの場合、それはかろうじて安全であるだけであり、時にはそれはより安全ではありません。
どのような状況でexeをダウンロードできますか（cutable？）
主要なディストリビューションからの署名付きパッケージは、ディストリビューションのビルドサーバーでビルドされます。その点では、パッケージングシステムを使用するのがほぼ確実に最善です。
ソースからバイナリをコンパイルする必要があるときはありますか？
一般に、gitなどのソース管理リポジトリでは、個別に変更できるバイナリ出力とは対照的に、信頼できない履歴を監視できます。その点では、ソースコードの方が安全ですが、実際に確認している場合に限られます。悪意のあるバイナリが配置されたり、パッケージ開発者のシステムが悪意のあるコンパイラで危険にさらされたりする可能性がありますが、前者の記録されたインスタンスはまれであり、後者はほとんど前代未聞です。
コンパイルすると、未知のバグにさらされる可能性もあります。異なるコンパイラオプションを使用すると、定期的に配布されるバイナリには見られないバグが発生する可能性があります。さまざまなコンパイラフラグが原因で、マシンに依存する欠陥や動作の変更が多数発生します。その点で、ソースからのコンパイルは安全性が低くなる可能性があります。
ここでの最終的な答えは、バイナリまたはソースコードのソースを検証するために費やす時間の形でどれだけの価値があると感じるかです。
最初に、FOSSプロジェクトのプリコンパイルされた実行可能ファイルのみに悪意のあるコードが含まれているというケースは知らないと述べておきます。したがって、具体的な例を探している場合、この答えはおそらくあなたには向いていません。
自分でコードをコンパイルする最大の利点は、そのコードを読み通して、コードが実際に何を実行するかを決定できることです。これは、FOSSコードの主な利点としてよく宣伝されています。 Linusの法則を参照してください。
十分な眼球があれば、すべてのバグは浅い
しかし現実的には、1人の開発者や開発者の小さなチームでさえ、プロジェクトで使用されるすべてのFOSSコードのソースコードを確認する時間と傾向はありません。言うまでもなく、実際に悪意のあるコードを見つけるには、開発者はセキュリティのバックグラウンドを持っている必要があります。 Linuxカーネルのコードベース全体をコンパイルしてからコンパイルすることを想像してみてください。FOSS開発者とプロジェクトホスティングサイトをある程度信頼する必要があります。
個人的に、私が取るアプローチは、問題のFOSSプロジェクトの評判に依存します。それがLinuxカーネルのように巨大で評判の良いものである場合、私は彼らが提供するバイナリを使用し、多くの開発者が悪意のあるコードを見つけて修正を迅速に発行することを信頼します。プロジェクトの評判が悪い場合は、自分でコンパイルする前に、自分でソースコードを調べて、悪意のあるコードのヒントがないかどうかを確認します。それが不可能な場合は、上記のFOSSプロジェクトの使用に疑問を呈し、代わりに、より信頼できるプロジェクトを選ぶか、自分で機能を記述します。
ソースコードは次の点で「安全」です。
- （バイナリコードではなく）ソースコードにdiscreetバックドアを仕掛けることは、ソースコードをレビューする人の数に比例して困難です。
- ソースコードに自動的に感染するウイルスはほとんどありません。
最初の方法は強力な保証ではありません。まず、敵対的な作者を想定しているので、その作者がyoバックドアを備えた特定のソースコードを提供できる方法を検討する必要があります。したがって、コンパイルしようとしているソースをレビューする立場にある人々のセットは、1人、つまりあなたに減らされる可能性があります。その場合、個人的にyoが完全なソースコードレビューを実行する意思がない場合、ソースコードをコンパイルしても、少なくともバイナリを使用するよりも安全ではありません。バックドアを仕掛けたい。
次に、バックドアやその他の脆弱性はバグです。正直な間違いであるバグであっても、非常に深刻なものであっても、すべてのバグをコードレビューで検出できないことは十分に実証されています。単なる不運と不注意の結果であるバグを確実に見つけることができない場合、検出を回避しようとするインテリジェントな攻撃者によって意図的に作成されたバグをどのように認識できますか？
古典的な必読のリファレンスは ケントンプソンのチューリング賞講演 です。より最近の話については、（公式には）愚か者であることが判明した OpenBSD IPSec実装における疑わしいバックドア に関するすべてのドラマを参照してください。この後者のケースでは、実際のバックドアはなかったようです（私は自分でチェックしていません）seemsが、微妙に欠陥のあるバックドアにいくつかのバックドアを仕掛けているという事実を強調していますPRNG多くの人に明白に見えるソースコードでさえ、非常に可能性が高いようです。
結局、それはriskの問題です。攻撃者の観点から見ると、バックドアをソースコードに入れることは危険です。そのソースコードが広く利用可能である場合、捕まるリスクはより高くなります。一方、バイナリコードのバックドアはほとんど安全です。これも攻撃者にとっては安全です。より安全なソースコードに依存するfor yoは攻撃者の合理性に依存することを意味します。つまり、攻撃者は攻撃の危険を冒すほど怒っていないため、ソースコードを使用します目に見えるソースコードのバックドア。
ウイルスに対する保護は、少なくともWindows用のバイナリの場合、おそらくより高い実用的な価値があります。ソースコードを使用することで、ソフトウェア作成者のマシンで実行できるほとんどのウイルスに対して免疫力があります（もちろん、自分のマシンのウイルスに対してではありません-しかし、これらはすでに存在しています）。
まず、他の人が述べたように、オープンソースは、コードを見る人があなたが言及する問題を検出するのに十分なスキルを持っているという意味ではありません。また、コードが実際に裏で何かを実行するときに、コードを無害に見えるようにすることもできます。例については nderhanded C code contest を参照してください。
可能な限り読みやすく、明確で、一見信頼できるように見えるが、悪意のある機能をひそかに実装する、無邪気に見えるCコードを書くことによって、単純なデータ処理問題を解決するようにコーダーに挑戦する競争。
第2に、コードに悪意のあるビットが明示されていない場合でも、システムを危険にさらす可能性がある攻撃に対して脆弱である可能性があります。ここで最も明白な例はハートブリードです。
したがって、作成者とコミュニティを信頼していて、脆弱性などの微妙な問題が random number genreration にない場合、問題は-いつバイナリを信頼できるか、いつソースからコンパイルする方が賢明ですか？
この質問に答えるには、 再現可能なビルド を確認することをお勧めします。 debian と others -- tor を含めて実装されています。興味のあるFOSSプログラムが再現可能なビルドとチェックサムを配布する自動システムを提供している場合、バイナリが侵害される可能性はわずかです。特に、署名に関しては The Qubes project がどのように行うかを確認してください。
最後に、問題が コンパイラ妥協 のシナリオのアプリケーションソースコードにない可能性があることを忘れないでください。この場合、（信頼できる）バイナリを使用するほうがよいでしょう。