HTTPS اور VPN آپ کے انسٹال کردہ پیکیج کی تصدیق نہیں کرتے

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

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

دو کنٹرول جو مختلف سوالات کا جواب دیتے ہیں

ٹرانسپورٹ سیکیورٹی بتاتی ہے کہ اس کنکشن کے دوسرے سرے پر کون ہے اور راستے میں کوئی اسے پڑھ یا بدل سکتا ہے یا نہیں۔ پیکیج کی تصدیق بتاتی ہے کہ یہ شے اسی اتھارٹی نے شائع کی جسے آپ نے ترتیب دیا، اور اسے ایسے آئینے سے ڈاؤن لوڈ بھی سہنا ہوگا جسے آپ کنٹرول نہیں کرتے۔

یہ سوالات صرف کناروں پر ملتے ہیں۔ آئینے پر درست سرٹیفکیٹ ثابت کرتا ہے کہ آئینہ ہی آئینہ ہے؛ یہ ثابت نہیں کرتا کہ آئینے میں ناشر کا غیر تبدیل شدہ مواد ہے۔ دستخط شدہ پیکیج ثابت کرتا ہے کہ ناشر نے اس پر دستخط کیے؛ یہ آپ کو نہیں بتاتا کہ نیٹ ورک نے تازہ ترین ورژن پہنچایا یا آپ کا بتایا ہوا مخزن وہی ہے جسے آپ کی تنظیم نے منظور کیا۔

لوگ جانچیں بند کر کے جو ناکامی کی حالت بناتے ہیں وہ دوسری ضمانت کا مستقل نقصان ہے، ایک کامیاب ڈاؤن لوڈ کے بدلے۔ یہ سودا اس دن تک نظر نہیں آتا جب یہ اہم ہوتا ہے۔

apt دراصل کس چیز کی تصدیق کرتا ہے

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

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

apt-get update
apt-cache policy
apt-config dump | grep -iE 'AllowInsecure|AllowDowngrade'

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

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

dnf5 الگ کیا جانچتا ہے

RPM کا پہلو دو مختلف سوئچ پیش کرتا ہے، اور انہیں ملانا مخالف سمت میں اسی قسم کی غلطی پیدا کرتا ہے۔ ایک کنٹرول کرتا ہے کہ پیکیج فائلوں پر درست دستخط ہوں یا نہیں؛ دوسرا کہ مخزن کا میٹاڈیٹا دستخط شدہ ہو یا نہیں۔ انہیں آزادانہ مقرر کیا جا سکتا ہے، اور کوئی نظام ایک میں سخت اور دوسرے میں نرم ہو سکتا ہے۔

dnf5 config-manager --dump 2>/dev/null | grep -iE 'gpgcheck|repo_gpgcheck'
rpm -q --qf '%{NAME} %{SIGPGP:pgpsig}\n' bash

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

جہاں دونوں منتظم مختلف ہیں وہاں فرق تعمیراتی ہے، یہ اشارہ نہیں کہ کوئی کمزور ہے۔ دونوں ناشر کے مواد کی تصدیق کرتے ہیں؛ وہ دستخط کو سلسلے کے مختلف مقامات پر رکھتے ہیں۔

سرنگ کیا شامل کرتی ہے اور کیا نہیں

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

HTTPS اپنی ضمانت شامل کرتا ہے، اور وہ محسوس ہونے سے زیادہ تنگ ہے۔ یہ اُس TLS سرے کی تصدیق کرتا ہے جس سے آپ جڑے۔ اگر وہ سرا آئینہ ہے تو آپ نے آئینے کی تصدیق کی، اُس آرکائیو مواد کی نہیں جو وہ پیش کرتا ہے۔ دستخط شدہ میٹاڈیٹا کا سلسلہ بالکل اسی صورت کے لیے موجود ہے۔

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

ناکام حد کی تشخیص کریں

کچھ بھی بدلنے سے پہلے مرحلے کا نام لیں: DNS حل، پراکسی یا راستہ، TLS سرے کی شناخت، آرکائیو کی تصدیق، پیکیج دستخط کی جانچ، یا تنصیب۔ ہر ایک کی الگ غلطی کی شکل اور الگ مالک ہے۔

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

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