-
I've happily been using git-secret (https://sobolevn.me/git-secret/) for encrypting non-critical (i.e. non-production) secrets for a while now. It sounds like Gittuf will do a lot more than git-secret, but for the use case of encrypted files specifically, is there a significant different about with the approach that Gittuf has taken?
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
It's multi-pronged and I imagine adopters may use a subset of features. Broadly, I think folks are going to be interested in a) branch/tag/reference protection rules, b) file protection rules (monorepo or otherwise, though monorepos do pose a very apt usecase for gittuf), and c) general key management for those who primarily care about Git signing.
For those who care about a and b, I think the work we want to do to support [in-toto attestations](https://github.com/in-toto/attestation) for [SLSA's upcoming source track](https://github.com/slsa-framework/slsa/issues/956) could be very interesting as well.
-
It's multi-pronged and I imagine adopters may use a subset of features. Broadly, I think folks are going to be interested in a) branch/tag/reference protection rules, b) file protection rules (monorepo or otherwise, though monorepos do pose a very apt usecase for gittuf), and c) general key management for those who primarily care about Git signing.
For those who care about a and b, I think the work we want to do to support [in-toto attestations](https://github.com/in-toto/attestation) for [SLSA's upcoming source track](https://github.com/slsa-framework/slsa/issues/956) could be very interesting as well.
-
> 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
-
Hey Will, thanks!
The paper is from quite a few years ago now and the reference is for a subset of gittuf's threat model, specifically the metadata manipulation / reference state attacks. The paper talks about MITM as one way to carry out a ref state attack, but if you're communicating with a compromised repository, you can be a victim of such an attack even if you're using authenticated transport and using signed commits / tags that you have a way of verifying.
We do have a threat model for gittuf that we've been meaning to add [0] to the design doc. I'll try and get that done today. It should probably be in there before we tag our alpha release. :)
[0] https://github.com/gittuf/gittuf/issues/95
