كان هجوم supply-chain على crate arrayref في Rust قصيراً ومحدوداً، لكنه مهم. بحسب Rust Security Response Team، أزيلت الإصدارات الخبيثة المرتبطة بـ arrayref و internment و append-only-vec من crates.io خلال نوافذ 86 و90 و107 دقائق. ويقول Rust blog إن maintainer الشرعي لـ arrayref لا يُعتقد أنه تصرف بسوء نية؛ الفرضية هي اختراق جهاز أو credentials. سرعة الاستجابة خبر جيد.

حزمة مشبوهة في مخطط اعتماديات open source وخط CI

لكنها ليست القصة كاملة. يهم هذا Open Source Radar لأنه يطرح سؤالاً صعباً في package managers الحديثة: عند بناء dependency، أي code يسمح له بالعمل، وأين يعمل، وبأي credentials؟ Rust ليس npm، و crates.io ليس نظاماً مهملاً. ومع ذلك، تحولت dependency صغيرة وقديمة ومملة إلى build-time execution path.

arrayref ليس إطاراً لامعاً. توثيقه يصف module صغيراً بأربع macros لأخذ array references من arrays أو slices. لذلك القضية مهمة: الخطر لا يأتي دائماً من مكتبة جديدة واضحة، بل قد يأتي من utility صغيرة ساكنة في transitive dependency graph منذ سنوات.

ماذا حدث

يقول Rust blog إن تقريراً عن crate خبيث اسمه proc-macro1 تم التحقق منه في 20 أغسطس 2026. نُشر [email protected] عند 07:15 UTC وحُذف عند 08:41:40. كان [email protected] متاحاً من 07:34:07 إلى 09:04:11. أما [email protected] فمن 07:37:49 إلى 09:25:24.

حُذفت أيضاً crates يملكها المهاجم: proc-macro1 و proc-macro-en و aovine و arone و aronenao و tinymember. أُعيدت الإصدارات الشرعية التي yanked بشكل خبيث، وأُغلق الحساب المتأثر كاحتياط. نشر GitHub Advisory Database التحذير GHSA-jwh4-228v-r358 لـ arrayref = 0.3.10، مصنفاً كـ malicious code بلا patched version.

كانت التقنية مفهومة. تشرح SafeDep وغيرها أن [email protected] أضاف dependency على الاسم typosquatted proc-macro1، وهو قريب من proc-macro2. ويقال إن crate الخبيث نسخ source حقيقياً من proc-macro2 حتى تبدو builds طبيعية بينما يعمل build script.

النقطة الأساسية هي build script. يستخدم Cargo هذه scripts لأسباب شرعية: native libraries و code generation و platform detection و configuration. لكن هذا يعني أن dependency يمكنها تنفيذ code أثناء build. إذا حدث ذلك على laptop مطور أو CI runner يحمل tokens أو SSH keys أو cloud credentials أو publishing rights، فحتى نافذة قصيرة مهمة.

لماذا النافذة القصيرة مهمة

من السهل القول إن الخطر انتهى لأنه استمر أقل من ساعتين. هذا تبسيط. CI الحديثة سريعة وتلقائية وغنية بالأسرار. dependency update أو scheduled build أو cargo update أو rebuild لصورة أو bot-managed bump قد يكفي لتشغيل code.

تشير التقارير أيضاً إلى أن إصدارات أقدم من arrayref تم yanked، ما جعل الإصدار الخبيث يبدو كمسار تحديث طبيعي لبعض workflows. metadata وسلوك registry جزء من attack surface.

الموقف الدقيق: ليس كل مشروع يستخدم arrayref compromised. لكن أي نظام بنى affected versions خلال نافذة التعرض يجب اعتباره potentially exposed حتى تراجع logs و artifacts و credentials.

ما الذي فعله Rust جيداً

كانت الاستجابة سريعة وعلنية: حذف crates الخبيثة، إعادة الإصدارات الشرعية، توثيق versions و timelines، إرشاد المستخدمين لفحص cargo caches، تنسيق RustSec و GitHub advisories، وقفل الحساب. كما أن اللغة الرسمية لم تتهم maintainer الشرعي بلا دليل.

هذا مهم في open source. الحوادث ستقع؛ جودة response تحدد هل تُصلح الثقة. يحتاج registry إلى takedown و yanking procedures و security response path و public advisories وتمييز واضح بين maintainer compromise و maintainer malice.

كما ناقش مجتمع Rust التصميم نفسه: sandboxing build scripts و allowlists و registry anomaly detection و lockfile discipline و dependency culture و containerized development. هذه هي المحادثة الصحيحة. الحادث لا يعني أن Rust uniquely unsafe؛ بل يعني أن لا ecosystem يستطيع تجاهل package-manager trust boundaries.

