fix(node): carry full owner DID on ref-update wire event (#144)#145
fix(node): carry full owner DID on ref-update wire event (#144)#145Gravirei wants to merge 8 commits into
Conversation
github-actions
Bot
added
the
needs-tests
|
Thanks for the contribution. A couple of things will help us review this faster:
See CONTRIBUTING.md. Update the PR and these notes will clear automatically. |
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds an optional ChangesOwner DID propagation
Estimated code review effort: 3 (Moderate) | ~25 minutes Possibly related issues
Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
beardthelion
added
crate:node
github-actions
Bot
removed
the
needs-tests
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
crates/gitlawb-node/src/test_support.rs (1)
1969-2043: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueConsider a shared builder for
ReceivedRefUpdatetest fixtures.Both tests construct near-identical
ReceivedRefUpdateliterals inline. A shared helper (similar to theupdate(...)fixture already used in db/mod.rs tests) would reduce duplication and make future field additions (likeowner_did) less error-prone to keep in sync across test files.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@crates/gitlawb-node/src/test_support.rs` around lines 1969 - 2043, The `events_returns_inserted_ref_updates` and `events_limit_respects_limit_param` tests duplicate the same `crate::db::ReceivedRefUpdate` setup inline, so add a shared test fixture/builder for `ReceivedRefUpdate` in `test_support.rs` and use it in both cases. Model it after the existing `update(...)` helper used in the db tests, and make sure the helper accepts overrides for fields like `repo`, `owner_did`, `new_sha`, and timestamps so future schema changes stay consistent across tests.crates/gitlawb-node/src/db/mod.rs (1)
3919-4077: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winAssert
owner_didin the filtered-by-repo test too.
list_ref_updates_filtered_by_repo(lines 4027-4058) inserts records with distinctowner_didvalues but only assertsid/count, notowner_did, unlike the siblinglist_repo_ref_updates_filters_by_repotest which does check it. Adding that assertion would close a small gap in coverage for the exact field this PR introduces.♻️ Proposed test strengthening
let filtered = db .list_ref_updates_filtered(Some("ownerA/proj"), 100) .await .unwrap(); assert_eq!(filtered.len(), 1); assert_eq!(filtered[0].id, "u5"); + assert_eq!(filtered[0].owner_did.as_deref(), Some("did:key:zA"));🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@crates/gitlawb-node/src/db/mod.rs` around lines 3919 - 4077, The list_ref_updates_filtered_by_repo test is missing coverage for the new owner_did behavior. Update ref_update_db_tests::list_ref_updates_filtered_by_repo to assert the returned row’s owner_did matches the inserted value, similar to list_repo_ref_updates_filters_by_repo, so the filtered path verifies both repo filtering and owner_did preservation.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@crates/gitlawb-node/src/test_support.rs`:
- Around line 1969-2007: The ref-update events payload returned by the events
API is still missing owner_did, so the current test only verifies persistence in
Postgres. Update the ref-update feed serialization in the events response path
to include owner_did, using the relevant event model/handler that backs
events_router and GET /api/v1/events/ref-updates, and then extend
events_returns_inserted_ref_updates to assert events[0]["owner_did"] matches the
inserted value.
---
Nitpick comments:
In `@crates/gitlawb-node/src/db/mod.rs`:
- Around line 3919-4077: The list_ref_updates_filtered_by_repo test is missing
coverage for the new owner_did behavior. Update
ref_update_db_tests::list_ref_updates_filtered_by_repo to assert the returned
row’s owner_did matches the inserted value, similar to
list_repo_ref_updates_filters_by_repo, so the filtered path verifies both repo
filtering and owner_did preservation.
In `@crates/gitlawb-node/src/test_support.rs`:
- Around line 1969-2043: The `events_returns_inserted_ref_updates` and
`events_limit_respects_limit_param` tests duplicate the same
`crate::db::ReceivedRefUpdate` setup inline, so add a shared test
fixture/builder for `ReceivedRefUpdate` in `test_support.rs` and use it in both
cases. Model it after the existing `update(...)` helper used in the db tests,
and make sure the helper accepts overrides for fields like `repo`, `owner_did`,
`new_sha`, and timestamps so future schema changes stay consistent across tests.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 6d0fa77a-014d-4a04-af46-9ef99e20fe27
📒 Files selected for processing (5)
crates/gitlawb-node/src/api/peers.rscrates/gitlawb-node/src/api/repos.rscrates/gitlawb-node/src/db/mod.rscrates/gitlawb-node/src/p2p/mod.rscrates/gitlawb-node/src/test_support.rs
beardthelion
left a comment
beardthelion
left a comment
There was a problem hiding this comment.
The write-side plumbing is right: the full DID comes from the local repo record, it's threaded through both the gossip and HTTP-notify paths, and the #[serde(default)] / nullable column keeps older peers compatible. CodeRabbit's feed-serialization ask is genuinely addressed too. Two things block merge, and the first is a hard one: the schema change breaks every existing node on upgrade, and the PR closes #144 without fixing #144's symptom.
Findings
-
[P1] Ship
owner_didas a new migration version, not appended to v1
crates/gitlawb-node/src/db/mod.rs:542
TheALTER TABLE ... ADD COLUMN owner_didandidx_ref_updates_ownerwere added insideMigration { version: 1 }, butrun_migrationsskips any version already recorded inschema_migrations, and the catalogue comment right above the array says new schema must be a new version (v2, v3, ...). Every existing node has v1 recorded, so on upgrade the column is never created;insert_ref_update(binds$12) and all threelist_*SELECTs then reference a missing column and error, which stops ref-update ingestion on both the gossip and notify paths and 500s the events feed. Fresh databases pass because they run v1 from scratch, which is why CI is green. I reproduced it against the real migration runner: an existing node (v1..v9 recorded, noowner_did) upgraded to this build leaves the column absent and the insert/select fail; moving both statements into a newMigration { version: 10 }makes the same upgrade round-trip cleanly. -
[P2] Don't close #144 on this PR; nothing consumes
owner_didyet
crates/gitlawb-node/src/api/events.rs:38
#144 has two halves: carry the full owner DID (done here) and make the feed gate use it to stop the over-drop. Nothing in this diff readsowner_didfor a visibility decision; it's stored and echoed in the feed JSON only, andidx_ref_updates_owneris an index no query uses. The gate that over-drops isn't in this branch, so merging this auto-closes #144 while the reported symptom persists. Keep the plumbing, but change "Closes #144" to "Refs #144" and land the gate consumption (the did:key-aware match #144 describes) in the follow-up that sits on top of the gate. -
[P3] Populate
owner_didon the other read surfaces, or hold the JSON change
crates/gitlawb-node/src/graphql/query.rs:61,crates/gitlawb-node/src/api/events.rs:117
The field lands on the global REST feed but the GraphQLref_updatesresolver drops it (RefUpdateTypehas no such field) and the repo-scopedlist_repo_eventsgossip block omits it. No consumer reads it yet so there's no impact today, but the asymmetry is the same drift the duplicated four-copy SELECT column list invites, and it becomes a trap once something depends on the field. Either populate all three surfaces or defer the JSON exposure until the gate needs it. While here, add a migration upgrade-path test (seedschema_migrationsat v1, run migrations, assert the column round-trips) so the v1-append class can't recur.
The direction is right and the receive/publish wiring is sound; once the migration moves to its own version this is close.
beardthelion
dismissed
their stale review
P1 migration break resolved on 72ccb28; re-reviewed the new head, posting a fresh review.
beardthelion
left a comment
beardthelion
left a comment
There was a problem hiding this comment.
Re-reviewed on 72ccb28d. The P1 migration break is resolved and I verified it by execution: the owner_did DDL now lives in a new Migration{version:10}, and on a simulated existing node (schema_migrations at v1..v9, received_ref_updates without the column) migrate() adds the column and index and records v10. Putting the DDL back inside the already-applied v1 makes that same check fail (the column is never re-added), so the guard is load-bearing. Wire compat (#[serde(default)] Option<String>) and the DB plumbing are sound, and "Refs #144" is correct. Four items to fold in.
Findings
-
[P2] Drop the premature
idx_ref_updates_ownerindex, or defer it to the gate PR
crates/gitlawb-node/src/db/mod.rs:833
Nothing readsreceived_ref_updatesbyowner_didyet: every reference is a projection, no WHERE/JOIN/ORDER. Migrations run inside a transaction soCREATE INDEX CONCURRENTLYisn't available here (mod.rs:426), which means this index builds under a write-blocking lock at startup on exactly the populated nodes this PR targets, for no current benefit. Ship the column now and add the index in #143 next to the query that reads it. -
[P2] Expose owner_did on the repo-scoped events feed
crates/gitlawb-node/src/api/events.rs:116
list_ref_updatesreturnsowner_didnow, but thegossip_eventsblock inlist_repo_eventsomits it, soGET /api/v1/repos/{owner}/{repo}/eventssilently drops the field. Add"owner_did": u.owner_didto thatjson!block to match line 38. -
[P2] Carry owner_did through the GraphQL query and subscription
crates/gitlawb-node/src/graphql/types.rs:52
RefUpdateTypeandRefUpdateBroadcast(state.rs:12) have noowner_did, so theref_updatesquery (query.rs:61) and the subscription drop it while REST exposes it. Addowner_did: Option<String>to both structs and populate it at query.rs, subscription.rs, and the broadcast send in repos.rs. -
[P2] Add an existing-node upgrade test for v10
crates/gitlawb-node/src/db/mod.rs:3200
migration_v10_creates_owner_did_columnruns only a fresh v1..v10 chain, which can't catch DDL appended to an already-applied version. Seedschema_migrationswith v1..v9 and areceived_ref_updateswithout the column, thenmigrate()and assert the column, index, and v10 row appear. I ran exactly this against the head and it passes; the same body fails when the DDL sits back in v1, so it is the missing regression guard, not a live bug.
One forward note for #143, not a blocker here: the wire owner_did is attacker-controlled (the peer signature authenticates the relaying node, not this field) and is stored verbatim. Every authorization path today reads the trusted record.owner_did from the local repo row, so nothing consumes the wire value yet, but the gate must cross-check it against a trusted source and must not fall back to the lossy last-segment / did_matches matcher the full DID exists to avoid.
@Gravirei migration fix verified, thanks. The above are plumbing-consistency and deploy-window items.
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
crates/gitlawb-node/src/db/mod.rs (2)
3207-3218: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winAssert the column is actually nullable.
The tests fetch
is_nullablebut only assert the name/type. Since older peers can omitowner_did, please assert"YES"so a futureNOT NULLchange is caught.Proposed fix
assert_eq!(col.0, "owner_did"); assert_eq!(col.1, "text"); + assert_eq!(col.2, "YES");Apply the same assertion in both migration tests.
Also applies to: 3274-3284
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@crates/gitlawb-node/src/db/mod.rs` around lines 3207 - 3218, The migration tests for received_ref_updates currently verify owner_did exists and is text, but they ignore the fetched is_nullable value. Update both migration test blocks that query information_schema.columns in db::mod to assert the third tuple field from sqlx::query_as is "YES" alongside the existing name/type checks, so changes to nullable behavior are caught.
2103-2107: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick winPreserve later
owner_didenrichment on duplicate ref-update IDs.With
ON CONFLICT(id) DO NOTHING, a mixed-version network can store the olderNonepayload first and ignore a later duplicate carrying the full owner DID, leaving the feed unable to disambiguate that event.Proposed fix
(id, node_did, pusher_did, repo, ref_name, old_sha, new_sha, timestamp, cert_id, received_at, from_peer, owner_did) VALUES ($1,$2,$3,$4,$5,$6,$7,$8,$9,$10,$11,$12) - ON CONFLICT(id) DO NOTHING", + ON CONFLICT(id) DO UPDATE + SET owner_did = COALESCE(received_ref_updates.owner_did, EXCLUDED.owner_did) + WHERE received_ref_updates.owner_did IS NULL + AND EXCLUDED.owner_did IS NOT NULL",🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@crates/gitlawb-node/src/db/mod.rs` around lines 2103 - 2107, The INSERT into received_ref_updates currently uses ON CONFLICT(id) DO NOTHING, which prevents a later duplicate from enriching an earlier row with owner_did. Update the upsert logic in the received ref-update insert path so duplicates with the same id can fill in a missing owner_did while still avoiding overwriting existing non-null data. Refer to the received_ref_updates insert statement and the surrounding db write function that persists ref updates.
🧹 Nitpick comments (1)
crates/gitlawb-node/src/db/mod.rs (1)
4096-4129: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winAdd a same-slug owner collision regression.
This test uses different
repovalues, so it does not cover the PR’s core case: two updates with the same trailing repo slug but different fullowner_didvalues. Add a row pair likealice/myrepo+did:web:host:aliceandalice/myrepo+did:gitlawb:alice.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@crates/gitlawb-node/src/db/mod.rs` around lines 4096 - 4129, The current `list_repo_ref_updates_filters_by_repo` test only verifies filtering by full repo name, not the same-slug owner collision case. Update this test in `db` to insert two ref updates with the same trailing repo slug but different full owner identifiers, using the existing `insert_ref_update`, `update`, and `list_repo_ref_updates` helpers, and assert the query returns the correct row for each full repo owner path. Keep the original repo-filter assertions if helpful, but add coverage for the `owner_did` collision scenario the PR is targeting.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@crates/gitlawb-node/src/api/events.rs`:
- Line 130: The event payload in list_repo_events is only populating owner_did
for gossipsub events, so local cert events in the same feed remain inconsistent.
Update the local event mapping in events.rs to also set owner_did from
record.owner_did, keeping the repo-scoped payload shape consistent with the
existing gossipsub path and preserving consumers that dedup or gate on the full
owner DID.
---
Outside diff comments:
In `@crates/gitlawb-node/src/db/mod.rs`:
- Around line 3207-3218: The migration tests for received_ref_updates currently
verify owner_did exists and is text, but they ignore the fetched is_nullable
value. Update both migration test blocks that query information_schema.columns
in db::mod to assert the third tuple field from sqlx::query_as is "YES"
alongside the existing name/type checks, so changes to nullable behavior are
caught.
- Around line 2103-2107: The INSERT into received_ref_updates currently uses ON
CONFLICT(id) DO NOTHING, which prevents a later duplicate from enriching an
earlier row with owner_did. Update the upsert logic in the received ref-update
insert path so duplicates with the same id can fill in a missing owner_did while
still avoiding overwriting existing non-null data. Refer to the
received_ref_updates insert statement and the surrounding db write function that
persists ref updates.
---
Nitpick comments:
In `@crates/gitlawb-node/src/db/mod.rs`:
- Around line 4096-4129: The current `list_repo_ref_updates_filters_by_repo`
test only verifies filtering by full repo name, not the same-slug owner
collision case. Update this test in `db` to insert two ref updates with the same
trailing repo slug but different full owner identifiers, using the existing
`insert_ref_update`, `update`, and `list_repo_ref_updates` helpers, and assert
the query returns the correct row for each full repo owner path. Keep the
original repo-filter assertions if helpful, but add coverage for the `owner_did`
collision scenario the PR is targeting.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 9f70fb07-7129-4c96-9e77-7b2943106a56
📒 Files selected for processing (7)
crates/gitlawb-node/src/api/events.rscrates/gitlawb-node/src/api/repos.rscrates/gitlawb-node/src/db/mod.rscrates/gitlawb-node/src/graphql/query.rscrates/gitlawb-node/src/graphql/subscription.rscrates/gitlawb-node/src/graphql/types.rscrates/gitlawb-node/src/state.rs
🚧 Files skipped from review as they are similar to previous changes (1)
- crates/gitlawb-node/src/api/repos.rs
beardthelion
left a comment
beardthelion
left a comment
There was a problem hiding this comment.
Re-reviewed on 63ab6015. All four items from my last pass are in, CodeRabbit's local-cert-events fix landed, and I verified the security- and deploy-relevant paths by execution:
-
Migration, both ways: on a simulated existing node (v1..v9 recorded, no
owner_didcolumn),migrate()adds the column and records v10; moving that DDL back into the already-applied v1 makesmigration_v10_existing_node_upgradefail (RowNotFound) while the fresh-DB test still passes, so the upgrade guard is load-bearing. A pre-upgrade row (owner_didNULL, since the ALTER has no default) round-trips through the feed as JSON null, no 500. The index is correctly deferred to #143. -
Feed provenance, executed: the repo-scoped feed's local block carries the trusted
record.owner_did, and the gossip block echoes the stored wire value verbatim, which I confirmed with a spoofedowner_didsurfacing unchanged (display-only, nothing filters on it). All fourreceived_ref_updatesSELECTs projectowner_did, so the shared row mapper never hits a missing column. The global feed and GraphQL (query, subscription, broadcast) carry the field through as a passthrough. -
[P3] The stored
received_ref_updates.owner_didis attacker-controlled (the peer signature authenticates the relaying node, not this field, andnotify_syncaccepts it unsigned by default) and is echoed verbatim, as the spoof test shows. It is display-only and nothing gates on it, so not a break. A short comment at the two ingest sites (p2p/mod.rs,api/peers.rs:398) marking the column untrusted would keep #143's DID-aware feed gate from consuming it as trusted; that gate must reconcile it against the repo slug or a verified cert.
@Gravirei the P2s and the migration all check out, thanks. @kevincodex1 this is ready.
|
hello @Gravirei kindly rebase to main and fix conflicts |
Gravirei
force-pushed
the
fix/issue-144-full-did-wire-slug
branch
from
63ab601 to
b46005b
Compare
beardthelion
dismissed
their stale review
Stale after the rebase to b46005b; re-reviewing the new head.
beardthelion
left a comment
beardthelion
left a comment
There was a problem hiding this comment.
Re-reviewed on b46005bf. The owner_did work (#144) is solid: owner_did is carried on all four emit paths, the shared received_ref_updates mapper and migration v10 line up, and the feed gate never trusts the stored value. But the rebase onto 0.5.0 pulled api/ipfs.rs backward relative to main and reintroduces an unauthenticated availability regression, so I can't approve this head.
Findings
-
[P1] Restore the pre-walk object-existence check on
GET /ipfs/{cid}
crates/gitlawb-node/src/api/ipfs.rs(get_by_cid)
Current main (via #133,466a550) runsstore::object_typeandcontinues before the reachability walk, so a random CID can't trigger a full-history walk on repos that don't hold the object. This branch removes that guard and runsallowed_blob_set_for_caller(git rev-list --all+ a per-commitls-tree) beforeread_object. The route isoptional_signatureand unthrottled, andget_by_ciditerates the fulllist_all_repos(), so one anonymous request with an absent CID walks every public path-scoped repo's history. I reproduced it: an anon request for an object not in the repo fires the walk on this head and fires zero on main. Restore main'sobject_typepre-filter, or gate the walk behind an indexed proof the object is present. -
[P2] Drop the
/ipfs/{cid}change from this PR
crates/gitlawb-node/src/api/ipfs.rs
d995c4deis a ~150-line ipfs gate revision unrelated to #144, and main already carries #133. Rebasing onto current main to drop it (keeping main'sipfs.rs) removes both the P1 and the scope creep in one move. -
[P2] Correct the docstring claiming owner_did feeds the feed gate
crates/gitlawb-node/src/p2p/mod.rs:42
The comment says owner_did was added "so the feed gate can distinguish different DID methods that share the same trailing segment," butvisibility::ref_update_row_names_repomatches onrow_repoplus the local record and collapses both via.split(':').next_back(), never reading the wire owner_did. The field is additive display/storage today. Either wire owner_did into the matcher or fix the doc so it doesn't imply that collision is closed. -
[P3] Exercise the real v9 to v10 upgrade over populated data
crates/gitlawb-node/src/db/mod.rs(migration_v10_creates_owner_did_column)
The test runs the full v1..v10 chain on a fresh pool; nothing seedsschema_migrationsat v9 with existingreceived_ref_updatesrows before applying v10. The migration is safe (ADD COLUMN IF NOT EXISTS, nullable, Option readers), so this is coverage rather than a defect. A test that migrates to v9, inserts a row without owner_did, then applies v10 and assertsowner_did IS NULLpins the actual upgrade path. -
[P3] Don't render peer-supplied owner_did as authoritative
crates/gitlawb-node/src/api/events.rs:261
Gossip and notify rows store owner_did verbatim off the wire with no signature binding it to the owner's key, and the feed echoes it. It isn't an authz break (the gate uses the matched local record, never the stored value) and it's the same spoofable class aspusher_did/node_did, but rendering the display owner from the local record for locally-known rows would close it.
The owner_did core is ready; the ipfs regression is the only merge blocker. @Gravirei recommend rebasing onto current main to drop d995c4de and pick up the #133 ipfs gate.
Gravirei
force-pushed
the
fix/issue-144-full-did-wire-slug
branch
from
b46005b to
1ddbc5b
Compare
jatmn
left a comment
jatmn
left a comment
There was a problem hiding this comment.
I found a couple of review-feedback/test issues that need to be addressed before this is ready.
Findings
-
[P2] Make the v10 migration test actually start from a v9 schema
crates/gitlawb-node/src/db/mod.rs:3320
This test says it simulates an existing v9 node, but it first runsdb.migrate(), which applies v10 and createsreceived_ref_updates.owner_didbefore the test deletes and reseedsschema_migrationsat v9. The later insert withoutowner_didtherefore runs against a table that already has the new column, so the test would still pass if the upgrade path being claimed here was not actually exercised. Please build the pre-v10 schema without applying migration 10 first, or explicitly drop the new column/index before the reseed, then apply v10 and assert the old populated row survives withowner_did IS NULL. -
[P3] Complete CodeRabbit's owner_did feed assertion
crates/gitlawb-node/src/test_support.rs:2432
CodeRabbit's request to exposeowner_didin/api/v1/events/ref-updatesis marked addressed, and the handler now serializes the field, but the end-to-end test still only asserts the returnedrepo. Since the row inserted above hasowner_did: Some(owner.into()), this test would pass even if the API regressed to omitting the new field again. Please complete that review item by assertingevents[0]["owner_did"]matches the inserted owner DID.
jatmn
left a comment
jatmn
left a comment
There was a problem hiding this comment.
Thanks for the update. I found one remaining issue that needs to be addressed before this is ready.
Findings
- [P2] Defer the unused owner_did index until the gate query lands
crates/gitlawb-node/src/db/mod.rs:834
Migration v10 createsidx_ref_updates_owner, but this PR only stores and projectsreceived_ref_updates.owner_did; no current query filters, joins, or orders that table byowner_did. Since migrations run inside a transaction here, this index cannot be built concurrently, so existing nodes with populated ref-update tables take avoidable write-blocking startup work for no current read path. Please ship just the nullable column in this plumbing PR, then add the index in the follow-up that actually consumesowner_didfor the feed gate.
jatmn
left a comment
jatmn
left a comment
There was a problem hiding this comment.
I found one issue to address.
Findings
- [P2] Do not resolve
owner_didfrom the lossy repo slug alone
crates/gitlawb-node/src/api/events.rs:145
The global REST feed overrides a row's storedowner_didwheneverref_update_row_names_repo(record, u.repo)matches a local repo, but that matcher intentionally collapses both owners to the trailing DID segment. If this node hosts a readabledid:web:host:alice/widgetand receives a remote row fordid:gitlawb:alice/widgetwith the legacyreposlugalice/widget, the visibility gate keeps the row because the local repo is public, then the response rewrites itsowner_didtodid:web:host:alice. That loses the full owner DID this PR is adding for same-slug disambiguation. GraphQL has the opposite drift (query.rs:86still returns the stored wire value directly), so the two global feeds can disagree for the same row. Please include the newowner_didin the local-record resolution before replacing it withrecord.owner_did, and share or mirror that projection in GraphQL with an assertion for the exactownerDidvalue.
jatmn
left a comment
jatmn
left a comment
There was a problem hiding this comment.
Thanks for the update. I rechecked the previously discussed owner_did, migration, REST, and GraphQL paths and do not see any remaining actionable code issues from my side.
GitHub still reports this PR as blocked even though it is mergeable and the visible checks are passing, so there may be a remaining branch-protection or review-state item for maintainers to clear.
@kevincodex1 LGTM
beardthelion
left a comment
beardthelion
left a comment
There was a problem hiding this comment.
Re-reviewed the new head 1074aa4; refreshing my earlier approval, which sat on 093a3c0.
The change since then resolves the owner_did display divergence: both the REST feed and GraphQL now prefer the stored wire owner_did and fall back to a local lookup only for legacy rows with no stored owner, so the two surfaces agree. I verified the security-relevant behavior by execution against a local Postgres, not by reading:
- The wire owner_did is display-only, never a visibility input. A ref-update row carrying a spoofed owner_did is dropped for anonymous callers and for a caller authenticated as the spoofed DID; only the real owner sees it, with the spoofable value merely displayed. Reverting the gate's fail-closed arm flips that to a leak, so the gate is load-bearing.
- The local fallback cannot surface a private owner. A slug that collides on the loose owner matcher fails closed when the collision partner is a private repo the caller cannot read (verified the cross-method did:gitlawb vs did:key case drops the row for anon), and where the collision is the same key in two DID spellings the dedup resolves to the owner's public repo, so the displayed owner is always one the caller can already list.
- The migration nullability assertion from last round is in.
A few non-blocking follow-ups, none of which need to hold this:
- The feed handlers load list_all_repos_deduped() twice per request (once in the collector, once for the owner_did projection) on both REST and GraphQL. Threading the collector's set through would drop the redundant query on the hot feed path.
- The fallback resolves by first match over that query, whose outer ORDER BY has no id tiebreaker, and REST and GraphQL query it separately. For legacy no-owner rows under a tied updated_at plus a name collision the two surfaces can still pick different owners. A stable tiebreaker (and sharing the set, per the point above) closes it.
- A peer's empty or malformed wire owner_did is shown verbatim, since the fallback only applies to a missing value. Treating an empty string as missing would recover the local owner.
@kevincodex1 good to merge.
|
hello @Gravirei please rebase to main and fix conflicts |
Gravirei
force-pushed
the
fix/issue-144-full-did-wire-slug
branch
from
1074aa4 to
4d37b11
Compare
beardthelion
left a comment
beardthelion
left a comment
There was a problem hiding this comment.
Re-reviewed on dbfb0a1. Approving. I verified the security-critical properties by execution on this head.
The wire owner_did is display-only and the gate does not trust it: I seeded a private local repo and a received_ref_updates row naming it with a forged owner_did, drove the global feed as anon, and the private row stays dropped. A public repo's row with the same forged owner_did is shown with the forged value echoed. So a peer cannot use owner_did to unlock a private row, only to mislabel a public one on the feed. The shared row mapper reads owner_did as Option, so a backward-compat NULL row round-trips as None with no panic (insert_and_list_without_owner_did covers it). The v10 migration is a new highest-version block, nullable and idempotent, and its upgrade-path test genuinely starts from a v9 schema. All four emit paths carry owner_did, and I confirmed the HTTP-notify path stores it end-to-end.
Two non-blocking notes:
- The feed echoes the wire owner_did verbatim even on rows that name a local repo this node hosts, where the true owner is already known from the record. It is display-only and joins the feed's existing untrusted peer fields (pusher_did, node_did, from_peer), so it is not a gate issue, but for local-matching rows preferring record.owner_did would avoid displaying a peer's claim over a fact the node holds. This reflects the prefer-wire resolution from an earlier round, so treat it as a judgment call rather than a required change.
- Thin emit-path coverage: the notify_sync tests do not assert owner_did is stored, so a revert of the binding would pass all of them, and the REST None-fallback branch and the subscription projection are untested. The behavior is correct, but a regression in those paths would not be caught.
@kevincodex1 good to merge.
beardthelion
dismissed stale reviews from themself
Stale approval on an earlier head; superseded by my re-review on dbfb0a1.
|
hello @Gravirei please rebase to main and fix conflicts |
Gravirei
force-pushed
the
fix/issue-144-full-did-wire-slug
branch
from
dbfb0a1 to
58d5c76
Compare
|
hello @Gravirei please rebase to main again and fix conflicts |
beardthelion
left a comment
beardthelion
left a comment
There was a problem hiding this comment.
The owner_did wire plumbing is sound: it's display-only (projected after the visibility gate, which keys on the local repo record, never the peer-supplied wire value), the migration is a correct new v10 with a load-bearing upgrade test, and all four fan-out paths carry the field. Two things still gate merge.
The branch conflicts with main, and its base predates #149 (list_ref_certificates bound + upsert) and #180 (per-IP creation rate-limit), both of which touch the same files this PR does (events.rs, repos.rs, db/mod.rs, state.rs, test_support.rs). Please rebase onto current main and fix the conflicts; the resolved diff needs another pass, because a careless resolution on those files silently drops one of those merged gates.
Findings
-
[P2] Drop the per-request full-repo dedup on the ref-updates feed
crates/gitlawb-node/src/api/events.rs:144,crates/gitlawb-node/src/graphql/query.rs:80
list_ref_updatesand therefUpdatesresolver calllist_all_repos_deduped()for the display fallback, butcollect_visible_ref_updatesalready loaded that exact set, so the full-repos-table dedup CTE runs twice per request. The second load is also unconditional: it fires even when every returned row already carries a wireowner_didand the fallback is never consulted, which is the steady state once peers upgrade. The endpoint is anonymous, so a permissionless caller drives two full-table scans per hit, scaling with node repo count rather than the (<=200) rows returned. Thread the set the collector already holds through to the handler, and gate the fallback load onupdates.iter().any(|u| u.owner_did.is_none()). -
[P3] Resolve the display owner with an exact key match, not the fail-safe gate matcher
crates/gitlawb-node/src/api/events.rs:147,crates/gitlawb-node/src/graphql/query.rs:85
The fallback picks the first record matchingref_update_row_names_repo, a deliberately loose prefix matcher built for the visibility gate (where over-matching fails safe). For display it mis-attributes: a legacy row naming ownerzXis shown with the owner of any local repo whose key prefixeszX. This is cosmetic only (the private-match case is withheld by the gate rather than disclosed) and affects legacy pre-#144 rows only. Resolve with the canonicalnormalize_owner_keyand require a unique match, skipping on ambiguity.
…mprove migration test, use local owner_did
…omplete owner_did API assertion
…ion test, add owner_did echo assertions
…ion; mirror projection in GraphQL
Gravirei
force-pushed
the
fix/issue-144-full-did-wire-slug
branch
from
58d5c76 to
2107633
Compare
beardthelion
dismissed
their stale review
Superseded by a fresh re-review on the current head (2107633).
beardthelion
left a comment
beardthelion
left a comment
There was a problem hiding this comment.
Re-reviewed the current head. The owner_did wire plumbing is sound, and I re-verified the security-critical property by execution on this head rather than reading it: the wire owner_did is display-only and never a visibility-gate input. Driving a forged wire owner_did that names a private repo through the resolver, the row stays dropped for anon and for a caller authenticated as the forged DID, and only the true owner sees it; forcing the gate open flips it to a leak, so the gate is load-bearing. The rebase is clean, #149's list_ref_certificates bound and #180's per-IP creation limiter both survive (verified by their tests). Migration is a correct new v11 (nullable, idempotent) with a load-bearing upgrade test, all four emit paths carry owner_did, and the shared mapper round-trips a null owner_did with no panic.
One item from my last pass is still open, plus two small ones.
Findings
-
[P2] Drop the redundant per-request repo dedup on the ref-updates feed.
crates/gitlawb-node/src/api/events.rs:145,crates/gitlawb-node/src/graphql/query.rs:80—collect_visible_ref_updatesalready loadslist_all_repos_deduped()for the gate (events.rs:57), but both handlers load it a second time for the owner_did display fallback, so every anonymous request now runs the full-table dedup CTE twice (one before this PR). The second load is unconditional: it fires even when every returned row already carries a wire owner_did and the fallback is never consulted, which is the steady state once peers upgrade. Thread the set the collector already holds through to the handler, or gate the second load onupdates.iter().any(|u| u.owner_did.is_none()). -
[P3] Resolve the display owner with an exact key match, not the fail-safe gate matcher.
crates/gitlawb-node/src/visibility.rs:229— the legacy-None fallback reusesref_update_row_names_repo, whoserecord_key.starts_with(row_key)is always true when an empty-owner-segment slug (/name) reducesrow_keyto"", so a legacy row can display the wrong owner. Display-only: the same over-match in the gate only ever drops (covered byfeed_empty_owner_slug_matches_and_drops), and it affects only pre-#144 rows stored withowner_did = None. Resolve withnormalize_owner_keyand require a unique match, skipping on ambiguity. -
[P3] Add a regression test for a forged wire owner_did. The existing gate tests forge the slug or set
owner_didtoNone; none drives a forged wireowner_didfield, which is the exact must-not (a peer-supplied owner_did must not unlock a private row). The property holds today, but a permanent test guards a future change that starts keying on the wire value. A drop-in that mirrors the existing resolver tests:#[sqlx::test] async fn forged_wire_owner_did_never_unlocks_private_row(pool: PgPool) { let db = db(pool).await; db.create_repo(&repo("r1", OWNER, "widget", false)).await.unwrap(); // private let mut row = ref_row("u1", "z6MkOwner/widget"); row.owner_did = Some("did:key:z6MkAttacker".into()); // forged wire owner db.insert_ref_update(&row).await.unwrap(); let schema = schema(db); let q = r#"{ refUpdates(repo: "z6MkOwner/widget") { refName ownerDid } }"#; assert_eq!(count(&anon(&schema, q).await), 0); assert_eq!(count(&authed(&schema, q, "did:key:z6MkAttacker").await), 0); assert_eq!(count(&authed(&schema, q, OWNER).await), 1); }
I ran this against the branch (passes) and against a fail-open gate (fails), so it is load-bearing.
The core is solid and the security properties hold. The P2 is the one I'd want fixed before merge, and it's a small change; the two P3s are polish.
jatmn
left a comment
jatmn
left a comment
There was a problem hiding this comment.
I found issues that need to be addressed before this is ready.
Findings
-
[P1] Restore the iCaptcha PoW protocol support before merging
crates/icaptcha-client/src/lib.rs:194
This head is behind the current PR base and removes theChallenge.powfield, its solver, andpowNoncefrom the/v1/answerrequest (as well as deletingpow.rs). A PoW-enabled iCaptcha service therefore has its requiredpowextension silently ignored and receives only{token, answer}, so it rejects the solve andglcannot mint a proof for register/repository-create/fork writes. Rebase onto currentmainand preserve the optional PoW parsing, solving, nonce submission, and regression coverage. -
[P1] Keep iCaptcha key trust scoped to the full origin
crates/icaptcha-client/src/lib.rs:110
x-icaptcha-urlis controlled by the node, but the newhost_ofcomparison accepts any HTTPS port on the configured operator host and marks itkey_trusted. For example, an operator configured withhttps://icap.example:443can be redirected tohttps://icap.example:8443; both challenge and answer requests then sendGITLAWB_ICAPTCHA_API_KEYto that distinct listener. The base implementation compared scheme, host, and effective port specifically to prevent this. Restore full-origin matching for both acceptance and bearer-key attachment. -
[P2] Return the received event's owner DID on the repo-scoped feed
crates/gitlawb-node/src/api/events.rs:284
The new field is stored onReceivedRefUpdate, and the global REST and GraphQL feeds prefer that wire value, but this projection unconditionally substitutesrecord.owner_did. A received row whose slug collides with a hosted repo is consequently reported as owned by the local record rather than by its stored full DID—the exact identity ambiguity this change is intended to carry. Projectu.owner_didwhen present and use the local value only as the legacy-Nonefallback, with a collision regression test. -
[P2] Do not perform a second full repository-dedup scan for every feed read
crates/gitlawb-node/src/api/events.rs:145
collect_visible_ref_updatesalready loadslist_all_repos_deduped()for its visibility gate, but the new REST projection immediately loads it again for the legacy fallback; the GraphQL resolver repeats the same pattern. This doubles the full-repository scan on every anonymous global-feed request even when all bounded result rows already containowner_did. Thread the collector's deduped records through, or load them only if a returned legacy row actually needs fallback resolution.
Summary
Carry the full owner DID on the ref-update wire event so the feed gate can distinguish different DID methods that share the same trailing segment (e.g.
did:web:host:alicevsdid:gitlawb:alice).Motivation & context
Refs #144
The ref-update wire slug was previously constructed from the last colon-segmented component of the owner DID (
{owner_did.split(":").last}/{name}), which is lossy. Two owners with different DID methods but the same trailing segment would produce identical slugs, causing the feed gate to over-drop remote rows for anonymous callers.This PR is the plumbing half of #144: it carries the full owner DID on the wire and stores it in the database so a follow-up can teach the feed gate to use
did_matchesfor proper disambiguation. The gate itself (the second half of #144) will land in a separate change on top of this.Kind of change
What changed
crates/gitlawb-node (gitlawb-node):
p2p/mod.rs: Addedowner_did: Option<String>toRefUpdateEventwith#[serde(default)]for backward compat with older peers that do not include the fielddb/mod.rs: Addedowner_did: Option<String>toReceivedRefUpdate, added migration v10 to addowner_did TEXTcolumn andidx_ref_updates_ownerindex to thereceived_ref_updatestable, updated all SELECT/INSERT queries to include the columnapi/repos.rs: Setowner_did: Some(record.owner_did)when publishing ref-update events over gossip; addedowner_didto the HTTP sync notify bodyapi/peers.rs: Addedowner_didtoNotifyRequestand wired it through toReceivedRefUpdateHow a reviewer can verify
DATABASE_URL=postgresql://gitlawb:changeme@172.19.0.2:5432/gitlawb cargo test -p gitlawb-node cargo fmt --check cargo clippy --workspace --all-targets -- -D warningsBefore you request review
cargo test --workspacepasses locally (327/327)cargo fmt --allandcargo clippy --workspace --all-targets -- -D warningsare cleanfix(...),test(...),style(...)).env.exampleupdated if behavior or config changed (or N/A)Protocol & signing impact
This is a backward-compatible wire-format addition: the new
owner_didfield is#[serde(default)], so events from older peers deserialize without it (owner_did: None). Therepofield format is unchanged. Migration v10 adds the column to existing databases;ADD COLUMN IF NOT EXISTSis idempotent for re-runs.did:key, Ed25519 / RFC 9421 signatures, UCAN, ref certs, or P2P wire formatsSummary by CodeRabbit
New Features
owner_didwhen available.owner_didas optional (omittable).Bug Fixes
owner_didis missing or null in incoming notifications.