Кейс Кук (Kees Cook), бывший главный системный администратор kernel.org и лидер Ubuntu Security Team, продемонстрировал возможность создания коммита, сокращённый идентификатор которого совпадает с коммитом, ранее добавленным в ядро Linux. Эксперимент проведён в качестве подтверждения целесообразности перехода на 16-символьные сокращённые идентификаторы коммитов в ядре Linux, ранее обсуждавшегося в списке рассылки разработчиков ядра, но не одобренного Линусом Торвальдсом...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62495
А как этим можно злоупотребить? Я пример понял но вот реальный обход нет. Да и Торвальдс и так все сам читает.
> А как этим можно злоупотребить? Я пример понял но вот реальный обход нет.
> Да и Торвальдс и так все сам читает.Это сложно ибо при этом патч должен осмыленно выглядеть и проч, не вызывая подозрений. Но те кто удумал сократить хеши до 48 бит - все же нарываются. Простите, но высокосекурный DES с 56 битов вынесли полным перебором еще во времена царя гороха. А некоторые до сих пор не доперли что так делать не надо.
короткий хэш - это просто обрезанный до n символов полный хэш (для человеков и ui). сами хэши остаются как были
> короткий хэш - это просто обрезанный до n символов полный хэш
> (для человеков и ui). сами хэши остаются как былиЕсли удалось на...ть человека, показав ему короткий хэш такой же как заявлено - он его и втянет, нисколько не сомневаясь что все как надо. А то что там хвост не совпадал... кто ж его знал, если попросили - вот это?!
> но до отправки патча было выявлено утилитой checkpatch.Выглядит как майнинг коллизий.
Какой-то бред новость. В git все коммиты хранятся в sha-1, и это обычный связанный список, там есть ссылка на первый, последний, предыдущий и следующий коммит, и индекс коммитов, таким образом легко перемещаться по дереву коммитов в любые стороны. Короткая запись по умолчанию нигде не используется, даже git log по умолчанию показывает длинный хэш. Коротки хэш это всеволишь строка поиска, с точки зрения баз данных строки: "носки дырявые", "носки новые", "носки стиранные", "носки грязные" это все уникальные идентификаторы, и нигде не возникнет коллизий, и слово "носки" является подстрокой и оно никак не является уникальным, и даже не должно быть уникальным, но может помочь найти например только "носки" из списка одежды. В каком-то git проекте я встречал одинаковые короткие хэши, и при обращении к коммиту по короткому хэшу он показывал информацию по последнему коммиту с таким хэшем. И Линус тут прав, если кто-то хочет забивать шурупы молотком, то это их проблемы и не целевое использование инструмента. Так же молотком можно кого-то убить, но это не делает инструмент не правильным и не говорит, что его надо переделать...Корпорации понабрали индусов, трaнсг3ндеров, и р6стоманов, и они теперь лезут во все дыры и несут полную безграмотную чушь во всех проектах. Интел настолько наиграл с этим, что уже процы и прошивки с гавнецом выпускают...
> и оно никак не является уникальным, и даже не должно быть уникальнымНе все это понимают
Так ведь экономическое и управленческое образование не полностью показывает, чем кончается попытка обмануть математику с физикой.Показалось инвестору, что Индия ИТ за миску супа даст тот же результат. Но - это не так. Просто заметно не сразу.
Есть люди, которые никогда не поймут отличие гуида от хеша, и которые на серьёзных щах будут утверждать что нужно просто использовать хорошую хеш функциюЭто не лечится
Ненужно ударяться в преждевременную оптимизацию.
> Ненужно ударяться в преждевременную оптимизацию.Глупый, что-ли? Коллизии выстреливают года через два, это именно то место, которое нужно предварительно правильно делать
Пользуйтесь SVN: 1,2,... 100000 цифирьки увеличиваются и никогда никаких коллизий.
Проблема в подмене смысла этих цифр с буквами. Глупость - она такая: хоть алфавит смени, но не помогает.
> Пользуйтесь SVN: 1,2,... 100000 цифирьки увеличиваются и никогда никаких коллизий.Ога, сломал 1 сервак - и выгрузил всей толпе неведомые фекальи. А без сервака этот антик вообще неоперабелен, и уж точно такой подарок проверками по локальным репам замечен не будет.
Svn централизованная система и поэтому это в принципе возможно
к счастью авторы hg не были в курсе, что это в принципе невозможно, и у них в dvcs тоже можно использовать нормальные номера версий.
Вот только они у каждого свои, что делает их непригодными для обсуждаемых целей.По большому счету, вся польза от этих циферок покрывается конструкциями вида HEAD~4.
Я уважаю Кейса Кука больше, чем Линуса, НО в этой ситуации я согласен с Линусом. 🤷♂️💬
> Я уважаю Кейса Кука больше, чем Линуса, НО в этой ситуации я согласен с Линусом. 🤷♂️💬Да это не киса куку предложил хрень с base36, как по мне - так стоит просто оперировать полными хешами. По хорошему - перйдя на SHA256.
К полному хешу можно еще unix-timestamp добавить для надежности.
что бы что? проблема в коллизии первых 12 символов, а не в полном хэше
А на фига использовать только первые 12 символов ?! Какой умник это придумал ?
Потому-что 12 символов это коротко.
Не понимаю местных комментаторов, которым коллизии непочем. Коллизии - это страшно, нужно предотвращать, удлинять. ShA-1 в целом тоже уже устаревшая хэш-функция, но понимаю, что на sha2 менять мб затруднительно
Проснитесь уже, для индентификации коммита используется 160 битный хэш, и количество коллизий там минимальное, в случае возникновения коллизии легко можно скипнуть коммит, и сделать его снова, это событие довольно редко. Речь в статье идет не про сам хэш, а про транкейт hex строки из 160 битного хэша, до короткого хэша вида f293418d и этот хэш нигде не хранится в метаданных, это не более чем строка поиска. Поэтому попытки комментаторов сделать из мухи слона выглядят довольно безграмотно. Короткий хэш используется обычно в связки git log --oneline, а дальше например git show короткий_хэш. Короткий хэш лишь облегчается поиск хэша, занимает меньше места, служит для удобства, и не является какой-либо реальной ссылкой. Тот же гитхаб к примеру показывает текст ссылки на комминт как короткий хэш, а сама ссылка уже ведет на полноценный - длинный 160 битный хэш. Если кто-то использует не корректно короткий хэш и привязывает к нему какие-то данные, это его проблемы, и не корректное использование короткого хэша. Кроме как для сокращения выводы на экране и поиска он нигде не должен быть использован.
> Проснитесь уже, для индентификации коммита используется 160 битный хэш,
> и количество коллизий там минимальное,Для SHA-1 все же известны криптографические атаки. Конечно на слом 160 битов - да еще с теми constraints - ресурсов надо многократно больше. Но совсем не столько сколько ожидалось. А вот SHA256... там, видите ли, генерация "нужного" хеша основа майнинга. Если б кто-то сумел в предсказуемые хеши, уже миллиардером был бы. Потому что pow сводится к подгону SHA256 до нужного числа нолей в начале. Если удалось - ЗБС, вы намайнили блок, профит ваш! Правда, есть перестроить сложность если вы будете блоки слишком бытсро фигачить - но не сразу - и к тому же профит все же уйдет от остальных майнеров к более успешному шустряку.
> можно скипнуть коммит, и сделать его сноваМожно поподробнее? С точки зрения использования гита из командной строки это как будет выглядеть?
Не благодарите:
git add blblba
git commit -S
-- ошибка при создании коммита
git commit -SХэш формируется командой git commit или git merge.
Короткие идентификаторы используются для быстрого поиска, а не для коммитов. Попробуй потоньше.
Ненене, мой вопрос к анониму выше касался именно (гипотетической) ситуации с полным идентификатором коммита. Спасибо ему за ответ.
Всё же поблагодарю. Спасибо за информацию!Никогда с таким не сталкивался на практике (по понятным причинам), и было интересно, как с таким бороться в случае чего.
правда в том, что наглядность и удобность 12- и 16-ти символьных short hash'ей одинаковая. Они одинаково длинные для запоминания и необходимости копирования, а для билд/чек скриптов это все без разницы.
Во-во. Мы вот в нашей компании сыздавна использовали полные id коммитов где только можно (в почте, JIRA и тп). Какая разница что копировать по двойному клику-то?
да, то и другое - г-но полное.Вот как ты собираешься обсуждать с коллегами изменение с хэшем <somerandomshit> ?
Только человек в принципе не умеющий пользоваться vcs (угадайте, кто ж это был) мог придумать эту чушь.
> да, то и другое - г-но полное.
> Вот как ты собираешься обсуждать с коллегами изменение с хэшем <somerandomshit> ?
> Только человек в принципе не умеющий пользоваться vcs (угадайте, кто ж это
> был) мог придумать эту чушь.хэши не для обсуждения с коллегами нужны
а версий у вас нет. Поэтому когда надо сказать "а вот в этом изменении было вот такое" - остаются только хэши.Повторяю - придумать такую глупость - достойный результат человека, которого всей толпой пять лет уговаривали научиться пользоваться ну хоть какой vcs. Но он был совершенно счастлив своей "новая папка 94"
Сокращение строковых значений и их последующее восстановление и сравнение - это глупость. Адреса криптокошельков, номера расчетных счетов - тоже строковые значения.
Коллизии настролько редки, что решили оставить всё как есть а не усложнять.
т.е. они просто берут первые 12 символов от хеша?
Гениально!
"Оставайтесь, у нас. Будете гениальным механиком планеты!" (с)
А что туту такого. На то и короткие.
Да, потому что это не реальная ссылка, а лишь удобный метод сокращения вывода на экране! Он даже не является реальной ссылкой на какой-то коммит, а лишь являет более удобной подстрокой, для текстового поиска, отсюда мы можем иметь сколько угодно много таких одинаковых подстрок.
этим довенам даже показали как повторить первые 12 символов,
а они продолжают нахваливать и жрать с лопаты - "ну а че, это уже удобно"...
>Возникновение коллизий, при которых несколько разных изменений оказываются связаны с одним сокращённым идентификатором, могут привести к нарушению работы инструментов для анализа и проверки изменений, учитывающих содержимое тегов "Fixes".
Да, талантливые ребята. Прямо как те, кто заложили год кодировал двумя символами. Заранее заложенная мина замедленного действия.
"640 КБ на самом деле хватит всем"
Эта та самая, знаменитая цитата Билла Гейтса?
Два символа для хранения года в данных. Гениальная экономия))). Чтобы потом пострадать
> Сокращённые идентификаторы коммитов формируются через оставление
> первых 12 символов от хэша SHA-1 (48 бит из 160 бит)Ну спасибо капитан очевидность, заколлайдить 48 битов - это вообще как дважды два. И вот тут я не понимаю тех кто хочет сократить хэш, они давно нарываются.
Это хэш коммитов ЯДРА. Нафига ты коммитишь каждые 2 символа?
> Это хэш коммитов ЯДРА. Нафига ты коммитишь каждые 2 символа?Вон там гражданин показал - что задавшись целью можно подогнать такой же "на вид" (сокрашенный хеш) комит - с другим содержимым. А вот это уже не айс. Ибо открывает почву для злоупотреблений. Конечно там еще пуллы по иерархии и все же это читают - но лучше пусть двуногие И машины обеспечивают 2 контура проверок, чем чисто на одних глазах выезжать.
Если бы Линус не разгонял этих горе новаторов не было бы сейчас никакого ядра. Сначала они пропихнут длинную коммитов, а потом зонд.
Самое странное, зачем делать уязвимости в ядре, когда полно приложух работающих с привилегиями ядра, и за которыми особо не смотрят. Наверняка специально отвлекают внимание на ядро, чтобы и дальше никто не смотрел.
> Самое странное, зачем делать уязвимости в ядре, когда полно приложух работающих с
> привилегиями ядраЭто как? Мне уже интересно, право. Примеры такой приложухи? :)
git уже давно умеет не только sha1, а вообще давно нужно перейти на sha3-512
Он на GitHub слать не умеет так. Да и GitHub принимать не умеет так.
> Он на GitHub слать не умеет так. Да и GitHub принимать не умеет так.Да и хрен с ним с гитхабом. Майкрософт его уже и так почти доломал, а с их маркетинговым булшитом - скоро доломает окончательно.
Можно же добавить проверку на уже существующие и использовать короткие, пока не кончатся. Думаю, этого Торвальдс и хочет.