حاوية dasel v3.3.1 المحصّنة

هذه حزمة melange وصورة حاوية apko لـ dasel v3.3.1 مع تصحيح وقت البناء لـ CVE-2026-33320 (توسّع غير محدود للأسماء المستعارة في YAML). الصورة مبنية بالكامل من APK مُنتج محليًا - لا تُستخدم أي صورة جاهزة من المصدر الأصلي.

المتطلبات الأساسية

• البنية: x86_64 فقط
• الوصول إلى الإنترنت مطلوب للبناء الأولي (يجلب أرشيف المصدر، وحدات Go، وحزم Wolfi)

متطلبات Windows

تعمل جميع أوامر البناء والتحميل من أي طرفية (PowerShell أو CMD أو bash). لا تزال خطوة واحدة تتطلب قشرة Unix:

• bash tests/test.sh — يستخدم سكربت الاختبار bash وcoreutils (timeout وgrep وsed)

ثبّت Git Bash (يأتي مع Git for Windows) قبل تشغيل اختبارات الصورة.

هيكل المشروع

.
├── .github/
├── melange/
│   ├── dasel.yaml
│   └── CVE-2026-33320.patch
├── apko/
│   └── dasel.yaml
├── tests/
│   └── test.sh
├── Makefile
├── compose.yaml
├── keys/                       # Generated, gitignored
│   ├── melange.rsa
│   └── melange.rsa.pub
├── sbom/                       # Generated, gitignored
│   ├── sbom-x86_64.spdx.json
│   └── sbom-index.spdx.json
├── packages/                   # Generated, gitignored
│   └── x86_64/
│       ├── dasel-3.3.1-r0.apk
│       └── APKINDEX.tar.gz
└── README.md

البناء

باستخدام Make

make build        # keygen (if needed) + package + image
make test         # package tests + image tests
make all          # build + test
make clean        # remove all generated artifacts
make help         # list all targets and variables

الأوامر اليدوية

# 1. Generate signing keys (one-time)
docker compose run --rm melange keygen keys/melange.rsa

# 2. Build the APK package (fetches source, applies CVE patch, compiles)
docker compose run --rm melange build melange/dasel.yaml --arch x86_64 --signing-key keys/melange.rsa

# 3. Build the OCI image (consumes the local APK)
docker compose run --rm apko build apko/dasel.yaml dasel:3.3.1 dasel.tar --arch x86_64 --sbom-path sbom/

تنشئ الخطوة 2 وتوقّع تلقائيًا packages/x86_64/APKINDEX.tar.gz.

التشغيل

بعد تحميل الصورة، شغّل dasel:

docker load --input dasel.tar

# Example: query a JSON file
echo '{"name": "dasel"}' | docker run --rm \
  --read-only \
  --cap-drop=ALL \
  --security-opt=no-new-privileges \
  -i dasel:3.3.1-amd64 \
  -i json 'name'

تفرض هذه العلامات طبقة وقت التشغيل لاستراتيجية الدفاع المتعمق الموصوفة في تحصين الصورة: نظام ملفات جذر غير قابل للتغيير، صفر من قدرات Linux، ولا مسارات لتصعيد الامتيازات.

الاختبار

باستخدام Make

make test          # all tests (package + image)
make package-test  # melange package tests only
make image-test    # image tests only (requires bash)

الأوامر اليدوية

# Package tests
docker compose run --rm melange test melange/dasel.yaml --arch x86_64

# Image tests (requires Git Bash on Windows)
docker load --input dasel.tar
bash tests/test.sh

يتحقق سكربت الاختبار من:

• تحميل الصورة وأن dasel version يعرض v3.3.1
• استخراج مفتاح JSON (-i json 'test')
• التحويل من JSON إلى YAML (-i json -o yaml --root)
• تصحيح CVE: إدخال YAML الخبيث من نوع billion-laughs يُطلق "yaml expansion budget exceeded" بدلًا من التعلّق

إصلاح CVE-2026-33320

تتيح الثغرة استهلاكًا غير محدود لوحدة المعالجة المركزية/الذاكرة عبر أسماء YAML المستعارة المتداخلة بشكل أسي (هجوم billion laughs). يضيف التصحيح في melange/CVE-2026-33320.patch ضابطتي أمان لقارئ YAML في dasel: حدًا لعمق التوسّع (32) يحدّ من التداخل التكراري للأسماء المستعارة، وميزانية توسّع (1000) تحدّ من إجمالي عمليات إلغاء مرجعية الأسماء المستعارة لكل مستند. عند بلوغ أي من الحدّين، يعيد فك الترميز خطأً فورًا.

الأمان وإعادة الإنتاج والحدّ الأدنى

