Coding Lovers

باورم نمیشه یه باگ لینوکس که فکر کنم چند ماه پیش کشف شد ( تمام لینوکس هارو در بر میگیره ) که باهاش میشه بدون هیچ چیزی به دسترسی root رسید. فقط یه اسکریپت پایتونه که ران کردنش باعث میشه به root دسترسی مستقیم پیدا کنین ...!

این یک مقالهٔ پژوهشی مهم از James Kettle (مدیر تحقیقاتی PortSwigger) است که در اوت ۲۰۲۵ منتشر شد. در ادامه، خلاصه‌ای از ایده‌های کلیدی آن آمده است: استدلال اصلی پروتکل HTTP/1.1 ذاتاً ناامن است و مرتباً میلیون‌ها وب‌سایت را در معرض تصاحب مخرب قرار می‌دهد. شش سال تلاش برای کاهش این مشکل فقط آن را پنهان کرده، اما موفق به حلش نشده است. مقاله استدلال می‌کند که HTTP/1.1 باید کنار گذاشته شود و برای ارتباطات upstream از HTTP/2 یا نسخه‌های جدیدتر استفاده شود. نقص مرگبار مرزهای درخواست‌ها در HTTP/1.1 بسیار ضعیف هستند — درخواست‌ها صرفاً روی اتصال TCP/TLS زیربنایی به هم چسبانده می‌شوند و هیچ جداکنندهٔ واقعی ندارند، ضمن اینکه چندین روش مختلف برای تعیین طول آن‌ها وجود دارد. وقتی reverse proxyها درخواست‌های چند کاربر را روی اتصال‌های مشترک عبور می‌دهند، یک اختلاف کوچک در parser بین سرور front-end و back-end به مهاجم اجازه می‌دهد دادهٔ مخرب را به ابتدای درخواست کاربران دیگر تزریق کند — که اغلب منجر به تصاحب کامل سایت می‌شود. چرا راهکارهای فعلی شکست می‌خورند سرورها و CDNها معمولاً ادعا می‌کنند از HTTP/2 پشتیبانی می‌کنند، اما در عمل درخواست‌های HTTP/2 ورودی را برای انتقال upstream به HTTP/1.1 تبدیل (downgrade) می‌کنند و در نتیجه بیشتر مزایای امنیتی از بین می‌رود. دفاع‌های مبتنی بر WAF نیز از الگوهای regex استفاده می‌کنند که به‌راحتی قابل دور زدن هستند و صرفاً «توهم امنیت» ایجاد می‌کنند. کلاس‌های جدید حمله معرفی‌شده 1. شناسایی اختلاف Parser یک ابزار متن‌باز جدید به نام HTTP Request Smuggler v3.0 به‌صورت سیستماتیک اختلاف‌های V-H (Visible-Hidden) و H-V (Hidden-Visible) بین parserهای front-end و back-end را بررسی می‌کند و امکان ایجاد desyncهای نوع CL.0 را فراهم می‌کند؛ حملاتی که WAFها معمولاً جلویشان را نمی‌گیرند. 2. حملات Desync نوع 0.CL قبلاً تصور می‌شد این حملات قابل بهره‌برداری نیستند، چون باعث deadlock می‌شوند. کلید فرار از deadlock در 0.CL پیدا کردن یک «early-response gadget» است — یعنی راهی برای وادار کردن back-end به پاسخ دادن قبل از دریافت کامل body. یکی از نمونه‌های کشف‌شده: درخواست مسیر /con روی IIS باعث فعال شدن یک رفتار قدیمی ویندوز می‌شود که پاسخ زودهنگام ایجاد می‌کند. تکنیکی به نام «double-desync» دو درخواست را زنجیره می‌کند تا حملهٔ 0.CL را به یک حملهٔ عملیاتی و قابل‌استفاده از نوع CL.0 تبدیل کند. 3. حملات Desync مبتنی بر Expect هدر Expect: 100-continue درخواست HTTP را به یک فرآیند دو مرحله‌ای تبدیل می‌کند و مدیریت صحیح آن برای reverse proxyها بسیار پیچیده است. مشخص شد که هم هدرهای Expect معمولی و هم نسخه‌های obfuscated آن می‌توانند روی زیرساخت‌های بزرگ باعث desyncهای نوع 0.CL و CL.0 شوند. یافته‌های مهم در دنیای واقعی Cloudflare: یک desync از نوع H2.0 در زیرساخت داخلی Cloudflare بیش از ۲۴ میلیون وب‌سایت را در معرض تصاحب کامل قرار داد. مشکل ظرف چند ساعت patch شد و ۷۰۰۰ دلار bounty پرداخت شد. Akamai CDN: یک desync از نوع CL.0 از طریق هدر Expect مبهم‌شده (CVE-2025-32094) تعداد بسیار زیادی از سایت‌های میزبانی‌شده روی Akamai را تحت تأثیر قرار داد. در مجموع ۷۴ bounty جداگانه ثبت شد که مجموعاً ۲۲۱ هزار دلار پرداخت داشت و رفع کامل مشکل ۶۵ روز زمان برد. Netlify: یک آسیب‌پذیری CL.0 RQP باعث شد جریان مداومی از پاسخ‌ها از تمام وب‌سایت‌های CDN نتلیفای ارسال شود و tokenهای احراز هویت و محتوای سایت‌های ثالث افشا گردد. همچنین سرویس‌های: T-Mobile GitLab LastPass (auth.lastpass.com) نیز از طریق desyncهای مبتنی بر Expect مورد نفوذ قرار گرفتند. مجموع bountyهای این تحقیق: بیش از ۳۵۰ هزار دلار راه‌حل HTTP/2 یک پروتکل باینری است که دربارهٔ طول پیام‌ها هیچ ابهامی ندارد؛ به همین دلیل احتمال بروز آسیب‌پذیری‌های desync در آن بسیار کمتر است. اما downgrade کردن HTTP/2 — یعنی زمانی که front-end با کلاینت HTTP/2 صحبت می‌کند ولی upstream را به HTTP/1.1 بازنویسی می‌کند — تقریباً مزیت امنیتی خاصی ندارد و حتی سایت‌ها را بیشتر در معرض خطر قرار می‌دهد. فروشنده‌ها و سرویس‌هایی که از HTTP/2 در upstream پشتیبانی می‌کنند: HAProxy F5 Google Cloud Imperva Apache (به‌صورت آزمایشی) Cloudflare (هرچند هنوز در داخل از HTTP/1 استفاده می‌کند) سرویس‌هایی که هنوز upstream HTTP/2 ندارند: nginx Akamai CloudFront Fastly پیام پایانی مقاله:

