Are you concerned at all how the Wireguard thing is playing out vs your desire to see this stuff open sourced?
If you mean "Warp doesn't support generic clients", I commented about that over on the Reddit thread: https://old.reddit.com/r/programming/comments/b9sznr/im_join...
If you mean "CloudFlare pursued BoringTon outside of the general WireGuard project", well, I don't have any real insight into the specifics of why that was chosen, but it seems extremely open source to me. As far as I know, BoringTon is just an implementation of a protocol. There's a ton of reasons to want to do things on your own rather than work on upstream. And if anything, for protocols, independent implementations can be a good thing, more than a bad thing.
If you mean something else, well, I'm not sure, those are the only ones I can remember :p
Your previous rooting interest in this story would have been for Rust itself. And Rust itself would have been been best served by having it host the dominant sanctioned userland implementation of WireGuard, not merely as an implementation detail for a commercial offering that also treats WireGuard as yet another implementation detail. Rust? Important! WireGuard? Important! Warp? Who gives a fuck?
So this is a bit of a surprising response to see from you.
Apologies for the late edit:
I should lay my own cards on the table here.
First, it's not much of a secret that I'm no fan of big Flare. But just to be clear: good friends of mine have worked there, and several other people I deeply respect have as well, and I don't judge any of them for that.
Much more importantly: Jason Donenfeld is, to my mind, the hardest working person in show business, and he's set himself on one of the most important projects in network security, basically all on his own, and the momentum he's managed to achieve doing that is insane and a little inspiring --- especially given the amount of shade he's been repaid with by network security luminaries --- and basically the last thing in the world he needs is to burn cycles worrying what some giant corporation is doing with his work (which, sure, does not include this Rust implementation, but very obviously does include all the hard protocol design and validation work he's been doing over the last several years, which, if it were easy and straightforward to do, several people would have done before him).
I've done about as much serious technical work on WireGuard as you have --- to wit: none, though I am a loyal, diligent distributor of WireGuard stickers. My partners all feel the same way, so we've just been sending the project cash.
If your employer has done the same, and dumped a giant bucket of cash on Jason in exchange for having gotten so much mileage out of his work, that would be an excellent rejoinder to this particular set of concerns.
Eagerly, therefore, awaiting my comeuppance on this thread! :)
> then rolled it out as a proprietary offering that WireGuard itself is not allowed to connect to.
So, I said this in the link, but the implementation of the protocol itself is, as Zack said, fully open source. To me, that's the high order bit here. And as I said on the reddit thread, it appears from the outside that this is more of a support issue than anything else. Maybe that's a lie, but I'm inclined to take jgc at his word.
On working with upstream, what they said publicly is this: https://blog.cloudflare.com/boringtun-userspace-wireguard-ru...
> We communicated with Jason throughout the process and have a ton of respect for him and the entire WireGuard community. In the short term, we need the flexibility to quickly update BoringTun's code base to support the project we built it for. That's harder when you need to coordinate with people outside Cloudflare and when we need to move as fast as we plan to. However, we really believe in Open Source and want the WireGuard community to thrive. We licensed the code very openly (3-paragraph BSD) and WireGuard may choose to fork it. If they do, we'll support it and plan to contribute any improvements in our own fork back. Over the long term, I think we're very open to merging this back into the upstream project.
This seems very reasonable to me. YMMV. I have no idea what requirements would cause this friction at the moment, but peeking at https://www.wireguard.com/#contributing it looks like they do the "non-GitHub server + mailing list" for development. I mean, I'm literally wearing a GitHub hoodie, but I know that I personally prefer the GitHub workflow to the point where if doing work via that system were an upstream requirement, I'd probably do my own thing on GitHub too.
Basically, it may be good, it may be bad. I don't have enough information to really pass judgement.
:gif_of_homer_simpson_backing_slowly_into_the_hedge: is a totally legit response to this whole situation, for what it's worth.
(I'll reiterate: it would be amusing if your employer just smote me where I stand by revealing the large donation they've made to Jason's project).
My job isn't to be a PR person for everything Cloudflare does. Cloudflare has and does things I disagree with. It's a company with a lot of people working there, after all :)
All of this stuff is completely outside of what is going to be my job. And a job I haven't even started yet! I mean, sure, it's legitimate to talk about like anything is, but if you want to know what's going on, I'm certainly not the person to talk to about it.
It was a pretty weird move on Cloud Flare's part. I'm not saying it was "bad", just, weird.