Skip to content

feat: cross-network calls [OpenAgriNet/network-adapter#78] - #84

Open
ameersohel45 wants to merge 4 commits into
feat/76-crawl-admitted-networkfrom
feat/78-cross-network-calls
Open

ameersohel45 wants to merge 4 commits into
feat/76-crawl-admitted-networkfrom
feat/78-cross-network-calls

Conversation

@ameersohel45

@ameersohel45 ameersohel45 commented Oct 15, 2026 •

Copy link
Copy Markdown
Collaborator

Sends a call meant for another network to that network, and refuses one we never agreed to answer.

What

Outbound — routeElsewhere in the capability step, before its binding check. If context.receiverId is not this module's own id, the network must be admitted as a source or the call is refused; otherwise it routes to context.bppUri plus the action, signed as us. StepContext gains OwnSubscriberID for this, because SubID comes from the body and is them.

Inbound — agreedToGiveTo in the registry plugin refuses a signing key to a caller we did not admit as a requester, so the call dies at validateSign. Off unless crossNetworkCheck is set.

Subset — a discover naming a capability outside the agreement is refused, as is one naming none. Discover only: no other action carries context.schemaContext.

Also: services.discovery is called as published, not appended to.

Why

A binding key names the upstream, not the network fronting it, so two networks fronting one upstream hold identical keys. Checking the binding first would answer another network's call with our data.

Each check sits where a config cannot omit it: inside the capability step, and inside the key lookup.

Testing

Both directions, each refusal, the shared-binding case, a cached key judged like a fetched one, and every non-discover action passing untouched. Run end to end on two local networks.

@github-actions

github-actions Bot commented Oct 15, 2026 •

Copy link
Copy Markdown

🛡️ Trivy security scan (CRITICAL,HIGH,MEDIUM,LOW)

View full run

Go dependencies

Package Severity Installed Fixed in Advisory
github.com/getkin/kin-openapi HIGH v0.144.0 0.146.0 CVE-2026-100349
github.com/getkin/kin-openapi HIGH v0.144.0 0.147.0 CVE-2026-100351
github.com/getkin/kin-openapi HIGH v0.144.0 0.148.0 CVE-2026-100352
github.com/getkin/kin-openapi HIGH v0.144.0 0.149.0 CVE-2026-100353
github.com/getkin/kin-openapi HIGH v0.144.0 0.149.0 CVE-2026-100354
github.com/getkin/kin-openapi MEDIUM v0.144.0 0.145.0 CVE-2026-100347
github.com/getkin/kin-openapi MEDIUM v0.144.0 0.145.0 CVE-2026-100348

Container image

No findings at CRITICAL,HIGH,MEDIUM,LOW.

@github-actions

github-actions Bot commented Oct 15, 2026 •

Copy link
Copy Markdown

📊 Test Coverage: ✅ Passed — 87% of changed lines covered, min 80%

@ameersohel45 ameersohel45 changed the title feat: send a call addressed to another network to that network [OpenAgriNet/network-adapter#78] feat: let two networks call each other, only where we agreed [OpenAgriNet/network-adapter#78] Oct 15, 2026
@ameersohel45 ameersohel45 changed the title feat: let two networks call each other, only where we agreed [OpenAgriNet/network-adapter#78] feat: cross-network calls [OpenAgriNet/network-adapter#78] Oct 15, 2026
@ameersohel45
ameersohel45 force-pushed the feat/78-cross-network-calls branch from 3014237 to b19ebe8 Compare October 15, 2026 19:19
A select naming another network's provider arrives at our provider module
like any other. The capability step now asks who it is for before it asks
whether it has a binding for it -- a binding key names the upstream, so two
networks fronting the same upstream hold identical keys and the binding check
cannot tell them apart.

Outbound: context.receiverId is compared against the module's own configured
id, never the one reqpreprocessor resolved from the body -- on a request
addressed to another network that one is THEM. A receiver that is not us must
be a network we admitted as a source, or the request is refused. It goes to
context.bppUri plus the action, signed as us.

Inbound: the registry refuses to hand back a signing key for a network we did
not admit as a requester, so the request dies at validateSign rather than
reaching any capability. The check lives there and not in a step because a
step can be left out of a config, and a signature check cannot proceed without
the key. Off unless crossNetworkCheck is set, so a deployment that federates
with nobody behaves exactly as before.

A participant with no federationRole is an ordinary caller -- a farmer's app
-- and is served as it always was.
federationRole becomes a direction-keyed object, so an agreement says which way
it runs and which packs it covers.

A discover is refused if it names a pack we did not agree to give. Every other
action is governed by the direction alone, because only a discover carries
context.schemaContext.
@ameersohel45
ameersohel45 force-pushed the feat/78-cross-network-calls branch from b19ebe8 to c42d8ae Compare October 17, 2026 17:51
services.discovery names the discover endpoint, not a mount to append an action
to, so a network may serve it from any path. Appending turned the architecture
doc's own example into /federation/discovery/discover.
]

A pack URL names the attributes document and the context document beside it is
what a discover asks for, so the suffix is swapped. An agreement recorded with
the context document already was having a second one appended, and one with no
filename at all lost its separator. Both produced a URL matching nothing, on
the asking side and on the comparison side, with no error anywhere.
kelvinprabhu added a commit that referenced this pull request Oct 22, 2026
github.com/getkin/kin-openapi v0.144.0 -> v0.149.0 (used by
schemav2validator). Clears code scanning alerts #78-#84:

- CVE-2026-100351 (HIGH)   auth bypass via URL path decoding discrepancy
- CVE-2026-100349 (HIGH)   DoS via nil pointer deref in response validation
- CVE-2026-100352 (HIGH)   DoS via non-finite number handling
- CVE-2026-100353 (HIGH)   DoS via nil pointer deref in request validation
- CVE-2026-100354 (HIGH)   DoS via unbounded schema recursion
- CVE-2026-100347 (MEDIUM) DoS via unsupported HTTP methods on static routes
- CVE-2026-100348 (MEDIUM) fixed in 0.145.0

Transitive: santhosh-tekuri/jsonschema/v6 v6.0.2 -> v6.0.3.

Refs #85
@manjudr
manjudr added this pull request to stack #89 October 22, 2026 11:34
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