«حملات desync بیشتری همیشه در راه هستند»

و تنها راه‌حل واقعی این است که HTTP/1.1 در ارتباطات upstream کاملاً حذف شود.

یه مقاله مهم پیدا کردم که خالی از لطف نیست بدونیم. چرا نباید از HTTP 1.1 استفاده کرد و خطرناک است؟

دقیقا داستان همینه

واقعا چی باید گفت فکرشو بکن مثل اینه تو حق داری نفس بکشی بیان دی اکسید کربن بزنن توی هوا بعد بیان قیمت درخت رو زیاد کنن یا بیان اکسیژن بفروشن دقیقا یه چیزی مثل اینه

اینترنت پرو خیانت به مردمه، هرکسی هم که بگیره فقط شرایط رو برای بدتر شدن همین شرایط هموار کرده

تازه میگن اینترنت احتمالااااا ۴۰ تا ۹۰ روز دیگه برمیگرده حالت قبل ای بر پدرشون ...

🔥 ابزار Moon: مدیریت پروژه های monorepo بعد از تست تمام ابزار های مدیریت، بهترین‌شون رو اوردم بهتون معرفی کنم.

این ابزار فقط کم مونده بره نون بگیره بیاد.

چند زبانه برخلاف بقیه ابزارها، تمام زبان هارو ساپورت میکنه. یه CI/CD کامله درحد یک github actions قابلیت بهتون میده. میتونین دقیقا مثل اون task ( همون job ) تعریف کنین. به هم وابسته‌شون کنین. براشون متغییر های env و secret مشخص کنین. و ... به کد شما کاری نداره کانفیگ کردنش به کد شما کاری نداره. فقط به فایل های خودش ( که moon.yml هستن ) کار داره. برعکس بقیه ابزار ها که بعد یه مدت کدتونو خراب میکنن. قدرت caching قبل از بیلد کردن پروژه‌تون، بررسی میکنه که اصلا کدتون تغییری داشته یا نه؟ برای ادیتور ضعفی ایجاد نمیکنه توی بیشتر ابزار ها، شما مجبور بودین کل پروژه رو با ادیتور باز کنید. اما اینجا، فقط بخشی که میخواید رو باز کنین، و با کامند های ساده از همونجا کل پروژه رو مدیریت کنین. داکیومنت: https://moonrepo.dev/moon گیتهاب: https://github.com/moonrepo/moon @CodingLovers_OFF

