[Cryptech Core] git, again
Rob Austein
sra at hactrn.net
Thu Jan 23 17:50:02 UTC 2014
cryptech.is now has a gitolite installation under username "git".
Per discussion, it has an update hook (well, OK, a VREF rule if you
want to be picky) which insists that every commit uploaded to any
repository under its control be signed by a known PGP key.
At the moment, it knows about my SSH and PGP keys and Randy's. Others
who want to use this will need to send me their keys; those for whom I
do not already have PGP keys will have to find some way to
authenticate themselves to me (at the moment I think I have keys for
Linus, Patrik, Jakob, and Randy).
Aside from the PGP signature check, the current configuration is
simple:
- The magic gitolite-admin repository is restricted to the same people
who already administer the underlying host.
- The PGP signature check applies to all repositories, even
gitolite-admin.
- There's no real coupling between PGP and SSH identities. Access
control is all via the SSH identities as is normal with gitolite.
- Other than gitolite-admin, the whole thing is set up for what
gitolite calls "wild repositories", ie, repositories that are
created automatically when an authorized user first clones them,
after which that user owns the repository and can grant rights to
other authorized users via the gitolite remote command interface
("ssh git at cryptech.is help", etc).
- I'm happy to add static configuration for repositories that for
whatever reason should not be handled via the wild repository
mechanism, just let me know.
- I haven't done anything yet to integrate all of this with Trac.
I've been considering using a system based on client certificates
generated from the SSH public keys (not all that hard, just haven't
worked out all the details or figured out if it's worth it) to
replace the current password-based setup.
If this will suffice for now, cool, otherwise tell me what needs
changing (and why...).
More information about the Core
mailing list