21.3. セキュリティの考慮事項
マスターパスワードが入力されると、APIは、Firefoxが機能する方法と同様、認証データベース中のアクセス認証configsに開放されます。しかし、初期の実装では、PyQGISアクセスに対しては壁が定義されていません。これは、認証証明書へのアクセスを獲得する悪意のあるPyQGISプラグインまたはスタンドアロンアプリケーションをユーザーがダウンロード／インストールする問題につながる可能性があります。
機能の最初のリリースのための手っ取り早い解決策は、単に認証システムのためにほとんどのPyQGISバインディングを含めないことです。
別の簡単な、堅牢ではないけれども、修正は でコンボボックスを追加することです（デフォルトは「never」）：
"Allow Python access to authentication system"
Choices: [ confirm once per session | always confirm | always allow | never]
このようなオプションの設定は、例えば、認証データベースのPythonへの非アクセスできる場所に保存し、マスターパスワードで暗号化する必要があろう。
別のオプションは、ユーザーが特にどのプラグインを＠認証システムへのアクセスを許可したか＠追跡することかもしれません＠
認証システムへのアクセスを許可＠どのプラグインが実際に呼び出しをしているかを推測するにはこつがいるかもしれませんが。
プラグインを、おそらく自分の仮想環境で、サンドボックス設定すると、認証されている別のプラグインから認証コンフィグの「クロス・プラグイン」ハッキングを低減するでしょう。これは同様のクロス・プラグイン通信を制限する意味するかもしれませんが、多分サードパーティのプラグインとの間にのみ。
もう一つの良い解決策は吟味されたプラグインの作者にコード署名証明書を発行することです。そのときはロード時にプラグインの証明書を検証します。必要であればユーザーは、直接既存の証明書の管理ダイアログを使用してプラグインに関連付けられた証明書を信頼されていないポリシーを設定できます。
また、Pythonのよりセンシティブ認証システムのデータへのアクセス
メインアプリの分野では、マスターパスワードと認証の設定負荷を維持しながら、認証の設定を持っているリソースで動作するようにプラグインを可能にする、許可されていない、とQGISコアウィジェットの使用のみ、または認証システム統合を複製することがない可能性があります。
単にPythonのと同じように削除するバインディング機能がないため、アクセスを制限することが困難になりますけれども、同じセキュリティ上の問題は、C ++のプラグインに適用されます。
21.3.1. 制限事項
OpenSSLのに関連した紛らわしい ライセンスとエクスポート 問題が適用されます。QtがSSL証明書を使用して動作するためには、OpenSSLライブラリにアクセスする必要があります。Qtがどうコンパイルされたかに応じて、デフォルトは（エクスポート制限を回避するために）実行時に動的にOpenSSLのライブラリにリンクすることです。
QCAは同様の戦術に従います、そこではQCAにリンクすることは何の制限を招かない、なぜならQCA-OSSL（OpenSSLの）プラグインが実行時にロードされるため。QCA-OSSLプラグインは、直接にOpenSSL LIBSにリンクされています。パッケージャは、彼らがプラグインを出荷する場合は、任意のOpenSSLの-リンクの制約が満たされていることを確認する必要なものだろう。多分。私は本当に知りません。私は弁護士ではありませんよ。
qca-ossl が実行時に見つからない場合、認証システムは安全に自身を無効にします。