5 ms·

Are you concerned at all how the Wireguard thing is playing out vs your desire to see this stuff open sourced?

zackbloom 8y ago
The Cloudflare Wireguard implementation is open-sourced and BSD licensed, what would be the concern? https://github.com/cloudflare/boringtun https://github.com/cloudflare/boringtun
- tptacek 8y ago
  That Jason asked Cloud Flare to contribute to an actual sanctioned Rust port of WireGuard --- important to Jason because the current userland implementation is Go, and thus not as fast as it could possibly be, which is a priority for Jason --- and they refused and built their own instead. Also, WireGuard-the-protocol is not a collaborative effort, and so Jason's presumably a bit concerned about a divergent fork this early in the process of getting WireGuard fielded. Particularly because Jason is just one dude working on this with a couple volunteers, and Cloud Flare is, well, yeah. It was a pretty weird move on Cloud Flare's part. I'm not saying it was "bad", just, weird.
steveklabnik 8y ago
I think it depends on which "Wireguard thing" you're talking about, there were several semi-controversies. 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_joining_cloudflare/ek6tp9w/?st=ju4db19o&sh=0bcb793e&context=4 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
- tptacek 8y ago
  Well, they took WireGuard, wrote a Rust implementation of it, refused to collaborate with Jason, who's been trying to get a Rust implementation of his protocol off the ground, then rolled it out as a proprietary offering that WireGuard itself is not allowed to connect to. This seems like the sort of analysis that would be pretty cut-and-dried among open source advocates (I'm not one of those, so I'm not saying it's cut-and-dried for me). 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! :)
  - steveklabnik 8y ago
    So, I'm hedging because I frankly know next to nothing about WireGuard. It's clear you know a lot more. But, without knowing more details, I can't really say if it's good or bad. > 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-rust/#comment-4401651800 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 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.

The Cloudflare Wireguard implementation is open-sourced and BSD licensed, what would be the concern? https://github.com/cloudflare/boringtun https://github.com/cloudflare/boringtun

tptacek 8y ago
That Jason asked Cloud Flare to contribute to an actual sanctioned Rust port of WireGuard --- important to Jason because the current userland implementation is Go, and thus not as fast as it could possibly be, which is a priority for Jason --- and they refused and built their own instead. Also, WireGuard-the-protocol is not a collaborative effort, and so Jason's presumably a bit concerned about a divergent fork this early in the process of getting WireGuard fielded. Particularly because Jason is just one dude working on this with a couple volunteers, and Cloud Flare is, well, yeah. It was a pretty weird move on Cloud Flare's part. I'm not saying it was "bad", just, weird.

steveklabnik 8y ago

I think it depends on which "Wireguard thing" you're talking about, there were several semi-controversies. 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_joining_cloudflare/ek6tp9w/?st=ju4db19o&sh=0bcb793e&context=4 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

tptacek 8y ago
Well, they took WireGuard, wrote a Rust implementation of it, refused to collaborate with Jason, who's been trying to get a Rust implementation of his protocol off the ground, then rolled it out as a proprietary offering that WireGuard itself is not allowed to connect to. This seems like the sort of analysis that would be pretty cut-and-dried among open source advocates (I'm not one of those, so I'm not saying it's cut-and-dried for me). 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! :)
- steveklabnik 8y ago
  So, I'm hedging because I frankly know next to nothing about WireGuard. It's clear you know a lot more. But, without knowing more details, I can't really say if it's good or bad. > 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-rust/#comment-4401651800 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 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.