There are other possibilities for individuals:
"Monthly: GitHub Sponsors, Paypal, Patreon, Liberapay"
"Once: Stripe, Bitcoin, Paypal"
And also "for non-profit foundations and companies."
Thanks!
We're not a very big company, could easily afford 1k a month though, but then it becomes an actual sum that's harder to motivate as we're mainly working with MS products.
Unfortunately it is up to open source developers themselves to set their business model, and many don't seem to like (or want to do the work of) setting up overtly commercial relationships like support contracts.
I don't know if it's fair to say he's not making what he asks for.. or basing a 1/10th claim without knowing how much he gets from other sources. (Bronze/gold partnerships GitHub donations, stripe, crypto donations, and some others).
As someone who does not do heavy NetOps, can you speak more about what's wrong with IPsec?
While using IPSec between supported devices, in an ideally configured setup, yield slight but real benefits with respect to attack resistance, a practical comparison of the difficulty involved and possible configuration mistakes makes other solutions more robust and less likely to be used incorrectly.
This discussion covers most of the high level points, however it doesn't consider that Wireguard being adopted in 2020 and not 1995 means we've got 25 more years of public cryptography research and far more relevant defaults to include as the base of the standard.
https://crypto.stackexchange.com/questions/202/should-we-mac...
The answer here also provides some of the pitfalls of IPSec being more of a 'build your own crypto setup' than an off the shelf drop in solution.
https://crypto.stackexchange.com/questions/56354/ipsec-vs-ss...
I think the main reason of the less than polished IPsec experience is that operating systems didn't really promote it as a out of the box working feature, but instead just offered APIs that were mainly used by corporate VPN product vendors who didn't really want interoperation except as a checkbox feature. The early interop hassles are just a symptom of lack of testing and effort - when vendors are motivated and actually everyone's implementation of a standardised protocol to interoperate they organise interoperation testing events etc and make sure their products ship with configurations that actually do interoperate in the real world.
Your linked StackOverflow answer muddies the water too much - IKE was always the official keying protocol[1]. Yes you can use lower level IPsec parts without it with manual keying if you are a masochist or have a very simple topology (like a 2-host tunnel with static IPs), but the other keying methods are fringe or academic.
[1] IKE was finished later than the lower level parts of IPsec, technically there was a period in the beginning when it didn't exist and you had only manual key setup
IPsec can be/is complicated because we learnt as we went with it, but given the correct settings, it can be/is secure.
So just like with SSL/TLS, it may be necessary to 'simply' introduce new RFCs to deprecate the Bad Way(s) of configuring it. Doing a quick search, there's a BCP RFC:
* https://tools.ietf.org/html/rfc5406
(I haven't really used either, so am just spit-balling here.)
I can't deploy WG before that haven't happened... thus time to get WG into RFCs!!!
Now that it’s merged into Linus’s tree, any word on it getting an official release and the “this isn’t production ready, so no CVEs” disclaimer going away?
EDIT:
Further back in the thread, Donenfeld says “Please note that until Linux 5.6 is released, this snapshot is a snapshot rather than a secure final release.”, so perhaps real soon now?
https://lists.zx2c4.com/pipermail/wireguard/2020-January/004...
This is definitely big news!