Как я могу использовать метки времени RFC3161 (доверенные) для подтверждения возраста коммитов в моем репозитории Git?

Обновлено

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

Мой первоначальный вопрос для этого был: Есть ли способ подписать фиксацию Git с помощью сертификата X.509 и отметки времени?. Некоторое время я думал, что могу получить только то, что подписал с помощью сертификата X.509 с отметкой времени доверенной третьей стороны. Это не тот случай. Цифровая подпись с сертификатом X.509 и доверенная отметка времени являются взаимоисключающими. Я обновил свой вопрос, чтобы отразить это.

Как указывает VonC, подписание Git-коммитов сертификатом X.509 не добавляет никакой ценности. Использование ключа GPG - гораздо лучший вариант из-за встроенной поддержки Git.

Я принял ответ Грега, потому что он ближе всего к тому, о чем я просил, хотя мой первоначальный вопрос был немного двусмысленным. Как указывает Грег, если вы можете доказать, что вы знали хэш фиксации в определенный момент времени, это гарантирует, что вы знали содержимое репозитория, для которого этот хэш предназначен в то время, и нет необходимости хранить какие-либо дополнительные данные в репозитории. Данные отметки времени можно хранить где угодно.

Можно использовать openssl (v1.0.0 +) и curl для запроса меток времени RFC3161 для хэшей фиксации.

Запросить отметку времени

Для этого вам понадобится немного информации:

  • URL - служба отметок времени RFC3161
  • REV - версия (хэш), для которой требуется временная метка. Должен быть полный хеш.
CONTENT_TYPE="Content-Type: application/timestamp-query"
ACCEPT_TYPE="Accept: application/timestamp-reply"

openssl ts -query -cert -digest "$REV" -sha1 \
    | curl -s -H "$CONTENT_TYPE" -H "$ACCEPT_TYPE" --data-binary @- $URL

Вышеупомянутая метка времени будет выведена в stdout. Он также может выдать ошибку, если служба отметок времени отклонит запрос.

Проверить отметку времени

Это очень похоже на запрос отметки времени, но вам также потребуются:

  • CAFILE - цепочка сертификатов от службы отметок времени до корневого центра сертификации.

Служба отметок времени должна подписывать отметки времени с помощью сертификата, выданного доверенным центром. В противном случае ваши временные метки не вызывают особого доверия. Если вы не можете найти или создать правильную цепочку сертификатов, попробуйте использовать cacert.pem, опубликованный curl. Это здесь.

В приведенном ниже фрагменте предполагается, что существующий ответ с отметкой времени с подписью передается stdin. Должна быть возможность направить вышеуказанный запрос напрямую в приведенную ниже команду verify. Если вы сохраняете ответ на запрос в переменной, может потребоваться его кодирование / декодирование base64 (man base64).

openssl ts -verify -digest "$REV" -in /dev/stdin -CAfile "$CAFILE"

Если вы изучите ответ, вы заметите, что дайджест запроса совпадает с используемой ревизией Git. Вы можете проверить текстовую версию ответа с помощью этой команды.

openssl ts -reply -in /dev/stdin -text

Вот пример ответа, в котором я добавил версию Git вверху.

--------------------------------------------------------------------------------
Revision: 871d715e5c072b1fbfacecc986f678214fa0b585
--------------------------------------------------------------------------------
Status info:
Status: Granted.
Status description: unspecified
Failure info: unspecified

TST info:
Version: 1
Policy OID: 1.3.6.1.4.1.6449.2.1.1
Hash Algorithm: sha1
Message data:
    0000 - 87 1d 71 5e 5c 07 2b 1f-bf ac ec c9 86 f6 78 21   ..q^\.+.......x!
    0010 - 4f a0 b5 85                                       O...
Serial number: 0xB2EA9485C1AFF55C6FFEDC0491F257C8393DB5DC
Time stamp: Aug 15 08:41:48 2012 GMT
Accuracy: unspecified
Ordering: no
Nonce: 0x615F0BF6FCBBFE23
TSA: DirName:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO Time Stamping Signer
Extensions:

