You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit e4c7458
Browse filesBrowse the repository at this point in the historyBrowse files
|`gitlawb-attest`| Pluggable external provenance attestations for ref-update certificates. |
31
+
|`icaptcha-client`| Client for the iCaptcha proof-of-intelligence flow used to protect spam-prone writes. |
30
32
31
33
---
32
34
@@ -54,6 +56,7 @@ Good today:
54
56
- Bare git repository storage.
55
57
- Git smart-HTTP clone/fetch/push.
56
58
- RFC 9421-signed writes.
59
+
- Repository and path-scoped visibility enforcement for repository and Git content reads, with 404-shaped repository denials.
57
60
- DID identities.
58
61
-`gl` CLI workflows.
59
62
- libp2p peer discovery/gossip foundation.
@@ -63,11 +66,13 @@ Good today:
63
66
64
67
Known limitations:
65
68
66
-
- Private repository read enforcement is not wired yet. Treat public nodes as public infrastructure unless you restrict access at your proxy/firewall.
67
-
- UCAN chain validation and revocation are not complete.
68
-
- Repository write authorization is not capability-complete yet; HTTP signatures prove identity, not full authorization policy.
69
+
- Repository write authorization is not secure by default: `GITLAWB_ENFORCE_OWNER_PUSH` defaults to `false` for compatibility, so a valid HTTP Signature identifies a pusher but does not enforce owner-only pushes.
70
+
- UCAN proof chains are validated when supplied, but UCAN capabilities are not consulted by write authorization and the root issuer is not independently trust-anchored. UCANs therefore do not yet grant scoped collaborator access.
71
+
- Agent lifecycle revocation is not enforced by HTTP Signature authorization; do not rely on removing or revoking an agent record to block a compromised signer.
72
+
- Read visibility is not a blanket data-classification boundary: task, IPFS-pin, and Arweave-anchor listings are not repository-gated; withheld path names can be visible to a root reader; and later visibility changes cannot retract content already announced or externally anchored.
69
73
- Peer writes are signed by upgraded nodes, but strict signed-peer enforcement is opt-in during rolling upgrades.
70
-
- GraphQL mutations need mutation-aware auth before becoming a public write surface.
74
+
- Current GraphQL mutations require an authenticated signer, but there is no mutation-specific guardrail that prevents a future mutation from omitting that check.
75
+
- Pull-request review comments do not yet have threaded line-level anchors, and merges do not enforce approval requirements.
71
76
72
77
See:
73
78
@@ -466,8 +471,8 @@ Short-term priorities:
466
471
2. Add Docker and installer smoke tests.
467
472
3. Improve operator docs and `gl doctor` checks.
468
473
4. Harden peer writes and publish the signed-peer rollout plan.
- Bootstrap UCAN tokens are issued at registration.
33
+
- A supplied token's signature, audience, expiry, and proof-chain attenuation are validated.
34
+
- Tokens use a signed JSON wire format with expiry.
35
+
- Capability grants are not yet consulted by repository write authorization; see the limitations below.
35
36
36
37
**Smart contracts (Base Sepolia testnet)**
37
38
-`GitlawbDIDRegistry` — on-chain DID → document registry
@@ -48,21 +49,20 @@ We will acknowledge receipt within 48 hours and aim to release a fix within 14 d
48
49
49
50
---
50
51
51
-
## Known Limitations (Planned for v0.2)
52
+
## Known Limitations
52
53
53
-
These are **documented, accepted limitations** for the current live release and should be prioritized without breaking existing nodes during rolling upgrades.
54
+
These are documentedlimitations of the current live release. They should be prioritized without breaking existing nodes during rolling upgrades.
54
55
55
-
### UCAN chain validation
56
-
- The auth middleware verifies HTTP Signatures and token structure, but does not yet walk the full UCAN delegation chain.
57
-
-**Impact:** A node cannot yet enforce fine-grained capability delegation. Currently, any registered agent with a valid HTTP Signature can push.
58
-
-**Mitigation:** Keep write endpoints signed, treat public nodes as public infrastructure, and treat trust scores as soft rate-limiting signals rather than authorization.
59
-
-**Fix target:** v0.2
56
+
### Repository write authorization defaults
57
+
-`git-receive-pack` verifies HTTP Signatures, but `GITLAWB_ENFORCE_OWNER_PUSH` defaults to `false` for compatibility during rollout.
58
+
-**Impact:** With the default setting, a valid signature authenticates the pusher but does not require that DID to be the repository owner.
59
+
-**Mitigation:** Set `GITLAWB_ENFORCE_OWNER_PUSH=true` on nodes where owner-only pushes are required. Confirm that every legitimate pusher uses the owner DID before enabling it.
60
60
61
-
### UCAN revocation
62
-
-Issued UCAN tokens cannot be revoked before expiry.
63
-
-**Impact:** If a keypair is compromised, the attacker retains access until the UCAN expires (default: 30 days).
64
-
-**Mitigation:**Regenerate your identity (`gl identity new --force`) and re-register to issue a new UCAN. Until revocation/blocklisting is implemented, operators should remove compromised DIDs directly from their local database.
65
-
-**Fix target:**v0.2
61
+
### UCAN delegation and revocation
62
+
-The middleware validates a supplied UCAN's complete proof chain, but a root token is accepted without an independently trusted issuer anchor. `Ucan::can` is not yet used by write handlers, so a UCAN does not grant scoped repository access.
63
+
-Agent lifecycle revocation is not checked by HTTP Signature authorization. Removing or revoking an agent record does not itself block a compromised DID from authenticating.
64
+
-**Impact:**Do not use UCANs for collaborator permissions or rely on agent-record revocation as a key-compromise response.
65
+
-**Mitigation:**Keep sensitive deployments behind operational network controls and enable owner-only push enforcement where it fits the deployment until trusted delegation and authorization-aware revocation are implemented.
66
66
67
67
### git-receive-pack authentication
68
68
- The `git-receive-pack` endpoint enforces HTTP Signature auth. Plain Git smart-HTTP clients do not generate those headers, so the `git-remote-gitlawb` helper is required for pushes.
@@ -71,10 +71,20 @@ These are **documented, accepted limitations** for the current live release and
71
71
-**Fix target:** v0.2
72
72
73
73
### Private repository reads
74
-
- Repository records have an `is_public` field and the node exposes `GITLAWB_PUBLIC_READ`, but per-repository private-read enforcement is not wired in the current live release.
75
-
-**Impact:** Do not store private repositories or secrets on public nodes.
76
-
-**Mitigation:** Run isolated nodes for non-public data and restrict network access at the reverse proxy or firewall layer.
77
-
-**Fix target:** v0.2
74
+
- Repository and path-scoped visibility checks are enforced for repository API and Git content reads. A denied whole-repository or root read returns the same 404 shape as a missing repository, so the denial does not reveal private-repository existence.
75
+
- Sparse-clone support exposes withheld path globs to callers who may read the repository root. Do not put sensitive information in withheld path names.
76
+
-`GET /api/v1/tasks`, `/api/v1/ipfs/pins`, and `/api/v1/arweave/anchors` are not repository-gated. Task records include a UCAN token; pin and anchor listings expose object and ref metadata.
77
+
- Changing a repository's visibility controls future serving, but cannot retract ref metadata or configured external pins and anchors already announced while the repository was public. Do not push secrets to an announceable repository.
78
+
-**Impact:** Visibility policies protect the repository and Git content routes they gate, not every metadata endpoint or previously published content.
79
+
-**Remaining boundary:** This read control does not address the independent write-authorization and UCAN-delegation limitations described above.
80
+
81
+
### Pull-request review enforcement
82
+
- Pull-request review comments are not yet threaded or line-anchored, and merges do not enforce required approvals.
83
+
-**Impact:** Teams must use their own review policy or external controls for merge approval requirements.
84
+
85
+
### GraphQL mutation coverage
86
+
- Existing GraphQL mutations require an authenticated signer, but a mutation-specific source-level guardrail has not yet been added for future mutations.
87
+
-**Impact:** A new mutation could accidentally omit its signer check without an explicit test fence.
78
88
79
89
### Peer route hardening rollout
80
90
- Peer announce and sync notification routes accept signed requests and verify DID matches when a signature is present.
@@ -101,15 +111,15 @@ These are **documented, accepted limitations** for the current live release and
0 commit comments