پیش‌فرض SHA-256 آینده Git 3.0 یک اشتباه پرهزینه خواهد بود

Git 3.0 SHA-256 را به الگوریتم پیش‌فرض هش محتوا تبدیل می‌کند و یک کابوس جهانی غیرقابل درک و در نهایت بی‌ارزش و قابل اجتناب خواهد بود.

من چند سالی است که روی این موضوع نشسته ام، بیشتر به این دلیل که افراد باهوش تری هستند که روی این موضوع تمرکز کرده اند و من دوست ندارم راننده صندلی عقب باشم. با این حال، من فکر می‌کنم که انتشار Git 3.0 برای همه افراد وقت و اضطراب زیادی برای سود کمی دارد و تقریبا هیچ‌کس نمی‌داند چه چیزی در راه است.

پس کمی پاپ کورن بردارید و بگذارید داستانی را برایتان تعریف کنم که چگونه یکی از تغییرات جدید Git 3.0 در حال تبدیل شدن به یک قطار بزرگ، پرهزینه و جهانی است که تقریبا هیچ ارزش عملی ندارد.

من این را کوتاه می کنم زیرا بسیاری از شما احتمالا این را در سطح پایه می دانید.

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

این خوب است، زیرا به این معنی است که محتوای یک فایل هرگز دو بار ذخیره نمی شود. همچنین یک ویژگی جالب وجود دارد که در آن commit ها هش commit را که قبل از آن آمده است رمزگذاری می کند، به این معنی که این یکپارچگی اساسا منتشر می شود - شما نمی توانید هش هر چیزی را بدون تغییر هش هر چیزی که بعد از آن می آید تغییر دهید. این به آن «یکپارچگی رمزنگاری» می‌دهد، به این معنی که هش کردن آخرین commit اساسا میلیون‌ها محتوای فایل، درخت‌ها و commit‌هایی که قبل از آن آمده‌اند را نیز هش می‌کند.

در Git، این تابع هش همیشه SHA-1 بوده است. این همان چیزی بود که لینوس در سال 2005 هنگام راه اندازی Git انتخاب کرد و به مدت 20 سال به خوبی کار کرد - هش تصادفی دو فایل مختلف به یک مقدار نسبتا سریع و از نظر عملی غیرممکن است.

در واقع، تا آنجا که من می دانم، این هرگز در تاریخ هر فایل، درخت و commit ساخته شده در Git در هر مخزنی که تا به حال ساخته شده است - میلیاردها و میلیاردها مورد اتفاق افتاده است.

از نظر ریاضی، برای خروجی 160 بیتی SHA-1، کران تولد به این معنی است که برای داشتن یک فایل تصادفی به حدود 1.4 سپتیلیون فایل تصادفی (1.4 کوادریلیون فایل - 1،400،000،000،000،000 میلیارد - غیرممکن است که به طور موثر توصیف کنید) در یک پروژه به طور تصادفی نیاز دارید.

با این حال، یک مشکل وجود دارد، و آن این است که از نظر ریاضی، SHA-1 اکنون نیمه "شکسته" در نظر گرفته می شود زیرا حملات برخوردی منتشر شده است (در سال 2017 شکسته شد، SHA-1 یک Shambles در سال 2020 است) - واقعا برای بهره برداری به هیچ روش نشان داده شده عملی نیست، اما اکنون از نظر تئوری امکان پذیر است.

بنابراین در پاسخ به این، پس از حجم زیادی از کار توسط افراد بسیار باهوش، نسخه آینده Git 3.0 در حال برنامه ریزی برای تغییر الگوریتم هش پیش فرض خود از SHA-1 نیمه "شکسته" به الگوریتم قوی تر SHA-256 است.

اما اول، بیایید مکث کنیم. قبل از اینکه به این موضوع بپردازیم، "شکسته" به چه معناست؟

درک این مهم است، زیرا احتمالا این چیزی نیست که مردم عادی فکر می کنند "شکسته" به معنای آن است. از نقطه نظر هش رمزنگاری، شکسته شدن در این معنا اساسا به این معنی است که یافتن برخوردها غیرممکن نیست.

به عبارت دیگر، اگر پول و پردازنده‌های گرافیکی کافی را روی این مشکل پرتاب کنید، برای برخی از اشکال محتوا، می‌توانید دو چیز متفاوت را به‌عمد به یک مقدار هش کنید.

