WireGuard Digest, Vol 24, Issue 4
symgryph at gmail.com
Mon Mar 5 23:40:19 CET 2018
what is the go and rust git uri?
Thomas J Munn
> On Mar 5, 2018, at 06:00, wireguard-request at lists.zx2c4.com wrote:
> Send WireGuard mailing list submissions to
> wireguard at lists.zx2c4.com
> To subscribe or unsubscribe via the World Wide Web, visit
> or, via email, send a message with subject or body 'help' to
> wireguard-request at lists.zx2c4.com
> You can reach the person managing the list at
> wireguard-owner at lists.zx2c4.com
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of WireGuard digest..."
> Today's Topics:
> 1. [ANNOUNCE] WireGuard Snapshot `0.0.20180304` Available
> (Jason A. Donenfeld)
> 2. Tunsafe Windows client for wireguard (not opensource yet they
> say (Henrique Carrega)
> 3. Re: Tunsafe Windows client for wireguard (not opensource yet
> they say (Jason A. Donenfeld)
> Message: 1
> Date: Sun, 04 Mar 2018 18:54:23 +0100
> From: "Jason A. Donenfeld" <Jason at zx2c4.com>
> To: "WireGuard mailing list" <wireguard at lists.zx2c4.com>
> Subject: [ANNOUNCE] WireGuard Snapshot `0.0.20180304` Available
> Message-ID: <b97b4ced2749b831 at frisell.zx2c4.com>
> Content-Type: text/plain; charset=UTF-8
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> A new snapshot, `0.0.20180304`, has been tagged in the git repository.
> Please note that this snapshot is, like the rest of the project at this point
> in time, experimental, and does not consitute a real release that would be
> considered secure and bug-free. WireGuard is generally thought to be fairly
> stable, and most likely will not crash your computer (though it may).
> However, as this is a pre-release snapshot, it comes with no guarantees, and
> its security is not yet to be depended on; it is not applicable for CVEs.
> With all that said, if you'd like to test this snapshot out, there are a
> few relevent changes.
> == Changes ==
> * NOTICE: off the grid
> Do note that I'll be going off the grid from the end of this coming week until
> April 1. This snapshot is expected to be fairly stable in the interim.
> * queueing: skb_reset: mark as xnet
> This allows cgroups to classify packets.
> * contrib: embedded-wg-library: add ability to add and del interfaces
> * contrib: embedded-wg-library: add key generation functions
> The embeddable library gains a few extra tricks, for people implementing
> plugins for various network managers.
> * crypto: read only after init
> * allowedips: fix comment style
> * messages: MESSAGE_TOTAL is unused
> * global: in gnu code, use un-underscored asm
> * noise: fix function prototype
> Small cleanups.
> * compat: workaround netlink refcount bug
> An upstream refcounting bug meant that in certain situations it became
> impossible to unload the module. So, we work around it in the compat code. The
> problem has been fixed in 4.16.
> We nearly moved away from emscripten'ing the fiat32 code, but the resultant
> * Kconfig: require DST_CACHE explicitly
> Required for certain frankenkernels.
> * compat: use correct -include path
> Fixes certain out-of-tree build systems.
> * noise: align static_identity keys
> Gives us better alignment of private keys.
> * wg-quick: if resolvconf/interface-order exists, use it
> * wg-quick: if resolvconf/run/iface exists, use it
> Better compatibility with Debian's resolvconf.
> * contrib: add extract-handshakes kprobe example
> Small utility for extracting ephemeral key data from the kernel's memory. More
> information can be found here:
> As always, the source is available at https://git.zx2c4.com/WireGuard/ and
> information about the project is available at https://www.wireguard.com/ .
> This snapshot is available in tarball form here:
> SHA2-256: efb1652f0da67fb2731040439b6abb820a5e2f1bc177aa15c5dce68ea3327787
> BLAKE2b-256: 9b49122b546d334a431b12e5b62582a094db737f2497652e55b4155709107c40
> If you're a snapshot package maintainer, please bump your package version. If
> you're a user, the WireGuard team welcomes any and all feedback on this latest
> Finally, WireGuard development thrives on donations. By popular demand, we
> have a webpage for this: https://www.wireguard.com/donations/
> Thank you,
> Jason Donenfeld
> -----BEGIN PGP SIGNATURE-----
> -----END PGP SIGNATURE-----
> Message: 2
> Date: Mon, 5 Mar 2018 08:26:23 +0000
> From: Henrique Carrega <hcarrega at gmail.com>
> To: wireguard at lists.zx2c4.com
> Subject: Tunsafe Windows client for wireguard (not opensource yet they
> Message-ID: <41222FCF-F9F5-4FEC-AA71-73C48F4DA4BA at gmail.com>
> Content-Type: text/plain; charset="us-ascii"
> Sent from my iPhone
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20180305/e7c2813d/attachment-0001.html>
> Message: 3
> Date: Mon, 5 Mar 2018 10:19:35 +0100
> From: "Jason A. Donenfeld" <Jason at zx2c4.com>
> To: Henrique Carrega <hcarrega at gmail.com>
> Cc: WireGuard mailing list <wireguard at lists.zx2c4.com>
> Subject: Re: Tunsafe Windows client for wireguard (not opensource yet
> they say
> <CAHmME9r95cjSXK8YitGuHxFp0EfrMKhQEGXL5Ux=rMXLt=U5FA at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
> Hi Henrique,
> Thanks for posting this.
> Please stay away from this software, and generally be wary of
> closed-source WireGuard implementations trying to fill the void. This
> one was written by a community-unfriendly proprietary author, and
> we've got little way of ensuring protocol compliance or basic
> security. Especially from my discussions from him, it's clear what
> he's up to, and this seems like some nastiness. Should I spend my time
> reverse engineering this software and discovering zero-days? Probably
> not a good use of my time, despite my usual love of this sort of
> One aspect of the WireGuard project is that we're taking development
> very carefully and slowly, not jumping to premature releases, and
> really studying every bit of what we produce in order to ship the
> least-vulnerable and most-correct code we possibly can. We're still
> shipping code -- it's not an approach that results in a complete
> standstill -- but it does mean that in these intervening periods,
> there will be propheteers and cowboys coming out of the woodwork to
> fill the void.
> It's quite easy to make a tiny tunneling protocol that's reasonably
> fast and does a few things; if you look on Github there are hundreds.
> It's quite another thing to write robust and secure software intend to
> last for a long time. That's what we're working on here.
> Fortunately we have two very nice projects that are rapidly
> approaching maturity: one in Go and one in Rust. I fully welcome
> future OSS authors into the project. When I'm back from visiting
> family at the beginning of April, I think we'll be in a good place to
> have a few first releases.
> I'll also do what I can to see that people aren't peddling junk and
> calling it wireguard, so as to reduce user confusion, but this of
> course isn't a very easy endeavor. I'm open to suggestions on how to
> approach this.
> Subject: Digest Footer
> WireGuard mailing list
> WireGuard at lists.zx2c4.com
> End of WireGuard Digest, Vol 24, Issue 4
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the WireGuard