עדכון apt נכשל עם NO_PUBKEY לאחר הוספת מאגר VPN

מקור ה-apt של ספק ה-VPN שלכם שבר את מנהל החבילות, והתיקון הוא החלטה, לא פקודה. NO_PUBKEY, או תלונה שלמאגר אין קובץ Release, פירושה ש-apt סירב לתת אמון באותו מקור, ולכן כל פעולת חבילה מאוחרת ממשיכה להדפיס את אותה אזהרה. המנהרה עצמה כנראה חפה מפשע. ענו על שלוש שאלות אם אתם עדיין רוצים את המקור הזה, והתיקון הנכון מגיע כמעט באופן מכני.

ראשית, שימו את התקלה בקטגוריה הנכונה

כשל אמון נוקב בשם קובץ המקור ובמפתח החסר או בקובץ ה-Release החסר. כשל תעבורה נראה אחרת: שגיאות תעודת TLS, חיבור שנדחה, פסקי זמן, או פרוקסי שמסרב ל-CONNECT. ההבחנה הזו קובעת איזה מאמר אתם קוראים, כי VPN שחוטף TLS או חוסם את המארח של הספק מייצר שגיאות תעבורה, לא שגיאות חתימה.

הריצו sudo apt update לבד וקראו את הסוף, תוך התעלמות מהתוצאות השמורות למעלה. השורה החשובה נוקבת ב-/etc/apt/sources.list.d/ ואומרת לכם איזה קובץ לפתוח.

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

שלוש שאלות שבוחרות את המסלול

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

שנית, האם הספק מפרסם מפתח וטביעת אצבע שתוכלו לאמת מחוץ לערוץ? שלישית, מי מנהל מפתחות במארח הזה: ההפצה או אתם? מקור שחתום במפתח שאינכם יכולים לאמת הוא סמכות עדכון שלא כדאי להעניק.

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

למה trusted=yes נראה כמו תיקון ואינו כזה

עמוד המדריך של sources.list אומר זאת ישירות. הגדרת האפשרות Trusted ל-yes אומרת ל-apt לקבל את המקור גם כשהוא נכשל באימות, מה שמכבה את apt-secure לאותו מאגר. העמוד שומר זאת להקשר מקומי, אם בכלל משתמשים בכך.

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

מסלול תיקון: השיגו את המפתח ואז הצמידו אותו

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

1. קראו את השורה שנכשלת כדי לקבל את מזהה המפתח ואת שם קובץ המקור.
2. הורידו את המפתח המשוריין ב-ASCII של הספק והריצו gpg --dearmor אל /etc/apt/keyrings/vendor-name.gpg.
3. הוסיפו [signed-by=/etc/apt/keyrings/vendor-name.gpg] לרשומה בקובץ .list של אותו ספק.
4. הריצו sudo apt update ואשרו שהמקור מביא אינדקס במקום לחזור על אזהרת החתימה.

העדיפו /usr/share/keyrings למפתחות שמגיעים עם חבילה ו-/etc/apt/keyrings למפתחות שאתם מציבים ביד. החלוקה אינה קוסמטית: היא אומרת למנהל הבא אילו מפתחות ישרדו שדרוג חבילה ואילו זקוקים לאדם.

אמתו את טביעת האצבע מול הערך המפורסם של הספק לפני שאתם נותנים בה אמון. מזהה מפתח שהודבק מהודעה בפורום הוא הדרך שבה מחשב מתחיל לתת אמון בסמכות עדכון שאיש אינו יכול לנקוב בשמה.

מסלול הסרה, ולמה השגיאה יכולה לחזור

הסתכלו מה המתקין באמת כתב, כי כמה קבצים יכולים להזכיר את אותו ספק ואחד מהם הוא בדרך כלל עותק שנשאר.

grep -r . /etc/apt/sources.list.d/
sudo rm /etc/apt/sources.list.d/vendor.list

apt קורא רק קבצי .list ו-.sources מהתיקייה הזו, ולכן עותק .save או .distUpgrade כבר מתעלמים ממנו; מחיקתו בכל זאת מונעת מקורא מאוחר לשחזר אותו בטעות. הסרת המקור אינה מסירה התקנות, ו-apt עשוי אז לתאר את חבילת ה-VPN המותקנת כמותקנת מקומית או כלא זמינה יותר, וזו הודעת מצב חבילה ולא חזרת שגיאת האמון.

המקרה החוזר הוא הנחיה ישנה יותר שהתקינה מפתחות עם apt-key לטבעת האמון הגלובלית. המסלול הזה הוצא משימוש, ושדרוג גרסה יכול להשאיר את המפתח מושלך או פשוט לא נבדק, וזו בדיוק הסיבה ששגיאה ששתקה שנה מופיעה בשבוע שבו אתם משדרגים. בדקו את /etc/apt/trusted.gpg.d/, ואז העבירו את החלטת האמון לשורת המאגר שאליה היא שייכת. אם הספק עדיין מדפיס הוראות apt-key, השתמשו ב-signed-by בכל זאת; זה הסידור שהמדריך מתעד, וזה ששורד שדרוג.