این بدان معناست که در حالی که هنوز تقریبا غیرممکن است که تصادفا دو فایل معقول با محتوای متفاوت داشته باشید، از نظر فنی ساختن دو فایل مختلف که در یک چیز هش شوند غیرممکن است.

این بدان معنی است که از نظر تئوری بردارهای حمله وجود دارد که در آن شخصی می تواند محتویات یک فایل را با یک نسخه مخرب جایگزین کند و Git نمی تواند تفاوت را تشخیص دهد زیرا هش از نظر ریاضی یکسان است.

این مقالات نشان دادند که SHA-1 دارای خاصیتی است که در تئوری می‌تواند توسط مزارع GPU مدرن برای ایجاد برخوردهای هدفمند به سفارش چند ده هزار دلاری امروز مورد سوء استفاده قرار گیرد که SHA-256 ندارد (در گوگل «برنامه‌بندی پیام خطی sha-1 در مقابل sha-256» اگر مراقبت فوق‌العاده‌ای دارید...).

واقعا ترسناک و نگران کننده به نظر می رسد، درست است؟ آیا کسی لطفا به فکر بچه ها نیست!؟!

اما بیایید یک دقیقه به عقب برگردیم و در مورد این برخوردها صحبت کنیم.

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

«حمله برخورد» زمانی است که می‌دانید یک مهاجم می‌شوید اما تا زمانی که اعتماد به دست نیاورید وانمود کنید که آدم خوبی هستید. شما دو فایل را عمدا با هش یکسان تولید می کنید - یکی خوش خیم و دیگری مخرب است. شما تا زمانی که مورد اعتماد قرار نگیرید، آن را به افراد بدخیم می‌دهید و سپس آن را با مخرب تغییر می‌دهید، زیرا هش مطابقت دارد و می‌دانید که Git نمی‌تواند تفاوت را تشخیص دهد. حتی می‌توانید برچسب‌ها یا commit‌های امضا شده را روی درخت‌هایی که فایل خوش‌خیم دارند دریافت کنید و به نظر برسد که فایل بد امضا شده است.

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

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

Git می‌تواند از MD5 استفاده کند (که یک تابع هش فوق‌العاده شکسته در نظر گرفته می‌شود) و همچنان به طور موثری از حمله دوم پیش تصویر مصون باشد. باز هم، MD5 چیزی است که یک تابع هش کاملا "شکسته" در نظر گرفته می شود، که SHA-1 نیست - بسیار قوی تر است.

منظور من از "ایمنی موثر" چیست؟ اگر هر یک از تقریبا 3 میلیارد پردازنده گرافیکی روی زمین به طور جادویی با یک RTX 5090 جایگزین می‌شد و هر کدام 100 درصد از زمان خود را صرف انجام کاری جز MD5 می‌کرد، زمان مورد انتظار برای ایجاد یک پیش‌تصویر خاص هنوز حدود 16 میلیارد سال (حدود 11 میلیارد میانه) یا تقریبا به سن کیهان خواهد بود.

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

با این حال، بیایید به طور انبوه، به طور غیرواقعی محافظه کار باشیم و حتی برای استدلال فرض کنیم که یک پیش تصویر آسان است. فرض کنید راهی برای ایجاد تصویر اولیه دوم مطابق با هش هر فایل شناخته شده در لپ تاپ خود در یک ساعت پیدا کرده اید.

اکنون می‌توانید هر فایلی را که می‌خواهید جایگزین کنید، هدف قرار دهید و فایل مخرب دیگری را که بدون زحمت با هش مطابقت دارد، پیدا کنید. تبریک می گویم! اکنون می‌توانید هر پایگاه کد موجود در زمین را pwn کنید!

هر بحث و مشکلی که بعد از این تنظیم می شود به پاسخ این سؤالات بستگی دارد، اما پاسخ به این سؤالات معمولا بخشی از گفتگو پیرامون این مشکل نیست.

حتی اگر فرض کنیم که شکستن SHA-1 بی‌اهمیت بود، حتی اگر فرض کنیم که تولید پیش‌تصویر دوم امکان‌پذیر بود (یا حتی ارزان)، بهره‌برداری از بردارهای حمله‌ای که در دسترس هستند را واقعا آسان نمی‌کند.

دلیل این امر این است که هش واقعا مکانیسم اعتماد در دنیای SCM نیست. مطمئنا عنصری از یکپارچگی رمزنگاری را فراهم می کند، اما این چیزی نیست که اساسا اعتماد بر آن استوار است.

لینوس به معنای واقعی کلمه در هنگام تولد Git استدلال می کند.

