The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:24:17Zhttps://gitlab.torproject.org/tpo/network-health/metrics/onionoo/-/issues/16907Stop returning a 500 Internal Server Error when the hourly updater has not ru...2020-06-27T14:24:17ZKarsten LoesingStop returning a 500 Internal Server Error when the hourly updater has not run for 6+ hoursWhen the hourly updater has not run for 6 hours or more, the server responds to all queries with a 500 Internal Server Error. This seemed to be a good idea, because users would tell us when the hourly updater was broken and we could fix...When the hourly updater has not run for 6 hours or more, the server responds to all queries with a 500 Internal Server Error. This seemed to be a good idea, because users would tell us when the hourly updater was broken and we could fix it. But actually, it's a really bad idea, because there are valid cases when we need to stop the hourly updater, for example, for making backups. Last night's backup took 10 hours, which is not really sane, but which is not a good reason to break the service for all clients. I also have a Nagios check in place that warns me when the hourly updater stops running, so that I don't rely on poor users to find out when things are broken and tell me.
The suggested change is to just serve whatever data is available, regardless of when it was written. Usually, it would be less than two hours old. But we might also serve 5 hours or 25 hours or 100 hours old data. It would be up to clients like Atlas and Globe to warn their users that the displayed data is outdated.
I'm not implementing this right now, because I want to give the Atlas and Globe maintainers the chance to add such warnings to their applications. I'd want to implement this in a month from now, if possible.https://gitlab.torproject.org/tpo/core/tor/-/issues/28079Stop returning the empty string when the cstr! macro fails2021-09-16T14:27:19ZteorStop returning the empty string when the cstr! macro failsSplit off legacy/trac#28077:
> > from_bytes_with_nul returns an error if there is more than one nul byte in the string.
> > ...
> > Returning an empty string could be a source of subtle bugs.
> Misuse is extremely unlikely to slip in s...Split off legacy/trac#28077:
> > from_bytes_with_nul returns an error if there is more than one nul byte in the string.
> > ...
> > Returning an empty string could be a source of subtle bugs.
> Misuse is extremely unlikely to slip in since this is only used on string literals. But yeah, the ideal solution would be statically asserting at compile-time that the passed literal has no NUL bytes in it, so the only one is the byte being appended.
>
> But defaulting to an empty string(in a case that is basically impossible to get) is the intentional documented behavior of the macro ever since it was first [merged](https://gitweb.torproject.org/tor.git/commit/?h=tor-0.3.4.1-alpha&id=bda1dfb9e0a863ae1ec1230c23ed74837be01a35) in legacy/trac#25185. Improving on that seems like a separate ticket.https://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/34103Stop rounding y axis labels with units2022-07-07T00:57:12ZKarsten LoesingStop rounding y axis labels with unitsThe [Time to download files over Tor graph](https://metrics.torproject.org/torperf.html) now displays the following labels, all using seconds as units: 0, 0, 1, 2, 2, 2. Better labels would be 0.0, 0.5, 1.0, 1.5, 2.0, 2.5.
Similarly, th...The [Time to download files over Tor graph](https://metrics.torproject.org/torperf.html) now displays the following labels, all using seconds as units: 0, 0, 1, 2, 2, 2. Better labels would be 0.0, 0.5, 1.0, 1.5, 2.0, 2.5.
Similarly, the [Advertised bandwidth distribution graph](https://metrics.torproject.org/advbwdist-perc.html?start=2015-01-19&end=2020-04-18&p=50) showing the median displays the following labels, all using Gbit/s: 0.00, 0.02, 0.05, 0.08. Better labels would be 0.000, 0.025, 0.050, 0.075.
The underlying issue, which we didn't fix in legacy/trac#33933 nor in legacy/trac#33066, is that we have to pick a number of digits for a graph which then needs to work for whichever scale is being displayed. In some cases this is difficult to do right (first graph above with measurements apparently getting faster over time), in other cases it's impossible (second graph above with 1st and 99th percentile having different orders of magnitude).
The fix is to stop using the `unit_format` function from the somewhat outdated `scales` package that we're using and instead write our own function for formatting labels with units.
I'm going to attach two example graphs where this went wrong plus a patch that I'll review more carefully tomorrow before I deploy it on the server.Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/tpo/core/tor/-/issues/28568Stop running stem's unit tests in Tor's stem test2020-06-27T13:51:35ZteorStop running stem's unit tests in Tor's stem testAs noted by atagar in:
https://trac.torproject.org/projects/tor/ticket/28552#comment:4
We can use --integ rather than --all.As noted by atagar in:
https://trac.torproject.org/projects/tor/ticket/28552#comment:4
We can use --integ rather than --all.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/28897Stop running twice destination usability tests2020-06-27T13:41:23ZjugaStop running twice destination usability testsEvery time that a relay is measured, it is first checked whether destination is usable, and then run connect_to_destination_over_circuit, which checks again if destination is "usable".
It implies two locks, and a destination can fail in ...Every time that a relay is measured, it is first checked whether destination is usable, and then run connect_to_destination_over_circuit, which checks again if destination is "usable".
It implies two locks, and a destination can fail in a row due to the relay being unstable.
It'd be better to determine that a destination is not usable, either by trying to make a connection not over Tor, or after a X number of failures in a row.sbws: 1.0.x-finaljugajugahttps://gitlab.torproject.org/tpo/network-health/metrics/collector/-/issues/20983Stop sanitizing contact information from bridge descriptors2023-05-15T14:02:55ZcypherpunksStop sanitizing contact information from bridge descriptorscontext:
https://lists.torproject.org/pipermail/tor-dev/2016-December/011756.html
Why does CollecTor remove ContactInfo from bridge descriptors?
Publishing the ContactInfo should not (directly) reveal the bridge location?
use-case for...context:
https://lists.torproject.org/pipermail/tor-dev/2016-December/011756.html
Why does CollecTor remove ContactInfo from bridge descriptors?
Publishing the ContactInfo should not (directly) reveal the bridge location?
use-case for that data:
bridge group detection
If plain publishing is not acceptable how about generating a random string replacement for a given ContactInfo string.
https://lists.torproject.org/pipermail/tor-dev/2016-December/011761.html
That mapping contactInfo -> random id should remain static for at least 24 hours.Metrics OKR Q1 - Q2 2022https://gitlab.torproject.org/tpo/core/tor/-/issues/10758Stop serving version 2 directory information by default2020-06-27T14:03:30ZKarsten LoesingStop serving version 2 directory information by defaultThe third and last directory authority stopped serving version 2 directory information a week ago, and apparently the Tor network survived. We should make it the new default that directory authorities don't serve version 2 directory inf...The third and last directory authority stopped serving version 2 directory information a week ago, and apparently the Tor network survived. We should make it the new default that directory authorities don't serve version 2 directory information, so that the three directory authorities don't need the "DisableV2DirectoryInfo_ 1" torrc lines anymore.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/33583Stop setting AssumeReachable on chutney relays and bridges2020-07-23T20:36:05ZteorStop setting AssumeReachable on chutney relays and bridgesWe need to stop setting AssumeReachable on relays and bridges in chutney networks, so they do reachability self-tests.
We should continue to set AssumeReachable on authorities (including the bridge authority), because it disables author...We need to stop setting AssumeReachable on relays and bridges in chutney networks, so they do reachability self-tests.
We should continue to set AssumeReachable on authorities (including the bridge authority), because it disables authority to relay reachability tests. (These tests are still performed on a half-hourly schedule, even in chutney networks. And they are out of scope for Sponsor 55.)
After we implement this change, we should also be able to implement legacy/trac#33581.Sponsor 55: Improving the Tor network’s IPv6 supportteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24490Stop setting bridges running in networkstatus_getinfo_by_purpose()2021-09-16T14:31:40ZteorStop setting bridges running in networkstatus_getinfo_by_purpose()A GETINFO controller function shouldn't modify vital data structures.
Instead, we should make sure the list is up to date regularly, or that it is updated before we call this function.
This bug was introduced in commit 74d05f4 in tor-0...A GETINFO controller function shouldn't modify vital data structures.
Instead, we should make sure the list is up to date regularly, or that it is updated before we call this function.
This bug was introduced in commit 74d05f4 in tor-0.2.0.13-alpha.Tor: 0.4.1.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/chutney/-/issues/23976Stop setting CircuitIdleTimeout in chutney, it's obsolete2020-06-27T13:18:47ZteorStop setting CircuitIdleTimeout in chutney, it's obsoletehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/28370stop setting obsolete media.eme.apiVisible pref2020-06-27T14:34:36ZMark Smithstop setting obsolete media.eme.apiVisible prefIn https://bugzilla.mozilla.org/show_bug.cgi?id=1242321 (for Firefox 54) Mozilla removed all code that used the `media.eme.apiVisible` pref. We should also remove it from `browser/app/profile/000-tor-browser.js`.In https://bugzilla.mozilla.org/show_bug.cgi?id=1242321 (for Firefox 54) Mozilla removed all code that used the `media.eme.apiVisible` pref. We should also remove it from `browser/app/profile/000-tor-browser.js`.https://gitlab.torproject.org/tpo/core/chutney/-/issues/27230Stop setting PathsNeededToBuildCircuits to a low value2020-06-27T13:18:45ZteorStop setting PathsNeededToBuildCircuits to a low valueIt caused legacy/trac#27080, and it's not a good idea to depart from the Tor defaults.
When we make this change, we need to run "make test-network-all" on all supported tor versions.It caused legacy/trac#27080, and it's not a good idea to depart from the Tor defaults.
When we make this change, we need to run "make test-network-all" on all supported tor versions.teorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27648Stop setting the IPv6 preferred flag on nodes2020-07-28T23:00:38ZteorStop setting the IPv6 preferred flag on nodesInstead:
* for guards, decide on the address to use at random
* for bridges, decide on the address to use at random, but make it more likely that we will use the configured addressInstead:
* for guards, decide on the address to use at random
* for bridges, decide on the address to use at random, but make it more likely that we will use the configured addressTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30797Stop shipping an abandoned systemd script?2021-09-16T14:23:38ZRoger DingledineStop shipping an abandoned systemd script?legacy/trac#19759, legacy/trac#19761, legacy/trac#19762 are bugs filed on the systemd script that we ship in "contrib/dist/tor.service.in".
The bugs haven't been looked at in years, and it looks like nobody on our side is paying attenti...legacy/trac#19759, legacy/trac#19761, legacy/trac#19762 are bugs filed on the systemd script that we ship in "contrib/dist/tor.service.in".
The bugs haven't been looked at in years, and it looks like nobody on our side is paying attention to this systemd script. That sounds to me like we would consider people foolish if they tried to use it.
Should we confirm that somebody, somewhere else on the internet, has a better systemd script than we do, and then remove ours?Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16199Stop shipping generated Trunnel files in git repository2020-06-27T14:01:09ZNick MathewsonStop shipping generated Trunnel files in git repositoryTor: unspecifiedhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40971Stop shipping Linux i686 debug archive until we actually produce the symbols2023-11-27T18:08:47ZPier Angelo VendrameStop shipping Linux i686 debug archive until we actually produce the symbols@richard noticed the Linux i686 debug archive is only 6MB.
When I enabled it I didn't realize that we're not producing debug symbols on Linux because of an old bug with the GNU linker that might have been solved (we haven't checked yet)...@richard noticed the Linux i686 debug archive is only 6MB.
When I enabled it I didn't realize that we're not producing debug symbols on Linux because of an old bug with the GNU linker that might have been solved (we haven't checked yet).
I think we shouldn't ship this archive for 13.0, and get back to it in 13.5a1 or after we solve tor-browser#42146.Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/core/tor/-/issues/31040Stop showing git scripts changes, unless the base is master2020-06-27T13:49:51ZteorStop showing git scripts changes, unless the base is masterIn legacy/trac#29588, we made the pre-merge script log changes to the git scripts.
But it logs (the wrong) changes when I'm merging into maint-0.4.1 or earlier.
Let's just make it log changes when it's merging into master?In legacy/trac#29588, we made the pre-merge script log changes to the git scripts.
But it logs (the wrong) changes when I'm merging into maint-0.4.1 or earlier.
Let's just make it log changes when it's merging into master?Tor: 0.4.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13538Stop signed left shift overflows in curve25519-donna (non-64-bit)2020-06-27T14:02:20ZteorStop signed left shift overflows in curve25519-donna (non-64-bit)Similarly to legacy/trac#13280, the curve25519-donna.c code contains some signed left shifts of negative numbers, which clang identifies as runtime errors. (This is only an issue with the generic code, not the 64-bit code.)
Under -ftrap...Similarly to legacy/trac#13280, the curve25519-donna.c code contains some signed left shifts of negative numbers, which clang identifies as runtime errors. (This is only an issue with the generic code, not the 64-bit code.)
Under -ftrapv, this causes a trap/crash.
I've used a similar strategy to the one in legacy/trac#13280, where we automate the entire SHL32/SHL64 conversion using a perl script. The first commit sets up the macros.
The safe SHL32/SHL64 macros perform potentially overflowing left shifts in unsigned arithmetic.
I'll post a branch as soon as I've set up a change entry (for which I need the bug number).
Version: tor 2.6.?-alpha
git: fc5cab44724e8328e2186f22114625388f1c8f0d (Thu Oct 16 13:29:14 2014 -0400)Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13280Stop signed left shift overflows in ed255192020-06-27T14:02:26ZteorStop signed left shift overflows in ed25519The new ed25519 code contains some signed left shifts of negative numbers, which clang identifies as runtime errors.
Under -ftrapv, this causes a trap/crash.
Without -ftrapv, this causes about 100 warnings during the tests like:
crypto...The new ed25519 code contains some signed left shifts of negative numbers, which clang identifies as runtime errors.
Under -ftrapv, this causes a trap/crash.
Without -ftrapv, this causes about 100 warnings during the tests like:
crypto/ed25519_simple: src/ext/ed25519/ref10/ge_scalarmult_base.c:42:48: runtime error: left shift of negative value -2
(log attached)
A patch is attached that performs potentially overflowing left shifts in unsigned arithmetic. Macros SHL64 and SHL32 are defined for convenience.
This is my first patch using git format-patch with a changes entry - let me know if it needs revising.
Version: tor 2.6.?-alpha
git: 5190ec0bc4c22d7bab756e21db6e357ba07379c4Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17945Stop single hop client connections to Single Onion Services2020-06-27T13:59:52ZteorStop single hop client connections to Single Onion ServicesTor2Web clients make a one-hop connection to HSDirs, intro points, and rend points. Single Onion Services also make a one-hop connection to the rendezvous point.
This uses Tor as a one-hop proxy (in this case, to a single onion service)...Tor2Web clients make a one-hop connection to HSDirs, intro points, and rend points. Single Onion Services also make a one-hop connection to the rendezvous point.
This uses Tor as a one-hop proxy (in this case, to a single onion service), which we try to avoid, because it enables certain attacks. We also try to avoid single hop connections in the onion service protocol, because they give IP addresses to middle relays.
See the child tickets for details.Tor: unspecified