خریداری میں اوپن سورس VPN کو کیوں مسترد کیا جاتا ہے
اوپن سورس پر اعتراض کرنے والا جائزہ لینے والا عام طور پر ایک تقاضے کا دفاع کرتا ہے، لائسنس کی پسند کا نہیں۔ پوچھیں کون سا، پھر وہ دستاویز تیار کریں جو اس کا جواب دیتی ہے۔
اوپن سورس کا ذکر کرنے والے مسترد فیصلے کم ہی لائسنسنگ سے متعلق ہوتے ہیں۔ جائزہ لینے والا عام طور پر ایک تقاضے کا دفاع کرتا ہے: کہ کوئی تعینات شدہ ریلیز کو برقرار رکھے، نصب شدہ بلڈ کی شناخت ہو سکے، کوئی جائزہ اس چیز کو محیط ہو جو منسلک کی جا رہی ہے، یا کنکشن واپس لیا جا سکے۔ اس کے بعد کی بحث عام طور پر ایسے سوال کا جواب دیتی ہے جو کسی نے نہیں پوچھا۔
لائسنس کا دفاع کرنے سے پہلے پوچھیں کہ کون سا تقاضا لاگو ہوتا ہے۔ جواب طے کرتا ہے کہ آپ کو کون سی دستاویز درکار ہے۔
لیبل بذات خود تقاضا نہیں
پڑھنے کے قابل سورس کوڈ کا مطلب ہے کہ شائع شدہ عمل درآمد کا جائزہ لیا جا سکتا ہے۔ اس کا مطلب یہ نہیں کہ کسی نے اس کا جائزہ لیا، کہ گیٹ وے پر بلڈ شائع شدہ سے مطابقت رکھتا ہے، یا کہ کوئی دیکھ بھال کرنے والا آپ کی تعیناتی کو اصلاح کا پابند ہے۔ ان میں سے ہر ایک الگ مالک کے ساتھ الگ دعویٰ ہے، اور جس جائزہ لینے والے کو ان میں سے ایک درکار ہو وہ باقیوں سے مطمئن نہیں ہوگا۔ دعوے کو بلند آواز میں کہنا عام طور پر گفتگو بدلنے کے لیے کافی ہوتا ہے۔
الٹی غلطی بھی اتنی ہی عام ہے۔ تجارتی لائسنس ثابت نہیں کرتا کہ معاونت اس خصوصیت کو محیط ہے جس پر آپ انحصار کرتے ہیں، کہ کسی جائزے نے اس جزو کا معائنہ کیا جو آپ تعینات کرتے ہیں، یا کہ فروش آپ کی دیکھ بھال کی مدت میں اصلاح بھیجے گا۔ لائسنسنگ تقسیم کی شرائط بیان کرتی ہے، جبکہ خریداری کے فیصلے اعتماد سے متعلق ہوتے ہیں۔ دونوں صورتوں میں لائسنس جواب کا سب سے کم معلوماتی حصہ ہے۔
کلائنٹ اور سروس کو بھی الگ رکھیں۔ ڈیسک ٹاپ کلائنٹ کا آڈٹ شریک کی گیٹ وے کنفیگریشن، اس کے شناختی فراہم کنندہ یا اس کے آپریٹرز کے اکاؤنٹ ہٹانے کے طریقے کے بارے میں کچھ نہیں کہتا۔ آپ جو بھی ثبوت جمع کریں وہ اس حد سے میل کھانا چاہیے جس پر شریک سے اعتماد کرنے کو کہا جاتا ہے۔
تشویش کو دستاویز میں بدلیں
منظوری دینے والے سے کہیں کہ تقاضا ایک جملے میں بیان کرے، پھر اس دستاویز کا نام لیں جو اسے پورا کرے گی۔ مبہم تسلی ہی ان گفتگوؤں کو نظریے کی بحث میں بدلتی ہے۔
| What the reviewer is protecting | Artifact that answers it | Who can sign it |
|---|---|---|
| The deployed release keeps getting fixes | Named maintainer, supported version list and the cadence for security releases | The operating team, with the maintainer's published policy attached |
| The build is the one that was reviewed | Package source, version string and the checksum or signature you verify at install | The team that builds or vendors the package |
| An assessment covers the right scope | Component and version assessed, findings raised, corrections made, retest date | Whoever performed the assessment |
| The access can be withdrawn | Identities granted, resources reachable, and the tested removal procedure | The service owner on the partner side |
NIST Secure Software Development Framework یہاں ایک تنگ وجہ سے مفید ہے: یہ خریداری کی گفتگوؤں کو طریقوں اور فراہم کنندگان سے رابطے کی مشترکہ اصطلاحات کے گرد ڈھالتا ہے۔ یہ لیبل پر بحث کرنے کے بجائے متعین ثبوت مانگنے کی تائید کرتا ہے، اور یہ ایسی سند نہیں جسے کوئی مخصوص VPN پاس کرتا ہو۔
غور کریں کہ درمیانی کالم کیا کرتا ہے۔ ہر قطار ایسی دستاویز مانگتی ہے جو یا موجود ہے یا نہیں، اور یہ رائے کو ایسی پیداوار میں بدل دیتا ہے جو کوئی بنا یا رد کر سکتا ہے۔
کلائنٹ کو سروس سے الگ رکھیں
کلائنٹ ایپلیکیشن کے لیے معاونت کا معاہدہ اس سرور کے بارے میں عہد نہیں جو آپ کی ٹریفک تک پہنچتا ہے۔ ثبوت پیش کرنے سے پہلے نشان زد کریں کہ راستے کے کون سے حصے شریک چلاتا ہے اور کون سے حصے آپ اس کی طرف سے چلاتے ہیں۔ دونوں کو ملانے سے ایسی دستاویزات کا مجموعہ بنتا ہے جو جامع لگتا ہے اور کسی بات کا جواب نہیں دیتا۔
اگر تعیناتی آپ کی ہے تو شریک کو شاید صرف ایک شناخت اور ایک رسائی قاعدے پر اعتماد کرنا ہو، جو آپ کی پوری سافٹ ویئر فراہمی زنجیر پر اعتماد کرنے سے بہت چھوٹی درخواست ہے۔ اگر تعیناتی اس کی ہے تو آپ کا پسندیدہ کلائنٹ غیر متعلق ہو سکتا ہے اور گیٹ وے کنفیگریشن موضوع بن جاتی ہے۔ دوسری ملاقات سے پہلے یہ طے کرنا کہ آپ کس صورت میں ہیں، ایک جائزہ چکر بچاتا ہے۔
پھر وہ عملی سوالات دیکھیں جن پر جائزے واقعی ناکام ہوتے ہیں: کون اکاؤنٹ ہٹاتا ہے، کتنی تیزی سے، اور بعد میں کیا ثبوت موجود رہتا ہے۔ ہٹانے کے طریقہ کار کے بغیر خوبصورتی سے دستاویزی جائزہ بھی کھلا نتیجہ ہی رہتا ہے۔
بحث نہیں، فیصلے پر ختم کریں
تبادلہ تحریری نتیجے پر ختم کریں: منظور شدہ ورژن، اس سے منسلک کنٹرولز، نامزد آپریٹرز، وہ ثبوت جو ابھی باقی ہیں اور وہ تاریخ جس تک وہ پیش کیے جائیں۔ کوئی بھی غیر حل شدہ بات عام منظوری کے بیان میں ضم کرنے کے بجائے شرط کے طور پر درج ہونی چاہیے۔
اگر پالیسی کسی مخصوص منظور شدہ مصنوعات کا نام لیتی ہے تو ایسا متوازی انتظام بنانے کے بجائے جس کی کسی نے اجازت نہیں دی، استثنا کا راستہ اختیار کریں۔ مؤثر تکنیکی دلیل اجازت نہیں دیتی، اور غیر رسمی تعیناتی ایسی نشاندہی ہے جو دریافت ہونے کا انتظار کرتی ہے۔
اگر کوئی تقاضا واقعی پورا نہیں ہو سکتا تو منظور شدہ متبادل پر جائیں اور بتائیں کیوں۔ اس مشق کا مقصد یہ طے کرنا ہے کہ ادارہ کس چیز پر انحصار کر سکتا ہے، اور واضح نہیں ایسی منظوری سے بہتر نتیجہ ہے جسے بعد میں کوئی بچا نہ سکے۔