L’installation d’OpenVPN échoue parce que le gpg de Git gagne dans PATH

Une installation d’OpenVPN qui meurt sous Chocolatey avec une erreur de signature ou de clé n’est généralement pas un problème de téléchargement. Le paquet exécute une étape de vérification qui appelle gpg, et Windows résout ce nom nu via PATH. Si Git for Windows a été installé en premier, son gpg.exe embarqué se place avant la compilation GnuPG qu’OpenVPN attend, et le mauvais programme répond à l’appel. L’erreur que vous voyez est ce dont cet autre programme a décidé de se plaindre, et c’est pourquoi elle ne mentionne jamais la vraie cause.

L’ordre de PATH décide quel gpg s’exécute

Windows n’a pas de registre central des noms d’exécutables. Quand un processus demande gpg sans chemin complet, le chargeur parcourt les entrées de PATH dans l’ordre et exécute la première correspondance. Git for Windows fournit une compilation GnuPG minimale dans son répertoire usr/bin pour que les commits signés fonctionnent, et son installateur place généralement ce répertoire près du début du PATH de l’utilisateur.

GnuPG s’installe dans son propre répertoire, généralement C:\Program Files (x86)\GNU\GnuPG\pub, et cette entrée peut être plus loin dans la liste ou manquer complètement du PATH de l’utilisateur. Les deux programmes partagent un nom et une bonne partie d’une interface en ligne de commande, mais pas leur état : la compilation de Git cherche un trousseau ailleurs, peut être une version différente et peut refuser les options que l’installateur transmet. Cette divergence se manifeste par une erreur de signature ou de clé, qui est un rapport véridique de ce que le mauvais binaire a vu. Rien dans le message ne pointe vers le chargeur, car le chargeur a fait exactement ce qu’on lui avait dit.

Pourquoi le shell depuis lequel vous démarrez décide du résultat

La règle d’héritage est la partie qui vaut la peine d’être intériorisée. Un processus enfant reçoit l’environnement du shell qui l’a lancé, donc l’ordre qui compte est celui au moment où Chocolatey démarre, pas celui d’après votre correction.

C’est pourquoi modifier PATH dans une fenêtre de paramètres et relancer l’installation dans le même terminal ne change souvent rien : le terminal a conservé l’ancien environnement. Démarrez un nouveau shell après toute modification et confirmez avec where.exe gpg dans ce nouveau shell avant de réessayer. C’est aussi pourquoi une entrée au niveau machine peut l’emporter sur un changement au niveau utilisateur, car certains installateurs ajoutent au début du PATH de la machine et les entrées machine sont évaluées avant les entrées utilisateur. Si les deux niveaux contiennent un chemin GnuPG, décidez lequel vous maintenez réellement.

Correctif un : réordonnez les entrées

Le correctif précis est de faire gagner le répertoire GnuPG voulu. Ouvrez les variables d’environnement de l’utilisateur, modifiez Path et déplacez le répertoire pub de GnuPG au-dessus des entrées Git. Ouvrez ensuite une nouvelle fenêtre PowerShell, car celle en cours conserve encore l’ancienne liste.

L’alternative est un environnement propre temporaire pour l’installation : retirez les entrées Git, ouvrez un nouveau shell, exécutez choco install openvpn, puis restaurez-les.

Les deux approches fonctionnent pour la même raison, et la seconde n’est sûre que si vous restaurez réellement les entrées. Retirer le usr/bin de Git de PATH casse définitivement les commits signés, et l’outil suivant qui attend un gpg fonctionnel échoue avec son propre message qui n’a rien à voir avec OpenVPN. Si vous prenez la voie temporaire, conservez la valeur d’origine de Path dans le ticket pour que la restauration soit un collage et non une reconstruction. Ordonner les entrées est le correctif durable ; les supprimer est un contournement avec une date d’expiration.

Vérifiez, puis remettez en place

Vérifiez avant et après dans le même contexte utilisateur que Chocolatey utilisera. where.exe gpg liste chaque correspondance dans l’ordre de résolution, donc la première ligne est celle qui s’exécutera ; Get-Command gpg -All donne la même réponse avec plus de détails dans PowerShell. Ensuite gpg --version confirme quelle compilation a répondu.

Si where.exe liste encore la copie de Git en premier, le réordonnancement n’a pas atteint cette session, et aucune réinstallation n’aidera. Vérifiez à la fois le PATH machine et utilisateur avec [Environment]::GetEnvironmentVariable('Path','Machine') et le même appel avec 'User', car la liste effective est assemblée à partir des deux. Après une installation réussie, revérifiez avec openvpn --version et démarrez le service ou l’interface graphique une fois, car un paquet peut s’installer proprement et laisser un service qui ne démarrera pas.

Si un PATH correctement ordonné échoue encore, la variable restante est la version du paquet. Un paquet Chocolatey épinglé peut attendre une compilation GnuPG ou un chemin d’installation précis que votre machine n’a pas.

Lisez le journal propre au paquet avant de changer quoi que ce soit d’autre. C:\ProgramData\chocolatey\logs\chocolatey.log enregistre la ligne de commande qui a échoué et le répertoire depuis lequel elle a été exécutée, ce qui vous dit si l’appel en échec était une vérification de signature, une extraction ou un script post-installation. Cette distinction décide si vous déboguez encore gpg.

L’habitude qui évite une répétition est de traiter PATH comme un état partagé avec un ordre documenté plutôt que comme un sac de répertoires. Quand vous installez un outil qui embarque un nom de binaire courant, vérifiez ce qu’il masque dans le prochain shell que vous ouvrez. Notez ensuite l’ordre sur lequel vous vous êtes arrêté, car le prochain installateur y ajoutera et la prochaine personne se demandera pourquoi une vérification de signature échoue sur une machine où rien n’a changé. Un seul where.exe avant l’installation épargne toute la boucle.