[ANNOUNCE] WireGuard Snapshot `0.0.20171211` Available

[ANNOUNCE] WireGuard Snapshot `0.0.20171211` Available

[Jason A. Donenfeld]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello,

A new snapshot, `0.0.20171211`, 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 ==

  * curve25519: explictly depend on AS_AVX
  * curve25519: modularize dispatch
  
  It's now much cleaner to see which implementation we're calling, and it will
  be simpler to add more implementations in the future.
  
  * compat: support RAP in assembly
  
  This should fix PaX/Grsecurity support.
  
  * device: do not clear keys during sleep on Android
  
  While we want to clear keys when going to sleep on ordinary Linux, this
  doesn't make sense in the Android world, where phones often sleep but are
  woken up every few milliseconds by the radios to process packets.
  
  * compat: fix 3.10 backport
  
  Important compat fixes for non-x86.
  
  * device: clear last handshake timer on ifdown
  
  When bringing up an interface, we don't want the rate limiting to handshakes
  to apply.
  
  * netlink: rename symbol to avoid clashes
  
  Allows coexistance with horrible Android drivers.
  
  * kernel-tree: jury rig is the more common spelling
  * tools: no need to put this on the stack
  * blake2s-x86_64: fix spacing
  
  Small fixes.
  
  * contrib: keygen-html for generating keys in the browser
  
  This was covered here:
  https://lists.zx2c4.com/pipermail/wireguard/2017-December/002127.html
  
  * tools: remove undocumented unused syntax
  
  Not only did nobody know about this or use it, but the implementation actually
  exposed compiler bugs in Qualcomm's "Snapdragon Clang".
  
  * poly1305: update x86-64 kernel to AVX512F only
  
  From Samuel Neves, this pulls in Andy Polyakov's changes to only require F and
  not VL for the Poly implementation.
  
  * chacha20-arm: fix with clang -fno-integrated-as.
  
  This pulls in David Benjamin's clang fix.
  
  * global: add SPDX tags to all files
  
  From Greg KH, we now have SPDX annotations on all files, matching upstream
  kernel's new approach to file licenses.
  
  * chacha20poly1305: cleaner generic code
  
  This entirely removes the last remains of Martin Willi's ChaCha
  implementation, and now the generic C implementation is extremely small and
  clearly written, while delivering a small performance boost too.
  
  * poly1305: fix avx512f alignment bug
  
  Unlucky people may have had their linkers misalign a constant. This fixes that
  potential.
  
  * chacha20: avx512vl implementation
  
  From Samuel Neves, this imports Andy Polyakov's AVX512VL implementation of
  ChaCha which should have a ~50% performance improvement over AVX2, though it
  is still much slower than our AVX512F implementation.
  
  * chacha20poly1305: wire up avx512vl for skylake-x
  
  Some Skylake machines do not have two FMA units (though others do), so we
  prefer the AVX512VL implementation over the should-be-faster AVX512F
  implementation on those machines. What's needed now is to read the PIROM in
  order to determine at runtime whether the particular Skylake-X machine
  actually has the second FMA unit or not, but until that happens, we just fall
  back to the VL implementation for all Skylake-X.

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:
  https://git.zx2c4.com/WireGuard/snapshot/WireGuard-0.0.20171211.tar.xz
  SHA2-256: 57d799d35e92c905e548d00adeb7ed1ead4d6560f084c99e5aae0a87b4eb09e4
  BLAKE2b-256: 7cdaae2f6a6886b8cb86d0cdb2170c22447dda8fa247f10924f920e14d8f51e9

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

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

