Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:01:38Zhttps://gitlab.torproject.org/legacy/trac/-/issues/961TotalTraffic option (upload+download)2020-06-13T14:01:38ZTracTotalTraffic option (upload+download)Could a TotalTraffic option similar to AccountingMax be added?
I know, it isn't to hard to divide by two, but you usually need
to limit the sum of upload and download to not exceed your
traffic limit.
Maybe the description of Accounting...Could a TotalTraffic option similar to AccountingMax be added?
I know, it isn't to hard to divide by two, but you usually need
to limit the sum of upload and download to not exceed your
traffic limit.
Maybe the description of AccountingMax should also be changed to
make it clear, if one, either upstream traffic or downstream
traffic exceeds the limit Tor will hibernate.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: AthabaTor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/4243rend_consider_services_upload waits up to 4 hours to publish the first HS des...2020-06-13T14:37:10ZRobert Ransomrend_consider_services_upload waits up to 4 hours to publish the first HS descriptor by defaultFrom the documentation comment on `rend_consider_services_upload` (in src/or/rendservice.c):
```
* For the first upload, pick a random time between now and two periods
* from now, and pick it independently for each service.
```
“first...From the documentation comment on `rend_consider_services_upload` (in src/or/rendservice.c):
```
* For the first upload, pick a random time between now and two periods
* from now, and pick it independently for each service.
```
“first upload” means the first HS descriptor upload after the service is configured in the Tor instance (i.e. when Tor is started); the ‘period’ referred to there is that specified in the `RendPostPeriod` configuration option (default 2 hours).
Users have complained that HSes don't work for a while after they are set up. Now we know why they don't work for a while.
Should this be changed? I assume this huge delay was intended to (a) conceal associations between different hidden services run on the same Tor client, and (b) try a little bit to conceal associations between hidden services run on a relay and the relay's uptime. Do users really gain any privacy/security/whatever from this delay? If so, how much?
If this shouldn't be changed, we need an FAQ entry about this somewhere.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/4244Tor changes default value of DirReqStatistics, then wants to SAVECONF the new...2020-06-13T15:05:15ZRobert RansomTor changes default value of DirReqStatistics, then wants to SAVECONF the new default#4237 was caused by [ticket:4237#comment:2 an underlying Tor bug].
We should fix it, and someday we should redesign the configuration-handling code to make this class of bugs go away.#4237 was caused by [ticket:4237#comment:2 an underlying Tor bug].
We should fix it, and someday we should redesign the configuration-handling code to make this class of bugs go away.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/4436Bridges should be able to disable v1 and v2 link handshakes2020-06-13T14:14:32ZGeorge KadianakisBridges should be able to disable v1 and v2 link handshakesThere is no point in implementing scanning resistance and all that fancy stuff, if censors can make a bridge perform the fingerprintable v1/v2 link handshakes by adding a few ciphers to ClientHello, or renegotiating right after TLS.
The...There is no point in implementing scanning resistance and all that fancy stuff, if censors can make a bridge perform the fingerprintable v1/v2 link handshakes by adding a few ciphers to ClientHello, or renegotiating right after TLS.
There should be a way to disable v1 and v2 link handshakes before we implement scanning resistance stuff.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/5583Add option to overwrite logs2020-06-13T14:18:54ZbastikAdd option to overwrite logsAdd an option to make Tor overwrite logs, instead of appending them.
For instance whenever Tor gets restarted and this option is enabled the log does not get appended.*
This should enable operators to log without the risk of month old ...Add an option to make Tor overwrite logs, instead of appending them.
For instance whenever Tor gets restarted and this option is enabled the log does not get appended.*
This should enable operators to log without the risk of month old logs. Even when not enabled by default, what I was looking for in the first place, as I had not understood why logs are appending, it might help to have this option available.
The same applies to the client, once I was asked to provide logs from my client, and got told afterwards to remove the logging entry from torrc. When that does not happen, the client is logging for eternity and therefor provides an usage history due to the fact that the log is appending.
I couldn't pick "Tor" for "Component"; for me it's client and relay related.
*Other ways like, logging for a 24 hour period, keep this period and delete the lines that are older, might bring more problems than it's worth.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6031Distinguish when a Tor HS is "not found" vs "not reachable" (exists / does no...2020-06-13T14:20:12ZnaifDistinguish when a Tor HS is "not found" vs "not reachable" (exists / does not exists)Tor2web software (but also on other software) need to provide a different response depending if a Tor Hidden Service that a user is trying to access exists or not.
The error handling revealed that today there's no specific return code t...Tor2web software (but also on other software) need to provide a different response depending if a Tor Hidden Service that a user is trying to access exists or not.
The error handling revealed that today there's no specific return code to distinguish between:
- TorHS does not exists
- TorHS exists (and then it maybe reachable or not)
So in order to mimic the error-response typical of internet environment:
- Host not found (TorHS does not exists)
- Host unreachable (Tor HS exists but is not reachable)
After a discussion on IRC with Nick and sebastian the following conclusion arised:
nickm: so, this concept of ==== "We can have "exists" mean "This HS has been running recently, and has been attempting to provide service", though and implement that by saying that an HS "exists" if we find a descriptor for it, and doesn't exist if we don't. ==== is already "available" os must be implemented?
nickm
naif: I don't think that's exposed from Tor right now.
This ticket is to provide an implementation for that feature.
Whenever possible we should use a Return Code from Socks Server following SOCKS protocol so that a Socks Client can parse the result and know that connection to this TorHS is "Not Found".Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6088Gather data about possible transition to 2048bit RSA/DHE2020-06-13T14:40:17ZJacob AppelbaumGather data about possible transition to 2048bit RSA/DHEI propose that while prop 198 and others cover some crypto changes we need to make - I think they won't be made quickly enough. I think that we should jump to 2048bit rsa and 2048bit DHE as soon as possible. We should do this before 0.2....I propose that while prop 198 and others cover some crypto changes we need to make - I think they won't be made quickly enough. I think that we should jump to 2048bit rsa and 2048bit DHE as soon as possible. We should do this before 0.2.4.x (which nick says will enable TLS-ECDHE by default) as we have a long way before 0.2.4.x is even remotely available.
The first thing is that nick says:
<nickm> I want to know performance impact and fingerprintability.
This ticket should gather data on performance (RSA/DHE/etc) for servers and on the issue of fingerprintability (mitm filter/block/etc) where people use 2048bit DHE.
I've put this as a 02.3.x-final Milestone but it's likely this will change.Tor: 0.2.6.x-finalJacob AppelbaumJacob Appelbaumhttps://gitlab.torproject.org/legacy/trac/-/issues/6456Merge parse_client_transport_line() and parse_server_transport_line()2020-06-13T14:21:26ZGeorge KadianakisMerge parse_client_transport_line() and parse_server_transport_line()There is too much code duplication between `parse_client_transport_line()` and `parse_server_transport_line`. We should probably merge them into one function during 0.2.4.x.There is too much code duplication between `parse_client_transport_line()` and `parse_server_transport_line`. We should probably merge them into one function during 0.2.4.x.Tor: 0.2.6.x-finalAndrea ShepardAndrea Shepardhttps://gitlab.torproject.org/legacy/trac/-/issues/6852bridges (especially unpublished ones) should include usage info in their hear...2020-06-13T14:22:49ZRoger Dingledinebridges (especially unpublished ones) should include usage info in their heartbeatsAs part of SponsorJ task 2, we're running some fast unpublished bridges. Since they're unpublished, we have no way to learn how much usage they see. We should at least log them so the operators can send us the log snippets over time.
As...As part of SponsorJ task 2, we're running some fast unpublished bridges. Since they're unpublished, we have no way to learn how much usage they see. We should at least log them so the operators can send us the log snippets over time.
As a side benefit, logging will help the bridge operators who don't use Vidalia/arm and wonder whether their bridge is being helpful.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6938Log early log messages to log files2020-06-13T14:23:05ZshamrockLog early log messages to log filesIssue:
When configuring Tor as a bridge and to advertise a DirPort, the resulting warning is displayed on the console, but is not logged to the Tor log file.
Environment:
Debian squeeze amd64, latest patches
Tor version 0.2.4.2-alpha (g...Issue:
When configuring Tor as a bridge and to advertise a DirPort, the resulting warning is displayed on the console, but is not logged to the Tor log file.
Environment:
Debian squeeze amd64, latest patches
Tor version 0.2.4.2-alpha (git-0537dc6364594474)
How to reproduce:
Set "BridgeRelay 1"
Set "DirPort 80"
Start Tor.
The following warning will be displayed on the console:
"Starting tor daemon...<date will be here> [warn] Can't set a DirPort on a bridge relay; disabling DirPort
done."
No corresponding warning is logged to the Tor log file.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/7356Make channel state test macros2020-06-13T14:24:43ZAndrea ShepardMake channel state test macrosWe check for conditions like if (!(circ->n_chan->state == CHANNEL_STATE_CLOSING || circ->n_chan->state == CHANNEL_STATE_CLOSED || circ->n_chan->state == CHANNEL_STATE_ERROR)) a lot; there should be more concise test macros.We check for conditions like if (!(circ->n_chan->state == CHANNEL_STATE_CLOSING || circ->n_chan->state == CHANNEL_STATE_CLOSED || circ->n_chan->state == CHANNEL_STATE_ERROR)) a lot; there should be more concise test macros.Tor: 0.2.6.x-finalrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/7484We allow */bits as an address-and-mask pattern2020-06-13T14:34:53ZNick MathewsonWe allow */bits as an address-and-mask patternWhen parsing bitmasks for policies, we allow a number of bits along with the "*" catch-all address. That's not what our specs say we allow, and it doesn't make any sense. We should treat it as a bad address-and-mask.
(If anybody is us...When parsing bitmasks for policies, we allow a number of bits along with the "*" catch-all address. That's not what our specs say we allow, and it doesn't make any sense. We should treat it as a bad address-and-mask.
(If anybody is using this now, we might need to deprecate it instead of disabling it, but I don't think anyone is.)Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/7555MapAddress from FQDN to .onion fails because resolve requests for hidden ser...2020-06-13T14:25:13ZAaron GibsonMapAddress from FQDN to .onion fails because resolve requests for hidden services are not allowed.Example torrc:
MapAddress irc.oftc.net 37lnq2veifl4kar7.onion
(Why would I want to do that? So that the host my IRC client connects to matches the SSL certificate presented by the server)
Here's what a connection to a hidden service w...Example torrc:
MapAddress irc.oftc.net 37lnq2veifl4kar7.onion
(Why would I want to do that? So that the host my IRC client connects to matches the SSL certificate presented by the server)
Here's what a connection to a hidden service without a MapAddress looks like.
```
Nov 22 13:41:54.000 [debug] connection_ap_handshake_rewrite_and_attach(): Client asked for [scrubbed]:7000
Nov 22 13:41:54.000 [info] connection_ap_handshake_rewrite_and_attach(): Got a hidden service request for ID '[scrubbed]'
Nov 22 13:41:54.000 [info] connection_ap_handshake_rewrite_and_attach(): Unknown descriptor [scrubbed]. Fetching.
Nov 22 13:41:54.000 [debug] rend_client_refetch_v2_renddesc(): Fetching v2 rendezvous descriptor for service [scrubbed]
```
And here's what happens with the above MapAddress:
```
Nov 22 13:53:52.000 [debug] connection_ap_handshake_rewrite_and_attach(): Client asked for [scrubbed]:0
Nov 22 13:53:52.000 [info] addressmap_rewrite(): Addressmap: rewriting [scrubbed] to [scrubbed]
Nov 22 13:53:52.000 [warn] Resolve requests to hidden services not allowed. Failing.
```
So it looks like the socks client tries to resolve www.duckduckgo.com, the address gets rewritten to 3g2upl4pq6kufc4m.onion, and then the request fails because resolving .onion doesn't make sense. Where do resolve requests for .onion normally get handled? I think I'd probably want to catch this MapAddress case in addressmap_rewrite and then proceed as usual for hidden services.
Thanks for any pointers!Tor: 0.2.6.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/7733Two channels required for bootstrap2020-06-13T14:25:39ZDavid Fifielddcf@torproject.orgTwo channels required for bootstrapI noticed a change in behavior in `cb62a0b69a7d67b427224ca4c3075b49853a3a1f` or thereabouts. tor opens a new SOCKS connection to a client transport plugin while bootstrapping at 50% (if descriptors are not cached) or at 85% (if descripto...I noticed a change in behavior in `cb62a0b69a7d67b427224ca4c3075b49853a3a1f` or thereabouts. tor opens a new SOCKS connection to a client transport plugin while bootstrapping at 50% (if descriptors are not cached) or at 85% (if descriptors are not cached). The upshot is that the flash proxy transport, for which new connections are not free, needs two connected browser proxies in order to bootstrap. Earlier revisions permit bootstrapping and circuit creation with just one connection to the proxy.
I start an external proxy thus:
```
$ ./flashproxy-client --external --unsafe-logging
2012-12-03 09:02:05 Listening remote on 0.0.0.0:9000.
2012-12-03 09:02:05 Listening remote on [::]:9000.
2012-12-03 09:02:05 Listening local on 127.0.0.1:9001.
2012-12-03 09:02:05 Listening local on [::1]:9001.
```
The "remote" listener is waiting for WebSocket connections from a
browser. The "local" listener is waiting for SOCKS connections from Tor.
Then I start Tor to use the proxy:
```
$ ./src/or/tor ClientTransportPlugin "websocket socks4 127.0.0.1:9001" UseBridges 1 Bridge "websocket 0.0.1.0:1" LearnCircuitBuildTimeout 0 CircuitBuildTimeout 60 Log "info stderr"
...
Dec 03 09:02:13.000 [notice] Bootstrapped 10%: Finishing handshake with directory server.
```
`flashproxy-client` notices Tor's pending SOCKS connection:
```
2012-12-03 09:02:13 Local connection from 127.0.0.1:55421.
2012-12-03 09:02:13 SOCKS request from 127.0.0.1:55421.
2012-12-03 09:02:13 Got SOCKS request for 0.0.1.0:1.
2012-12-03 09:02:13 locals (1): [u'127.0.0.1:55421']
2012-12-03 09:02:13 remotes (0): []
2012-12-03 09:02:13 Data from unlinked local 127.0.0.1:55421 (217 bytes).
2012-12-03 09:02:13 locals (1): [u'127.0.0.1:55421']
2012-12-03 09:02:13 remotes (0): []
```
Then I open a browser to make a single WebSocket connection which will appear as one of the pluggable transport's "remotes".
http://crypto.stanford.edu/flashproxy/embed.html?debug=1&client=127.0.0.1:9000&relay=173.255.221.44:9901
`flashproxy-client` sees the new remote and starts proxying data.
```
2012-12-03 09:02:17 Remote connection from 127.0.0.1:51321.
2012-12-03 09:02:17 Data from WebSocket-pending 127.0.0.1:51321.
2012-12-03 09:02:17 locals (1): [u'127.0.0.1:55421']
2012-12-03 09:02:17 remotes (1): [u'127.0.0.1:51321']
2012-12-03 09:02:17 Linking 127.0.0.1:55421 and 127.0.0.1:51321.
```
Now bootstrapping continues (over the WebSocket channel) until reaching 85%, and then it says "connections all too old, or too non-canonical" and makes a new SOCKS request:
```
Dec 03 09:02:18.000 [notice] new bridge descriptor '3VXRyxz67OeRoqHn' (fresh): $7C03D29CA58BE8EED5F483F31A2DEDF6FD7CC444~3VXRyxz67OeRoqHn at 0.0.1.0
Dec 03 09:02:18.000 [notice] We now have enough directory information to build circuits.
Dec 03 09:02:18.000 [notice] Bootstrapped 80%: Connecting to the Tor network.
...
Dec 03 09:02:18.000 [info] circuit_handle_first_hop(): Next router is [scrubbed]: Connections all too old, or too non-canonical. Launching a new one.
Dec 03 09:02:18.000 [notice] Bootstrapped 85%: Finishing handshake with first hop.
Dec 03 09:02:18.000 [info] connection_read_proxy_handshake(): Proxy Client: connection to 0.0.1.0:1 successful
```
`flashproxy-client` sees the SOCKS request, but because there are no more browser connections forthcoming, everything stalls at this point.
```
2012-12-03 09:02:18 Local connection from 127.0.0.1:55427.
2012-12-03 09:02:18 SOCKS request from 127.0.0.1:55427.
2012-12-03 09:02:18 Got SOCKS request for 0.0.1.0:1.
2012-12-03 09:02:18 locals (2): [u'127.0.0.1:55421', u'127.0.0.1:55427']
2012-12-03 09:02:18 remotes (1): [u'127.0.0.1:51321']
2012-12-03 09:02:18 Data from unlinked local 127.0.0.1:55427 (231 bytes).
```
I've verified this failure to bootstrap with recent 190c1d4981e5751aabd3d894095851c830f1d570. After bisecting, I think the last commit with the old behavior (bootstrapped 100%) was 751b3aabb5ab88fca16834e559a8d9835831b05f. There were some compile errors during bisecting so I couldn't narrow it to a specific revision; git reports
```
There are only 'skip'ped commits left to test.
The first bad commit could be any of:
35924435d22c2469ecbe06156c8069a928859d63
e136f7ccb4e671e33b6c92a48df819082291f5c1
4768c0efe3e9471cc367c3740d1a4ba0ab79626c
6cce6241dd4405f6cf21057f9913e07633cf18bb
519c971f6a3b89f1e81cda3c0290d4d943ec0d78
77dac97354974e8a819d8e35ad4e7a76199999b4
32337502f11e6c84e4db8591f5f81c4fc6d1da58
8b14db9628f0e8982e894034e86c8efdd78cff32
15303c32ec9d84aff8de5ed9df28e779c36c6e5c
28f108bcceab59fcf9f27e33065f64bfdb0f159a
7f952da55334d3a3693d1c6e8531fd96730265db
f0f87cb68a22feaf552a18b521d3313d843f8793
838743654c1bed2bfe22789ff53a1993c005f176
9ad7ba9f2267a9ee34fafda9356f1fa86633f00f
cb62a0b69a7d67b427224ca4c3075b49853a3a1f
We cannot bisect more!
```
Based on the log, cb62a0b69a7d67b427224ca4c3075b49853a3a1f seems a likely cause of the change: "Use channel_is_bad_for_new_circs(), connection_or_get_num_circs() in main.c".
I thought I would be able to reproduce this with another transport or with a simple SOCKS proxy, showing two connections where there used to be one, but I can't. I see two connections even with the old code. For example with an ssh SOCKS proxy (`ssh -v -D 9001 -N localhost`):
```
debug1: Connection to port 9001 forwarding to socks port 0 requested.
debug1: channel 2: new [dynamic-tcpip]
debug1: Connection to port 9001 forwarding to socks port 0 requested.
debug1: channel 3: new [dynamic-tcpip]
```
I guess that the difference is that previously, the second connection happens after bootstrapping is complete, while now it happens at 85%. (That is only a guess, I haven't verified it.)
Ticket description from https://lists.torproject.org/pipermail/tor-dev/2012-December/004221.html. nickm suggests log messages to test whether "is bad for new circs" is the reason the first channel isn't getting reused: https://lists.torproject.org/pipermail/tor-dev/2012-December/004246.html.Tor: 0.2.6.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/7803Clients shouldn't send timestamps in INTRODUCE1 cells2020-06-13T14:26:03ZRobert RansomClients shouldn't send timestamps in INTRODUCE1 cells0.2.3.x (and later) stable releases don't look at the timestamp field. As soon as 0.2.2.x is EOLed, clients should stop sending timestamps (send `(time_t)0` instead).0.2.3.x (and later) stable releases don't look at the timestamp field. As soon as 0.2.2.x is EOLed, clients should stop sending timestamps (send `(time_t)0` instead).Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8197Do something about policies_parse_exit_policy()'s arguments2020-06-13T14:27:22ZRoger DingledineDo something about policies_parse_exit_policy()'s arguments```
r = policies_parse_exit_policy(&line, &policy, 1, 0, 0, 1);
...
test_assert(0 == policies_parse_exit_policy(NULL, &policy2, 1, 1, 0, 1));
```
Quick quiz: which of these booleans means what? And which one isn't a boolean at all? ...```
r = policies_parse_exit_policy(&line, &policy, 1, 0, 0, 1);
...
test_assert(0 == policies_parse_exit_policy(NULL, &policy2, 1, 1, 0, 1));
```
Quick quiz: which of these booleans means what? And which one isn't a boolean at all? :)
(Don't work on this ticket until we merge #5528.)Tor: 0.2.6.x-finalrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/8402Tor should help its transport proxy use a proxy, if needed.2020-06-13T18:34:56ZGeorge KadianakisTor should help its transport proxy use a proxy, if needed.If a censored user wants to use both a (normal) proxy and a pluggable transport proxy, Tor should psas the credentials of the (normal) proxy to the pluggable transport proxy.
The proxy chain should look like this:
`Tor (Client) -> Trans...If a censored user wants to use both a (normal) proxy and a pluggable transport proxy, Tor should psas the credentials of the (normal) proxy to the pluggable transport proxy.
The proxy chain should look like this:
`Tor (Client) -> Transport Proxy (Client) -> SOCKS/HTTP Proxy -> Internet -> Transport Proxy (Server) -> Tor (Bridge)`
Arturo prepared a related proposal in:
https://lists.torproject.org/pipermail/tor-dev/2012-February/003318.html
We should clean it up, see if anything is missing, and start implementing it in Tor.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8405Provide a control port command to query the circuit used for SOCKS u+p2020-06-15T23:23:39ZMike PerryProvide a control port command to query the circuit used for SOCKS u+pOnce we start isolating streams by domain in the browser, it will be useful to have a way to ask Tor what circuit it is currently using for a given SOCKS username+password, so we can provide a tooltip or other indication directly in the ...Once we start isolating streams by domain in the browser, it will be useful to have a way to ask Tor what circuit it is currently using for a given SOCKS username+password, so we can provide a tooltip or other indication directly in the browser UI.Tor: 0.2.6.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/8546Make a copy-able connection-config type to limit copy burden of isolation fla...2020-06-13T14:28:23ZNick MathewsonMake a copy-able connection-config type to limit copy burden of isolation flags, etcRight now, an increasingly large number of fields and flags are duplicated between port_cfg_t, listener_connection_t, and (say) entry_connection_t. Every field we add here needs to be added to every one of those types, and needs to be e...Right now, an increasingly large number of fields and flags are duplicated between port_cfg_t, listener_connection_t, and (say) entry_connection_t. Every field we add here needs to be added to every one of those types, and needs to be explicitly copied from each to the next during construction time.
It would make this code much more maintainable if there were a type that we just copied from object to object here.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8964doc/HACKING is out of date2020-06-13T14:29:23ZRobert Ransomdoc/HACKING is out of date(as of commit e7134c2375f3c577ab7dcc20c74c5773d1a5f37d)
Line 43 states that the maint-0.2.1 branch is currently ‘actively developed’. It should not.
Line 54 uses “bug 9999” as a dummy bug number. That ticket will be opened this year....(as of commit e7134c2375f3c577ab7dcc20c74c5773d1a5f37d)
Line 43 states that the maint-0.2.1 branch is currently ‘actively developed’. It should not.
Line 54 uses “bug 9999” as a dummy bug number. That ticket will be opened this year.
Line 96 refers to “https://buildbot.vidalia-project.net/one_line_per_build”. I don't believe that that URL is still valid.
The Doxygen formatting details (starting after line 329) are frequently ignored in practice. That's probably a good thing, because fewer developers use Doxygen than jump around in the source using TAGS files and grep and read the comments directly. If you don't agree that abandoning Doxygen is a good idea, `make check-spaces` should detect and complain about at least gross problems (e.g. characters that should be escaped left unescaped).
The HACKING file does not mention using a TAGS file. (I put “`find src/ -name '*.[hc]' |etags -`” in my Git post-checkout hook.)Tor: 0.2.6.x-finalrl1987rl1987