پروژه های پلی‌ریپو که جزئیات خاصی ندارن. پس میریم سراغ مونوریپو. 🔥 ابزار های مدیریت monorepo برای مدیریت کردن این پروژه ها خیلی حیاتی‌عه. چندین ابزار وجود داره: - Turborepo - Nx - Lerna - pnpm workspaces - Bazel از اونجایی که همشون مزخرف هستن و دردسر هایی دارن که به مرور برنامه نویس رو خسته میکنن، میریم سراغ اصل کاری، یعنی Moon ( Moonrepo ).

✨️ نقاط قوت مونوریپو - اشتراک‌گذاری کد: کد مشترک رو یه بار مینویسی و همه پروژه ها ازش استفاده میکنن. - ریفکتور راحت تر: وقتی یه تابع یا تایپ رو عوض میکنی، همون لحظه میبینی کجاها خراب میشه. - یک CI/CD برای همه: یه pipeline داری که همه‌چیز رو مدیریت میکنه. - همکاری تیمی راحت‌تر: یه نفر میتونه همزمان روی چند بخش کار کنه.

✅️ اگه تنهایی یه پروژه کامل رو داری میاری بالا، برات فوق‌العادست؛ یا حتی برای تیم های ۲ ۳ نفره.

✨️ نقاط قوت پلی‌ریپو - استقلال کامل: هر پروژه زندگی مستقل خودشو داره. به کسی کاری نداره. - تیم های مستقل: هر تیم میتونه با ریتم خودش کار کنه. - مدیریت دسترسی راحت‌تر: میتونی مشخص کنی چه کسی به چه پروژه ای دسترسی داشته باشه.

✅️ برای تیم هایی که تعدادشون زیاده و گروهی سر هر بخش کار میکنن فوق‌العادست‌.

💥 ترکیب هردو پروژه های خیلی بزرگ، ترکیبی از هردو هستن. شرکت های بزرگی مثل گوگل همینکار رو میکنن. یک تیم بزرگ، تقسیم به تیم های کوچیک تر میشن. کل تیم روی یک Polyrepo کار میکنه، و هر بخش خودش یه Monorepo هست...

🗂️ سازماندهی پروژه های بزرگ

وقتی یک پروژه، چند تا پروژس :/

یکی از چالش هایی که هرکی بزودی باهاش روبرو میشه، اینه که از یه جایی دیگه پروژه هات فقط یه بخش نیست. یه پروژه ممکنه از تنها یک بخش تشکیل بشه، یا ممکنه یک چیز خیلی بزرگی باشه. اینارو باید کجا جا داد که ساختار تمیز در بیاد؟ 🚀 شروع: Monorepo vs Polyrepo - 📦 پلی‌ریپو: یعنی هر پروژه، کامل از بقیه جداست و ریپو و کانفیگ خودشو داره. در نگاه اول خیلی تمیزه، برای اپلیکیشن ها مناسبه. اما وقتی بخوای یک config یا کد مشترکی رو استفاده کنی، چیزی رو بین‌شون sync کنی، میفهمی عجب اشتباهی کردی! 😅 - 🏠 مونوریپو: یعنی همه‌چیز زیر یه سقف. چندین ابزار برای مدیریت همین ساخته شدن. اینجوری میتونی کد مشترک رو یه بار بنویسی و همه جا استفادش کنی. کانفیگ هارو sync کنی، با یک کامند همه چی رو ران کنی و .. 📝 جمع بندی پست اول سازماندهی پروژه‌های چندبخشی یه علم دقیق نیست، یه هنره. ولی اگه از اول یه ساختار منطقی داشته باشی، کد مشترک رو جدا کنی، و قراردادهای روشنی بین بخش‌ها تعریف کنی خیلی از دردسرهای بعدی رو از خودت دور کردی. پروژه بزرگ می‌شه ولی نه لزوماً پیچیده تر @CodingLovers_OFF

