Looking for a Collaborator/Maintainer - ProxyBridge Linux Version

[Anof-cyber]

Hey everyone,

ProxyBridge supports Windows, macOS, and Linux - but all three are completely separate applications. Same features and goals, but entirely different low-level architecture, language, and implementation for each platform. Maintaining all three solo is getting unsustainable.

I'm looking for someone to own or co-maintain the Linux version - fixing bugs, adding new features, keeping it in sync with what ships on the other platforms, and testing.

Why this is non-trivial

This isn't a port or a wrapper - the Linux version is its own codebase built around Linux-native internals. If you're picking this up, you're taking on a real low-level project, not glue code.

What the role involves

• Bug fixes and issue triage for the Linux version
• Implementing new features as they land on Windows/macOS
• Testing across Linux environments
• Keeping up with the project direction and discussing architecture changes

What I'm looking for

• Strong Linux systems/networking background (netfilter, raw sockets, low-level C or equivalent)
• Someone who can work independently - I can provide context and review, but I can't babysit the codebase
• Consistency over time - this is maintainership, not a one-off contribution

What you get

• Co-maintainer credit on the repo
• Full architecture context and onboarding from me
• I stay involved for reviews and design decisions - you're not on your own

If you're interested, reply here or open a conversation. Questions welcome too.

[1rhino2]

interested in co-maintaining the Linux tree.

background: C / Linux networking (netfilter, sockets). i can own triage, parity with win/mac features, and testing on debian/ubuntu + one rolling distro.

next step on my side: clone, build current linux tree, run through the beta install path, then pick one open linux bug or a parity gap and land a small PR against dev per CONTRIBUTING.

if that looks useful, happy to coordinate ownership of linux here.

[1rhino2]

Im finishing up a PR

[1rhino2]

Follow up on the PR mention: branch is up on my fork. Could not open a PR into dev from here because upstream has pull_request_creation_policy: collaborators_only. Left a tracking issue instead.

Branch: security/linux-relay-config-update on 1rhino2/ProxyBridge
Compare: dev...1rhino2:security/linux-relay-config-update
Issue: #211

Four commits, three files:

1. Relay bind: ports 34010/34011 used INADDR_ANY, now 127.0.0.1 only
2. Config perms: /etc/proxybridge/config.ini was world readable, now dir 0700 file 0600
3. GUI update: stopped curling and executing deploy.sh as root; opens the GitHub release page instead

Happy to rework this as a proper PR if you can flip collaborator access or want to cherry-pick from the fork. Can keep going on Linux triage after that.

[1rhino2]

quick update since my last comment + #211

still interested in co-maintaining Linux.

done since then:

• posted the three linux security fixes (fix(linux): relay bind, config perms, GUI update security #211 / branch security/linux-relay-config-update)
• finished the windows eBPF poc testing (discussion ProxyBridge 4.1.0-Beta Kernel Driver #210 thread)
  • tcp proxy path works
  • udp request redirect works
  • transparent udp reverse source does not without kernel wfp rewrite/reinject
  • so i consider the eBPF lane done and would rather help test / harden the 4.1.0-Beta WFP path next

blocked on: upstream is collaborators_only for PRs, so #211 needs a cherry-pick or collaborator access.

if you want me on linux ownership, next useful step from my side is:

1. get collaborator (or you cherry-pick fix(linux): relay bind, config perms, GUI update security #211)
2. clean VM test of 4.1.0-Beta (install/start/stop/reboot/uninstall + tcp/udp direct/block/proxy)
3. keep triage on linux issues

happy to take direction on what you want first.

[Anof-cyber]

I have got time to look into Linux part yet. I am interested in ebpf part.

Initial linux development started with ebpf only. The problem i faced was memory limitations on ebpf kernel mode.

Goal was to keep packet with direct connection on kernel only and never move them to user space. But ebpf has limited memory and cannot use proxy rules there means all packets has to be diverted to user mode or relay server. Even packet that has no proxy rule no Proxy needed also routed via relay.

Unwanted delay on network, latency issue. Unwanted cpu and memory load due to all traffic going via relay server.

I would love to know how thats works with ebpf solution if you are working on it.

[1rhino2]

windows poc, not linux tree yet. but yeah same pain you hit.

what worked for me:
DIRECT and BLOCK stay in kernel / never touch the relay.
only PROXY gets redirected to user-mode relay.

that was the whole point. if every packet goes through relay you eat latency and cpu for free, even when the rule is direct.

tcp proxy path was fine.
udp request redirect was fine.
udp reverse source transparency was not - response came back as the relay port. needs real kernel rewrite/reinject for that, so i stopped pushing eBPF for full transparent udp on windows.

so eBPF as classify + cheap DIRECT/BLOCK/PROXY switch = useful.
eBPF as the place for full rule tables + heavy flow state = bad, same memory wall you hit.

still want linux. want the design writeup for linux eBPF next, or get #211 in first?

[Anof-cyber]

Linux version is something i am looking some solution right now. It was released but never updated. The core implementation is similar to windows one but i am not 100% sure if that approch is is good enough for long run. Or Ebpf is possible on linux side in same way so only proxy packets goes via relay.

I think windows side best option is via WFP with own kernel which gives much more flexibility, performance and speed. Probably the Windows version will move with ProxyBridge own kernel driver. Maybe a seperate project similar to Windivert, another opensource windows WFP kernel based on WFP ALE Layer.

[1rhino2]

yeah that tracks with what i saw on the windows poc. WFP / own driver is the right long-term windows bet if you want full control and transparent udp. eBPF there was fine for classify + tcp proxy smoke, not for the whole product.

on linux i think eBPF can do the "only PROXY hits relay, DIRECT stays in kernel" shape. maps for process/rule lookup stay small; heavy proxy work stays user-mode. thats different from stuffing the whole rule engine into bpf memory.

current linux tree being stuck on the old divert-everything path is why it feels dead-end-ish for the long run.

i can poke the linux tree and sketch that hybrid (what stays bpf vs relay) against the existing code. still want the linux seat if youre filling it. #211 is sitting whenever you want it cherry-picked.