سبب وجيه لاختبار تبعياتك: إصدار AGPL

هنا تأخذ الشفرة بموجب تراخيص BSD و MIT و Apache2 ولا تخفق في الخفقان ، ثم - بام! - التحول الثاني ، وفي الاعتماد التبادلي ، يتم رسم الكود تحت AGPL. نحاول أن نراقب هذا ونفضل أن نتفوق بدلاً من أن ننتهي.



قبل إضافة تبعيات جديدة إلى أي من مشاريعي ، أقوم دائمًا بإجراء فحص أساسي. ما أفحصه (قائمة مرجعية قياسية):

• تحت أي ترخيص يتم إصدار الرمز؟
• من هو المؤلف؟
• هل هناك أي مشاكل خطيرة لم يتم حلها في تعقب الأخطاء؟
• هل هناك تاريخ من الأخطاء الخطيرة في تعقب الخطأ؟
• كيف تتم مراجعة التعليمات البرمجية لسحب المهام؟

بعد ذلك ، أطلع على الكود نفسه بحثًا عن شيء غير آمن أو ضار. هذا أمر ضروري لتشعر بجودة قاعدة الكود نفسها. بعد ذلك ، أحاول العثور على "M& Ms" - تفاصيل بسيطة قد تشير إلى مشاكل كبيرة. وكرر بشكل متكرر كل ما سبق مع التبعيات متعدية. بالإضافة إلى ذلك ، أقوم مرة أخرى بتصفح الكود في كل مرة أقوم فيها بتحديث التبعية.

هذا قدر كبير من العمل ، لكنه ضروري حتى لا تصبح ضحية لهجمات مثل مجرى الأحداث . ومؤخرًا ، تم تذكيرنا بسبب وجيه آخر للتحقق من التبعيات. في تلك اللحظة كنت أقوم بمراجعة المكتبة التي تم الإعلان عنها بنشاط من Duo لـ WebAuthn on Go ، هنا: github.com/duo-labs/webauthn .

بدأ كل شيء مع حقيقة أنني لاحظت بعض "M & M البني":

• تم تسجيل البيانات في stdout ، على الرغم من أن هذه مكتبة.
• تم تخزين الكود.

بالطبع ، كانت هذه المشكلات البسيطة فقط نذيرًا لشيء أكثر: عندما بدأت في مراجعة أحد التبعيات العابرة ( github.com/katzenpost/core/crypto/eddsa ) ، التقى رأس ترخيص AGPLv3 .

هذه أخبار سيئة لأي شخص يريد استخدام مكتبة Duo WebAuthn. على الرغم من حقيقة أن Duo قامت بترخيص مكتبتها بموجب BSD ، فإن تحديدها ، يمكنك أيضًا ربط تطبيقك بمكتبة AGPL. وفقًا لـ (A) GPL ، يمكنك بهذه الطريقة إنشاء منتج "معدل" يندرج ضمن قواعد القسم 13 من AGPL :

إذا قمت بإجراء تغييرات على البرنامج ، فيجب أن يقدم نسختك المعدلة بشكل صريح لجميع المستخدمين الذين يتفاعلون معه عن بُعد عبر الشبكة (إذا كان نسختك تدعم هذا التفاعل) فرصة للحصول على وصول مجاني مجاني إلى الكود المصدر لإصدارك باستخدام أدوات نسخ البرامج القياسية (على الرغم من إلى أي أحكام أخرى من هذا الترخيص).

بمعنى آخر ، إذا استخدمت github.com/duo-labs/webauthn في تطبيق ويب عام ، فيجب أن يكون تطبيق الويب الخاص بك مفتوحًا الآن.

الشيء الأكثر إثارة للفزع حول هذه التبعية هو أنها تكرر golang.org/x/crypto/ed25519 - إحدى مكتبات Go " شبه" القياسية .

في الواقع ، github.com/duo-labs/webauthn هو نفسه golang.org/x/crypto/ed25519 المستخدم في الأصل. تم إجراء الاستبدال أثناء بحث خارجي عن تعاون خارجي يسمى "دمج أشياء COSE في منطقتهم" . في عملية نقل جزء من التعليمات البرمجية من ملف إلى آخر ، غير طلب السحب هذا بهدوء تغيير تطبيق OKPPublicKeyData.Verify .

