Upadted iOS Tor.Framework to Latest Tor 0.4.9.5

[bitmold]

Was having difficulty testing the iOS app on the nearly 6 year old version of Tor included in the app. It supported v2 onion services. The logs would be flooded with warnings saying this Tor is old and that it'd have a harder and harder time forming circuits over the tor network.

@kingalg had some problems with Tor 0.4.8.21 when that was included in the big PR. This updates to the newer 0.4.9 series and the changes can be tested in isolation on this branch.

[adrastaea]

I'm getting some tor related errors when closing the app on iOS. They don't seem to persistently break functionality when I reopen the app, but I wanted to bring this to your attention.

===================================================
========= T= 1773939499
INTERNAL ERROR: Raw assertion failed in Tor 0.4.9.5
(git-1442ca4852283d66) at
src/lib/lock/compat_mutex_pthreads.c:120: 0
Error destroying a mutex.
0 Tor
0x0000000105f95f40 dump_stack_symbols_to_error_fds

• 88
  1 Tor
  0x0000000105f96c4c tor_raw_assertion_failed_msg_ +
  424
  2 Tor
  0x0000000106005504 tor_mutex_uninit.cold.3 + 44
  3 Tor
  0x0000000105f9ffec tor_mutex_uninit + 132
  4 Tor
  0x0000000105f9a334 threadpool_free_ + 252
  5 Tor
  0x0000000105ede540 cpuworker_free_all + 48
  6 Tor
  0x0000000105f687c4 tor_free_all + 56
  7 Tor
  0x0000000105f187a0 tor_run_main + 5092
  8 Tor
  0x0000000105b1a40c -[TORThread main] + 324
  9 Foundation
  0x000000018622f21c
  42C593BB-89FB-3EC4-8220-C746811E7A43 + 401948
  10 libsystem_pthread.dylib
  0x00000001e570c44c _pthread_start + 136
  11 libsystem_pthread.dylib
  0x00000001e57088cc thread_start + 8
  Type: stdio

[bitmold]

I'm seeing that there's now some merge conflicts with the Podfile and one of the Xcode project files. I'll rebase off the latest develop later today when I'm in front of a mac...

[bitmold]

@adrastaea @holmesworcester regarding the crash Taea found earlier:

I'm getting some tor related errors when closing the app on iOS. They don't seem to persistently break functionality when I reopen the app, but I wanted to bring this to your attention.

For one thing, the type of crash is especially frustrating because this PR doesn't change how the iOS app integrates with Tor at all (this PR is essentially just the necessary boilerplate needed to get our xcode project building with newer tor releases)

My $0.02 is that if and only if we're only seeing these crashes after stopping+reopening Quiet, and if the app never breaks/crashes in a way that negatively impacts a user, then I think i'ts acceptable to merge this PR even though there are technically still crashes being logged that the user is unaware of. Although, with the caveat that we open a ticket to investigate how the biggest Tor.framework apps integrate with both the iOS system and the tor network in 2026... outlined more below 🔽 )

If on the other hand Taea's crash persistently breaks functionality then of course this PR is no good in its current state and we'd have to go back to the drawing board and figure out how to safely move to newer versions of tor. In such a scenario, a valuable stopgap strategy can be incrementally upgrading Tor.Framework release-by-release up from the antique 0.4.5.9 we have today, to increasingly newer releases -- with this approach, we'd at least be able to quickly move to the most modern version of Tor/Tor.Framework that Quiet can safely upgrade to without breaking anything (ideally such a process would also help shine a light on how a specific Tor/Tor.framework release, if any, could have broken Quiet's seemingly stable iOS+Tor.Framework integration.

But in either case, there are still very important reasons to prioritize getting a working Tor upgrade shipped out ASAP ... As the half-decade chasm between the unsupported tor v 0.4.5.9 and the newest releases widens, the iOS app will in turn start deteriorating into a useless state. This is because as time goes tor relays will become pickier about talking to older versions of Tor... which effectively impedes and eventually denies the iOS app to establish any connection to the tor network that abandoned it. Today you may have a slow connection on iOS, then tomorrow its a bit more painful but still works, until eventually there is only s i l e n c e ...... 🪦 💀 🪦 💀 🪦 💀 On the flip side though, I've noticed that the benefits of using the new Tor in this PR are rather pronounced: the iOS app seems to connect to other Quiet users a great deal faster than before.

It seems like it'd be very wise for us to take a look at how the biggest+most popular Tor.Framework iOS apps respond to system life cycle events (such as app closing/reopening). Since Taea can reproduce this issue around closing+reopening, my gut instinct is that Quiet is most likely improperly integrating with all of the lifecycle events/system states that are to be expected of modern iOS apps. It could be possible that this Tor crash is occurring as a side effect of this larger issue. Or it could be, that that this issue was silently present before this PR - the only difference being that the PR's modern Tor invokes tor_raw_abort() instead of failing more quietly... (tor_raw_abort()' is an internal Tor API that wraps C's abort() method - it's often explicitly used to by developer's to intentionally crash tor's process @runtime in circumstances where tor takes on an invalid state, the idea is to crash tor instead of continuing to use it in unacceptable/undefined ways at runtime.)

Onion Browser and orbot for iOS seem like the best places to start looking...

[adrastaea]

It seemed in my testing like it was safe. I just wanted to check with you that the crash text didn't seem more serious.