Instalacja OpenVPN kończy się niepowodzeniem, bo gpg Git wygrywa w PATH

Instalacja OpenVPN, która pod Chocolatey umiera z błędem podpisu lub klucza, zwykle nie jest problemem z pobieraniem. Pakiet wykonuje krok weryfikacji, który wywołuje gpg, a Windows rozwiązuje tę gołą nazwę przez PATH. Jeśli Git for Windows zainstalowano pierwszy, jego dołączony gpg.exe stoi przed kompilacją GnuPG, której oczekuje OpenVPN, i to niewłaściwy program odpowiada na wywołanie. Błąd, który widzisz, jest tym, na co ten drugi program postanowił się poskarżyć, dlatego nigdy nie wspomina prawdziwej przyczyny.

Kolejność PATH decyduje, który gpg się uruchomi

Windows nie ma centralnego rejestru nazw plików wykonywalnych. Gdy proces żąda gpg bez pełnej ścieżki, loader przechodzi przez wpisy PATH po kolei i uruchamia pierwsze dopasowanie. Git for Windows dostarcza minimalną kompilację GnuPG w swoim katalogu usr/bin, aby podpisane commity działały, a jego instalator zwykle umieszcza ten katalog blisko początku PATH użytkownika.

GnuPG instaluje się we własnym katalogu, zazwyczaj C:\Program Files (x86)\GNU\GnuPG\pub, a ten wpis może być dalej na liście lub w ogóle nie występować w PATH użytkownika. Oba programy dzielą nazwę i dużą część interfejsu wiersza poleceń, ale nie swój stan: kompilacja Git szuka pęku kluczy gdzie indziej, może być inną wersją i może nie akceptować opcji przekazywanych przez instalator. Ta niezgodność objawia się błędem podpisu lub klucza, co jest prawdziwym raportem o tym, co zobaczył niewłaściwy plik binarny. Nic w komunikacie nie wskazuje loadera, bo loader zrobił dokładnie to, co mu kazano.

Dlaczego powłoka, z której zaczynasz, decyduje o wyniku

Reguła dziedziczenia jest tą częścią, którą warto sobie przyswoić. Proces potomny otrzymuje środowisko powłoki, która go uruchomiła, więc liczy się kolejność w momencie startu Chocolatey, a nie kolejność po twojej poprawce.

Dlatego edycja PATH w oknie ustawień i ponowne uruchomienie instalacji w tym samym terminalu często nic nie zmienia: terminal zachował stare środowisko. Po każdej zmianie uruchom nową powłokę i potwierdź za pomocą where.exe gpg w tej nowej powłoce, zanim spróbujesz ponownie. To także powód, dla którego wpis na poziomie komputera może pokonać zmianę na poziomie użytkownika, ponieważ niektóre instalatory dodają na początek PATH komputera, a wpisy komputera są oceniane przed wpisami użytkownika. Jeśli oba poziomy zawierają ścieżkę GnuPG, zdecyduj, który naprawdę utrzymujesz.

Poprawka pierwsza: zmień kolejność wpisów

Dokładna poprawka polega na tym, aby wygrał zamierzony katalog GnuPG. Otwórz zmienne środowiskowe użytkownika, edytuj Path i przenieś katalog pub GnuPG ponad wpisy Git. Następnie otwórz nowe okno PowerShell, ponieważ działające nadal trzyma starą listę.

Alternatywą jest tymczasowe czyste środowisko do instalacji: usuń wpisy Git, otwórz nową powłokę, uruchom choco install openvpn, a następnie je przywróć.

Oba podejścia działają z tego samego powodu, a drugie jest bezpieczne tylko wtedy, gdy naprawdę przywrócisz wpisy. Usunięcie usr/bin Git z PATH trwale psuje podpisane commity, a następne narzędzie oczekujące działającego gpg zawodzi z własnym komunikatem, który nie ma nic wspólnego z OpenVPN. Jeśli wybierzesz drogę tymczasową, zachowaj oryginalną wartość Path w zgłoszeniu, aby przywrócenie było wklejeniem, a nie odbudową. Uporządkowanie wpisów jest trwałą poprawką; ich usunięcie to obejście z datą ważności.

Sprawdź, a potem przywróć

Sprawdź przed i po w tym samym kontekście użytkownika, którego użyje Chocolatey. where.exe gpg wymienia każde dopasowanie w kolejności rozwiązywania, więc pierwszy wiersz to ten, który zostanie uruchomiony; Get-Command gpg -All daje tę samą odpowiedź z większą szczegółowością w PowerShell. Następnie gpg --version potwierdza, która kompilacja odpowiedziała.

Jeśli where.exe nadal wymienia najpierw kopię Git, zmiana kolejności nie dotarła do tej sesji i żadne przeinstalowanie nie pomoże. Sprawdź zarówno PATH komputera, jak i użytkownika za pomocą [Environment]::GetEnvironmentVariable('Path','Machine') oraz tego samego wywołania z 'User', ponieważ skuteczna lista jest składana z obu. Po udanej instalacji sprawdź ponownie za pomocą openvpn --version i uruchom raz usługę lub GUI, ponieważ pakiet może zainstalować się czysto i mimo to pozostawić usługę, która nie wystartuje.

Jeśli poprawnie uporządkowany PATH nadal zawodzi, pozostałą zmienną jest wersja pakietu. Przypięty pakiet Chocolatey może oczekiwać konkretnej kompilacji GnuPG lub ścieżki instalacji, której twoja maszyna nie ma.

Przeczytaj własny dziennik pakietu, zanim zmienisz cokolwiek innego. C:\ProgramData\chocolatey\logs\chocolatey.log zapisuje wiersz poleceń, który zawiódł, oraz katalog, z którego go uruchomiono, co mówi ci, czy nieudane wywołanie było sprawdzeniem podpisu, rozpakowaniem czy skryptem po instalacji. Ta różnica decyduje, czy w ogóle jeszcze debugujesz gpg.

Nawyk, który zapobiega powtórce, to traktowanie PATH jako stanu współdzielonego z udokumentowaną kolejnością, a nie jako worka katalogów. Gdy instalujesz narzędzie przynoszące popularną nazwę binarnej, sprawdź, co przesłania w następnej powłoce, którą otworzysz. Następnie zapisz kolejność, na której się zatrzymałeś, ponieważ następny instalator coś do niej doda, a następna osoba będzie się zastanawiać, dlaczego sprawdzenie podpisu zawodzi na maszynie, na której nic się nie zmieniło. Jedno where.exe przed instalacją oszczędza całą pętlę.