هنا هو OKPPublicKeyData.Verify الذي يستخدم golang.org/x/crypto/ed25519 :

 // Verify Octet Key Pair (OKP) Public Key Signature func (k *OKPPublicKeyData) Verify(data []byte, sig []byte) (bool, error) { f := HasherFromCOSEAlg(COSEAlgorithmIdentifier(k.PublicKeyData.Algorithm)) h := f() h.Write(data) return ed25519.Verify(k.XCoord, h.Sum(nil), sig), nil } 

وهنا OKPPublicKeyData.Verify ، والذي يستخدم OKPPublicKeyData.Verify المرخص بـ AGPL :

 // Verify Octet Key Pair (OKP) Public Key Signature func (k *OKPPublicKeyData) Verify(data []byte, sig []byte) (bool, error) { f := HasherFromCOSEAlg(COSEAlgorithmIdentifier(k.PublicKeyData.Algorithm)) h := f() h.Write(data) var oKey eddsa.PublicKey err := oKey.FromBytes(k.XCoord) if err != nil { return false, err } return oKey.Verify(h.Sum(nil), sig), nil } 

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

لهذا السبب لا أرغب في قبول طلبات طلبات السحب التي تنقل الرمز. حتى إذا كان التنظيم الجديد للرمز أفضل من السابق ، فإن الوقت الذي يستغرقه التحقق من "ما إذا كان البحث الجديد يقوم بشيء إضافي" يستهلك الكثير من الوقت.

لقد نشرت تحذيرًا حول تبعية المكتبة بترخيص AGPL ، وقام المطورين بإرجاع golang.org/x/crypto/ed25519 . على الرغم من ذلك ، قررت عدم استخدام github.com/duo-labs/webauthn . تم تصميم الجزء الأكبر من المكتبة وتوابعها لدعم WebAuthn misfeature المسمى attestation ، والذي لدي رغبة أقل من الصفر في استخدامه. لقد انتهيت للتو من كتابة مكتبة أكثر بساطة وخالية من التصديق ، وأصغر من عُشر ما سبق. قريباً سأفتح الكود المصدري. جاء تطوير هذه المكتبة أرخص من مسؤولية استخدام مكتبة WebAuthn Go الحالية.

هذه الحالة ذكرني لماذا أحب البرمجة على الذهاب. بفضل مكتبات Go الواسعة النطاق وشبه القياسية "x" ، عادة ما تكون هناك القليل من التبعيات الإضافية في مشاريعي. تسمح لي سمعة جيدة وإجراءات التشغيل الخاصة بـ Go بأخذ حمام بخار وعدم التحقق من الكود المصدري للمترجم والمكتبات القياسية. وعلى الرغم من أنني أحب روست ، فإنني أشعر بالفزع في كل مرة أنظر فيها إلى شجرة التبعية في مكتباتهم النموذجية: عادةً ما أرى العشرات من التبعيات التبادلية التي كتبها رفاق عشوائية غامضة من الإنترنت ليس لدي أي سبب للثقة. يستغرق فحص كل هذه التبعيات وقتًا طويلاً ، لذا فأنا أقل إنتاجية في برنامج Rust من Go.

ملاحظة أخيرة: كمشجع لهياكل البيانات القابلة للتحقق منها مثل شهادة الشفافية ، يجب أن أحب قاعدة بيانات المجموع الاختباري Go الجديدة. ومع ذلك ، فإن قاعدة بيانات المجموع الاختباري لن تفيدك إذا لم تقضي وقتًا في التحقق من تبعياتك. لسوء الحظ ، لقد رأيت بالفعل مستخدم Go متحمسًا للغاية يدعي أن قاعدة بيانات المجموع الاختباري تحل جميع المشكلات المتعلقة بإدارة التبعية. لكن هذا ليس كذلك. لا توجد طرق سهلة للتخلص من هذا ، وعليك أن تتصالح مع الحقيقة: من وقت لآخر تحتاج إلى القيام بمراجعات التبعية في مشاريعك.