Вопрос по rfc3161, x509certificate, trusted-timestamp, git – Как я могу использовать RFC3161 (доверенные) временные метки для подтверждения возраста коммитов в моем Git-репозитории?

18
Updated

я имеюопубликовал скрипт Я использую это для сайта проверки кода StackExchange.

Мой оригинальный вопрос для этого былIs there a way I can sign a Git commit with an X.509 certificate and timestamp?, Некоторое время я думал, что смогу получить только те вещи, которые я подписал с помощью своего сертификата X.509, с отметкой времени от доверенной третьей стороны. Это не вариант. Цифровая подпись с сертификатом X.509 и надежной отметкой времени являются взаимоисключающими. Я обновил свой вопрос, чтобы отразить это.

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

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

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

Request A Timestamp

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

URL - An RFC3161 time-stamping service REV - The revision (hash) you want a timstamp for. Must be a full hash.
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, Он также может выдать ошибку, если служба отметок времени отклонит запрос.

Verify A Timestamp

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

CAFILE - A certificate chain from the timestamp service back to a root CA

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

В приведенном ниже фрагменте предполагается, что существующий подписанный ответ с отметкой времени передаетсяstdin, Должна быть возможность направить указанный выше запрос непосредственно в приведенную ниже команду проверки. Если вы сохраняете ответ на запрос в переменной, может потребоваться закодировать / декодировать 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:
Other Notes

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

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

Мой оригинальный вопрос и обновления ниже.

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

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

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

Added Info For Clarity

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

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

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

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

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

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

Sign my (public) GPG key using my X.509 certificate and an online time-stamping service. Commit the change to the repository with a signature from my (private) GPG key.
Я хотел бы быть в состоянии доказать другим, что я не переписывал историю хранилища. Ryan J
Какой смысл? Пока никто не возится с локальным репо на вашем компьютере, целостность истории гарантирована. Даже если вы извлекаете изменения у кого-то, кто переписал историю, изменения не будут объединены автоматически, и обе копии истории останутся в репо. Если вам нужна одна точная копия репо без переписанной истории, вы можете попросить всех перенести свою работу на сервер где-нибудь, который отклоняет принудительные толчки или что-то в этом роде ... Robert Rouhani
Просто позвольте им периодически вытягивать ваш репо. Если переписать историю, sha1 изменится, они это узнают. kan

Ваш Ответ

4   ответа
8

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

3

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

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

1

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

Видеть этоРечь 2007 года в Google (расшифровка):

Most of them I could discard without even trying them out.

If you're not distributed, you are not worth using, it's that simple. If you perform badly, you are not worth using, it is that simple. And if you cannot guarantee that the stuff I put into an SCM comes out exactly the same, you are not worth using.

Quite frankly, that pretty much took care of everything out there.

There are a lot of SCM systems that do not guarantee that what you get out of it again is the same thing you put in.
If you have a memory corruption, if you have a disc corruption, you may never know.
The only way you know is you notice that there is corruption in the files when you check them out. And the source control management system does not protect you at all.
And this is not even uncommon. It is very very common. .

Поэтому я не думаю, что добавлениеanother Функция целостности добавит любую ценность.
И & quot; отметка времени & quot; тоже не очень хорошая идея, так как они не записаны для DVCS в первую очередь (см. & quot;Git: проверка старого файла с оригинальными временными метками создания / изменения& quot; и & quot;Что эквивалентно времени использования-коммитов для git?& Quot;)

@RyanJ - это не то, что «дата автора» связано с любым новым коммитом для? Нет необходимости в новой отметке времени: коммит уже содержит всю необходимую вам информацию.
То, что отметка времени не проверена третьей стороной, не так ли? Я предполагаю, что оно генерируется локально, поэтому оно основано на моем слове, а не на чем-то доказуемом. Использование метки времени, полученной от Comodo, Verisign и т. Д., Означает, что третье лицо гарантировало ее точность. Когда я подписываю и ставлю отметку времени с помощью своего сертификата X.509, центры сертификации & apos; служба отметок времени отображается в виде контрподписи. Например, когда я запрашиваю отметку времени уtimestamp.comodoca.com/authenticodeконтрподпись отCOMODO Time Stamping Signer. Ryan J
"Эта отметка времени не проверена третьей стороной, не так ли?" Правда, это будет проблемой, которая не решается ни одной DVCS из-за их распределенного характера и отсутствия гарантии доступа к конкретной сторонней службе при выполнении фиксации (т. Е. Инструментаgit Сам не может предоставить эту функцию).
Я доверяю Git за целостность, но (в конце концов) я хотел бы иметь возможность позволить кому-нибудь взглянуть на мой (частный) репозиторий и убедиться, что определенному коду уже исполнилось X лет. Я обновил вопрос, чтобы сделать его более понятным. Ryan J
Предполагая, что я могу проверить файл с отметкой времени и проверить его независимо от Git, гарантирует ли Git целостность каждого коммита до того, как я его проверил? Другими словами, представляет ли хеш коммита целостность всего хранилища или только часть дерева, от которой зависит фиксация? Ryan J
0

GitLock& Quot; именно для этого. Это добавляет доверенные временные метки к вашему репо.

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

Похожие вопросы