It’s not my area, but I bumped into this yesterday: https://gittuf.dev/ - wondered if it might be worth considering longer-term, particularly if we end up managing larger repos on the scale of nixpkgs for any length of time? (Will cross-post to the mono repo topic too.)
I’m a bit worried by this
Note that gittuf is currently in alpha, and it is not intended for use in a production repository
as well as concerned about the friction this would add for new developers… let’s bring this up again if the project develops further and we find we need something like it, but for now this isn’t something that I would want to adopt
4 Likes
Oh absolutely, it was just something I bumped into while looking for something else, and wanted to bring to the attention of anyone who might find it relevant. Anyway, now it’s here it’s searchable!
what is the benefit you are hoping/ envisioning/ seeing/ getting from using gittuf? Or alternatively what problem does/ would it solve?
2 Likes
It looks like it should be possible to create very fine-grained access controls with it, down to the individual file level, which might be useful if we end up maintaining a large-ish collection of packages in one repo for any significant length of time. I seem to recall nixpkgs having issues around who was allowed to update maintained packages etc.?
possibly we could look into something like CODEOWNERS for this instead, where you can assign files/directories to specific users?
1 Like
I’m not familiar with it, but a quick google suggests it might be a lighterweight system, yeah. OTOH gittuf looks like it creates a portable cryptographically verifiable “paper trail” of what’s been done to the repo, and the history git refs etc.
(BTW, the reason I bumped into it is it got linked on the Radicle zulip, as apparently radicle does similar things for verifying the validity of git refs etc.)
1 Like
What is this cryptographic verification stuff? It differs from just setting commit signing as required?