تجربیاتی که از اولین مشارکتم در یک پروژه نرم افزار آزاد کسب کردم ۲

درود

در ادامه‌ی ماجرای اولین مشارکت درست حسابیم(کمی درست حسابی) در یک پروژه نرم افزار‌آزاد، ماجرای اولین درخواست واکشیمو براتون گفتم. البته بگم، من نمیگم که حتی کل مشارکتام روی همم باز چیز بزرگیه، هدف من این بود که در روند توسعه یک پروژه تاثیر زیادی داشته باشم. حالا چه یک پروژه کوچیک یا یک پروژه بزرگ. حتی منظورم این نبود که مشارکتام باید از نظر فنی نیاز به دانش زیادی داشته باشن.

معنای Phoenix یعنی ققنوس، عکسی هم که برای این نوشته انتخاب کردم یک ققنوسه که در فرسته‌های بعدی میگم از کجا اومده.

اون زمان Phoenix تنها میتونست از راه کدنوشته‌ها نصب و حذف‌نصب بشه و کاملا به کدنوشته‌ها وابسته بود. فرایند نصب خیلی ساده بود، با wget پرونده هارو از مخزن Codeberg در tmp/ بارگیری میکردی و بعدش هم اون پرونده هارو با mv سر جای خودشون میذاشتی. فرایند حذف‌نصب هم با rm انجام میشد.

کد نوشته‌ها رو هم کاربر اینجوری اجرا میکرد. برای نمونه اجراء کدنوشته‌ی نصب به این صورت بود

sudo bash -c "$(curl -fsSL https://phoenix.celenity.dev/uninstall.sh)"

پیوند phoenix.celenity.dev هم فقط یک تغیر مسیر برای حالت خام(raw) پرونده‌ها در مخزن codeberg بود.

این روش حذف و نصب در بسیاری از پروژه ها به کار گرفته میشه و کاملا هم شناخته شده هست. قبول دارم این روش نصب برنامه‌ها اصلا خوب نیست و برای ناپایدار کنندگیش هم معروفه.

اما، امااااا، شنیدن کی بود مانند دیدن!

من حتی قبل از اینکه در Phoenix شرکت کنم و خودم عامل ایجاد یکی از این روش ها بشم و تاثیراتشو روی مردم هم ببینم باز هم به این حرفا که «نرم افزار هارو بجز از مخازن رسمی و مدیر بسته، از جای دیگه نصب نکن. هر کد‌نوشته‌ای رو اجرا نکن و …..» اعتقاد زیادی داشتم.

من همیشه تمام تلاشمو میکنم که چیزی رو از مخازن غیر رسمی نصب نکنم و هر کدنوشته‌ای رو اجرا نکنم. ولی وقتی خودم وارد این جریانانت شدم فهمیدم که عهههههههههه بابا این روش رسما فضاحت ملیه. ولی خب تا خودم توزیع چند نفرو نترکوندم به این حد به این جمله اعتقاد نداشتم. الآن نه تنها اعتقاد دارم بلکه بهش ایمان راسخ هم دارم.

من و Celenity در روند توسعه Phoenix به اشکالات و خراب‌کاری‌های زیادی برخوردیم. اکثر این مشکلات هم فقط به خاطر این کدنوشته های نصب و حذف بود.

اولین مشکل این روش کند و اعصاب خرد کدن بودن اون بود، کاربر برای هر نصب و حذف باید مرورگر رو باز میکرد، وارد مخزن ما میشد، دستور حذف یا حذف‌نصب رو رونوشت میکرد و در پاپانه اجرا میکرد. شاید فکر کنید خب در طول استفاده از یک نرم افزار مگه چند بار باید اونو نصبو حذف کنم مگه؟ همش یکبار نصبش میکنم و بعدش هم یکبار حذفش میکنم. ولی خب این تمام ماجرا نبود مشکل اصلی این بود که جنس پروژه Phoenix از جنس پروژه هایی هست که به بروزرسانی های زیادی نیاز دارن و این روش نمیتونست بروزرسانی رو به صورت خودکار انجام بده و خب هدف ما این بود که این پروژه برای استفاده‌ی روزانه‌ی کاربر مناسب باشه و نه اینکه صرفا بیاد یه ناخونکی بزنه و بره پی کارش! میخواستیم کاربر بتونه بروزرسانی هارو به راحتی دریافت کنه، در این روش حتی کاربر نمیتونه به راحتی از انتشار یک نگارش جدید به راحتی مطلع بشه!!! 🤦🏻‍♂️🤦🏻‍♂️🤦🏻‍♂️🤦🏻‍♂️

