התקנת OpenVPN נכשלת כי ה-gpg של Git מנצח ב-PATH

התקנת OpenVPN שמתה תחת Chocolatey עם שגיאת חתימה או מפתח היא בדרך כלל לא בעיית הורדה. החבילה מריצה שלב אימות שקורא ל-gpg, ו-Windows פותר את השם החשוף הזה דרך PATH. אם Git for Windows הותקן ראשון, ה-gpg.exe המצורף שלו עומד לפני בניית ה-GnuPG ש-OpenVPN מצפה לה, והתוכנה הלא נכונה עונה לקריאה. השגיאה שאתם רואים היא מה שאותה תוכנה אחרת החליטה להתלונן עליו, ולכן היא אף פעם לא מזכירה את הסיבה האמיתית.

סדר ה-PATH קובע איזה gpg ירוץ

ל-Windows אין מרשם מרכזי של שמות קבצי הרצה. כשתהליך מבקש gpg בלי נתיב מלא, הטוען עובר על ערכי PATH לפי הסדר ומריץ את ההתאמה הראשונה. Git for Windows מספק בניית GnuPG מינימלית בתוך תיקיית usr/bin שלו כדי שקומיטים חתומים יעבדו, והמתקין שלו בדרך כלל ממקם את התיקייה הזו סמוך לתחילת ה-PATH של המשתמש.

GnuPG מתקין בתיקייה משלו, בדרך כלל C:\Program Files (x86)\GNU\GnuPG\pub, והערך הזה עשוי להיות מאוחר יותר ברשימה או חסר לגמרי מה-PATH של המשתמש. שתי התוכנות חולקות שם וחלק ניכר מממשק שורת פקודה, אבל לא את המצב שלהן: בניית Git מחפשת מחזיק מפתחות במקום אחר, עשויה להיות גרסה אחרת, ועשויה לא לקבל את האפשרויות שהמתקין מעביר. אי-ההתאמה הזו מופיעה כשגיאת חתימה או מפתח, וזה דיווח אמיתי על מה שהבינארי הלא נכון ראה. שום דבר בהודעה לא מצביע על הטוען, כי הטוען עשה בדיוק מה שנאמר לו.

למה המעטפת שממנה אתם מתחילים קובעת את התוצאה

כלל הירושה הוא החלק ששווה להפנים. תהליך בן מקבל את הסביבה של המעטפת שהפעילה אותו, ולכן הסדר שחשוב הוא הסדר ברגע ש-Chocolatey מתחיל, לא הסדר אחרי שתתקנו אותו.

לכן עריכת PATH בחלון הגדרות והרצה חוזרת של ההתקנה באותו מסוף לרוב לא משנה דבר: המסוף שמר את הסביבה הישנה. התחילו מעטפת חדשה אחרי כל עריכה, ואמתו עם where.exe gpg באותה מעטפת חדשה לפני שתנסו שוב. זו גם הסיבה שערך ברמת המחשב יכול לנצח שינוי ברמת המשתמש, מכיוון שכמה מתקינים מוסיפים לתחילת ה-PATH של המחשב וערכי מחשב מוערכים לפני ערכי משתמש. אם שתי הרמות מכילות נתיב GnuPG, החליטו איזו מהן אתם באמת מתחזקים.

תיקון ראשון: סדרו מחדש את הערכים

התיקון המדויק הוא לגרום לתיקיית ה-GnuPG הרצויה לנצח. פתחו את משתני הסביבה של המשתמש, ערכו את Path, והעבירו את תיקיית ה-pub של GnuPG מעל ערכי Git. אחר כך פתחו חלון PowerShell חדש, כי החלון שרץ עדיין מחזיק ברשימה הישנה.

החלופה היא סביבה נקייה זמנית להתקנה: הסירו את ערכי Git, פתחו מעטפת חדשה, הריצו choco install openvpn, ואז החזירו אותם.

שתי הגישות עובדות מאותה סיבה, והשנייה בטוחה רק אם אתם באמת מחזירים את הערכים. הסרת ה-usr/bin של Git מה-PATH שוברת לצמיתות קומיטים חתומים, והכלי הבא שמצפה ל-gpg עובד נכשל עם הודעה משלו שאין לה שום קשר ל-OpenVPN. אם אתם בוחרים במסלול הזמני, שמרו את הערך המקורי של Path בכרטיס כדי שהשחזור יהיה הדבקה ולא בנייה מחדש. סידור הערכים הוא התיקון המתמשך; מחיקתם היא עקיפה עם תאריך תפוגה.

אמתו, ואז החזירו למקום

אמתו לפני ואחרי באותו הקשר משתמש ש-Chocolatey ישתמש בו. where.exe gpg מפרט כל התאמה לפי סדר פתרון, ולכן השורה הראשונה היא זו שתרוץ; Get-Command gpg -All נותן את אותה תשובה עם יותר פירוט ב-PowerShell. אחר כך gpg --version מאשר איזו בנייה ענתה.

אם where.exe עדיין מפרט את עותק Git ראשון, הסידור מחדש לא הגיע לאותה הפעלה, ושום התקנה מחדש לא תעזור. בדקו גם את ה-PATH של המחשב וגם של המשתמש עם [Environment]::GetEnvironmentVariable('Path','Machine') ואותה קריאה עם 'User', כי הרשימה האפקטיבית מורכבת משניהם. אחרי התקנה מוצלחת, בדקו שוב עם openvpn --version והפעילו את השירות או ה-GUI פעם אחת, מכיוון שחבילה יכולה להתקין נקי ובכל זאת להשאיר שירות שלא יעלה.

אם PATH מסודר כהלכה עדיין נכשל, המשתנה שנותר הוא גרסת החבילה. חבילת Chocolatey מוצמדת עשויה לצפות לבניית GnuPG או לנתיב התקנה מסוימים שאין למחשב שלכם.

קראו את היומן של החבילה עצמה לפני שתשנו כל דבר אחר. C:\ProgramData\chocolatey\logs\chocolatey.log מתעד את שורת הפקודה שנכשלה ואת התיקייה שממנה רצה, מה שאומר לכם אם הקריאה שנכשלה הייתה בדיקת חתימה, חילוץ או סקריפט לאחר התקנה. ההבחנה הזו קובעת אם אתם בכלל עוד מנתחים את gpg.

ההרגל שמונע חזרה על עצמו הוא להתייחס ל-PATH כאל מצב משותף עם סדר מתועד ולא כשקית של תיקיות. כשאתם מתקינים כלי שמביא איתו שם בינארי נפוץ, בדקו מה הוא מסתיר במעטפת הבאה שתפתחו. אחר כך כתבו את הסדר שהחלטתם עליו, כי המתקין הבא יוסיף לו והאדם הבא יתהה למה בדיקת חתימה נכשלת במחשב שבו שום דבר לא השתנה. where.exe אחד לפני ההתקנה חוסך את כל הלולאה.