A instalação do OpenVPN falha porque o gpg do Git vence no PATH

Uma instalação do OpenVPN que morre sob o Chocolatey com um erro de assinatura ou de chave normalmente não é um problema de download. O pacote executa um passo de verificação que invoca gpg, e o Windows resolve esse nome nu através de PATH. Se o Git for Windows foi instalado primeiro, o seu gpg.exe incluído fica à frente da compilação do GnuPG que o OpenVPN espera, e o programa errado responde à chamada. O erro que vê é aquilo de que esse outro programa decidiu queixar-se, e por isso nunca menciona a causa real.

A ordem do PATH decide qual gpg é executado

O Windows não tem um registo central de nomes de executáveis. Quando um processo pede gpg sem um caminho completo, o carregador percorre as entradas de PATH por ordem e executa a primeira correspondência. O Git for Windows inclui uma compilação mínima do GnuPG dentro do seu diretório usr/bin para que os commits assinados funcionem, e o seu instalador costuma colocar esse diretório perto do início do PATH do utilizador.

O GnuPG instala-se no seu próprio diretório, normalmente C:\Program Files (x86)\GNU\GnuPG\pub, e essa entrada pode estar mais abaixo na lista ou faltar por completo no PATH do utilizador. Os dois programas partilham um nome e grande parte de uma interface de linha de comandos, mas não o seu estado: a compilação do Git procura um porta-chaves noutro sítio, pode ser uma versão diferente e pode não aceitar as opções que o instalador passa. Essa discrepância manifesta-se como um erro de assinatura ou de chave, que é um relato verdadeiro do que o binário errado viu. Nada na mensagem aponta para o carregador, porque o carregador fez exatamente o que lhe foi dito.

Porque a shell de onde começa decide o resultado

A regra de herança é a parte que vale a pena interiorizar. Um processo filho recebe o ambiente da shell que o lançou, por isso a ordem que importa é a do momento em que o Chocolatey arranca, não a de depois de a corrigir.

É por isso que editar PATH numa janela de definições e voltar a executar a instalação no mesmo terminal muitas vezes não muda nada: o terminal manteve o ambiente antigo. Inicie uma nova shell após qualquer edição e confirme com where.exe gpg nessa nova shell antes de tentar de novo. Também é por isso que uma entrada ao nível da máquina pode vencer uma alteração ao nível do utilizador, já que alguns instaladores antepõem ao PATH da máquina e as entradas de máquina são avaliadas antes das de utilizador. Se ambos os níveis contiverem um caminho do GnuPG, decida qual está realmente a manter.

Correção um: reordene as entradas

A correção precisa é fazer vencer o diretório do GnuPG pretendido. Abra as variáveis de ambiente do utilizador, edite Path e mova o diretório pub do GnuPG para cima das entradas do Git. Depois abra uma nova janela do PowerShell, porque a que está em execução ainda mantém a lista antiga.

A alternativa é um ambiente limpo temporário para a instalação: retire as entradas do Git, abra uma nova shell, execute choco install openvpn e depois restaure-as.

Ambas as abordagens funcionam pelo mesmo motivo, e a segunda só é segura se restaurar realmente as entradas. Retirar o usr/bin do Git do PATH quebra permanentemente os commits assinados, e a ferramenta seguinte que espera um gpg funcional falha com a sua própria mensagem que nada tem a ver com o OpenVPN. Se seguir a via temporária, guarde o valor original de Path no ticket para que a restauração seja uma colagem e não uma reconstrução. Ordenar as entradas é a correção duradoura; apagá-las é uma solução paliativa com data de validade.

Verifique e depois volte a pôr

Verifique antes e depois no mesmo contexto de utilizador que o Chocolatey vai usar. where.exe gpg lista cada correspondência por ordem de resolução, por isso a primeira linha é a que será executada; Get-Command gpg -All dá a mesma resposta com mais detalhe no PowerShell. Depois gpg --version confirma qual compilação respondeu.

Se where.exe ainda listar primeiro a cópia do Git, a reordenação não chegou a essa sessão, e nenhuma reinstalação ajudará. Verifique tanto o PATH da máquina como o do utilizador com [Environment]::GetEnvironmentVariable('Path','Machine') e a mesma chamada com 'User', porque a lista efetiva é composta por ambos. Após uma instalação bem-sucedida, verifique novamente com openvpn --version e inicie o serviço ou a GUI uma vez, já que um pacote pode instalar-se limpo e deixar um serviço que não arranca.

Se um PATH bem ordenado ainda falhar, a variável que resta é a versão do pacote. Um pacote do Chocolatey fixado pode esperar uma compilação do GnuPG ou um caminho de instalação específicos que a sua máquina não tem.

Leia o registo próprio do pacote antes de mudar qualquer outra coisa. C:\ProgramData\chocolatey\logs\chocolatey.log regista a linha de comando que falhou e o diretório de onde foi executada, o que lhe diz se a chamada falhada foi uma verificação de assinatura, uma extração ou um script posterior à instalação. Essa distinção decide se ainda está a depurar gpg.

O hábito que evita uma repetição é tratar PATH como um estado partilhado com uma ordem documentada em vez de como um saco de diretórios. Quando instalar uma ferramenta que traz um nome de binário comum, verifique o que ela ensombra na shell seguinte que abrir. Depois anote a ordem com que ficou, porque o instalador seguinte acrescentará a ela e a pessoa seguinte perguntar-se-á porque é que uma verificação de assinatura falha numa máquina onde nada mudou. Um único where.exe antes da instalação poupa todo o ciclo.