Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes: > Anton Wuerfel venit, vidit, dixit 07.03.2016 15:15: >> Hello, >> >> as part of an university project we plan to implement time stamp >> signatures according to RFC 3161. This enables users to create and verify >> cryptographic time stamp signatures to prove that a commit existed at a >> certain point in time. > > Before talking about a specific header format (and, possibly, repeating > mistakes of the past) we should take a step back to exactly here: What > is the goal that you are trying to achieve? > > "prove that a commit existed at a certain point in time" is a good > definition for that goal. Moving the timestamp signature out of line has merits and demerits. - Inline timestamp signature proves that the commit existed at a certain point in time, and also it proves that any descendant commit was not there before that time. Also, the object name of the signed object itself protects the fact that it was created with the signature (i.e. if you replace the signature, its object name would change)--this can be a feature or inconvenience, depending on your use case. - Out of line timestamp signature allows you to say "I didn't bother timestamping that commit I made 5 days ago, and it now is buried 200 commits deep in the history from the tip, but I am asking a timestamping service that the commit existed as of now--I cannot go back and prove that it actually was made 5 days ago, but at least the timestamp proves it was there today". It does not allow you to say anything about descendant commits, though, like an inline timestamp would. There is a convenience argument, too, for and against inline vs out of line signatures. - The original "signed tag" is a good out-of-line signature mechanism that you can add signed attestation to a different object (i.e. you made a commit either 2 seconds or 5 days ago, and then you certify that you would want to call that with a tagname with some messages and cryptgraphically sign that retroactively). Being in the ref namespace, it didn't scale for use cases where you would want to have as many signatures as you would have commits, though. - The "signed commit" is made in-line, and for those who want to always validate each and every commit, not having to maintain a separate collection of signatures was a convenience. - The "merge signed tags" is also made in-line, primarily for convenience benefit, i.e. not having to keep collection of all pull request tags out of line. I haven't thought deeply enough between in-line and out-of-line which would suit better for timestamp signatures, though. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html