Прочие примечания

Многие службы отметки времени просят пользователей добавить задержку к скриптовым запросам подписи. Убедитесь, что вы узнали, требует ли этого услуга, которую вы планируете использовать. Во время написания того, что я использую, Comodo, запрашивает 15-секундную задержку между скриптовыми запросами. Единственная причина, по которой я решил использовать Comodo, - это то, что у него я купил свой сертификат подписи кода.

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

Мой исходный вопрос и обновления приведены ниже.


Я хотел бы доказать, когда мои коммиты Git происходят и что история моего репозитория не переписывалась. Это не обязательно должно быть каждое коммит. Раз в день или раз в неделю будет достаточно. Есть ли рекомендуемый способ сделать это?

Я знаю, что могу подписывать коммиты Git с помощью ключа GPG, но мне интересно, есть ли способ подписать свои коммиты с помощью сертификата X.509 и использования онлайн-службы отметки времени, такой как http://timestamp.comodoca.com/rfc3161.

Если нет, будет ли достаточно сбросить текущую ревизию с использованием git rev-parse --verify HEAD в текстовый файл один раз в день, подписать этот файл и зафиксировать, чтобы доказать (примерно), когда был написан мой код?

Добавлена ​​информация для ясности

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

Вот вымышленные варианты использования, которые должны дать лучшее представление о том, чем я хочу заниматься.

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

Используя сертификат X.509 со службой отметки времени, я могу доказать, когда было подписано. Пока я могу доказать, что знаю хэш для коммита годичной давности, Git гарантирует целостность архива.

В качестве альтернативы, есть ли способ подписать фиксацию с помощью ключа GPG, но с проверенной меткой времени? Есть ли доверенная третья сторона, которая предоставляет услугу отметки времени, аналогичную тем, которые доступны для сертификатов X.509, но для GPG?

Возможно, я мог бы использовать комбинацию ключа GPG и сертификата X.509. Предполагая, что я храню копию своего (общедоступного) ключа GPG в репозитории, будет ли работать следующее, если я буду делать это в конце каждого дня?

  1. Подпишите мой (публичный) ключ GPG, используя мой сертификат X.509 и онлайн-службу отметок времени.
  2. Зафиксируйте изменение в репозитории с подписью моего (частного) ключа GPG.

person Ryan J    schedule 11.08.2012    source источник
comment
В чем смысл? Пока никто не вмешивается в локальное репо на вашем компьютере, целостность истории гарантирована. Даже если вы получите изменения от кого-то, кто переписал историю, изменения не будут объединены автоматически, и обе копии истории останутся в репо. Если вам нужна одна окончательная копия репо без перезаписанной истории, вы можете попросить всех отправить свою работу куда-нибудь на сервер, который отклоняет принудительные нажатия или что-то в этом роде ...   -  person Robert Rouhani    schedule 11.08.2012
comment
Я хотел бы доказать другим, что я не переписывал историю репозитория.   -  person Ryan J    schedule 11.08.2012
comment
Просто позвольте им периодически вытаскивать ваше репо. Если переписать историю, sha1 изменится, они это узнают.   -  person kan    schedule 11.08.2012
comment
@kan может понадобиться доказать властям в какой-то момент в будущем, что коммиты существовали в определенный момент времени и не были переписаны позже - например, во время аудита. Так что позволять им периодически вытаскивать ваше репо - не решение. хранение токенов временных меток доверенного TSA для хэшей коммитов кажется правильным способом сделать это, вопрос в том, какой способ сделать это наиболее элегантно   -  person matthias_buehlmann    schedule 03.02.2021
comment
@matthias_buehlmann Если мы доверяем аудиторам, то их обязанность - отслеживать и отслеживать то, что было извлечено, а затем. Если нет, то помогает TSA.   -  person kan    schedule 04.02.2021
comment
@kan это аудиторы будущего - они могут даже не существовать в то время, когда вы создаете коммит   -  person matthias_buehlmann    schedule 04.02.2021


Ответы (5)


