فعّال‌ساز آفلاین ویندوز روی سافت ۹۸ قرار گرفت.
ریتوئیت کنید، کسایی که دهن‌شون سرویس شده بود، و هم راستا باهاش دهن ما رو هم سرویس کرده بودن ببینن 🌹
https://x.com/SMostafaMoosavi/status/2053434126493995422?s=20

@codehalics | کدهالیک

اپل و گوگل دارن کم‌کم کاری می‌کنن که خیلی از سرویس‌ها فقط وقتی بهت اجازه ورود بدن که گوشی یا سیستم‌عاملت از نظر خودشون «تأیید شده» باشه. مثلاً بانک، اپلیکیشن دولتی، کپچا یا سایت‌ها ممکنه از دستگاهت مدرک بخوان که رسمی و مورد قبول اپل یا گوگله. روی کاغذ اسمش امنیته، ولی GrapheneOS می‌گه مشکل اینجاست که اگه از سیستم‌عامل‌های آزادتر، کاستوم‌رام‌ها، لینوکس، یا دستگاه‌های خارج از چارچوب اپل و گوگل استفاده کنی، ممکنه الکی از بعضی سرویس‌ها محروم بشی.

نگرانی اصلی اینه که این ماجرا فقط محدود به موبایل نمی‌مونه و داره وارد وب هم می‌شه. یعنی حتی اگه با لپ‌تاپ ویندوزی، لینوکسی یا هر سیستم دیگه‌ای وارد یک سایت بشی، ممکنه سایت ازت بخواد با یک گوشی آیفون یا اندرویدِ تأییدشده توسط گوگل، هویت دستگاهت رو ثابت کنی. خلاصه حرف GrapheneOS اینه که این سیستم‌ها شاید به اسم امنیت معرفی بشن، ولی در عمل می‌تونن آزادی انتخاب کاربر رو کم کنن و قدرت اپل و گوگل رو بیشتر کنن.

https://grapheneos.social/@GrapheneOS/116550899908879585

@codehalics | کدهالیک

ماجرا اینه که Anthropic گفته بود مدل جدیدش به اسم Mythos خیلی در پیدا کردن باگ‌های امنیتی توی کد قویه؛ انقدر قوی که فعلاً عمومی منتشرش نکرده. برای همین به بعضی پروژه‌های متن‌باز، از جمله curl، فرصت دادن که کدشون رو با این مدل اسکن کنن. curl هم چون یکی از مهم‌ترین ابزارهای اینترنتیه و تقریباً همه‌جا استفاده می‌شه، گزینه خیلی حساسی بود. نتیجه؟ Mythos گفت ۵ آسیب‌پذیری امنیتی پیدا کرده، ولی تیم curl بعد از بررسی دید فقط یکی‌شون واقعاً آسیب‌پذیریه؛ اون هم با شدت پایین و قرار شده جزئیاتش بعداً همراه نسخه جدید curl منتشر بشه.
نکته جالب حرف دنیل استنبرگ، سازنده curl، اینه که می‌گه هایپ Mythos شاید بیشتر تبلیغاتی بوده تا یک جهش عجیب. یعنی Mythos خوبه، ولی از نظر او فعلاً شواهدی نیست که خیلی خطرناک‌تر یا شگفت‌انگیزتر از ابزارهای AI قبلی باشه. با این حال، خودش تأکید می‌کنه که ابزارهای تحلیل کد با هوش مصنوعی واقعاً مفیدن و از ابزارهای قدیمی خیلی بهتر باگ پیدا می‌کنن. جمع‌بندی‌اش اینه: AI فعلاً نوع کاملاً جدیدی از باگ کشف نکرده، ولی در پیدا کردن نمونه‌های جدید از همان باگ‌های قدیمی خیلی قوی شده؛ پس پروژه‌هایی که هنوز کدشان را با این ابزارها اسکن نکرده‌اند، احتمالاً کلی مشکل پنهان دارند.

https://daniel.haxx.se/blog/2026/05/11/mythos-finds-a-curl-vulnerability/

@codehalics | کدهالیک

وقتی Mythos لانچ بشه، باگ‌هانترهای ایرانی به شرکت‌هایی که سروراشون ۷۲ روزه آپدیت نشده:

@codehalics | کدهالیک

این میم هر کسی درک نمیکنه :)))))))))))

@codehalics | کدهالیک

