أزمة eMudhra تهز Python: يجب تحديث pip وcertifi فورًا

يتضرر مستخدمو Python أكثر من غيرهم من اكتشاف أن المفاتيح الخاصة لثماني شهادات وسيطة تعود إلى جهة إصدار الشهادات الهندية eMudhra يمكن لأي شخص استعادتها. وبحسب موضوع الإرشادات المثبّت الذي فتحه مطور CPython الأساسي Seth Michael Larson في موقع النقاش الرسمي لـ Python في 20 أكتوبر، يجب على مستخدمي Python تحديث عدة حزم فورًا وإعادة بناء صور الحاويات مع تعطيل التخزين المؤقت للطبقات، وإلا فقد تبقى الأدوات التي تتصل بـ python.org وpypi.org معرضة لهجمات الوسيط (MITM). وقد تجاوزت مشاهدات الموضوع 90 ألفًا مع عشرات الردود خلال يومين.

ماذا حدث

كانت المفاتيح الخاصة لثماني شهادات وسيطة أنشأتها eMudhra في أبريل 2025 أرقامًا أصغر بكثير مما ينبغي، وكان أحدها الرقم 4 فقط. وبهذه المفاتيح كان بإمكان أي شخص إنشاء شهادات HTTPS مزيفة تبدو صالحة لأي موقع. وحجبت المتصفحات الشهادات ليلة 17 أكتوبر، وسحبت Mozilla وGoogle الثقة من شهادة الجذر ECC لدى eMudhra. لكن بعض هذه الشهادات الوسيطة كانت موقّعة توقيعًا متقاطعًا أيضًا من جذر آخر هو Comodo/Sectigo AAA Certificate Services، الذي لا يزال موجودًا في قوائم الشهادات القديمة. وهذا ما أوقع أدوات Python في المشكلة.

لماذا تتضرر Python أكثر

وزعت المتصفحات وأنظمة التشغيل قوائم الإلغاء بنفسها، أما في عالم Python فكثير من الأدوات تحمل شهادات الجذر الموثوقة الخاصة بها. وكما أوضح Christian Heimes، المساهم منذ زمن طويل في أعمال الأمان في Python، فإن pip يحمّل الشهادات الموثوقة دائمًا من نسخة certifi المدمجة فيه، ولا توجد طريقة مدعومة لتعطيل ذلك، كما أن الإشارة إلى ملف شهادات خاص لا تُبطل القائمة القديمة. ونتيجة لذلك، يستمر كل إصدار من pip أقدم من 26.2.2 في الثقة بالشهادات الوسيطة المخترقة، وبحسب Heimes فإن تحديث pip هو الحل الموثوق الوحيد.

وهذا يعني أن طرفًا وسيطًا أثناء تنفيذ pip install يستطيع انتحال PyPI بشهادة مزيفة وتقديم حزمة خبيثة. ولهذا يوصي الموضوع الرسمي بتثبيت pip من رابط مباشر مثبّت بقيمة تحقق (hash)، ما يضمن تثبيت الملف الصحيح حتى في حال هجوم الوسيط. انسخ هذا الأمر وقيمة التحقق فيه من موضوع النقاش الرسمي فقط، لا من مصادر ثانوية.

ما يجب تحديثه

أدنى الإصدارات الآمنة المذكورة في الموضوع الرسمي والإرشادات الأمنية المرتبطة به:

• certifi 2026.10.19 (تذكر الإرشادات 2026.10.18 ويوصي الموضوع بـ 2026.10.19، والإرشادات مصنفة حرجة)
• pip 26.2.2
• uv 0.13.4 (إرشادات uv نفسها مصنفة عالية الخطورة)
• conda 26.9.4، وca-certificates بالإصدار 2026.10.19 على conda-forge و2026.10.20 على قناة Anaconda
• pixi 0.82.1 وsigstore 4.5.1
• إجراء GitHub الذي يرفع الحزم إلى PyPI ‏pypi-publish 1.14.3، وأداة بناء الحزم cibuildwheel 4.3.3 و4.3.4 لـ pip على Python 3.9
• إصدارات Python التي تضم pip المصحح: 3.15.1 و3.14.9 و3.13.17

ويقدم الموضوع لمستخدمي uv خيارًا إضافيًا: ضبط UV_SYSTEM_CERTS=true يجعل uv يستخدم شهادات نظام التشغيل. ولا يوجد إعداد كهذا في pip.

بحسب نظام التشغيل

