Новий хеш за замовчуванням у Git – що це означає

Що охоплює це відео

• Чому два репозиторії Git можуть відмовитися взаємодіяти?
• Що насправді змінює Git 3?
• Навіщо замінювати SHA-1, якщо Git виявляє колізії?
• Що показала наша локальна перевірка сумісності?
• Що виживає після збою в Pi Durable?

Перекладена стенограма

Перекладено з оригінальної англійської розповіді. Доступне аудіо та субтитри контролюються YouTube.

Чому два репозиторії Git можуть відмовитися взаємодіяти?

0:00 Можна подумати, що оновлення Git зберігає взаємодію ваших інструментів. Запланований новий хеш за замовчуванням у Git створює репозиторії, з якими старий формат сьогодні не може взаємодіяти. У цьому відео, навіщо змінювати? Що зламається? Хто готовий? На GitHub вже є робочий виняток. Я покажу вам, що він доводить в кінці. Сьогодні п'ятниця, друге жовтня, і це The Daily Diff.

0:18 У четвер співзасновник GitHub назвав заплановану зміну Git дорогою помилкою. Pi випустив новий агентний каркас, а SvelteKit випустив ще одну міграцію. Скотт Чакон допомагав створювати GitHub і написав Pro Git, тож ця скарга походить з середини будинку. Будинок також продає інструменти Git. По-перше, фактичний план.

Що насправді змінює Git 3?

0:35 Git три за замовчуванням встановлюватиме нові репозиторії на SHA-256, як тільки бібліотеки та хостинг-сервіси будуть готові його підтримувати. Офіційний документ не вказує дати випуску та зберігає підтримку SHA-1. Ваш існуючий репозиторій не змінює формат магічним чином, коли ви оновлюєте виконуваний файл. Це варто пам'ятати, перш ніж ваш груповий чат запланує термінову міграцію. Драма – це запропонований за замовчуванням, і термін – це наразі порожній календар.

Навіщо замінювати SHA-1, якщо Git виявляє колізії?

0:58 Навіщо взагалі змінювати? Git іменує об'єкти, хешуючи їх вміст. Файли подаються до дерев, а коміти посилаються на дерева та попередні коміти. Це забезпечує цілісність по всій історії. Змініть схему хешування, і імена об'єктів також зміняться, включно з посиланнями, що зберігаються всередині інших об'єктів. Чакон повертається до Лінуса Торвальдса, творця Git, стверджуючи, що надійний

1:17 розподіл має значення. Це історична позиція, і Лінус вибрав SHA-1 ще у дві тисячі п'ятому році. З того часу ситуація з безпекою змінилася. Дослідники продемонстрували колізії SHA-1 у дві тисячі сімнадцятому році, а пізніше продемонстрували атаку з обраним префіксом проти сертифікатів ідентифікації PGP. Сучасний Git виявляє відомі атаки колізій за допомогою посиленого SHA-1. Його розробники хочуть захисту і від майбутніх атак, що є розумним бажанням щодо підписів.

1:41 Чакон вважає, що екосистемний рахунок купує занадто мало безпеки. Він пропонує підписувати окрему сильну контрольну суму вмісту дерева, зберігаючи при цьому сьогоднішню адресацію об'єктів. Що зламається? Я створив обидва формати локально та хешував той самий маленький файл.

Що показала наша локальна перевірка сумісності?

1:54 Одне ім'я об'єкта має сорок шістнадцяткових символів, інше – шістдесят чотири. Потім я спробував отримувати дані між ними. Мій встановлений Git відхилив це з невідповідними алгоритмами, саме той розрив сумісності, описаний в поточному офіційному посібнику. Це використовувало мій старий встановлений Git, тому він розповідає нам про сьогоднішню межу. Назвати це тестом не випущеного Git 3 було б креативним обліком. Робота з міграцією поширюється на скрипти, які передбачають довжину хешу, та системи, які посилаються на імена об'єктів.

2:19 Перехешування історії потребує зіставлення між цими ідентичностями. Дизайн переходу Git включає це зіставлення та обробку підписів. Готовність до реалізації має значення, оскільки дизайн-документ не оновлює бібліотеку, що ховається у вашому улюбленому інструменті розробника. Це людські витрати в аргументі Чакона. Кожен розробник інструментів отримує ще одне завдання на сумісність, тоді як користувачі виявляють, що їхньому контролю версій тепер потрібен контроль версій. Наразі протестуйте свій хост та інструменти, перш ніж вибирати новий формат для

2:44 проекту. Існуючі команди можуть зберігати свій поточний формат, поки ця екосистема наздоганяє. Тим часом, Pi досяг версії 1.0.

Що виживає після збою в Pi Durable?

2:51 Це агентний каркас кодування від Earendil, з рідною підтримкою MCP через Codemode та інструментами, які завантажуються за потребою. Команда називає мінімалізм головним. Якщо ваша агентна установка вже нагадує малий уряд, зберігання інструментів поза підказкою до потреби звучить як адміністративна реформа. Він також випустив Pi Durable, окремий експериментальний каркас. Завдання зберігають контрольні точки, щоб перезапущений процес міг продовжити незавершену роботу з постійного сховища. Вирішальною деталлю є повторне відтворення інструменту.

3:16 Інструмент, перерваний збоєм, повторно запускається лише тоді, коли він заявляє, що це безпечно. В іншому випадку моделі повідомляється, що її було перервано. Це корисна межа, коли інструмент може витрачати гроші. Я хочу, щоб помічник запам'ятав мій список покупок, не святкуючи збій тим, що купує його двічі.

Що SvelteKit 3 мігрує для вас?

3:30 SvelteKit 3 також вийшов у четвер, перемістивши конфігурацію до Vite та замінивши dollar lib на hash lib, використовуючи стандартні імпорти підшляхів пакетів. Команда міграції переписує те, що може, і залишає список справ для решти. Ваш робот може допомогти, і ваш диференціал все ще заслуговує на прочитання. Оголошення навіть залучає ваших друзів-роботів для залишків. Ми досягаємо точки, коли оновлення фреймворку надає домашнє завдання та запропонованого замінного вчителя. А віддалені функції все ще потребують експериментального Async Svelte.

3:56 Основний номер версії виглядає обнадійливо, але окремі функції мають власні мітки зрілості. Перевірте ті, які ви фактично використовуєте.

Що доводить робочий виняток GitHub?

4:03 То хто готовий до нового формату Git? Ось цей виняток. Публічний репозиторій GitHub, що містить доповідь Брайана Карлсона, вже повертає повне ім'я об'єкта SHA-256. Я перевірив публічний віддалений репозиторій безпосередньо. Слайди доповіді називають підтримку приватним попереднім переглядом і кажуть, що створення репозиторіїв все ще попереду. За кімнатою очікування є реальний прогрес. Це доводить, що GitHub може обслуговувати цей репозиторій попереднього перегляду.

4:24 Він не дає жодних гарантій, що звичайне створення проектів або всі ваші інтеграції готові. Виняток має межу дозволу. Якщо ви волієте читати це, а не чути від мене, диференціал надходить на вашу поштову скриньку щоранку, безкоштовно на thedailydiff.dev, посилання нижче. Отже, сьогоднішній вердикт – NEEDS REVIEW.

Чому мій вердикт залежить від всього набору інструментів?

4:40 Я б залишив опцію сильнішого хешу та перевірив весь набір інструментів, перш ніж змінювати налаштування за замовчуванням. Сумісність є частиною впровадження покращення безпеки. І це диференціал на сьогодні. Я Ніко з Axrisi. Зливайте відповідально.

Джерела

1. Chaconblog.gitbutler.com
2. Git's official plangit-scm.com
3. Current interoperabilitygit-scm.com
4. Transition designgit-scm.com
5. Independent collision researchsha-mbles.github.io
6. GitHub preview repositorygithub.com
7. Pi 1.0earendil.com
8. Pi Durableearendil.com
9. SvelteKit 3svelte.dev
10. HN discussionnews.ycombinator.com