Good question! I've never tried. The NT driver makes use of some of the more advanced features of the networking stack, so possibly not. But you never know. I'd love a Wg4React.
As I mentioned in the mailing list post, the Microsoft paperwork shuffling matter got dealt with rather quickly, following all the attention the HN thread from the other day got. And now we're finally out with an update!
NT programming is a lot of fun, though this release was quite challenging, because of all of the toolchain updates. On the plus side, we got to remove pre-Win10 support -- https://lists.zx2c4.com/pipermail/wireguard/2026-March/00954... . But did you know that Microsoft removed support for compiling x86 drivers in their latest driver SDK? So that was interesting to work around. There was also a fun change to the Go runtime included in this release: https://github.com/golang/go/commit/341b5e2c0261cc059b157f1c...
All and all, a fun release, and I'm happy to have the Windows release train cooking again.
This is the same problem I'm currently facing with WireGuard. No warning at all, no notification. One day I sign in to publish an update, and yikes, account suspended. Currently undergoing some sort of 60 days appeals process, but who knows. That's kind of crazy: what if there were some critical RCE in WireGuard, being exploited in the wild, and I needed to update users immediately? (That's just hypothetical; don't freak out!) In that case, Microsoft would have my hands entirely tied.
If anybody within Microsoft is able to do something, please contact me -- jason at zx2c4 dot com.
In that first one, the double pasted AI retort in the last comment is pretty wild. In both of these, look at the actual "files changed" tab for the wtf.
On Linux, there's no need to use this. Modern Linux kernels implement getrandom() in the vDSO, which does similar buffering, and keeps those buffers safe in the event of forks or VM forks and kernel reseed events.
The readme says:
> Maintains all cryptographic security guarantees of crypto/rand
I'm not sure that's correct. If you're running this in a VM that forks, this new package will give out the same random bytes to both VMs, which could be catastrophic. If you're using normal crypto/rand, Linux has got you covered, and the VM forks get reseeded.
If you don't need "predictable randomness", like for repeatable statistical simulations, then absolutely, you should only use getrandom(). On recent Linux, this is implemented in the vDSO and is super fast. Few excuses now to use anything different.
Careful with the "chacha csprng" when the seed from the seed() function appears to be 32 or 64 bits. That's not enough for the cs part. (Also the output stream appears to wrap after 2**32 blocks. Could make this larger.)