دومین مشکل این این روش ناهماهنگی‌ای بود که در سامانه‌‌ی پرونده ها ایجاد میکرد

سومین مشکل یک اشکال امنیتی بود که در این روش وجود داشت!!!!!!!!!!! ما وقتی متوجه این اشکال شدیم که یک نفر اونو گذارشش داد. البته این بنده خدا اینو برای نصب دستی گفته بود، ولی خب نصب با کدنوشته هامون هم این مشکلو داشت.

حرف اون بنده خدا:

The manual install instructs several “sudo mv” operations. IIUC ‘mv’ will maintain the original owner and permissions. This would mean that the policy and configuration files, when properly installed, are still owned by the user instead of e.g. root. Thus there is access to and room for malicious changes. (And depending on umask, might also not be accessible to other users on the system even though placed in system-wide paths.)

یادتونه گفتم پرونده های بارگیری شده رو با mv سر جای خودشتون جاگذاری میکردیم؟ خب مشکل اینکه دستور mv برعکس دستور cp بعد از انتقال یک پرونده صاحب پرونده رو به کاربری که این انتقالو انجام داده تغیر نمیده!! یعنی اگه شما با sudo cp یک پرونده رو که خودتون صاحب اون هستید رو در جای دیگه جاگذاری کنید، چون شما این کارو با دسترسی کاربر ریشه انجام دادید مثل اینکه واقعا خود کاربر ریشه این کارو کرده و دستور cp میاد صاحب پرونده‌ی جدید به کاربر ریشه تغیر میده ولی دستور mv این کارو نمیکنه و ما با این کار چنتا پرونده‌ رو که کاربر معمولی هم میتونه اونو ویرایش کنه در جای خطرناکی قرار داده بودیم. تازه چه پرونده‌هایی رووو! پرونده هایی که برای پیکربندی مرورگر استفاده میشدند!

مشکل که زیاد بود، یک بار یه کاربر میومد میگفت که کدنوشته حذف کار نمیکنه، یه بار یکی دیگه میگفت کدنوشته نصب کار نمیکنه، یه بار یکی میومد میگفت که چرا اینقدر تعداد کدنوشته ها زیاده(ما برای هر کدوم از توزیع های آرچ، دبیان و فدورا یک کدنوشته نصب داشتیم و هم یک کد‌نوشته‌ی حذف که روی هم میشه ۶ تا)، یه بار مسیر پرونده هارو اشتباه تنظیم کرده بودیم و یکی از پرونده ها رفته بود به ناکجا آباد و ………………

مشکل تعداد زیاد کدنوشته هارو تونستیم با ایجاد یک کدنوشته‌ی نصب و حذف اصلی که کاربر در اون توزیعشو انتخاب میکرد حل کنیم ولی اونم باز خیلی چیز بیخودی بود. تازه ما میخواستیم این همه کدنوشته با هم هماهنگ هم باشن و تو حالا باید بیای و ۶ تا کدنوشته رو کاری کنی که گذارشاتشونم مثل هم باشه و خب واقعا خیلی سخت بود. خیلی که پیشرفته شدیم، زدیم یکی اصلی برای نصب و یکی اصلی برای حذف ساختیم. یکی از اون اصلی ها رو در زیر میبینید:

البته عکس بالا برای یکی زمانی هست که تازه ما یک نصب و حذف کننده اصلی داشتیم. بعد ها طی چند مرحله‌ی دور و دراز تبدیلشون کردیم به زیری، تازه در عکس زیری ما دیگه برای همه‌ی توزیع ها از بسته‌بندی خودشون استفاده می کردیم

تازه! تنظیم و همانگی رنگ ها در نصب و حذف کننده اصلی باز خودش دوباره خیلی دنگو فنگ داشت!

خلاصه بنده با افتخار بگم که ما با این همه تلاش و مشقت فراوان برای اینکه کاملا مطمئن شیم این کدنوشته ها کارشونو درست انجام میدن، باز به توزیع حدود ۲۰ نفر گند زدیم! البته باز گند های دیگه‌ای هم هست که در فرسته‌های دیگه ای به اونا اشاره میکنم.