21.3. Considerazioni sulla sicurezza
Una volta inserita la master password, l’API è aperta per accedere alle configurazioni di autenticazione nel database di autenticazione, in modo simile a come funziona Firefox. Tuttavia, nell’implementazione iniziale, non è stato definito un firewall contro l’accesso di PyQGIS. Questo può portare a problemi in cui un utente scarica/installa un plugin PyQGIS dannoso o un’applicazione standalone che ottiene l’accesso alle credenziali di autenticazione.
La soluzione rapida per il rilascio iniziale della funzionalità è semplicemente di non includere la maggior parte dei collegamenti di PyQGIS per il sistema di autenticazione.
Un’altra soluzione semplice, anche se non robusta, è aggiungere un menù a tendina in (predefinita su «mai»):
"Allow Python access to authentication system"
Choices: [ confirm once per session | always confirm | always allow | never]
L’impostazione di una tale opzione dovrebbe essere salvata in una posizione non accessibile a Python, ad esempio il database di autenticazione, e criptata con la password principale.
Un’altra opzione può essere quella di controllare quali plugin l’utente ha in particolare
permesso di accedere al sistema di autenticazione, anche se può essere difficile dedurre quale plugin sta effettivamente facendo la chiamata.
Sandboxing dei plugin, possibilmente nei loro propri ambienti virtuali, ridurrebbe la violazione «cross-plugin» delle configurazioni di autenticazione da un altro plugin che è autorizzato. Questo potrebbe significare limitare anche la comunicazione cross-plugin, ma forse solo tra plugin di terze parti.
Un’altra buona soluzione è quella di rilasciare certificati di firma del codice ad autori di plugin controllati. Poi convalidare il certificato del plugin al momento del caricamento. Se necessario, l’utente può anche impostare direttamente una politica di non fiducia per il certificato associato al plugin utilizzando le finestre di dialogo esistenti per la gestione dei certificati.
In alternativa, l’accesso ai dati sensibili del sistema di autenticazione da Python
potrebbe non essere mai permesso, e solo l’uso dei widget del nucleo di QGIS, o la duplicazione delle integrazioni del sistema di autenticazione, permetterebbe al plugin di lavorare con risorse che hanno una configurazione di autenticazione, mantenendo la password principale e il caricamento della configurazione di autenticazione nel dominio dell’applicazione principale.
Gli stessi problemi di sicurezza si applicano ai plugin C++, anche se sarà più difficile limitare l’accesso, poiché non c’è una connessione di funzionalità da rimuovere semplicemente come con Python.
21.3.1. Restrizioni
Si verificano complicati problemi di licenza ed esportazione associati a OpenSSL. Per poter lavorare con i certificati SSL, Qt ha bisogno di accedere alle librerie OpenSSL. A seconda di come Qt è stato compilato, il default è di collegare dinamicamente le librerie OpenSSL in fase di esecuzione (per evitare le limitazioni di esportazione).
QCA segue una tattica simile, per cui il collegamento a QCA non comporta restrizioni, perché il plugin qca-ossl (OpenSSL) è caricato in esecuzione. Il plugin qca-ossl è direttamente collegato alle librerie OpenSSL. I pacchettizzatori sarebbero quelli che hanno bisogno di assicurarsi che qualsiasi restrizione di collegamento a OpenSSL sia soddisfatta, se spediscono il plugin. Forse. Non lo so davvero. Non sono un avvocato.
Il sistema di autenticazione si disattiva in modo sicuro quando qca-ossl non viene trovato in fase di esecuzione.