<wlhlm>
MoreTea, zx2c4: I'm mostly just compiling the commands listed on the wireguard website. I'm using Mullvad for this - they offer a couple of experimental wireguard endpoints (https://www.mullvad.net/guides/wireguard-and-mullvad-vpn/).
<MoreTea>
Could you not create wireguard interfaces, and bridge them to your private network devices? Not sure if that would be possible
<wlhlm>
zx2c4: There is no package for the wireguard module specifically (only for the cli tools). I think the module is only installed if I add a wireguard interface in the nixos configuration, which I'm trying to avoid since I can't use it with netns that way.
<zx2c4>
wlhlm: `modprobe wireguard` will insert the kernel module if its been installed
<wlhlm>
Mic92, ericsagnes: Hi, I'm trying to use wireguard with network namespaces, which is currently not possible with the wireguard module in nixpkgs. The problem is that there seems to be no way to just install the kernel modules without having to configure network.wireguard.interfaces.*. Do you know how I could work around that?
<NixOS_GitHub>
nixpkgs/master 6e50243 Jason A. Donenfeld: wireguard: preshared-key is now an attribute of the peer...
<NixOS_GitHub>
nixpkgs/master ef018d8 Jason A. Donenfeld: wireguard: 0.0.20170421 - 0.0.20170517...
2017-05-09
<zx2c4>
in wireguard, the PQ resistance is just "hash in a 256-bit symmetric key". grover's theorem says that a quantum computer can _at best_ get a square root speed up, so that still leaves 128-bits, which means it's secure. this is the so called "poor man's PQ resistance", which always works. it is _not_, however, a key exchange (by virtue of being "preshared").
<NixOS_GitHub>
nixpkgs/release-16.09 efdcb44 Franz Pletz: wireguard: 2016-10-01 -> 2016-10-25...
<NixOS_GitHub>
nixpkgs/master 36d5097 Jason A. Donenfeld: wireguard: 0.0.20170213 -> 0.0.20170214...
<NixOS_GitHub>
nixpkgs/master 1a9707d Graham Christensen: wireguard: update description to describe its current state
<gchristensen>
zx2c4: what I'm thinking is updating the description of wireguard to indicate that it is a pre-prelease, is experimental and not to be depended upon for security, and then moving forward with regular backports to stable
<gchristensen>
or rename it to wireguard-experimental (to reflect its upstream lack of historical support, it is a _stable_ release, and mandatory upgrades is a bit antithetical to that) or issue a warning
<zx2c4>
wireguard simply isnt at the point where it makes sense to branch a certain snapshot and then "backport" particular fixes. it's very much a work in progress, albeit a fairly stable work in progress. it's pretty safe to just bump snapshots for all nix versions
<gchristensen>
zx2c4: so we're just discussing how to handle wireguard for stable releases
<gchristensen>
before we discuss that too far -- what should we do about the ancient wireguard package we have in 16.09?
<gchristensen>
we could rename it wireguard-experimental
<fpletz>
the thing is that wireguard is not finished yet - we should ask ourselves if we should even support it in a stable distribution (like those rc kernels that are available in stable but never updated \o/)
<gchristensen>
hmm should we be more clearly denoting wireguard as experimental?
<gchristensen>
ikwildrpepper: the author of wireguard is incredibly high-and-mighty
<gchristensen>
Mic92: should these wireguard PRs be backported?
<Mic92>
gchristensen: we most likely do not have to deal with him in future, when this module gets merged into linux and wireguard-tools gets merged into iproute2.
<NixOS_GitHub>
nixpkgs/master 77588ca Jason A. Donenfeld: wireguard: 20161209 -> 20161218 (#21288)
<gchristensen>
Mic92: that wireguard fellow is very difficult.
2016-12-19
<Mic92>
gchristensen: the guy behind wireguard
<Mic92>
gchristensen: I decided not do any wireguard maintance as long as this guy is lurking in the issue tracker.