hgkeeper is an server for mercurial
repositories. It provides access control for SSH access.
hgkeeper is licensed under the GNU AFFERO GENERAL PUBLIC LICENSE version 3.
This project is brand new and not even functional yet... But if you're
interested in helping, please do!!
hgkeeper has a couple modes of operation but serve
is the main mode.
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
.
The serve
command is the main mode of operation which is to provide access to
the repositories.
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
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
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.