مواصفات تحديث البرمجيات

نظرة عامة

يستخدم I2P نظاماً بسيطاً وآمناً للتحديث التلقائي للبرامج. تقوم وحدة تحكم router بسحب ملف الأخبار بشكل دوري من عنوان URL خاص بـ I2P قابل للتكوين. يوجد عنوان URL احتياطي مُبرمج مسبقاً يشير إلى موقع المشروع الإلكتروني، في حالة تعطل مضيف أخبار المشروع الافتراضي.

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

يمكن للـ router اختيارياً تحميل الإصدار الجديد، أو تحميله وتثبيته، إذا تم تكوينه للقيام بذلك.

مواصفات ملف الأخبار القديم

تم استبدال هذا التنسيق بتنسيق أخبار su3 اعتباراً من الإصدار 0.9.17.

قد يحتوي ملف news.xml على العناصر التالية:

<i2p.news date="$Date: 2010-01-22 00:00:00 $" />
<i2p.release version="0.7.14" date="2010/01/22" minVersion="0.6" />

المعاملات في إدخال i2p.release كما يلي. جميع المفاتيح غير حساسة لحالة الأحرف. يجب وضع جميع القيم بين علامتي اقتباس مزدوجتين.

date : تاريخ إصدار إصدار الـ router. غير مستخدم. التنسيق غير محدد.

minJavaVersion : الحد الأدنى من إصدار Java المطلوب لتشغيل الإصدار الحالي. اعتباراً من الإصدار 0.9.9.

minVersion : الحد الأدنى لإصدار الـ router المطلوب للتحديث إلى الإصدار الحالي. إذا كان الـ router أقدم من هذا، يجب على المستخدم (يدوياً؟) التحديث إلى إصدار وسيط أولاً. اعتباراً من الإصدار 0.9.9.

su3Clearnet : واحد أو أكثر من عناوين URL لـ HTTP حيث يمكن العثور على ملف التحديث .su3 على الشبكة العادية (غير I2P). يجب فصل عناوين URL المتعددة بمسافة أو فاصلة. اعتباراً من الإصدار 0.9.9.

su3SSL : واحد أو أكثر من عناوين HTTPS URLs حيث يمكن العثور على ملف التحديث .su3 على الشبكة العادية (غير I2P). يجب فصل عدة URLs بمسافة أو فاصلة. اعتباراً من الإصدار 0.9.9.

sudTorrent : رابط المغناطيس للتورنت .sud (غير pack200) للتحديث. اعتباراً من الإصدار 0.9.4.

su2Torrent : رابط magnet لملف التورنت .su2 (pack200) الخاص بالتحديث. اعتباراً من الإصدار 0.9.4.

su3Torrent : رابط المغناطيس لتورنت .su3 (التنسيق الجديد) للتحديث. اعتباراً من الإصدار 0.9.9.

version : مطلوب. أحدث إصدار router متاح حالياً.

يمكن تضمين العناصر داخل تعليقات XML لمنع تفسيرها من قبل المتصفحات. عنصر i2p.release والإصدار مطلوبان. جميع العناصر الأخرى اختيارية. ملاحظة: بسبب قيود المحلل يجب أن يكون العنصر بأكمله على سطر واحد.

مواصفات ملف التحديث

اعتباراً من الإصدار 0.9.9، سيستخدم ملف التحديث الموقع، المسمى i2pupdate.su3، تنسيق الملف “su3” المحدد أدناه. سيستخدم الموقعون المعتمدون للإصدارات مفاتيح RSA بحجم 4096 بت. يتم توزيع شهادات المفاتيح العامة X.509 لهؤلاء الموقعين في حزم تثبيت router. قد تحتوي التحديثات على شهادات لموقعين جدد معتمدين، و/أو تحتوي على قائمة بالشهادات المراد حذفها للإلغاء.

مواصفات ملف التحديث القديم

هذا التنسيق قديم منذ الإصدار 0.9.9.

ملف التحديث الموقع، والذي يُسمى تقليدياً i2pupdate.sud، هو ببساطة ملف مضغوط بتنسيق zip مع رأس (header) مكون من 56 بايت مُضاف في المقدمة. يحتوي الرأس على:

