compatibility with emscripten (LLVM compiled to webassembly)

[jaromil]

Is this desired as a new build target? If yes, I'll pack a PR which adds compatibility with emscripten's api when detected.

[dsprenkels]

Hey @jaromil. I would be happy to merge support for emscripten. Do you know if it is possible to also add a test for this platform?

[dsprenkels]

If you need some example, this may help: https://github.com/jedisct1/libsodium/blob/master/src/libsodium/randombytes/randombytes.c#L95-L119

Important is that we must never allow Math.random to be used. In this case we should panic instead.

[jaromil]

Yes, I know it is not good random, but then I'm studying how to apply this See ftp://ftp.rsasecurity.com/pub/pdfs/bull-1.pdf meanwhile, since I plan to use randombytes, its useful for me to know if I shall add this support inside your library or inside my own software (zenroom). And yes, using zenroom will be possible to add tests.

[dsprenkels]

randombytes is actually intended for usage by libraries such as yours, so in this manner I would be happy to get emscripten support in here.

But this library always assumes to that the only thing that we can trust is the platform itself. Its goal is not to implement a random generator in itself, only to interface with the platform. (The reason is that we cannot reasonably implement entropy collection on every platform.)

[jaromil]

Understood and sure, I did not plan to implement the software RNG but only the emscripten support, sorry for confusion and thanks for the pointer to the libsodium implementation, indeed useful. Did not know it was possible to inline js inside C like that. Comfortable and horrifying at the same time.

[jaromil]

I've made it! its different from libsodium (which I'm not even sure it works)... will test further, meanwhile let me know how do you feel about adding

#include <stdlib.h>

to the headers? its fully portable AFAIK and its needed because I need to free() a buffer that emscripten allocates.

[dsprenkels]

Thanks for your efforts!

I am totally okay with adding stdlib.h, but do we need to? Can we surround it with #ifdefs, to only include stdlib.h only when targeting emscripten (as it is not needed for other targets anyway)?

[jaromil]

Good idea. need to jump out now but will be back with a PR really soon, after some more testing. We need stdlib for C99 compatibility, then free() declaration cannot be implicit. If you are curious, it is currently working in zenroom's develop branch which helps also making tests.

[jleni]

Sorry to jump in.. but emscripten compatibility would be great!

[jaromil]

PR is ready here #8 this is tested on nodejs. I'll follow up with more fixes after testing on different setups: browser only, asm.js and WASM. I have also a couple other changes to support old linux kernels (pre SYS_getrandom as for instance the one in stock ubuntu 14.04) all already visible here https://github.com/DECODEproject/zenroom/blob/develop/src/randombytes.c wondering if Daan will like me to push so much in or tell me to fork :call_me_hand:

[dsprenkels]

I will accept any pull requests for support for new platforms. And I will try to help out if I have the time. :D

Btw. Old Linux kernels should work, although they ware a pain to implement.

[jaromil]

I saw your attempts but apparently they fail (testing on ubuntu 14.04 on travis CI) right now I've fixed with a solution that I may pack into a pull request, however first I want to try your _GNU_SOURCE fix: is that related?

[dsprenkels]

The _GNU_SOURCE fix is unrelated (and only relevant on linux>=3.17).

What is the error in your case (maybe open a separate issue)? The /dev/urandom back-end is in Travis and it seems to work fine.

[jaromil]

Strange! here is what I got https://travis-ci.org/DECODEproject/zenroom/jobs/358002125#L2621

[dsprenkels]

I looks like there is a problem when using musl. I opened an issue in #11.