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

ترجمه است ولی منبعش نمی دونم کجا بوده

چند سالی است که نمی دونم چرا هر بار آخر سال فکر می کنم باید یک نظرسنجی گسترده درست کنم تا از برنامه نویس ها در مورد خیلی چیزها سوال کنیم، ولی اینکار رو نمی کنم و بعد می گم «سال بعد». اما امسال بالاخره دست به عمل زدم و با همکاری و نظر یکسری از دوستان، یک پرسشنامه طراحی کردیم. ایده این پرسشنامه اینه که در مورد زندگی و شرایط کار برنامه نویس ها، توسعه دهنده ها و مدیر سیستم ها سوال بپرسه و بعد نتایج رو به شکل آزاد به همه بده. سوال ها در بخش های مختلفی (دموگرافیک، زندگی و کار) هستن. بزرگترین فایده اش این دو تا است:
در نتیجه اگر در نظر سنجی گسترده وضعیت برنامه نویس ها و سیستم ادمین های ایران شرکت کنین و جواب ها رو دقیق بدین و مهمتر از اون لینک و مفهومش رو جاهای دیگه پخش کنین عالی می شه. هر چقدر پر شدنش گسترده تر باشه باعث می شه بایاس به سمت خواننده های من، لینوکسی ها، اوپن سورسی ها، … کمتر بشه و جواب ها دقیق تر باشه و به همه ما توی شرایط کاری آینده کمک کنه. خیلی مسخره است که ما اکثرا نمی دونیم که مثلا یک برنامه نویس پی اچ پی حرفه ای با حدود ۱۰ سال سابقه کار در یک شرکت ۱۰۰ نفره تقریبا چقدر باید حقوق بگیره. برای حل این مشکل و خبردار شدن از وضعیت همدیگه نظر سنجی گسترده وضعیت برنامه نویس ها و سیستم ادمین های ایران منتظر شماست: جواب بدین و پخش کنین تا همه از نتایجش استفاده کنیم.
البته برای پخش کردن می تونین فقط از لینک نظر سنجی استفاده کنین ولی توضیح اینکه چرا مهمه رو خوبه همراهش بنویسین: http://j.mp/itstatus1394
به روز رسانی: نتایج نهایی نظر سنجی بزرگ از برنامه نویسان و مدیر سیستم های ایران ۱۳۹۴ اینجا منتشر شدن