• macOS (مثبّت python.org): بحسب الموضوع، تأتي certifi ضمن هذا المثبّت ويجب تحديثها على حدة.
• macOS (Python المرفق بالنظام): بحسب صفحة الحادثة، يحجب macOS الشهادات المخترقة، لكن python3 وcurl وgit المرفقة بالنظام تعتمد على الملف /etc/ssl/cert.pem الذي لم يُحدَّث، كما يستخدم pip النظامي قائمته القديمة.
• Windows: وزعت Microsoft الحجب عبر التحديثات التلقائية، وهناك نص برمجي منفصل للأجهزة التي لا تتلقاها، لكنه غير موصى به للأجهزة التي تديرها المؤسسات.
• Linux: يعتمد الأمر على حزمة ca-certificates في التوزيعة، وقد أصدرت Ubuntu وDebian وFedora وAlpine وArch وغيرها تحديثات. وتعدّل Debian حزمة pip الخاصة بها لتستخدم شهادات النظام.

Docker وCI وملفات القفل

أفاد مستخدم في النقاش بأن صورة Docker الرسمية python:3.15-slim تأتي مع pip 26.2.1، أي أنها غير آمنة. وردّ مطورو Python الأساسيون بأن هذه الصور "الرسمية" هي صور Docker الرسمية لا صور مشروع Python، ويتولى صيانتها فريق منفصل. وكتب Barry Warsaw، عضو المجلس التوجيهي لـ Python، أن صور CI شبه الرسمية تُحدَّث تلقائيًا إلى أحدث الإصدارات، لذا يُفترض أن تكون Python 3.13 إلى 3.15 آمنة، بينما لن تكون 3.16 آمنة تمامًا قبل صدور alpha 2.

والمشاريع التي تدير تبعياتها بملفات القفل (lockfile) أو بإصدارات مثبتة لا تُصلح تلقائيًا إذا كانت قد ثبّتت إصدارًا قديمًا من certifi، كما تبقى المشاريع التي تؤخر اعتماد الإصدارات الجديدة (dependency cooldown) معرضة حتى تحدّث. ولهذا أيضًا يُطلب إعادة بناء صور الحاويات دون تخزين مؤقت، إذ قد لا يتغير pip وcertifi العالقان في طبقة قديمة حتى عند إعادة بناء الصورة.

جوهر الخلاف: 3.11 و3.12

يدور أكثر أجزاء النقاش سخونة حول Python 3.11 و3.12 اللذين لا يتلقيان سوى الإصلاحات الأمنية. فالإصدارات الأمنية لهذين الفرعين لا تحدّث pip المرفق عادة. وأوضح مدير الإصدارات Hugo van Kemenade أن pip لا يُحدَّث عادة في الإصدارات الأمنية، وأشار Thomas Wouters عضو المجلس التوجيهي إلى أن pip ليس له إصدارات أمنية منفصلة عن الميزات الجديدة والتغييرات غير المتوافقة. واحتج مستخدمون بأن من يستخدم هذين الإصدارين سيبقى غير آمن افتراضيًا، وطلبوا إصدارات مصححة لفروع pip القديمة، بينما قال مشرفو pip إنهم لا يستطيعون صيانة الفروع القديمة.

وأعلن المشرف Łukasz Langa أن مديري الإصدارات يفضلون إصلاحًا موجهًا بدل ترقية pip بالكامل، وأنهم سينشرون التفاصيل قريبًا. وفي هذا الإطار اقترح Heimes تغييرًا يضيف إلى وحدة ssl في CPython قائمة حجب للمفاتيح المعروف أنها مخترقة. وأثار الاقتراح نفسه جدلًا: فقد شدد بعض المطورين الأساسيين على أن القائمة ليست حدًا أمنيًا، وأن عبارة "حدّثوا Python" لا ينبغي أن تصبح الرد الدائم على كل حادثة مستقبلية، بينما قال Heimes إن القائمة لن تُحدَّث إلا عند اختراق جذر أو شهادة وسيطة موثوقة، وإنها مصممة كخط دفاع أخير. كما أضافت Node.js قائمة حجب مماثلة.

كيف تتحقق

• تحقق من إصدار pip بالأمر python -m pip --version ومن موقع certifi بالأمر python -m certifi.
• اتصل بعناوين الاختبار في صفحة الحادثة عبر curl؛ ظهور خطأ في الشهادة يعني أن أداتك لا تثق بالشهادات المخترقة.
• لا تنسَ كل البيئات الافتراضية (venv) على جهازك، فقد تحمل كل منها نسخة خاصة من pip وcertifi.

تستند التفاصيل إلى موضوع النقاش الرسمي لـ Python والإرشادات الأمنية لـ certifi وuv وconda وصفحة الحادثة لدى الباحث الذي أبلغ عنها. ويجب التذكير بأن المفاتيح المخترقة كانت قابلة للتخمين فعليًا منذ أبريل 2025، ولا يُعرف إن كانت قد أُسيء استخدامها خلال هذه المدة. وبخلاف المتصفحات، لا تتحقق معظم أدوات Python من سجلات شفافية الشهادات، لذا فإن تحديث شيفرة Python العاملة على الخوادم وفي خطوط CI وصور Docker القديمة أهم حتى من تحديث المتصفحات. ننصح بمتابعة تقييمات الباحثين الأمنيين المستقلين للاطلاع على زوايا أخرى.