انجمن‌های فارسی اوبونتو
کمک و پشتیبانی => انجمن عمومی => نویسنده: Sosha در 07 آبان 1396، 10:59 ق‌ظ
-
maintainer معمولا کسی هست که بسته‌های deb رو آماده می‌کنه تا توی مخزن دبیان قرار بگیره. کم پیش میاد که maintainer و developer یکی باشن و به دلیل مسایل امنیتی توصیه هم نمیشه که یکی باشن.
جناب سلمان خان، در یک ارسالی، نوشته بالا رو گفته بودن، می‌خوام بدونم دلیلش چیه و چرا از نظر امنیتی هم توصیه نمیشه؟
-
اول از همه باید بدونیم که این دو شخص چه کسانی هستن
۱. developer (توسعه‌دهنده): توسعه دهنده اصلی نرم‌افزار
۲. maintainer (نگهدارنده): کسی که packaging (بسته‌بندی) رو برای یه توزیع خاص (اینجا مثلا دبیان) انجام میده و دسترسی مستقیم به مخزن دبیان برای آپلود کردن داره.
اگه این دو مورد بالا یکی باشن، یعنی توسعه دهنده‌ی یه نرم‌افزار مستقیم به مخزن‌های دبیان دسترسی داشته باشه، این مورد از لحاظ امنیتی توصیه نمیشه، ولی اگه دو نفر متفاوت باشن، اگر کسی بخواد توی مخزن‌های دبیان خراب‌کاری کنه، یک پله کارش سخت‌تر میشه (البته غیرممکن نیست ولی سخت‌تر میشه). یعنی نیاز به دو نفر هست، نفر اول که سورس کد نرم‌افزار رو تغییر بده و نفر دوم که کار بسته بندی رو انجام میده. این در صورتی هست که بخواد توی سورس کد دستکاری انجام بده و بفرسته روی مخزن دبیان.
یک مورد دیگه هم هست، به طور مثال، فرض کن که من هم developer و هم maintainer یک بسته خاص هستم، میام نسخه‌ی اول و دوم و سوم نرم‌افزار رو بدون هیچ مشکلی آپلود می‌کنم توی مخزن‌های دبیان ولی سپس از نسخه چهارم تصمیم می‌گیرم که نرم‌افزارم رو با یه کامپایلر که که در هنگام کامپایل کردن، یک سری کدهای اضافه قاطیش می‌کنه، کامپایل کنم و سپس نرم‌افزار رو آپلود کنم توی مخزن‌های دبیان، اینجوری یک نفر می‌تونه راحت‌تر این کار رو انجام بده تا این که دو نفر نیاز باشه.
به صورت کلی برای این که این مشکل رفع بشه، دبیان یک سیستمی رو در حال پیگیری هست به اسم reproducible builds (ساخت‌های قابل بازتولید) که این وب‌گاهش هست (https://reproducible-builds.org) که یک سری راهنمایی‌هایی داره، مثلا میگه که توی artifact تولید شده توسط build system نباید زمان build به عنوان یه variable (متغییر) وجود داشته باشه، تا تغییر در binary تولید شده فقط وابسته به دو تا چیز باشه ۱. تغییر در سورس کد ۲.تغییر در build environment (محیط توسعه، مثل نسخه کامپایلر استفاده شده)، اینجوری میشه اطمینان بیشتری نسبت به نسخه‌های باینری تولید شده داشت.
-
خب Maintainer بستگی به توزیع داره. مثلا ممکنه یکی بخواد توی فدورا برنامه‌ای که من نوشتم رو داخل مخازن بکنه و من اصلا فدورا ندارم، در نتیجه Maintainer مناسبی برای فدورا نخواهم بود.
یک مورد دیگه هم هست، به طور مثال، فرض کن که من هم developer و هم maintainer یک بسته خاص هستم، میام نسخه‌ی اول و دوم و سوم نرم‌افزار رو بدون هیچ مشکلی آپلود می‌کنم توی مخزن‌های دبیان ولی سپس از نسخه چهارم تصمیم می‌گیرم که نرم‌افزارم رو با یه کامپایلر که که در هنگام کامپایل کردن، یک سری کدهای اضافه قاطیش می‌کنه، کامپایل کنم و سپس نرم‌افزار رو آپلود کنم توی مخزن‌های دبیان، اینجوری یک نفر می‌تونه راحت‌تر این کار رو انجام بده تا این که دو نفر نیاز باشه.
البته توی دبیان و اوبونتو، Maintainer فقط سورس‌کدها رو برای مخازن می‌فرسته و کامپایل شدن بسته‌ها توسط یک سیستم مکانیزه انجام میشه.
-
گفته من بر اساس نوشته‌ی اینجا بود که نوشته آپلودهای جدید نمی‌تونن که source only باشن.
https://wiki.debian.org/SourceOnlyUpload
NEW uploads and uploads with NEW binaries currently cannot be source-only.
-
البته اون NEW به معنای عمومی جدید نیست و به NEW Queue اشاره می‌کنه (برای همین هم تماما با حروف بزرگ نوشته میشه). بسته‌های NEW تنها برای این هستند که تصمیم گرفته بشه این بسته توی دبیان قرار بگیره یا نه، برای همین از Autobuilder network برای اون‌ها استفاده نمیشه.
The source and binary packages in the NEW queue are not made publicly available. This is because the purpose of the NEW queue is mainly to work out if the packages can be distributed by Debian.
-
جالب بود تشکر :)
-
این کامپایلرهای GCC و Clang توانایی شناسایی بدافزار توی کد منبع را ندارند؟ منظورم از بدافزار کدهای مخرب و اینجور چیزهاست، کدهایی که خیلی واضح هدفشون مثلن جاسوسی باشه، جمع آوری اطلاعات و ارسال آنها به یک آدرس.
-
این کامپایلرهای GCC و Clang توانایی شناسایی بدافزار توی کد منبع را ندارند؟ منظورم از بدافزار کدهای مخرب و اینجور چیزهاست، کدهایی که خیلی واضح هدفشون مثلن جاسوسی باشه، جمع آوری اطلاعات و ارسال آنها به یک آدرس.
نه ؛ اما کدهای مخازن رسمی اول بازرسی میشن بعد وارد مخزن میشن