Installationen av OpenVPN misslyckas eftersom Gits gpg vinner på PATH

En OpenVPN-installation som dör under Chocolatey med ett signerings- eller nyckelfel är vanligtvis inte ett nedladdningsproblem. Paketet kör ett verifieringssteg som anropar gpg, och Windows löser det bara namnet via PATH. Om Git for Windows installerades först står dess medföljande gpg.exe före den GnuPG-build som OpenVPN förväntar sig, och fel program svarar på anropet. Felet du ser är det som det andra programmet bestämde sig för att klaga på, och därför nämner det aldrig den egentliga orsaken.

Ordningen i PATH avgör vilken gpg som körs

Windows har inget centralt register över körbara namn. När en process begär gpg utan fullständig sökväg går inläsaren igenom PATH-posterna i ordning och kör den första träffen. Git for Windows levererar en minimal GnuPG-build i sin usr/bin-katalog så att signerade commits fungerar, och dess installationsprogram placerar vanligtvis den katalogen nära början av användarens PATH.

GnuPG installeras i sin egen katalog, vanligtvis C:\Program Files (x86)\GNU\GnuPG\pub, och den posten kan ligga längre ner i listan eller saknas helt i användarens PATH. De två programmen delar ett namn och en stor del av ett kommandoradsgränssnitt men inte sitt tillstånd: Git-bygget letar efter en nyckelring någon annanstans, kan vara en annan version och kanske inte accepterar de alternativ som installationsprogrammet skickar. Den missanpassningen visar sig som ett signerings- eller nyckelfel, vilket är en sanningsenlig rapport om vad den felaktiga binärfilen såg. Inget i meddelandet pekar på inläsaren, eftersom inläsaren gjorde precis det den blev tillsagd.

Varför skalet du startar från avgör resultatet

Ärvningsregeln är den del som är värd att internalisera. En underordnad process får miljön från skalet som startade den, så ordningen som spelar roll är ordningen i det ögonblick då Chocolatey startar, inte ordningen efter att du har rättat den.

Det är därför redigering av PATH i ett inställningsfönster och omkörning av installationen i samma terminal ofta inte ändrar något: terminalen behöll den gamla miljön. Starta ett nytt skal efter varje ändring och bekräfta med where.exe gpg i det nya skalet innan du försöker igen. Det är också därför en post på maskinnivå kan slå en ändring på användarnivå, eftersom vissa installationsprogram lägger till i början av maskinens PATH och maskinposter utvärderas före användarposter. Om båda nivåerna innehåller en GnuPG-sökväg måste du bestämma vilken du faktiskt underhåller.

Rättelse ett: ordna om posterna

Den exakta rättelsen är att låta den avsedda GnuPG-katalogen vinna. Öppna miljövariablerna för användaren, redigera Path och flytta GnuPG-pub-katalogen ovanför Git-posterna. Öppna sedan ett nytt PowerShell-fönster, eftersom det som körs fortfarande håller den gamla listan.

Alternativet är en tillfällig ren miljö för installationen: ta bort Git-posterna, öppna ett nytt skal, kör choco install openvpn och återställ dem sedan.

Båda tillvägagångssätten fungerar av samma skäl, och det andra är bara säkert om du faktiskt återställer posterna. Att ta bort Gits usr/bin från PATH bryter signerade commits permanent, och nästa verktyg som förväntar sig en fungerande gpg misslyckas med sitt eget meddelande som inte har något med OpenVPN att göra. Om du tar den tillfälliga vägen, behåll det ursprungliga värdet av Path i ärendet så att återställningen är en inklistring och inte en återuppbyggnad. Att ordna posterna är den varaktiga rättelsen; att ta bort dem är en kringgång med utgångsdatum.

Verifiera och sätt sedan tillbaka

Verifiera före och efter i samma användarkontext som Chocolatey kommer att använda. where.exe gpg listar varje träff i upplösningsordning, så den första raden är den som körs; Get-Command gpg -All ger samma svar med mer detalj i PowerShell. Sedan bekräftar gpg --version vilken build som svarade.

Om where.exe fortfarande listar Git-kopian först har omordningen inte nått den sessionen, och ingen mängd ominstallation hjälper. Kontrollera både maskin- och användar-PATH med [Environment]::GetEnvironmentVariable('Path','Machine') och samma anrop med 'User', eftersom den effektiva listan sätts samman från båda. Efter en lyckad installation, kontrollera igen med openvpn --version och starta tjänsten eller GUI:t en gång, eftersom ett paket kan installeras rent och ändå lämna en tjänst som inte startar.

Om en korrekt ordnad PATH fortfarande misslyckas är den återstående variabeln paketversionen. Ett fastnålat Chocolatey-paket förväntar sig kanske en viss GnuPG-build eller installationssökväg som din maskin inte har.

Läs paketets egen logg innan du ändrar något annat. C:\ProgramData\chocolatey\logs\chocolatey.log registrerar kommandoraden som misslyckades och katalogen den kördes från, vilket talar om för dig om det misslyckade anropet var en signeringskontroll, en uppackning eller ett skript efter installationen. Den skillnaden avgör om du överhuvudtaget fortfarande felsöker gpg.

Vanan som förhindrar en upprepning är att behandla PATH som delat tillstånd med en dokumenterad ordning i stället för som en påse med kataloger. När du installerar ett verktyg som medför ett vanligt binärnamn, kontrollera vad det skuggar i nästa skal du öppnar. Skriv sedan ner ordningen du landade på, eftersom nästa installationsprogram lägger till i den och nästa person kommer att undra varför en signeringskontroll misslyckas på en maskin där ingenting har ändrats. Ett enda where.exe före installationen sparar hela loopen.