Hacker News new | comments | show | ask | jobs | submit login

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.

i know how gitolite works; i've used it myself.

what i am asking about is the central generation of private keys. that is not necessary for gitolite. the normal (secure) process is to have users provide their public keys.

what i would like to know is how kernel.org generating private keys for users (in one central location, and then, i assume, distributing them) can be "more secure".

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact