A instalación de OpenVPN falla porque o gpg de Git gaña en PATH

Unha instalación de OpenVPN que morre baixo Chocolatey cun erro de sinatura ou de clave normalmente non é un problema de descarga. O paquete executa un paso de verificación que invoca gpg, e Windows resolve ese nome espido a través de PATH. Se Git for Windows se instalou primeiro, o seu gpg.exe incluído sitúase diante da compilación de GnuPG que OpenVPN espera, e o programa equivocado responde á chamada. O erro que ve é o que ese outro programa decidiu reprochar, e por iso nunca menciona a causa real.

A orde de PATH decide que gpg se executa

Windows non ten un rexistro central de nomes de executables. Cando un proceso pide gpg sen unha ruta completa, o cargador percorre as entradas de PATH por orde e executa a primeira coincidencia. Git for Windows inclúe unha compilación mínima de GnuPG dentro do seu directorio usr/bin para que funcionen os commits asinados, e o seu instalador adoita colocar ese directorio preto do comezo do PATH do usuario.

GnuPG instálase no seu propio directorio, normalmente C:\Program Files (x86)\GNU\GnuPG\pub, e esa entrada pode estar máis abaixo na lista ou faltar por completo no PATH do usuario. Os dous programas comparten un nome e boa parte dunha interface de liña de ordes, pero non o seu estado: a compilación de Git busca un chaveiro noutro sitio, pode ser unha versión distinta e pode non aceptar as opcións que lle pasa o instalador. Esa discrepancia maniféstase como un erro de sinatura ou de clave, que é un informe veraz do que viu o binario equivocado. Nada na mensaxe apunta ao cargador, porque o cargador fixo exactamente o que se lle dixo.

Por que o intérprete desde o que comeza decide o resultado

A regra de herdanza é a parte que paga a pena interiorizar. Un proceso fillo recibe o ambiente do intérprete que o lanzou, así que a orde que importa é a do momento en que arrinca Chocolatey, non a de despois de corrixilo.

Por iso editar PATH nunha xanela de configuración e volver executar a instalación no mesmo terminal a miúdo non cambia nada: o terminal conservou o ambiente antigo. Inicie un intérprete novo tras calquera edición e confirme con where.exe gpg nese novo intérprete antes de tentalo de novo. Tamén é a razón de que unha entrada de nivel de máquina poida vencer un cambio de nivel de usuario, xa que algúns instaladores antepoñen ao PATH da máquina e as entradas de máquina avalíanse antes ca as de usuario. Se ambos os dous niveis conteñen unha ruta de GnuPG, decida cal mantén en realidade.

Corrección un: reordene as entradas

A corrección precisa é facer gañar o directorio GnuPG previsto. Abra as variables de ambiente do usuario, edite Path e mova o directorio pub de GnuPG por riba das entradas de Git. Logo abra unha xanela nova de PowerShell, porque a que está en execución aínda conserva a lista antiga.

A alternativa é un ambiente limpo temporal para a instalación: quite as entradas de Git, abra un intérprete novo, execute choco install openvpn e despois restaureas.

Ambos os enfoques funcionan polo mesmo motivo, e o segundo só é seguro se realmente restaura as entradas. Quitar o usr/bin de Git de PATH rompe de forma permanente os commits asinados, e a seguinte ferramenta que espere un gpg funcional fallará cunha mensaxe propia que non ten nada que ver con OpenVPN. Se toma a vía temporal, garde o valor orixinal de Path no ticket para que a restauración sexa un pegamento e non unha reconstrución. Ordenar as entradas é a corrección duradeira; borralas é un apaño cunha data de caducidade.

Verifique e logo volva deixalo

Verifique antes e despois co mesmo contexto de usuario que usará Chocolatey. where.exe gpg lista cada coincidencia en orde de resolución, así que a primeira liña é a que se executará; Get-Command gpg -All dá a mesma resposta con máis detalle en PowerShell. Despois gpg --version confirma que compilación respondeu.

Se where.exe segue listando primeiro a copia de Git, a reordenación non chegou a esa sesión e ningunha reinstalación axudará. Comprobe tanto o PATH de máquina como o de usuario con [Environment]::GetEnvironmentVariable('Path','Machine') e a mesma chamada con 'User', porque a lista efectiva componse de ambos. Tras unha instalación correcta, volva comprobar con openvpn --version e inicie o servizo ou a GUI unha vez, xa que un paquete pode instalarse limpiamente e deixar un servizo que non arrincará.

Se un PATH ben ordenado segue fallando, a variable restante é a versión do paquete. Un paquete de Chocolatey fixado pode esperar unha compilación de GnuPG ou unha ruta de instalación concretas que a súa máquina non ten.

Lea o rexistro propio do paquete antes de cambiar calquera outra cousa. C:\ProgramData\chocolatey\logs\chocolatey.log rexistra a liña de ordes que fallou e o directorio desde o que se executou, o que lle di se a chamada fallida foi unha comprobación de sinatura, unha extracción ou un script posterior á instalación. Esa distinción decide se segue depurando gpg.

O hábito que evita unha repetición é tratar PATH como un estado compartido cunha orde documentada en lugar de como un saco de directorios. Cando instale unha ferramenta que trae un nome de binario común, comprobe que sombrea no seguinte intérprete que abra. Logo anote a orde que escolleu, porque o seguinte instalador engadirá a ela e a seguinte persoa preguntarase por que falla unha comprobación de sinatura nunha máquina onde nada cambiou. Un só where.exe antes da instalación aforra todo o ciclo.