smimesign VS opentimestamps-client

I believe GitHub's smimesign can use RFC3161 timestamps:

How to specify a timestamp server

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

smimesign supports timestamping with a normal timestamp server, with a bit of extra effort. It would be cool if your tool could (at least optionally) do the same.

https://github.com/github/smimesign/issues/47#issuecomment-4...

OpenTimeStamp-client v0.7.1 (Released: 26th August 2022) - https://github.com/opentimestamps/opentimestamps-client/releases

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.