* 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 was added in 04892da490, but it changes generated code, so
re-running the generated removes it. Remove it so that the next codegen
can change only the things related to that codegen.
There are some Swift-only features that are part of these protocols, so
they were split into Obj-C and Swift variants. However, the class itself
only reports conformance to the Swift variant, which leads to warnings
when using the class in Objective-C.
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.)
Emoji availability is tested by *drawing the emoji to a graphics
context* and seeing if it comes out as a replacement character glyph.
This is not the fastest operation, so we cache it, and update the
cache whenever the user updates their version of iOS. This cache
previously lived in SDSKeyValueStore, i.e. in a shared table in the
database. Reading it took longer than we might like even before we get
to updating it, and it's not even secret data at all.
This commit replaces the SDSKeyValueStore with a plist file and adds a
migration to remove the SDSKeyValueStore data.
As we come into a PNI-capable world, the primary device checks to see
if the server has the correct PNI identity key, due to possible
failures in the initial upload. Unfortunately, I got the check for
that backwards. Fix that and add more logging.
This change:
1. Configures [SwiftLint's `type_name` rule][0] to allow for very long
types, which we use, and to allow `Id` as a type name
2. Fixes a few trivial violations of the rule that weren't covered by
that
[0]: https://realm.github.io/SwiftLint/type_name.html
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)
Each attachment-to-be-removed may have a different model object
representing the message, and there may have also been previous
deletions without refreshing these models. So asking whether the
message has any attachments left might give an out-of-date answer. Fix
this by doing an explicit database query to count remaining
attachments, and refreshing the message model before deletion if
necessary.
_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.
Previously, MediaGallery built "album" objects as it loaded items,
adding them to the album as they were loaded. This could be a problem
if items were ever *re*loaded, because then the old model would be in
the album and the new model in the top-level "sections" table. Having
potentially-inconsistent models floating around already isn't great,
but MediaGalleryAlbum and MediaGalleryItem also formed a reference
cycle.
Now, MediaGalleryAlbums are built on demand when showing the "page"
view by walking forward and backwards from an item. GalleryRailView
uses object identity to check whether we've changed albums, so
MediaPageViewController now keeps track of the most recent album and
checks its items to see if it needs to refresh it. This is a linear
check, but that's just not that bad for a message album, which will
only ever have a handful of attachments. (Even if this gets up to,
say, 100 items, that's just not that much work for a modern phone.)
There was a bug that caused avatars to be
encrypted with the wrong key, causing them to be
undecryptable both by ourselves and others.
That bug (IOS-2262) was fixed in #4078.
The purpose of this PR is to replace the broken
avatars with good ones.
PNI identity keys for existing accounts are uploaded the first time
the primary notices that it doesn't have a PNI identity key. However,
if that upload is interrupted, the local state would be out of sync
with the server. We can try to be more careful about that, but *this*
PR will manually get them out of that state by explicitly doing a
profile fetch for our own PNI and seeing if the identity key we get
back is what we expect. If not, we upload it again as if it were the
first time.
The existing index was not useful for the query we needed. Running this
query would open a write transaction for several seconds on every
launch. This new index should be much faster.
We can only *really* trust this once the certificate validates, and
even then the certificate could be out of date. So now the mapping is
only treated as high-trust when the inner messages decrypts
successfully too.
If the CreatePreKeysOperation fails on registration, we don't ever
retry it, and registration is considered to have failed anyway. If it
fails for the first time we create PNI keys, though, the identity key
will still be saved locally, and therefore we won't try again until
regular pre-key rotation happens. To guard against this, wipe a
newly-generated identity key if the upload to the service fails.
If an existing account ever generates a new PNI identity key, it
should immediately tell its linked devices. This is faster than
waiting for a sync request, and also better for keeping linked devices
on the same page.
This small change cleans up two things for the donate URL:
1. Moves it into a constant in `TSConstants`
2. Adds a trailing slash to the URL (because the server will redirect
you without one)
I think these cleanups are useful by themselves, but I'll be using the
constant again in an upcoming change and split this off into its own
small commit.
Made sure I could still open the URL in the app.
This upgrades [GRDB][0] from v4.3.0 to v5.23.0, the latest version.
I closely followed the [migration guide][1] and stole from a prior
attempt at this upgrade. I also made sure to test the media gallery,
because that allegedly had problems before.
[0]: https://github.com/groue/GRDB.swift
[1]: 6d3f309cad/Documentation/GRDB5MigrationGuide.md
