"we will start sending out new ssh credentials to the active developers who had kernel.org accounts before"
um no. You _should_ be asking developers to send you new SSH credentials. Generating users' private keys on their behalf is completely unnecessary and provides extra opportunities for attackers to snarf them.
The gitolite permissions file is fairly robust. Each person who needs to access Git repo(s) sends you their public key (i.e. id_rsa.pub) and only their public key is stored on the server. Since access to the gitolite server is really just an SSH connection, the keys are stored in ~/.ssh/authorized_keys and managed via gitolite.
So, you get the tried-and-true security flow of public keys within SSH.
As for the user/group management, gitolite lets you provide access to various repos (with settable read, read/write, read/write/+ permissions) to individuals identified by the public key files you've received from your Git contributors.
Not sure if that's what you were wondering but we've had a fairly easy time providing secure access to our own private Git repos using gitolite.
Server-side hooks are going to be an interesting problem to solve for kernel.org.
Gotcha. Yeah, there's no reason for users not to generate their own key pair and submit the public keys via whatever means makes the most sense. It's going to take someone a great deal of time to gather all the public keys, rename them and add them to the gitolite system.
There are a couple of web admin panels that can sit in front of gitolite and manage keys, repos and permissions. I've not tried any of them but hopefully someone is looking into that. Makes a lot more sense than generating key pairs and distributing private keys to everyone.
I don't know about kernel.org stats, but these are pretty useful server side for sanity checks (i.e. enforce commit message rules), notifications (IRC, XMPP, etc), and external integration (Gerrit, Jenkins CI, etc).
Junio (git's maintainer) was using a hook to pre-generate html documentation and manpages. These would get committed to "html" and "man" branches so that others could check them out without needing to have the asciidoc tools installed.
I'm missing something. If the goal of revoking ssh access is to stop kernel devs being able to run arbitrary commands on kernel.org servers...surely you can't give them permissions to set their own commit hooks?
If an attacker compromises a kernel dev, instead of using their ssh access to run cmds on kernel.org, they just use their hook access to run cmds on kernel.org.
HN is full of spam and has been for years. There are more spam submissions in /newest than non-spam. Thankfully pg and the other moderators are swift in implementing tools to blast spam accounts and urls.