Rename methods on the curve25519 interface to be a bit more high level.
Cleanup emscripten wrapper class, wrap long lines and such. Also add a
grunt task alias for building the emscripten compiled curve
implementation.
Firstly, don't initialize textsecure.nativclient unless the browser
supports it. The mimetype-check trick is hewn from nacl-common.js.
Secondly, nativeclient crypto functions will all automatically wait for
the module to load before sending messages, so we needn't register any
onload callbacks outside nativeclient.js. (Previously, if you wanted to
do crypto with native client, you would have to register a call back and
wait for the module to load.) Now that the native client crypto is
encapsulated behind a nice interface, it can handle all that
onload-callback jazz internally: if the module isn't loaded when you
call a nativeclient function, return a promise that waits for the load
callback, and eventually resolves with the result of the requested
command. This removes the need for textsecure.registerOnLoadCallback.
Finally, although native client has its quirks, it's significantly
faster than the alternative (emscripten compiled js), so this commit
also lets the crypto backend use native client opportunistically, if
it's available, falling back to js if not, which should make us
compatible with older versions of chrome and chromium.
Man you shoulda been there. Code was compiling all over the damn place.
It was wild.
Seriously though. Ignore that intermediate compiled file. What happens
in build stays in build.
Build with `grunt compile && grunt concat:curve25519` after installing
emscripten.
Enable by either (a) not loading nativeclient.js or (b) setting
`textsecure.NATIVE_CLIENT = false` before loading nativeclient.js.
The nativeclient.js module overrides
window.textsecure.registerOnLoadFunction with its own version. Otherwise
helpers will define a trivial placeholder for same.
The flag textsecure.NATIVE_CLIENT can be set anywhere ahead of
nativeclient.js, but is only acted on in nativeclient.js,
and crypto.js.
NB: this diff is best viewed with --ignore-whitespace
Distills crypto.js down to the hard cryptoey bones. It pulls from
webcrypto for aes and hmac, and from native client for curve25519 stuff
or potentially another object implementing the handful of needed
curve25519 functions.
Everything else formerly known as crypto, including session storage and
management, axolotl, etc.. is now protocol.js. The separation is not
quite perfect, but it's a big step.
nativeclient.js now enables talking to the native client module through
a high level interface as well as registering callbacks that will be
executed once the module is loaded. And it has tests!
Finally, this commit removes all references to the "testing_only"
object, preferring to run tests on textsecure.crypto instead.
Since I decided to preen mocha and chai, we can no longer generate the
concat file list from the preen config. We must instead explicitly list
the modules we want to concatenate. I placed this config in bower.json
so that most of the time, we won't need to change the Gruntfile.
Also added a concatenation task for test page dependencies.
To components. Because tab-completion works better when there aren't two
things starting with bower, and shorter names are nicer to deal with in
general.
The jquery mainline is lagging on support for responseType:
'arraybuffer', an XHRHTTPRequest Level 2 feature (whatever that means).
We use this responseType to transfer attachments.
I rebased https://github.com/jquery/jquery/pull/1525 on the 2.1.1
release and cut 2.1.1-ajax-nativetransport in my own fork.
Latest protobuf.js requires that we pass in the sign value when making
longs from strings, ex: dcodeIO.Long.fromString(id, true);
However, it does the string->long conversion automatically if its given
a string for a fixed64 field, so we can pass our string ids right in!
ftw
Set up grunt with tasks for:
* preen - deletes unused files from bower_components, configured in
bower.json
* concat - concatenates preened bower components, configured
automagically from the preen config
It's worth noting that this setup assumes the order of files within a
package doesn't matter. This is usually true since we often include only
one file from the package.