تاحالا به این فکر کردین که این پروژه های بزرگ، که خودشون از چند پروژه کوچیک تشکیل میشن، چجوری سازمان‌دهی میشن؟ مثلا یه سایت که از ۳ بخش تشکیل میشه: - پروژه فرانت‌اند - پروژه بک‌اند - پروژه فرانت داشبورد واسه هرکدوم یه ریپوزیتوری جدا میسازن مدیریت میکنن؟ یا یجا؟ همچین تجربه ای داشتین؟

#موقت اگه حوصله داشتین شماهم یه امتحان کنین😂 برنامه GapGPT ظااااهرا داره کلاهبرداری میکنه و مدل های قدیمی رو به اسم مدلای جدید میده مردم خودمم تست کردم همینجوری بود ولی خب هنوز کامل مطمئن نیستم😂

🔴 CVE-2026-41940 — آسیب‌پذیری بحرانی در cPanel و WHM خلاصه این آسیب‌پذیری در ۲۸ آوریل ۲۰۲۶ افشا شد، امتیاز CVSS آن ۹.۸ از ۱۰ است و به مهاجمان غیرمجاز اجازه می‌دهد بدون نیاز به احراز هویت، به کنترل پنل مدیریتی دسترسی کامل پیدا کنند. نوع آسیب‌پذیری این یک حمله CRLF Injection برای دستکاری فایل session است. مهاجم بدون احراز هویت، خطوط دستکاری‌شده‌ای را در فایل session پیش از احراز هویت تزریق می‌کند. وقتی سرویس cpsrvd این فایل را مجدداً پارس می‌کند، خطوط تزریق‌شده به عنوان ورودی‌های معتبر session پذیرفته می‌شوند — از جمله مقادیری مثل user=root، hasroot=1، tfa_verified=1 — که نتیجه آن ارتقاء session به سطح root بدون نیاز به رمز عبور یا احراز هویت دو مرحله‌ای است. جزئیات تکنیکی مهاجم می‌تواند کوکی whostmgrsession را با حذف یک بخش مورد انتظار دستکاری کرده و از فرآیند رمزنگاری فرار کند. با تزریق کاراکترهای خام \r\n از طریق یک header مخرب Basic Authorization، سیستم فایل session را بدون sanitize کردن داده‌ها می‌نویسد و در نتیجه مهاجم می‌تواند ویژگی‌هایی مثل user=root را در فایل session خود وارد کند. دامنه تأثیر این آسیب‌پذیری تمام نسخه‌های فعلاً پشتیبانی‌شده cPanel و WHM را تحت تأثیر قرار می‌دهد — نه برخی، نه چند نسخه خاص، بلکه همه آن‌ها. cPanel بیش از ۷۰ میلیون دامنه را مدیریت می‌کند. این آسیب‌پذیری تمام نسخه‌های cPanel و WHM بعد از v11.40 و همچنین WP Squared نسخه v136.1.7 را شامل می‌شود. وضعیت اکسپلویت بر اساس اعلام KnownHost، این آسیب‌پذیری از ۲۳ فوریه ۲۰۲۶ (دو ماه قبل از افشای عمومی) به صورت zero-day در حال استفاده بوده است. بنیاد Shadowserver گزارش داده که حدود ۴۴ هزار IP منحصربه‌فرد در حال اسکن، اجرای اکسپلویت یا حمله brute-force علیه سنسورهای آن هستند و حدود ۶۵۰ هزار IP نمونه‌های آسیب‌پذیر cPanel/WHM را در معرض اینترنت قرار داده‌اند. نسخه‌های پچ‌شده نسخه‌های زیر حاوی رفع این آسیب‌پذیری هستند: - cPanel & WHM نسخه 11.136.0.5 یا بالاتر - WP Squared نسخه 136.1.7 یا بالاتر اقدامات فوری برای رفع و بررسی آسیب‌پذیری: 1. اجرای دستور /scripts/upcp --force برای بروزرسانی اجباری 2. بررسی لاگ‌های دسترسی cpsrvd برای خطاهای 401 مشکوک 3. بررسی مسیر /var/cpanel/sessions/raw/ برای session‌های حاوی user=root یا hasroot=1 4. محدود کردن دسترسی به پورت‌های 2082، 2083، 2086، 2087 به IP‌های مدیریتی شناخته‌شده 5. بررسی وجود حساب‌های کاربری، SSH keys یا cron jobهای غیرمجاز در WHM توصیه: اگر سرور cPanel دارید، فوراً به‌روزرسانی انجام دهید چون این آسیب‌پذیری به‌طور فعال در حال سوءاستفاده است.

