Remove 1000 messageKey limit entirely, along with custom limits (#42)
Throw error if asked to jump forward in chain by over 2000 (#43)
Remove logging from verifyMAC on mismatch (#44)
Update to new signalapp github organization (#45)
Fix code example typo in Readme (#39)
Quite a few changes to reflect new behavior around identity keys rolled
out in the Signal apps in June 2017:
- We always trust a new identity key when receiving messages
- We have a few requirements for trust when sending messages:
1) it can't have changed very recently
2) if the previous identity key had been verified by the user, the
user needs to explicitly approve a new identity key
Expose ability to delete all existing sessions - for proper reset (#35)
Allow caller to provide fillMessageKeys limit - allowing customization
of the maxiumum number of one-sided messages in a conversation (#29)
Dev:
- A number of changes to make the branch build in CI, add badge, etc.
Note: we appear to have some unreliability during our Firefox 34 builds
on Sauce. A little less than half the time the test fails with an out of
memory error.
Catching master up with the latest updates. the trust-store-changes branch has all
recent tags, and the master branch has a few readme and project-level changes.
If options.messageKeysLimit is provided by falsey, then we don't apply
any limit at all. This can be used to set no limit for communications
from your own devices.
Why would you want that? People leave their laptops closed for weeks at
a time and get this error, since their other devices are sending
messages to it constantly:
"Too many message keys for chain"
And it seems to be really hard to fix once you're in this state. Sync
messages no longer show up from the device that got into this state.
FREEBIE
Update in-memory storage implementation to parse full address strings in
saveIdentity. Update usage of saveIdentity, passing in the full address string.
This reverts commit b45ace4 and parts of 2657f00.
The purpose of the deletes was so that a session with a different identity key
couldn't get "resurrected" after an identity switch. But if the validate/save
action is happening for every encrypt/decrypt, then it shouldn't be possible
for an old identity to get invisibly resurrected.
Furthermore, at the application level we would clear sessions for all devices
on the affected number, but libsignal-protocol operates on a per-device basis,
so it can only perform what amounts to an incomplete removal.
Reflect whether a saveIdentity operation reflects a replacement of an existing
key or not. The return value can be used by the caller to decide whether they
should clear sessions for the recipient.
Pass in a direction to isTrusted, based on constants defined by the storage
implementation. These values allow the trust store to determine whether a given
key is trusted, given the directional context.
This check didn't work, which resulted in closing and then immediately
reopening the current session. Not that big a deal, since it merely
flips a flag off and back on again just before saving the session
record, but does result in spurious log statements.
`MessageCounterError` is the expected result of repeated deliveries.
Error handling in decryptWithSessionList should immediately return such
an error if it occurs. Previous to this change, a Bad MAC error to be
returned instead of a MessageCounterError, if the message in question
was encrypted for a closed session.
This was mostly used internally by SessionRecord to flag the lack of an
open session, but that can be replaced with an actual check for an open
session.
This is redundant to the identity key store, and only used to check
internal consistency between sessions and the 'current' remote identity,
though there's no particular reason we can't keep sessions from previous
identity keys.
The signal service requires this field to accompany outgoing ciphertexts.
With this change we can likely remove the correspinding getter from
SessionCipher.
