The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-04-18T06:56:46Zhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40833base-browser nightly is using the default channel instead of nightly2023-04-18T06:56:46Zboklmbase-browser nightly is using the default channel instead of nightlybase-browser nightly is missing `--enable-update-channel=[% c("var/channel") %]` in `projects/firefox/build`.base-browser nightly is missing `--enable-update-channel=[% c("var/channel") %]` in `projects/firefox/build`.boklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41426base-browser nightly fails to build for windows-i6862022-11-17T15:31:31Zboklmbase-browser nightly fails to build for windows-i686base-browser nightly currently fails to build for windows-i686 with the following error:
```
0:25.92 checking for valloc in malloc.h... no
0:25.94 checking for valloc in unistd.h... no
0:25.96 checking for _aligned_malloc in malloc.h....base-browser nightly currently fails to build for windows-i686 with the following error:
```
0:25.92 checking for valloc in malloc.h... no
0:25.94 checking for valloc in unistd.h... no
0:25.96 checking for _aligned_malloc in malloc.h... yes
0:25.97 checking if app-specific confvars.sh exists... /var/tmp/build/firefox-3018199c65eb/browser/confvars.sh
0:25.97 ERROR: STUB installer expected to be enabled but
0:25.97 ERROR: USE_STUB_INSTALLER is not specified in the environment
0:25.97 DEBUG: <truncated - see config.log for full output>
0:25.97 DEBUG: #define _BSD_SOURCE 1
0:25.97 DEBUG: #endif
0:25.97 DEBUG: #include <sys/types.h>
0:25.97 DEBUG: #include <netinet/in.h>
0:25.97 DEBUG: #include <arpa/nameser.h>
0:25.97 DEBUG: #include <resolv.h>
0:25.97 DEBUG:
0:25.97 DEBUG: int main() {
0:25.97 DEBUG: int foo = res_ninit(&_res);
0:25.97 DEBUG: ; return 0; }
0:25.97 DEBUG: configure:4665: checking for __thread keyword for TLS variables
0:25.97 DEBUG: configure:4677: /var/tmp/dist/mingw-w64-clang/bin/i686-w64-mingw32-clang++ -std=gnu++17 -o conftest.exe -fms-extensions -D_HAS_EXCEPTIONS=0 -fno-exceptions -Wno-incompatible-ms-struct -mstackrealign -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -Qunused-arguments -Wl,--no-seh -Wl,--no-insert-timestamp -Wl,--large-address-aware -Wl,--icf=safe -shared conftest.C 1>&5
0:25.97 DEBUG: configure:4748: checking for malloc.h
0:25.97 DEBUG: configure:4761: /var/tmp/dist/mingw-w64-clang/bin/i686-w64-mingw32-clang -std=gnu99 -c -D_HAS_EXCEPTIONS=0 -mstackrealign -ffunction-sections -fdata-sections -fno-math-errno -Qunused-arguments conftest.c 1>&5
0:25.97 DEBUG: configure:4796: checking whether malloc_usable_size definition can use const argument
0:25.97 DEBUG: configure:4807: /var/tmp/dist/mingw-w64-clang/bin/i686-w64-mingw32-clang -std=gnu99 -c -D_HAS_EXCEPTIONS=0 -mstackrealign -ffunction-sections -fdata-sections -fno-math-errno -Qunused-arguments conftest.c 1>&5
0:25.97 DEBUG: configure:4829: checking for valloc in malloc.h
0:25.97 DEBUG: configure:4854: checking for valloc in unistd.h
0:25.97 DEBUG: configure:4879: checking for _aligned_malloc in malloc.h
0:25.97 DEBUG: configure:4960: checking if app-specific confvars.sh exists
0:25.97 ERROR: old-configure failed
Running "pip check" to verify compatibility between the system Python and the "mach" site.
Running "pip check" to verify compatibility between the system Python and the "build" site.
*** Fix above errors and then restart with "./mach build"
Finishing build (script: build): 2022-11-07 04:20:21
Build time: 0 hours 5 minutes and 25 seconds
```Sponsor 131 - Phase 2 - Privacy Browserrichardrichardhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19462base*_encode/decode functions should clear any unused portion of their target...2020-06-27T13:58:44ZNick Mathewsonbase*_encode/decode functions should clear any unused portion of their target buffer.For safety, it's not great to leave uninitialized data in a buffer.
Occasionally, this would pose a performance cost. But I maintain that mostly it won't, and we can improve the callsites where it would.For safety, it's not great to leave uninitialized data in a buffer.
Occasionally, this would pose a performance cost. But I maintain that mostly it won't, and we can improve the callsites where it would.Tor: 0.2.9.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/network-health/metrics/onionoo/-/issues/40030Base submodule and commons codec version update2022-09-26T14:39:10ZHiroBase submodule and commons codec version updateWe should update commons codec and the base submodule.We should update commons codec and the base submodule.HiroHirohttps://gitlab.torproject.org/tpo/ux/team/-/issues/37banner(s) for tpo.org2019-10-24T12:46:53ZPili Guerrabanner(s) for tpo.orgYear End Campaign 2019Antonelaantonela@torproject.orgAntonelaantonela@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/17565Banner on about:tor page2020-06-27T14:39:57ZArthur EdelsteinBanner on about:tor pageWe should add a banner on Tor Browser's about:tor page that links to the crowdfunding donation page. This will make most users aware of the crowdfunding campaign when Tor Browser updates next.
It might be fun and helpful to users to mak...We should add a banner on Tor Browser's about:tor page that links to the crowdfunding donation page. This will make most users aware of the crowdfunding campaign when Tor Browser updates next.
It might be fun and helpful to users to make it look stylistically similar to the crowdfunding page. Ideally we would translate the banner to several languages.
The next Tor Browser release is December 15, so we should aim for then at the very latest.Arthur EdelsteinArthur Edelsteinhttps://gitlab.torproject.org/tpo/core/tor/-/issues/397bandwidthrate unreadable ?2020-06-27T14:10:44ZTracbandwidthrate unreadable ?Hello,
I'm a new Tor user and I tried to set up server mode. However, I always get these warnings (they come 1 time / min, approx.)
févr. 24 14:29:34:078 [Warning] bandwidthrate unreadable or 0. Failing.
févr. 24 14:29:34:250 [Warning...Hello,
I'm a new Tor user and I tried to set up server mode. However, I always get these warnings (they come 1 time / min, approx.)
févr. 24 14:29:34:078 [Warning] bandwidthrate unreadable or 0. Failing.
févr. 24 14:29:34:250 [Warning] router_rebuild_descriptor(): Couldn't allocate string for descriptor.
Does it means my server is KO ? I don't know if it's a problem in my configuration or a bug.
Thanks for your help
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: zambetti0.1.2.x-finalhttps://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/issues/55BandwidthParser obtain `r_strm` as `rstrmFilt`2023-11-02T18:20:25ZjugaBandwidthParser obtain `r_strm` as `rstrmFilt`Working on tpo/network-health/metrics/monitoring-and-alerting#29 i obtained the same values for `r_strm` and `r_strm_filt` per relay, which are usually different. Looking at the [parser code](https://gitlab.torproject.org/tpo/network-hea...Working on tpo/network-health/metrics/monitoring-and-alerting#29 i obtained the same values for `r_strm` and `r_strm_filt` per relay, which are usually different. Looking at the [parser code](https://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/blob/main/src/main/java/org/torproject/metrics/descriptorparser/parsers/BandwidthParser.java?ref_type=heads#L412) i realized that it's getting `r_strm` when it seems to be parsing `r_strm_filt`.jugajugahttps://gitlab.torproject.org/tpo/core/tor/-/issues/2704BandwidthObserved higher than BandwidthBurst2020-06-27T14:08:35ZTracBandwidthObserved higher than BandwidthBurstgot this line looking at my relay:
Bandwidth (Max/Burst/Observed - In Bps): 340992 / 1022976 / 30676070
1h20 after an upgrading from 0.2.2.22-alpha to 0.2.2.23-alpha
**Trac**:
**Username**: kebgot this line looking at my relay:
Bandwidth (Max/Burst/Observed - In Bps): 340992 / 1022976 / 30676070
1h20 after an upgrading from 0.2.2.22-alpha to 0.2.2.23-alpha
**Trac**:
**Username**: kebTor: 0.2.2.x-finalSebastian HahnSebastian Hahnhttps://gitlab.torproject.org/tpo/core/tor/-/issues/802BandwidthBurst rate being used constantly2020-06-27T14:10:12Zmicahmicah@torproject.orgBandwidthBurst rate being used constantlyI have three machines, all configured exactly the same way acting as round-robin web servers. They get an even distribution
of traffic, averaging 50kbps in and 200kbps out and have had an even distribution amongst the nodes for a year an...I have three machines, all configured exactly the same way acting as round-robin web servers. They get an even distribution
of traffic, averaging 50kbps in and 200kbps out and have had an even distribution amongst the nodes for a year and a half.
I installed tor on one of the nodes to test an exit enclave setup, with the idea that if it worked well, I would deploy it
to the other nodes (as well as elsewhere). I used the following configuration:
SocksPort 0 # what port to open for local application connections
SocksListenAddress 127.0.0.1 # accept connections only from localhost
Log notice syslog
RunAsDaemon 1
DataDirectory /var/lib/tor
Nickname auk
Address my.ip.here
OutboundBindAddress my.ip.here
ContactInfo my.contact.info.here
ORPort 9001
ExitPolicyRejectPrivate 0
ExitPolicy accept my.ip.here:80
ExitPolicy accept my.ip.here:443
ExitPolicy reject *:*
BandwidthRate 250 KB
BandwidthBurst 1MB
As you can see, I set BandwidthBurst to 1MB, and BadwidthRate to be 250KB, but looking at my bandwidth usage
statistics, I see that this node is using 1MB the entire time, averaging 872kbps in and 1.03M out (almost always at
this rate, with some fluctuations up to 2.35M in and 2.71M out.
This doesn't seem like what I would expect for these bandwidth settings, I could be misunderstanding how these
are applied, and if so please tell me what I am missing.
Thanks for your work on tor, its appreciated!
[Automatically added by flyspray2trac: Operating System: Other Linux]https://gitlab.torproject.org/tpo/web/support/-/issues/252bandwidth-shaping script link Path not found2022-06-14T15:01:36Zcypherpunksbandwidth-shaping script link Path not foundon page:
https://support.torproject.org/operators/bandwidth-shaping/
The link from last script, leads to nowhere.
https://gitweb.torproject.org/tor.git/tree/contrib/operator-tools/linux-tor-prio.sh
Path not foundon page:
https://support.torproject.org/operators/bandwidth-shaping/
The link from last script, leads to nowhere.
https://gitweb.torproject.org/tor.git/tree/contrib/operator-tools/linux-tor-prio.sh
Path not foundhttps://gitlab.torproject.org/tpo/community/support/-/issues/33943bandwidth-shaping script link Path not found2021-09-02T18:37:51Zcypherpunksbandwidth-shaping script link Path not foundon page:
https://support.torproject.org/operators/bandwidth-shaping/
The link from last script, leads to nowhere.
https://gitweb.torproject.org/tor.git/tree/contrib/operator-tools/linux-tor-prio.sh
Path not foundon page:
https://support.torproject.org/operators/bandwidth-shaping/
The link from last script, leads to nowhere.
https://gitweb.torproject.org/tor.git/tree/contrib/operator-tools/linux-tor-prio.sh
Path not foundGusGushttps://gitlab.torproject.org/tpo/core/tor/-/issues/28599bandwidth-file-spec.txt: bandwidth-avg is not calculated from any bandwidth b...2021-02-18T15:34:40Zjugabandwidth-file-spec.txt: bandwidth-avg is not calculated from any bandwidth burst option```
bandwidth-avg is the minimum of MaxAdvertisedBandwidth,
BandwidthRate, RelayBandwidthRate, BandwidthBurst, and
RelayBandwidthBurst.
```
(https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-spec.txt#n315)
This s...```
bandwidth-avg is the minimum of MaxAdvertisedBandwidth,
BandwidthRate, RelayBandwidthRate, BandwidthBurst, and
RelayBandwidthBurst.
```
(https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-spec.txt#n315)
This should be:
```
bandwidth-avg is the minimum of MaxAdvertisedBandwidth, BandwidthRate, RelayBandwidthRate,
bandwidth-burst is the minimum of BandwidthBurst, and RelayBandwidthBurst.
```Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1294Bandwidth weights absent when D=02020-06-27T14:09:35ZMike PerryBandwidth weights absent when D=0When the directory authorites vote that there are insufficient Exit nodes for them to be labled as both Exit and
Guard, the authorities fail to add a bandwidth-weights line in consensus method 9. This has two problems:
1. We could actu...When the directory authorites vote that there are insufficient Exit nodes for them to be labled as both Exit and
Guard, the authorities fail to add a bandwidth-weights line in consensus method 9. This has two problems:
1. We could actually create weights in may cases when this does happen.
2. This decision is made on the individual consensus *votes*, not the final consensus. There have been several
situations so far when the authorites voted not to have Guard+Exit even though there was sufficient exit bandwidth
in the consensus, and vice-versa.
The problem is that this check probably is a good idea to perform, because of the large numbers of existing clients that
we want to avoid using Exits-as-Guards with until they update to the new weighting system.
The correct solution should be to tweak the Guard flag such that it produces a fixed amount of Guard-flagged nodes in
the actual consensus. We should allow the weights themselves to handle what to do with Guard+Exit nodes.
However, because this is a mostly harmless result that just causes clients to revert to the old weights when it
happens, and because a bit of work and thought is needed to decide how to properly allocate the Guard flag, we're
not going to just do a quick fix and allow weights for the D=0 situation. We should fix this issue once we feel
that enough clients have upgraded to 0.2.2.x for it to make sense to fix it properly.
[Automatically added by flyspray2trac: Operating System: All]Mike PerryMike Perryhttps://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/27571Bandwidth values in top relays and relay view2020-06-27T14:25:52ZjugaBandwidth values in top relays and relay viewClicking on `Top Relays` [0] it says `Top Relays by Consensus Weight`
then the column that is shown is `Advertised Bandwidth`.
Is it actually top relays by advertised bandwidth?.
Would be easy to add a consensus weight column?
Is it t...Clicking on `Top Relays` [0] it says `Top Relays by Consensus Weight`
then the column that is shown is `Advertised Bandwidth`.
Is it actually top relays by advertised bandwidth?.
Would be easy to add a consensus weight column?
Is it total number shown down left regarding the relays displayed or the total regarding the query?
In a relay view [1], consensus weight does not have units, but dir-spec says it's in KB [2]. Would be useful to add the unit there?.
Is it took into account that consensus weight values are published in KB (not KiB, not B)?
[0] https://metrics.torproject.org/rs.html#toprelays
[1] https://metrics.torproject.org/rs.html#details/BC630CBBB518BE7E9F4E09712AB0269E9DC7D626
[2] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2337https://gitlab.torproject.org/tpo/core/dirauth/-/issues/30533Bandwidth Unmeasured in Testing Tor Network2020-06-27T14:11:26ZTracBandwidth Unmeasured in Testing Tor NetworkI have run the Testing Tor Network based on docker, however, the bandwidth of relays in consensus is 0, and they are labeled as unmeasured.
like
```
r tor21 AXeRGqg59zZ0JOyocxlonwk84Qg zv7cbbO1TcuYfwhzA/VjeE/u9UY 2019-05-18 15:49:03 172...I have run the Testing Tor Network based on docker, however, the bandwidth of relays in consensus is 0, and they are labeled as unmeasured.
like
```
r tor21 AXeRGqg59zZ0JOyocxlonwk84Qg zv7cbbO1TcuYfwhzA/VjeE/u9UY 2019-05-18 15:49:03 172.25.0.121 5000 0
s Exit Fast Running V2Dir Valid
v Tor 0.3.5.7
pr Cons=1-2 Desc=1-2 DirCache=1-2 HSDir=1-2 HSIntro=3-4 HSRend=1-2 Link=1-5 LinkAuth=1,3 Microdesc=1-2 Relay=1-2
w Bandwidth=0 Unmeasured=1 (The bandwidth is labeled as unmeasured)
p reject 25,119,135-139,445,563,1214,4661-4666,6346-6429,6699,6881-6999
```
The torrc file of my authority server is listed as following:
```
Log info file /root/log/info.log
DisableDebuggerAttachment 0
SocksPort 0
OrPort 5000
Address 172.25.0.10
DirPort 7000
AuthoritativeDirectory 1
V3AuthoritativeDirectory 1
ContactInfo auth@test.test
ExitPolicy reject *:*
ServerDNSAllowBrokenConfig 1
DirAllowPrivateAddresses 1
EnforceDistinctSubnets 0
AssumeReachable 1
AuthDirMaxServersPerAddr 0
AuthDirMaxServersPerAuthAddr 0
ClientDNSRejectInternalAddresses 0
ClientRejectInternalAddresses 0
CountPrivateBandwidth 1
ExitPolicyRejectPrivate 0
ExtendAllowPrivateAddresses 1
V3AuthVotingInterval 5 minutes
V3AuthVoteDelay 20 seconds
V3AuthDistDelay 20 seconds
MinUptimeHidServDirectoryV2 0 seconds
TestingV3AuthInitialVotingInterval 5 minutes
TestingV3AuthInitialVoteDelay 20 seconds
TestingV3AuthInitialDistDelay 20 seconds
TestingAuthDirTimeToLearnReachability 0 minutes
TestingEstimatedDescriptorPropagationTime 0 minutes
TestingClientMaxIntervalWithoutRequest 5 seconds
TestingDirConnectionMaxStall 30 seconds
TestingEnableConnBwEvent 1
TestingEnableCellStatsEvent 1
```
The version of tor is 0.3.3.8
**Trac**:
**Username**: TBD.Chenhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19009bandwidth testing circuits should be allowed to use our guards2022-06-22T15:21:09ZRoger Dingledinebandwidth testing circuits should be allowed to use our guardsIn git commit 267e61d0, we fixed bug legacy/trac#654, where relays were putting all their bandwidth testing circuits over the same small set of guards, thus having an accidental bottleneck, meaning we got an inaccurate bandwidth estimate...In git commit 267e61d0, we fixed bug legacy/trac#654, where relays were putting all their bandwidth testing circuits over the same small set of guards, thus having an accidental bottleneck, meaning we got an inaccurate bandwidth estimate.
But we fixed it by having them *never* use a guard for their first hop of a testing circuit, which in turn produced surprising behavior in tiny test networks, because relays can't make testing circuits if all the available relays are in their guard list.
teor fixed that in commit 22a1e9cac by making us not avoid our guards if testingtornetwork, and not avoid our guards if all the nodes in the consensus are on our guard list. It turns out that latter check isn't quite good enough, because we're picking two hops, so having at least one relay in the network that isn't in our guard list isn't enough to complete a circuit.
The underlying problem is that when UseEntryGuards is true, the rest of choose_good_entry_server() is entirely about picking a new entry guard. Except we reuse it for some edge cases where we want to just pick some entry point and not use our guard list. Some refactoring or something seems wise.https://gitlab.torproject.org/tpo/core/tor/-/issues/23512Bandwidth stats info leak upon close of circuits with queued cells2020-06-27T13:55:38ZGeorge KadianakisBandwidth stats info leak upon close of circuits with queued cellsWe received a tor bug bounty report from `jaym` about a congestion attack variant that can cause bandwidth stats watermark.
The bug uses the fact that Tor increments the _read bytes counter_ before adding the cell to the output buffer:...We received a tor bug bounty report from `jaym` about a congestion attack variant that can cause bandwidth stats watermark.
The bug uses the fact that Tor increments the _read bytes counter_ before adding the cell to the output buffer: If the circuit gets killed before the cell gets relayed to the next hop, then the _write bytes counter_ will never be updated, making the _read bytes counter_ having a higher value than the _write bytes counter_. The attacker could exploit this assymetry to find relays using their bandwidth graph.
The attacker can kill the circuit using the OOM killer by saturating its output queue with cells until `circuits_handle_oom()` gets called and kills the circuit.
We should figure out whether this attack is practical (the paper claims it is) and whether it's worthwhile fixing it. Just fixing this issue won't solve the general issue of congestion attacks, and it might even allow other kinds of attacks.
The most practical fix right now seem to be to hack circuit_handle_oom()` to actually decrement the read counters before killing a circuit. However, that's a very specific fix that might solve this very specific bug, but leave the rest of the bug class open.
Another approach would be removing the bandwidth graphs, or aggregating them over a greater period of time, or adding noise. We should consider these approaches carefully since bandwidth graphs see great use by academic papers and also by relay operators (to gauge their contribution).Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40161Bandwidth scanners don't measure >1 Gbps per IP2023-09-28T15:39:05ZNeel Chauhanneel@neelc.orgBandwidth scanners don't measure >1 Gbps per IPThis isn't my usual "sbws is slow" issue, but with the new 8 relays per IP, I found one possible bottleneck: the fact that an IPv4 can't measure more than 1 Gbps.
This happens on my **opsrelay** family relays: https://metrics.torproject...This isn't my usual "sbws is slow" issue, but with the new 8 relays per IP, I found one possible bottleneck: the fact that an IPv4 can't measure more than 1 Gbps.
This happens on my **opsrelay** family relays: https://metrics.torproject.org/rs.html#search/family:E1E99C9C48054C988A124BE5678A45F883FC8E72
Most of these these relays are hosted on a 2 Gbps OVH VPS (since I had to leave ReliableSite, avoid them, even pay the AWS tax instead), each VPS has 8 exit relays, all 8 which only measure 1 Gbps combined. The only exception is my **NeelTorRelay** middle relays which are hosted on a CenturyLink Gigabit connection with 4 middle relays.
I can understand why you measure all relays on one IP at once (assuming you do): to see the server's capacity when fully loaded. But since we allow 8 relays per IP, many IPs can give >1 Gbps relay capacity. I have 2 Gbps bandwidth per OVH IP but each only measure up to 1 Gbps.
Other people may be affected as well: people with 10 Gigabit servers but not a lot of IPv4, and multi-Gigabit XGS-PON fiber ISPs.
**I believe this isn't an issue with sbws, but rather the servers hosting sbws.**
We *need* to upgrade the scanners to 10 Gbps ports when we can. It's more expensive, but necessary. You don't need 10 Gbps upfront, but we can start at 2 Gbps and slowly ramp up the bandwidth, or use 95th Percentile ports and only "commit" to 1 Gbps to avoid overpaying for capacity we don't have
We could also measure each relay individually, but this has the issue of overstating capacity and ruining user experience if a relay is congested.https://gitlab.torproject.org/tpo/network-health/metrics/consensus-health/-/issues/22108Bandwidth scanner page chooses yellow for moria12020-06-27T14:23:09ZteorBandwidth scanner page chooses yellow for moria1When I go to the graph:
https://consensus-health.torproject.org/graphs.html#bwauthgraphs
I see a light yellow as the colour for moria1.
That makes it hard to see.
Can you make it a more visible colour?
Can we do something to identify t...When I go to the graph:
https://consensus-health.torproject.org/graphs.html#bwauthgraphs
I see a light yellow as the colour for moria1.
That makes it hard to see.
Can you make it a more visible colour?
Can we do something to identify the lines for colour-blind people?Tom Rittertom@ritter.vgTom Rittertom@ritter.vg