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

[Daniel Kahn Gillmor <dkg@fifthhorseman.net>]

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