curve25519_generate.js [was: Re: [ANNOUNCE] WireGuard Snapshot `0.0.20171211` Available]
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Mon Dec 11 20:26:21 CET 2017
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
which appears to be a generated file -- looks like it would normally be
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:
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 832 bytes
Desc: not available
More information about the WireGuard