من واقعا فکر می کنم مردم نباید sha1 را "امنیت" بدانند. امنیت واقعی در توزیع است.

اعتماد بر این اساس است که "از کجا می کشی؟" و همیشه بوده است

برای یک دقیقه، بیایید در نظر بگیریم که یک حمله واقعی در دنیای تبدیل محتوای غیرقابل اعتماد به پایگاه های کد چگونه به نظر می رسد. البته این بدترین سناریویی است که ما در اینجا به آن نگاه می کنیم. برخی از فایل های کد منبع (یا به احتمال زیاد در مورد حمله هش، فایل باینری) به صورت مخرب و بدون اینکه شما بدانید درج شده است.

به نظر می رسد، این در واقع به مقدار عادلانه اتفاق می افتد.

نه به این دلیل که مردم صدها هزار دلار برای GPU ها خرج می کنند تا آنتروپی تصادفی تولید کنند تا پس از یک بایت تهی پرتاب شود، به طوری که برخی از فایل های باینری ممکن است با جمع کنترلی SHA-1 مطابقت داشته باشند.

نه، در حال حاضر در دنیای واقعی اتفاق می‌افتد، زیرا فردی از نظر اجتماعی یک اکسپلویت را برای دسترسی نوشتن به بسته‌های npm مورد استفاده میلیون‌ها پروژه طراحی می‌کند. اکنون این یک باینری نیست که تشخیص آن دشوار باشد، بلکه تک تک فایل‌ها در یک وابستگی هستند که کورکورانه بدون هیچ تطابق جمع‌بندی بررسی قبلی توسط هر پروژه‌ای که این پروژه را در فایل package.json خود دارد، وارد می‌شود.

این شاید یک میلیارد بار ساده‌تر، ارزان‌تر و احتمال موفقیت‌آمیز آن بیشتر از تلاش برای ایجاد اجبار در برخورد هش و دستکاری یک واکشی نامعتبر باشد.

اگر می‌خواستم کد نامعتبر را در Android وارد کنم، رشوه دادن یا متقاعد کردن نگهدارنده یک پروژه محبوب پایین‌دستی، گرفتن آن و تزریق کد دشوار به یک URL منبع از قبل قابل اعتماد بسیار ساده‌تر از تلاش برای مهندسی کردن برخی برخورد آسان برای تشخیص هش و قرار دادن آن در یک URL است که هیچ‌کس نمی‌تواند از آن استفاده کند.

به عبارت دیگر، حملات برخورد هش ممکن است احمقانه ترین راه ممکن برای دریافت کد غیرقابل اعتماد در یک سیستم باشد، زمانی که نگهبانان منبع باز بدون پرداخت پول و جعل مدیریت بسته های کم اعتماد وجود دارند.

برای بازگشت به استدلال لینوس، من کدی را از https://github.com/rust-lang/rust نمی گیرم زیرا به امضای GPG که آخرین commit SHA را امضا کرده اعتماد دارم و فقط فرض می کنم که هر منبع تصادفی خوب است.

من آن را از آنجا بیرون می کشم زیرا اطمینان دارم که GitHub به اندازه کافی بازی احراز هویت خود را با هم دارد که بعید است که کسی مخرب چیزی را بدون اطلاع نگهدارنده به آنجا منتقل کرده باشد. به همین دلیل است که من از https://randomhash.onion/hAAAxx0r/rust خارج نمی شوم زیرا برخی از ایمیل ها به من گفته اند.

من واقعا اهمیتی نمی‌دهم که الگوریتم هش چیست و چند میلیارد سال محاسبه کمتر ممکن است طول بکشد تا یک برخورد هش در یک فایل باینری بزرگ ایجاد شود که Rust به وضوح در وهله اول به مخزن متعهد نمی‌شد.

هر سناریوی حمله ای که برای دفاع از تلاش مهاجرت باورنکردنی و گران قیمت SHA-256 که کل صنعت در شرف انجام آن است، برای من غیر واقعی است. همه آنها به راحتی و با هزینه کم توسط بسیاری از محافظت های قوی تر و ساده تر از منابع و محتوا به جای الگوریتم های هش کمی قوی تر کاهش می یابند.

اگر ما SHA-1 را به سادگی روشی به اندازه کافی خوب و به اندازه کافی سریع برای تولید کلیدهای منحصر به فرد برای محتوا در یک مخزن قابل اعتماد در نظر بگیریم، و بپذیریم که هش ها ذاتا برای اعتماد استفاده نمی شوند، پس هیچ دلیل واقعی برای جایگزینی آن وجود ندارد. ما می‌توانیم از MD5 استفاده کنیم و انصافا احتمالا خوب خواهد بود.

