How can I use RFC3161 (trusted) timestamps to prove the age of commits in my Git repository?

Question

Updated

I have posted a script I\'m using for this to the StackExchange Code Review site.

My original question for this was Is there a way I can sign a

Answer 1

All you have to do, is publish the SHA1 (the commit id) publicly. If you like, you can take that SHA1 and sign it with your X.509 certificate (using an appropriate timestamping service) and keep that around. If anybody challenges your authorship, you can easily show that you knew the contents of the repository at the particular time that generated that particular SHA1. You don't need to actually store any signature inside the code repository.

Answer 2

Simply add a time stamped certificate to your latest commit. The sha1 will verify that the certificate hasn't been modified, and the certificate itself will verify all those 'facts' that it claims, such as the date and time stamp from a trusted server, and who you claim to be, etc. That is, the commit signs the certificate, as per VonC's quote from Linus's speech ;-)

---

[EDIT] Obviously you do need to publish the sha1 of that new commit, otherwise you could amend it (and the certificate) and use the new sha1 to claim whatever is in that new commit's history. As always it is creating the web of mutual trust.

Answer 3

I am not usre I follow, because Linus did make Git with that specific feature in mind (ie the integrity of what you are putting in is exactly what comes out)

See is 2007 speech at Google (transcript):

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. .

So I don't think adding another integrity feature will add any value.
And the "timestamp" isn't exactly a good idea either, since they aren't recorded for a DVCS in the first place (see "Git: checking out old file WITH original create/modified timestamps", and "What's the equivalent of use-commit-times for git?")

Answer 4

I just wrote a program called "GitLock" exactly for this purpose. It adds trusted timestamps to your repo.

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