` `
Als het hoofdwachtwoord eenmaal is ingevoerd, is de API geopend om toegang te verkrijgen voor de configuraties voor autehnticatie in de database voor authenticatie, soort gelijk aan de manier waarop Firefox werkt. Echter, in de initiële implementatie, is geen wall tegen toegang door PyQGIS gedefinieerd. Dit kan leiden tot problemen als een gebruiker een schadelijke plug-in of zelfstandige toepassing voor PyQGIS downloadt/installeert die toegang verkrijgt tot gegevens voor authenticatie.
De snelle oplossing voor de initiële uitgave van deze mogelijkheid is om gewoonweg niet de meeste bindingen voor PyQGIS voor het systeem van authenticatie op te nemen.
Een andere eenvoudige, maar niet robuuste, reparatie is om een combinatievak toe te voegen in Extra ‣ Opties ‣ Authenticatie (standaard “nooit”):
"Allow Python access to authentication system"
Choices: [ confirm once per session | always confirm | always allow | never]
Een dergelijke instelling voor een optie zou moeten worden opgeslagen op een locatie die niet toegankelijk is voor Python, bijv. de database voor authenticatie, en moeten zijn versleuteld met het hoofdwachtwoord.
Een andere optie zou kunnen zijn na te gaan welke plug-ins de gebruikers specifiek heeft
toegestaan om toegang te verkrijgen tot het systeem voor authenticatie, hoewel het gevaarlijk kan zijn om te bepalen welke plug-in in feite de aanroep doet.
Testen van plug-ins in een zandbak, mogelijkerwijze in hun eigen virtuele omgevingen, zou hacken via ‘cross-plugin’ van configuraties voor authenticatie vanuit een andere plug-in die wel is geautoriseerd kunnen reduceren. Dit zou zou ook de communicatie tussen plug-ins kunnen beperken, maar misschien alleen tussen plug-ins van derde partijen.
Een andere goede oplossing is om gecodeerde certificaten uit te geven aan betrouwbare auteurs van plug-ins. Daarna het certifcaat te valideren bij het laden van de plug-in. Indien nodig zou de gebruiker ook direct een beleid voor niet vertrouwd kunnen instellen voor het certifcaat dat is geassocieerd met de plug-in met behulp van bestaande dialoogvenster voor het beheren van certificaten.
Als alternatief, toegang tot gevoelige gegevens in het systeem voor authenticatie vanuit Python
kan nooit worden toegestaan, en alleen het gebruiken van bronwidgets van QGIS, of het dupliceren van integraties voor het systeem van authenticatie, zou de plug-in toestaan om te werken met bronnen die een configuratie voor autehnticatie hebben, terwijl het hoofdwavjtwoord en de configuratie voor authenticatie worden geladen in het gebied van de hoofdtoepassing.
Dezelfde beveiligingsoverwegingen bestaan voor plug-ins van C++, hoewel het moeilijker zal zijn om toegang te beperken, omdat er geen binding voor functies is die eenvoudigweg kan worden verwijderd, zoals met Python.
De verwarrende problemen voor licensing and exporting die zijn geassocieerd met OpenSSL zijn van toepassing. Om Qt te kunnen laten werken met certificaten van SSL, heeft het toegang nodig tot de bibliotheken van OpenSSL. Afhankelijk van hoe Qt werd gecompileerd, is de standaard om dynamisch te koppelen naar de bibliotheken van OpenSSL tijdens run-time (om beperkingen voor exporteren te vermijden).
QCA volgt een soortgelijke taktiek, waarbij koppelen naar QCA geen beperkingen ophaalt, omdat de plug-in qca-ossl (OpenSSL) gedurende run-time wortd geladen. De plug-in qca-ossl is direct gekopeld aan de bibliotheken van OpenSSL. Verpakkers zouden degenen moeten zijn die er voor zorgen dat aan de beperkingen voor koppelen naar OpenSSL wordt voldaan, als zij de plug-in distribueren. Misschien. Ik weet het echt niet. Ik ben geen jurist.
Het systeem voor authenticatie schakelt zichzelf veiligheidshalve uit indien qca-ossl niet wordt gevonden gedurende run-time.