قد تكون إصلاح الثغرات الأمنية مهمة مُحبطة، خاصة عندما تتعلق بالتبعيات الانتقالية. تعلم كيفية ترقيتها دون التأثير على التبعيات المباشرة.
في الوقت الحاضر، تُعد الثغرات الأمنية قضية شائعة في تطوير البرمجيات. لحسن الحظ، لدينا أدوات مثل GitHub Dependabot لمساعدتنا في الحفاظ على تحديث التبعيات لدينا مع الكشف التلقائي وطلبات السحب.
ومع ذلك، لا تعمل دائمًا كما هو متوقع. نظرًا لأن بعض التبعيات انتقالية، فقد يكون ترقيتها مهمة صعبة لهذه الأدوات لأنها لا تعرف أثر التغييرات وما القرار الذي يجب اتخاذه عند وجود تعارضات. نحن بحاجة إلى التعامل مع هذه الحالات يدويًا.
pnpm up ستفسد ملف pnpm-lock.yaml الخاص بك. يوجد مشكلة حول هذا لا تزال مفتوحة حتى وقت كتابة هذه السطور.pnpm-lock.yaml.حقل overrides هو ميزة قوية في PNPM تسمح لك بتجاوز بعض تحديدات النسخة. سنستخدم هذه الميزة لترقية التبعيات الانتقالية وجعل التغيير بسيطًا قدر الإمكان.
لنستخدم تنبيه Dependabot أعلاه كمثال. يخبرنا أن حزمة follow-redirects تحتوي على ثغرة أمنية، وأن النسخة المرصعة هي 1.15.6. ومع ذلك، يستخدم التبعية المباشرة gatsby الحزمة axios التي تعتمد على [email protected].
توجد طرق عديدة لتحديد التبعية الانتقالية، لكنني أوصي بالطريقة الأكثر مباشرة: ابحث في ملف pnpm-lock.yaml.
ماذا عن "pnpm why"؟
الأمر pnpm why <package> مفيد بالفعل. ومع ذلك، قد يربكك في هذه الحالة. على سبيل المثال، عندما أشغل pnpm why follow-redirects، هنا جزء من المخرجات:
في الواقع، يوجد فقط تحديد واحد لـ follow-redirects في ملف pnpm-lock.yaml. قد يُظهر لك الأمر pnpm why مسارات متعددة تعتمد على نفس نسخة الحزمة.
الحالة الأسهل هي أن يكون هناك تحديد واحد فقط في ملف pnpm-lock.yaml. يمكنك إضافة التجاوز مباشرة إلى ملف package.json:
إذا كنت في مساحة عمل، يجب عليك إضافة التجاوز إلى ملف package.json في جذر مساحة العمل.
قم بتشغيل pnpm install لتطبيق التغييرات. يمكننا رؤية الحزمة follow-redirects تمت ترقيتها إلى 1.15.6 في ملف pnpm-lock.yaml بتعديلات بسيطة.
الآن يمكنك إزالة حقل overrides من ملف package.json للحفاظ عليه نظيفًا. ثم قم بتشغيل pnpm install مرة أخرى للتأكد من أنه يمكن تطبيق التغييرات بدون حقل overrides.
الخطوات أعلاه هي الحالة المثالية. قد لا تسير الأمور دائمًا كما هو متوقع. إليك بعض النصائح لحل المشاكل:
قد يحدث هذا عندما تحتوي الحزمة التابعة على نسخة ثابتة أو مدى لا يشمل النسخة المستهدفة. تحقق من ملف package.json الخاص بالحزمة التابعة، في هذه الحالة، axios، لترى إذا كان هذا ينطبق.
إذا كان الأمر كذلك، تحتاج إلى الاحتفاظ بحقل overrides في ملف package.json حتى تقوم الحزمة التابعة بترقية تعريفات النسخة.
مع توسع المشروع، قد يتضخم ملف pnpm-lock.yaml بتحديدات متعددة لنفس الحزمة. على سبيل المثال، قد يكون هناك نسختان رئيسيتان من نفس الحزمة foo:
التقرير عن الثغرات الأمنية يُظهر أن [email protected] يحتوي على ثغرة أمنية تم إصلاحها في 1.0.1، و[email protected] غير متأثر.
لا يمكننا ببساطة إضافة تجاوز لـ foo:
"foo": "^1.0.1"، سيتم خفض [email protected] إلى 1.0.1. قد يؤدي هذا إلى كسر المشروع لأن [email protected] قد يحتوي على بعض المزايا الجديدة التي تُستخدم في الحزم التابعة."foo": "^2.0.0"، سيتم ترقية [email protected] إلى 2.0.0. قد يؤدي هذا إلى كسر المشروع لأن [email protected] قد يحتوي على بعض التغييرات الكبيرة.بالنظر إلى أن foo يتبع الإصدارات الدلالية، يمكننا إضافة تجاوز مثل هذا:
سيؤدي هذا إلى ترقية [email protected] إلى 1.0.1 مع إبقاء [email protected] دون تغيير.
قبل أن يدعم PNPM ترقية التبعيات الانتقالية مباشرة، يُعتبر حقل overrides حلاً مؤقتًا جيدًا لإصلاح الثغرات الأمنية دون كسر الأمور. آمل أن يساعدك هذا المقال في التعامل مع هذه الحالات بكفاءة أكبر. في Logto، نستخدم هذه الطريقة للحفاظ على تحديث وأمان التبعيات لدينا.