• توقيع DSA بحجم 40 بايت Signature
• إصدار I2P بحجم 16 بايت بترميز UTF-8، مبطن بأصفار في النهاية إذا لزم الأمر

التوقيع يغطي أرشيف zip فقط - وليس الإصدار المُضاف في المقدمة. يجب أن يطابق التوقيع أحد مفاتيح DSA SigningPublicKey المُكوَّنة في router، والذي يحتوي على قائمة افتراضية مُدمجة من مفاتيح مديري إصدارات المشروع الحاليين.

لأغراض مقارنة الإصدارات، تحتوي حقول الإصدار على [0-9]*، وفواصل الحقول هي ‘-’ و ‘_’ و ‘.’، ويتم تجاهل جميع الأحرف الأخرى.

اعتباراً من الإصدار 0.8.8، يجب أيضاً تحديد الإصدار كتعليق في ملف zip بترميز UTF-8، بدون الأصفار اللاحقة. يتحقق router المُحدِّث من أن الإصدار في الرأس (غير المشمول بالتوقيع) يتطابق مع الإصدار في تعليق ملف zip، والذي يكون مشمولاً بالتوقيع. هذا يمنع انتحال رقم الإصدار في الرأس.

التحميل والتثبيت

يقوم الـ router أولاً بتنزيل رأس ملف التحديث من واحد من قائمة قابلة للتكوين من عناوين I2P URLs، باستخدام عميل HTTP المدمج والـ proxy، ويتحقق من أن الإصدار أحدث. هذا يمنع مشكلة خوادم التحديث التي لا تحتوي على أحدث ملف. ثم يقوم الـ router بتنزيل ملف التحديث الكامل. يتحقق الـ router من أن إصدار ملف التحديث أحدث قبل التثبيت. كما يتحقق بالطبع من التوقيع، ويتحقق من أن تعليق ملف الـ zip يطابق إصدار الرأس، كما هو موضح أعلاه.

يتم استخراج ملف zip ونسخه إلى “i2pupdate.zip” في دليل تكوين I2P (~/.i2p على Linux).

اعتباراً من الإصدار 0.7.12، يدعم الـ router ضغط Pack200. الملفات داخل أرشيف الzip التي تحمل لاحقة .jar.pack أو .war.pack يتم إلغاء ضغطها بشكل شفاف إلى ملف .jar أو .war. ملفات التحديث التي تحتوي على ملفات .pack تُسمى تقليدياً بلاحقة ‘.su2’. Pack200 يقلل حجم ملفات التحديث بحوالي 60%.

اعتباراً من الإصدار 0.8.7، سيقوم الـ router بحذف ملفات libjbigi.so و libjcpuid.so إذا كان أرشيف الـ zip يحتوي على ملف lib/jbigi.jar، بحيث يتم استخراج الملفات الجديدة من jbigi.jar.

اعتباراً من الإصدار 0.8.12، إذا كان أرشيف zip يحتوي على ملف deletelist.txt، فسيقوم الموجه بحذف الملفات المدرجة فيه. التنسيق هو:

• اسم ملف واحد في كل سطر
• جميع أسماء الملفات نسبية لدليل التثبيت؛ لا يُسمح بأسماء الملفات المطلقة، ولا ملفات تبدأ بـ “..”
• التعليقات تبدأ بـ ‘#’

سيقوم الـ router بعد ذلك بحذف ملف deletelist.txt.

مواصفات ملف SU3

يتم استخدام هذه المواصفة لتحديثات router اعتباراً من الإصدار 0.9.9، وبيانات reseed اعتباراً من الإصدار 0.9.14، والإضافات اعتباراً من الإصدار 0.9.15، وملف الأخبار اعتباراً من الإصدار 0.9.17.

المشاكل مع تنسيق .sud/.su2 السابق

