Можно ли доверять хэшу коммита git?

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

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

У меня вопрос: при новой загрузке исходного кода могу ли я быть уверен, что если я проверю конкретную фиксацию на основе ее полного хэша фиксации, это будет на 100% тот же код, который я просматривал ранее?

Основное внимание в этом вопросе уделяется не вероятности возникновения коллизий sha1 (поскольку коллизию намного проще вычислить, чем вычисление конкретного хэша sha1, что, надеюсь, в значительной степени невозможно в данный момент?), но каждый и каждый файл является частью этой суммы sha1, так что изменение всегда будет вызывать другой хэш.


git git-hash
person Zulakis    schedule 22.02.2016    source источник

Ответы (2)


arrow_upward
5
arrow_downward

короче: да.

на этой странице вы можете увидеть, как формируется эта сумма sha1. Он состоит из:

  • Исходное дерево коммита (которое раскрывается на все поддеревья и большие двоичные объекты)
  • Родительский коммит sha1
  • Информация об авторе
  • Информация о коммиттере (правильно, они разные!)
  • Сообщение фиксации

Таким образом, каждое изменение в каждом файле учитывается при расчете sha1sum. Насколько я знаю, вы можете быть уверены, что любое изменение в любом файле в каждом случае будет давать разную сумму sha1.

EDIT: я начал работать над одним из своих коммитов:

git cat-file commit HEAD

дает:

tree 563ccb5109fbf0a01d99517ca1dbe15db349592d
parent 3c6f0800708aeaaeaba804273406ddcd0b3175ad
...

теперь git cat-file -p 563ccb5109fbf0a01d99517ca1dbe15db349592d:

100644 blob d8fe4fa70f618843e9ab2df67167b49565c71f25    .gitignore
100644 blob dba1ba3a31837debf7a28eceb194e86916b88cbc    README
040000 tree 37ad71e959c6dadd0e4b7aff8a0c6e85a0eff789    conf
040000 tree 60eca667ab8b5852ecd2dd2d91d198a3956a8b73    etc
040000 tree 634c4c2ec34aec14142b5991bd3a5126110f2cae    sbin
040000 tree 256db03954535d25d5f340603e707207170f199c    spec
040000 tree 9e1e156f88b842da471f52d4c135f391319b4991    usr

а я могу продолжить глубже :git cat-file -p d8fe4fa70f618843e9ab2df67167b49565c71f25:

/.project

(это содержимое моего файла .gitignore) или git cat-file -p 256db03954535d25d5f340603e707207170f199c:

100644 blob 591367a913adbeb1c86d674d240fb08ab8ccf78b    base.spec

(что является содержимым моего каталога "spec").

так что, как вы можете видеть, содержимое каждого файла рекурсивно присутствует в сумме sha1 файла; затем в сумме sha1 исходного дерева и, наконец, в сумме sha1 коммита.

person Chris Maes    schedule 22.02.2016
comment
Спасибо! Можете ли вы привести пример, как генерировать (файловые) хэши, которые вы используете с git cat-file -p, из содержимого файла? Они не кажутся sha1sum файла. - person Zulakis; 22.02.2016
comment
обратите внимание на ответ @ChrisMartin: поскольку вы сказали, что не хотите учитывать вероятность столкновения, ответ ДА, насколько я понимаю. Как указывает КрисМартин; эта возможность все еще существует, поэтому нет надежной гарантии, что столкновения никогда не произойдет. - person Chris Maes; 22.02.2016
comment
Документы не были полностью прозрачными в этом вопросе, но я предполагаю, что хэш, который возвращает git hash-object <filename>, представляет собой sha1sum, выполненный по всему содержимому файла + что-то еще? (Как бы я воспроизвел это вручную?) О столкновении: исходя из того, что мы знаем, я бы предположил, что найти совпадающее столкновение возможно, но это не было сделано и потребовало бы абсурдных (сегодняшних) вычислительных мощностей - верно? Я знаю, что хеш — это не безопасность, а функция целостности, но в отсутствие экспертной проверки, я полагаю, злоупотребление функцией целостности commit-hash, вероятно, лучший способ. - person Zulakis; 22.02.2016
comment
вы можете увидеть в этом ответе: stackoverflow.com/a/7225329/2082964, как воссоздать это с помощью shasum - person Chris Maes; 22.02.2016
comment
будьте осторожны с подмодулями. если в репозитории есть подмодуль, отслеживающий ветку, код этого подмодуля может измениться без изменения хэша родительского репо git commit. поэтому использование хэша фиксации безопасно, если вы подтверждаете, что нет подмодулей, отслеживающих ветку, и вы не небрежны с такими вещами, как git clone --recursive - person JDiMatteo; 24.10.2017

arrow_upward
0
arrow_downward

Git хеширует все, так что на ваш заголовок и итоговый вопрос: да.

коллизию намного проще вычислить, чем вычислить конкретный хэш sha1, что, надеюсь, практически невозможно на данный момент?

Правильно по обоим пунктам. Вы даже можете потерять часть «в значительной степени», ответ на вопрос «можно ли создать сообщение с заданным хэш-кодом SHA1» будет правильным «смеется, нет».

person jthill    schedule 23.02.2016