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

Я провел эксперимент, чтобы выяснить, как именно 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. Если большой двоичный объект с таким же хешем уже существует, вы вообще не получите никаких предупреждений. Кажется, все в порядке, но если вы нажмете кнопку, кто-то клонирует или вернетесь назад, вы потеряете последнюю версию (в соответствии с тем, что описано выше).
2. Если объект дерева уже существует и вы создаете blob-объект с тем же хешем: все будет казаться нормальным, пока вы не попытаетесь отправить или кто-то клонирует ваш репозиторий. Тогда вы увидите, что репо повреждено.
3. Если объект фиксации уже существует, и вы создаете большой двоичный объект с тем же хешем: то же, что и # 2 - поврежден
4. Если большой двоичный объект уже существует, и вы создаете объект фиксации с тем же хешем, при обновлении «ref» произойдет сбой.
5. Если большой двоичный объект уже существует, и вы создаете объект дерева с тем же хешем. Это не удастся при создании фиксации.
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

or:

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 в порядке, так как он будет остановлен с ошибкой. Полагаю, было бы лучше, если бы он не сработал с ошибкой, по крайней мере, во всех случаях.

Исходный ответ (2012 г.) (см. shattered.io Конфликт SHA1 2017 г. ниже)

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

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

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

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

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

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

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