24.3. Considerações de segurança
Depois que a senha mestra é inserida, a API é aberta para acessar as configurações de autenticação no banco de dados de autenticação, semelhante ao modo como o Firefox funciona. No entanto, na implementação inicial, nenhuma parede contra o acesso ao PyQGIS foi definida. Isso pode levar a problemas em que um usuário baixa/instala um plug-in PyQGIS malicioso ou aplicativo autônomo que obtém acesso a credenciais de autenticação.
A solução rápida para o lançamento inicial do recurso é simplesmente não incluir a maioria das ligações PyQGIS para o sistema de autenticação.
Outra correção simples, embora não robusta, é adicionar uma caixa de combinação em: seleção de menu: Configurações –> Opções –> Autenticação (o padrão é “nunca”):
"Allow Python access to authentication system"
Choices: [ confirm once per session | always confirm | always allow | never]
A configuração de tal opção precisaria ser salva em um local não acessível ao Python, por exemplo, o banco de dados de autenticação e criptografado com a senha mestra.
Outra opção pode ser rastrear quais plugins o usuário possui especificamente
permissão para acessar o sistema de autenticação, embora possa ser complicado deduzir qual plug-in está realmente fazendo a chamada.
Plugins de caixa de areia, possivelmente em seus próprios ambientes virtuais, reduziriam o hacker ‘plug-in cruzado’ de configurações de autenticação de outro plugin autorizado. Isso também pode significar limitar a comunicação entre plugins, mas talvez apenas entre plugins de terceiros.
Outra boa solução é emitir certificados de assinatura de código para autores de plug-ins verificados. Em seguida, valide o certificado do plugin ao carregar. Se necessário, o usuário também pode definir diretamente uma política não confiável para o certificado associado ao plug-in usando as caixas de diálogo de gerenciamento de certificados existentes.
Como alternativa, acesse dados confidenciais do sistema de autenticação do Python
nunca poderia ser permitido, e apenas o uso de widgets principais do QGIS, ou a duplicação de integrações do sistema de autenticação, permitiria que o plug-in trabalhasse com recursos que possuem uma configuração de autenticação, mantendo a senha mestra e o carregamento da configuração de autenticação no domínio do aplicativo principal.
As mesmas preocupações de segurança se aplicam aos plugins C++, embora seja mais difícil restringir o acesso, pois não há nenhuma ligação de função vinculativa para simplesmente ser removida como no Python.
24.3.1. Restrições
Os confusos problemas de licenciamento e exportação se aplicam aos associados ao OpenSSL. Para que o Qt funcione com certificados SSL, ele precisa acessar as bibliotecas OpenSSL. Dependendo de como o Qt foi compilado, o padrão é vincular dinamicamente às bibliotecas do OpenSSL em tempo de execução (para evitar as limitações de exportação).
O QCA segue uma tática semelhante, em que a vinculação ao QCA não incorre em restrições, porque o plug-in qca-ossl (AbrirSSL) é carregado em tempo de execução. O plugin qca-ossl está diretamente vinculado às bibliotecas do AbrirSSL. Os empacotadores seriam os que precisariam garantir que todas as restrições de vinculação do AbrirSSL sejam atendidas, se enviarem o plug-in. Pode ser. Eu realmente não sei. Não sou advogado.
O sistema de autenticação se desativa com segurança quando qca-ossl não é encontrado em tempo de execução.