برخورد تصادفی محتوا از نظر ریاضی تقریبا در هر پایگاه کد معقولی غیرممکن است و بقیه را می توان با تأیید محتوای امضا شده، تأیید هویت خارجی و مکانیسم های اعتماد اجتماعی کنترل کرد.

اگر این را نپذیریم، در حلقه‌ای گیر می‌افتیم که کسی یک اکسپلویت تئوری برخورد پیدا می‌کند و هر بار که مقاله جدیدی منتشر می‌شود، دوباره نیاز به مهاجرت کل اکوسیستم Git داریم. ما می توانیم سال ها از این مهاجرت SHA-1 به SHA-256 بگذریم و سپس کامپیوترهای کوانتومی عدد 256 را بشکنند و دوباره به همان قایق احمقانه برگردیم.

صرفا به این دلیل که ما یکپارچگی رمزنگاری را با اعتماد ترکیب می کنیم.

حالا یک دقیقه صبر کن اسکات، گفتی که این یک قطار وحشتناک خواهد بود. مطمئنا این هذل گویی است.

اما مهم نیست که چگونه هزینه را محاسبه کنید، ارزان یا آسان نخواهد بود. امیلی شفر به تازگی در مورد چگونگی آماده شدن گوگل برای مقابله با این مشکل صحبت کرد و این تصویر زیبایی نیست.

بیایید آنچه را که قرار است با عرضه Git 3.0 با این پیش‌فرض جدید رخ دهد، بررسی کنیم.

اولین چیز این است که تمام مخازن جدید ایجاد شده با git init با الگوریتم هش محتوا SHA-256 ایجاد می شوند. امروز می توانید این کار را خودتان با اجرای git init --object-format=sha256 امتحان کنید.

اولین چیزی که متوجه خواهید شد (غیر از مقدار هش بسیار طولانی تر) این است که نمی توانید این کد را به GitHub فشار دهید، اگرچه تقریبا مطمئنا تا زمان انتشار Git 3.0 برطرف خواهد شد. در واقع، این احتمالا اصلی ترین چیزی است که در حال حاضر 3.0 را به طور کامل به تاخیر می اندازد.

اما وقتی می‌خواهید آن را به GitHub (یا هر میزبان دیگری) فشار دهید، باید هنگام ایجاد مخزن روی سرور به آنها بگویید که این یک پروژه sha256 است. اکنون هر پروژه در یک سطل قرار می گیرد و نمی توان آنها را مخلوط کرد.

این بلافاصله مردم را ناامید می کند زیرا اکنون آنها باید بدانند که git init را با چه نسخه ای از git اجرا کرده اند و مطمئن شوند که وقتی برای ایجاد مخزن سرور به GitHub می روند، نسخه مناسب را انتخاب می کنند.

به چند دلیل مختلف از آنجا که بسته به نحوه برچسب گذاری میزبان ها به این، بسیار دشوار است که بدانید به کدام فرمت نیاز دارید که مخزن بالادستی به عنوان مقداردهی اولیه شود. بنابراین می‌توانید 256 upstream را انجام دهید و سعی کنید یکی از آنها را به صورت محلی با یک باینری قبل از 3.0 فشار دهید. یا به وضوح برعکس.

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

این امکان وجود دارد که forges بتواند با نگه داشتن آینه های فرمت دیگر، هر دو فرمت را مدیریت کند، اما این کار باعث افزایش بار سایت هایی مانند GitHub برای تقریبا هر عملیاتی می شود و همچنین مشکل اعتماد را بیشتر سردرگم می کند.

برای پروژه های موجود که تصمیم به تبدیل از SHA-1 به SHA-256 دارند، باید هر شیء موجود در پروژه را به فرمت جدید تبدیل کنند، که تمام امضاهای موجود را از بین می برد. همچنین همه افرادی که روی آن پروژه کار می کنند یا از آن استفاده می کنند، باید به طور همزمان تغییر کنند تا از مشکلات تقسیم سر جلوگیری کنند. یا، دوباره، تنظیمات آینه را داشته باشید و دسترسی نوشتن را از یکی به دیگری قطع کنید. که باز هم مشکل تعویض آبجکت برای آینه های دیگر که نسخه 256 ندارند حل نمی شود.

