* Ignore `exclusiveProcessIdentifier` parameter
This was added in fee1bbddad, but the `NS_UNAVAILABLE` declarations
weren’t updated, which led to warnings in Xcode.
* Ignore `TSThread` initializer in subclasses
* Fix `TSAttachmentPointer` ignored initializer
* Add missing initializers to `TSMessage` subclasses
This only handles the immediate subclasses. There’s still more warnings
in the extended hierarchy, but those don’t seem to have been handled as
consistently in the first place, so updating them is more involved.
This only calls the block, and the formatting in the old design made it
particularly difficult to read. (It also makes this path and the success
path more similar in their construction.)
This removes calls to `arc4random` and `arc4random_uniform` and replaces
them with calls to `Int.random` or equivalent.
These are a little less readable, which may be [why SwiftLint doesn't
like them][0]. (SwiftLint calls them "legacy", possibly because they're
not strong random number generators, but I couldn't find a clear
explanation for this anywhere, including [the original PR][1].)
This is the kind of change that's error-prone, so I wrote [a simple
script to help avoid regressions][2]. The script runs 10,000 iterations
of the old and new RNG and compares the ranges, reporting differences.
(Some differences are likely, like the ones that involve floats; others
are very unlikely to have differences.)
`git grep arc4random | grep swift` returns no results after this change.
Same for [everything else SwiftLint checks for][3].
[0]: https://realm.github.io/SwiftLint/legacy_random.html
[1]: https://github.com/realm/SwiftLint/pull/2419
[2]: https://gist.github.com/EvanHahn-Signal/9c75c9f484f4778149cbde3eafc9b285
[3]: ea6cc50890/Source/SwiftLintFramework/Rules/Idiomatic/LegacyRandomRule.swift (L23-L27)
_I recommend reviewing this with whitespace changes disabled._
Signal has renamed its primary branch to `main`. This updates references
to the old name, `master`, to either reference `main` or a specific
commit hash.
I also fixed a couple of small whitespace issues in a file I was
editing.
We already have the deserialized envelope at the point where we're
first checking, but also we don't even use any information from it
besides the source address.
This commit also stops checking whether a group context has a revision
once we've created a job; I think that's reasonable.
They aren't needed; the code only checked that the envelope had some
content, any content.
No functionality change in practice: all call sites already had
plaintext data alongside the envelope, where that data was assumed to
come from the envelope, proving it had content.
Pre-keys are refreshed at regular (throttled) intervals, but the
"refresh" operation will only actually upload new pre-keys if the
server says we're running low. In addition, after the "refresh",
there's a "rotation" operation for the signed pre-key if the current
one is more than two days old. This only runs if the refresh was
skipped, since uploading new one-time pre-keys is already an
opportunity to rotate the signed pre-key (and it's worth doing so,
since pre-keys running low can indicate high traffic).
None of this has changed. However, we can now do this for both ACI and
PNI pre-keys. This reworked +[TSPreKeyManager
checkPreKeysWithShouldThrottle:] quite a bit to declare the proper
operation dependencies, which isn't *strictly* necessary because the
queue they're executed on is already limited to a
maxConcurrentOperationCount of 1. We could remove that at this point
with proper use of "barrier" operations, but since all the operations
are hitting the server and account updates have to be serialized on
*that* end, there doesn't seem to be much of a benefit.
This doesn't handle
- device linking (we need to send the PNI identity key as well as the
ACI identity key)
- existing devices that need PNI keys (that'll be an explicit check)
Save the PNI after registration and when verifying or updating our
current phone number. (Also, show it in the Internal settings like the
phone number and ACI.)
This is intended to catch requests to the server that could be causing
problems in the memory-constrained environment of the NSE. It's
unlikely, since we log *all* network requests and we haven't seen any
suspicious ones, but it could still be useful in the future.
Note that this only applies to data tasks, not download tasks; a
download task can be as big as it needs to be.
Every single message updates a TSThread model, but only a change in a
member's profile name or phone number, or a change to a group's model,
can update the indexing information. Turn 'shouldBeIndexedForFTS' into
a tri-state 'FTSIndexMode' with options 'never', 'manualUpdates', and
'always', and use 'manualUpdates' for TSThreads. Then explicitly
reindex on any of the changes listed above.
