vole

Clone

Read only, no credentials:

https://rodent.software/vole.git

Write over SSH with a registered key:

git clone ssh://git@rodent.software:2222/vole.git

A free and open-source forge that lives in your Git repo.

Accounts with stable ids; the roster moves into the system repository

31df8baea9c9e8acf74b71bdda26d27907b30f2a · Keenan Nemetz · 18d ago · parent 36293228

Accounts with stable ids; the roster moves into the system repository

Names were the primary key everywhere — the keys file name, the ACL entry, the
approval file — so renaming someone broke their access, orphaned their approvals,
and left a retired name able to hand a newcomer the old holder's rights. This
splits identity into an account (stable id, anchored by its SSH keys) and a name
(mutable, never reissued).

  data/system.git  refs/heads/main
    users/<ulid>/meta.json   name, status, keys, former_names

Everything that grants authority now holds the id: ACL entries, approval files,
and the identity resolved at the SSH handshake (VOLE_ACTOR_ID). A rename is a
one-file change that disturbs nothing else, and both the old and new names stay
reserved forever.

The roster moved from a trusted-keys directory back into git, which reverses an
earlier simplification — deliberately, and in a smaller shape (one file per
account, one writer, no CAS plumbing for unused fields). Git buys what a directory
could not: `git log` answers who renamed whom and when a key appeared, and the
roster is now readable by anyone who can clone, since it is served read-only at
ssh://host/system.git. `vole request new` and `approve` use exactly that to turn a
name typed on the command line into the account id they store.

Two latent bugs surfaced, both caught by tests added here:

- gitx inherited git's repository-scoped environment. pre-receive runs with
  GIT_OBJECT_DIRECTORY and GIT_QUARANTINE_PATH pointing at the pushed repository's
  quarantine, so every git call a hook made for a *different* repository silently
  read the pushed one: the hook saw an empty roster. gitx now scrubs those
  variables and the hook restores them for the pushed repository only.
- The hook built the repository name with filepath.Base on receive-pack's path,
  which carries a trailing separator, so refusals read "does not have write access
  to .". Cleaned first.

Verified end to end on a live instance: two accounts file, approve and land a
change; `vole user rename wilbur robert` keeps the same key's write access and the
approval still reads as current, now credited to robert; the roster history shows
"user: rename wilbur to robert"; retiring an account rejects its key within five
seconds and refuses to reissue the name.

internal/web/requests.go +7

@@ -52,6 +52,8 @@ func (w Web) Requests(rw http.ResponseWriter, r http.Request) {
	52	52	// which approvals currently apply.
	53	53	type requestApproval struct {
	54	54	requests.Approval
		55	// Name is the approver's current name; the file itself is keyed by account id.
		56	Name string
	55	57	// Current is false when the approval names a commit or base that is no longer
	56	58	// what the request asks for, which is the normal state after a force-push.
	57	59	Current bool
@@ -81,8 +83,13 @@ func (w Web) RequestView(rw http.ResponseWriter, r http.Request) {
	81	83	}
	82	84	approvals := make([]requestApproval, 0, len(req.Approvals))
	83	85	for _, a := range req.Approvals {
		86	name := a.Principal
		87	if w.Ident != nil {
		88	name = w.Ident.Name(a.Principal)
		89	}
	84	90	approvals = append(approvals, requestApproval{
	85	91	Approval: a,
		92	Name: name,
	86	93	Current: a.Head == req.Head && a.Base == req.Base,
	87	94	})
	88	95	}