Как Git справится со столкновением SHA-1 на BLOB-объекте?

543

Вероятно, этого еще никогда не случалось в реальном мире, и, возможно, никогда не случится, но давайте рассмотрим это: скажем, у вас есть git-репозиторий, сделайте коммит, и вам очень очень не повезло: один из BLOB-объектов заканчивается тем же SHA-1 как другой, который уже находится в вашем хранилище. Вопрос в том, как Git справится с этим? Просто потерпеть неудачу? Найдите способ связать два блоба и проверить, какой из них нужен в соответствии с контекстом?

Больше дразнилка, чем реальная проблема, но я нашел проблему интересной.

Gnurou
источник
76
Когда-то дразнилка мозга, теперь потенциально актуальная проблема .
Тоби,
11
@Toby Этот вопрос был о нападении перед изображением ; Google продемонстрировал атаку столкновением - похожую, но немного другую. Вы можете прочитать больше о разнице здесь .
Сахид
@Saheed Я не понимаю, какая часть этого вопроса касается конкретно атаки перед изображением, поскольку поставленный вопрос касается только коллизии в git-репозитории, а не об ее использовании.
Тоби,
3
@Toby Оригинальный тизер мозга был не о нападении (ни до изображения, ни о столкновении), а о случайном столкновении, которое настолько невероятно маловероятно, что его не стоит рассматривать. Я думаю, что Сахид правильно пытался сказать, что это все еще не актуальная проблема. Однако вы правы в том, что атака коллизий Google потенциально создала проблему безопасности в зависимости от того, как используется Git.
Эндрю В. Филлипс
Вот второе столкновение, которое составляет всего 320 байт privacylog.blogspot.com/2019/12/the-second-sha-collision.html
Уильям Энтрикен,

Ответы:

736

Я провел эксперимент, чтобы выяснить, как именно Git будет вести себя в этом случае. Это с версией 2.7.9 ~ rc0 + next.20151210 (версия Debian). Я просто уменьшил размер хеша со 160-битного до 4-битного, применив следующий diff и перестроив git:

--- git-2.7.0~rc0+next.20151210.orig/block-sha1/sha1.c
+++ git-2.7.0~rc0+next.20151210/block-sha1/sha1.c
@@ -246,6 +246,8 @@ void blk_SHA1_Final(unsigned char hashou
    blk_SHA1_Update(ctx, padlen, 8);

    /* Output hash */
-   for (i = 0; i < 5; i++)
-       put_be32(hashout + i * 4, ctx->H[i]);
+   for (i = 0; i < 1; i++)
+       put_be32(hashout + i * 4, (ctx->H[i] & 0xf000000));
+   for (i = 1; i < 5; i++)
+       put_be32(hashout + i * 4, 0);
 }

Затем я сделал несколько коммитов и заметил следующее.

  1. Если BLOB-объект с таким же хешем уже существует, вы вообще не получите никаких предупреждений. Кажется, все в порядке, но когда вы нажимаете, кто-то клонирует, или вы возвращаетесь, вы потеряете последнюю версию (в соответствии с тем, что описано выше).
  2. Если объект дерева уже существует, и вы создаете BLOB-объект с таким же хешем: все будет казаться нормальным, пока вы не попробуете протолкнуть или кто-то клонирует ваш репозиторий. Тогда вы увидите, что репо повреждено.
  3. Если объект фиксации уже существует, и вы создаете BLOB-объект с таким же хешем: то же самое, что и # 2 - поврежден
  4. Если BLOB-объект уже существует, и вы создаете объект коммита с таким же хешем, он потерпит неудачу при обновлении «ref».
  5. Если BLOB-объект уже существует, и вы создаете объект дерева с таким же хешем. Это не удастся при создании коммита.
  6. Если объект дерева уже существует, и вы делаете объект фиксации с тем же хешем, то произойдет сбой при обновлении «ref».
  7. Если объект дерева уже существует и вы создаете объект дерева с таким же хешем, все будет хорошо. Но когда вы фиксируете, все хранилище будет ссылаться на неправильное дерево.
  8. Если объект фиксации уже существует, и вы делаете объект фиксации с тем же хешем, все будет хорошо. Но когда вы делаете коммит, коммит никогда не будет создан, а указатель HEAD будет перемещен в старый коммит.
  9. Если объект фиксации уже существует, и вы создаете объект дерева с таким же хешем, он завершится неудачно при создании фиксации.