اگر آنها تبدیل شوند، همه URL ها یا پیوندهای موجود در Slack یا ایمیل ها یا هر چیزی که تا به حال دارای هش SHA-1 بوده است دیگر کار نمی کند و باید هدایت شود (با فرض اینکه این امکان وجود داشته باشد - شما هاست یا چیزی را به مکانی که نقشه ندارد تغییر داده اید).

همه ابزارهای داخلی یا سایر ابزارهای جهانی که انتظار 40 کاراکتر برای هش را دارند، شکسته می شوند یا برای حدس زدن یا تشخیص قالب هش باید به روز شوند.

همچنین، در حالی که هسته گیت دارای این قابلیت برای کار با مخازن هر فرمت است، همه کتابخانه ها این کار را نمی کنند و تقریبا هیچ یک از آنها پشتیبانی کامل ندارند.

از آنجایی که Git به‌عنوان پروژه‌ای با کتابخانه غیرقابل ورود، دارای مجوز GPL و غیرقابل پیوند توسعه داده شد، اکثر پروژه‌ها در اکوسیستم گیت گسترده‌تر از پیاده‌سازی مجدد از ابتدا استفاده می‌کنند. از آنجایی که این کتابخانه‌ها همگی پشتیبانی صفر یا جزئی دارند، همه اسکریپت‌ها و ابزارهایی که به صورت فورکی در باینری Git اجرا نمی‌شوند، مقداری خرابی در این مخازن جدید خواهند داشت.

من می توانم ادامه دهم، اما این یک مشکل بزرگ، گسترده و هنوز تا حد زیادی حل نشده است و هیچ اجماع یا راه حل بزرگی وجود ندارد که کسی برای آسان کردن این کار اندیشیده باشد. امیلی حتی خاطرنشان کرد که ممکن است گوگل فقط برای اطمینان از اینکه همه پروژه‌های جدید در Google همچنان SHA-1 هستند، نادیده‌گیری‌های داخلی در سراسر سیستم را تنظیم کند، و تلاش می‌کند مطمئن شود که همه چیز پیش‌فرض جدید 3.0 را تا زمانی که ممکن است برمی‌گرداند.

شخصا، من فکر می کنم که این یک راه حل غیر ضروری است که به دنبال یک مشکل تئوری است و حتی آن مشکل تئوری و غیرعملی را می توان به روشی بسیار ساده تر و سرراست برای تعداد کمی از پروژه هایی که ممکن است واقعا اهمیت دهند، حل کرد.

اگر فرض کنید که منابع مخزن شما قابل اعتماد هستند، هیچ کدام از اینها مهم نیست. اصلا و 99٪ از ما فقط با منابع مخزنی که مورد اعتماد هستند کار می کنیم. تقریبا برای همه افرادی که از Git استفاده می کنند، حملات هش درب پشتی فانتزی بی ربط هستند زیرا اگر فقط روی یک مخزن کار می کنید و اگر دسترسی نوشتن به آن مخدوش شود، هر کسی می تواند هر چیزی را در شاخه اصلی قرار دهد و احتمالا هیچ کس متوجه نخواهد شد. شما نیازی به ترفندهای فانتزی جایگزینی اشیاء ندارید تا افراد را سرزنش کنید.

اگر به منابع خود کاملا اعتماد ندارید (1٪ دیگر)، شاید روش های دیگر، ساده تر و بهتری وجود داشته باشد که باید قبل از هاشمگدون جهانی خود امتحان کنیم.

اگر به این موضوع بسیار متفاوت برخورد کنیم، چه؟ شاید ما یک کار ساده انجام دهیم مانند اینکه به طور مستقل محتویات درخت را با یک الگوریتم متفاوت بازنویسی کنیم، سپس آن هدر را به اشیایی که امضا می کنیم تزریق کنیم تا هر دو هش را امضا کنیم؟ یکی (SHA-1) برای بازیابی محتوا و دیگری (مثلا SHA-256) برای تأیید محتوای مستقل استفاده می شود.

من می‌خواهم کمی به این موضوع بپردازم، زیرا احساس می‌کنم که رویکردی مانند این می‌تواند تقریبا تمام مشکلات حتی تئوری را بدون نیاز به دوشاخه کردن کل اکوسیستم Git حل کند و همه را ناامید کند.

