PC Toledo

Mais outra, achei que autoridade raiz era uma só, mas não:

A instalação de um certificado de autoridade confiável (CA) pode ser feita tanto no repositório do usuário local quanto no repositório da máquina local, dependendo do escopo desejado:

Usuário Local
- Escopo: O certificado será confiável apenas para o usuário atual.
- Local no registro: HKEY_CURRENT_USER
- Quando usar:
- Quando você quer limitar a confiança do certificado a um único usuário.
- Em ambientes multiusuário onde nem todos devem confiar no mesmo certificado.

Máquina Local
- Escopo: O certificado será confiável para todos os usuários do computador.
- Local no registro: HKEY_LOCAL_MACHINE
- Quando usar:
- Quando o certificado precisa ser confiável por todos os usuários do sistema.
- Para certificados de raiz ou de autenticação de drivers, que exigem instalação no nível da máquina.

Recomendação Geral
Se o certificado for de uma Autoridade de Certificação Raiz Confiável e você deseja que ele seja aceito por todo o sistema (por exemplo, para evitar erros de SSL em navegadores ou validar assinaturas de software), instale-o no repositório da máquina local.

Dica rápida com PowerShell (como administrador):
Import-Certificate -FilePath "C:\caminho\para\certificado.cer" -CertStoreLocation "Cert:\LocalMachine\Root"

Isso instala o certificado diretamente na raiz confiável da máquina local.

Mais uma coisa:
Estou trabalhando no aplicativo do cliente, do jeito que estava.

No upload, faço download pra conferir.
No download, SÓ NESSE EXE DO CLIENTE, aparecia a mensagem de checagem do Windows.
Ao colocar manifest, ela parou.

Meu aplicativo já tem manifest
O manifest define pra rodar com mesmas permissões do usuário logado.
Dessa forma, há uma redução na checagem de segurança.

Quanta putaria de checagem diferente no Windows.
E todas contornáveis kkkk
Se eu fiz, um hacker faz mais fácil ainda. kkkk

Pude constatar as diferenças no Windows:

1) A segurança é diferente para um EXE no disco local ou no disco da rede
Se gravar o EXE em C: a segurança pega mais leve
Se o EXE está na rede, é onde tem verificação de certificado e tudo mais.
Se o EXE vai pra Microsoft, pra checagem, o certificado local não terá validade pra Microsoft

2) DBFs na rede
Se tem um EXE na pasta dos DBFs da rede, ao acessar a pasta ele é verificado

Isso explica porque o cliente sem certificado consegue trocar o EXE na hora que quiser.
Quando eu passei o EXE para o servidor, aí a segurança foi mais "pesada".

ESSE cliente pode fazer alterações no próprio EXE.
Vou usar algo mais ou menos assim no fonte: Qual o resultado:
EXE carregado sempre local, segurança do windows não enche o saco
EXE detectando PATH local, recarrega definindo path da rede
Path da rede não tem EXE, segurança também não enche o saco
E tudo roda tranquilo, com path default sendo o path da rede.
Talvez nem precise certificado.

E o que mudou:
Não tem mais EXE na rede, pra segurança não meter o nariz.

Conclusão:
Pra segurança da Microsoft não existe rede local.
O mesmo tratamento de segurança dado a programas da internet, também é dado pra programas da rede local.
E pra segurança da internet.... coisa "mundial"... só certificado digital oficial.

Muito doido isso.
Não precisa ser nenhum expert pra perceber.
É só prestar atenção no comportamento.
Só executar um EXE em C:, e comparar com ele sendo executado na pasta da rede.

A diferença: economizar alguns milhares de reais com certificado, e encheções de saco da segurança.
Download da internet: não gravar o arquivo diretamente da internet, senão o windows marca como vindo da internet.

Quintas,

Download da internet: não gravar o arquivo diretamente da internet, senão o windows marca como vindo da internet.

Teria alguma sugestão de como contornar essa gravação direta? Disponibilizar como zip?

Antonio Carlos
Curitiba PR

carlos_dornelas escreveu:Teria alguma sugestão de como contornar essa gravação direta? Disponibilizar como zip?

Fui pro lado mais simples.
hb_MemoWrit()
Isso cria um arquivo novo, criado local, não vém da internet.