رابطه باگ امنیتی خون ریزی قلبی با منبع باز در این سال باعث شعله ور شدن علاقه ما به توابع رمزنگاری مربوط به لینوکس و کلا فناوریهای باز امنیتی شده است. صرف نظر از این که خون ریزی قلبی اجتناب ناپذیر ۲.۰ در اطراف باشد یا نه، صنعت فناوری اطلاعات (و همینطور امیدوارانه جامعه کسب و کار) در حال حاضر هشدارهای گستردهای را با مضامینی مثل: وصله کردن، بررسی دقیق، ادغام کد و ناحیه گستردهترای از مدیریت چرخه توسعه برنامههای نرم افزاری را اعلام میکند.
شاون گیلیس به عنوان یک طراح وب، دانشجو و مدافع منبع باز اشاره می کند که مدیران پروژه یا رهبران صنعتی موفق در جامعه منبع باز، اغلب فناوریهای «بررسی دقیق» را به عنوان یک معیار در چرخه توسعه خود بکار میبرند.
چه میزان «بررسی دقیق باز» خوب است؟
با تفکر عمیق بر روی خود پرتال open source.com، گیلیس پرسید چه میزان بررسی دقیق در متن باز قوی است؟
همزمان که نرم افزار متن باز محبوبیت بیشتری به عنوان جایگزین نرمافزارهای اختصاصی پیدا میکند،مهارتهای توسعهای موجود در پشت محصولات باید پالوده و تمیز شوند تا قابلیت اطمینان را در جامعه بهبود ببخشند. نرم افزارهای تولید شده توسط تیمها، کاملتر بوده و در بحث «بررسی دقیق» استانداردتر هستند که باعث تولید نرمافزارهایی با رابط کاربری بهتر و قابل اعتمادتر میشود. گیلیس میگوید زمان مورد نیاز برای اطمینان یافتن از این که الگوی کنترل کیفیت استاندارد شده است، باعث ایجاد محصولی پر جلا میشود.
بنابراین آیا سیستمها کار میکنند یا معیوبند؟ آیا به نام «اجرا غیر همزمان» بررسی دقیق و وصله کردن برای لینوکس سازمانی به اندازه کافی بوده تا عمیقتر وارد محیطهای میزکار بشوند؟ به هر حال چه کسی این موارد را کنترل میکند و این موارد برای بار اول در کجا به بحث گذاشته میشوند؟
به شکل مستقیم به آسیب پذیری خون ریزی قلبی مربوط نیست اما در درون همان خانواده از فناوری قرار میگیرید (بحث به شکل فعال بر روی «درخت وصله کردن زنده است») که به طور فوق العادهای نتیجهاش بر روی خود هسته لینوکس نیز تاثیر دارد و خب بر روی نصبهای سازمانی هسته لینوکس نیز اثر خواهد گذاشت. این موضوع به شکل باز در انجمنهای گفتگو توسعه دهندگان که متشکل از Linux SUSE، Red Hat RHT +0.45% و Hitachi بود مورد کنکاش قرار گرفت.
جیری کسینا از آزمایشگاه SUSE مینویسد: سهم عمدهای از کار در خلاصه کردن کارکردهای اصلی «وصله کردن زنده»، در پیاده سازیهای موجود سرمایه گذاری شده است. بنابراین بهبودهای بعدی میتوانند به صورت گامهای افزایشی بر روی آن ساخته شوند.
آن چیزی که لینوکسهای سازمانی به آن نیاز دارند «مکمل و تکمیل کننده» است، نه الزاما فناوریهای رقابتی (و حداقل ناسازگار) برای رشد کردن.
patch یا graft?
بحث در اینجا بر روی انتخاب میان دو سیستم مختلف پچ کردن هسته است، یکی Kgraft از SUSE و دیگری Kpatch از Red Hat. آنچه که واقعا اتفاق افتاده است این است که کارایی اصلی هر دو فناوری بررسی شده و قسمتهای مشترک ویژگیهای در حال توسعهای که اکنون امکان وقوع دارند به دست آمده است. بنابراین هر دو فناوری (از دو بازیکن لینوکس سازمانی) در نهایت به عنوان ویژگی به هسته 3.20 اضافه خواهند شد. این خبر خوبی است، به دلیل این که هر دو کار یکسانی را از طریق فناوریهای مختلف انجام میدهند.
ریچارد مورل، مبلغ و معمار امنیتی اصلی ابر در Red Hat میگوید:
پچ کردن زنده سیستمها یک مورد روی لبه است که نیاز برای آپتایم و پایداری موثر در آن با مسائل امنیتی اورژانسی و تصحیح باگها تصادم میکند. Red Hat پیش نمایش فناوری Kpatch را در RHEL 7 گنجانده است و به کار بر روی چارچوب کلی پچ کردن زنده برای پشتیبانی موارد کاریای که از سرورهای چندکاربره عادی تا اپلاینسهای توکار هستند، ادامه میدهد. ما نیاز داریم تا معقول و اهل عمل باشیم، Red Hat Enterprise Linux رسایی و پذیرش صنعتی گستردهای بخاطر پایداری دارد. اگر ما نیازهای امنیتی هر روزه محیطهای محافظت شده با برچسب معتبر شناخته شده را، در بسیاری از موارد سازمانی که بر Red Hat تکیه دارند بررسی کنیم، خواهیم دید که علاقهمند به دانستن درباره Live impacting، بشکل خاص در مورد گسترش ابرهای بزرگ مقیاس بارکاری، هستند. اکثر این بارهای کاری بر روی Red Hat Linux Enterprise اجرا میشوند.
ماهیت اصلی این موضوع، فرآیند بروزرسانی و بهبود امکانات، همانند کاربران میزکار است که سیستمهای عامل Apple و Microsoft آنها را از بروزرسانیهای دورهای آگاه میکنند. اگر یک تیم فناوری اطلاعات نیاز به انجام بروزرسانی مهم در یک خوشه سرور به دلیل هشدارهای امنیتی یا تنها به خاظر نسخه جدیدی که موجود است، داشته باشد، ما نیاز داریم تا سازگاری و پشتیبانی یکپارچگی کد را از خارج ببینیم. نتایج بازی پایانی این راه را امنتر میکند. باز یا غیر باز.