Need version control

[nszeek]

I am trying to set up some kind of version control and wouldn't mind some help.

What I would like to have:
- Several repositories
- Permissions per repository (user1 can read/write repo1 and repo2 while user2 can only read/write repo2 and user3 can't see anything)
- No user should have direct access to the repository (i.e.: rm -rf /var/.../repo1/* shouldn't work for regular users)
- Users can change their own passwords at will
- The passwords cannot be stored as plain-text (i.e.: I can't know the passwords)

I tried installing dev-vcs/git but couldn't set user permissions on a per repository base. I read somewhere it can't be done without A LOT of tweaking, something about HOOKS (installing git was already troublesome enough). After that I tried dev-vcs/subversion and found that:
- If I use ssh+svn users can "rm -rf /var/svn/repo1"
- If I use svnserve.conf + passwd then passwords are stored as plain-text and users can't change them
- If I use htpasswd users can't change their own passwords

So, does someone want to shed some light over my problem?

P.S.: Don't know if I am in the right sub-forum. Found some version control questions under this one and decided to use it. Please move me to the right one if I am in the wrong one.

[dmpogo]

Use git (which does not have much of a concept of repository) together with gitolite to manage central repositories

[nszeek]

Thanks, gitolite worked quite well. Just didn't like to have to add a public rsa key for each combination user-machine. Wish I could just use the regular users in the server as login but oh well ... I will live with it.

[dmpogo]

[SirRobin2318]

You can also use the ssh keys from another computer:
GIT_SSH="ssh -i ~/copied_id/id_rsa" git push ...

[steveL]

The key doesn't have to be per user-machine as Robin showed; eg: if they have the same key on several machines (it'll still require the same passphrase across all.)

IOW that aspect is up to the remote-user to sort out. They can use one key across client-machines, or configure a key per-server (it's up to them what pubkey they give you, after all.)

We certainly only use one key per-user in gitolite; the comment at the end is just that: a comment. (You can edit it before upload, and ssh doesn't care, iirc so long as it's the same on both ends, once in use.)
gitolite only checks based on the filename under keydir, which is the same as the user nickname in the conf/gitolite.conf file, ie anything the admin wants (self-referential and closed; the rest is up to ssh.)

Though if you want a local login to work, the user@host in the keyfile does need to match the local machine; so we end up with at most two keys, for users who login remotely and via locally logged-in terminal (ssh). In our case, we only allow the latter for gitolite admins.

If you do that just by editing the comment in the keyfile, then the user can use the same key. So we end up with: "ssh-rsa ..== user@remote" in (server-side) ~/.ssh/authorized_keys, and the same key in keydir/user.pub (for remote login) and edited with: "== user@ourhost" in keydir/user_ourhost.pub

Though even that duplication is not needed, when the user sets up a separate key specifically for our machine.

That's what we use on our shared-machine, anyhow. Groups in gitolite.conf are how we merge where needed, though in our case the locals are just in @admin, since we only allow them for gitolite admins, to use when logged-in.

Not requiring shell accounts for users makes gitolite much more flexible, and security-wise means you don't have to provide them in the first place.

I highly recommend #openssh on IRC: chat.freenode.net for help with general ssh, and many in #git use gitolite quite extensively.

I may be a bit fuzzy on some of the details above (especially ssh specifics: so I'd refer you to #openssh); feel free to correct any mistakes, as usual.