zx2c4

It's associated per-peer, so it assures a cryptographic mapping between src ip and public key.

It's like a routing table on the way out and an ACL on the way in. Maybe an easier way to think of it.

I likewise wonder from time to time whether I should replace WireGuard's allowedips.c trie with something better: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Thank you! I'm glad somebody appreciates it. A lot of thought has gone into the installer and upgrade aspect.

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.

This was just for WireGuardNT, the kernel driver for the NT kernel that Windows uses.

This project -- https://git.zx2c4.com/wireguard-nt/about/ -- is used by this app -- https://git.zx2c4.com/wireguard-windows/about/ . The former is what the signing situation was about. The latter is just signed using a normal boring (but very expensive!) EV code signing certificate from one of the CAs.

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.

Microsoft got in touch. All sorted out now.

Hopefully soon, Microsoft-willing.

No. The humans just said 60 days.

Encouraged by this thread, I tweeted about it: https://x.com/EdgeSecurity/status/2041872931576299888

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.

Voila:

https://github.com/WireGuard/wireguard-android/pull/82 https://github.com/WireGuard/wireguard-android/pull/80

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.

I was curious upon seeing this and found the thread where its inclusion was turned down: https://sourceforge.net/p/sevenzip/discussion/45797/thread/a...

> about 4x to 10x faster than channels.

I'd be interested to learn why/how and what the underlying structural differences are that make this possible.

Similar project of mine from a long while ago: https://git.zx2c4.com/cscript/about/

Linus merged it on July 24, 2024, so about a year I guess. Kernel is released ~8 weeks after the merge window, so I suppose September or so.

I think neither are unbelievably slow. I dunno, take some measurements and see, maybe it suits you.

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.)

Should be fixed now. App Store needed an EU declaration.

> By the end of the training, they learned to name an average of 7.08 pitches (ranging from 3 to 12) at an accuracy of 90% or above and within a response-time (RT) window of 1,305–2,028 ms.

That doesn't actually seem very promising, or at least useful at all. It still seems way less useful than my accurate and near instantaneous relative-pitch. What could I do as a musician with 2 seconds of latency to be wrong some amount of the time.

Saw that. Looks appealing, but I'm not particularly keen on, "We only require that you keep one sudo-enabled account on the system for us to use as needed for troubleshooting." [1] Do I want to give root access to the project's master git server to somebody I've never met, who is probably a good & nice person, but not really directly associated with the project? In general, I'm wary of places with relaxed enough informal policies that somebody could just walk over to a machine and fiddle with it. It's not that I actually intend to do some kind of top secret computing on Internet-facing machines like those, but I also don't want to have to be _as_ concerned about those edge cases when I'm deciding which things to run or host on it.

[1] https://osuosl.org/services/hosting/details/

No, it's considerably more involved than that. For example, there's extensive CI: https://www.wireguard.com/build-status/ This thing builds a fresh kernel and boots it for every commit for a bunch of systems. And there's also a lot of long running fuzzing and SAT solving and all sorts of other heavy computation happening during different aspects of development. Development is a bit more than just pushing some code up to Github and hoping for the best.

The WireGuard project is also in the same situation, due to Equinix Metal shutting down. If anybody would like to host us, please reach out to team at wireguard dot com. Thanks!

From the article: "It remains possible to put arbitrary bytes AFTER the parts of the shell script that get parsed & executed (like some Solaris patch files do). "

Why fork/copy&paste wireguard-go source code instead of using wireguard-go's existing netstack package? Couldn't you help improve instead?

I would be interested to learn from somebody with experience using both Bun and Deno: which one is actually the more compelling Node successor? Bun's website makes some impressive performance claims over Deno. Are these true in practice? And if so, why? Seems like Deno also has similar goals. Also, are there large philosophical differences between the two projects? Like Bun tries to reimplement the kitchen sink but Deno wants a new post-Node way of doing things? (Just guessing, no idea if that's true.)

Any seasoned users with time spent on both?

Maybe OP is thinking of https://paste.sh/Uwyu3Clb#MSWkjF81G0RvLYtrU6wic6LZ ?

Sounds like you have a handy script to paste here... :)