依存関係の信頼

💡 お知らせ: このドキュメントはAIによって翻訳されています。表現に違和感がある場合は、原文（英語）を参照するか、翻訳にご協力ください。

サプライチェーン攻撃(supply-chain attack)のリスクを軽減するため、Flix はすべてのパッケージの依存関係を、使用できる言語機能を制限する security context(セキュリティコンテキスト) の中でビルドします。

security context は次のとおりです：

plain context でビルドされた依存関係は計算を行い、エフェクトを使用できますが、Flix の外側には手を伸ばせません。Java クラスの import も、Java のコンストラクタ・メソッド・フィールドの呼び出しも、unsafe も、未検査キャストも使えません。paranoid context でビルドされた依存関係は、IO エフェクトすら使用できません。

これが plain と paranoid を信頼して依存できる理由です。Java に手を伸ばせず、型システムを迂回することもできないパッケージは、その型とエフェクトが示すことしか行えません。呼び出す関数のシグネチャを読めば、それを呼び出すことで何が起こりうるかがエフェクトシステムからわかります。paranoid パッケージが純粋な値を返す場合、内部でどう書かれていようと、ファイルシステムに触れることも、ソケットを開くことも、時刻を読み取ることもできません。unrestricted context には、そのような保証がなく、シグネチャはそのコードが何をするかについて何も教えてくれません。

私たちが読むシグネチャは、現在ビルドしているリリースのものであり、後のリリースではそれが変わるかもしれません。エフェクトのロックでは、シグネチャが変わったときにそれを知らせてもらえるよう、シグネチャを記録しておく方法を説明しています。

security context の設定

各依存関係の security context は、マニフェストの中で設定できます：

[dependencies]
"github:flix/museum-giftshop" = { version = "2.0.2", mount = "giftshop", security = "plain" }
"github:flix/museum"          = { version = "4.0.0", mount = "museum", security = "unrestricted" }

flix/museum パッケージは、それ自身の依存関係の 1 つが Java ライブラリを使用しているため、unrestricted でなければなりません。

security context を宣言していない依存関係は、plain context でビルドされます。install コマンドは security context を宣言しないため、それ以外の context を設定する場合はマニフェストを編集します。

注意: security context は依存関係に適用されます。私たち自身のコードは、依存しているパッケージに対して何を宣言していようと、常に unrestricted です。

context がグラフ全体に広がる仕組み

security context は推移的に適用されます。ある依存関係の security context は、その依存関係自身が持つ依存関係にも適用されます。ただし、そのうちの 1 つがより制限の弱い security context を明示的に宣言している場合は例外です。複数の依存関係が同じパッケージを必要とする場合、そのパッケージには、要求された中で最も制限の強い security context が適用されます。

したがって、依存関係は他の何かに依存することでその context から逃れることはできません。plain context または paranoid context でビルドされたパッケージは、Maven 依存関係や JAR 依存関係を自身で持つことすらできません。Java ライブラリには unrestricted context が必要であり、それが見つかった場合 Flix はエラーを報告します。

context の選び方

推奨されるのは、security context を指定せず、デフォルトの plain を使うことです。これが柔軟性と安全性の最も良いバランスを提供します。

警告: unrestricted は、依存関係と、それが依存するすべてのものが何でもできてしまうため、可能な限り避けてください。unrestricted な依存関係を含むコードは、ビルドやコンパイルをするだけでもサプライチェーン攻撃にさらされる可能性があります。

エフェクトを必要とするライブラリを書く

エフェクトを必要とする Flix ライブラリの作者である場合のベストプラクティスは、IO エフェクトを直接使うのではなく独自のカスタムエフェクトを導入し、ライブラリを 2 つのパッケージに分割することです：

このアプローチには、次のような利点があります：

• ほとんどの機能が、信頼できる plain の security context にとどまります。
• 安全でないコードは webserver-lib-handlers に隔離されるため、レビューが容易になります。
• 提供されたハンドラを信頼できない場合、ユーザーは自分でハンドラを実装できます。

エフェクトとそのハンドラの定義方法については、エフェクトとハンドラ を参照してください。