L’installazione di OpenVPN fallisce perché il gpg di Git vince nel PATH

Un’installazione di OpenVPN che muore sotto Chocolatey con un errore di firma o di chiave di solito non è un problema di download. Il pacchetto esegue un passaggio di verifica che richiama gpg, e Windows risolve quel nome nudo tramite PATH. Se Git for Windows è stato installato per primo, il suo gpg.exe incluso si trova davanti alla build di GnuPG che OpenVPN si aspetta, e il programma sbagliato risponde alla chiamata. L’errore che vedete è ciò di cui quell’altro programma ha deciso di lamentarsi, ed è per questo che non menziona mai la causa reale.

L’ordine del PATH decide quale gpg viene eseguito

Windows non ha un registro centrale dei nomi degli eseguibili. Quando un processo chiede gpg senza un percorso completo, il loader percorre le voci di PATH in ordine ed esegue la prima corrispondenza. Git for Windows fornisce una build minima di GnuPG nella sua directory usr/bin perché i commit firmati funzionino, e il suo installer di solito colloca quella directory vicino all’inizio del PATH dell’utente.

GnuPG si installa nella propria directory, di solito C:\Program Files (x86)\GNU\GnuPG\pub, e quella voce può trovarsi più avanti nell’elenco o mancare del tutto dal PATH dell’utente. I due programmi condividono un nome e gran parte di un’interfaccia a riga di comando, ma non il loro stato: la build di Git cerca un portachiavi altrove, può essere una versione diversa e può non accettare le opzioni che l’installer passa. Questa discrepanza si manifesta come errore di firma o di chiave, che è un resoconto veritiero di ciò che ha visto il binario sbagliato. Nulla nel messaggio indica il loader, perché il loader ha fatto esattamente ciò che gli era stato detto.

Perché la shell da cui partite decide il risultato

La regola di ereditarietà è la parte che vale la pena interiorizzare. Un processo figlio riceve l’ambiente della shell che lo ha avviato, quindi l’ordine che conta è quello nel momento in cui parte Chocolatey, non quello dopo la vostra correzione.

Ecco perché modificare PATH in una finestra delle impostazioni e rieseguire l’installazione nello stesso terminale spesso non cambia nulla: il terminale ha conservato il vecchio ambiente. Avviate una nuova shell dopo ogni modifica e confermate con where.exe gpg in quella nuova shell prima di riprovare. È anche il motivo per cui una voce a livello di macchina può battere una modifica a livello utente, dato che alcuni installer antepongono al PATH della macchina e le voci di macchina vengono valutate prima di quelle utente. Se entrambi i livelli contengono un percorso GnuPG, decidete quale state effettivamente mantenendo.

Correzione uno: riordinate le voci

La correzione precisa è far vincere la directory GnuPG desiderata. Aprite le variabili d’ambiente dell’utente, modificate Path e spostate la directory pub di GnuPG sopra le voci di Git. Poi aprite una nuova finestra di PowerShell, perché quella in esecuzione tiene ancora il vecchio elenco.

L’alternativa è un ambiente pulito temporaneo per l’installazione: rimuovete le voci di Git, aprite una nuova shell, eseguite choco install openvpn, poi ripristinatele.

Entrambi gli approcci funzionano per lo stesso motivo, e il secondo è sicuro solo se ripristinate davvero le voci. Rimuovere il usr/bin di Git da PATH rompe definitivamente i commit firmati, e il successivo strumento che si aspetta un gpg funzionante fallisce con un messaggio proprio che non ha nulla a che fare con OpenVPN. Se prendete la via temporanea, conservate il valore originale di Path nel ticket così il ripristino è un incolla e non una ricostruzione. Ordinare le voci è la correzione duratura; eliminarle è un aggiramento con una scadenza.

Verificate, poi rimettete a posto

Verificate prima e dopo nello stesso contesto utente che userà Chocolatey. where.exe gpg elenca ogni corrispondenza in ordine di risoluzione, quindi la prima riga è quella che verrà eseguita; Get-Command gpg -All dà la stessa risposta con più dettagli in PowerShell. Poi gpg --version conferma quale build ha risposto.

Se where.exe elenca ancora la copia di Git per prima, il riordino non ha raggiunto quella sessione, e nessuna reinstallazione aiuterà. Controllate sia il PATH di macchina sia quello utente con [Environment]::GetEnvironmentVariable('Path','Machine') e la stessa chiamata con 'User', perché l’elenco effettivo è composto da entrambi. Dopo un’installazione riuscita, ricontrollate con openvpn --version e avviate una volta il servizio o la GUI, dato che un pacchetto può installarsi pulito e lasciare comunque un servizio che non partirà.

Se un PATH correttamente ordinato fallisce ancora, la variabile rimanente è la versione del pacchetto. Un pacchetto Chocolatey bloccato può aspettarsi una build GnuPG o un percorso di installazione precisi che la vostra macchina non ha.

Leggete il registro proprio del pacchetto prima di cambiare qualsiasi altra cosa. C:\ProgramData\chocolatey\logs\chocolatey.log registra la riga di comando che ha fallito e la directory da cui è stata eseguita, il che vi dice se la chiamata fallita era un controllo di firma, un’estrazione o uno script post-installazione. Questa distinzione decide se state ancora debuggando gpg.

L’abitudine che evita una ripetizione è trattare PATH come uno stato condiviso con un ordine documentato invece che come un sacco di directory. Quando installate uno strumento che porta un nome di binario comune, controllate cosa oscura nella successiva shell che aprite. Poi annotate l’ordine su cui vi siete stabilizzati, perché il prossimo installer vi aggiungerà e la prossima persona si chiederà perché un controllo di firma fallisce su una macchina dove nulla è cambiato. Un solo where.exe prima dell’installazione risparmia tutto il ciclo.