[_alex_]

if you sign your commits, you should also consider timestamping your commits. I use OpenTimestamps for this. Docs and some rationale here: https://github.com/opentimestamps/opentimestamps-client/blob...

from the doc:

> My signing keys (e.g. blog or Qubes code signing keys) do not have expiration dates. This is not laziness. There is a fundamental problem with using an expiration date on keys used for code signing (e.g. git tag -s), because it is unclear what the outcome should be when one verifies some old code (written and signed when the key was still valid) in the future when the key has already expired?

> Naturally we would like the old code, written and signed when the key was still valid, to continue to verify fine also in the future, after the key expires (and the developer passed away, perhaps). However, it is very problematic to prevent the attacker from creating falsified code pretending to be an old one.

[justsomeadvice0]

Alright I'll bite - why do all this blockchain hoopla instead of just using SMIME/CMS's trusted timestamp feature? That already works fine with git signatures.

[andrewstuart2]

Personally I'm pretty against bitcoin et all for their wastefulness (PoW) or lack of improvement on existing systems (PoS), but I can definitely see trusted timestamps as a valid use of a public ledger. Ironically, since git is implemented as a merkle tree, you could do this quite easily in git as a "blockchain" minus the Proof of *. So, no distributed trust, but I'm personally usually glad to trade a little bit of centralization for a whole lot of performance/efficiency.

[justsomeadvice0]

We are on the same page. I do think there are some gains, although I question the use of "permissionless" blockchains (we have to remember to add this caveat now since we decided 90s tech should now be called "permissioned blockchains"). A simple published ledger ("immutable append-only", like CT logs) seems like a much easier route. If nodes care enough, they can poll it and alert when the tip changes in a way that should not be allowed.

[password4321]

I believe GitHub's smimesign can include RFC3161 timestamps:

How to specify a timestamp server

https://github.com/github/smimesign/issues/47

[justsomeadvice0]

Yep, precisely what I was referring to.

[alfiedotwtf]

Can a non-PoW timestamp server actually be trusted? The thing with open timestamp etc is that it's completely trustless

[justsomeadvice0]

"trustless" is not the word here... you are trusting the economic incentives of the blockchain system to remain in-tact. But I do agree with you that one could feasibly trust it "more" than a single entity protecting a key and acting correctly. However in practice "more" comes with a very very hefty price tag, in my experience one that makes it completely impractical in the real world. Look at the verification requirements:

- run a full bitcoin node, download the full blockchain - wait several hours after the timestamp is produced for the system to publish to blockchain (which also reduces the granularity of the timestamp, within this window the system is only "as secure" as a solution trusting a single entity) - download all the commits in the Merkle tree that was signed and published, and search for the commit you are verifying within the tree

Security in practice is about tradeoffs, and I can't imagine a scenario wherein these tradeoffs would work for me without ultimately having a centralized provider verify them for me, at which point I just have complexity with no gain over the traditional trusted timestamps.

[smileybarry]

Yes, because it's very small list of companies that have trusted timestamp servers and follow a strict set of rules re: key storage, rotation, issuance, etc.

[justsomeadvice0]

TBH this is a good argument not to trust timestamp servers. AFAIK usually you just want to stick to one, and not treat a group of them interchangeably (ala the Internet Root Bundle). In any case, the owners of the repo (or email message) would decide for themselves which one(s) they want to trust.

[smileybarry]

We do use just a specific one at work. My point was that it's a highly secured process limited to just a few companies, and becoming one is a lot of effort, if at all possible. There are even some RFC3161 servers just not trusted by Windows, ergo: useless for most timestamping uses.

[michaelt]

As much as you can trust SSL certificates and code-signing certificates.

[alfiedotwtf]

Signing will say who signed it, but it cannot say when they signed it.

[waynesonfire]

is it just me or is the opentimestamp thing poorly described in that after reading the how it works section I still have no idea wtf this thing is doing?

bitcoin.

merkle tree.

and some third party calendar server.

It's fine maybe this thing is so complicated that I'm not allowed to understand it. And if it's so complicated that it can't even be explained in a high level way, I don't want to use it.