سؤال Cargo الصعب

Build scripts ليست خطأ. npm لديه postinstall، وPython لديه build backends، والحزم الأصلية لديها configure scripts، وRust لديه build.rs. اختار open source الراحة والقابلية للنقل والأتمتة. يلاحظ المهاجمون أن build systems تعمل مبكراً وبامتيازات أكثر مما تتوقعه الفرق.

السؤال ليس هل يجب وجودها. السؤال هو هل كل build script جديد أو متغير يجب أن يعمل بكامل الوصول افتراضياً. dependency صغيرة قد تضيف build dependency فجأة. crate قد يسحب package باسم typosquatted. build script قد يفتح network أو يقرأ environment أو يلمس files. غالباً لا يحصل developer على trust prompt واضح قبل ذلك.

يوضح Cargo issue “Build script allowlist mode” وهدف sandboxed build scripts أن المجتمع كان يفكر في هذا. حادث arrayref يعطي الموضوع استعجالاً. الحل غالباً طبقات: registry signals و allowlists و sandboxed build execution و dependency diffs تبرز new build scripts و network-deny modes في CI ومراجعة أقوى لـ yanking و ownership changes.

ماذا يجب فحصه الآن

على فرق Rust البحث عن [email protected] و [email protected] و [email protected] وcrates المحذوفة في Cargo.lock و vendored dependencies و CI logs و caches و artifact provenance. caches مهمة لأن crate قد يبقى بعد takedown.

ثم راجع builds التي عملت في 20 أغسطس 2026 ضمن النوافذ المذكورة: CI jobs و self-hosted runners و developer workstations و release builders و container image rebuilds. إذا كان build المتأثر يصل إلى secrets أو package tokens أو cloud credentials أو signing keys أو SSH material، فقم بتدوير ما قد يكون تعرض.

راجع network egress من build jobs. كثير من builds لا تحتاج خروجاً واسعاً بعد fetch dependencies. ephemeral runners و egress policies و isolated containers و short-lived credentials تقلل قيمة build-time payloads.

الأدوات تساعد بحدود. cargo audit و advisories تفيد بعد معرفة الحزمة الخبيثة. cargo deny يفرض policies. cargo vet يسجل قرارات ثقة بشرية. scanners قد تكشف سلوكاً مشبوهاً مبكراً. ولا شيء منها يغني عن sandbox.

دروس للـ maintainers و registries

يجب على maintainers تقوية publishing accounts: strong authentication و scoped tokens و least privilege و release machines منفصلة ومراقبة unexpected yanks و owner changes و releases. crate صغير قد يصبح critical infrastructure إذا اعتمدت عليه مشاريع كثيرة transitively.

على registries معاملة التغييرات الغريبة كإشارات: crate صامت سنوات يضيف build script، dependency باسم typosquatted، yanking مشبوه، أو build behavior يصل إلى network. يمكن أن تكون friction على شكل warnings أو delayed propagation أو maintainer confirmation أو automated scanning أو UI أوضح.

Tool authors لديهم فرصة: dependency diffs يجب أن تعرض trust changes، لا source changes فقط: new build scripts و proc macros و owners و native code و outbound network و yanked predecessors وأسماء تشبه حزم معروفة.

ليس Rust فقط

المقارنة مع npm postinstall attacks و PyPI typosquatting مفيدة إذا لم تتحول إلى language tribalism. لدى Rust type safety قوية وثقافة أمنية جدية، لكنها لا تمنع registry compromise أو stolen credentials أو malicious build scripts أو package-name social engineering.

الدرس العام: قراءة source code وحدها لم تعد تكفي. المهم متى يعمل code. dependency في lockfile شيء، وdependency لديها build script يعمل على CI runner يحمل release tokens شيء أكثر حساسية.

ما يستحق التجربة

راجع Cargo.lock، استخدم ephemeral runners، أخرج long-lived secrets من build jobs العامة، قيّد network بعد dependency fetch، واحتفظ بقائمة crates المسموح لها بتشغيل build scripts. للبرمجيات الحرجة جرّب cargo vet و cargo deny وتنبيهات RustSec/GitHub وscanners تنظر إلى build-time behavior.

إشارة الرادار واضحة: الحادث اختبار لـ registries و lockfiles و advisories و CI و package managers. reuse يبقى قوة عظيمة في open source، لكنه يحتاج trust model يعامل build-time code ككود حقيقي لا كحاشية بريئة.