La instal·lació d’OpenVPN falla perquè el gpg de Git guanya al PATH

Una instal·lació d’OpenVPN que mor sota Chocolatey amb una error de signatura o de clau normalment no és un problema de descàrrega. El paquet executa un pas de verificació que invoca gpg, i Windows resol aquest nom nu a través de PATH. Si Git for Windows es va instal·lar primer, el seu gpg.exe inclòs se situa davant de la compilació de GnuPG que OpenVPN espera, i el programa equivocat respon a la crida. L’error que veieu és el que aquell altre programa va decidir retreure, i per això mai no esmenta la causa real.

L’ordre del PATH decideix quin gpg s’executa

Windows no té cap registre central de noms d’executables. Quan un procés demana gpg sense una ruta completa, el carregador recorre les entrades de PATH en ordre i executa la primera coincidència. Git for Windows inclou una compilació mínima de GnuPG dins del seu directori usr/bin perquè els commits signats funcionin, i el seu instal·lador normalment col·loca aquest directori a prop del capdavant del PATH de l’usuari.

GnuPG s’instal·la al seu propi directori, normalment C:\Program Files (x86)\GNU\GnuPG\pub, i aquesta entrada pot ser més avall de la llista o faltar del tot al PATH de l’usuari. Els dos programes comparteixen un nom i bona part d’una interfície de línia d’ordres, però no el seu estat: la compilació de Git busca un clauer en un altre lloc, pot ser una versió diferent i pot no acceptar les opcions que l’instal·lador hi passa. Aquesta discrepància es manifesta com una error de signatura o de clau, que és un informe veraç del que va veure el binari equivocat. Res del missatge no assenyala el carregador, perquè el carregador va fer exactament el que se li va dir.

Per què l’intèrpret des del qual comenceu decideix el resultat

La regla d’herència és la part que val la pena interioritzar. Un procés fill rep l’entorn de l’intèrpret que el va llançar, així que l’ordre que importa és l’ordre en el moment en què arrenca Chocolatey, no l’ordre després que el corregiu.

És per això que editar PATH en una finestra de configuració i tornar a executar la instal·lació al mateix terminal sovint no canvia res: el terminal ha conservat l’entorn antic. Inicieu un intèrpret nou després de qualsevol edició i confirmeu-ho amb where.exe gpg en aquest intèrpret nou abans de tornar-ho a provar. També és per això que una entrada a nivell de màquina pot superar un canvi a nivell d’usuari, ja que alguns instal·ladors afegeixen al capdavant del PATH de la màquina i les entrades de màquina s’avaluen abans que les d’usuari. Si tots dos nivells contenen una ruta de GnuPG, decidiu quina manteniu realment.

Correcció primera: reordeneu les entrades

La correcció precisa és fer guanyar el directori GnuPG previst. Obriu les variables d’entorn de l’usuari, editeu Path i moveu el directori pub de GnuPG per sobre de les entrades de Git. Després obriu una finestra de PowerShell nova, perquè la que s’executa encara té la llista antiga.

L’alternativa és un entorn net temporal per a la instal·lació: traieu les entrades de Git, obriu un intèrpret nou, executeu choco install openvpn i després restaureu-les.

Tots dos enfocaments funcionen pel mateix motiu, i el segon només és segur si realment restaureu les entrades. Treure el usr/bin de Git del PATH trenca permanentment els commits signats, i la propera eina que esperi un gpg funcional fallarà amb un missatge propi que no té res a veure amb OpenVPN. Si preneu la via temporal, guardeu el valor original de Path al tiquet perquè la restauració sigui un enganxat i no una reconstrucció. Ordenar les entrades és la correcció duradora; eliminar-les és una solució provisional amb data de caducitat.

Verifiqueu i després torneu-ho a deixar com estava

Verifiqueu abans i després amb el mateix context d’usuari que farà servir Chocolatey. where.exe gpg llista totes les coincidències en ordre de resolució, així que la primera línia és la que s’executarà; Get-Command gpg -All dona la mateixa resposta amb més detall a PowerShell. Després gpg --version confirma quina compilació ha respost.

Si where.exe encara llista la còpia de Git primer, la reordenació no ha arribat a aquella sessió, i cap reinstal·lació no hi ajudarà. Comproveu tant el PATH de màquina com el d’usuari amb [Environment]::GetEnvironmentVariable('Path','Machine') i la mateixa crida amb 'User', perquè la llista efectiva es compon de tots dos. Després d’una instal·lació correcta, torneu a comprovar-ho amb openvpn --version i inicieu el servei o la GUI un cop, ja que un paquet pot instal·lar-se net i deixar un servei que no arrencarà.

Si un PATH ben ordenat encara falla, la variable que queda és la versió del paquet. Un paquet de Chocolatey fixat pot esperar una compilació de GnuPG o una ruta d’instal·lació concretes que la vostra màquina no té.

Llegiu el registre propi del paquet abans de canviar res més. C:\ProgramData\chocolatey\logs\chocolatey.log registra la línia d’ordres que va fallar i el directori des d’on es va executar, cosa que us diu si la crida fallida era una comprovació de signatura, una extracció o un script posterior a la instal·lació. Aquesta distinció decideix si encara esteu depurant gpg.

L’hàbit que evita una repetició és tractar PATH com un estat compartit amb un ordre documentat i no com un sac de directoris. Quan instal·leu una eina que porta un nom de binari comú, comproveu què fa ombra al proper intèrpret que obriu. Després anoteu l’ordre que heu triat, perquè el proper instal·lador hi afegirà i la propera persona es preguntarà per què falla una comprovació de signatura en una màquina on no ha canviat res. Un sol where.exe abans de la instal·lació estalvia tot el cicle.