AURパッケージに悪意のあるコードがないか確認する方法は？
悪意のあるコードが見つかり、後で3つのAURパッケージacroread、blaz、およびminergateから削除されました（ 例：acroread PKGBUILD detail ）。これは、孤立したAURパッケージの所有者を変更し、悪意のあるcurlコマンドを含めることにより、悪意のあるユーザーによってリリースされたコミットで見つかりました。
curlコマンドは、メインのbashスクリプトxをダウンロードし、次に2番目のスクリプトu（u.sh）systemdサービスを作成し、関数を使用して一部のシステムデータ（機密性の低いデータ）を収集するためですが、攻撃者はスクリプトを変更して順次アップロードすることができます。
実際には、何らかの理由で（ある程度の知識が必要で、時間がかかるなど）、すべてのユーザーがシステムでパッケージをビルドする前にPKGBUILDをチェックできるわけではありません。それがどのように機能するかを理解するために、私は2つのbashスクリプトをダウンロードしてアップロードしました このパストビンページ 。
AURパッケージに悪意のあるコードがないかチェックする最も簡単な方法は何ですか？
重要なのは、経験の浅いユーザーがソースコードをチェックするのはそれほど簡単ではないかもしれないということです。ただし、当然の対位法では、ArchLinuxは経験の浅いユーザーに最適なLinuxディストリビューションではないと主張することもできます。
Arch wiki（s）、AURヘルパー、およびオンラインのほとんどのフォーラムは、そのようなリポジトリ/ AURの危険性について警告しており、盲目的に信頼してはならないことを警告しています。一部のヘルパーは、インストールする前にPKGBUILDを読む必要があることも警告しています。
推奨事項として、aurman（問題のある/廃止されたものとしてリストされている）の代わりに trizen またはyaourt（または同様のユーティリティ）を使用することを常にお勧めします。ユーザーはパッケージ/差分リストを検査する機会があります。また、パッケージを取得または更新するときに、投稿の履歴を確認するのにも役立ちます。
代わりに公式のバイナリパッケージがある場合、カジュアルユーザーはこれらのリポジトリをパッケージのソースの主要なステープルとして使用しないでください。 AURを使用する必要がある場合は、Archフォーラムやメーリングリストで問題のレポートを検索できます。ただし、これは過度に楽観的な見方ですが、ここの場合のように、Archコミュニティは定期的にパッケージを検査しているようです。
maldetectを使用して、ダウンロードしたソースコードで既知のマルウェアシグネチャを検索することもできますが、カスタムメイドのコードで何かをキャッチする可能性はありません。 maldetectは、多くの場合、PHPコードでマルウェアをキャッチするのに適しています。
P.S.私の最後の仕事では、ソースからコンパイルされたdhcpdパッケージをしばらく使用し、ソースからコンパイルされたFreeRadiusパッケージを何年も使用していました（Debianバージョンが廃止されたため）。
最初のケースでは、ダウンロードした数回、githubからソースコードをざっとチェックしました。 2番目のケースでは、FreeRadiusユーザーフォーラム、githubフォーラム、およびコードの更新を積極的にフォローしました。また、テスト/検疫環境もありました。 （テスト環境で見つかった重要なバグレポートを提出することさえできました）。
要点を言えば、ソースがインストールされたパッケージでanyの深刻な作業を行っている場合、通常、ディストリビューションによって提供される公式のコンパイル済みパッケージよりもはるかに多くの作業が必要になります。
P.S.2。通常、経験豊富なUnix管理者は、curlから直接ソースされたスクリプト/ソースコードを、いかなる種類の目視検査もなしに直接実行することを教えてくれますが、セキュリティの観点からは非常に悪い考えです。