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. :)
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.
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.
> 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.
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.
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!
I haven't read the paper but if Wikipedia serves as a detection tool, I don't particularly see a problem using it. Perhaps the real problem is the non-Wikipedia, canonical systems to find these probably-relevant cases?
Unfortunately (this may have changed in recent times), they often don't update the public repos in line with their releases. They put them out all at once later. Also, last I checked only the clients are open source? Has that changed?
As I understand it, federation enables two separate instances of some particular service to interact. They can still use single sign-on independently for their own authentication needs.
NPCI is a not-for-profit organization which is a consortium of banks and is promoted by the Reserve Bank of India. And these guys absolutely kill it. I moved from India to the US last year and payments are overall so much more complicated here. I have to download a third party app and even my bank, at least as far as I can tell, doesn't have a straightforward mechanism to transfer money to other people without using Zelle.
NPCI came up with IMPS, which is also what UPI is partially built upon I think. IMPS worked for basically every bank and you could transfer to every other bank instantly, usually via that bank's app or website. UPI almost took it to an IM-ing money level.
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