 As Maria said, I'm Aditya, I'm a PhD student at NYU, I research software supply chain security here in the CNCF, I'm one of the maintainers of Intodo, and for about a year, just over a year now, we've been building GitHub for securing Git repositories. So, you know, just to get, just to, you know, pay out the land a bit. The state of Git security today is, Git is kind of addressed, so you get some integrity checks out of the box. It also has some semantics for things like signing your commits and tags and pushes too, but sending that aside for now. If you've looked at a best practice guide for source control, source code management systems in the last few years, you probably come across this thing that says you should sign your commits and things like that and, you know, Git does that offer, allows you to do that out of the box. But what Git does not support is actually defining policies around all of these things. It's like, if I'm supposed to be signing my commits and so on, what, like as a ratifier, as someone who's actually going to ratify those signatures, how do they know what keys to trust for that repository? And when should they stop trusting a key for that repository? Maybe the key was lost or maybe the developers stopped working on the project and no longer considered a maintainer. That keeps happening. Other access control-ish things like, oh, what kind of actions can a developer take in a repository? Are they allowed to merge something into the main branch? Typically not. That's typically a capability you limit to a handful of maintainers and so on. Which files a developer can write to or conversely not write to, things like that, which is just not supported in Git Repository. So these are the kind of questions we started out with. And that's where I'm going to present to you, you know, Git Dove. So one of the first things we started doing in Git Dove is to try and see how we could store policies around all of these kinds of, you know, to try and answer and to try and enforce those kinds of checks in a Git Repository within the repository itself. We Git allows you to store things in custom namespaces, which is really, really neat and we take advantage of that quite a bit. So we encode policies using some semantics from the update framework, a graduated project here at the CNCF, which you might have heard of a bit in the last few days especially, as well as some semantics from the Intodo project, which the asterisk up there shows is a work in progress because I opened that PR last week and it's not been merged yet. But anyway, so the idea is to use these semantics to declare trusted signing keys for the repository and specify namespace specific rules for that repository. Right? So this is just something I put up there to show that all of this is like where you get native. So if you start looking at, if you start implementing Git Dove in a Git Repository and you start poking around the custom namespace, it just looks like another Comet history thing. And if you actually like start inspecting this Comet, you're just going to see those policies I was just talking about. And this is from our demo and it's just something I added to the policy. Like I added a rule to protect the main branch, right? And that's pretty much what the rule looks like. It's like for the main branch, the only person who's trusted to merge something in there is my own identity. And here I'm using a Git sign to identify me from the six store project. So it just says that like any change I make to the main branch must be authorized by my signature issued using that, you know, identity, my email ID coming from GitHub. And you can verify that entire flow with six store. That's, that's roughly it. But also more generally speaking, you can define policies for like, Oh, this, this person can write to this file and this person can write to these branches and so on and so forth. So with, with all of that, you get to do things like, Oh, I can verify signatures using GitHub policies for commits and tags, which is like pretty similar to what Git already gives you. But you know, it doesn't actually bring your own keys and so on, but GitHub tries to plug that whole a bit. But you can also verify changes that were made to a branch or a tag and so on. And again, that uses the GitHub policy. And interestingly, because all of this is tracked within the repository itself using Git's own semantics, you can revoke keys in the event of, you know, the key getting compromised or developer leaving your team. And that it's a useful property because everything they did up until that point can continue to be trusted. And everything after that point, you know, you know, when to stop trusting the key, which is just something you don't get if you don't closely associate these kinds of policies with the repository. And to be able to verify changes that happen to a ref, it's not, you know, enough to just look at the main branch. We also need to know when a change happened to the main branch. And that's where we also introduce something like, well, not introduced, we implement something called a reference state log. It's it was first described in an academic paper from, I'm going to say 2016. Yeah, 2016. And it is, you can think of it like, like the Git ref log, but it's authenticated and actually shared with like all of the developers of the repository. It's also tracked in a custom namespace. It's basically a constant tracker of changes that happen to different branches and tags and so on. Right. And again, this is also, I said, it's authenticated. It uses the same Git signing mechanisms. You could use TPG, Git sign, whatever. Like here's here are a couple of examples. It's just this is an entry, the change is to the main branch and the main branches tip is now that commit ID. And before that, the main branch had that other commit ID. So it's just a log of how the branches evolve over time. I also want to note that I, like I called out that we want to start supporting in Dodo. But like more broadly speaking, we think there's a lot of room here to also start using attestations, because you can also start answering all kinds of other questions that, you know, that that that go back to the data that you'd store in an attestation like, Oh, was was this changed? I got merged to main reviewed by these two other people. What did the code review say? Or before we merge it, did my CI pipeline go and run an automated test and give me a test result attestation, things like that. And this is also where we really want to plug into salsa, where there's a lot of ongoing work at the moment on defining a source track centered on all of this, because salsa at the moment, like the spec itself is very focused on the build track, but there's another track coming up called a source track. But and yeah, we've got a work in progress thing on the Gitaf repository that starts implement has started implementing some lightweight attestations to try and answer some of these questions. And more, yeah, because we, you know, like I said, it gives you that custom namespace, you can track a lot of things in there. And we want to try and make Gitaf extensible to support all kinds of other features that may be necessary as, you know, as threats evolve and so on. Before I close out and you know, open the Florida discussion because this is an unconference. Like I want to just highlight a couple of key properties that we've kept in the back of our mind when designing Gitaf, because like one of the first things we've been really focused on here is trying to make policy enforcement and Git repositories distributed. So every developer can every Git after every developer who uses get tough can verify policy enforcement constantly in their copy of the repository without relying on someone else or stress like a single synchronization point to do the policy enforcement for them, which is kind of where we are today. And because all policies attract in the Git repository itself, and we have the reference state log to track, you know, how the policy evolves over time, it also makes it incredibly auditable. Like, we now have a log of every change to every policy right now to who made that change to policy and why and things like that. And you can also track the active policy for whenever a change was made to some other part of your like your main branch and you're like, wait a minute, when did this commit enter the main branch? And what was the policy active at the time and get through all the checks, you can make all of these things auditable without, you know, it being opaque in another system, right? This is all this can now all be stored in your Git repository and verified in a distributed manner. And yet the all of the and because we reuse so many of these get native semantics like the object store, the custom namespaces and get signing any Git repository can use get tough, right? It doesn't matter whether I mean, as long as you're not using an incredibly old version of Git, but yeah, any Git repository can start using get tough. And you know, the authentication just uses get signatures, which again, every Git user can can can start using to and it doesn't matter it's compatible with most all fortress, you can use it with GitHub, you can use it with Git lab, that's that's that's what we're trying to build in here. So that we're agnostic to all of these things. A couple of quick links that we have a GitHub repository, where we're building out get tough. We had our first release about two weeks ago. It's an alpha we zero dot one dot oh, it includes some of what I talked about here already, like branch protection, file protection, signature verification stuff, but we're building in things like the attestation support, etc. still. And we've got a couple of demos on our GitHub org as well, that you can play with. And yeah, happy to, you know, hope. Yeah. questions, feedback, discussion, etc. If folks want to say something, please just let me bring the mic over to you. So it's on the recording. So yeah, so what's the emphasis and how do you how would you say, um, how will the workflow be when you have a client user using get tough and someone not using get not not using get tough, right? So I can see an example for where a project is using get tough, but there's a guy who's like, Hey, I don't want to touch that. Like, is there a way you can like assign them a specific key or a system? Like, what's the mechanism for them to like contribute to a repository without using get tough? And how do you maintain the same guarantees that we're talking about maintaining this? That's a good question. Maintaining the same guarantees in that context is a little hard. But we are working through like, we're thinking through these workflows a lot because yeah, this isn't built into get itself. So you're going to have that, especially in open source projects where you got a subset of people using get tough and like what that looks like. We're talking about how we can include other authentication methods as well, maybe to see if someone else can like, you know, science and get tough specific metadata. Like, yep, this action is fine because I authenticated in this separate way and include that information as well. So that it's still transparent. But, but again, it's not going to be exactly the same set of security properties you'd get if everyone was using get tough. Well done. Any plans to upstream this back to get? I think not at the moment, but maybe as it matures, I would definitely love to explore that some more. But yeah, we're just still like, yeah, we've got to see how this goes. Yeah, sorry, I was just going to add on to that like politically, I think we'd like to do that. But historically, that's been a very slow process. So we're trying to make some steps forward and we'd be happy to have that all integrate back in in the future. For context, that's one of the other get tough maintainers. Any other thoughts, questions? All this is stored in the repo. What if I push the squash and merge button in GitHub? Also, a good question. That is again, where we're trying to find some work around around there. So we're like, hoping that you could maybe, I don't know, build a bot for this. And if GitHub, for example, one day, start supporting, say, using get sign instead of just using their online key to sign that commit that gets created, right? Then you press that button and it's still authenticated back to you, right? Like, these are all things we're still discussing and we're still like, we're building out how we can make GitHub as transparent as possible, as opposed to being a bunch of extra commands and a bunch of extra steps that developers have to take because no one's going to use any security tool that has that kind of burden. But yeah, one of the other maintainers is Billy Lynch who built get sign over at six store. And like, we do keep talking about all of this. And we hope that one day this becomes really seamless as well. And like, yeah, what is the I'm thinking, particularly of like the branch protections component of this, what is the advantage of using this method for doing that over, say, using settings in GitHub to protect certain branches from being merged by certain users? Yeah, I think that's where it really goes back to being whereifiable, like, all the time and like being able to walk back the history of all of these merges over time because, you know, you're going to have a lot of PRs and you want to know that the right policy was enforced for each one of them and being able to walk back and verify that it trivially making it more auditable. And yeah, I think that's that's sorry, I thought I had another thing, but it's my mind maybe to come back. I can maybe add a little bit more to that. So you don't in GitHub have the history of all the policy changes, which is one of the problems because you don't know what's gone wrong. And also you can't apply those kind of protections on finer granularities of like files and file per branch and all that other stuff. And one of the things that we're looking at doing also, which is a little bit later down the roadmap is also giving away to do actually read protections on certain files where they would appear encrypted people who are not able to access them, but would be transparently not, you know, decrypted by those who are. So, you know, you may or may not want to store the worst secrets in the world, but sometimes you want to hide things like configuration files or email addresses of employees or stuff like that. And so you can go and put those types of things into a repo with some degree of safety. Thanks. Yeah, that the policy change thing was what I was what I forgot right there. Because for example, today, you know, by default, you can turn on branch protection, but you still if you're an admin, for example, you have that merges administrator button that you can also disable that. But if you're an admin, you can also disable that protection that gives you the right to, you know, go back and then you can turn that back on again and all of this just gets lost in the process. So it's hard to tell and hard to audit. Whereas here you can enforce that more rigorously. I missed a couple minutes at the beginnings. I don't know if it was mentioned, but you're mentioning file specific protections. And how does that compare to some get server provider features like GitHub's code owners? It is similar. It is quite similar. But again, it does tie back into the, you know, how does it evolve over time? And was it actually enforced at the time, and then like distributing the verification of all of these properties? It is similar. But yeah, and again, we want to plug into some of the same things. Because if, for example, if GitHub starts doing salsa source track at the stations around code reviews, which is what, you know, the code owners file enforcers, it says someone on this file must review for these bots and things like that. Like we want to be able to support that consuming those out of stations in GitHub and verifying it again as well. So how flexible are you with like different crypto algorithm systems? You mentioned Git sign, but PGP, for example, is also popular to sign your commits. And it has a very different set of attributes and like operations you can do like revocation. Like, how do you stay flexible and still cope with like the different capabilities of those systems? Right. That's a good question. We support, you know, the additional commit signing and whatever you do when you use GitHub, because the RSL commits, et cetera, you do sign them. It just uses whatever you want to use as a developer, whatever you're configured using on your machine. It uses, if you're configured to use Git sign, it's going to use that. If you want to use your GPG key, it does that. But if you're doing, it supports, you know, signing with GPG and GitHub policies can distribute and say this GPG key is trusted and so on, but it doesn't plug into like the actual GPG keys revocation mechanisms and so on. It's already centered around the GitHub policy because it, you know, associates all of this information particularly with this repository. And so revocation in that context would be within the GitHub policy rather than just, yeah. I guess I can ask a question if anyone else has one. How do you see this fitting more broadly into a software supply chain security posture? Good question. Well, I mean, your source code is a pretty big component of your software supply chain, right? And, and there's a lot of really cool work happening with securing software delivery with projects like tough with securing with a lot of focus right now in like the build parts of your software supply chain with salsa with like in total at a stations at the moment that are very more focused on that part of the supply chain rather than the source side of things. And that's how I see it. Like, I think we're just like, we did the delivery, we did the build stuff. And now we're moving on to improving the security posture for source code management systems. I'm really excited to use this with something like Argo CD. I know that it already had like GBG signature verification on Git repose, but I could see this being sort of like a successor to that, which would be really, really cool. Cool. Yeah. Have to help out if, you know, and hear about any pain points because there are some sharp edges still. We're in alpha. So have you thought about how do you handle a sub module with like transitive trust, where you're sucking in another repo that has like a completely different trust route? And do you think anybody could do anything funny with that to cause like bad stuff to happen in a repo? That's a good question. And there isn't anything in the implementation that, you know, is centered around that particular model, but I haven't, we haven't been thinking about it a bit. And I do want to, like, you know, for sub modules, I want to be able to map them back to GitHub policy to say, this is what I expect from that sub module. So that even if like, because if it's not in your control, and if that's a GitHub repository, so you can do both recursive verification of that GitHub repository, and also set expectations on what its trust routes are, and so on. But that hasn't been implemented yet. But you know, also, yeah, we would be happy to sketch that out and so on some more. In terms of the scope of who might be using GitHub, do you see the application as being more like open source projects where many different entities are kind of working on the same repo? Do you all see a use case for just repos that are totally internally controlled by a company? I mean, it's not really shared outside the company because there's still value for them? I think so. I don't know. I think it's both. I also see some. Yeah, we're going through tons of stuff like that, like with some of our customers, you know, people who want to make sure that their code is gone through security scanning, and you need like something content addressable to attach like an attestation to. So this is a case where like, you know, you have developers building an application, but you still have to go through like a change advisory board process and figuring out how to automate that and, you know, make all these sort of security guarantees, even things like, you know, has this version of this like repot this commit been signed off by QA or whatever kind of a spoke enterprise requirements you need to have. And well, I think to your point, I've been in environments and situations where we needed a business logic general controls that we started business logic and get and we didn't for we had to store our logic or our controls in our CI, right, to prove that, yes, this is this was the policies that were applied, and this is what was done. So to be able to store that and get and really to be this is where wherever it wherever our our Git repository is, this is the policy that was applied, be very strong proof that in a digital forensic conversation. Yes, this was applied at this time. Our controls at this place were did not fail. And you can go, you know, be faster searching other places. It seems that you're paying quite a lot of trust into get sign itself you verifying the actual trust of that. So you're making you obviously, you're allowing the kind of call out of the keys to kind of sign that you verifying that. As far as it just you've got you've notes from the key from there. Sorry, I didn't fully say it's obviously it's providing the service of which someone as I understand it they can use like the identity to tie it to their key. Surely there's ones if that is actually even compromise that service itself. Right. And yes, you're right. On that front, but I we use six store for what I was trying to say there is that we trust six store for that part of it. And like, because, you know, six store has a tool that does get signing and we do verify all the way back to the transparency log to ensure that that commit signature was, yeah, like, we don't just trust the signature against some random key that was generated by get sign at that moment in time, we do look for inclusion in vcar and so on. But yeah, that makes sense. And I'll also just add that we just support other key types. So it's not there's no reason why if you don't want to do that and you have a key, you use your other type of key. Give me questions. Yeah. Yeah, I mean, we're, like I said, we're still building a lot of this out. We're, you know, we're always on the lookout for interesting use cases people have for some of this. If this triggered some ideas in your head or, you know, some thoughts or way you'd like to see it applied, or if you have any concerns around niche, get workflows that you think might break because of some of what I described, you know, we'd love to hear them and try to incorporate them in our mental model of how we're designing get tough. So that'd be really cool. Come. We're on the open access. We're in open access of sandbox project. So we're on that slack. We have a channel and that's a great place to find us or just our git repository is another great place to find us. And I'll also add one last thing, which is it each has done just an amazing job of getting us to where we are. Our number two contributor is a 14 year old who's been pushing actually very, very good code commits in. There's absolutely room for anybody who wants to get involved and, you know, do some really cool stuff in the space that I think has a lot of legs to come in and participate in our community. We're very, very welcoming. Any other final thoughts? That's about it for me.