Skip to content

fix: r148 on the core: a module is withdrawn, never uninstalled; tombstones hold their principal - #21

Merged
antoinetoussaint-byte merged 2 commits into
mainfrom
fix/core-r148
Oct 26, 2026
Merged

antoinetoussaint-byte merged 2 commits into
mainfrom
fix/core-r148

Conversation

@antoinetoussaint-byte

Copy link
Copy Markdown
Collaborator

What we are trying to do

Close review r148 on #20 before the local authority wires Uninstall into a host. The wrapper PR, which comes next, is what exposes it.

The change (libraries/authority-core/go)

  • M1. A module is withdrawn, never uninstalled.
    • Uninstall refuses a module's installation by name, as Install already refuses a module.
    • ApplyModule reactivates revoked module installations only on the tombstone path, that is, after a WithdrawModule.
    • An administrator's uninstall of a solution stays uninstalled across deliveries.
  • m1. A tombstone holds its principal.
    • The Store contract gains TombstoneByPrincipal.
    • No other module can claim a withdrawn module's principal, and Install refuses one.
    • A tombstone is never cleared: a module that must change principal is delivered under a new name. This is documented on domain.Tombstone and on the Store contract.
  • m2. Only an administrator learns what is installed.
    • Uninstall gives the foreign answer to anyone who is not a current administrator of the named organization, before any installation is read.
    • In every role call, a caller the store no longer knows belongs to no organization, so they get the foreign answer whatever their session says.
  • m3. Issuance reports a store failure under the fence as the store failure, not as a refusal.

Size

52 hand-written non-test lines and 124 test lines.

Classification

This is a fix at the owner. It reuses decide.ForeignInstallation and the existing tombstone record; nothing new is added beside them.

Tests

  • r148_test.go:
    • a module installation is never uninstalled, and a routine delivery reactivates nothing an administrator cut;
    • a tombstoned principal is never claimed, by a module or by an installation;
    • no one but an administrator tells a present installation from an absent one: a member uninstalling, and a deleted ex-member uninstalling or listing;
    • an issue reports a store outage as the outage.
  • Each test was run against main's core and failed.
  • sources_test.go: a member who administers nothing now gets the foreign answer.
  • go vet and go test -race -count=1 with GOWORK=off pass in authority-core, hop, conformance and local/code.

🤖 Generated with Claude Code

antoinetoussaint-byte and others added 2 commits October 26, 2026 00:23
…stones hold their principal; only an administrator learns what is installed

- M1: Uninstall refuses a module's installation by name (a module is
  installed by composition and withdrawn, never uninstalled), and a delivery
  reactivates revoked module installations only after a withdrawal (the
  tombstone path). An administrator's uninstall of a solution stays.
- m1: tombstones are found by principal too: no other module may claim a
  withdrawn module's principal, and Install refuses one. A tombstone is
  never cleared; a module that must change principal takes a new name.
- m2: Uninstall gives the foreign answer to anyone but a current
  administrator of the organization named, before any installation read; a
  caller the store no longer knows belongs to no organization in every role
  call.
- m3: issuance reports a store failure under the fence as itself, not as a
  refusal.

Each new test (r148_test.go) was run against main's core and failed.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…d it stays retired

Only a person is refused uninstalling a module's installation. The host's
setup (no caller) retiring one at an organization is kept across routine
deliveries, since only a withdrawal and a redelivery reactivate a module's
installations; the test covers both.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@antoinetoussaint-byte
antoinetoussaint-byte merged commit 83423fc into main Oct 26, 2026
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant