Подписание коммитов в приватном репозитории Git

Линус упомянул в 2009 году, что “подпись каждого коммита – это совершенно глупо”.

С тех пор общая точка зрения по этому вопросу изменилась? Разве это не защищает от того, чтобы кто-то узурпировал вашу личность, чтобы сделать коммит в вашем git-репозитории?

Спасибо

Это по-прежнему в целом бессмысленно.

Подпись коммитов позволяет проверить, был ли коммит подписан определённым ключом. В свою очередь, это позволяет сделать вывод о том, был ли коммит создан конкретным человеком. Это может иметь значение, например, если человек A публикует коммит, подписанный человеком B. Но это полезно только на социальном уровне.

Это не влияет на безопасность самого git-репозитория.

• Целостность уже обеспечивается благодаря структуре дерева Меркла типа блокчейна в Git. Если я знаю, что коммит dd71cae49e1ba0e09034ecca51b0d3ceb44280eb существует, Git может проверить целостность этого коммита и всей истории, ведущей к этому коммиту.
• Git-серверы обычно имеют контроль доступа, который ограничивает, кто может отправлять изменения на сервер. Этот контроль доступа совершенно не связан с подписями коммитов. Git также может работать совершенно без нескольких людей, имеющих доступ на отправку в один и тот же репозиторий – его децентрализованный дизайн позволяет людям публиковать свои собственные репозитории, из которых другие могут извлекать.

Некоторые веб-интерфейсы Git, такие как GitHub, без критики принимают метаданные коммита и связывают коммит с аккаунтом. Например, это позволяет всем создавать неподписанные мем-коммиты, которые GitHub связывает с аккаунтом Линуса Торвальдса.

Но что это значит?

• Что Git небезопасен? Абсолютно нет.
• Что GitHub небезопасен? Для некоторых определений безопасности, возможно.
• Что GitHub не четко передает надежность данных, которые они отображают в веб-интерфейсе? Да, это более уместная точка зрения. Из-за этого GitHub ввел режим бдительности. Если бы Торвальдс включил режим бдительности на своем аккаунте, другие люди увидели бы значок “непроверенный” для неподписанных коммитов, созданных от его имени – или созданных им самим, которые он не стал подписывать.

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

• Если я загружаю исходный код Linux с https://github.com/torvalds/linux и доверяю GitHub, мне не важно, подписаны коммиты или нет.
• Если я загружаю git-репозиторий Linux с сомнительного сайта, но Линус Торвальдс говорит мне через надежный канал, что он автор коммита 8bb7eca972ad531c9b149c0a51ab43a417385813, я могу проверить, что этот коммит и все коммиты и файлы, доступные из этой отправной точки, идентичны тем, что сам Торвальдс видел.
• Если я загружаю git-репозиторий Linux с сомнительного сайта, и Линус Торвальдс подписывает все свои коммиты, и я знаю его открытый ключ, который он использует для этих подписей, то я также могу подтвердить, что его коммиты не были изменены. Но это не сильно проще, чем в предыдущих сценариях.

Где подписи действительно играют роль, так это не для обеспечения целостности репозитория, а как доказательство личности автора или коммиттера. Участие в проекте имеет юридические последствия в отношении авторского права, или проект может требовать проверки определёнными людьми. Проект Linux использует строку Signed-off-by в сообщениях коммитов, которая работает на основе доверия. Также было бы возможно использовать подписанные коммиты, но это потребовало бы (a) способа добавить больше подписей к коммиту без изменения хэш-идентификатора коммита,¹ и (b) легкого способа узнать, у кого какой открытый ключ. Запуск инфраструктуры открытых ключей, которая работает для обычных людей, является довольно сложной задачей, при этом распространенные ориентированные на потребителей решения, такие как мессенджер Signal, в значительной степени полагаются на “доверие при первом использовании”, лишь показывая неявное предупреждение, когда ключ меняется. Сообщество GPG пыталось создать веб доверия через личные вечеринки подписания ключей, но ценность таких проверок сомнительна.

^{1. Может быть последовательность коммитов A → B → C, где A – это HEAD-коммит, который ссылается на другие коммиты. Все коммиты подписаны. Я хочу добавить подпись к коммиту C. Это создаст другой коммит C’, который будет иметь другой хэш для C, так что он не будет частью истории, на которую ссылается A. Я могу выполнить rebase и записать новую историю A' → B' → C', но теперь подписи на A и B уже не будут применимы. Поэтому работа с подписанными коммитами может быть сложной и нарушать некоторые рабочие процессы. Другой дизайн для подписей может сработать, например, если подписи записаны в отдельных объектах, так что я мог бы создать историю Signature(A,B,C) → A → B → C.}

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