gitsign VS opentimestamps-client

> does it also filter/escape ANSI Sequences in messages and author names?

Not at present! Do you have a link or so I could use to familiarize myself? I'm curious if it'd fall within gittuf's scope.

> does it block garbage collection?

Nope, it doesn't. That said, the repository will have more objects, gittuf tracks additional objects through custom refs in `refs/gittuf/`.

> how do you ensure that the developers are really the developers and there's no spoofing?

At present, gittuf policies use signing keys. It doesn't rely on the commit metadata for author and committer but rather the commit's signature. We support GPG and Sigstore's gitsign [0] right now, and we want to support other signing mechanisms like SSH keys as well.

[0] https://github.com/sigstore/gitsign

You may want to check out https://github.com/sigstore/gitsign! You can generate ephemeral x509 code signing certs for free using Sigstore.

(disclosure: I'm a maintainer for gitsign)

Def check out the gitsign project mentioned in the post: https://github.com/sigstore/gitsign

Gitsign offers a keyless commit signing implementation based on OIDC, which is an identity layer built on top of the OAuth 2.0 framework. Gitsign supports verifying your identity either through GitHub, Microsoft, or a Google account.

Shameless plug for the gitsign project in sigstore: https://github.com/sigstore/gitsign

This isn't supported by GitHub yet but we're hopefully working towards that too.

We used to actually run an RFC3161 timestamp server in addition to the transparency log but recently turned it down because no one was using it. I'd like to bring it back for stuff like this.

https://github.com/sigstore/gitsign/issues/22

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.