يفشل تحديث 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 لذلك المستودع. وتخصّص الصفحة ذلك لسياق محلي، إن استُخدم أصلًا.

هذا ليس نسخة أضيق من الوثوق بالمورّد. إنه يزيل سؤال من وقّع الفهرس، لذا يمكن لأي شخص يستطيع الإجابة عن ذلك الاسم المضيف أن يسلّم جهازك حزمًا تُثبّت بصلاحيات الجذر.

مسار الإصلاح: اجلب المفتاح ثم ثبّته

اجلب المفتاح من المكان الذي يوثّقه المورّد وأزل تغليفه إلى حلقة مفاتيح يديرها المسؤول، ثم وجّه سطر المستودع إلى ذلك الملف حتى لا تنزلق الثقة.

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 على أي حال؛ فهو الترتيب الذي يوثّقه الدليل، وهو الذي يبقى بعد الترقية.