## 🔴 CVE-2026-41940 — آسیب‌پذیری بحرانی در cPanel و WHM ### خلاصه این آسیب‌پذیری در ۲۸ آوریل ۲۰۲۶ افشا شد، امتیاز CVSS آن ۹.۸ از ۱۰ است و به مهاجمان غیرمجاز اجازه می‌دهد بدون نیاز به احراز هویت، به کنترل پنل مدیریتی دسترسی کامل پیدا کنند. [Rapid7](https://www.rapid7.com/blog/post/etr-cve-2026-41940-cpanel-whm-authentication-bypass/) --- ### نوع آسیب‌پذیری این یک حمله CRLF Injection برای دستکاری فایل session است. مهاجم بدون احراز هویت، خطوط دستکاری‌شده‌ای را در فایل session پیش از احراز هویت تزریق می‌کند. وقتی سرویس cpsrvd این فایل را مجدداً پارس می‌کند، خطوط تزریق‌شده به عنوان ورودی‌های معتبر session پذیرفته می‌شوند — از جمله مقادیری مثل user=root، hasroot=1، tfa_verified=1 — که نتیجه آن ارتقاء session به سطح root بدون نیاز به رمز عبور یا احراز هویت دو مرحله‌ای است. [Hadrian](https://hadrian.io/blog/cve-2026-41940-a-critical-authentication-bypass-in-cpanel) --- ### جزئیات تکنیکی مهاجم می‌تواند کوکی whostmgrsession را با حذف یک بخش مورد انتظار دستکاری کرده و از فرآیند رمزنگاری فرار کند. با تزریق کاراکترهای خام \r\n از طریق یک header مخرب Basic Authorization، سیستم فایل session را بدون sanitize کردن داده‌ها می‌نویسد و در نتیجه مهاجم می‌تواند ویژگی‌هایی مثل user=root را در فایل session خود وارد کند. [Help Net Security](https://www.helpnetsecurity.com/2026/04/30/cpanel-zero-day-vulnerability-cve-2026-41940-exploited/) --- ### دامنه تأثیر این آسیب‌پذیری تمام نسخه‌های فعلاً پشتیبانی‌شده cPanel و WHM را تحت تأثیر قرار می‌دهد — نه برخی، نه چند نسخه خاص، بلکه همه آن‌ها. cPanel بیش از ۷۰ میلیون دامنه را مدیریت می‌کند. [watchTowr Labs](https://labs.watchtowr.com/the-internet-is-falling-down-falling-down-falling-down-cpanel-whm-authentication-bypass-cve-2026-41940/) این آسیب‌پذیری تمام نسخه‌های cPanel و WHM بعد از v11.40 و همچنین WP Squared نسخه v136.1.7 را شامل می‌شود. [Help Net Security](https://www.helpnetsecurity.com/2026/04/30/cpanel-zero-day-vulnerability-cve-2026-41940-exploited/) --- ### وضعیت اکسپلویت بر اساس اعلام KnownHost، این آسیب‌پذیری از ۲۳ فوریه ۲۰۲۶ (دو ماه قبل از افشای عمومی) به صورت zero-day در حال استفاده بوده است. بنیاد Shadowserver گزارش داده که حدود ۴۴ هزار IP منحصربه‌فرد در حال اسکن، اجرای اکسپلویت یا حمله brute-force علیه سنسورهای آن هستند و حدود ۶۵۰ هزار IP نمونه‌های آسیب‌پذیر cPanel/WHM را در معرض اینترنت قرار داده‌اند. [Help Net Security](https://www.helpnetsecurity.com/2026/04/30/cpanel-zero-day-vulnerability-cve-2026-41940-exploited/) --- ### نسخه‌های پچ‌شده نسخه‌های زیر حاوی رفع این آسیب‌پذیری هستند: - cPanel & WHM نسخه 11.136.0.5 یا بالاتر - WP Squared نسخه 136.1.7 یا بالاتر [Rapid7](https://www.rapid7.com/blog/post/etr-cve-2026-41940-cpanel-whm-authentication-bypass/) --- ### اقدامات فوری برای رفع و بررسی آسیب‌پذیری: 1. اجرای دستور /scripts/upcp --force برای بروزرسانی اجباری 2. بررسی لاگ‌های دسترسی cpsrvd برای خطاهای 401 مشکوک 3. بررسی مسیر /var/cpanel/sessions/raw/ برای session‌های حاوی user=root یا hasroot=1 4. محدود کردن دسترسی به پورت‌های 2082، 2083، 2086، 2087 به IP‌های مدیریتی شناخته‌شده 5. بررسی وجود حساب‌های کاربری، SSH keys یا cron jobهای غیرمجاز در WHM [Hadrian](https://hadrian.io/blog/cve-2026-41940-a-critical-authentication-bypass-in-cpanel) --- ### واکنش نهادهای امنیتی آژانس CISA این آسیب‌پذیری را به فهرست Known Exploited Vulnerabilities (KEV) اضافه کرده و از سازمان‌های دولتی آمریکا خواسته تا پیش از ۳ می ۲۰۲۶ پچ را اعمال کنند. [The Hacker News](https://thehackernews.com/2026/04/critical-cpanel-authentication.html) --- توصیه: اگر سرور cPanel دارید، فوراً به‌روزرسانی انجام دهید چون این آسیب‌پذیری به‌طور فعال در حال سوءاستفاده است.

❗ مشکل امنیتی cPanel/WHM ریسک هک شدن سایت‌های سی‌پنل: بالا🔴 خیلی از برنامه‌نویس‌ها و مدیران سایت برای مدیریت هاست و سرویس‌هاشون از cPanel استفاده می‌کنن، این آپدیت مهمه. یک باگ امنیتی با شناسه CVE-2026-41940 منتشر شده که می‌تونه باعث دور زدن لاگین و دسترسی به بخش‌هایی از cPanel/WHM بشه. طبق اعلام رسمی cPanel، حتماً نسخه cPanel/WHM نصب‌شده روی سرورتون رو آپدیت کنید. حالا فکر کن برنامه‌نویس یا مدیر سایت در کشوری باشی که اینترنتش قطعه، دسترسی درست به سرورت نداری، از اون طرف هم هکر از همین فرصت استفاده کرده و زده همه اطلاعات سایت، سرور و بکاپ‌هات رو نابود کرده…

تازه این لینک رو دیدم. باهاش میشه لحظه ای دید چه سایت های مهمی باز هستن یا بستن. https://radar.chabokan.net/

کیا اپ "بله" دارن؟ یا حداقل دیدنش؟ من تازه فهمیدم سرمایه گذار ( و تقریبا مالکش ) بانک ملی‌عه واقعا این همه سرمایه داشته باشی و نتونی یه اپ بسازی، خیلی هنر میخواد

ازش تعریف کردیم، ضعف هاشم بگیم. نسبت به vscode: - کد completion ضعیفی داره. - تم های خشک تری داره. - توی کاراکتر های فارسی ضعف داره.

⚡️ ادیتور Zed 1.0 سازندگان Zed همون تیمی هستن که قبلاً Atom رو ساختن، ادیتوری که پایه‌گذار Electron شد و VS Code روش ساخته شد. اما هر چقدر تلاش کردند، نمی‌تونستن از سقف اون پلتفرم فراتر برن. پس همه چیز رو از نو ساختن. این بار مثل یه بازی ویدیویی: کل UI مستقیم روی GPU رندر میشه و فریم‌ورک اختصاصی GPUI با Rust از صفر نوشته شده. هوش مصنوعی بومی همزمان چند تا AI میتونن روی پروژت کار کنن و پیشنهاد بدن ( به کار ما ایرانیا نمیاد پس توضیح اضافی نمیدم ) یه ادیتور کامل توی این هرچیزی که یه ادیتور نیاز داره رو تکمیل کردن. برای زبان های معروف مثل Python و Rust نیازی به نصب هیچ اکستنشنی هم نداری. آینده: DeltaDB هدف بعدیشون DeltaDB هست. یه موتور sync اختصاصی بر پایه CRDT که انسان‌ها و ایجنت ها یه دیدگاه یکپارچه از codebase دارند. https://zed.dev/blog/zed-1-0 @CodingLovers_OFF