Vouch request: davidpeden3 #658
Closed
davidpeden3
started this conversation in
Vouch Request
Replies: 2 comments
-
|
/vouch |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
@davidpeden3 has been vouched by @johntmyers. You can now submit pull requests to OpenShell. Welcome aboard. Please read CONTRIBUTING.md before submitting. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
What do you want to work on?
i want to fix #652. i believe my solution will also address the second failure mentioned in NVIDIA/NemoClaw#409.
i have been working on setting up a mesh network of fully sandboxed openclaw instances (gateway + two nodes). i have installed openshell and openclaw on three different machines (two macs, one windows pc). i was able to fully secure and lockdown the gateway instance. initially, i was unable to get the machines to talk to each other via tailscale (including serve), socat, ssh, etc. i was using claude to help me sort through it. i then also started including grok in the discovery phase. both ais independently determined that all efforts attempted were an exhaustive search and that it just wouldn't work. they both proposed that i run my nodes unsandboxed, claiming it was secure "enough" given the gateway was sandboxed and that the transport layer was still secure via tailscale and wireguard plus gateway token auth.
i refused to compromise and suggested that we should just open an issue. grok then found the similar issue (409 above) and that got me thinking that maybe we could just find/fix it ourselves which is exactly what we did.
Why this change?
this bug will affect anyone that attempts to run a meshed network of openshell/openclaw instances that are fully sandboxed. it will also affect anyone that tries to use websocket-based plugins. the code changes are very targeted and small. the issue is that the unpatched code treats a
101as a bodiless response instead of an upgrade request which means it misinterprets the subsequent bytes over the wire, causing the websocket handshake to fail. so, instead, we look for101first and treat it as a proper upgrade request so that we opt into the bidirectional communication and stop doing http parsing.all 322 existing tests pass and we've added one new test as well that, of course, also passes. not only that, but i built the binary and patched it into my setup (both into the gateway and one of the nodes) and proved that it works. i have forked the repo and put up a pr in my fork that anyone can look at. i would like to formally submit the pr to this repo to fix the issue and help out anyone affected by the bug.
Checklist
Beta Was this translation helpful? Give feedback.
All reactions