hgkeeper

hgkeeper is an server for mercurial
repositories. It provides access control for SSH access.

License

hgkeeper is licensed under the GNU AFFERO GENERAL PUBLIC LICENSE version 3.

Status

This project is brand new and not even functional yet... But if you're
interested in helping, please do!!

Usage

hgkeeper has a couple modes of operation but serve is the main mode.

setup

The setup command is used to bootstrap hgkeeper. It will create the
directory for the repositores, the hgkeeper repository, and create an initial
access.yml.

serve

The serve command is the main mode of operation which is to provide access to
the repositories.

Access Control

Controlling access to the repositories is done via the hgkeeper repository.
The repository has a specific layout to make it easier to reason about.

hgkeeper/
  - keys/
    - user1
    - user2
  - access.yml

keys/

The keys directory contains a list of files that contain one or many SSH public
keys. It is entirely up to you on how to name these files and their contents,
but note that the filename is used in access.yml to delegate permissions.

access.yml

access.yml is the access control configuration. When you initial setup
hgkeeper you will get an access.yml like the following.

global:
  init:
    - admins
  read:
    - public
groups:
  admins:
    - grim
patterns:
  hgkeeper:
    read:
      - admins
    write:
      - admins

There's a lot going on here, so let's talk about the basics here first. Access
is granted to user via the file name in the keys/ directory or the name of a
group.

The groups section contains the name of the group and the list of keys that
are in that group. So in the above example, the admins group has one file
who's keys will be put into the admins group. You can add a group to another
group. There is also a special built-in group named public which will allow
anyone to access the repository.

Now that we have a basic understanding of how keys are specified, we can cover
how to grant and revoke their permissions to specific repositories.

The global and patterns sections use a simple format to specify a list of
which keys are allowed to init (create), read, and write repositories.

The global section contains the defaults for all repositories. In the above
example, it gives permission to admins to create repositories anywhere and
allows all users to read all repositories. These permissions will be used
only if a repository's matching pattern does not specify a value for this
field.

The patterns section uses a key of a glob of what repositories to apply
these changes to. Since this is a glob pattern, that means it'll allow *
and ? for wildcards. If an entry in a patterns entry does not specify
any of the init, read, and/or write permissions, the corresponding value from
the global section will be used.