• لا يوجد رقم سحري أو علامات
• لا توجد طريقة لتحديد الضغط، pack200 أم لا، أو خوارزمية التوقيع
• الإصدار غير مغطى بالتوقيع، لذا يتم فرضه من خلال طلب وجوده في تعليق ملف zip (لملفات الموجه) أو في ملف plugin.config (للإضافات)
• الموقع غير محدد لذا يجب على المُتحقق تجربة جميع المفاتيح المعروفة
• تنسيق التوقيع قبل البيانات يتطلب مرورين لتوليد الملف

الأهداف

• إصلاح المشاكل المذكورة أعلاه
• الانتقال إلى خوارزمية توقيع أكثر أماناً
• الاحتفاظ بمعلومات الإصدار في نفس التنسيق والإزاحة للتوافق مع أدوات فحص الإصدار الحالية
• التحقق من التوقيع واستخراج الملف في مرة واحدة

المواصفة

تفاصيل التوقيع

يغطي التوقيع الرأس بالكامل بدءاً من البايت 0، وحتى نهاية المحتوى. نستخدم التواقيع الخام. نأخذ hash للبيانات (باستخدام نوع hash المضمن في نوع التوقيع في البايتات 8-9) ونمررها إلى دالة توقيع أو تحقق “خام” (مثل “NONEwithRSA” في Java).

بينما يمكن تنفيذ التحقق من التوقيع واستخراج المحتوى في مرحلة واحدة، يجب على التطبيق قراءة وتخزين أول 10 بايت مؤقتاً لتحديد نوع الـ hash قبل البدء في التحقق.

أطوال التوقيعات لأنواع التوقيعات المختلفة مُعطاة في مواصفات التوقيع . قم بحشو التوقيع بأصفار رائدة إذا لزم الأمر. راجع صفحة تفاصيل التشفير لمعرفة معايير أنواع التوقيعات المختلفة.

ملاحظات

يحدد نوع المحتوى نطاق الثقة. لكل نوع محتوى، يحتفظ العملاء بمجموعة من شهادات المفاتيح العامة X.509 للأطراف الموثوقة لتوقيع ذلك المحتوى. يمكن استخدام الشهادات المخصصة لنوع المحتوى المحدد فقط. يتم البحث عن الشهادة بواسطة معرف الموقع. يجب على العملاء التحقق من أن نوع المحتوى هو المتوقع للتطبيق.

جميع القيم بترتيب بايت الشبكة (big endian).

للحصول على تنفيذ python لتوقيعات Raw RSA المتوافقة مع Java “NONEwithRSA”، راجع هذا المقال في Stack Overflow .

مواصفات ملف تحديث Router SU3

تفاصيل SU3

• نوع محتوى SU3: 1 (تحديث ROUTER)
• نوع ملف SU3: 0 (ZIP)
• إصدار SU3: إصدار الـ router

ملفات Jar و war في الأرشيف المضغوط لم تعد مضغوطة باستخدام pack200 كما هو موثق أعلاه لملفات “su2”، لأن بيئات تشغيل Java الحديثة لم تعد تدعمها.

ملاحظات

• بالنسبة للإصدارات، إصدار SU3 هو إصدار router “الأساسي”، مثل “0.9.20”.
• بالنسبة لإصدارات التطوير، المدعومة اعتباراً من الإصدار 0.9.20، إصدار SU3 هو إصدار router “الكامل”، مثل “0.9.20-5” أو “0.9.20-5-rc”. راجع RouterVersion.java في مصدر I2P .

مواصفات ملف SU3 لإعادة البذر

اعتباراً من الإصدار 0.9.14، يتم تسليم بيانات إعادة البذر بصيغة ملف “su3”.

الأهداف

• ملفات موقعة بتوقيعات قوية وشهادات موثوقة لمنع هجمات man-in-the-middle التي يمكن أن تقوم بتشغيل الضحايا في شبكة منفصلة وغير موثوقة.
• استخدام تنسيق ملف su3 المستخدم بالفعل للتحديثات والإضافات
• ملف مضغوط واحد لتسريع عملية reseeding، والتي كانت بطيئة عند جلب 200 ملف

المواصفات