iQJEBAEBCAAuFiEEq5lC5tSkz8NBJiCnSfxwEqXeA64FAlot0g8QHGphc29uQHp4
MmM0LmNvbQAKCRBJ/HASpd4Drln9D/4nO1CBPdaM9VajE8w/sczfKtYlHh0tF++X
zr3QKCNmH7zqK0C2B5pdLr8ZF7fIwnT7R4DfR9KDiCCt963AmGueJGs3OYgB6QvP
JdCYpnhExJOK6PtDpZ04GrXnCioXMLZn23nY6o4rp52p3CND4nNYPLGyU67wYS1R
ZuJom5bvianleu+rPOEQKdYIy2Ey3UYOgrkR0D1e6htM7EfQcqUIVP3JhjOorVtD
nRBWJrdE74ffEvCfivzvroqZKfXmJI7WvRGbGwgVyHJj8a9c8Y7y8n1U//PiYran
jd9IOFaAtc9KF44lKa6jjz9Jai6RB/J/imU06cInCgKoIYMA1HyxmYUPzcBHwPPx
6Ac4jOpFTcLUUs3CfAdTFpp8T5CrrP2uCbUDtjxYNiqhMYECLv2ZBSrr81JLczzc
iL3pGWtc6zQH1fsAT4zSarui6SbRsJS+i7I3AsDjX0jO4FCdqCWTvvsKJmRdTMlX
ZPWxb9YILxJZpMhy4RmaNWjyTzRXYhA4vSF6RVPMlc6IU+2Cv9RtJm5H3T/pMX+C
K4kWj4O6dCHZajRoVB0rJYYxkXKN/5UPTqgghtyGAoD1hwWPCncq8Y7KrqYUgjV+
AUvs8V0jJrgy1zzqb1u9WmzvqT9RgZB8QWOwqvSstxFcvOTI2DGz4sT4Pr1bqpSZ
SxzBLStgcA==
=N5k8
-----END PGP SIGNATURE-----

curve25519_generate.js [was: Re: [ANNOUNCE] WireGuard Snapshot `0.0.20171211` Available]

[Daniel Kahn Gillmor]