Все, что вам нужно сделать, это опубликовать SHA1 (идентификатор фиксации) публично. Если хотите, вы можете взять этот SHA1 и подписать его своим сертификатом X.509 (используя соответствующую службу меток времени) и оставить его при себе. Если кто-то оспорит ваше авторство, вы можете легко показать, что вы знали содержимое репозитория в тот конкретный момент, когда был сгенерирован этот конкретный SHA1. На самом деле вам не нужно хранить какую-либо подпись внутри репозитория кода.

person Greg Hewgill    schedule 17.08.2012
comment
это действительно зависит от политики, установленной организацией, которой это нужно доказать. Сущность могла указать, что данные должны иметь временную метку, используя конкретную службу TSA. В этом случае хэш фиксации SHA1 может быть помечен меткой времени, запросив для него токен RFC3161 (нет необходимости дополнительно подписывать его с помощью сертификата X.509, метка времени подписывается доверенным сертификатом TSA). Однако также необходимо проверить, принимают ли используемые политики SHA1 в качестве безопасного алгоритма хеширования для доказательств. В противном случае нельзя полагаться на хеш фиксации (или использовать репо --object-type = sha256) - person matthias_buehlmann; 22.02.2021

Просто добавьте сертификат с отметкой времени к последней фиксации. Sha1 проверит, что сертификат не был изменен, а сам сертификат проверит все те «факты», которые он утверждает, такие как отметка даты и времени с доверенного сервера, и кем вы себя называете и т. Д. есть, коммит подписывает сертификат, согласно цитате VonC из речи Линуса ;-)


[РЕДАКТИРОВАТЬ] Очевидно, вам действительно нужно опубликовать sha1 этого нового коммита, иначе вы можете изменить его (и сертификат) и использовать новый sha1 для утверждения всего, что есть в истории этого нового коммита. Как всегда, он создает паутину взаимного доверия.

person Philip Oakley    schedule 11.08.2012
comment
публикация хэша не требуется, если он имеет отметку времени (также не требуется подпись с использованием сертификата). Доверенная временная метка доказывает всем, кто доверяет TSA, что хэш (и, следовательно, фиксация со всеми его данными и историей) существовал в то время, которое было сертифицировано в метке времени. - person matthias_buehlmann; 22.02.2021
comment
@matthias_buehlmann, но для пояснения, ключ состоит в том, чтобы выбрать, какой из двух «хешей» (фиксация или отметка времени) является ссылочным элементом, а какой - вторичным контентом, содержащимся в ссылочном элементе. Либо отметка времени удостоверяет фиксацию, либо фиксация удостоверяет отметку времени. Затем вы «публикуете» ссылку, чтобы другие знали и доверяли им. - person Philip Oakley; 24.02.2021

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

См. выступление 2007 г. в Google (transcript):

От большинства из них я мог отказаться, даже не пробуя их.

  • Если вас не распространяют, вас не стоит использовать, это так просто.
  • Если вы плохо справляетесь, вас не стоит использовать, это так просто.
  • И если вы не можете гарантировать, что все, что я вложил в SCM, будет точно таким же, вам не стоит использовать.

Откровенно говоря, это почти позаботилось обо всем на свете.

Существует множество систем SCM, которые не гарантируют, что то, что вы снова получите, будет тем же самым, что и вы вставили.
Если у вас есть повреждение памяти, если у вас есть повреждение диска, вы, возможно, никогда не узнаете. < br> Единственный способ узнать об этом - это заметить, что файлы повреждены, когда вы их просматриваете. А система управления версиями вас совсем не защищает.
И это даже не редкость. Это очень часто. .