• الأمان: تم تصحيح CVE-2026-33320 في وقت البناء. جميع الحزم موقّعة. تحتوي الصورة على 3 حزم APK فقط (wolfi-baselayout وca-certificates-bundle وdasel)
• إعادة الإنتاج: YAML تصريحي لكل من الحزمة والصورة. أرشيف المصدر مثبّت عبر SHA256. جميع إصدارات الأدوات موثّقة. ثنائي Go مبني باستخدام -trimpath لإزالة مسارات البناء المحلية
• الحدّ الأدنى: لا قشرة ولا مدير حزم في الصورة النهائية - فقط ثنائي dasel وشهادات CA وbaselayout

تحصين الصورة

تطبّق الصورة الدفاع المتعمق أبعد من التغليف الأدنى:

فحص الثغرات

تم فحص الصورة المبنية (dasel.tar) باستخدام أدوات قياسية في الصناعة للتحقق من الوضع الأمني أبعد من تصحيح CVE نفسه.

Syft (توليد SBOM)

استخرجت Syft 36 حزمة من الصورة بفحص بيانات وحدات ثنائي Go:

• 3 حزم APK: wolfi-baselayout 20230201-r29 وca-certificates-bundle 20260413-r0 وdasel 3.3.1-r0
• 32 وحدة Go: بما فيها go.yaml.in/yaml/v4 وgithub.com/hashicorp/hcl/v2 وgithub.com/pelletier/go-toml/v2 وgithub.com/goccy/go-json وgithub.com/charmbracelet/bubbletea وgolang.org/x/sys وgolang.org/x/text وstdlib go1.25.9 و25 وحدة أخرى
• 19 ملفًا تم جردها: /usr/bin/dasel و/etc/ssl/certs/ca-certificates.crt وAPK DB وملفات SBOM لكل حزمة وملفات إعداد baselayout

Grype (ماسح الثغرات)

تم فحص SBOM الذي أنشأته باستخدام Grype، ولم يُعثر على أي ثغرات أخرى في أي من وحدات Go الـ32 أو حزم APK الثلاث.

التسليم

الافتراضات

• x86_64 فقط - بناء أحادي البنية. البناء متعدد البنيات يتطلب أعلام --arch إضافية

• مفاتيح توقيع مؤقتة - تُنشأ محليًا ومستثناة عبر git (gitignored). في بيئة الإنتاج، يجب تخزين مفاتيح التوقيع الخاصة في مدير أسرار، وليس على نظام الملفات المحلي، حتى لو كان يمكن كشف الملفات المستثناة عبر git من خلال أدوات النسخ الاحتياطي أو تحميل وحدات تخزين الحاويات أو محطة عمل مخترقة.

• اعتماد على نظام Wolfi OS - يعتمد البناء والصورة النهائية على حزم Wolfi (busybox وgo وca-certificates-bundle). إذا اكتُشفت ثغرة في أي من تلك الحزم الأصلية، فستؤثر على هذه الصورة أيضًا. سيكون تحديث حزم Wolfi أو الاشتراك في نشراتها الأمنية ضروريًا في الإنتاج

• غلافات Docker Compose - يعمل melange وapko كحاويات Docker عبر compose.yaml. طُوّر هذا على Kali 2025.3 وتُحقق منه على Windows 10 باستخدام Docker Desktop 29.3.1

• سكربت الاختبار يتطلب bash - يستخدم tests/test.sh أداة timeout (من coreutils) وواجهة Docker CLI. جميع الأوامر الأخرى هي docker خالصة وتعمل من PowerShell أو CMD. على Windows، شغّل سكربت الاختبار من Git Bash (انظر متطلبات Windows)

فجوة تغطية SBOM

تُنشئ apko تلقائيًا ملفات SBOM بصيغة SPDX وقت البناء داخل مجلد sbom/ (sbom/sbom-x86_64.spdx.json وsbom/sbom-index.spdx.json). تتعقّب هذه الملفات حزم APK الثلاث المثبتة مع الإصدارات وCPEs ومصدر البرنامج ومراجع تعريف بناء Melange. ومع ذلك، فهي لا تتضمن تبعيات وحدات Go المترجمة داخل ثنائي dasel. قررت فحصها واستخدمت Syft لسد هذه الفجوة باستخراج جميع وحدات Go الـ32 من البيانات الوصفية المضمّنة في الثنائي.

بالنسبة لبيئة الإنتاج، يجب أن تكون هناك أتمتة لاستخراج SBOM تستعلم بشكل دوري. ثم ربما إرفاق نتائج SBOM بشيء مثل https://github.com/nedlir/CVEnotifier الذي كتبته بلغة Golang للعثور على ثغرات جديدة في سلسلة التوريد.

الأوامر المنفذة ونتائجها

تحسينات مستقبلية

• بناءات متعددة البنيات - دعم بنيات متعددة لبناء هذه الحاوية.

• خط أنابيب CI/CD - أتمتة البناء والاختبار في GitHub Actions باستخدام إجراءات حاويات melange/apko

• SBOM على مستوى Go في melange - تشغيل syft أثناء خط أنابيب بناء melange ودمج SBOM لوحدات Go بجانب APK