VPN کلائنٹ ڈاؤن لوڈ کرنا ایک بار کا فیصلہ ہے؛ اس کا APT ذخیرہ شامل کرنا ایسا نہیں۔ دوسرا پیکیج منتظم کو بتاتا ہے کہ آئندہ سافٹ ویئر کہاں سے آ سکتا ہے، اور یہ ڈاؤن لوڈ نہیں بلکہ اختیار کی مستقل منتقلی ہے۔ جب فروش ذخیرہ مناسب طور پر برقرار رکھتا ہے تو یہ درست انتظام ہو سکتا ہے۔ پھر بھی یہ باخبر فیصلے کا حقدار ہے، اور زیادہ تر تنصیبی رہنما اسے چھوڑ دیتے ہیں۔

دستخط ایک محفوظ شدہ دستاویز کی تصدیق کرتے ہیں، اس کے کوڈ کی نہیں

APT دستخط شدہ ذخیرہ میٹاڈیٹا کی جانچ کرتا ہے اور پھر جو پیکیج وہ لاتا ہے ان کے لیے اسی میٹاڈیٹا کے اندر موجود چیک سم پر بھروسا کرتا ہے۔ یہ ثابت کرتا ہے کہ محفوظ شدہ دستاویز کلید کے مالک کی شائع کردہ چیز سے مطابقت رکھتی ہے، اور اندر کے کوڈ کے بارے میں کچھ نہیں۔ درست طریقے سے دستخط شدہ پیکیج میں بھی غیر محفوظ دیکھ بھال کرنے والی اسکرپٹس ہو سکتی ہیں، اور پیکیج کی تنصیب کے دوران وہ اسکرپٹس root کے طور پر چلتی ہیں۔ apt-secure رہنما محفوظ شدہ دستاویز کی تصدیق اور سافٹ ویئر کے جائزے کے درمیان ٹھیک یہی لکیر کھینچتا ہے۔

اس لیے مفید سوال یہ نہیں کہ دستخط درست ہیں یا نہیں، کیونکہ ٹوٹا ہوا دستخط بہرحال تنصیب روک دیتا ہے۔ سوال یہ ہے کہ اب سے آپ کس کے دستخط پر بھروسا کرنا چنتے ہیں۔ چوری شدہ دستخطی کلید چوری شدہ پیکیج سے بدتر ہے، کیونکہ حملہ آور پہلی خراب ریلیز کے بعد بھی طویل عرصے تک درست میٹاڈیٹا تیار کرتا رہتا ہے۔ صرف کلید کی تبدیلی ہی علاج ہے، اور یہ اس پر منحصر ہے کہ فروش ایسے ذریعے سے نئی کلید شائع کرے جسے آپ خود مختار طور پر جانچ سکیں۔

اسی لیے کلید کی شناخت ذخیرے کے URL جتنی توجہ کی حقدار ہے۔ پرانے فورم جواب میں دیے گئے پتے سے لی گئی کلید ناشر کے بارے میں کچھ ثابت نہیں کرتی، جبکہ HTTPS فون اٹھانے والے تک کی ترسیل کی حفاظت کرتا ہے۔ ترسیل کی حفاظت اور ناشر کی شناخت الگ سوالات ہیں، اور صرف پہلا ہی سرٹیفکیٹ سے حل ہوتا ہے۔

کلید کو نظام تک نہیں، ماخذ تک محدود کریں

جدید APT ماخذ کے لیے مخصوص Signed-By حوالہ قبول کرتا ہے۔ آپریٹر کے زیر انتظام کلید /etc/apt/keyrings/ کے تحت رہ سکتی ہے، اور ماخذ کا اندراج اس کلید کا نام دیتا ہے جسے اس محفوظ شدہ دستاویز کی تصدیق کی اجازت ہے۔ یہ اسی کلید کو عالمی قابل اعتماد مجموعے میں ڈالنے سے زیادہ تنگ ہے، جہاں یہ ان ماخذوں کی ضمانت دے سکتی ہے جنہیں آپ نے کبھی اجازت دینا نہیں چاہا۔ مختلف نسلوں کے رہنماؤں کے ٹکڑے ملانے کے بجائے نصب شدہ APT ورژن اور فروش کی موجودہ ہدایات کی پیروی کریں۔

curl -fsSL https://repo.example.com/vpn-key.gpg -o /etc/apt/keyrings/vpn.gpg
echo "deb [signed-by=/etc/apt/keyrings/vpn.gpg] https://repo.example.com/debian stable main" > /etc/apt/sources.list.d/vpn.list

جانچ بند کر کے یا کسی نامعلوم محفوظ شدہ دستاویز کو قابل اعتماد نشان زد کر کے دستخط کی ناکامی کبھی درست نہ کریں۔ یہ نظر آنے والی غلطی کو نظر نہ آنے والی غلطی سے بدل دیتا ہے، اور نظر نہ آنے والی تب تک رہتی ہے جب تک کوئی ماخذوں کی فہرست کا جائزہ نہ لے۔ اگر کلید مطابقت نہ رکھتی ہو تو درست حل درست کلید تلاش کرنا ہے، جانچ ہٹانا نہیں۔

