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
Flagging this ahead of #70. The current service discovery implementation introduces a mild security concern. While not a vulnerability in and of itself, it is likely to confuse users into introducing vulnerabilities in their applications.
The issue is that the service.Registry capability wraps a pubsub.Router capability, effectively providing an higher level API on top of the pubsub capability. Users could be misled into believing that a principal cannot provide or discover services because they have not been given a service capability of some sort, when in fact, they can still do so if they are able to join arbitrary topics.
Two possible solutions:
Create an entirely separate pubsub mesh for service discovery, and wrap that.
Change the service discovery API to receive Topics as arguments, instead of strings.
In addition to being simpler, it should be noted that option #2 avoids ambient authority in the form of topic strings. The counterpoint, which @aratz-lasa has brought up is that it may be initially confusing to users if the the API operates on topic instances instead of strings. This can be documented, and it also has the benefit of being more transparent w.r.t. underlying mechanics.
TODO: make a call.
The text was updated successfully, but these errors were encountered:
Flagging this ahead of #70. The current service discovery implementation introduces a mild security concern. While not a vulnerability in and of itself, it is likely to confuse users into introducing vulnerabilities in their applications.
The issue is that the
service.Registry
capability wraps apubsub.Router
capability, effectively providing an higher level API on top of the pubsub capability. Users could be misled into believing that a principal cannot provide or discover services because they have not been given a service capability of some sort, when in fact, they can still do so if they are able to join arbitrary topics.Two possible solutions:
Topic
s as arguments, instead of strings.In addition to being simpler, it should be noted that option #2 avoids ambient authority in the form of topic strings. The counterpoint, which @aratz-lasa has brought up is that it may be initially confusing to users if the the API operates on topic instances instead of strings. This can be documented, and it also has the benefit of being more transparent w.r.t. underlying mechanics.
TODO: make a call.
The text was updated successfully, but these errors were encountered: