[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