` `
Lorsque le mot de passe principal est tapé, l’API est disponible pour accéder aux configurations d’authentification de la base de données d’authentification, de façon similaire à ce que fait Firefox. Cependant, lors de la mise en œuvre initiale, aucune protection contre l’accès à PyQGIS n’a été définie. Cela peut conduire à des problèmes lorsqu’un utilisateur télécharge/installe un plugin ou une application PyQGIS malicieux qui a accès aux identifiants.
La solution rapide pour le déploiement initial de fonctionnalité est de ne pas inclure la plupart des liens pyQGIS pour le système d’authentification.
Une autre solution simple, mais non robuste, est d’ajouter une liste déroulante dans Paramètres‣ Options ‣ Authentification (défaut : “jamais”) :
"Allow Python access to authentication system"
Choices: [ confirm once per session | always confirm | always allow | never]
Un tel paramètre optionnel devra être sauvé dans un endroit dont Python n’a pas accès, par ex. la base de données d’authentification, et encrypté avec le mot de passe principal.
Une autre option serait de traquer quels sont les plugins que l’utilisateur utilise spécifiquement.
autorisé à accéder au système d’authentification, bien qu’il puisse être compliqué de déduire quel est l’extension qui passe l’appel.
Isoler les extensions, peut être dans leurs propres environnements virtuels, réduirait le piratage “inter-extension’ des configurations d’authentification d’une extension qui est autorisée. Cela peut aussi vouloir dire de limiter la communication entre extensions, mais peut être seulement entre les extensions de tiers.
Une autre bonne solution est d’émettre des certificats pour signer le code des auteurs d’extensions approuvés. Puis de valider le certificat de l’extension lors du chargement. En cas de besoin, l’utilisateur pourrait directement définir une politique de non-confiance pour le certificat associé à l’extension en utilisant les dialogues de gestion des certificats.
Alternativement, accès aux données sensitives du système d’authentification à partir de Python
ne devrait jamais être permis, et seulement l’utilisation des gadgets de base de QGIS ou la duplication des intégrations du système d’authentification, pourrait permettre à l’extension de fonctionner avec les ressources qui ont une configuration d’authentification, tout en ayant le mot de passe principal et la configuration d’authentification chargés dans l’espace de l’application principale.
Les mêmes préoccupations de sécurité s’appliquent aux extensions C++, mais il sera plus difficile d’en restreindre l’accès, car il n’y a pas de fonction de correspondance qui peut être retirée comme c’est le cas pour Python.
Les problèmes confus de licensing and exporting associés à OpenSSL s’appliquent. Pour que Qt puisse fonctionner avec les certificats d’OpenSSL, il a besoin d’avoir accès aux librairies d’OpenSSL. Suivant la façon dont Qt est compilé, le défaut est de se lier dynamiquement aux librairies d’OpenSSL lors de l’exécution (pour contourner les limitations de l’export).
QCA suit une tactique similaire, où la liaison à QCA n’a aucune contrainte, parce que l’extension qca-ossl (OpenSSL) est chargée lors de l’exécution. L’extension qca-ossl est directement liée aux librairies OpenSSL. Les développeurs sont ceux qui doivent s’assurer que toutes les contraintes de liens d’OpenSSL soient satisfaites, s’ils publient l’extension. Peut être, je n’en suis pas sûr, je ne suis pas un avocat.
Le système d’authentification se déactive sans risque lorsque qca-ossl n’est pas trouvé lors de l’exécution.