Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Subclutser peer list contains peers not in the subcluster #906

Open
garth opened this issue Jan 30, 2024 · 4 comments
Open

Subclutser peer list contains peers not in the subcluster #906

garth opened this issue Jan 30, 2024 · 4 comments

Comments

@garth
Copy link

garth commented Jan 30, 2024

The subcluster peer list often contains peers that have not joined the subcluster. I guess that this might be because they are relaying, but if that is the case I think they should be hidden.

What OS are you using (uname -a, or Windows version)?

Darwin Garths-MacBook-Pro.local 23.2.0 Darwin Kernel Version 23.2.0: Wed Nov 15 21:53:18 PST 2023; root:xnu-10002.61.3~2/RELEASE_ARM64_T6000 arm64

What version Socket Runtime are you using?

0.5.4 (97fa3f7c)
Installation path: /Users/garth/Projects/socket-editor/node_modules/.pnpm/@[email protected]/node_modules/@socketsupply/socket-darwin-arm64/

I also tried this on the latest master branch but the results are the same.

0.5.4 (ef7fb555)
Installation path: /Users/garth/.local/share/socket/

What programming language are you using (C/C++/Go/Rust)?

node --version
v20.11.0

What did you expect to see and what you saw instead?

I would expect that the following would only list peers that have explicitly joined the subcluster.

console.log(
  'current peers',
  Array.from(subcluster.peers.values()).map((peer: any) => peer.peerId),
)

This list often includes additional peers that are not part of the subcluster.

@garth garth changed the title Subcluser peer list contains peers not in the subcluster Subclutser peer list contains peers not in the subcluster Jan 30, 2024
@garth
Copy link
Author

garth commented Jan 30, 2024

It's also worth noting that since we cannot currently use subcluster.emit the following will send messages to peers who should not receive it which could be a potential data leak/security issue?

for (const peer of this.subcluster.peers.values()) {
  peer.emit('message', data)
}

@heapwolf
Copy link
Member

heapwolf commented Jan 30, 2024

only peers with the sharedKey will be able to read the contents of the packet (of course you area able to do whatever cryptography you want to do on top of that). the peers listed on sub cluster should only be members of the sub cluster, if you're trying to create a setup where peers that are removed from the sub cluster are no longer able to read the data, that will be an application level security issue. The protocol can not realistically enforce application level security design.

@garth
Copy link
Author

garth commented Jan 30, 2024

the peers listed on sub cluster should only be members of the sub cluster

The list of peers includes peerIds from outside the cluster.

@heapwolf
Copy link
Member

heapwolf commented Jan 30, 2024

They must have at one point been a member of the cluster though. When a #join event happens, the packet is checked for the corresponding subcluster, if in the case it is a match, the peer is added to the subcluster set.

https://github.com/socketsupply/socket/blob/master/api/stream-relay/sugar.js#L284

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

No branches or pull requests

2 participants