Для # 2 вы, как правило, получаете ошибку, подобную этой, когда вы запускаете "git push":

error: object 0400000000000000000000000000000000000000 is a tree, not a blob
fatal: bad blob object
error: failed to push some refs to origin

или:

error: unable to read sha1 file of file.txt (0400000000000000000000000000000000000000)

если вы удалите файл, а затем запустите "git checkout file.txt".

Для № 4 и № 6 вы, как правило, получите ошибку, подобную этой:

error: Trying to write non-commit object
f000000000000000000000000000000000000000 to branch refs/heads/master
fatal: cannot update HEAD ref

при запуске "git commit". В этом случае вы можете просто снова набрать «git commit», так как это создаст новый хеш (из-за измененной метки времени)

Для № 5 и № 9 вы обычно получаете сообщение об ошибке, подобное этому:

fatal: 1000000000000000000000000000000000000000 is not a valid 'tree' object

при запуске "git commit"

Если кто-то попытается клонировать ваш поврежденный репозиторий, он обычно увидит что-то вроде:

git clone (one repo with collided blob,
d000000000000000000000000000000000000000 is commit,
f000000000000000000000000000000000000000 is tree)

Cloning into 'clonedversion'...
done.
error: unable to read sha1 file of s (d000000000000000000000000000000000000000)
error: unable to read sha1 file of tullebukk
(f000000000000000000000000000000000000000)
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry the checkout with 'git checkout -f HEAD'

Меня «беспокоит» то, что в двух случаях (2,3) хранилище становится поврежденным без каких-либо предупреждений, а в 3 случаях (1,7,8) все выглядит нормально, но содержимое хранилища отличается от того, что вы ожидаете быть. У людей, клонирующих или тянущих, будет другое содержание, чем у вас. Случаи 4,5,6 и 9 в порядке, так как остановится с ошибкой. Я полагаю, было бы лучше, если бы это не удалось с ошибкой, по крайней мере, во всех случаях.

Ruben
источник
157
Потрясающий ответ - уменьшить размер хеша, чтобы увидеть, как он на самом деле себя ведет, отличная идея.
Гнуроу
4
@Gnurou Я согласен, и тогда я ответил на этот вопрос. Упоминались ли эти случаи в списке рассылки git?
VonC
1
Насколько вероятно, что это действительно происходит без уменьшения размера хеша?
Матиас Бадер
4
Кроме того, каковы планы, если таковые имеются, чтобы перейти к другому алгоритму хеширования.
Пит
9
Обязательно прочитайте - объяснения Линуса Торвала: plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL
phil_lgr
238

Оригинальный ответ (2012) (см. shattered.ioСтолкновение SHA1 2017 ниже)

Этот старый (2006 г.) ответ Линуса все еще может быть актуален:

Нет. Если он имеет тот же SHA1, это означает, что когда мы получим объект с другого конца, мы не будем перезаписывать объект, который у нас уже есть.

Так что получается, что если мы когда-либо увидим столкновение, «более ранний» объект в любом конкретном хранилище всегда будет переопределяться. Но обратите внимание, что «ранее» очевидно для каждого хранилища, в том смысле, что сеть объектов git генерирует группу обеспечения доступности баз данных, которая не полностью упорядочена, поэтому в то время как разные хранилища согласятся с тем, что «раньше» в случае прямого происхождения, если объект прошел через отдельные и не связанные напрямую ветви, два разных хранилища, очевидно, могли получить два объекта в разном порядке.

Тем не менее, «более ранняя переопределение» очень важна с точки зрения безопасности: помните, что модель git заключается в том, что вы должны в первую очередь доверять только своему собственному репозиторию.
Поэтому, если вы делаете « git pull», новые входящие объекты по определению менее надежны, чем объекты, которые у вас уже есть, и поэтому было бы неправильно разрешать новому объекту заменять старый.

Итак, у вас есть два случая столкновения:

  • непреднамеренный вид , где - то очень - очень повезло, и два файла в конечном итоге с той же SHA1.
    В этот момент происходит то, что когда вы фиксируете этот файл (или делаете « git-update-index», чтобы переместить его в индекс, но еще не зафиксировали), SHA1 нового содержимого будет вычислено, но так как он соответствует старому объекту, новый объект не будет создан, и фиксация или индекс заканчивает указанием на старый объект .
    Вы не заметите сразу (так как индекс будет соответствовать старому объекту SHA1, и это означает, что что-то вроде «git diff " будет использовать извлеченную копию), но если вы когда-нибудь сделаете diff на уровне дерева (или вы сделаете клон или вытащить, или принудительно оформить заказ) вы вдруг заметите, что этот файл изменился на что-тополностью отличается от того, что вы ожидали.
    Таким образом, вы, как правило, заметили такое столкновение довольно быстро.
    В связанных новостях вопрос заключается в том, что делать с непреднамеренным столкновением.
    Прежде всего, позвольте мне напомнить людям, что непреднамеренное столкновение действительно очень маловероятно, поэтому мы, скорее всего, никогда не увидим его за всю историю. Вселенной.
    Но если это произойдет, это не конец света: вам, скорее всего, придется просто изменить файл, который слегка столкнулся, и просто принудительно создать новый коммит с измененным содержимым (добавьте комментарий с надписью « /* This line added to avoid collision */») и затем обучите мерзавца магии SHA1, которая оказалась опасной.
    Таким образом, в течение пары миллионов лет, возможно, нам придется добавить одно или два «отравленных» значения SHA1 в git. Это очень маловероятно, чтобы быть проблемой обслуживания;)

  • Взломщик рода столкновения , потому что кто - то сломал (или скотина-принудительную) SHA1.
    Это, безусловно, намного более вероятно, чем непреднамеренный, но по определению это всегда «удаленный» репозиторий. Если бы у злоумышленника был доступ к локальному хранилищу, у него были бы намного более простые способы испортить вас.
    Таким образом, в этом случае столкновение не является проблемой : вы получите «плохой» репозиторий, отличный от того, который планировал атакующий, но поскольку вы никогда не будете использовать его сталкивающийся объект, он буквально не отличается от злоумышленник просто не обнаружил столкновения вообще, но просто используя объект, который у вас уже был (т.е. он на 100% эквивалентен «тривиальному» столкновению идентичного файла, генерирующего тот же SHA1).

Вопрос об использовании SHA-256 регулярно упоминается, но не действует на на текущем (2012).
Примечание: начиная с 2018 года и Git 2.19 , код подвергается рефакторингу для использования SHA-256.


Примечание (юмор): вы можете принудительно зафиксировать конкретный префикс SHA1 с помощью gitbrute проекта от Брэда Фицпатрика ( bradfitz) .

gitbrute brute-форсирует пару временных меток "автор + коммиттер", так что результирующий git commit имеет желаемый префикс.

Пример: https://github.com/bradfitz/deadbeef


Даниэль Динниес указывает в комментариях на 7.1 Git Tools - Revision Selection , который включает в себя:

Существует более высокая вероятность того, что каждый член вашей команды программистов будет атакован и убит волками в несвязанных инцидентах в одну и ту же ночь.


Даже совсем недавно (февраль 2017 года) была shattered.ioпродемонстрирована возможность создания столкновения SHA1:
(см. Гораздо больше в моем отдельном ответе , в том числе в посте Линуса Торвальдса в Google+)

  • а / все еще требуется более 9 223 372 036 854 775 808 вычислений SHA1. Это заняло эквивалентную вычислительную мощность как 6500 лет вычислений с одним ЦП и 110 лет вычислений с одним ГП.
  • b / подделал бы один файл (с тем же SHA1), но с дополнительным ограничением его содержимое и размер дали бы идентичный SHA1 (коллизия только одного содержимого недостаточна): см. « Как вычисляется git-хеш? ») : BLA- объект SHA1 вычисляется на основе содержимого и размера .

Смотрите " Время жизни криптографических хеш-функций " от Валери Аниты Авроры для получения дополнительной информации.
На этой странице она отмечает:

Google потратил 6500 лет CPU и 110 лет GPU, чтобы убедить всех, что нам нужно прекратить использовать SHA-1 для критически важных приложений.
Кроме того, потому что это было круто

Смотрите больше в моем отдельном ответе ниже .

VonC
источник
25
твист: все еще хэширует то же самое после добавления /* This line added to avoid collision */: D вы можете выиграть в лотерею дважды: P
Янус Троелсен
4
@JanusTroelsen конечно, но это все равно лотерея, не так ли? ;) (как упомянуто в этой короткой заметке о SHA1 )
VonC
6
@VonC относительно этой ссылки : является ли вспышка глобальной эпидемии оборотней - уничтожение всего человечества и приведение к ужасной смерти всех моих разработчиков в одну ночь, даже если они были географически распределены - считается несвязанным инцидентом ?? Конечно, если предположить, что это произошло в полнолуние, очевидно. Теперь такой сценарий изменит вещи. Даже думать об этом - безумие! Это в совершенно другом масштабе вероятности! Это означало бы, что мы должны ... ОСТАНОВИТЬ ИСПОЛЬЗОВАНИЕ GIT! СЕЙЧАС ЖЕ!!! КАЖДЫЙ RUUUUUN !!!!!!!
Даниэль Динниес
2
Обратите внимание, что gitbrute не форсирует конкретный SHA1, а только префикс (то есть часть всего SHA1). Форсирование всего SHA1 (то есть с префиксом полной длины ключа), вероятно, займет слишком много времени.
mb14
2
@JanusTroelsen Тогда вы бы добавили:/* This line added to avoid collision of the avoid collision line */
Smg
42

По словам Pro Git :

Если вам случится зафиксировать объект, который хэширует то же значение SHA-1, что и предыдущий объект в вашем хранилище, Git увидит предыдущий объект уже в вашей базе данных Git и предположит, что он уже записан. Если в какой-то момент вы попытаетесь снова проверить этот объект, вы всегда получите данные первого объекта.

Так что это не подведет, но и не сохранит ваш новый объект.
Я не знаю, как это будет выглядеть в командной строке, но это, безусловно, сбивает с толку.

Чуть дальше эта же ссылка пытается проиллюстрировать вероятность такого столкновения:

Вот пример, чтобы дать вам представление о том, что потребуется, чтобы получить столкновение SHA-1. Если бы все 6,5 миллиарда людей на Земле программировали, и каждую секунду каждый из них создавал код, который был эквивалентен всей истории ядра Linux (1 миллион объектов Git), и помещал его в один огромный репозиторий Git, это заняло бы 5 лет, пока этот репозиторий содержал достаточно объектов, чтобы иметь 50% вероятности столкновения одного объекта SHA-1. Существует более высокая вероятность того, что каждый член вашей команды программистов будет атакован и убит волками в несвязанных инцидентах в одну и ту же ночь.

Мат
источник
44
Я хотел бы видеть источник чисел в последнем предложении ;-)
Йоахим Зауэр
17
@Jasper: эта ссылка является хорошей документацией, но она не содержит статистических данных о вероятности того, что каждый член команды будет атакован и убит волками в несвязанных инцидентах в одну и ту же ночь.
Йоахим Зауэр
5
@Jasper: Ну, как я понял, текст буквально утверждает, что вероятность того, что 6,5 миллиарда членов команды будут убиты волками в одну и ту же ночь, выше 50%. Но мое главное возражение против его утверждения , что такое событие будет иметь для быть всемирным явлением; это немыслимо , что это могло произойти из - за несвязанные инциденты. ;)
Кит Робертсон
5
@KeithRobertson Я почти уверен, что пост говорит о вероятности того, что все ваши действительные члены команды будут съедены по сравнению с вероятностью коллизии хэшей, если все в мире будут создавать безумные объемы кода, а также время, которое требуется в этих обстоятельствах для вероятность столкновения составляет 50% (т. е. инцидент с волками не охватил весь мир, а 50% были отделены от волков). Хотя вы и поняли, что если такое событие немыслимо, то и должно случиться столкновение с git-хешем. (Конечно, один (почти) основан исключительно на случайности, а другой нет, но все же.)
Джаспер
12
Тоби
23

Чтобы добавить к моему предыдущему ответу от 2012 года , теперь есть (февраль 2017 года, пять лет спустя) пример фактического столкновения SHA-1 с shattered.io , где вы можете создать два сталкивающихся PDF-файла: получить SHA- 1 цифровая подпись на первом файле PDF, которая также может использоваться как действительная подпись на втором файле PDF.
Смотрите также « У дверей смерти в течение многих лет, широко используемая функция SHA1 теперь мертва », и эта иллюстрация .

Обновление от 26 февраля: Линус подтвердил следующие пункты в посте Google+ :

(1) Прежде всего - небо не падает. Существует большая разница между использованием криптографического хэша для таких вещей, как подпись безопасности, и его использованием для генерации «идентификатора контента» для системы с адресным контентом, такой как git.

(2) Во-вторых, природа этой конкретной атаки SHA1 означает, что на самом деле довольно легко принять меры против нее, и уже было выпущено два набора исправлений для этой меры.

