The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-02-04T08:32:48Zhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/4020710.5a7-build2 Linux64 mismatch2021-02-04T08:32:48ZMatthew Finkel10.5a7-build2 Linux64 mismatchComparing acat's and my `tor-browser-linux64-10.5a7_en-US.tar.xz` we have:
```
-87f0a8b965f25c8491624eb22e22e4a58a5b5d7b2105e4e7312643ef77cc444b linux64/tor-browser_en-US/Browser/TorBrowser/Tor/PluggableTransports/obfs4proxy ...Comparing acat's and my `tor-browser-linux64-10.5a7_en-US.tar.xz` we have:
```
-87f0a8b965f25c8491624eb22e22e4a58a5b5d7b2105e4e7312643ef77cc444b linux64/tor-browser_en-US/Browser/TorBrowser/Tor/PluggableTransports/obfs4proxy
-264f38f77ad07f391b68253c05f3a7fcab20ec5e06ebd79b3442fba8cd1d699a linux64/tor-browser_en-US/Browser/TorBrowser/Tor/PluggableTransports/snowflake-client
+a7b7c0e3d5f0979fa7b117e792196b638413b1c3fbf87f447d902a0455648341 linux64/tor-browser_en-US/Browser/TorBrowser/Tor/PluggableTransports/obfs4proxy
+43a8f7d39f5e44633d8128a020dab2cd50db5a2b195395b389c95931c46eb29e linux64/tor-browser_en-US/Browser/TorBrowser/Tor/PluggableTransports/snowflake-client
```
Looking at those, they differ by:
```
--- acat.obfs4proxy.xxd 2021-01-18 16:43:47.685480270 +0000
+++ sysrqb.obfs4proxy.xxd 2021-01-18 16:43:56.085494140 +0000
@@ -247,9 +247,9 @@
00000f60: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000f70: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000f80: 0400 0000 5300 0000 0400 0000 476f 0000 ....S.......Go..
-00000f90: 4659 6e35 7843 3676 7745 3469 4133 6c7a FYn5xC6vwE4iA3lz
-00000fa0: 564a 7239 2f78 6c56 4b4b 7a38 7546 5646 VJr9/xlVKKz8uFVF
-00000fb0: 3847 6159 6639 4562 522f 496e 4543 676d 8GaYf9EbR/InECgm
+00000f90: 7a76 6466 5153 6438 5032 5044 4263 4d49 zvdfQSd8P2PDBcMI
+00000fa0: 6a6c 5259 2f61 7864 6450 6c46 3236 6248 jlRY/axddPlF26bH
+00000fb0: 7765 6d69 574f 4a77 752f 496e 4543 676d wemiWOJwu/InECgm
00000fc0: 3248 3635 6b78 555a 4451 5853 5f30 2f61 2H65kxUZDQXS_0/a
00000fd0: 3678 4562 5751 4730 6239 4e6f 4a78 2d35 6xEbWQG0b9NoJx-5
00000fe0: 434f 7300 2f6c 6962 3634 2f6c 642d 6c69 COs./lib64/ld-li
```
```
--- acat.snowflake-client.xxd 2021-01-18 16:46:59.973819114 +0000
+++ sysrqb.snowflake-client.xxd 2021-01-18 16:47:07.277832763 +0000
@@ -247,9 +247,9 @@
00000f60: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000f70: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000f80: 0400 0000 5300 0000 0400 0000 476f 0000 ....S.......Go..
-00000f90: 5276 3157 4e58 657a 326b 3931 4e2d 6b51 Rv1WNXez2k91N-kQ
-00000fa0: 3679 6d4d 2f66 6f75 2d5f 5f33 3536 662d 6ymM/fou-__356f-
-00000fb0: 6538 5f6e 3851 344c 592f 6b33 7946 485f e8_n8Q4LY/k3yFH_
+00000f90: 4569 4d4e 4447 5139 4378 6952 5138 384c EiMNDGQ9CxiRQ88L
+00000fa0: 3541 7077 2f76 726b 6157 4d42 6c63 6b65 5Apw/vrkaWMBlcke
+00000fb0: 5064 5737 364f 3842 302f 6b33 7946 485f PdW76O8B0/k3yFH_
00000fc0: 7758 3239 3953 7771 6d59 4d2d 534d 2f62 wX299SwqmYM-SM/b
00000fd0: 6354 4178 4848 7953 7262 2d36 346a 6b37 cTAxHHySrb-64jk7
00000fe0: 7056 7900 2f6c 6962 3634 2f6c 642d 6c69 pVy./lib64/ld-li
```Tor Browser: 10.5https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40205Prep 10.5a72021-01-22T15:31:11ZMatthew FinkelPrep 10.5a7- [x] tor-browser#40293
- [x] #40204
- [x] tor-browser#40297
- [x] android-components#40036
- [x] fenix#40134
- [x] tor-browser-build#40190
- [x] tor-browser-build#40191
- [x] #40165- [x] tor-browser#40293
- [x] #40204
- [x] tor-browser#40297
- [x] android-components#40036
- [x] fenix#40134
- [x] tor-browser-build#40190
- [x] tor-browser-build#40191
- [x] #40165Tor Browser: 10.5https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/4020810.5a7-build2 Android mismatch2022-02-23T18:28:05ZMatthew Finkel10.5a7-build2 Android mismatchDifferent from #40207
```
--- acat.android-x86_64.filelist.sha256 2021-01-18 16:58:00.452669252 +0000
+++ sysrqb.android-x86_64.filelist.sha256 2021-01-18 16:57:43.948573779 +0000
@@ -456,7 +456,7 @@
7d8df6264700eae16233122cfcb7...Different from #40207
```
--- acat.android-x86_64.filelist.sha256 2021-01-18 16:58:00.452669252 +0000
+++ sysrqb.android-x86_64.filelist.sha256 2021-01-18 16:57:43.948573779 +0000
@@ -456,7 +456,7 @@
7d8df6264700eae16233122cfcb7ccc83177ae986b9fa2fb522e5135875facda android-x86_64/assets/searchplugins/youtube.xml
8ca7bd3bd2ca30c8e65150ea52e1c00ef418021569ac73c7fb48ac2079ee1299 android-x86_64/assets/shared_error_style.css
a97624851f3ccb4f9746802cfe5d75fe983aff5b477bfd659445d12734f1d42f android-x86_64/classes2.dex
-f6a0a0e3de5d1e5aa52921f563e738e5a7a48633851d846cdb1fb0657e9f35be android-x86_64/classes.dex
+40caf93c6533ef8a3d193f1ae86e83ce429d82f1943a68e92bdce92d2e0e6738 android-x86_64/classes.dex
ab6d48d5d868c733cd03345f8aabae3d905bd6f0fc661117a8bdfea6c51b9274 android-x86_64/DebugProbesKt.bin
cb93b54f651ad6fa439d8fc33c8e0be1a9b2085df88edc2f267c83f4cffd2f76 android-x86_64/firebase-common.properties
2f74bb762ee0dee50b0a05eee510dd4196ef8e033ea9d2e1cba3eeec91941fda android-x86_64/firebase-components.properties
```
```
--- acat/android-x86_64/classes.dex.xxd 2021-01-18 17:09:11.875703985 +0000
+++ sysrqb/android-x86_64/classes.dex.xxd 2021-01-18 17:09:18.439728415 +0000
@@ -1,5 +1,5 @@
-00000000: 6465 780a 3033 3500 38ce 3d2f f0f4 8076 dex.035.8.=/...v
-00000010: 923c 44d6 d9e6 0274 d031 e7c3 0bd5 c80b .<D....t.1......
+00000000: 6465 780a 3033 3500 0fcf d2e2 2b9a 7fc2 dex.035.....+...
+00000010: 03ce f5a8 e4fb 6a9e 0b8f ebba f134 16d1 ......j......4..
00000020: 4c85 8100 7000 0000 7856 3412 0000 0000 L...p...xV4.....
00000030: 0000 0000 7084 8100 f2ec 0000 7000 0000 ....p.......p...
00000040: 1028 0000 38b4 0300 ee32 0000 7854 0400 .(..8....2..xT..
@@ -466363,7 +466363,7 @@
0071dba0: 2c22 6861 732d 6368 6563 6b73 756d 7322 ,"has-checksums"
0071dbb0: 3a66 616c 7365 2c22 6d69 6e2d 6170 6922 :false,"min-api"
0071dbc0: 3a32 312c 2270 672d 6d61 702d 6964 223a :21,"pg-map-id":
-0071dbd0: 2230 3836 3936 3934 222c 2276 6572 7369 "0869694","versi
+0071dbd0: 2239 6439 3362 3164 222c 2276 6572 7369 "9d93b1d","versi
0071dbe0: 6f6e 223a 2232 2e30 2e38 3822 7d00 017f on":"2.0.88"}...
0071dbf0: 0001 c2a3 003f c380 c381 c382 c383 c384 .....?..........
0071dc00: c385 c386 c387 c388 c389 c38a c38b c38c ................
```
This is a different reproducibility issue than #40151Tor Browser: 10.0https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40169Container creation for Linux 32bit builds us busted (visible after #40166 lan...2020-12-09T12:22:17ZGeorg KoppenContainer creation for Linux 32bit builds us busted (visible after #40166 landed)```
E: Unable to locate package libgtk2.0-dev
E: Couldn't find any package by regex 'libgtk2.0-dev'
``````
E: Unable to locate package libgtk2.0-dev
E: Couldn't find any package by regex 'libgtk2.0-dev'
```Tor Browser: 10.0https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40610Migrate a generalized Moat implementation to Moat.jsm module2021-10-13T12:44:01ZrichardMigrate a generalized Moat implementation to Moat.jsm moduleWe need to add support to Tor Browser to access new Moat APIs (see: tpo/anti-censorship/bridgedb#40025). To do so we would need refactor the tor-launcher Moat code a fair bit, so instead we should just migrate and async/await'ify the rel...We need to add support to Tor Browser to access new Moat APIs (see: tpo/anti-censorship/bridgedb#40025). To do so we would need refactor the tor-launcher Moat code a fair bit, so instead we should just migrate and async/await'ify the relevant code to a Moat.jsm module rather than potentially break the legacy tor-launcher.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetrichardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40477Implementing Tor Browser quickstart's proposal on automatically detecting cen...2021-10-04T13:31:43ZGabagaba@torproject.orgImplementing Tor Browser quickstart's proposal on automatically detecting censorship for censored users (proposal 106)We want to suggest which bridges to use based on where the user is connecting from (improving the user flow for users requesting bridges). For this we are implementing the 'detecting censorship' part of the quickstart UX proposal https:...We want to suggest which bridges to use based on where the user is connecting from (improving the user flow for users requesting bridges). For this we are implementing the 'detecting censorship' part of the quickstart UX proposal https://gitlab.torproject.org/tpo/applications/tor-browser-spec/-/blob/master/proposals/106-quickstart.txt
## Problems
1. how to know where the user is connecting from? What explicit consent is required from users before attempting automation of country detection and/or performing connections?
solution a: show the user a list of countries and they select which ones to get bridges for. What explicit consent is required from users before attempting automation of country detection and/or performing connections?
2. what do we show if the user still can not connect with the suggested bridges?
3. how to get an accurate list of bridges that work in each country?
# Scope of Work
- Unify vocabulary in the interface and user manuals. Attach the name "bridge" to any intermediate node that allows users to reach the network. <-- need ticket
- Inform users in Tor Launcher of which settings are best for them based on their country
- [ ] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40259
- [ ] https://gitlab.torproject.org/tpo/community/outreach/-/issues/28531
- [ ] https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/34
- Make it easier to add a bridge in network settings https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/14638. @antonela Can you clarify what you are proposing here?
# User Flow
"The user opens the Tor Browser and automatically connects. If interference is detected, then an explainer error page appears, and a Use a Bridge is offered."
Interesting information on how Briar is approaching it: https://lists.torproject.org/pipermail/tor-dev/2019-February/013708.html
/cc @meskio @richard @antonela @dunqanSponsor 30 - Objective 3.3richardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40597Create TorSettings module to handle modifying all tor daemon settings2024-03-19T20:58:03ZrichardCreate TorSettings module to handle modifying all tor daemon settingsMove the implementation out of the about:preferences#tor pane into a module that is accessed by said preferences page, as well as the #40259 censorship-circumvention systemMove the implementation out of the about:preferences#tor pane into a module that is accessed by said preferences page, as well as the #40259 censorship-circumvention systemrichardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40250Rebase Tor Browser Stable onto 83.02020-11-26T14:55:43ZMatthew FinkelRebase Tor Browser Stable onto 83.0https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40222Bump GCC version for Linux builds to 10.3.02021-10-06T22:22:33ZGeorg KoppenBump GCC version for Linux builds to 10.3.0When switching to Firefox 86 (see: #40168), compiling our ASan build with GCC 9.3.0 results in
```
18:56.43 {standard input}: Assembler messages:
18:56.84 {standard input}:2051862: Warning: end of file not at end of a line; newline inser...When switching to Firefox 86 (see: #40168), compiling our ASan build with GCC 9.3.0 results in
```
18:56.43 {standard input}: Assembler messages:
18:56.84 {standard input}:2051862: Warning: end of file not at end of a line; newline inserted
18:56.84 {standard input}:2052290: Warning: Unary operator - ignored because bad operand follows
18:56.84 {standard input}:2052290: Error: missing or invalid displacement expression `-'
18:56.84 {standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive
18:57.25 g++.real: fatal error: Killed signal terminated program cc1plus
18:57.25 compilation terminated.
18:57.32 /var/tmp/build/firefox-89324d7a4cef/config/rules.mk:674: recipe for target 'UnifiedBindings22.o' failed
18:57.32 make[4]: *** [UnifiedBindings22.o] Error 1
```
Bumping GCC to the latest stable solves this issue. (And it is a good thing anyway when doing the switch away from ESR)Tor Browser: 11.0 Issues with previous releasehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40048Use llvm-project folder structure instead of our custom one2022-12-08T15:15:26ZGeorg KoppenUse llvm-project folder structure instead of our custom oneRight now we copy us the components together we want to use when
building our clang doing custom things like putting `libunwind` into a
special place as we only need it for getting built for our Windows builds.
We should just switch to ...Right now we copy us the components together we want to use when
building our clang doing custom things like putting `libunwind` into a
special place as we only need it for getting built for our Windows builds.
We should just switch to `llvm-project` and then use the particular
projects in it we need by passing the right CMake flags.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/34451Include Tor Browser Manual in packages during build2022-12-08T15:15:25ZMatthew FinkelInclude Tor Browser Manual in packages during buildIn tor-browser#11698 we are discussing of what we need to bundle an offline manual.
My proposal is to limit the changes on tor-browser, and inject the "compiled" manual during the build.
The rationale behind this is it's a simple solut...In tor-browser#11698 we are discussing of what we need to bundle an offline manual.
My proposal is to limit the changes on tor-browser, and inject the "compiled" manual during the build.
The rationale behind this is it's a simple solution, Tor Browser has its own pace for changes, and the manual has another one, they have different requirements, not doubling the efforts is always good, especially with localization, etc...
The main disadvantage I see is that injecting contents into `omni.ja` is a bit hackish.
(It also make creating dev builds outside tor-browser-build more difficult, but contrarily to NoScript/HTTPS-E, the manual isn't a funding TBB part).
So, for this issue, first we need to setup a new project to build the manual in all languages.
We discussed about using the same tools used for the website (e.g., lektor), but with a slightly different configuration.
In particular, since the URLs of `omni.ja` contents are quite ugly/really not meaningful to the users, we'd like to serve the manual through an `about:` page.
However, I _think_ that associating multiple HTML files with a single about page could be involved (I'm not sure how slashes are handled by `nsAboutRedirector`).
So, since lektor can create single page sites, we should investigate about such configuration.
Stylesheets, images and any scripts will need to have the correct `chrome://` URL.
The second part of this issue is modifying the `tor-browser` project to inject the manual in the `omni.ja`.Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/core/arti/-/issues/5Send and receive DESTROY cells correctly2020-10-15T12:48:00ZNick MathewsonSend and receive DESTROY cells correctlyArti currently doesn't send DESTROY cells when circuits close; it doesn't notice that circuits close when they are dropped. I should fix both of those problems.
Additionally, ISTR that we have some notion of recently destroyed circui...Arti currently doesn't send DESTROY cells when circuits close; it doesn't notice that circuits close when they are dropped. I should fix both of those problems.
Additionally, ISTR that we have some notion of recently destroyed circuits where we accept cells for a little while until we don't any more. We should implement that too, and make sure there's a spec for it.
* [x] Handle incoming DESTROY cells correctly
* [x] Send DESTROY cells when a circuit closes
* [x] Send DESTROY cell when a circuit is dropped.
* [x] Make sure that if a DESTROY cell goes out, we don't send any more on the circuit.
* [x] Make sure all circuit objects get closed if a channel dies or is shut down.
* [x] Make sure we have an appropriate means for handling for what Tor handles with `channel_mark_circid_unusable()`.
* [x] Make sure we have an appropriate means for handling for what Tor handles with `channel_note_destroy_pending()`.
* [x] Do the right thing for handling incoming cells to an unrecognized circuit.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40158Specify overload relay descriptors for load balancing and network health2023-03-17T11:44:35ZMike PerrySpecify overload relay descriptors for load balancing and network healthWe need to specify descriptor fields to signify when relays:
1. [ ] Are at or near CPU overload
2. [ ] Are at or near OOM killer invocation
3. [ ] Are at or near connection count limits
4. [ ] At or near their token bucket limit
5. [ ] ...We need to specify descriptor fields to signify when relays:
1. [ ] Are at or near CPU overload
2. [ ] Are at or near OOM killer invocation
3. [ ] Are at or near connection count limits
4. [ ] At or near their token bucket limit
5. [ ] Accumulating too many cells in queues (circuitmux, tls outbuf, aes)
6. [ ] Are failing too many onionskins, tls handshakes, other things?
7. [ ] Flag/checks to signify which relays are on the same machine
The specification should only emit enough information to determine if relays are at or near various forms of overload. They should *not* report detailed statistics, as these may aid in DoS attacks and traffic analysis.
With this information, we will use sbws to avoid allocating extra load to these relays, as well as use these fields to report unhealthy relays on the metrics portal, and investigate other misbehavior.
I can work on this spec but I will need much input from @dgoulet.Sponsor 61 - Making the Tor network faster & more reliable for users in Internet-repressive placesDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40254Can't migrate ORPort options from 0.4.4.6 to 0.4.5.3-rc2021-01-27T14:36:55ZVortCan't migrate ORPort options from 0.4.4.6 to 0.4.5.3-rcHello.
I was using unusual configuration for my relay:
Relay was listening at public IPv4 address and private IPv6 address:
```
ORPort 443
ORPort [ipv6_address]:ipv6_port NoAdvertise
```
IPv6 address belongs to Yggdrasil network, but it...Hello.
I was using unusual configuration for my relay:
Relay was listening at public IPv4 address and private IPv6 address:
```
ORPort 443
ORPort [ipv6_address]:ipv6_port NoAdvertise
```
IPv6 address belongs to Yggdrasil network, but it actually does not matter.
What important is that my IPv6 interface have no access to Internet.
This configuration was working fine with Tor 0.4.4.6.
But with upgrade to 0.4.5.3-rc, Tor begins to open not only IPv4:443, but also IPv6:443, which is, of course, then marked as unreachable.
I thought that it is possible to disable IPv6 listening at 443 port by modifying config this way:
```
ORPort 443 IPv4Only
ORPort [ipv6_address]:ipv6_port NoAdvertise
```
But then my log file began to be flooded with such messages:
```
Jan 22 15:55:04.000 [notice] Self-testing indicates your ORPort ipv4_address:443 is reachable from the outside. Excellent. Publishing server descriptor.
Jan 22 15:55:05.000 [notice] Guessed our IP address as [ipv6_address] (source: METHOD=INTERFACE).
Jan 22 15:55:05.000 [notice] Self-testing indicates your ORPort ipv4_address:443 is reachable from the outside. Excellent. Publishing server descriptor.
Jan 22 15:55:06.000 [notice] Guessed our IP address as [ipv6_address] (source: METHOD=INTERFACE).
Jan 22 15:55:06.000 [notice] Self-testing indicates your ORPort ipv4_address:443 is reachable from the outside. Excellent. Publishing server descriptor.
Jan 22 15:55:07.000 [notice] Guessed our IP address as [ipv6_address] (source: METHOD=INTERFACE).
...
```
Adding `Address ipv4_address` to `torrc` did not helped too.
Please let me know how to properly configure new version of Tor.
Or fix a bug if it should work, but not working as intended.Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40253Extend the DoS subsystem to block addrs that connect too often too2022-10-11T23:39:35ZRoger DingledineExtend the DoS subsystem to block addrs that connect too often tooRight now we have a connection-based DoS component which triggers on *concurrent* ORPort connections. That is, *if* you have 3 concurrent connections *and* you [write me more]Right now we have a connection-based DoS component which triggers on *concurrent* ORPort connections. That is, *if* you have 3 concurrent connections *and* you [write me more]Tor: 0.4.6.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40257Crash on MetricsPort when prematurely terminating socket2021-02-08T19:28:33ZNeel Chauhanneel@neelc.orgCrash on MetricsPort when prematurely terminating socketIf I setup a `MetricsPort` and telnet into it, and then prematurely terminate the socket without doing anything, we get a crash:
Jan 23 14:03:51.000 [notice] Bootstrapped 100% (done): Done
Jan 23 14:03:56.000 [warn] conn_read_ca...If I setup a `MetricsPort` and telnet into it, and then prematurely terminate the socket without doing anything, we get a crash:
Jan 23 14:03:51.000 [notice] Bootstrapped 100% (done): Done
Jan 23 14:03:56.000 [warn] conn_read_callback: Bug: Unhandled error on read for Metrics connection (fd 10); removing (on Tor 0.4.6.0-alpha-dev 878c124e0dda4cde)
Jan 23 14:03:56.000 [warn] tor_bug_occurred_: Bug: src/core/mainloop/mainloop.c:899: conn_read_callback: This line should not have been reached. (Future instances of this warning will be silenced.) (on Tor 0.4.6.0-alpha-dev 878c124e0dda4cde)
Jan 23 14:03:56.000 [warn] Bug: Tor 0.4.6.0-alpha-dev (git-878c124e0dda4cde): Line unexpectedly reached at conn_read_callback at src/core/mainloop/mainloop.c:899. Stack trace: (on Tor 0.4.6.0-alpha-dev 878c124e0dda4cde)
Jan 23 14:03:56.000 [warn] Bug: 0x130985c <log_backtrace_impl+0x5c> at /usr/home/neel/code/tor/tor/src/app/tor (on Tor 0.4.6.0-alpha-dev 878c124e0dda4cde)
Jan 23 14:03:56.000 [warn] Bug: 0x1317d91 <tor_bug_occurred_+0x1d1> at /usr/home/neel/code/tor/tor/src/app/tor (on Tor 0.4.6.0-alpha-dev 878c124e0dda4cde)
Jan 23 14:03:56.000 [warn] Bug: 0x116a843 <conn_read_callback+0x1021103> at /usr/home/neel/code/tor/tor/src/app/tor (on Tor 0.4.6.0-alpha-dev 878c124e0dda4cde)
Jan 23 14:03:56.000 [warn] Bug: 0x80140519d <event_base_assert_ok_nolock_+0xbfd> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.6.0-alpha-dev 878c124e0dda4cde)
Jan 23 14:03:56.000 [warn] Bug: 0x80140112c <event_base_loop+0x58c> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.6.0-alpha-dev 878c124e0dda4cde)
Jan 23 14:03:56.000 [warn] Bug: 0x116cbba <do_main_loop+0x12a> at /usr/home/neel/code/tor/tor/src/app/tor (on Tor 0.4.6.0-alpha-dev 878c124e0dda4cde)
Jan 23 14:03:56.000 [warn] Bug: 0x1155f1c <tor_run_main+0x12c> at /usr/home/neel/code/tor/tor/src/app/tor (on Tor 0.4.6.0-alpha-dev 878c124e0dda4cde)
Jan 23 14:03:56.000 [warn] Bug: 0x1154871 <tor_main+0x61> at /usr/home/neel/code/tor/tor/src/app/tor (on Tor 0.4.6.0-alpha-dev 878c124e0dda4cde)
^CJan 23 14:04:02.000 [notice] Interrupt: exiting cleanly.
neel@concorde:~/code/tor/tor %Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40261dos: Move subsystem to the subsys manager2022-10-11T23:39:35ZDavid Gouletdgoulet@torproject.orgdos: Move subsystem to the subsys managerIn order to be able to export `MetricsPort` data from the DoS subsystem (in part with tor#40259), we need the DoS subsystem to be added to the subsys manager so the `get_metrics()` method can be used.
Furthermore, to do it right, we nee...In order to be able to export `MetricsPort` data from the DoS subsystem (in part with tor#40259), we need the DoS subsystem to be added to the subsys manager so the `get_metrics()` method can be used.
Furthermore, to do it right, we need to move all configuration options within the module as well so we have better modularization.
This ticket is for this work.Tor: 0.4.6.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33624Static building tor with openssl does not work2021-02-06T05:05:34ZDavid Gouletdgoulet@torproject.orgStatic building tor with openssl does not workWe have couple opened ticket about building OpenSSL statically: legacy/trac#31565 and legacy/trac#32871 are the one I could find.
I've been working on this to measure the size of tor as a shared library for mobile environment for which ...We have couple opened ticket about building OpenSSL statically: legacy/trac#31565 and legacy/trac#32871 are the one I could find.
I've been working on this to measure the size of tor as a shared library for mobile environment for which we need to build tor with openssl and libevent statically.
At current master, this is not working for build system and code reasons.
This ticket is to address it all so we can close all other related tickets.
Here is a raw tor.git diff that makes this work. There is still some think to consider especially with the `OPENSSL_VERSION`:
https://gitlab.torproject.org/dgoulet/tor-library-size/blob/master/tor.diffTor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40173tracing-instrumentation-lttng doesn't build: 'core/or/lttng_circuit.inc' file...2022-07-07T00:48:31Zyurivicttracing-instrumentation-lttng doesn't build: 'core/or/lttng_circuit.inc' file not found```
In file included from src/core/or/circuitlist.c:68:
./src/core/or/trace_probes_circuit.h:18:10: fatal error: 'core/or/lttng_circuit.inc' file not found
#include "core/or/lttng_circuit.inc"
```
0.4.5.1-alpha on FreeBSD 12.2```
In file included from src/core/or/circuitlist.c:68:
./src/core/or/trace_probes_circuit.h:18:10: fatal error: 'core/or/lttng_circuit.inc' file not found
#include "core/or/lttng_circuit.inc"
```
0.4.5.1-alpha on FreeBSD 12.2Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40063stats: Create a stat exporter port for monitoring purposes2021-06-23T17:22:08ZDavid Gouletdgoulet@torproject.orgstats: Create a stat exporter port for monitoring purposesThe `Control Port` does basically export a lot of data that tor holds but this new `Stat Port` (we'll call that for now) differs in a couple of ways.
The idea is that it would be a pull mechanism so tools connect to the port, request a ...The `Control Port` does basically export a lot of data that tor holds but this new `Stat Port` (we'll call that for now) differs in a couple of ways.
The idea is that it would be a pull mechanism so tools connect to the port, request a series of stats, tor sends it and then disconnects. This follows the Prometheus model which is to expose your stats through an HTTP interface and the monitoring server just comes in regularly and get the data.
Tor has already everything to support that that is listener port and HTTP interface we can hook on (with a bit of work :).
We can export all sorts of stats useful for monitoring relays and onion services. For example, for onion service monitoring, exporting these would be game changer for service operators:
1. Amount of traffic the .onion is getting
2. Amount of introduction requests
3. Amount of rendezvous requests and how many succeeds vs fails.
4. Descriptor status with HSDir
...
The reason it differs from the Control Port is that most public relays or onion services would prefer not having that port open **especially** on a public address. But also, this follows the concept of providing a `REST` interface which would be very little amount of work for the tor daemon where with the control port, is often a mixed of poking at our internal state instead of a pre-populated memory with stats.
There is of course the question of data safety here. If we build nice interface that in couple clicks allows operators to have beautiful Grafana graphs, then some says it is an incentive to export it and sometimes publicly.
However, this is really not different from the Control Port or Nyx monitoring interface. The problem shows up when the third part tool gathering the data actually archives. That today, is doable. This would yes be lowering the bar for this to happen but I think the ability to properly monitor a relay or an onion service outweigh the cons.
We could see that at first it is only for onion services and on a non public port. We could think of security checks like this but in the end, this is would just be another tool in the service operator belt to properly monitor tor if they choose to with of course risks associated with it like anything tor opens.
This is one example that @ahf worked on but with a push model: https://github.com/ahf/tor/tree/ahf/feature/stats_reporterTor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org