encryptMessageFor now requires an array buffer instead of a protobuf.
By converting the message to an array buffer outside the Promise.all, we
avoid allocating a new copy for each device.
// FREEBIE
Follow up to b0da4910. When inferring membership of the sender in an
unknown group, remember to save and return the group members.
Generally, this should only effect standalone clients unless someone
managed to clear their groups db table, since linked clients get group
info synced at registration.
// FREEBIE
If you're the last member of the group, it doesn't make sense to send
messages to it. Previously, we would wait forever for a callback,
causing a stuck pending state indicator.
// FREEBIE
When we re-register, our deviceId might change, which makes our sessions
are no longer valid since the recipient will see us as a new device.
Fixes#388
Fix a bad loop scope bug in getKeysForNumber by using forEach.
Refactor the initial process of establishing key material for devices
that do not have open sessions.
// FREEBIE
These functions accept an array buffer and extract an AES and MAC key
from it without verifying it has the appropriate length. Ciphertext
messages are similarly dissected. The slice function does not raise an
error on out of bounds accesses but instead returns an empty or
partially-filled array. Empty or short arrays will be passed through to
the window.crypto.subtle API, where they will raise an error. We should
not rely on the Web Crypto API to validate key lengths or for MAC checks
to fail. Instead, validate the lengths of given parameters before
extracting their components.
// FREEBIE
This may increase processing latency a bit, particularly with large
attachments, but will ensure that messages are dispatched in the order
they are received.
It would be nice to enforce ordering on only the dispatch step, so that
we could, for example, decrypt the next websocket message while waiting
for an attachment to download, but that will require a more complicated
refactor. Will stick with the quick fix for now and revisit later.
Fixes#342
// FREEBIE
It's rare that we get in a state where we have a device record without a
session, but we should handle errors gracefully in that case. Catch them
and register them, except for identity key errors which are registered
in handleResult.
// FREEBIE
fixup error handling // FREEBIE
This function dynamically declares a bunch of functions which bind to
its input arguments. Instead, use a new prototypal class to define
these functions within the context of a particular message.
// FREEBIE
Add a pendingMessages object to MessageSender. This object holds
one promise per recipient number. We init this promise with
Promise.resolve(), and chain on promises for message sending, replacing
the previous promise with the newly chained promise each time. If the
current promise resolves and finds that it is still the last promise
in the chain, it removes itself.
Websocket resources should have their keepalive timers reset whenever a
message comes in. This is a nicety that slightly reduces the amount of
traffic we send when actively messaging.
Previously this was handled by MessageReceiver, but it's a bit cleaner
to just have the WebsocketResource add an extra 'message' event handler.
// FREEBIE
These are failing because MockSocket doesn't implement an EventTarget
interface like an actual WebSocket does, so we get an exception when
trying to call addEventListener on it. :(
// FREEBIE
Split into separate encrypt and transmit functions. Let the encryption
function also handle all wire formatting (ie, jsonification and base64
encoding), which simplifes TextSecureServer.sendMessages, removes a
TODO, and lets us save fewer params to make network errors replayable.
// FREEBIE
This ensures that the containing promise is rejected without triggering
the side effects of an uncaught exception, such as causing the debugger
to pause.
// FREEBIE
Previously would fail to register keys by using the wrong username.
The username should be <number>.<deviceid> once we've confirmed our
account and received a deviceId from the server.
// FREEBIE
`tryMessageAgain` is the routine called when re-trying a message that
failed to decrypt due to an IncomingIdentityKeyError. This handling
needs to move to MessageReceiver because it depends on
`processDecrypted` to handle incoming message protos, which depends
on a server instance in order to download attachments.
// FREEBIE
lilia
codedust