` `

Avertismente de Securitate

O dată ce este introdusă parola de master, API-ul este deschis pentru a vă oferi acces la baza datelor de autentificare, similar modului în care funcționează Firefox. Cu toate acestea, la implementarea inițială, nu sunt definit piedici împotriva accesului PyQGIS. Acest lucru poate conduce la probleme, în cazul în care un utilizator descarcă/instalează un plugin PyQGIS rău intenționat, sau o aplicație de sine stătătoare, care obține acces la prerogativele de autentificare.

Soluția rapidă pentru versiunea inițială a caracteristicii, este de a nu include doar cele mai multe legături PyQGIS pentru sistemul de autentificare.

O altă modalitate simplă, deși nu robustă, este de a adăuga un ComboBox prin Setări ‣ Opțiuni ‣ Autentificare (implicit “niciodată”):

"Allow Python access to authentication system"
Choices: [ confirm once per session | always confirm | always allow | never]

Setarea unei asemenea opțiuni ar trebui să fie salvată într-o locație de bază inaccesibilă pentru Python, cum ar fi baza de date de autentificare, și să fie criptată cu parola principală.

  • O altă opțiune ar putea consta în urmărirea plugin-urilor specifice utilizatorului

  • allowed to access the authentication system, though it may be tricky to deduce which plugin is actually making the call.
  • Sandboxing plugins, possibly in their own virtual environments, would reduce ‘cross-plugin’ hacking of authentication configs from another plugin that is authorized. This might mean limiting cross-plugin communication as well, but maybe only between third-party plugins.
  • Another good solution is to issue code-signing certificates to vetted plugin authors. Then validate the plugin’s certificate upon loading. If need be the user can also directly set an untrusted policy for the certificate associated with the plugin using existing certificate management dialogs.

  • Alternativ, accesați din Python datele sensibile de autentificare la sistem

  • could never be allowed, and only the use of QGIS core widgets, or duplicating authentication system integrations, would allow the plugin to work with resources that have an authentication configuration, while keeping master password and authentication config loading in the realm of the main app.

The same security concerns apply to C++ plugins, though it will be harder to restrict access, since there is no function binding to simply be removed as with Python.

Restricții

The confusing licensing and exporting issues associated with OpenSSL apply. In order for Qt to work with SSL certificates, it needs access to the OpenSSL libraries. Depending upon how Qt was compiled, the default is to dynamically link to the OpenSSL libs at run-time (to avoid the export limitations).

QCA follows a similar tactic, whereby linking to QCA incurs no restrictions, because the qca-ossl (OpenSSL) plugin is loaded at run-time. The qca-ossl plugin is directly linked to the OpenSSL libs. Packagers would be the ones needing to ensure any OpenSSL-linking restrictions are met, if they ship the plugin. Maybe. I don’t really know. I’m not a lawyer.

The authentication system safely disables itself when qca-ossl is not found at run-time.