بریم برای ادامه قوانین مهندسی نرم‌افزار بعد از مدت‌ها. این‌بار سراغ Pareto Principle یا قانون ۸۰/۲۰ بریم؛ قانونی که میگه معمولاً ۸۰ درصد نتیجه‌ها از ۲۰ درصد علت‌ها میاد. توی نرم‌افزار یعنی همه‌چیز به یک اندازه مهم نیست. مثلاً ممکنه ۲۰ درصد فیچرهای یک محصول، ۸۰ درصد استفاده کاربران رو بسازن؛ یا ۲۰ درصد باگ‌ها، عامل بیشتر کرش‌ها و نارضایتی‌ها باشن. پس به‌جای اینکه انرژی تیم رو مساوی بین همه‌چیز پخش کنیم، باید بفهمیم اون بخش‌های کم‌تعداد ولی پراثر کجان و اولویت رو بذاریم روی همونا.

#lawsofsoftwareengineering

@codehalics | کدهالیک

مثالش توی مهندسی نرم‌افزار خیلی ملموسه. مایکروسافت متوجه شده بود حدود ۲۰ درصد باگ‌های Windows و Office باعث ۸۰ درصد کرش‌ها میشن، حتی فقط ۱ درصد باگ‌ها حدود نصف خطاها رو ایجاد می‌کردن. پس تمرکز روی همون چند باگ حیاتی می‌تونست کیفیت محصول رو خیلی سریع‌تر بهتر کنه. توی محصول هم همین اتفاق می‌افته؛ شاید از ۵۰ تا قابلیت، فقط ۵ تا ۱۰ تای اون‌ها واقعاً توسط اکثر کاربران استفاده بشن. قانون پارتو یادآوری می‌کنه کار حرفه‌ای یعنی اول پیدا کنیم کدوم بخش‌ها بیشترین اثر رو دارن، بعد زمان، انرژی، تست، بهینه‌سازی و تصمیم‌های محصولی رو همون‌جا خرج کنیم؛ نه اینکه با همه‌چیز مثل یک اولویت برابر برخورد کنیم.

@codehalics | کدهالیک

قانون پارتو توی ایران هم کلی مثال واقعی داره. مثلاً در اسنپ‌باکس، کسب‌وکارها فقط حدود یک‌سوم کاربران رو تشکیل می‌دادن، اما نزدیک به ۸۰ درصد سفرهای این سرویس از سمت همین گروه می‌اومد. یعنی همه کاربران به یک اندازه اثرگذار نیستن؛ یک سگمنت خاص می‌تونه بار اصلی مصرف، درآمد و حساسیت محصول رو بسازه.

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

@codehalics | کدهالیک

صبح زیباتون رو با خبر هک TanStack شروع کنیم؛ همون اکوسیستمی که React Query یا TanStack Query از دلش اومده. طبق گزارش Snyk، در حمله زنجیره تأمین npm، ده‌ها پکیج @tanstack آلوده منتشر شده و هدف اصلی هم سرقت اطلاعات و توکن‌های CI/CD بوده.

https://tanstack.com/blog/npm-supply-chain-compromise-postmortem

@codehalics | کدهالیک

نکته مهم اینجاست که طبق گزارش خود TanStack، پکیج‌های خانواده Query آلوده نبوده‌اند. بنابراین تیتر دقیق ماجرا این نیست که «React Query هک شد».
اتفاق اصلی در بخشی از اکوسیستم TanStack و از مسیر GitHub Actions، کش آلوده و فرآیند انتشار پکیج‌های npm رخ داده است.
ماجرا از یک Pull Request ظاهراً عادی شروع شد. مهاجم‌ها از یک الگوی خطرناک در GitHub Actions به نام pull_request_target سوءاستفاده کردند.