فرض کنید می خواهید به یک کتابخانه یا فروشنده خارجی تکیه کنید و می خواهید حملات احتمالی برخورد اشیا را کاهش دهید. نمی‌توانید به امضای SSH/GPG روی یک commit یا برچسب اعتماد کنید زیرا چیزی که امضا می‌کند هش SHA-1 است که ما برای ذخیره محتوا استفاده می‌کنیم و نشان داده می‌شود که بدون شناسایی یا تغییر چیزی که امضا می‌کنید قابل تعویض است.

به طور مستقل هش SHA-256 (یا BLAKE3 یا هر چیز دیگری) از تمام محتوای درخت را هنگام امضای commit یا تگ محاسبه کنید و آن را به عنوان یک هدر جدید در آن شی که سپس امضا می شود، تزریق کنید. اکنون امضا، محتوای و تاریخچه مبتنی بر SHA-1 و همچنین هش محتویات درختی را که به طور مستقل در زمان امضا محاسبه می‌شود، هش می‌کند.

اکنون وقتی آن را وارد پروژه دیگری می‌کنید، می‌توانید امضا را از طریق کلید عمومی تأیید کنید و مطمئن شوید که محتوایی که بررسی می‌کنید با هر دو امضا مطابقت دارد.

این ایده جدیدی نیست git-evtag کالین والترز از سال 2015 تقریبا دقیقا این کار را انجام داده است: این یک جایگزین برای تگ git -s است که یک جمع کنترلی Git-EVTag-v0-SHA512 را روی commit، درخت و هر حباب (که در زیر ماژول‌ها تکرار می‌شود) به تگ اضافه می‌کند قبل از اینکه علامت SHA مستقل از درخت تأیید شود.

اگر SHA-256 به خطر بیفتد، می‌توانیم برای یک تابع هش جدید و پروژه‌هایی که مراقبت می‌توانند به آن نیاز داشته باشند، پشتیبانی اضافه کنیم (هدر tree-blake3 یا هر چیز دیگری). ما حتی می‌توانیم این کار را با هش‌های متعدد انجام دهیم و هیچ‌کدام یا همه آنها را برای اعتماد محتوا تأیید کنیم. هر بار که اعتماد به یک الگوریتم به خطر می افتد، تنها کاری که باید انجام دهیم این است که یک روش هش و تأیید جدید اضافه کنیم، نه اینکه همه پروژه های موجود را مهاجرت کنیم.

نقاط ضعف این است که ممکن است نتوانیم به هر commit اعتماد کنیم، فقط به اشیایی که هدر در آنها وجود دارد و امضا شده اند، اما تقریبا برای هر پروژه ای که اهمیت می دهد، این احتمالا خوب است. اعتماد به یک امضا در این مورد کل تاریخ را در حال حاضر گسترش نمی دهد، اما واقعا چقدر مشکل بزرگ است؟ به هر حال پروژه هایی با این ماهیت تقریبا به طور قطع با نسخه های برچسب گذاری شده مرتبط هستند.

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

در این مورد، ما با یک درخت کاری 35 گیگابایتی از 2.1 میلیون فایل روبرو هستیم. ابزار من یک چک‌سوم (همه فایل‌های درختی اصلی، همه فایل‌های زیر ماژول) را در 5 ثانیه تولید کرد (M5 Mac multithreaded). این تقریبا بدترین حالت مطلق است.

درخت لینوکس برای درخت 1.5 گیگابایتی خود 257 میلی‌ثانیه طول می‌کشد. پروژه Git 17 میلی‌ثانیه طول می‌کشد. شما حتی می توانید این را در هر commit برای اکثر پروژه ها قرار دهید. همچنین قابل پر کردن است. شما می توانید به گذشته برگردید و به راحتی تگ های امضا شده و جمع بندی شده را روی commit های گذشته برای هر پروژه ای پرتاب کنید.

هر درختی که هر کسی به آن اهمیت می‌دهد می‌تواند به‌طور مستقل جمع‌بندی شود و بدون تغییر در مدل هش‌سازی هسته امضا شود. در هر صورت، از نظر فنی از SHA-256 به تنهایی ایمن تر خواهد بود، زیرا اکنون باید محتوایی را دریافت کنید که در هر دو الگوریتم هش برخورد کند تا مشکل ایجاد شود.

ما می‌توانیم بدون دور انداختن SHA-1 و شکستن کل اکوسیستم، استفاده از SHA-1 را برای اعتماد به محتوا متوقف کنیم. ما می‌توانیم بردار اعتماد محتوای دیگری را بدون ایجاد آشفتگی و سردرگمی عظیم برای اقلیت کوچکی از پروژه‌ها با این مشکل اعتماد اضافه کنیم.