La instalación de OpenVPN falla porque el gpg de Git gana en PATH

Una instalación de OpenVPN que muere bajo Chocolatey con un error de firma o de clave normalmente no es un problema de descarga. El paquete ejecuta un paso de verificación que invoca gpg, y Windows resuelve ese nombre desnudo a través de PATH. Si Git for Windows se instaló primero, su gpg.exe incluido se sitúa delante de la compilación de GnuPG que OpenVPN espera, y el programa equivocado responde a la llamada. El error que ve es lo que ese otro programa decidió reprochar, y por eso nunca menciona la causa real.

El orden de PATH decide qué gpg se ejecuta

Windows no tiene un registro central de nombres de ejecutables. Cuando un proceso pide gpg sin una ruta completa, el cargador recorre las entradas de PATH en orden y ejecuta la primera coincidencia. Git for Windows incluye una compilación mínima de GnuPG dentro de su directorio usr/bin para que funcionen los commits firmados, y su instalador suele colocar ese directorio cerca del principio del PATH del usuario.

GnuPG se instala en su propio directorio, normalmente C:\Program Files (x86)\GNU\GnuPG\pub, y esa entrada puede estar más abajo en la lista o faltar por completo en el PATH del usuario. Los dos programas comparten un nombre y buena parte de una interfaz de línea de comandos, pero no su estado: la compilación de Git busca un llavero en otro sitio, puede ser una versión distinta y puede no aceptar las opciones que le pasa el instalador. Esa discrepancia se manifiesta como un error de firma o de clave, que es un informe veraz de lo que vio el binario equivocado. Nada en el mensaje apunta al cargador, porque el cargador hizo exactamente lo que se le dijo.

Por qué el intérprete desde el que empieza decide el resultado

La regla de herencia es la parte que merece interiorizarse. Un proceso hijo recibe el entorno del intérprete que lo lanzó, así que el orden que importa es el del momento en que arranca Chocolatey, no el de después de corregirlo.

Por eso editar PATH en una ventana de configuración y volver a ejecutar la instalación en el mismo terminal a menudo no cambia nada: el terminal conservó el entorno antiguo. Inicie un intérprete nuevo tras cualquier edición y confirme con where.exe gpg en ese nuevo intérprete antes de intentarlo de nuevo. También es la razón de que una entrada de nivel de máquina pueda vencer a un cambio de nivel de usuario, ya que algunos instaladores anteponen al PATH de la máquina y las entradas de máquina se evalúan antes que las de usuario. Si ambos niveles contienen una ruta de GnuPG, decida cuál mantiene en realidad.

Corrección uno: reordene las entradas

La corrección precisa es hacer que gane el directorio de GnuPG previsto. Abra las variables de entorno del usuario, edite Path y mueva el directorio pub de GnuPG por encima de las entradas de Git. Luego abra una ventana nueva de PowerShell, porque la que está en ejecución aún conserva la lista antigua.

La alternativa es un entorno limpio temporal para la instalación: quite las entradas de Git, abra un intérprete nuevo, ejecute choco install openvpn y luego restáurelas.

Ambos enfoques funcionan por el mismo motivo, y el segundo solo es seguro si realmente restaura las entradas. Quitar el usr/bin de Git de PATH rompe de forma permanente los commits firmados, y la siguiente herramienta que espere un gpg funcional fallará con un mensaje propio que no tiene nada que ver con OpenVPN. Si toma la vía temporal, guarde el valor original de Path en el ticket para que la restauración sea un pegado y no una reconstrucción. Ordenar las entradas es la corrección duradera; borrarlas es un apaño con fecha de caducidad.

Verifique y luego vuelva a dejarlo

Verifique antes y después con el mismo contexto de usuario que usará Chocolatey. where.exe gpg enumera cada coincidencia en orden de resolución, así que la primera línea es la que se ejecutará; Get-Command gpg -All da la misma respuesta con más detalle en PowerShell. Después gpg --version confirma qué compilación respondió.

Si where.exe sigue enumerando primero la copia de Git, el reordenamiento no ha llegado a esa sesión y ninguna reinstalación ayudará. Compruebe tanto el PATH de máquina como el de usuario con [Environment]::GetEnvironmentVariable('Path','Machine') y la misma llamada con 'User', porque la lista efectiva se compone de ambos. Tras una instalación correcta, vuelva a comprobar con openvpn --version e inicie el servicio o la GUI una vez, ya que un paquete puede instalarse limpiamente y dejar un servicio que no arrancará.

Si un PATH bien ordenado sigue fallando, la variable restante es la versión del paquete. Un paquete de Chocolatey fijado puede esperar una compilación de GnuPG o una ruta de instalación concretas que su máquina no tiene.

Lea el registro propio del paquete antes de cambiar cualquier otra cosa. C:\ProgramData\chocolatey\logs\chocolatey.log registra la línea de comandos que falló y el directorio desde el que se ejecutó, lo que le dice si la llamada fallida fue una comprobación de firma, una extracción o un script posterior a la instalación. Esa distinción decide si sigue depurando gpg.

El hábito que evita una repetición es tratar PATH como un estado compartido con un orden documentado en lugar de como un saco de directorios. Cuando instale una herramienta que traiga un nombre de binario común, compruebe qué sombrea en el siguiente intérprete que abra. Luego anote el orden que eligió, porque el siguiente instalador añadirá a él y la siguiente persona se preguntará por qué falla una comprobación de firma en una máquina donde nada ha cambiado. Un solo where.exe antes de la instalación ahorra todo el ciclo.