(3) И, наконец, на самом деле существует довольно простой переход к другому хешу, который не сломает мир - или даже к старым git-репозиториям.

Относительно этого перехода см. Git 2.16 Q1 2018, в котором добавлена ​​структура, представляющая алгоритм хеширования. Осуществление этого перехода началось.

Начиная Git 2.19 (Q3 2018) , Git выбрал SHA-256 в качестве NewHash и находится в процессе интеграции его в код (то есть SHA1 по-прежнему используется по умолчанию (Q2 2019, Git 2.21), но SHA2 будет преемником)


Оригинальный ответ (25 февраля) Но:

Джои Хесс пробует эти PDF в репозитории Git, и он обнаружил :

Это включает в себя два файла с одинаковым SHA и размером, которые получают разные BLOB-объекты благодаря тому, как git добавляет заголовок к содержимому.

joey@darkstar:~/tmp/supercollider>sha1sum  bad.pdf good.pdf 
d00bbe65d80f6d53d5c15da7c6b4f0a655c5a86a  bad.pdf
d00bbe65d80f6d53d5c15da7c6b4f0a655c5a86a  good.pdf
joey@darkstar:~/tmp/supercollider>git ls-tree HEAD
100644 blob ca44e9913faf08d625346205e228e2265dd12b65    bad.pdf
100644 blob 5f90b67523865ad5b1391cb4a1c010d541c816c1    good.pdf

В то время как добавление идентичных данных в эти конфликтующие файлы приводит к возникновению других коллизий, предварительные данные - нет.

Таким образом, основным вектором атаки (подделка коммита) будет :

  • Создать объект регулярной фиксации;
  • использовать весь объект фиксации + NUL в качестве выбранного префикса, и
  • используйте атаку с идентичным префиксом для создания конфликтующих хороших / плохих объектов.
  • ... и это бесполезно, потому что хорошие и плохие объекты коммитов все еще указывают на одно и то же дерево!

Кроме того, вы уже можете и обнаруживать криптоаналитические атаки на SHA-1, присутствующие в каждом файле с cr-marcstevens/sha1collisiondetection

Добавление аналогичной проверки в Git само по себе потребует некоторых вычислений .

Об изменении хэша Linux комментирует :

Размер хеша и выбор алгоритма хеширования являются независимыми вопросами.
Что вы, вероятно, сделаете, это переключитесь на 256-битный хеш, используйте его внутренне и в собственной базе данных git, а затем по умолчанию покажите хэш только как шестнадцатеричную строку из 40 символов (вроде того, как мы уже сокращаем вещи в много ситуаций).
Таким образом, инструменты вокруг git даже не видят изменения, если не переданы в каком-то специальном --full-hashаргументе " " (или --abbrev=64"или как угодно - по умолчанию мы сокращаем до 40).

Тем не менее, план перехода (от SHA1 к другой хэш-функции) все еще будет сложным , но активно изучается. Кампания находится в стадии разработки :
convert-to-object_id


Обновление 20 марта: GitHub подробно описывает возможную атаку и ее защиту :

Именам SHA-1 можно присвоить доверие через различные механизмы. Например, Git позволяет криптографически подписывать коммит или тэг. При этом подписывается только сам объект фиксации или тега, который, в свою очередь, указывает на другие объекты, содержащие фактические данные файла, используя их имена SHA-1. Столкновение в этих объектах может привести к подписи, которая кажется действительной, но которая указывает на данные, отличные от предполагаемых подписывающим лицом. В такой атаке подписывающий видит только одну половину столкновения, а жертва видит вторую половину.

Степень защиты:

Недавняя атака использует специальные методы для использования слабых мест в алгоритме SHA-1, которые обнаруживают столкновение за гораздо меньшее время. Эти методы оставляют шаблон в байтах, который может быть обнаружен при вычислении SHA-1 любой половины пары столкновения.

GitHub.com теперь выполняет это обнаружение для каждого вычисляемого им SHA-1 и прерывает операцию, если есть доказательства того, что объект является половиной конфликтующей пары. Это не позволяет злоумышленникам использовать GitHub, чтобы убедить проект принять «невинную» половину их столкновения, а также не позволяет им размещать вредоносную половину.

Смотри " sha1collisiondetection" Марк Стивенс


Снова, с Q1 2018 Git 2.16, добавляющего структуру, представляющую алгоритм хеширования, началась реализация перехода к новому хешу.
Как упоминалось выше, новый поддерживаемый хэш будет SHA-256 .

VonC
источник
Столкновение: 1. Попытка была создать столкновение, а не случайное. 2. Из отчета в формате PDF: В целом затраченные вычислительные ресурсы эквивалентны 2 ^ 63,1 сжатиям SHA-1 и заняли приблизительно 6 500 лет CPU и 100 лет GPU . 3. Хотя мы должны перейти от MD5 и SHA-1, в общем, они подходят для уникального использования файлов.
zaph
Стоит отметить, что WebKit проверил сталкивающиеся PDF-файлы для теста. Это сломало их зеркальную инфраструктуру git-svn: bugs.webkit.org/show_bug.cgi?id=168774#c24
dahlbyk
1
@dahlbyk На самом деле стоит отметить ... в том, что я отметил это в ответе (ссылка на «У него есть какая-то проблема, git-svnхотя» относится к нему, хотя и косвенно)
VonC
1
@Mr_and_Mrs_D нет, это еще не ошибка с ошибкой. Выполняется
VonC
1
@Mr_and_Mrs_D СМОТРИТЕ редактировать 4 в stackoverflow.com/posts/42450327/revisions : сейчас происходит сбой, по крайней мере при переходе на GitHub.
VonC
6

Я думаю, что криптографы будут праздновать.

Цитата из статьи Википедии о SHA-1 :

В феврале 2005 года было объявлено о нападении Сяоюнь Вана, Ицюня Лизы Инь и Хунбо Ю. Атаки могут обнаружить столкновения в полной версии SHA-1, требующей менее 2 ^ 69 операций. (Поиск грубой силы потребует 2 ^ 80 операций.)

Виллем Хенгевельд
источник
7
Дело в том, что в SHA1 был обнаружен недостаток, и это было примерно в то время, когда был представлен Git. Кроме того, вероятность нелинейна. То, что вы играете в лотерею в течение пятидесяти лет, не означает, что у вас больше шансов на победу. У вас просто один и тот же шанс каждый раз. Человек, играющий в первый раз, все еще может победить.
0xC0000022L
Это только атака, которая обнаруживает коллизию, что означает, что вы можете найти yтакую, что h(x) == h (y) `, которая представляет серьезную угрозу для произвольных данных, таких как сертификаты SSL, однако это не влияет на Git, который будет уязвим для второй атаки перед изображением, что означает, что имея сообщение, xвы можете изменить его на сообщение, x'что h(x) == h(x'). Так что эта атака не ослабляет Git. Также Git не выбрал SHA-1 по соображениям безопасности.
Хаулет
Теперь обнаружена коллизия - только не та, которая беспокоит git напрямую. stackoverflow.com/questions/42433126/…
Виллем Хенгевелд
2 ^ 69 - это около 600 экз-операций. Восемь лет спустя суперкомпьютер Nvidia SaturnV, модернизированный с помощью A100, может выполнить 4,6 ExaOPS, поэтому он может решить эту проблему чуть более чем за 2 минуты или провести атаку методом перебора в течение нескольких дней.
qdin
6

Существует несколько различных моделей атак на хэши, например SHA-1, но обычно обсуждается поиск коллизий, включая инструмент Марка Стивенса « HashClash» .

«Начиная с 2012 года, наиболее эффективной атакой на SHA-1 считается атака Марка Стивенса [34] с оценочной стоимостью 2,77 млн. Долл. США для взлома единственного значения хеш-функции путем аренды питания ЦП от облачных серверов».

Как указали люди, вы можете вызвать хеш-коллизию с git, но это не приведет к перезаписи существующих объектов в другом хранилище. Я думаю, что даже git push -f --no-thinне будет перезаписывать существующие объекты, но не уверен на 100%.

Тем не менее, если вы взломать удаленный репозиторий , то вы можете сделать ваш ложный объект старше одного там , возможно встраивание взломанный код в исходный проект с открытым на GitHub или аналогичный. Если вы были осторожны, возможно, вы могли бы представить взломанную версию, которую загружали новые пользователи.

Однако я подозреваю, что многие вещи, которые могут сделать разработчики проекта, могут либо разоблачить, либо случайно уничтожить ваш взломанный многомиллионный взлом. В частности, это огромные деньги, если какой-то разработчик, которого вы не взломали, когда-либо запускает вышеупомянутое git push --no-thinпосле изменения созданных файлов, иногда даже без --no-thinзависимости.

Джефф Берджес
источник