ذخیرے کی تفصیلات اور کلید کی شناخت منصوبے یا زیر انتظام منتظم سے حاصل کریں۔ بلاگ پوسٹ سے نقل کی گئی کلید مصنفیت کے بارے میں دعویٰ ہے، اس کا ثبوت نہیں۔ جب فروش تبدیلی کا ذریعہ شائع کرے تو اسے کلید کے ساتھ ہی درج کریں، کیونکہ اگلی تبدیلی اسی ذریعے سے ممکن ہوتی ہے۔

ماخذ کی پننگ پیکیج کی اجازت فہرست نہیں ہے

کلید کو ایک ماخذ تک محدود کرنا یہ محدود کرتا ہے کہ وہ کس محفوظ شدہ دستاویز کی تصدیق کر سکتی ہے، یہ نہیں کہ وہ ذخیرہ کون سے پیکیج شائع کر سکتا ہے۔ ذخیرہ آپ کے مطلوبہ VPN کلائنٹ سے کہیں زیادہ بھیج سکتا ہے، اور کون سا اہل ورژن جیتے گا یہ APT کی امیدوار چناؤ اور ترجیحات طے کرتی ہیں۔ تصدیق سے پہلے تجویز کردہ معاملے کا، انحصار کی فہرست سمیت، جائزہ لیں، کیونکہ انحصار اسی ذخیرے سے آتے ہیں۔ کلید کا دائرہ ’صرف یہ پیکیج’ نہیں کہہ سکتا۔

اگر زیادہ مضبوط کنٹرول درکار ہو تو اسے پیکیج کے ناموں یا ورژنوں پر پالیسی کے طور پر بیان کریں اور وہ پالیسی ترتیب کے انتظام کے تحت رکھیں۔ معاملہ پڑھنے میں ایک منٹ لگتا ہے؛ چھ ماہ بعد غیر متوقع پیکیج دریافت کرنے میں ایک جائزہ لگتا ہے۔

غیر متوقع پیکیج آگے بڑھنے کا نہیں، رکنے کا لمحہ ہیں، اور ذخیرے کے مالک سے سوال یہ ہے کہ یہ کیوں ضروری ہیں۔ ایک کلائنٹ کے گرد درجن بھر پیکیج شائع کرنا ڈیسک ٹاپ سوٹ بھیجنے والے فروش کے لیے معمول ہے۔ یہ تنصیبی رہنما کے اشارے سے بڑی سطح بھی ہے، اور یہی حصہ درج کرنے کے قابل ہے۔ دونوں میں سے کوئی نتیجہ دستخط پر عدم اعتماد کی وجہ نہیں؛ دونوں یہ لکھنے کی وجہ ہیں کہ آپ نے کیا قبول کیا۔

اختیار اور اسے ہٹانے کا طریقہ درج کریں

ذخیرے کا مالک، معاونت یافتہ آپریٹنگ سسٹم ورژن، کلید کی تبدیلی کا ذریعہ اور ہٹانے کا طریقہ کار لکھیں۔ یہ چار حقائق ہی جانشین کو درکار ہوتے ہیں جب کلائنٹ ریٹائر ہو یا فروش اپنی کلید بدلے۔ ان کے بغیر اگلا شخص بغیر کسی کہانی کے ماخذ کی سطر اور کلید کی فائل ورثے میں پاتا ہے۔

ہٹانا ہی وہ مرحلہ ہے جو چھوڑ دیا جاتا ہے، اس لیے اسے تنصیب کے وقت ہی لکھیں۔ ماخذ کا اندراج اور اس کی مخصوص کلید اکٹھے مٹائیں، اور فائل ہٹانے سے پہلے دیکھیں کہ اس کلید کا حوالہ کہیں اور ہے یا نہیں۔ اس جانچ کے بغیر مٹائی گئی مشترکہ کلید صفائی کو غیر متعلق خلل میں بدل دیتی ہے، جو معمول کی تبدیلی کے لیے بدترین نتیجہ ہے۔ پھر تصدیق کریں کہ اندراج جانے کے بعد بھی عام اپ ڈیٹس حل ہوتے ہیں۔

ذخیرہ ہٹانے کے بعد ایک چیز باقی رہتی ہے: اس سے پہلے سے نصب کوئی بھی پیکیج تب تک چلتا رہتا ہے جب تک کوئی چیز اسے بدل نہ دے۔ ایماندار سوال یہ ہے کہ آپ نے کون سا اختیار شامل کیا، اور اس کا کردار کتنی تنگی سے بیان کیا گیا۔

متعلقہ مضامین