Поэтому я не думаю, что добавление еще одной функции целостности принесет какую-либо пользу.
И «временная метка» тоже не совсем хорошая идея, поскольку они не записываются для DVCS в первое место (см. «Git: проверка старого файла С оригинальные временные метки создания / изменения "и" Что эквивалент use-commit-times для git? ")

person VonC    schedule 11.08.2012
comment
Я доверяю Git в плане целостности, но (в конце концов) я хотел бы позволить кому-нибудь взглянуть на мой (частный) репозиторий и убедиться, что определенному коду X лет. Я обновил вопрос, чтобы было понятнее. - person Ryan J; 13.08.2012
comment
@RyanJ - это не дата автора, связанная с любым новым коммитом? Нет необходимости в новой метке времени: фиксация уже содержит всю необходимую информацию. - person VonC; 13.08.2012
comment
Эта отметка времени не проверяется третьей стороной, не так ли? Я предполагаю, что он сгенерирован локально, поэтому он основан на моем слове, а не на чем-то доказуемом. Использование метки времени от Comodo, Verisign и т. Д. Означает, что третья сторона гарантирует ее точность. Когда я что-то подписываю и ставлю отметку времени своим сертификатом X.509, служба отметок времени центра сертификации отображается как контрподпись. Например, когда я запрашиваю отметку времени у timestamp.comodoca.com/authenticode, контрподпись будет от 1_. - person Ryan J; 13.08.2012
comment
Эта отметка времени не проверяется третьей стороной, не так ли? Правда, эта проблема не решается никакими DVCS из-за их распределенного характера и отсутствия гарантии доступа к конкретной сторонней службе при выполнении фиксации (т.е. сам инструмент git не может предоставить эту функцию) . - person VonC; 13.08.2012
comment
Предполагая, что я могу проверить файл с отметкой времени и проверить его независимо от Git, гарантирует ли Git целостность каждого коммита до того, которое я проверил? Другими словами, представляет ли хеш фиксации целостность всего репозитория или только часть дерева, от которой зависит фиксация? - person Ryan J; 13.08.2012
comment
@RyanJ хеш фиксации представляет собой целостность самого себя, его содержимого и всех его предков. Если мы говорим о фиксации корневого каталога репо, то единичная фиксация SHA1 представляет собой целостность всего репо. Если бы вы добавили в коммит дополнительные данные (в его комментарии), вы не смогли бы изменить эти данные без изменения SHA1. Вы также можете добавить эту информацию позже, используя git notes (alblue.bandlem.com/2011/11/git-tip-of-week-git-notes.html), но у него есть собственный отдельный SHA1, который нужно запомнить (т. е. SHA1 корневого коммита не хватит уже). - person VonC; 13.08.2012
comment
позвольте нам продолжить это обсуждение в чате - person Ryan J; 13.08.2012
comment
В любом случае, надеюсь, это мой последний вопрос. Я ценю вашу помощь и думаю, что почти понимаю, но я не совсем понимаю, что вы подразумеваете под фиксацией корневого каталога репозитория. Что, если я создам осиротевшую ветку с помощью git checkout --orphan MYBRANCH? Могут ли хэши из коммитов на MYBRANCH по-прежнему проверять целостность других веток? Я пытался прочитать это (git-scm.com/book/ch9-2 .html), но это немного не по мне. - person Ryan J; 13.08.2012
comment
@RyanJ true, сиротская ветка представит другой SHA1, независимый от корневого дерева SHA1 (даже если stackoverflow.com/questions/1384325/ предлагает вместо этого создать новое репо;)). - person VonC; 13.08.2012

Я как раз для этого написал программу под названием «GitLock». Он добавляет надежные метки времени в ваше репо.

https://www.npmjs.com/package/gitlock

person Zhenzhen Zhan    schedule 08.06.2016

Я написал статью, в которой подробно описываются временные метки репозитория git с использованием временных меток RFC3161, а также предоставляется ловушка после фиксации, которая автоматически делает это:

https://matthias-buehlmann.medium.com/git-as-cryptographically-tamperproof-file-archive-using-chained-rfc3161-timestamps-ad15836b883

Ключевыми моментами являются следующие:

  1. SHA1, вероятно, больше не следует считать безопасным, особенно если он должен что-то доказать через пару лет (https://sha-mbles.github.io/). Таким образом, рекомендуется инициализировать репозиторий git, используя хеши sha256 git init --object-type=sha256 (даже если поддержка sha256 все еще считается экспериментальной)

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

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

person matthias_buehlmann    schedule 22.02.2021