یک باگ جدید و جدی توی glibc دیده شده. یک باگ خیلی جدی. کتابخونه سی گنو یا همون glibc یکی از بخشهای بسیار مهم اکثر توزیع های لینوکس است. حالا یک باگ توی این کتابخونه هزاران برنامه لینوکس رو تهدید می کنه. این باگ نسبتا شبیه باگ سال گذشته GHOST است (CVE-2015-0235) که اجازه می داد از راه دور کدهایی روی ماشین اجرا بشه.
باگ فعلی (CVE-2015-7547) یک باگ سرریز استک (stack based buffer overflow) است در بخش کلاینت دی ان اس glibc که وظیفه تبدیل کردن آدرس های قابل فهم برای آدم ها (مثلا jadi.net) به آی پی رو داره.
این مشکل وقتی دیده می شه که یک دستگاه دارای باگ سعی کنه به یک DNS سرور بدطینت ریکوئست بزنه و نتایج رو توی حافظه بذاره (تابع getaddrinfo). چیزی که دی ان اس سرور بدخواه بدجنس بر می گردونه ممکنه حاوی کدی باشه که کار مخربی می کنه و نشستنش توی حافظه – در سطرح تئوری – باعث اجراش خواهد شد. البته در عمل این اتفاق تقریبا غیر ممکنه چون انواع مکانیزمهای امنیتی جلوی اونو خواهند گرفت (شامل ASLR). حالت بعدی اینه که حمله کننده به شکل مرد میانی درخواست های دی ان اس رو خودش بر می گردونه و بینشون کدهای نامناسب درج می کنه.
تقریبا هر سیستم لینوکس جدید با این مشکل مواجه خواهد بود. این باگ از جی لیب سی ۲.۹ به بعد ظاهر شده و در نتیجه هر برنامه ای که با استفاده از توابع glibc به شبکه دسترسی پیدا می کنه ریسک داره. نمونه ها؟ اس اس اچ، سودو و کرل. لیست کامل می خواین؟ تقریبا غیر ممکنه. بهتره تصور کنین اکثر برنامه های مرتبط با شبکه و حتی زبون های پایتون، پی اچ پی، روبی، … و البته برنامههای بیت کوین.
محققین گوگل می گن که بخشی از glibc که به دی ان اس ریکوئست می زنه مشکل داره. این مساله به جی لیب سی تذکر داده شده و اصلاح شده و همه باید آپدیت کنیم… حداقل در طول هفته آینده دائما آپدیت کنیم. مهندسین گوگل می گن:
جی لیب سی ۲۰۴۸ بایت برای استک الوک می کنه تا جواب دی ان اس از _nss_dns_gethostbyname4_r رو توش ذخیره کنه. جلوتر در تابع send_dg و send_vc اگر جواب بزرگتر از ۲۰۴۸ بایت باشه، بافر جدیدی درست می شه و پوینترها آپدیت میشن. در شرایط خاص ناهماهنگی بین بافر استک و تخصیص دهی جدید هیپ پیش می یاد و نتیجه این می شه که بافر استک برای ذخیره کردن جواب دی ان اس استفاده می شه، حتی در مواقعی که جواب بزرگتر از اندازه این بافر باشه. این مساله موجب اورفلوی بافر استک می شه.
(فارسی گفتن اینها عجیب می شه. متن اصلی اینجاست).
سه شنبه مهندس گوگل فرمین سرنا یک اکسپلویت برای اثبات این مساله منتشر کرد. با استفاده از این اثبات مفهوم می شه چک کرد که آیا برنامه های ما در مقابل این مشکل صدمه پذیر هستن یا نه (هستن!).
مهندسین گوگل با همراهی ردهت یک پچ برای حل مشکل ارائه کردن. اما مساله اینه که حالا تک تک توزیعها باید glibc خودشون رو آپدیت کنن و هر برنامه ای که استاتیک این کتابخونه رو لینک کرده، باید خودش رو آپدیت کنه. مثل همیشه در دنیای لینوکس وقتی مشکلات دیده بشن سریعا حل می شن و من و شما فقط کافیه آپدیت کنیم. پس در روزهای آینده حواستون به آپدیت ها باشه منتظر آپدیت های زیاد باشین. همچنین اگر از سروری محافظت می کنین که به اینترنت وصل نیست، دردسرهای نسبتا زیادی منتظر شما خواهد بود چون آپدیت کردن این سیستمها معمولا دردسره و در مواردی شاید نتونین به سادگی فقط glibc رو آپدیت کنین.
در حالت معقول نه. کامپیوترهای ما به دی ان اس سرورهای بدجنس وصل نمی شن و اگر از لینوکس هایی به روز استفاده کنیم مشکل همین الان هم تا حدی برطرف شده و فقط در روزهای آینده باید آپدیتها رو جدی بگیریم همچنین اندرویدها به جای glibc از بیونیک استفاده می کنن که این مشکل رو نداره و اکثر لینوکس های درونکار( امبدد؟ ) هم مشکلی نداره چون اکثرا uclibc هستن.
به سادگی در کامنت ها مطرح کنین و سعی می کنم در سطح سواد و وقت جواب بدم و بقیه رو هم می سپریم به دوستان باسوادتر در کامنت ها (:
دوستان خوب شرکت وادا همین فردا پنجشنبه یک گردهمایی خوب تشکیل دادن: جشن انتشار نسخه ۱.۶ زبان برنامه نویسی گو. اگر دوست دارین توی این جشن گوفری شرکت کنین زمان دقیقش پنجشنبه ۲۹ بهمن ساعت سه تا شش بعد از ظهر است و مکان دقیقش ستارخان، ابتدای باقرخان ،پلاک ۱۲۴ طبقه منفی ۲ شرکت وادا (نقشه گوگل). برای اطلاعات بیشتر سایت جهانی رو ببینین یا در اینجا ثبت نام و در جشن شرکت کنین. امیدوارم به جز خوراکی، برنامههای آشنایی با زبان و غیره هم باشه اما علی الحساب با این راهنمای اینتراکتیو با مقدمات گو آشنا بشین.
همراه اول یک سیستم فروشگاه درست کرده و کپچای بامزه ای هم براش گذاشته، اما مشکل اینجاست که دو چیز رو هیچ وقت نباید دوباره اختراع کرد: کپچا و رمزنگاری. در این شماره با اسکرپینگ، پایتون و کمی آمار از دیتا استور ردیس استفاده می کنیم تا ببینیم مشکل اختراع دوباره چرخ چیه!
لینک روی یوتیوب و هر کس هر جای دیگه آپلود کنه و لینک بده، باعث خوشحالی و دعای خیر پشت سانسوریهاست (:
آپدیت: انواع لینک دانلود در کامنت ها (:
آپدیت: دوستان در کامنت ها چندین بار گفتن که چرا توی بش چند صد بار برنامه رو اجرا کردیم. در واقع این ویدئوها آموزشی هستن و ایده شون این نیست که راحتترین روش انجام یک چیز رو نشون بدن. می خوایم حتما از ردیس استفاده کرده باشیم اینجا. نشون بدیم که چطوری می شه پیچیدگی برنامه نویسی رو با یک معماری خوب به حداقل رسوند. چطوری می شه یک سیستم رو قابل اجرا روی چندین کامپیوتر مختلف کرد و اصولا ردیس چیه (: معلومه که «ساده ترین» روش نوشتن این برنامه خاص این بود که توی پایتون یک لوپ و کمی آسینک قاطی کنیم و نتایج رو توی یک دیکشنری بشمریم. البته در عمل اون پیچیدگی هایی داشت تا به این سرعت برسه ولی خب برنامه نویسی سنتی تری بود. دقیقا ایده این ویدئو کست این بود که نشون بدیم چطوری باید اجزای شناخته شده و بسیار قوی رو ترکیب کرد تا به سادگی به یک سیستم با قابلیت بسیار بالا رسید.

چه از قبل رجکس بلد بوده باشین، چه توی ویدئوی آموزش رجکس باهاش آشنا شده باشین، چلنجهای این سایت میتونه چند دقیقه تا چند ساعت سرگرمتون کنه. احتیاط کنین که اعتیاد آور هم هست: جدول رجکسهای متقاطع
رجکس (regex) بخش مهمی از دنیای مدرن کامپیوتر است. از سیستم عاملها تا ادیتورها تا زبانهای برنامه نویسی از رجکس استفاده می کنن. اما خیلی از آدمها با رجکس راحت نیستن. نه به این دلیل که رجکس سخته بلکه به این دلیل که کمی وقت نذاشتن ایده ساده پشت رجکس رو بخونن. این ویدئو بدون تمرکز بر جزییات رجکس، سعی می کنه این ایده رو توضیح بده.

فرض ۰ – آی ای شش و ویندوز ایکس پی زنده هستن
فرض ۱ – برنامه نویسی هست که فقط با یک تکنولوژی منسوخ روی آی ای ۶ کار کرده
فرض ۲ – مدیر پروژه ای هست که اصولا نمی دونه چطوری باید تکنولوژی انتخاب کنه
فرض ۳ – مدیر فنی ای هست که درکی از جهت حرکت دنیای وب نداره
فرض ۴ – مسوول آموزشی هست که نمیدونه باید چه نرم افزاری بخره
فرض ۵ – مشاورهای دانشگاه اصولا درکی از اینترنت، برنامه نویسی و تکنولوژیهاش ندارن یا دانشگاه اصولا مشاور فنی نداره
فرض ۶ – کل ایدهها و قوانین دسترسی برابر و آزاد به سیستم آموزشی بی اهمیت هستن
فرض ۷ – دانشجوها و نظرشون هیچ اهمیتی ندارن
فرض ۸ – متخصصین و نظرشون اهمیت خاصی نداره
اگر فرضیات بالا صحیح باشن به نظرتون به چی می رسیم؟ به سیستم جامع دانشگاهی گلستان که البته در مورد دانشگاه من یعنی خواجه نصیر، اس اس ال سرتیفیک ارور هم می ده حتی (: