The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:48:36Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32808I can't connect anymore to tor 22020-06-27T13:48:36ZTracI can't connect anymore to tor 212/19/19, 18:13:39.773 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
12/19/19, 18:13:39.773 [NOTICE] DisableNetwork is set. Tor will not make or accep...12/19/19, 18:13:39.773 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
12/19/19, 18:13:39.773 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
12/19/19, 18:13:39.773 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
12/19/19, 18:13:39.773 [NOTICE] Opening Socks listener on 127.0.0.1:9150
12/19/19, 18:13:39.773 [NOTICE] Opened Socks listener on 127.0.0.1:9150
12/19/19, 18:13:39.773 [NOTICE] The current consensus has no exit nodes. Tor can only build internal paths, such as paths to onion services.
12/19/19, 18:13:39.773 [NOTICE] Bootstrapped 5% (conn): Connecting to a relay
12/19/19, 18:14:30.778 [WARN] Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 10; recommendation warn; host 7B68E4C2601B77B5B4313E3FCB34FD9DC8886030 at 51.15.36.229:443)
12/19/19, 18:14:30.780 [WARN] 9 connections have failed:
12/19/19, 18:14:30.780 [WARN] 9 connections died in state connect()ing with SSL state (No SSL object)
12/19/19, 18:14:30.792 [WARN] Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 11; recommendation warn; host 79E48A3242DB3515700F8925FA8E6323F8D51D7D at 37.191.194.50:8443)
12/19/19, 18:14:30.792 [WARN] 10 connections have failed:
12/19/19, 18:14:30.792 [WARN] 10 connections died in state connect()ing with SSL state (No SSL object)
12/19/19, 18:14:30.793 [WARN] Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 12; recommendation warn; host E14F6B387A832AC0F50564128B1E2BD409F1D3BD at 51.75.144.233:443)
12/19/19, 18:14:30.793 [WARN] 11 connections have failed:
12/19/19, 18:14:30.793 [WARN] 11 connections died in state connect()ing with SSL state (No SSL object)
12/19/19, 18:14:30.793 [WARN] Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 13; recommendation warn; host FF1AA085300284BA5AAC7341671E57D53EC40FE3 at 213.32.71.116:9001)
12/19/19, 18:14:30.793 [WARN] 12 connections have failed:
12/19/19, 18:14:30.793 [WARN] 12 connections died in state connect()ing with SSL state (No SSL object)
12/19/19, 18:14:30.793 [WARN] Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 14; recommendation warn; host 13BC57BE4A6287D5C9AB970E94823BCAF7B5FFB2 at 95.168.216.152:80)
12/19/19, 18:14:30.793 [WARN] 13 connections have failed:
12/19/19, 18:14:30.794 [WARN] 13 connections died in state connect()ing with SSL state (No SSL object)
12/19/19, 18:14:30.794 [WARN] Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 15; recommendation warn; host 96DCD1D17C1F0FA4DED207C148E54C0A55553076 at 108.206.76.242:9001)
12/19/19, 18:14:30.797 [WARN] 14 connections have failed:
12/19/19, 18:14:30.797 [WARN] 14 connections died in state connect()ing with SSL state (No SSL object)
12/19/19, 18:14:30.798 [WARN] Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 16; recommendation warn; host C7371E258455BC73288B7E511B63C423709D4004 at 145.239.93.255:9001)
12/19/19, 18:14:30.798 [WARN] 15 connections have failed:
12/19/19, 18:14:30.798 [WARN] 15 connections died in state connect()ing with SSL state (No SSL object)
12/19/19, 18:14:30.798 [NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150
12/19/19, 18:14:30.798 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
12/19/19, 18:14:30.798 [NOTICE] Delaying directory fetches: DisableNetwork is set.
**Trac**:
**Username**: rlkoTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32809Move AuthDir* policy entries into feature/dirauth2021-09-16T14:22:17ZNick MathewsonMove AuthDir* policy entries into feature/dirauthRight now, there are several dirauth-related configuration options that are handled in policies.c. We should move them into dirauth.Right now, there are several dirauth-related configuration options that are handled in policies.c. We should move them into dirauth.https://gitlab.torproject.org/tpo/core/tor/-/issues/32810Move timing-related authority options into dirauth module2021-09-16T14:22:17ZNick MathewsonMove timing-related authority options into dirauth moduleWe should concentrate all of the options related to vote timing into the dirauth module.
Some of these will turn out to belong in voting_schedule.c: we'll need to be careful.
The ones I know of are:
* TestingV3AuthInitialDistDelay
...We should concentrate all of the options related to vote timing into the dirauth module.
Some of these will turn out to belong in voting_schedule.c: we'll need to be careful.
The ones I know of are:
* TestingV3AuthInitialDistDelay
* TestingV3AuthInitialVoteDelay
* TestingV3AuthInitialVotingInterval
* TestingV3AuthVotingStartOffset
* V3AuthDistDelay
* V3AuthNIntervalsValid
* V3AuthVoteDelay
* V3AuthVotingIntervalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32812Move authority-mode options into dirauth module2022-06-17T18:27:41ZNick MathewsonMove authority-mode options into dirauth moduleThese are "v3authoritativedirectory" and "bridgeauthoritativedir".
Also we should be away that lots of the code indirectly asks "are we an authority": that should probably be something that we reconsider or redesign. We don't _want_ m...These are "v3authoritativedirectory" and "bridgeauthoritativedir".
Also we should be away that lots of the code indirectly asks "are we an authority": that should probably be something that we reconsider or redesign. We don't _want_ most modules invoking the authority module.
This might also mean that authmode.c belongs in src/core? There could be a better solution here.https://gitlab.torproject.org/tpo/core/tor/-/issues/32813Move V3BandwidthsFile into feature/dirauth module2020-07-29T14:21:26ZNick MathewsonMove V3BandwidthsFile into feature/dirauth moduleThis change will take some code movement, because the option is also used in dircache.c.This change will take some code movement, because the option is also used in dircache.c.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32814Move V3AuthUseLegacyKey into dirauth module2021-09-16T14:22:17ZNick MathewsonMove V3AuthUseLegacyKey into dirauth moduleThis option is also used in router.c, where maybe it should not be.This option is also used in router.c, where maybe it should not be.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32817Run sandbox tests on Xenial and Bionic2020-07-29T14:18:37ZteorRun sandbox tests on Xenial and BionicWe currently run a Tor Travis CI chutney job on Bionic with the sandbox disabled.
The chutney Travis CI runs on Bionic and Xenial (for pypy), also with the Sandbox disabled.
Once legacy/trac#32722 is fixed, we should run some sandbox u...We currently run a Tor Travis CI chutney job on Bionic with the sandbox disabled.
The chutney Travis CI runs on Bionic and Xenial (for pypy), also with the Sandbox disabled.
Once legacy/trac#32722 is fixed, we should run some sandbox unit tests, Tor binary tests, or chutney on both Xenial and Bionic, and newer Ubuntu versions as Travis creates images for them.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32818Standardise EXPOSE and INTERNAL macros to PRIVATE2020-06-27T13:48:35ZteorStandardise EXPOSE and INTERNAL macros to PRIVATEWe should rename all our EXPOSE and INTERNAL macros to PRIVATE.
Then we can simplify the PRIVATE patterns in legacy/trac#32798 and legacy/trac#32522.We should rename all our EXPOSE and INTERNAL macros to PRIVATE.
Then we can simplify the PRIVATE patterns in legacy/trac#32798 and legacy/trac#32522.Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32823support Android SharedPreferences xml as a torrc format2022-06-17T16:22:29Zeighthavesupport Android SharedPreferences xml as a torrc formatWith Tor Browser, Orbot, and other apps on Android, some Tor settings are managed via the `SharedPreferences`/`PreferenceFragment` Android classes. When used in their standard setup, these handle the whole lifecycle of preferences. Rig...With Tor Browser, Orbot, and other apps on Android, some Tor settings are managed via the `SharedPreferences`/`PreferenceFragment` Android classes. When used in their standard setup, these handle the whole lifecycle of preferences. Right now, we have to do a lot of tricks to get the settings from the Android classes, convert them to `torrc` format, then handle reloading Tor at the right time.
Android's `SharedPreferences` writes out to a standard xml file, e.g `/data/data/org.torproject.android/shared_prefs/org.torproject.android_preferences.xml`. This XML file has a simple format that has been the same since the beginning. If Tor can read this format as an optional `torrc` format, and also potentially automatically reload the config when that file changes, then the Android code will be drastically simpler. This will greatly improve the interaction around any kind of user-facing setting, like bridges, exit countries, pluggable transports, etc.
Here's an example of what the XML would look like:
```
<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
<boolean name="RunAsDaemon" value="true" />
<boolean name="AvoidDiskWrites" value="true" />
<string name="TransPort">auto</string>
<int name="DNSPort" value="5400" />
<string name="TransPort" value="auto" />
<string name="Bridges">obfs4 77.81.104.251:443 115C90EBD0EB631C177560A872535772215478D9 cert=UsuF7oN4KNKviZP54JOyTCoCphrdM5gwZK4vT8GnCAcmqLUJEJxyw1dpko9a/ii6He4iZg iat-mode=0,obfs4 5.249.146.133:80 FAF3A0073330D6AD92F3B4874B0D945562A633EF cert=TRe8bAODtjcGij7EPQaUayWEOqR99wDh2l3B4hFtCsn1JTJCph03pRZ9tx8wynpLYKWMQg iat-mode=0,meek_lite 0.0.2.0:2 97700DFE9F483596DDA6264C4D7DF7641E1E39CE url=https://meek.azureedge.net/ front=ajax.aspnetcdn.com</string>
</map>
```
We might want an alternate format for bridge lines, where would be a dedicated XML file for only bridge lines with the `name` specifying the line number:
```
<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
<string name="0">obfs4 77.81.104.251:443 115C90EBD0EB631C177560A872535772215478D9 cert=UsuF7oN4KNKviZP54JOyTCoCphrdM5gwZK4vT8GnCAcmqLUJEJxyw1dpko9a/ii6He4iZg iat-mode=0</string>
<string name="1">obfs4 5.249.146.133:80 FAF3A0073330D6AD92F3B4874B0D945562A633EF cert=TRe8bAODtjcGij7EPQaUayWEOqR99wDh2l3B4hFtCsn1JTJCph03pRZ9tx8wynpLYKWMQg iat-mode=0</string>
<string name="2">meek_lite 0.0.2.0:2 97700DFE9F483596DDA6264C4D7DF7641E1E39CE url=https://meek.azureedge.net/ front=ajax.aspnetcdn.com</string>
</map>
```
Yxml is a 6k C XML parser in a single file under an MIT license. It has been maintained since 2013. It would fit the bill quite nicely.
https://dev.yorhel.nl/yxml
Yes, XML is not an ideal format. We don't need the most problematic parts of XML for this, e.g. namespaces, custom entities, etc. and Yxml does not support them anyway.https://gitlab.torproject.org/tpo/core/tor/-/issues/32825Disable unsupported tests on android2020-06-27T13:48:34ZNick MathewsonDisable unsupported tests on androidThere are some pieces of our test suite that we should disable in Android, including user-id and homedir stuff: see legacy/trac#32172. Hans-Christoph has already done this in Guardian's branch; we should merge this back into our code.There are some pieces of our test suite that we should disable in Android, including user-id and homedir stuff: see legacy/trac#32172. Hans-Christoph has already done this in Guardian's branch; we should merge this back into our code.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32828automatically disable relay exit policy on DNS failure2020-06-27T13:48:34Zstarlightautomatically disable relay exit policy on DNS failureLarge numbers of exit relays with 100% DNS failure rates frequently appear on https://arthuredelstein.net/exits/, which by itself has proven insufficient motivation for exit operators to assure functional DNS. Enhance tor daemon to auto...Large numbers of exit relays with 100% DNS failure rates frequently appear on https://arthuredelstein.net/exits/, which by itself has proven insufficient motivation for exit operators to assure functional DNS. Enhance tor daemon to automatically disable the exit policy and fallback to not-exit operation when DNS failure rates exceed a threshold for a time.https://gitlab.torproject.org/tpo/core/tor/-/issues/32829Fix spacing in tor_inet_aton()2020-06-27T13:48:34ZNeel Chauhanneel@neelc.orgFix spacing in tor_inet_aton()Neel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/32830Relay_extended - hash and padding - specs are wrong or unclear2020-06-27T13:48:34ZAymericRelay_extended - hash and padding - specs are wrong or unclearI noticed recently plenty of 'unrecognized' relay_extended messages for node-Tor project while everything was working fine in the past after I updated the code and made it modular (and some abnormal delays to establish circuits), see als...I noticed recently plenty of 'unrecognized' relay_extended messages for node-Tor project while everything was working fine in the past after I updated the code and made it modular (and some abnormal delays to establish circuits), see also http://peersm.com/peersm2 this is temporary but I had to put a lot of debug stuff to find out what was going on
Finally I figured out why: unlike what is writen in the main Tor specs the hash is calculated not only with the real payload of the relay_extended messages but includes also the padding (apparently starting with 00000000, not sure where it comes from neither where it is specified)
This looks quite strange, what is the rationale for this, is it a bug, why is it not documented and does it impact other types of messages?Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32831create JAR artifacts for consuming geoip files in Android apps2021-04-28T14:13:30Zeighthavecreate JAR artifacts for consuming geoip files in Android appsFor Android apps, JAR files in Maven repositories are the standard way to use libraries. The _geoip_ and _geoip6_ files are a kind of library of data. So this adds the `-make-maven-artifacts` option to _src/config/mmdb-convert.py_ to g...For Android apps, JAR files in Maven repositories are the standard way to use libraries. The _geoip_ and _geoip6_ files are a kind of library of data. So this adds the `-make-maven-artifacts` option to _src/config/mmdb-convert.py_ to generate the standard Maven artifacts of these datafiles that are directly consumable in a standard Android build setup, e.g. in _build.gradle_:
```
implementation 'org.torproject:geoip:20191217'
```
These should be reproducible running them anywhere, since the timestamps come from the MaxMind file.
https://github.com/torproject/tor/pull/1631https://gitlab.torproject.org/tpo/core/tor/-/issues/32835regression: log subsystem not closing files on switch back to syslog2022-09-01T21:42:49Zstarlightregression: log subsystem not closing files on switch back to syslog```
SETCONF Log="debug file logfile001"
SETCONF Log="notice syslog"
$ fuser logfile001
logfile001: 31388
```
Did behave correctly in earlier versions.```
SETCONF Log="debug file logfile001"
SETCONF Log="notice syslog"
$ fuser logfile001
logfile001: 31388
```
Did behave correctly in earlier versions.https://gitlab.torproject.org/tpo/core/tor/-/issues/32839tor does not create HiddenServiceDir for v2 onion service2020-06-27T13:48:34ZTractor does not create HiddenServiceDir for v2 onion servicehi,
i am trying to create a v2 onion hidden service, i used the line "HiddenServiceVersion 2" in the torrc file but tor does not create the HiddenServiceDir.If i comment that line, tor does create the HiddenServiceDir as per config.
**T...hi,
i am trying to create a v2 onion hidden service, i used the line "HiddenServiceVersion 2" in the torrc file but tor does not create the HiddenServiceDir.If i comment that line, tor does create the HiddenServiceDir as per config.
**Trac**:
**Username**: hyblahttps://gitlab.torproject.org/tpo/core/tor/-/issues/32841sandbox error on 0.4.2.x2020-11-04T14:18:22Zweasel (Peter Palfrader)sandbox error on 0.4.2.x0.4.2.x has (apparently introduced) a sandbox issue. This did not happen on 0.4.1.6 before.
Currently it seems to happen every time at midnight (the hup might come from logrotate)
```
Dec 17 23:55:04.000 [notice] Uploaded signature(s)...0.4.2.x has (apparently introduced) a sandbox issue. This did not happen on 0.4.1.6 before.
Currently it seems to happen every time at midnight (the hup might come from logrotate)
```
Dec 17 23:55:04.000 [notice] Uploaded signature(s) to dirserver 171.25.193.9:443
Dec 17 23:57:30.000 [notice] Time to fetch any signatures that we're missing.
Dec 18 00:00:00.000 [notice] Time to publish the consensus and discard old votes
Dec 18 00:00:00.000 [notice] Published ns consensus
Dec 18 00:00:01.000 [notice] Published microdesc consensus
Dec 18 00:00:04.000 [notice] Received reload signal (hup). Reloading config and resetting internal state.
Dec 18 00:00:04.000 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Dec 18 00:00:04.000 [notice] Read configuration file "/etc/tor/torrc".
============================================================ T= 1576627205
(Sandbox) Caught a bad syscall attempt (syscall dup)
/usr/bin/tor(+0x1fc9fa)[0x565130b7a9fa]
/lib/x86_64-linux-gnu/libc.so.6(dup+0x7)[0x7f46a89a0bc7]
/lib/x86_64-linux-gnu/libc.so.6(dup+0x7)[0x7f46a89a0bc7]
/usr/bin/tor(tor_log_update_sigsafe_err_fds+0x18b)[0x565130b8e99b]
/usr/bin/tor(set_options+0x3c0)[0x565130b0af80]
/usr/bin/tor(options_init_from_string+0x17d)[0x565130b0d3dd]
/usr/bin/tor(options_init_from_torrc+0x404)[0x565130b0da74]
/usr/bin/tor(+0x5f961)[0x5651309dd961]
/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x22a6c)[0x7f46a8ff8a6c]
/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7)[0x7f46a8ff9537]
/usr/bin/tor(do_main_loop+0xff)[0x5651309f23af]
/usr/bin/tor(tor_run_main+0x1105)[0x5651309dfd55]
/usr/bin/tor(tor_main+0x3a)[0x5651309dd23a]
/usr/bin/tor(main+0x19)[0x5651309dcdf9]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f46a88da09b]
/usr/bin/tor(_start+0x2a)[0x5651309dce4a]
```
and
```
Dec 20 00:00:00.000 [notice] Published microdesc consensus
Dec 20 00:00:05.000 [notice] Received reload signal (hup). Reloading config and resetting internal state.
Dec 20 00:00:05.000 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Dec 20 00:00:05.000 [notice] Read configuration file "/etc/tor/torrc".
============================================================ T= 1576800005
(Sandbox) Caught a bad syscall attempt (syscall dup)
/usr/bin/tor(+0x1fc9fa)[0x55ffd52439fa]
/lib/x86_64-linux-gnu/libc.so.6(dup+0x7)[0x7fcb63423bc7]
/lib/x86_64-linux-gnu/libc.so.6(dup+0x7)[0x7fcb63423bc7]
/usr/bin/tor(tor_log_update_sigsafe_err_fds+0x18b)[0x55ffd525799b]
/usr/bin/tor(set_options+0x3c0)[0x55ffd51d3f80]
/usr/bin/tor(options_init_from_string+0x17d)[0x55ffd51d63dd]
/usr/bin/tor(options_init_from_torrc+0x404)[0x55ffd51d6a74]
/usr/bin/tor(+0x5f961)[0x55ffd50a6961]
/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x22a6c)[0x7fcb63a7ba6c]
/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7)[0x7fcb63a7c537]
/usr/bin/tor(do_main_loop+0xff)[0x55ffd50bb3af]
/usr/bin/tor(tor_run_main+0x1105)[0x55ffd50a8d55]
/usr/bin/tor(tor_main+0x3a)[0x55ffd50a623a]
/usr/bin/tor(main+0x19)[0x55ffd50a5df9]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7fcb6335d09b]
/usr/bin/tor(_start+0x2a)[0x55ffd50a5e4a]
```Tor: 0.4.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32845Add UTF-8 validation unit tests2020-06-27T13:48:33ZteorAdd UTF-8 validation unit testsWe should add unit tests for the following UTF-8 sequences. Their validity varies between different programming languages. We should go with the common case (if it matches the standard).
Invalid:
surrogate nullsurrog threehigh
EDA081 30...We should add unit tests for the following UTF-8 sequences. Their validity varies between different programming languages. We should go with the common case (if it matches the standard).
Invalid:
surrogate nullsurrog threehigh
EDA081 3000EDA081 EDBFBF
fourhigh fivebyte sixbyte sixhigh
F490BFBF FB80808080 FD80808080 FDBFBFBFBF
Valid:
fourbyte fourbyte2
F0908D88 F0BFBFBF
Valid in the Unicode standard, invalid in torrcs and directory documents:
nullbyte
3031320033
See proposal 285 for details, and for the null byte exception:
https://gitweb.torproject.org/torspec.git/tree/proposals/285-utf-8.txt
Test Case Source:
`POC||GTFO 19`, page 43
https://www.alchemistowl.org/pocorgtfo/Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32846Tor Manual: Alphabetize Client Options2021-07-22T16:19:07ZTracTor Manual: Alphabetize Client OptionsThis ticket is for the alphabetical sorting of Client options. Making this a child ticket for legacy/trac#4310.
**Trac**:
**Username**: swatiThis ticket is for the alphabetical sorting of Client options. Making this a child ticket for legacy/trac#4310.
**Trac**:
**Username**: swatihttps://gitlab.torproject.org/tpo/core/tor/-/issues/32847Tor 0.4.3.0-alpha-dev asserts when quitting while visiting an onion service2021-02-25T15:32:27ZTracTor 0.4.3.0-alpha-dev asserts when quitting while visiting an onion serviceReproducibility: often
Steps:
Quit Tor Browser Nightly.
What happened:
Crash.
Expected result:
No crash.
**Trac**:
**Username**: rex4539Reproducibility: often
Steps:
Quit Tor Browser Nightly.
What happened:
Crash.
Expected result:
No crash.
**Trac**:
**Username**: rex4539Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org