Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:36:12Zhttps://gitlab.torproject.org/legacy/trac/-/issues/11966"Bootstrapped 20%: Asking for networkstatus consensus" is a lie for bridge users2020-06-13T14:36:12ZRoger Dingledine"Bootstrapped 20%: Asking for networkstatus consensus" is a lie for bridge usersWhen a Tor client that's configured to use a bridge sees
```
[notice] Bootstrapped 20%: Asking for networkstatus consensus
```
its next plan is actually to send a DIR_PURPOSE_FETCH_SERVERDESC request for the bridge's descriptor. This is ...When a Tor client that's configured to use a bridge sees
```
[notice] Bootstrapped 20%: Asking for networkstatus consensus
```
its next plan is actually to send a DIR_PURPOSE_FETCH_SERVERDESC request for the bridge's descriptor. This is surprising.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/16824Emit a warning message about side channel leaks when using relays as clients2020-06-13T14:48:14ZstarlightEmit a warning message about side channel leaks when using relays as clientsAnalysis presented in bug #16585 demonstrates client circuit formation processing perturbs relay cell forwarding in a manner that may be susceptible to traffic confirmation analysis.
With the present code structure it is recommended tha...Analysis presented in bug #16585 demonstrates client circuit formation processing perturbs relay cell forwarding in a manner that may be susceptible to traffic confirmation analysis.
With the present code structure it is recommended that simultaneous client and relay operation be aggressively discouraged with a new `torrc` configuration parameter to inhibit it--default value set to prevent. In addition log warnings should be generated when both client and relay functions are allowed to operate concurrently.
Correct support of simultaneous client and relay function requires segregation of the client function to a separate thread running on a different processor core than the relay function.
Correcting the current client implementation's deficit of transaction granularity is unlikely to eliminate the potential for a sophisticated advisory to detect perturbation of cell forwarding by client circuit creation activity.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/17520Relax the rend cache failure cleanup timer2020-06-13T14:50:45ZDavid Gouletdgoulet@torproject.orgRelax the rend cache failure cleanup timer`rend_cache_failure_clean()` is called every second and the reason is that we want to make the client wait as little as possible so we try our best to cleanup the failure cache.
This is not ideal CPU wise since the cache could technical...`rend_cache_failure_clean()` is called every second and the reason is that we want to make the client wait as little as possible so we try our best to cleanup the failure cache.
This is not ideal CPU wise since the cache could technically grow to the number of possible introduction point in the network thus making it a larger loop every second.
Let's relax the cleanup timer here to 5 minutes (expiry time of an entry) and at each lookup, if the entry did expire, clean it and return that "we do not have an entry". This will not address the size of the cache that can grows but that's fine since we can handle that in the OOM. Also, a cache that has the maximum number of entries is a valid use case.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/17949Make loopback address search more accurate2020-06-13T14:53:04ZteorMake loopback address search more accurate#17901 and #11360 search local interfaces for loopback addresses.
We could make this more efficient by using the flags returned with each address:
* getifaddrs returns struct ifaddrs with ifa_flags which has IFF_LOOPBACK
* ioctl(.,SIOCG...#17901 and #11360 search local interfaces for loopback addresses.
We could make this more efficient by using the flags returned with each address:
* getifaddrs returns struct ifaddrs with ifa_flags which has IFF_LOOPBACK
* ioctl(.,SIOCGIFCONF,.) returns struct ifreq with ifr_flags which has IFF_LOOPBACK
* GetAdaptersAddresses (Win32) returns IP_ADAPTER_ADDRESSES with IfType which has IF_TYPE_SOFTWARE_LOOPBACK
* Also pass GAA_FLAG_SKIP_FRIENDLY_NAME as we never use it
* tor_getsockname/get_interface_address6_via_udp_socket_hack connects to a public address. When passed the localhost flag, it could connect to a loopback address, but this seems rather tautologous, and it's hard to know which loopback address to pick in 127/8. Alternately, we could lookup localhost using the resolver, and check the returned address is 127/8 or ::1 (otherwise, broken DNS configs could lead to security issues).
A design for this could be:
* pass a flag to get_interface_address* indicating whether we want loopback addresses
* pass that flag down to get_interface_addresses_raw
* pass that flag to the API-specific functions
* when converting the address to a smartlist, include/exclude addresses matching the specified types
* always exclude tor_addr_is_null()
* always exclude addresses matching tor_addr_is_multicast
* for extra points, create a flags argument for:
* loopback
* this will require disabling the checks for tor_addr_is_loopback() in get_interface_address6_list() and get_interface_address6_via_udp_socket_hack(), see #17901
* listen any (0.0.0.0 and [::], needs `tor_addr_is_listen_any()`)
* link-local (needs `tor_addr_is_link_local()`)
* other internal/private
* public
* with #defines:
* _INTERNAL: everything except public
* _INTERNAL_FOR_LISTENING: everything except public and listen any
After doing this, refactor the changes in #17901 and #11360, and all existing code, to use the new flags argument.
This will also resolve issues where systems have addresses other than 127.0.0.0/8 or ::1 as the loopback address (like some BSD jails and OpenVZ). But we're not too worried about this, they're non-standards-compliant, so the operator can configure the exact address correctly, as long as we fail with an informative message.
I need this to do #17835, I'll likely do it then if no-one gets to it first.Tor: unspecifiedrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/24000circuit_send_intermediate_onion_skin() and extend_cell_format() should check ...2020-06-13T15:16:19Zteorcircuit_send_intermediate_onion_skin() and extend_cell_format() should check for IPv6When circuit_send_intermediate_onion_skin() and extend_cell_format() handle tor_addr_t, they assume they are IPv4.
But in #23502, we almost wrote code that sent them an IPv6 address. In this case, they put 0.0.0.0 in the extend cell, bu...When circuit_send_intermediate_onion_skin() and extend_cell_format() handle tor_addr_t, they assume they are IPv4.
But in #23502, we almost wrote code that sent them an IPv6 address. In this case, they put 0.0.0.0 in the extend cell, but they could issue a BUG() warning and refuse to send the cell instead.
Or they could send a proper IPv6 link specifier where the extend cell allows it.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24300Failed to find node for hop #1 of our path. Discarding this circuit2020-06-13T15:17:28ZDavid Gouletdgoulet@torproject.orgFailed to find node for hop #1 of our path. Discarding this circuitBeen two days in a row with git master (033-alpha), when I boot up my computer and tor starts and fails to bootstrap. It takes around 8 minutes before it finally work.
The particularity I have with my tor client is that I pin my `EntryN...Been two days in a row with git master (033-alpha), when I boot up my computer and tor starts and fails to bootstrap. It takes around 8 minutes before it finally work.
The particularity I have with my tor client is that I pin my `EntryNodes` with one specific Guard for testing purposes and I stumbled on this issue.
Attached to the ticket are the info logs from the start of tor up to the 100% bootstrap.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24732Remove unused IPv6 DirPort code2020-06-13T15:19:26ZteorRemove unused IPv6 DirPort codeIPv6 DirPorts aren't used by Tor: clients use IPv4/IPv6 ORPorts, and relays use IPv4 DirPorts (and IPv4 ORPorts).
There is code that implements this algorithm in commit 36ba50c820 of my bug23975_tree branch.IPv6 DirPorts aren't used by Tor: clients use IPv4/IPv6 ORPorts, and relays use IPv4 DirPorts (and IPv4 ORPorts).
There is code that implements this algorithm in commit 36ba50c820 of my bug23975_tree branch.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25372relay: Allocation for compression goes very high2020-06-13T15:22:27ZDavid Gouletdgoulet@torproject.orgrelay: Allocation for compression goes very highMy relay just OOMed some circuits with filled up queue (#25226) but then a useful log was printed showing that the compress total allocation is huge.
```
Feb 27 20:02:55.718 [notice] We're low on memory (cell queues total alloc: 2322798...My relay just OOMed some circuits with filled up queue (#25226) but then a useful log was printed showing that the compress total allocation is huge.
```
Feb 27 20:02:55.718 [notice] We're low on memory (cell queues total alloc: 232279872 buffer total alloc: 1937408, tor compress total alloc: 878586075 rendezvous cache total alloc: 4684497). Killing circuits withover-long queues. (This behavior is controlled by MaxMemInQueues.)
```
That `878586075 = ~838MB`. My relay is hovering around 1.4GB of RAM right now which means ~60% of the RAM used is in the compression subsystem.
I'm not sure where it all comes, the relay is serving directory data but I have my doubt that *compressed*, it comes down to 800+ MB...
Datapoint:
```
$ du -sh diff-cache/
131M diff-cache/
```Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25713"DisableNetwork is set" log message in Tor Browser scares/confuses users2020-06-13T15:24:08ZRoger Dingledine"DisableNetwork is set" log message in Tor Browser scares/confuses usersWhen Tor Browser has trouble connecting, we tell users to go look at the logs. The first thing they see in their logs is something like
```
13/06/2017 11:31:29.600 [NOTICE] DisableNetwork is set. Tor will not make
or accept non-c...When Tor Browser has trouble connecting, we tell users to go look at the logs. The first thing they see in their logs is something like
```
13/06/2017 11:31:29.600 [NOTICE] DisableNetwork is set. Tor will not make
or accept non-control network connections. Shutting down all existing
connections.
```
and if they're hunting for a log message that gives them a hint about why Tor doesn't work, that one is easy to find and seems really related to why their tor might not work.
So we have this recurring event where users come to us and say "My Tor Browser isn't working, it says DisableNetwork is set."
Now, Tor Browser legitimately starts Tor with DisableNetwork set, so Tor Browser will have time to ask the user whether they want to use bridges or proxies or etc before their Tor starts interacting with the network. So "well stop using that option then" is hopefully not our best plan.
But I wonder if there is a smarter way to have that phrased in the logs, so users have a better chance of guessing correctly what is going on.
(Long term we want to not send Tor Browser users to go read Tor's logs. But we're not there yet either.)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25899Only run retry_dns() and check_dns_honesty() on exits2020-06-13T15:24:45ZNick MathewsonOnly run retry_dns() and check_dns_honesty() on exitsThese periodic callbacks can become exit-only, since only exits now need to use the dns.c module.These periodic callbacks can become exit-only, since only exits now need to use the dns.c module.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/18098prop224: Implement tor-genkey tool for offline HS key creation2020-06-13T15:25:05ZDavid Gouletdgoulet@torproject.orgprop224: Implement tor-genkey tool for offline HS key creationWith proposal 224, an operator can choose to keep her master key offline. Currently, tor as a `--keygen` option used for relay keys. Glueing HS key support _will_ be complicated (since it's already not that easy implementation wise).
I ...With proposal 224, an operator can choose to keep her master key offline. Currently, tor as a `--keygen` option used for relay keys. Glueing HS key support _will_ be complicated (since it's already not that easy implementation wise).
I propose we create a separate tool called `tor-genkey` (follows the tor-gencert naming) located in `src/tools` to create keys for different use case. We could ship this tool with our tor package or even as a separate package so people don't need to install the whole tor for just generating keys.
Furthermore, with prop224, an operator choosing to generate her key offline, we will need to create a bunch of blinded keys in advance with the offline master key which would make it much more easier than to glue yet another thing on top of tor cmdline.
Also, revocation of those keys could be a reality at some point in time which that tool could do really well without having a tons of new code in tor.Tor: unspecifiedhaxxpophaxxpophttps://gitlab.torproject.org/legacy/trac/-/issues/26316Windows newlines in extrainfo descriptor2020-06-13T15:26:30ZDamian JohnsonWindows newlines in extrainfo descriptorHi Network Team, the following extrainfo descriptor is making Stem's parser error with "Malformed dirreq-stats-end line: dirreq-stats-end 2018-06-05 06:11:40 (86400 s)"...
```
extra-info Jittor E062E8AD9FA8907D140ECFC406D5DAFD4B23F300
i...Hi Network Team, the following extrainfo descriptor is making Stem's parser error with "Malformed dirreq-stats-end line: dirreq-stats-end 2018-06-05 06:11:40 (86400 s)"...
```
extra-info Jittor E062E8AD9FA8907D140ECFC406D5DAFD4B23F300
identity-ed25519
-----BEGIN ED25519 CERT-----
AQQABnvMATGms3ONiqeM1KNjSmQQVTcmVFwb7pHjW6b4qB4DhqG/AQAgBACmvl+Y
QFLCTyOfsf9cL9qL7IDZLOceNdcTJSNGPzevmvgB827O9wO0IDxY4V10wDxHRiNG
TPy43S5ag5hWvyKzI3hGA/sz7+8NwnGEqFrjg9nlZt/FADvdC0Ow9owIHwU=
-----END ED25519 CERT-----
published 2018-06-05 12:27:03
geoip-db-digest 765D2F123DDA7DAEA9C9263975E2B4BAFBD2B908
geoip6-db-digest 2AA568CC898BF9924FBACEA26946AA7ED10E7D87
dirreq-stats-end 2018-06-05 06:11:40 (86400 s)^M
dirreq-v3-ips ru=488,us=400,de=264,ua=168,fr=160,gb=128,it=96,br=80,es=80,jp=80,ca=64,in=56,nl=56,pl=56,ar=32,au=32,tw=32,by=24,ch=24,cz=24,fi=24,id=24,ir=24,mx=24,ae=16,at=16,be=16,bg=16,gr=16,hk=16,hu=16,ie=16,il=16,lt=16,lv=16,my=16,no=16,pt=16,ro=16,rs=16,se=16,th=16,vn=16,??=8,ba=8,bd=8,bh=8,bj=8,ci=8,cl=8,cn=8,co=8,cr=8,cw=8,cy=8,dk=8,do=8,dz=8,ec=8,ee=8,et=8,ge=8,gh=8,gp=8,gt=8,gy=8,hr=8,iq=8,is=8,ke=8,kr=8,kw=8,kz=8,lk=8,lu=8,ma=8,md=8,me=8,mg=8,mu=8,mv=8,na=8,nz=8,pe=8,ph=8,pk=8,sd=8,sg=8,si=8,sk=8,sv=8,sy=8,tc=8,td=8,tn=8,tr=8,ug=8,uy=8,ve=8,za=8^M
dirreq-v3-reqs us=1464,ru=1048,de=752,fr=440,ua=280,gb=200,br=144,ca=136,it=136,jp=136,es=120,nl=120,pl=88,in=80,by=56,tw=56,au=48,ch=48,cz=48,id=48,md=48,se=48,ar=40,ir=40,ae=32,at=32,lt=32,mx=32,no=32,??=24,fi=24,hu=24,ie=24,il=24,lv=24,pt=24,ro=24,sg=24,vn=24,be=16,bg=16,cl=16,co=16,gr=16,hk=16,hr=16,is=16,kr=16,my=16,ph=16,rs=16,th=16,tr=16,ve=16,ba=8,bd=8,bh=8,bj=8,ci=8,cn=8,cr=8,cw=8,cy=8,dk=8,do=8,dz=8,ec=8,ee=8,et=8,ge=8,gh=8,gp=8,gt=8,gy=8,iq=8,ke=8,kw=8,kz=8,lk=8,lu=8,ma=8,me=8,mg=8,mu=8,mv=8,na=8,nz=8,pe=8,pk=8,sd=8,si=8,sk=8,sv=8,sy=8,tc=8,td=8,tn=8,ug=8,uy=8,za=8^M
dirreq-v3-resp ok=6200,not-enough-sigs=16,unavailable=0,not-found=0,not-modified=1120,busy=0^M
dirreq-v3-direct-dl complete=16,timeout=0,running=0,min=229451,d1=229451,d2=516011,q1=1012307,d3=1012307,d4=1059359,md=1587774,d6=2175000,d7=2758125,q3=3023437,d8=3023437,d9=3105875,max=3332493^M
dirreq-v3-tunneled-dl complete=6048,timeout=136,running=0,min=360,d1=147601,d2=281819,q1=344834,d3=417296,d4=547425,md=705125,d6=916070,d7=1265607,q3=1371936,d8=1660923,d9=2477000,max=41697000^M
hidserv-stats-end 2018-06-05 06:11:40 (86400 s)^M
hidserv-rend-relayed-cells 5973866 delta_f=2048 epsilon=0.30 bin_size=1024^M
hidserv-dir-onions-seen 262 delta_f=8 epsilon=0.30 bin_size=8^M
router-sig-ed25519 kZGzsa4k+78QHsyb/0FXWBJYxttV8KvVHV/LiMH1muGAk/f9fj9c+lYusnhK9sql+AB7r5b0j6uaNR7ZTCXLBw
router-signature
-----BEGIN SIGNATURE-----
WjdbB6hbV9cyHWMqglNNMfjuT+WUvOmqP+IvMgwCke5/cXXEHOzqVXsVFdXmEBsg
HQOjB4vlmK4n6diTc2O0LkUzZTk1XIQwZOyKjtFNi0OrQye6mJA9gKaCIQUF3CDZ
XL6dW0QQaXgURTlm3oApAsZ+vRzI/Wfq9YxjTCLc9u4=
-----END SIGNATURE-----
```
You can fetch this descriptor for yourself with...
```
curl http://154.35.175.225:80/tor/extra/fp/E062E8AD9FA8907D140ECFC406D5DAFD4B23F300
```
Note the "!^M" trailing a handful (but not all) of lines. Those are Windows carriage returns (\r\n line endings). There's two issues here, first that somehow this is getting published on metric lines and second that the dirauths aren't rejecting this descriptor.
According to its server descriptor this relay ([Jittor](https://metrics.torproject.org/rs.html#details/E062E8AD9FA8907D140ECFC406D5DAFD4B23F300)) is running Tor 0.3.3.6 on Linux.
That's right. Windows newlines on Linux. Pity we don't note the distro. :P
Thanks!Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26369Re-fetch onion service descriptor for isolated request2020-06-13T15:26:39ZMatthew FinkelRe-fetch onion service descriptor for isolated requestWhen tor receives a new request for connecting to an onion service and this request has different isolation flags/parameters than a previous (recent) request, then tor should re-fetch the service descriptor (if we already have it). Curre...When tor receives a new request for connecting to an onion service and this request has different isolation flags/parameters than a previous (recent) request, then tor should re-fetch the service descriptor (if we already have it). Currently, tor notices it already has the descriptor in its cache and it doesn't refetch. This is a nice performance optimization, but if a client is requesting an isolated circuit for an onion service, then we shouldn't leak that we already have the descriptor in our cache.
Instead of only using the onion service name as the map-key, we can add a unique value of the circuit isolation information (hash?).Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24546Use tor_addr_is_v4() rather than family, or reject all v6-mapped IPv4 addresses2020-06-13T15:26:54ZteorUse tor_addr_is_v4() rather than family, or reject all v6-mapped IPv4 addressesIn Tor, we try to support v6-mapped IPv4 addresses.
We should either:
* reject them unconditionally, or
* audit all uses of tor_addr_t.family to see if we should be calling tor_addr_is_v4() instead, and add a comment to the struct that s...In Tor, we try to support v6-mapped IPv4 addresses.
We should either:
* reject them unconditionally, or
* audit all uses of tor_addr_t.family to see if we should be calling tor_addr_is_v4() instead, and add a comment to the struct that says we should consider using tor_addr_is_v4() rather than comparing family.
If no relay in the consensus is currently using these addresses, then maybe we should just call them internal on authorities, relays, and clients, and remove all the code that tries to deal with them.
Discovered as part of #15518.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26478Unify bandwidth related terms in dir-spec and Tor code.2020-06-13T15:27:04ZjugaUnify bandwidth related terms in dir-spec and Tor code.Unifying these terms would make following what these bandwidth do in the code and the spec less confusing.
For instance:
- what is called `bandwidthrate` [0] in the code when building the descriptor, it is called `bandwidth-avg` in `dir-...Unifying these terms would make following what these bandwidth do in the code and the spec less confusing.
For instance:
- what is called `bandwidthrate` [0] in the code when building the descriptor, it is called `bandwidth-avg` in `dir-spec.txt` [1].
- what is called `bandwidthcapacity` [2] in the code, it is called `bandwidth-observed` in `dir-spec.txt`[1]
I don't know if it is prefered to modify terms in the spec or in the code.
It'd be also helpful to add formulae or more detailed descriptions on how the different bandwidth terms are generated in dir-spec.txt
[0] https://gitweb.torproject.org/tor.git/tree/src/or/router.c#n2370
[1] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n427
[2] https://gitweb.torproject.org/tor.git/tree/src/or/router.c#n2376Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26769We should make HSv3 desc upload less frequent2020-06-13T15:29:32ZGeorge KadianakisWe should make HSv3 desc upload less frequentWithout checking the source code right now, HSDirs are supposed to cache HS descriptors for the inscribed lifetime (3 hours), and HSv3s are supposed to upload descriptors at a random time between 1 and 2 hours (see `HS_SERVICE_NEXT_UPLOA...Without checking the source code right now, HSDirs are supposed to cache HS descriptors for the inscribed lifetime (3 hours), and HSv3s are supposed to upload descriptors at a random time between 1 and 2 hours (see `HS_SERVICE_NEXT_UPLOAD_TIME_MIN`).
This makes HSv3s upload descriptors more frequently than needed. For example, we could increase this to upload descriptors between 2 and 2.9 hours, to make HSv3s less intense on the network.
Someone should double check the above logic and make sure it won't cause issues, and implement it.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27201rust/protover doesn't forbid version zero2020-06-13T15:29:39ZTracrust/protover doesn't forbid version zeroPer the spec, version integers can't begin with, or be, zero:
```
Int = NON_ZERO_DIGIT
Int = Int DIGIT
```
**Trac**:
**Username**: cyberpunksPer the spec, version integers can't begin with, or be, zero:
```
Int = NON_ZERO_DIGIT
Int = Int DIGIT
```
**Trac**:
**Username**: cyberpunksTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27284Check IPv6 exit policies on microdescs2020-06-13T15:30:01ZteorCheck IPv6 exit policies on microdescsIn node_exit_policy_rejects_all(), we check IPv4 and IPv6 policies on ri, but on md we only check IPv4:
```
else if (node->md)
return node->md->exit_policy == NULL ||
short_policy_is_reject_star(node->md->exit_policy);
```
O...In node_exit_policy_rejects_all(), we check IPv4 and IPv6 policies on ri, but on md we only check IPv4:
```
else if (node->md)
return node->md->exit_policy == NULL ||
short_policy_is_reject_star(node->md->exit_policy);
```
One way to fix this issue is to refactor the existing code to check a new policy_is_reject_star, and then populate policy_is_reject_star when the md is parsed. (Like we already do with the ri.)Tor: 0.4.2.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/27308report bootstrap phase when we actually start, not just unblock something2020-06-13T15:30:07ZTaylor Yureport bootstrap phase when we actually start, not just unblock somethingRight now many bootstrap events get reported when the preceding task has completed. This makes it somewhat harder to tell what has gone wrong if bootstrap progress stalls.
[edit: The following isn't necessarily the best way to fix this...Right now many bootstrap events get reported when the preceding task has completed. This makes it somewhat harder to tell what has gone wrong if bootstrap progress stalls.
[edit: The following isn't necessarily the best way to fix this. It might be better to figure out how to report starting something when actually starting it.]
We should add completion milestones to bootstrap reporting. This makes bootstrap reporting more future-proof. If in the future we add a time-consuming task with (no bootstrap reporting) between two existing bootstrap tasks, it will be a little more obvious what's going on.
For example, say we have task X followed by task Z, but then we add a lengthy task Y without adding bootstrap reporting to it. In the old scheme without completion milestones, if Y stalls, the user sees:
* starting X
* starting Z
* [hang]
The user thinks Z has already started when no such thing has happened because Y is still in progress. If we add completion milestones, the user will see:
* starting X
* finished X
* starting Z
* finishing Z
in a normal bootstrap. If something gets stuck in task Y, the user will see:
* starting X
* finished X
* [hang]
This will make it more clear that something got stuck in between tasks.
In a one-line display like Tor Launcher, the completion milestones will normally flash by quickly and not be very visible to users. Completion milestones might make the NOTICE logs a bit more verbose.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27662refactor networkstatus_parse_vote_from_string()2020-06-13T15:31:13ZTracrefactor networkstatus_parse_vote_from_string()As of [1c62adb65baa99c92f937318c452955306301643](https://gitweb.torproject.org/tor.git/tree/src/feature/nodelist/routerparse.c?id=1c62adb65baa99c92f937318c452955306301643#n3395), the function is 628 lines long. It could be split into cal...As of [1c62adb65baa99c92f937318c452955306301643](https://gitweb.torproject.org/tor.git/tree/src/feature/nodelist/routerparse.c?id=1c62adb65baa99c92f937318c452955306301643#n3395), the function is 628 lines long. It could be split into calling 3 helper functions instead.
**Trac**:
**Username**: cyberpunksTor: unspecified