این workflow کدی را که از سمت یک fork بیرونی آمده بود اجرا کرد و همان‌جا مسیر آلودگی باز شد. کد مخرب مستقیماً همان لحظه پکیجی منتشر نکرد، بلکه cache مربوط به pnpm را آلوده کرد.
چند ساعت بعد، زمانی که یکی از maintainerهای اصلی TanStack یک تغییر سالم را merge کرد، release workflow رسمی اجرا شد. اما این workflow در زمان اجرا از همان cache آلوده استفاده کرد.
در این مرحله، بدافزار توانست از حافظه GitHub Actions Runner توکن OIDC را استخراج کند و با همان توکن، بدون اینکه npm token کسی دزدیده شده باشد، نسخه‌های آلوده را روی npm منتشر کند.
نتیجه این شد که در تاریخ ۱۱ می ۲۰۲۶، طی حدود ۶ دقیقه، ۸۴ نسخه آلوده از ۴۲ پکیج tanstack/* روی npm منتشر شد.

این نسخه‌ها در زمان نصب با npm install، pnpm install یا yarn install می‌توانستند روی سیستم توسعه‌دهنده یا محیط CI اجرا شوند و به دنبال اطلاعات حساسی مثل توکن‌های AWS، GCP، Kubernetes، Vault، GitHub، npm، فایل‌های .npmrc و کلیدهای SSH بگردند.

اهمیت این خبر دقیقاً همین‌جاست. این فقط یک باگ در یک کتابخانه فرانت‌اند نبود؛ یک نمونه جدی از حمله به زنجیره تأمین نرم‌افزار بود.
یعنی به‌جای حمله مستقیم به اپلیکیشن‌ها، مهاجم سراغ ابزارها و پکیج‌هایی رفته که هزاران پروژه به آن‌ها اعتماد می‌کنند.
خوش‌شانسی ماجرا این بود که نسخه‌های آلوده خیلی زود شناسایی شدند. حدود ۲۰ دقیقه بعد از انتشار، یک researcher خارجی الگوی مشکوک را گزارش کرد و تیم TanStack هم سریع وارد incident response شد.

نسخه‌های آلوده deprecated شدند، cacheها پاک شدند، دسترسی‌ها محدود شد و موضوع با npm security پیگیری شد.
در نهایت بخشی از اکوسیستم TanStack از مسیر GitHub Actions و npm supply chain آلوده شده است.

اگر کسی در تاریخ ۱۱ می ۲۰۲۶ نسخه‌های affected را نصب کرده، باید سیستم نصب‌کننده را potentially compromised فرض کند و credentialهای مهم مثل GitHub، npm، AWS، GCP، Kubernetes، Vault و SSH را rotate کند.

@codehalics | کدهالیک

حالا بهتر می‌فهمم چرا بعضی SDKهای جدید، مخصوصاً در اکوسیستم‌هایی مثل Telegram Mini Apps، تا این حد روی zero-dependency بودن حساس شده‌اند.

ماجرا فقط سبک‌تر شدن پکیج یا کم شدن حجم bundle نیست. بحث اصلی امنیت زنجیره تأمین است.

وقتی یک SDK وابستگی خارجی ندارد، یعنی با نصب آن، یک زنجیره بلند از پکیج‌های ناشناس، maintainerهای مختلف، workflowهای جداگانه و releaseهای غیرقابل‌ردیابی وارد پروژه نمی‌شود.

در اکوسیستم npm، خطر فقط خود پکیجی نیست که نصب می‌کنیم. خطر واقعی گاهی در dependencyهای عمیق‌تر است؛ همان پکیج‌های کوچکی که مستقیم نمی‌شناسیم، اما در زمان install یا build می‌توانند کد اجرا کنند.

اتفاق TanStack دقیقاً همین را دوباره یادآوری کرد. مهاجم لازم نداشت مستقیم به اپلیکیشن نهایی حمله کند. کافی بود بخشی از مسیر build، cache و release را آلوده کند تا نسخه‌های مخرب از چند پکیج منتشر شوند.

برای همین zero-dependency یک تصمیم صرفاً فنی نیست؛ یک تصمیم امنیتی است.

یعنی تیم توسعه می‌گوید تا وقتی واقعاً مجبور نیستیم، اعتمادمان را بین ده‌ها پکیج و maintainer پخش نمی‌کنیم. هر dependency جدید، فقط چند کیلوبایت کد اضافه نیست؛ یک نقطه اعتماد جدید است.

البته zero-dependency یعنی ریسک کمتر، نه امنیت مطلق. خود همان پکیج هم ممکن است compromise شود، release pipeline آن هم ممکن است آسیب ببیند، اما حداقل سطح حمله کوچک‌تر می‌شود.

پس وقتی می‌بینیم یک SDK جدی تلاش می‌کند بدون dependency خارجی کار کند، دلیلش فقط performance نیست. بخشی از ماجرا این است که هک کردنش سخت‌تر شود، audit کردنش ساده‌تر باشد و زنجیره اعتمادی که وارد پروژه می‌کند کوتاه‌تر بماند.

درس ساده ماجرا:

در دنیای امروز، هر دپندنسی یک تصمیم امنیتی است، نه فقط یک انتخاب فنی.

البته شما از tanstack استفاده کنین اینجا ایرانه چرخ از اول اختراع نکنین خواهشا خداروشکر ما ها اینترنت نداریم که هک بشیم ( البته کاش داشتیم هک میشدیم ولی وضعمون این نبود )

@codehalics | کدهالیک

فک کنم در جریان Rust-base شدن Bun هستید؛
امروز بالاخره Bun Image رو ریلیز کرد و صادقانه یکی از جذاب‌ترین فیچراییه که تا الان برای این ران‌تایم دیدم
دیگه لازم نیست برای image processing سمت سرور برید سراغ پکیج‌هایی مثل Sharp (همون چیزی که Next.js هم استفاده می‌کنه).
خود Bun یه image processor نیتیو نوشته که مستقیم توی ران‌تایم کار می‌کنه؛
با چند خط ساده می‌تونید resize کنید، کیفیت عکس رو کم کنید، فرمت عوض کنید، crop بزنید و کلی کار دیگه.
مثلاً:
const image = await Bun.file("./photo.jpg").image();

await image
.resize(800, 800)
.jpeg({ quality: 70 })
.write("./optimized.jpg");

بنظرم یه سر به ریپو bun بزنین چیزای باحالی تو این ران تایم هست ک میتونید ازش استفاده کنید

@codehalics | کدهالیک

این حرفی که این آقا میزنه رو من صد در صد باهاش موافقم چون خودم یه بار این مسیرو رفتم و واقعا دیدم که کار جالبی نیست این هزینه بابت این لپتاپ به این سنگینی !

feel free to change my mind btw ...

پ.ن : البته بگم این عقیده حداقل یه بابای پولدار یا یه خط ۱ ۹۱۲ یا ... میخواد الان متاسفانه قبلا اینطوری نبود با ۴ تا قرض و قوله میشد مک بخری الان نمیشه ولی اگر پولشو داشتید نکنید اینکارو مک بخرید برای برنامه نویسی !

@codehalics | کدهالیک

من توی فرانت چپتر ۱۴۰۲ دقیقا همین اتفاق برام افتاد یه لجیون داشتم خدا ! بعد هر کی میومد مک اش در میاورد بدون شارژر بدون هیچی
من رفتم بالا این گولاخ دراوردم شارژر میخواست شارژ نداشت اصلا جاش نمیشد تو اون استند جایی که میخوام توضیح بدم و خلاصه یه طور خاصی بود که فهمیدم از بعد اون چرا مردم میرن مک میخرن !

بازم میگم این عقیده برای قبل دلار ۱۸۵ ت ای پایدار و استیبل بود الان دیگ کلا هر چی گیرتون اومد بخرید واقعا از این گرون تر نشه !

@codehalics | کدهالیک

اگر پروژه خاصی دارید که دارید روش کار می‌کنید، Claude همین الان این لینک رو گذاشت برای کسایی که می‌خوان open source کار بکنن روی پروژه‌هاشون و بهتون Claude Max 20X رو می‌ده کاملاً رایگان.

https://claude.com/contact-sales/claude-for-oss

@codehalics | کدهالیک

ما مهندس‌های نرم‌افزار عادت داریم سیستم‌ها را از بیرون نگاه کنیم: ورودی‌ها را ببینیم، پردازش‌ها را بفهمیم، و خروجی‌ها را بررسی کنیم.
اما کمتر پیش می‌آید همین نگاه را به ذهن خودمان داشته باشیم.

شاید ذهن هم چیزی شبیه یک سیستم پیچیده باشد؛ سیستمی که قضاوت می‌کند، تصمیم می‌گیرد، خطا می‌کند، یاد می‌گیرد و در طول زمان evolve می‌شود.
از این زاویه، تفکر انتقادی و فراشناخت فقط مهارت‌های ذهنی نیستند؛ نوعی مهندسیِ خودآگاهانه‌اند.

این نوشته تلاشی است برای نگاه کردن به ذهن، نه از درونِ عادت‌های روزمره، بلکه از بیرونِ یک نگاه سیستمی.

این مقاله از محمد حسن رشیدی که تکنیکال لید آسان پرداخت هست رو حتما بخونید !
تقریبا اولین مقاله فارسیه که من دارم اینجا ریفر میدم که خونده شه

لینک مقاله در لینکدین

@codehalics | کدهالیک

خلاصه مقاله اینه که جناب رشیدی (نویسنده) ذهن انسان رو با یک سیستم نرم‌افزاری مقایسه می‌کنه؛ سیستمی که ورودی، پردازش و خروجی داره. ورودی‌های ذهن ما تجربه‌ها، ترس‌ها، باورها، آموزش‌ها، اخبار و فضای اطرافه. بعد ذهن این ورودی‌ها رو تفسیر، مقایسه و تحلیل می‌کنه و در نهایت خروجی‌هایی مثل تصمیم، رفتار، قضاوت، اعتماد یا تردید تولید می‌شه. بنابراین کیفیت زندگی ما تا حد زیادی به کیفیت همین پردازش‌های ذهنی وابسته است.

جناب رشیدی بعد وارد بحث تفکر انتقادی و فراشناخت می‌شه. تفکر انتقادی یعنی فقط سریع و خودکار فکر نکنیم، بلکه باورها و نتیجه‌گیری‌هامون رو بررسی کنیم. فراشناخت هم یعنی بتوانیم به خودِ فرایند فکر کردن‌مان نگاه کنیم و بفهمیم کجا ممکنه دچار خطا، سوگیری یا خودفریبی شده باشیم. مثلا confirmation bias باعث می‌شه فقط اطلاعاتی رو ببینیم که باورهای قبلی‌مون رو تأیید می‌کنه.

در ادامه مقاله می‌گه ذهن ما مثل سیستم‌های پیچیده همیشه نیاز به بازبینی و بهبود داره. همان‌طور که در مهندسی نرم‌افزار سیستم را مانیتور، دیباگ، refactor و evolve می‌کنیم، باید ذهن خودمان را هم از بیرون ببینیم، پیش‌فرض‌ها را بررسی کنیم، باورهای قدیمی را اصلاح کنیم و مدل‌های ذهنی بهتر بسازیم.

جمع‌بندی مقاله اینه که تفکر انتقادی و فراشناخت می‌تونن نوعی «مهندسی ذهن» باشند؛ یعنی به جای اینکه هر خروجی ذهن رو بی‌چون‌وچرا قبول کنیم، ورودی‌ها، پردازش‌ها و خروجی‌های ذهنی‌مون رو بررسی کنیم. در نهایت، رشد واقعی فقط به بیشتر دانستن نیست، بلکه به بهتر فکر کردن وابسته است.

@codehalics | کدهالیک

حالا که صحبت از سوگیری تاییدی یا کانفرمیشن بایاس شد داغ دل من تازه شد که چند روزه قوانین مهندسی نرم افزار رو نگفتم خب پس بریم ادامه قوانین مهندسی نرم افزار :

سوگیری تأییدی یعنی ذهن ما معمولاً دنبال چیزهایی می‌گردد که حرف، حدس یا باور قبلی‌مان را تأیید کند؛ نه چیزهایی که آن را به چالش بکشد. مثلا وقتی یک برنامه‌نویس فکر می‌کند باگ از ماژول A است، ممکن است فقط همان بخش را زیر و رو کند و خطاهای ماژول B را نبیند، چون از قبل تصمیم گرفته «مشکل آنجاست». این اتفاق در کد ریویو هم می‌افتد؛ اگر به یک نفر اعتماد زیادی داشته باشیم، شاید کدش را سطحی‌تر ببینیم، یا اگر از یک نیروی junior انتظار خطا داشته باشیم، ممکن است چیزهای کم‌اهمیت را جدی تلقی کنیم.


#lawsofsoftwareengineering

@codehalics | کدهالیک

راهکار چیه حالا :
برای کم کردن این خطا باید عمداً خلاف حدس خودمان را هم بررسی کنیم. یعنی وقتی نظری داریم، از خودمان بپرسیم: «اگر اشتباه کنم، چه نشانه‌ای باید ببینم؟» در تصمیم‌های تیمی هم بهتر است فقط دنبال تأیید نظر جمع نباشیم؛ مثلاً اگر همه فکر می‌کنند یک تکنولوژی بهترین انتخاب است، یک نفر مأمور شود دیدگاه مخالف را بررسی کند. تست‌های خودکار، معیارهای عملکردی، آزمایش، A/B تست و کد ریویو با نگاه تازه کمک می‌کنند تصمیم‌ها کمتر بر اساس حس و تعصب باشند و بیشتر روی شواهد واقعی بنا شوند.

@codehalics | کدهالیک

قبل تر ها هم اینو بررسی کردیم اما امروز برای اینکه صحه بزارم رو صحبت دوست عزیزمون دوباره با بیان خودش بیانش کردم
اونروز یادم رفت از خاطرات خودم راجب بایاس بگم
تقریبا اگر بخوام بگم یکی از مهم ترین چیز هایی ک یه تیم نرم افزاری رو از هم میپاشونه چیه دقیقا میگم همین کانفرمیشن بایاس عه اس !
از اون سمت پروداکت میگه من درست میگم تو برنامه نویس میگی نه من درست میگم یکی دیگ میگه نه من درست میگم میزنید تو سر کله هم دیگ !

حالا سوال پیش میاد دوست دارم که جواب بدید فرض کن یه تیمی همشون دچار این بایاسه شدن و هیچ جوره حل نمیشه داستانت باهاشون رفتار تو نسبت به این داستان چیه ؟!

feel free to explain your idea in comment :

@codehalics | کدهالیک