1. يجب أن يكون اسم الملف “i2pseeds.su3”. اعتباراً من الإصدار 0.9.42، يجب على المطلوب إلحاق سلسلة استعلام “?netid=2” بعنوان URL للطلب، بافتراض معرف الشبكة الحالي 2. يمكن استخدام هذا لمنع الاتصالات عبر الشبكات المختلفة. يجب أن تضع شبكات الاختبار معرف شبكة مختلف. راجع الاقتراح 147 للتفاصيل.
2. يجب أن يكون الملف في نفس الدليل مع معلومات router على خادم الويب.
3. سيحاول router أولاً جلب (عنوان URL للفهرس)/i2pseeds.su3؛ إذا فشل ذلك سيجلب عنوان URL للفهرس ثم يجلب ملفات معلومات router الفردية الموجودة في الروابط.

تفاصيل SU3

• نوع محتوى SU3: 3 (RESEED)
• نوع ملف SU3: 0 (ZIP)
• إصدار SU3: ثوانٍ منذ العصر، بصيغة ASCII (date +%s). لا يعود للصفر في 2038 أو 2106.
• ملفات معلومات router في ملف zip يجب أن تكون في “المستوى الأعلى”. لا توجد مجلدات في ملف zip.
• ملفات معلومات router يجب أن تُسمى “routerInfo-(44 حرف base 64 router hash).dat”، كما في آلية reseed القديمة. يجب استخدام أبجدية I2P base 64.

ملاحظات

• تحذير: من المعروف أن عدة reseeds غير مستجيبة عبر IPv6. يُنصح بإجبار أو تفضيل IPv4.
• تحذير: بعض reseeds تستخدم شهادات CA موقعة ذاتياً. يجب على التطبيقات إما استيراد والوثوق بهذه الـ CAs عند الـ reseeding، أو حذف الـ reseeds الموقعة ذاتياً من قائمة reseed.
• مفاتيح reseed signer يتم توزيعها على التطبيقات كشهادات X.509 موقعة ذاتياً مع مفاتيح RSA-4096 (نوع التوقيع 6). يجب على التطبيقات فرض التواريخ الصالحة في الشهادات.

مواصفات ملف المكون الإضافي SU3

اعتباراً من الإصدار 0.9.15، يمكن تعبئة الإضافات في تنسيق ملف “su3”.

تفاصيل SU3

• نوع محتوى SU3: 2 (PLUGIN)
• نوع ملف SU3: 0 (ZIP) - راجع مواصفات المكون الإضافي للتفاصيل.
• إصدار SU3: إصدار المكون الإضافي، يجب أن يطابق ذلك الموجود في plugin.config.

ملفات Jar و war في الملف المضغوط يجب ألا تُضغط باستخدام pack200 كما هو موثق أعلاه لملفات “su2”، حيث أن إصدارات Java الحديثة لم تعد تدعمها.

مواصفات ملف أخبار SU3

اعتباراً من الإصدار 0.9.17، يتم توصيل الأخبار بتنسيق ملف “su3”.

الأهداف

• أخبار موقعة بتوقيعات قوية وشهادات موثوقة
• استخدام تنسيق ملف su3 المستخدم بالفعل للتحديثات وإعادة البذر والإضافات
• تنسيق XML قياسي للاستخدام مع المحللات القياسية
• تنسيق Atom قياسي للاستخدام مع قارئات ومولدات التدفقات القياسية
• تطهير والتحقق من HTML قبل عرضه على وحدة التحكم
• مناسب للتنفيذ السهل على Android والمنصات الأخرى بدون وحدة تحكم HTML

تفاصيل SU3

• نوع محتوى SU3: 4 (NEWS)
• نوع ملف SU3: 1 (XML) أو 3 (XML.GZ)
• إصدار SU3: ثواني منذ العهد، في ASCII (date +%s). لا يتجاوز في 2038 أو 2106.
• تنسيق الملف: XML أو XML مضغوط، يحتوي على تغذية XML RFC 4287 (Atom). يجب أن تكون مجموعة الأحرف UTF-8.

تفاصيل تغذية Atom

يتم استخدام عناصر <feed> التالية:

<entry> : عنصر إخباري. انظر أدناه.

<i2p:release> : بيانات تحديث I2P الوصفية. انظر أدناه.

<i2p:revocations> : إبطالات الشهادات. انظر أدناه.

<i2p:blocklist> : بيانات قائمة الحظر. انظر أدناه.

<updated> : مطلوب. الطابع الزمني للتغذية (متوافق مع RFC 4287 القسم 3.3 و RFC 3339 ).

تفاصيل مدخل Atom

يمكن تحليل وعرض كل <entry> من Atom في تغذية الأخبار في وحدة تحكم الـ router. يتم استخدام العناصر التالية:

<author> : اختياري. يحتوي على <name> - اسم مؤلف الإدخال.

<content> : مطلوب. المحتوى، يجب أن يكون type=“xhtml”. سيتم تنظيف XHTML بقائمة بيضاء من العناصر المسموحة وقائمة سوداء من السمات غير المسموحة. قد يتجاهل العملاء عنصراً، أو الإدخال المحيط، أو الخلاصة بأكملها عند مواجهة عنصر غير موجود في القائمة البيضاء.

<link> : اختياري. رابط للمزيد من المعلومات.

<summary> : اختياري. ملخص قصير، مناسب لتلميح الأدوات.

<title> : مطلوب. عنوان الخبر.

<updated> : مطلوب. الطابع الزمني لهذا الإدخال (يجب أن يتوافق مع RFC 4287 القسم 3.3 و RFC 3339 ).

تفاصيل إصدار Atom i2p:release

يجب أن يكون هناك كيان <i2p:release> واحد على الأقل في التغذية. كل منها يحتوي على الخصائص والكيانات التالية:

date (خاصية) : مطلوب. الطابع الزمني لهذا الإدخال (متوافق مع RFC 4287 القسم 3.3 و RFC 3339 ). قد يكون التاريخ أيضاً بصيغة مقتطعة yyyy-mm-dd (بدون ‘T’)؛ هذه هي صيغة “التاريخ الكامل” في RFC 3339. في هذه الصيغة يُفترض أن الوقت هو 00:00:00 UTC لأي معالجة.

minJavaVersion (خاصية) : إذا كانت موجودة، فهي الحد الأدنى من إصدار Java المطلوب لتشغيل الإصدار الحالي.

minVersion (خاصية) : إذا كانت موجودة، فهي الإصدار الأدنى من الـ router المطلوب للتحديث إلى الإصدار الحالي. إذا كان الـ router أقدم من هذا، يجب على المستخدم التحديث (يدوياً؟) إلى إصدار وسطي أولاً.

<i2p:version> : مطلوب. أحدث إصدار متاح حالياً من الـ router.

<i2p:update> : ملف تحديث (واحد أو أكثر). يجب أن يحتوي على عنصر فرعي واحد على الأقل. - type (خاصية): “sud”، “su2”، أو “su3”. يجب أن تكون فريدة عبر جميع عناصر <i2p:update>. - <i2p:clearnet>: روابط التحميل المباشر خارج الشبكة (صفر أو أكثر). href (خاصية): رابط http عادي للإنترنت العادي. - <i2p:clearnetssl>: روابط التحميل المباشر خارج الشبكة (صفر أو أكثر). href (خاصية): رابط https عادي للإنترنت العادي. - <i2p:torrent>: رابط magnet داخل الشبكة. href (خاصية): رابط magnet. - <i2p:url>: روابط التحميل المباشر داخل الشبكة (صفر أو أكثر). href (خاصية): رابط http .i2p داخل الشبكة.

تفاصيل إلغاءات i2p للـ Atom

هذا العنصر اختياري ولا يوجد أكثر من عنصر <i2p:revocations> واحد في الخلاصة. هذه الميزة مدعومة اعتباراً من الإصدار 0.9.26.

يحتوي الكيان <i2p:revocations> على كيان واحد أو أكثر من <i2p:crl>. يحتوي الكيان <i2p:crl> على الخصائص التالية:

updated (السمة) : مطلوبة. الطابع الزمني لهذا الإدخال (وفقاً لـ RFC 4287 القسم 3.3 و RFC 3339 ). قد يكون التاريخ أيضاً بالتنسيق المقتطع yyyy-mm-dd (بدون ‘T’)؛ هذا هو تنسيق “التاريخ الكامل” في RFC 3339. في هذا التنسيق يُفترض أن الوقت هو 00:00:00 UTC لأي معالجة.

id (attribute) : مطلوب. معرف فريد لمنشئ قائمة الشهادات المُلغاة هذه.

(محتوى الكيان) : مطلوب. قائمة إبطال الشهادات (CRL) مشفرة بترميز base 64 قياسي مع أسطر جديدة، تبدأ بالسطر ‘—–BEGIN X509 CRL—–’ وتنتهي بالسطر ‘—–END X509 CRL—–’. راجع RFC 5280 لمزيد من المعلومات حول قوائم CRL.

تفاصيل Atom i2p:blocklist

هذا العنصر اختياري ولا يوجد أكثر من عنصر واحد <i2p:blocklist> في الخلاصة. هذه الميزة مجدولة للتنفيذ في الإصدار 0.9.28.

يحتوي عنصر <i2p:blocklist> على عنصر واحد أو أكثر من عناصر <i2p:block> أو <i2p:unblock>، وعنصر “updated”، وخصائص “signer” و “sig”:

signer (attribute) : مطلوب. معرف فريد (UTF-8) للمفتاح العام المستخدم لتوقيع قائمة الحظر هذه.

sig (خاصية) : مطلوب. توقيع بالتنسيق code:b64sig، حيث code هو رقم نوع التوقيع ASCII، و b64sig هو التوقيع المشفر بـ base 64 (أبجدية I2P). انظر أدناه لمواصفات البيانات المراد توقيعها.

<updated> : مطلوب. طابع زمني لقائمة الحظر (متوافق مع RFC 4287 القسم 3.3 و RFC 3339 ). يمكن أن يكون التاريخ أيضاً بصيغة مقطوعة yyyy-mm-dd (بدون ‘T’)؛ هذه هي صيغة “التاريخ الكامل” في RFC 3339. في هذه الصيغة يُفترض أن يكون الوقت 00:00:00 UTC لأي معالجة.

<i2p:block> : اختياري، يُسمح بعدة كيانات. إدخال واحد، إما عنوان IPv4 أو IPv6 حرفي، أو router hash مكون من 44 حرف base 64 (أبجدية I2P). عناوين IPv6 قد تكون في صيغة مختصرة (تحتوي على “::”). الدعم للإدخالات مع netmask، مثل x.y.0.0/16، اختياري. الدعم لأسماء المضيفين اختياري.

<i2p:unblock> : اختياري، يُسمح بعدة كيانات. نفس تنسيق <i2p:block>.

مواصفات التوقيع: لإنشاء البيانات المراد توقيعها أو التحقق منها، قم بربط البيانات التالية بترميز ASCII: النص المحدث متبوعاً بسطر جديد (ASCII 0x0a)، ثم كل إدخال حظر بالترتيب المستلم مع سطر جديد بعد كل منها، ثم كل إدخال إلغاء حظر بالترتيب المستلم مع سطر جديد بعد كل منها.

مواصفات ملف قائمة الحظر

TBD، غير مُنفذ، راجع الاقتراح 130. يتم تسليم تحديثات القائمة السوداء في ملف الأخبار، انظر أعلاه.

العمل المستقبلي

• آلية تحديث الـ router هي جزء من وحدة تحكم الـ router عبر الويب. لا يوجد حاليًا أي توفير لتحديثات الـ router المدمج الذي يفتقر إلى وحدة تحكم الـ router.

المراجع

• [CRYPTO-SIG] التشفير - التوقيعات
• [I2P-SRC] كود مصدر I2P
• [PLUGIN] مواصفة الإضافة
• [Python] توقيعات Python RSA الخام
• [RFC-3339] RFC 3339 - التاريخ والوقت
• [RFC-4287] RFC 4287 - تنسيق Atom Syndication
• [RFC-5280] RFC 5280 - قوائم إلغاء الشهادات
• [Signature] نوع التوقيع
• [SigningPublicKey] نوع SigningPublicKey