Miri کش‌های CI در Rust را به مرز مدیریت اسرار تبدیل می‌کند

یک اطلاعیه امنیتی تازه در Rust نگاه تیم‌ها به کش CI را تغییر می‌دهد: وقتی Miri در میان باشد، target/ فقط یک ابزار افزایش سرعت نیست؛ می‌تواند به مرز مدیریت اسرار تبدیل شود.

تیم پاسخ‌گویی امنیتی Rust اعلام کرد که Miri برای استفاده مجدد در اجراهای بعدی، همه متغیرهای محیطی را در target/ ذخیره می‌کرد. اگر workflow همین پوشه را cache می‌کرد، اسراری که در محیط وجود داشتند می‌توانستند در کش باقی بمانند و برای workflowهای pull request قابل دسترسی شوند. این وضعیت به ترکیبی مشخص نیاز داشت: CI باید cargo miri را اجرا می‌کرد، مرحله Miri باید به اسرار دسترسی می‌داشت و کش target/ نیز باید برای pull requestها قابل بازیابی می‌بود.

این مدل برای توسعه‌دهندگان ICP مهم است، چون مخزن‌های canister معمولاً با کش وابستگی‌ها و build در CI زمان اجرا را کاهش می‌دهند. بازیابی کش می‌تواند چند دقیقه صرفه‌جویی کند، اما هم‌زمان طول عمر و دامنه دسترسی فایل‌های تولیدشده در فرایند build را تغییر می‌دهد. یک pull request لازم نیست کش را تغییر دهد؛ ممکن است فقط به مجوز بازیابی artifactای که قبلاً ذخیره شده نیاز داشته باشد.

راه‌حل کوتاه‌مدت تیم Rust این است که Miri فقط متغیرهای محیطی CARGO_* ــ به‌جز CARGO_*_TOKEN ــ و OUT_DIR را حفظ کند. این اطلاعیه می‌گوید اصلاحیه برای nightly مورخ ۲۲ سپتامبر ۲۰۲۶ برنامه‌ریزی شده بود، اما تیم‌ها باید toolchain واقعی خود را بررسی کنند و صرفاً فرض نکنند که اصلاحیه در آن وجود دارد.

برای مخزنی که از Miri در GitHub Actions استفاده می‌کند، اقدام عملی روشن است:

• اسرار را در اختیار مرحله Miri قرار ندهید.
• کش target/ را برای آن job غیرفعال کنید یا کش را به فایل‌هایی محدود کنید که نمی‌توانند اعتبارنامه داشته باشند.
• پس از اصلاح، کش‌های قبلی را پاک کنید و اعتبارنامه‌هایی را که احتمالاً افشا شده‌اند تغییر دهید.
• build scriptها و ابزارهای دیگر را هم بررسی کنید؛ اطلاعیه Rust هشدار می‌دهد که Cargo و Rust تضمین نمی‌کنند متغیرهای محیطی هرگز در artifactهای کامپایل کپی نشوند.

مستندات GitHub نیز جداگانه توصیه می‌کند اسرار فقط به stepهایی داده شوند که به آن‌ها نیاز دارند و توضیح می‌دهد که اسرار، به‌طور معمول، در workflowهای ناشی از fork به runner داده نمی‌شوند؛ استثنای مهم GITHUB_TOKEN است. این محافظت جایگزین بررسی کش نیست: سیاست pull request و مجوزهای کش هر مخزن تعیین می‌کنند چه کسی می‌تواند artifactهای ذخیره‌شده را بخواند.

درس گسترده‌تر، عملیاتی است نه صرفاً مربوط به زبان. هر زمان ابزارهای تولید کد، build scriptها، تست‌ها یا emulatorها بتوانند وضعیت فرایند را ببینند، کش build بخشی از perimeter امنیتی است. محتوای کش را بالقوه حساس فرض کنید، jobهای CI را بر اساس حداقل دسترسی طراحی کنید و پاک‌سازی کش و چرخش اعتبارنامه را بخشی از پاسخ به حادثه بدانید.

ملاحظه: تیم پاسخ‌گویی امنیتی Rust می‌گوید اسکن اکوسیستم آن‌ها ممکن است کامل نبوده باشد؛ بنابراین maintainers باید workflowهای خود را مستقیماً بررسی کنند و اسکن منتشرشده را فهرستی کامل تلقی نکنند.