Repository navigation
feat: cross-network calls [OpenAgriNet/network-adapter#78] - #84
Open
ameersohel45 wants to merge 4 commits into
Open
ameersohel45 wants to merge 4 commits into
ameersohel45 wants to merge 4 commits into
Conversation
🛡️ Trivy security scan (CRITICAL,HIGH,MEDIUM,LOW)Go dependencies
Container imageNo findings at CRITICAL,HIGH,MEDIUM,LOW. |
|
📊 Test Coverage: ✅ Passed — 87% of changed lines covered, min 80% |
ameersohel45
force-pushed
the
feat/78-cross-network-calls
branch
from
October 15, 2026 19:19
3014237 to
b19ebe8
Compare
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
force-pushed
the
feat/78-cross-network-calls
branch
from
October 17, 2026 17:51
b19ebe8 to
c42d8ae
Compare
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.
3 tasks
] 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
added this pull request to stack #89
October 22, 2026 11:34
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Sends a call meant for another network to that network, and refuses one we never agreed to answer.
What
Outbound —
routeElsewherein the capability step, before its binding check. Ifcontext.receiverIdis not this module's own id, the network must be admitted as a source or the call is refused; otherwise it routes tocontext.bppUriplus the action, signed as us.StepContextgainsOwnSubscriberIDfor this, becauseSubIDcomes from the body and is them.Inbound —
agreedToGiveToin the registry plugin refuses a signing key to a caller we did not admit as a requester, so the call dies atvalidateSign. Off unlesscrossNetworkCheckis 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.discoveryis 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.