ترقية التبعيات الانتقالية باستخدام PNPM: إصلاح الثغرات الأمنية دون كسر الأمور

في الوقت الحاضر، تُعد الثغرات الأمنية قضية شائعة في تطوير البرمجيات. لحسن الحظ، لدينا أدوات مثل GitHub Dependabot لمساعدتنا في الحفاظ على تحديث التبعيات لدينا مع الكشف التلقائي وطلبات السحب.

ومع ذلك، لا تعمل دائمًا كما هو متوقع. نظرًا لأن بعض التبعيات انتقالية، فقد يكون ترقيتها مهمة صعبة لهذه الأدوات لأنها لا تعرف أثر التغييرات وما القرار الذي يجب اتخاذه عند وجود تعارضات. نحن بحاجة إلى التعامل مع هذه الحالات يدويًا.

الطرق التي لا تعمل#

• الأوامر الرسمية مثل pnpm up ستفسد ملف pnpm-lock.yaml الخاص بك. يوجد مشكلة حول هذا لا تزال مفتوحة حتى وقت كتابة هذه السطور.
• تثبيت أحدث نسخة من التبعية المباشرة التي تحتوي على التبعية الانتقالية المستهدفة قد لا يعمل. إذا لم تقم التبعية المباشرة بترقية تعريفات النسخة، لن يتم ترقية التبعية الانتقالية نظرًا لأنها قد تم حلها وقفلها في ملف pnpm-lock.yaml.

الحل#

حقل overrides هو ميزة قوية في PNPM تسمح لك بتجاوز بعض تحديدات النسخة. سنستخدم هذه الميزة لترقية التبعيات الانتقالية وجعل التغيير بسيطًا قدر الإمكان.

لنستخدم تنبيه Dependabot أعلاه كمثال. يخبرنا أن حزمة follow-redirects تحتوي على ثغرة أمنية، وأن النسخة المرصعة هي 1.15.6. ومع ذلك، يستخدم التبعية المباشرة gatsby الحزمة axios التي تعتمد على [email protected].

الخطوة 1: العثور على التبعية الانتقالية#

توجد طرق عديدة لتحديد التبعية الانتقالية، لكنني أوصي بالطريقة الأكثر مباشرة: ابحث في ملف pnpm-lock.yaml.

ماذا عن "pnpm why"؟

الأمر pnpm why <package> مفيد بالفعل. ومع ذلك، قد يربكك في هذه الحالة. على سبيل المثال، عندما أشغل pnpm why follow-redirects، هنا جزء من المخرجات:

في الواقع، يوجد فقط تحديد واحد لـ follow-redirects في ملف pnpm-lock.yaml. قد يُظهر لك الأمر pnpm why مسارات متعددة تعتمد على نفس نسخة الحزمة.

الخطوة 2: إضافة التجاوزات#

الحالة الأسهل هي أن يكون هناك تحديد واحد فقط في ملف pnpm-lock.yaml. يمكنك إضافة التجاوز مباشرة إلى ملف package.json:

إذا كنت في مساحة عمل، يجب عليك إضافة التجاوز إلى ملف package.json في جذر مساحة العمل.

الخطوة 3: تطبيق التغييرات#

قم بتشغيل pnpm install لتطبيق التغييرات. يمكننا رؤية الحزمة follow-redirects تمت ترقيتها إلى 1.15.6 في ملف pnpm-lock.yaml بتعديلات بسيطة.

الآن يمكنك إزالة حقل overrides من ملف package.json للحفاظ عليه نظيفًا. ثم قم بتشغيل pnpm install مرة أخرى للتأكد من أنه يمكن تطبيق التغييرات بدون حقل overrides.

حل المشاكل#

الخطوات أعلاه هي الحالة المثالية. قد لا تسير الأمور دائمًا كما هو متوقع. إليك بعض النصائح لحل المشاكل:

النسخة تعيد عند إزالة حقل "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، نستخدم هذه الطريقة للحفاظ على تحديث وأمان التبعيات لدينا.