[-- Attachment #1: Type: text/plain, Size: 2158 bytes --]

Hi Jason, all--

On Mon 2017-12-11 01:32:53 +0100, Jason A. Donenfeld wrote:
> A new snapshot, `0.0.20171211`, has been tagged in the git repository.

thanks for this!

>   * contrib: keygen-html for generating keys in the browser

This includes:

  contrib/examples/keygen-html/curve25519_generate.js

which appears to be a generated file -- looks like it would normally be
built from:

  contrib/examples/keygen-html/src/curve25519_generate.c

based on this comment in the headers of the .c file:

     Build with emcc -O3 --memory-init-file 0 -o curve25519_generate.js curve25519_generate.c

A few questions about this situation, as it doesn't align with the rest
of the source:

 * is there a reason to include a generated file in the revision
   control?  This seems similar to introducing a compiled copy of
   /usr/bin/wg to the source code, which doesn't seem like a great plan.

 * Is there a reason not to use a Makefile in this example directory, as
   a standard way of indicating how to do the build?

 * The conversion to the SPDX header of the .js file seems to be done
   manually.  if the generated .js file will stay in this example, will
   the SPDX header be re-created after any change to the .c source?

 * Do you expect packagers do rebuild this with whatever version of
   emscripten available to them?  Or should that be left up to the party
   who makes use of the key-generator?

   In debian, i can't reasonably ship a binary artifact that i can't
   build from source (this is sensible debian policy, and one of the
   things that keeps debian a free software operating system).  Alas, in
   debian emscripten seems to be having maintenance difficulties:

      https://tracker.debian.org/pkg/emscripten

   so it'll take me longer to package and release this snapshot if want
   to include the keygen-html example with the compiled binary.


I think the simplest thing for now is to drop the .js from the example
source, add a Makefile, and shift the burden of compilation/emscripten
onto the administrator who decides to deploy keygen.html.

I welcome any other suggestions or different perspectiveson the
situation.

  --dkg


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: curve25519_generate.js [was: Re: [ANNOUNCE] WireGuard Snapshot `0.0.20171211` Available]

[Jason A. Donenfeld]

Hi Daniel,

Thanks for bringing this up. All excellent points. I wasn't totally
confident about doing that, but what went into the decision was the
following:

- emscripten is laborious to build and recent versions are not readily
accessible on many distros.
- I figure web developers generally lack build system competence and
would be more inclined to use this if it was as easy as copy and
paste.
- Signal includes the generated .js file in their repos.

It would indeed be much cleaner to include a Makefile, like you
suggest, which would take care of all the appropriate magic, but I
worry about that being overwhelmingly inconvenient for some. Is that
actually a good reason? I don't know...

 > * Do you expect packagers do rebuild this with whatever version of
 >  emscripten available to them?  Or should that be left up to the party
 >  who makes use of the key-generator?

Certainly don't bother rebuilding it. contrib/examples has tons of
source code (most of which has proper makefiles!), which similarly
shouldn't be built, since it's example code meant to be tweaked.

>   In debian, i can't reasonably ship a binary artifact that i can't
>   build from source (this is sensible debian policy

This is sensible policy. There is a question that people could
bikeshed about all day: "Is emscripten output a binary artifact?"
Probably the existing Debian policy answer to that is a sufficient
one, if that kind of thing has already been decided.

So anyway, I'm not really sure what to do here. Happy to take
suggestions from all sides. Just keep in mind that emcc is a massive
pain to get installed.

Jason

Re: curve25519_generate.js [was: Re: [ANNOUNCE] WireGuard Snapshot `0.0.20171211` Available]

[Daniel Kahn Gillmor]

Hi Jason--

On Mon 2017-12-11 21:15:16 +0100, Jason A. Donenfeld wrote:
> - emscripten is laborious to build and recent versions are not readily
> accessible on many distros.
> - I figure web developers generally lack build system competence and
> would be more inclined to use this if it was as easy as copy and
> paste.
> - Signal includes the generated .js file in their repos.

these are all true statements, i'm just not sure that they argue in the
direction of the current state of the repository :)

> It would indeed be much cleaner to include a Makefile, like you
> suggest, which would take care of all the appropriate magic, but I
> worry about that being overwhelmingly inconvenient for some. Is that
> actually a good reason? I don't know...
>
>  > * Do you expect packagers do rebuild this with whatever version of
>  >  emscripten available to them?  Or should that be left up to the party
>  >  who makes use of the key-generator?
>
> Certainly don't bother rebuilding it. contrib/examples has tons of
> source code (most of which has proper makefiles!), which similarly
> shouldn't be built, since it's example code meant to be tweaked.

If we can't build it from the preferred form of modification in debian,
then we shouldn't be shipping it.  People *definitely* aren't going to
be tweaking the .js (other than the SPDX changes, which did appear to
happen by hand).

>>   In debian, i can't reasonably ship a binary artifact that i can't
>>   build from source (this is sensible debian policy
>
> This is sensible policy. There is a question that people could
> bikeshed about all day: "Is emscripten output a binary artifact?"
> Probably the existing Debian policy answer to that is a sufficient
> one, if that kind of thing has already been decided.

i think debian as a whole has answered that one pretty clearly (despite
some intermittent bickering).  Minimized or generated javascript is a
binary artifact, and is clearly not the "preferred form of
modification".  It's much more similar to java bytecode than it is to
source code, when it comes to manipulability and comprehension.

> So anyway, I'm not really sure what to do here. Happy to take
> suggestions from all sides. Just keep in mind that emcc is a massive
> pain to get installed.

agreed, but given that the introduction to this project is "don't use
this if you don't know what you're doing, and you've thought about all
the tradeoffs", i'm inclined to say having a "massive pain" hurdle that
keeps people from using it without really meaning to.  This patch will
also (as a happy byproduct) help me keep the debian packaging free from
un-buildable binary artifacts :)

I'll send a patch to the list shortly with a simple proposal.

all the best,

     --dkg

Re: curve25519_generate.js [was: Re: [ANNOUNCE] WireGuard Snapshot `0.0.20171211` Available]

[Jason A. Donenfeld]

Alright, here's a stab at it:


+<script src="curve25519_generate.js" onError='document.write("<h3>Did
you forget to run \"make\" to compile
curve25519_generate.js?</h3><!--");'></script>

Re: curve25519_generate.js [was: Re: [ANNOUNCE] WireGuard Snapshot `0.0.20171211` Available]

[Jason A. Donenfeld]

Yikes, tapped send by accident. Here's a stab at it:

https://git.zx2c4.com/WireGuard/commit/?id=037c389f2f09f721ecc84105b0d5d0ca8824c070

I changed this to make it more "okay" for the unwitting web developer:

<script src="curve25519_generate.js" onError='document.write("<h3>Did
you forget to run \"make\" to compile
curve25519_generate.js?</h3><!--");'></script>

We can all groan at the <!-- trick, and then get back to work writing C. :)

Jason

Re: curve25519_generate.js [was: Re: [ANNOUNCE] WireGuard Snapshot `0.0.20171211` Available]

[Daniel Kahn Gillmor]

On Tue 2017-12-12 01:18:49 +0100, Jason A. Donenfeld wrote:
> Alright, here's a stab at it:
>
> +<script src="curve25519_generate.js" onError='document.write("<h3>Did you forget to run \"make\" to compile curve25519_generate.js?</h3><!--");'></script>

That looks fine to me.

     --dkg