Gittuf – a security layer for Git(gittuf.github.io)
gittuf.github.io
Gittuf – a security layer for Git
https://gittuf.github.io/
23 comments
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
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
I’m one of the maintainers of gittuf, happy to answer questions!
I've happily been using git-secret (https://sobolevn.me/git-secret/) for encrypting and committing 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, are there any significant differences in the approach that Gittuf has taken?
At present, gittuf's access control policies are centered around _write_ permissions rather than _read_. That said, we want to re-use some of the same policy semantics to build _read_ permissions too. So, you'd use the same mechanism in the policy to determine who can read an object, by their signing key to share the key used to encrypt the secret. We've looked at git-secret, git-crypt, etc. a little and we'd like to integrate with existing tools where possible rather than build anew. With the alpha release coming up soon, we ought to have more time to develop the read permissions side of gittuf.
I notice a lot of warnings about it being experimental. Do you know what is the timeline where the goal is to have it more mature? It's going to be hard to sell my team on it unless it's available in various Linux distros' package managers, developers' Macs, etc
Our alpha release is this week! We have pretty much everything in place for us to cut the tag and publish the first binaries. The next thing is to kick its tires a bit, we have some test repositories in mind for that. I reckon gittuf should be beta-ready after said tire-kicking for the workflows we're considering in gittuf's design, but we also want to learn more about folks' non-traditional Git workflows. We're always on the lookout for those, so if you have something like that in mind, please let us know!
That sounds awesome, thanks.
We're a gerrit/git-review shop, so I imagine there could be fun interactions between those and gittuf :)
We're a gerrit/git-review shop, so I imagine there could be fun interactions between those and gittuf :)
Yes! We have clean integration with other tools in the Git ecosystem on our roadmap.
In a monorepo situation, can you restrict read access for certain branches/directories, or is it just writes e.g. push/merge. I was under the impression that isn't really possible given how git works but I thought I'd still ask, just in case.
As others have said, read access for refs / directories is a bit more complicated than just embedding a secret in the repository given how Git works. We have more exploring to do but it's possible that this isn't easy to implement without leaking some information about directory structure and so on, especially if someone can access one branch but not another.
Read access can't really be partially restricted in git, because git is content addressed. Without the data you can't construct the sha hash, so there's no way to address a commit at all. You could publish partial data, and you could generate new partial commits for that data, but it would probably not be very useful outside of a very niche use case.
with the sparse checkout/partial clone features there's no particular reason you couldn't enforce partial read access: the way git tree hashes work, if you don't change anything in a subdirectory, the contribution of that hash to the tree doesn't change. So as long as you have the hash of that directory you don't need the contents to construct a new commit. The same is true for files themselves: the main thing that must be known is that if you are a file you must know the contents of it, and the directory listing of all the parent folders up to the root. Everything else you only need to know the hash. This is how sparse checkouts work and still allow commits, and it can be turned into partial read access by only allowing sparse checkout and not allowing the content of those directories to be sent to the client.
Thanks for this excellent explanation. I'm not aware of any software that makes this easy e.g. like gitolite or gitlab but I'm pleased to now realise this isn't because it's not possible! I think there would be a lot of value in someone providing this feature.
That is true! I forgot about that. You need to be able to read metadata, including file names, but not the actual contents as the hash would suffice. That sounds like the start of quite a fun project!
Restricting read access is one of the missing features in monorepos. While they make a lot of stuff easier and trackable, I don't feel comfortable having every temporary consultant having access to all code at once.
What's the main use-case you imagine for gittuf?
Do you think it will work well for supporting a monorepo?
Do you think it will work well for supporting a monorepo?
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 [0] for SLSA's upcoming source track [1] could be very interesting as well.
[0] https://github.com/in-toto/attestation
[1] https://github.com/slsa-framework/slsa/issues/956
For those who care about a and b, I think the work we want to do to support in-toto attestations [0] for SLSA's upcoming source track [1] could be very interesting as well.
[0] https://github.com/in-toto/attestation
[1] https://github.com/slsa-framework/slsa/issues/956
Hey, this is interesting, some questions:
1. does it also filter/escape ANSI Sequences in messages and author names? 2. does it block garbage collection? 3. how do you ensure that the developers are really the developers and there's no spoofing?
1. does it also filter/escape ANSI Sequences in messages and author names? 2. does it block garbage collection? 3. how do you ensure that the developers are really the developers and there's no spoofing?
> 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 and how 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
Not at present! Do you have a link or so I could use to familiarize myself? I'm curious if and how 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
I find this interesting, from my reading it sounds like this would provide branch-protection as well as per-file protection at the local level. It could be very useful for projects that have public and private code.
I’m on a phone so please forgive me if I missed it, but is the intended threat model for gittuf documented anywhere? I see a reference (in the linked paper) to a vulnerability that’s been submitted to CERT that gittuf is expected to remediate, but it wasn’t immediately clear to me whether using an authenticated transport (e.g. SSH) would solve that particular issue as well.