Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T14:09:58Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/961TotalTraffic option (upload+download)2020-06-27T14:09:58ZTracTotalTraffic 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/tpo/core/tor/-/issues/4243rend_consider_services_upload waits up to 4 hours to publish the first HS des...2020-06-27T14:07:36ZRobert 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/tpo/core/tor/-/issues/4244Tor changes default value of DirReqStatistics, then wants to SAVECONF the new...2020-06-27T14:07:36ZRobert RansomTor changes default value of DirReqStatistics, then wants to SAVECONF the new defaultlegacy/trac#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.legacy/trac#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/tpo/core/tor/-/issues/4436Bridges should be able to disable v1 and v2 link handshakes2020-06-27T14:07:26ZGeorge 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/tpo/core/tor/-/issues/5583Add option to overwrite logs2020-06-27T14:06:31ZbastikAdd 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/tpo/core/tor/-/issues/6031Distinguish when a Tor HS is "not found" vs "not reachable" (exists / does no...2020-06-27T14:06:16ZnaifDistinguish 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/tpo/core/tor/-/issues/6088Gather data about possible transition to 2048bit RSA/DHE2020-06-27T14:06:14ZJacob 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/tpo/core/tor/-/issues/6456Merge parse_client_transport_line() and parse_server_transport_line()2021-09-16T14:36:00ZGeorge 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/tpo/core/tor/-/issues/6852bridges (especially unpublished ones) should include usage info in their hear...2020-06-27T14:05:40ZRoger 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/tpo/core/tor/-/issues/6938Log early log messages to log files2020-06-27T14:05:36ZshamrockLog 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/tpo/core/tor/-/issues/7356Make channel state test macros2020-06-27T14:05:18ZAndrea 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/tpo/core/tor/-/issues/7484We allow */bits as an address-and-mask pattern2020-06-27T14:05:14ZNick 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/tpo/core/tor/-/issues/7555MapAddress from FQDN to .onion fails because resolve requests for hidden ser...2020-06-27T14:05:11ZAaron 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/tpo/core/tor/-/issues/7733Two channels required for bootstrap2020-06-27T14:05:06ZDavid 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/tpo/core/tor/-/issues/7803Clients shouldn't send timestamps in INTRODUCE1 cells2020-06-27T14:05:01ZRobert 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/tpo/core/tor/-/issues/8197Do something about policies_parse_exit_policy()'s arguments2021-09-16T14:36:00ZRoger 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 legacy/trac#5528.)Tor: 0.2.6.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/8402Tor should help its transport proxy use a proxy, if needed.2020-06-27T14:04:39ZGeorge 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/tpo/core/tor/-/issues/8405Provide a control port command to query the circuit used for SOCKS u+p2020-06-27T14:04: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/tpo/core/tor/-/issues/8546Make a copy-able connection-config type to limit copy burden of isolation fla...2021-09-16T14:35:28ZNick 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/tpo/core/tor/-/issues/8964doc/HACKING is out of date2021-07-22T16:26:02ZRobert 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-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/9088Lower the voting interval in a test network2020-06-27T14:04:16ZLinus Nordberglinus@torproject.orgLower the voting interval in a test networkAs suggested in legacy/trac#8532, we could "trim time intervals as much as
possible while keeping everything stable. The current 5 minutes
between voting could perhaps change to 2." Or maybe one minute.
legacy/trac#8532 never did this. ...As suggested in legacy/trac#8532, we could "trim time intervals as much as
possible while keeping everything stable. The current 5 minutes
between voting could perhaps change to 2." Or maybe one minute.
legacy/trac#8532 never did this. It only added the possibility of chosing when
the voting should start so that we won't have to wait for the next
5-minute period (00, 05, 10, 15, ...).
This change would be valuable for testing changes to consensus voting,
like new consensus methods, and maybe more. These are probably not the
most common changes to tor. Setting priority minor.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9097Hidden service v0 and v1 INTRODUCE code should go away2020-06-27T14:04:16ZAndrea ShepardHidden service v0 and v1 INTRODUCE code should go awayHidden service INTRODUCE cell formats v0 and v1 are obsolete; the current hidden service code (rend_service_update_descriptor() of rendservice.c) only advertises support for v2 and v3 in descriptors.
The client-side INTRODUCE code in re...Hidden service INTRODUCE cell formats v0 and v1 are obsolete; the current hidden service code (rend_service_update_descriptor() of rendservice.c) only advertises support for v2 and v3 in descriptors.
The client-side INTRODUCE code in rend_client_send_introduction() of rendclient.c doesn't appear to ever generate the v1 cell format. It generates v3 if supported, then v2 if not, or v0 if neither v2 or v3 is marked supported in the descriptor. It does not test if the descriptor supports v0, but always generates and sends a v0 cell if neither v2 or v3 is supported. This behavior is broken but in a way that probably can never manifest.
The server-side v0/v1 INTRODUCE parsing code triggers a false positive buffer overflow warning in Coverity scan - which turns out to always be safe because the string in question is always NUL-terminated by that point. Still, it's a bit hair-raising to see and there's no reason for that code to still exist.hTor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9262Refactor cell scheduling to consider all connections at once2020-06-27T14:04:09ZNick MathewsonRefactor cell scheduling to consider all connections at onceRight now, our cell scheduling works by ensuring that every connection on which *any* circuit wants to write has at least one cell buffered for writing, and by putting more cells into the connection's write buffer every time a write make...Right now, our cell scheduling works by ensuring that every connection on which *any* circuit wants to write has at least one cell buffered for writing, and by putting more cells into the connection's write buffer every time a write makes it get low. The circuitmux logic is only used to choose which circuit on a given connection should have permission to write.
But this approach does a bad job in that it treats all connections equally: instead, it should look at all connections _which would like to write now_, and decide among them.
Reported by Rob Jansen.
Andrea is working on this one. As I understand it, the approach is to decouple the "Put a cell on this connection's output buffer" logic from the two things that trigger it: draining the output buffer a little in response to a libevent event, and making a circuit active on a connection which had no active circuits or buffered cells before. Instead, the main event loop should update a list of connections which would like to have cells put on them, and periodically (every X usec, or every time through the libevent loop, or something like that) queue cells onto the selected connections.
The details above will be a little tricksy. Andrea, could you explain a little more about your approach here? Alternatively I think I can dig up the conversation we had about this stuff, if you're okay with my posting it.Tor: 0.2.6.x-finalAndrea ShepardAndrea Shepardhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9273Brainstorm tradeoffs from moving to 2 (or even 1) guards2020-06-27T14:04:09ZRoger DingledineBrainstorm tradeoffs from moving to 2 (or even 1) guardsThere are now many conflicting issues to consider when changing the default number of guards. I'd like to write a proposal suggesting we move to 2 (or even 1), but I don't think I'm ready to write the analysis section yet.
Here's a star...There are now many conflicting issues to consider when changing the default number of guards. I'd like to write a proposal suggesting we move to 2 (or even 1), but I don't think I'm ready to write the analysis section yet.
Here's a start:
Pro 1: Reduces chance of using an adversary's guard. This argues for 1, but 2 would still be a lot better. See Tariq's WPES 2012 paper for details.
Pro 2: Reduces impact from guard fingerprinting: if the adversary learns that you have the following n guards, and later sees an anonymous user with the same guards, how likely is it to be you? Said another way, a trio of guards produces a cubic, whereas a duo of guards produces a quadratic. Somebody should do the math to sort out the chance of having all possible trios of guards, followed by the expected uniqueness of a trio. I expect moving to 2 gives the majority of the benefit here.
Con 1: Increases the variance of performance. The more guards you have, the closer to average performance you'll be. Whereas if you have just one guard, your performance will be impacted a lot by that choice. It would seem that we need to raise the bar on getting the Guard flag if we move people to having just one guard.
Con 2: Moving to 1 guard will rule out a Conflux-style design. But 2 guards would still work fine.
What did I miss?Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9286ordb1 uses milliseconds in its descriptor, spec says it can't2020-06-27T14:04:08ZRoger Dingledineordb1 uses milliseconds in its descriptor, spec says it can't```
router ordb1 213.246.53.127 8002 0 0
platform Tor 0.2.3.25 on Linux x86_64
opt protocols Link 1 2 Circuit 1
published 2013-07-17 13:38:46.992
```
But dir-spec.txt says
```
"published" YYYY-MM-DD HH:MM:SS NL
[Exactly once...```
router ordb1 213.246.53.127 8002 0 0
platform Tor 0.2.3.25 on Linux x86_64
opt protocols Link 1 2 Circuit 1
published 2013-07-17 13:38:46.992
```
But dir-spec.txt says
```
"published" YYYY-MM-DD HH:MM:SS NL
[Exactly once]
The time, in UTC, when this descriptor (and its corresponding
extra-info document if any) was generated.
```
It looks like it's violating the spec. Should we (i.e. the directory authorities) have validated and refused the descriptor?
Is it our Tor implementation that does this on a weird edge case, or did somebody mess with something?
(Noticed because contrib/exitlist can't handle it.)Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9321Load balance right when we have higher guard rotation periods2020-06-27T14:04:06ZRoger DingledineLoad balance right when we have higher guard rotation periodsHere's our plan:
1) Directory authorities need to track how much of the past n months each relay was around and had the Guard flag.
2) They vote a percentage for each relay in their vote, and the consensus has a new keyword on the w lin...Here's our plan:
1) Directory authorities need to track how much of the past n months each relay was around and had the Guard flag.
2) They vote a percentage for each relay in their vote, and the consensus has a new keyword on the w line so clients can learn how Guardy each relay has been.
3) Clients change their load balancing algorithm to consider how Guardy you've been, rather than just treating Guard status as binary (legacy/trac#8453).
4) Raise the guard rotation period a lot (legacy/trac#8240).Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9495Must we still disable threads on *-*-solaris*?2020-06-27T14:04:02ZNick MathewsonMust we still disable threads on *-*-solaris*?Back in 2005, in 8753e7ef6530c14a6d35c477a11ff203008bde50 (svn:r4383), we disabled threading on Solaris, in order to prevent some lockup bug or other. Unfortunately, back in 2005 we weren't so good at tracking bugs, so I can't easily fi...Back in 2005, in 8753e7ef6530c14a6d35c477a11ff203008bde50 (svn:r4383), we disabled threading on Solaris, in order to prevent some lockup bug or other. Unfortunately, back in 2005 we weren't so good at tracking bugs, so I can't easily find who reported it or how we diagnosed it.
But this is eight years later. If there was really a platform bug, surely it's gotten better by now?
We could contact one of the two or three operators whose nodes report being "on SunOS", and ask them if their nodes still work after an explicit --enable-threads , I guess.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9635Tor clients warn when they use the wrong ntor onion key2020-06-27T14:03:59ZbastikTor clients warn when they use the wrong ntor onion keyI got this warnings (exactly once, for the first time I'm aware of) on my 0.2.4.16-rc bridge on Windows.
Strangely I found no tickets for any of these failures.
Aug 31 09:37:10.793 [Warning] onion_skin_client_handshake failed.
Aug 31 0...I got this warnings (exactly once, for the first time I'm aware of) on my 0.2.4.16-rc bridge on Windows.
Strangely I found no tickets for any of these failures.
Aug 31 09:37:10.793 [Warning] onion_skin_client_handshake failed.
Aug 31 09:37:10.793 [Warning] circuit_finish_handshake failed.
Aug 31 09:37:10.794 [Warning] connection_edge_process_relay_cell (at origin) failed.
I'm unsure what _client means. Did my client (yes, I use my bridge's client functions) fail or did the client of an connecting bridge user fail?
Client functionality is not affected.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9682Better work queue implementation for cpuworkers2020-06-27T14:03:55ZNick MathewsonBetter work queue implementation for cpuworkersOur current implementation for passing work to cpuworkers and getting answers from them is pretty bulletproof: we share an fd with each one, write our requests there as a serialized struct, and get our answers back as serialized struct. ...Our current implementation for passing work to cpuworkers and getting answers from them is pretty bulletproof: we share an fd with each one, write our requests there as a serialized struct, and get our answers back as serialized struct. The cpuworker learns about new requests by calling read(); we learn about new answers from libevent().
But probably this isn't as efficient as it could be:
* We should have a work queue implementation that doesn't require a cpuworker to wait for the main process to give it more data after each request it answers.
* We should have a work queue implementation that uses condition variables as appropriate to notify cpuworkers of new data.
* We should use appropriate libevent mechanisms notify the main thread of new answers. (There are a bunch of ways to implement a condition variable that wakes libevent; we should pick one.)
* We should manage the communication in-memory rather than over sockets.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9708Clarify "please raise ulimit -n" message2020-06-27T14:03:53ZTracClarify "please raise ulimit -n" messageMy logfiles often contained messages like:
- Error creating network socket: Too many open files in system
This happens when socket layer calls return ENFILE or EMFILE. Raising kern.maxfiles and kern.maxfilesperproc makes these messag...My logfiles often contained messages like:
- Error creating network socket: Too many open files in system
This happens when socket layer calls return ENFILE or EMFILE. Raising kern.maxfiles and kern.maxfilesperproc makes these messages go away, as expected. However, the following message kept happening:
- Failing because we have 11062 connections already. Please raise your ulimit -n. [8422 similar message(s) suppressed in last 21600 seconds]
I spent a long time looking into file descriptor limits because the value (11062) was suspiciously close to the maximum number of file descriptors per process (11095), which I just raised earlier. Then I discovered #define ERRNO_IS_ACCEPT_RESOURCE_LIMIT(e) in src/common/compat.h and that I had to look for ENOMEM and ENOBUFS in addition to ENFILE and EMFILE.
Reading through the socket code in the kernel, I found that FreeBSD has a default maximum accept() backlog of 128 connections. When more than that number of TCPs are in the syncache, accept() will fail with one of ENOMEM or ENOBUFS. I haven't spent the time to figure out which (it's a maze of twisty passages between kern/uipc_socket and netinet/tcp_usrreq.c -- neither of those are in my active brain cache).
The actual "solution" to the problem (allow tor to accept more connections, and thus make the message go away) was to raise kern.ipc.somaxconn.
The instruction to raise ulimit -n is definitely wrong for FreeBSD. Or at least only part of the story, and certainly cause for confusion. Perhaps the message should point to some generic documentation suggesting system limits/knobs to twiddle, rather than assuming that all the world is Linux and ulimit -n will work in every case.
**Trac**:
**Username**: philipTor: 0.2.6.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/9709We accept way more tap cells than we process2020-06-27T14:03:53ZRoger DingledineWe accept way more tap cells than we processOur fix in legacy/trac#7291 was meant to have us turn away onionskins that we're unlikely to get to. But in practice our legacy/trac#9658 patch shows that we're accepting way more than we process.
Linus briefly did a test where he cherr...Our fix in legacy/trac#7291 was meant to have us turn away onionskins that we're unlikely to get to. But in practice our legacy/trac#9658 patch shows that we're accepting way more than we process.
Linus briefly did a test where he cherry-picked the legacy/trac#9658 patch onto 0.2.4.16-rc and it was still only handling about 25% of incoming requests. His cursory analysis was that he was dropping them with the
```
log_info(LD_CIRC,
"Circuit create request is too old; canceling due to overload.");
```
line.
Should we be refusing these earlier, so clients can know to go elsewhere?
One possible culprit is that the main Tor thread is too busy to give cpuworker events out on time.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9801options_act thinks options have changed that haven't2020-06-27T14:03:49Zcypherpunksoptions_act thinks options have changed that haven'toptions_act(): Changed to using entry guards or bridges, or changed preferred or excluded node lists. Abandoning previous circuits.
options_act(): Worker-related options changed. Rotating workers.
They haven't. Tor 0.2.3 did not have thi...options_act(): Changed to using entry guards or bridges, or changed preferred or excluded node lists. Abandoning previous circuits.
options_act(): Worker-related options changed. Rotating workers.
They haven't. Tor 0.2.3 did not have this bug.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9812Unhelpful "Crypto error" message in Release 0.2.4.17-rc non-exit Relay2020-06-27T14:03:49ZTracUnhelpful "Crypto error" message in Release 0.2.4.17-rc non-exit RelayMy relay that has been running release 0.2.4.17-rc for several day now
has become saturated with what I would consider 'noise' - namely a huge
amount of handshake activity. It does respond downward to lowereing the
bandwidth setting, bu...My relay that has been running release 0.2.4.17-rc for several day now
has become saturated with what I would consider 'noise' - namely a huge
amount of handshake activity. It does respond downward to lowereing the
bandwidth setting, but the bandwidth graph is nearly flat. Now I have
just noticed two crypto errors in the message log.
Sep 23 14:17:32.902 [Notice] Circuit handshake stats since last time:
224326/224887 TAP, 40/40 NTor.
Sep 23 15:17:32.999 [Notice] Circuit handshake stats since last time:
224169/225104 TAP, 77/77 NTor.
Sep 23 16:17:32.016 [Notice] Circuit handshake stats since last time:
224655/225333 TAP, 63/63 NTor.
Sep 23 16:50:14.883 [Warning] crypto error while checking RSA signature:
block type is not 01 (in rsa routines:RSA_padding_check_PKCS1_type_1)
Sep 23 16:50:14.883 [Warning] crypto error while checking RSA signature:
padding check failed (in rsa routines:RSA_EAY_PUBLIC_DECRYPT)
Sep 23 17:17:32.782 [Notice] Circuit handshake stats since last time:
222538/222987 TAP, 14/14 NTor.
Sep 23 17:36:03.704 [Warning] eventdns: All nameservers have failed
Sep 23 17:36:03.829 [Notice] eventdns: Nameserver 192.168.1.254:53 is
back up
My relay is running from 108.214.60.211 and in the last 2 days it has started eating up to 17 % of my CPU time where it previously used less than 10 %. Handshake counts are up substantially more than an order of magnitude.
I rebooted out of an abundance of caution, and the cpu usage is now below 5 % but the handshake numbers is "Sep 23 19:25:12.621 [Notice] Circuit handshake stats since last time: 131567/132269 TAP, 14/14 NTor.", after rebooting.
**Trac**:
**Username**: LoneRanger1012Tor: 0.2.6.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/9819Circuits through entry guards aren't distinguished on whether they originated...2020-06-27T14:03:49ZAndrea ShepardCircuits through entry guards aren't distinguished on whether they originated locallyWhen a node is both a relay and a client, and another node extends a circuit through it to one of its entry guards, that circuit isn't distinguished from a circuit which originated locally. If entry_guard_register_connect_status() decid...When a node is both a relay and a client, and another node extends a circuit through it to one of its entry guards, that circuit isn't distinguished from a circuit which originated locally. If entry_guard_register_connect_status() decides we should retry a different entry guard, the circuit will be killed in channel_do_open_actions(). This potentially could leak information about entry guards in circumstances which appear to be hard to exploit.
IRC log:
```
07:42 < athena> skruffy: what makes you believe 'channel_do_open_actions() can
leak of used guards if relay used as client' ?
07:43 < skruffy> if entry_guard_register_connect_status() failed it will close circuits
07:49 < athena> sooo - in other words, you think if an attacker can build a
circuit through a node N which is both a relay and a client to an
another node E, and then arrange for
entry_guard_register_connect_status() to fail, the attacker can
test a hypothesis about whether E is an entry guard for N?
07:52 < skruffy> something like that
07:53 < athena> okay; how would the attacker do that?
07:54 < athena> you may have something there; it seems fishy that killing pending
circuits on an entry guard we don't want to use doesn't
distinguish between locally originating circuits and circuits from
another relay - but i think if so it probably was there pre-
channels and i'm not convinced it's exploitable yet
07:59 < skruffy> yes it's pre-chans.
08:02 < athena> hmm, it looks like the only circumstance in which
entry_guard_register_connect_status() can fail is if this is a
first connection to a new entry guard *and* an old entry guard
which was offline has just come back
08:03 < athena> it doesn't seem that practical to exploit - for an attacker to try
to selectively manipulate connectivity to the old entry guards to
induce those conditions requires already knowing them
08:04 < nickm> It couldn't hurt to treat this as a bug that we should fix sooner
or later, though.
08:04 < athena> i think agree conceptually that locally originating circuits and
relay circuits should be distinguished and failing
entry_guard_register_connect_status() should only kill the local
ones, though
```
Proposed fix:
Modify circuit_n_chan_done() to take another possible parameter that notifies or_circuits of success but tells all other pending circuits to give up, and pass this from channel_do_open_actions() in case of entry_guard_register_connect_status() failing.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9969We launch 50 microdesc requests, spread out over just three guards?2020-06-27T14:03:44ZRoger DingledineWe launch 50 microdesc requests, spread out over just three guards?Our choice of how many microdescs to fetch per directory request is really totally irrational since the network has grown so much since we chose those parameters.
```
Oct 11 13:32:44.779 [info] launch_descriptor_downloads(): Launching 50...Our choice of how many microdescs to fetch per directory request is really totally irrational since the network has grown so much since we chose those parameters.
```
Oct 11 13:32:44.779 [info] launch_descriptor_downloads(): Launching 50 requests for 4574 microdescs, 92 at a time
```
Seriously, we're making 50 requests and spreading them over 3 guards? I guess it's nice that we can get partial answers, but generally partial answers don't help us.
We should fetch many more at a time if it's going over a begindir channel.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/10067Have `reject *` as the default exit policy2020-06-27T14:03:41ZLunarHave `reject *` as the default exit policyQuoting arma in [a discussion on tor-relays](https://lists.torproject.org/pipermail/tor-relays/2013-November/003191.html):
> On Thu, Oct 31, 2013 at 06:12:47PM -0700, Andy Isaacson wrote:
> > That's correct, it takes a deliberate action...Quoting arma in [a discussion on tor-relays](https://lists.torproject.org/pipermail/tor-relays/2013-November/003191.html):
> On Thu, Oct 31, 2013 at 06:12:47PM -0700, Andy Isaacson wrote:
> > That's correct, it takes a deliberate action on the part of the
> > administrator to become a relay; and another deliberate action to become
> > an exit relay.
>
> Actually, that second part isn't true. Once you decide to become a relay,
> the default is to exit to most popular ports.
>
> The main reason for this choice is the number of people who've told us
> that they are only able to run exit relays because "it's what Tor does
> when you run a relay", and their institution wouldn't let them do it if
> it required a manual config change to become an exit.
>
> Then again, that was a long time ago, and maybe it's gotten harder to
> sustain exits these days?
I think the change is actually worth making as I have seen two users being surprised by the current default behaviour. People running an exit while not fully aware of what it means usually turn unhappy.
(In any cases, we can discuss and `wontfix` if the previous rationale still hold.)Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/10116Avoid memory allocation in OOM handler2020-06-27T14:03:40ZNick MathewsonAvoid memory allocation in OOM handlerRight now, the OOM handler allocates an array of size(n_circs * sizeof(void*)) to figure out which circuits to kill. That's probably not a good idea. Instead, it would be better to select the select circuits from the circuitlist.
Opti...Right now, the OOM handler allocates an array of size(n_circs * sizeof(void*)) to figure out which circuits to kill. That's probably not a good idea. Instead, it would be better to select the select circuits from the circuitlist.
Options here include:
* Turn global_circuitlist into an array (smartlist) structure.
* Retain the linked-list structure, but do one of these:
* Use a merge sort to sort the circuitlist in place.
* Do an O(N^2) algorithm to walk the circuitlist to find the worst circuit, delete that, and then do it over and over until we have killed enough circuits.
* Do an O(Nk) algorithm to walk the circuitlist to find the k worst circuits; kill them; repeat until we have killed enough circuits. This still turns out to O(N^2)Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/10163Raise minimum consensus method to 132020-06-27T14:03:40ZNick MathewsonRaise minimum consensus method to 13Very old directory consensus methods simply won't generate results that work on the Tor network. There's a security flaw in consensus methods 7 through 11. According to proposal 215, it would be fine to simply require method 13 as a mi...Very old directory consensus methods simply won't generate results that work on the Tor network. There's a security flaw in consensus methods 7 through 11. According to proposal 215, it would be fine to simply require method 13 as a minimum for all authorities, since it's supported by 0.2.3 and later.
We should do this.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/10343specify units in torrc.sample2020-06-27T14:03:37ZRoger Dingledinespecify units in torrc.sampleweasel and i both thought we'd said bytes rather than b in the torrc file. Apparently we never did anything of the sort.
maybe there is a ticket about this somewhere, with a patch? If not, here is one.weasel and i both thought we'd said bytes rather than b in the torrc file. Apparently we never did anything of the sort.
maybe there is a ticket about this somewhere, with a patch? If not, here is one.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/10395Tor's consensus lists Torbrowser updates2020-06-27T14:03:37ZTom LowenthalTor's consensus lists Torbrowser updatesTor's consensus lists not only recommended versions of Torbrowser, but also the version numbers, names, and hashes of incremental updates.Tor's consensus lists not only recommended versions of Torbrowser, but also the version numbers, names, and hashes of incremental updates.Tor: 0.2.6.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/10427Point operators of new relay to the lifecycle document2020-06-27T14:03:36ZLunarPoint operators of new relay to the lifecycle documentIt's quite often that operators of new relays wonder why they are not seeing all their bandwidth used immediately. I wonder if it would help to add a log message like: _You are running a new relay. Thanks for helping the Tor network! If ...It's quite often that operators of new relays wonder why they are not seeing all their bandwidth used immediately. I wonder if it would help to add a log message like: _You are running a new relay. Thanks for helping the Tor network! If you wish to know what will happen in the upcoming weeks regarding its usage, have a look at https://blog.torproject.org/blog/lifecycle-of-a-new-relay_Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/10505Broken ASLR in windows executable2021-08-23T15:19:19ZTracBroken ASLR in windows executableASLR (Address Space Layout Randomization) is a windows feature to complicate writing exploits. The provided tor executable in the windows expert bundle doesn't have full ASLR support.
A windows executable must have two features to fully...ASLR (Address Space Layout Randomization) is a windows feature to complicate writing exploits. The provided tor executable in the windows expert bundle doesn't have full ASLR support.
A windows executable must have two features to fully support ASLR:
1) In the PE header the following DllCharacteristics flag must be set IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE (0x0040). Tor has this value correctly set.
2) PE relocation table. To successfully randomize the address space of the executable, the PE loader must know what addresses need to be adjusted. Therefore to randomize the image base (standard image base: 0x00400000) the PE file must have a relocation table. Tor is missing the relocation table. As a result, the image base is always 0x00400000 and this is bad.
The linker should provide a switch to include a relocation table.
PS: Greetings from the 30C3. Nice presentation yesterday.
**Trac**:
**Username**: BlueberryTor: 0.2.6.x-finalErinn ClarkErinn Clarkhttps://gitlab.torproject.org/tpo/core/tor/-/issues/10676Verify urandom-style RNG is seeded before generating ID keys2020-06-27T14:03:31ZNick MathewsonVerify urandom-style RNG is seeded before generating ID keysIn a better world, every kernel would have a /dev/urandom interface that would block if it hadn't been seeded enough. I hear that some operating systems do this already.
Unfortunately, the world is what it is, and a typical /dev/urando...In a better world, every kernel would have a /dev/urandom interface that would block if it hadn't been seeded enough. I hear that some operating systems do this already.
Unfortunately, the world is what it is, and a typical /dev/urandom implementation treats the case where its internal entropy estimator is low exactly the same as the case when its internal entropy estimator has never gotten high at all.
So we should try to protect ourselves from cases where we start up on systems with limited entropy and /dev/urandom refuses to tell us so. Here's a design sketch:
1. If we're generating an identity key when we haven't generated one before, or if we are starting Tor for the first time with a given DataDirectory, we should first try to read a single byte from /dev/random, and block until we can. This will ensure that the kernel RNG has (by its own lights) reached full entropy at least once, which guarantees cryptographic quality of the rest of the /dev/urandom stream.
2. Optionally, we can keep some RNG output in a file on disk in our data directory, and use it as an extra seed on subsequent Tor boots, regenerating it each time we start Tor. Combined with 1 above, this would protect us -- at least as well as most operating systems protect us -- from ever running our RNG in a low-entropy environment.
3. Optionally, we could to the trick in 1 above every time we start Tor.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/10816Don't exclude NTE_BAD_KEYSET error for windows2020-06-27T14:03:29ZcypherpunksDon't exclude NTE_BAD_KEYSET error for windows```
if (!provider_set) {
if (!CryptAcquireContext(&provider, NULL, NULL, PROV_RSA_FULL,
CRYPT_VERIFYCONTEXT)) {
if ((unsigned long)GetLastError() != (unsigned long)NTE_BAD_KEYSET) {
log_wa...```
if (!provider_set) {
if (!CryptAcquireContext(&provider, NULL, NULL, PROV_RSA_FULL,
CRYPT_VERIFYCONTEXT)) {
if ((unsigned long)GetLastError() != (unsigned long)NTE_BAD_KEYSET) {
log_warn(LD_CRYPTO, "Can't get CryptoAPI provider [1]");
return -1;
}
}
provider_set = 1;
}
```
According to http://msdn.microsoft.com/en-us/library/windows/desktop/aa379886%28v=vs.85%29.aspx NTE_BAD_KEYSET is
```
The key container could not be opened. A common cause of this error is that the key container does not exist. To create a key container, call CryptAcquireContext using the CRYPT_NEWKEYSET flag. This error code can also indicate that access to an existing key container is denied. Access rights to the container can be granted by the key set creator by using CryptSetProvParam.
```
Such error code can't be returned for used parametrs, but if something gone wrong in system then current processing this code blocks any next tries to get random data and hides real reason for any next CryptGenRandom failures.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/10993Fails to reconnect after connection loss when only one bridge is configured2021-10-29T17:55:46ZLunarFails to reconnect after connection loss when only one bridge is configuredWhen configured to use only a single bridge, if the connection to that bridge is lost (which typically happen when suspending or hoping from one network to another), tor will not try to reconnect even when the bridge is reachable availab...When configured to use only a single bridge, if the connection to that bridge is lost (which typically happen when suspending or hoping from one network to another), tor will not try to reconnect even when the bridge is reachable available again.
At notice level, you can see a loop of:
```
smartlist_choose_node_by_bandwidth(): Empty routerlist passed in to old node selection for rule weight as guard
should_delay_dir_fetches(): delaying dir fetches (no running bridges known)
compute_weighted_bandwidths(): Empty routerlist passed in to consensus weight node selection for rule weight as guard
```
I don't think this happen when there is more than one bridge configure but I'm not 100% sure at this time.
I also have the feeling that this did not happen with version 0.2.3, but I'm not 100% sure either.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11016Add support for systemd watchdog protocol2020-06-27T14:03:24ZTracAdd support for systemd watchdog protocolSystemd provides a watchdog protocol, as described on http://0pointer.de/blog/projects/watchdog.html . It basically requires the service to write a message to a socket every X second, if some environment variables are set. While present ...Systemd provides a watchdog protocol, as described on http://0pointer.de/blog/projects/watchdog.html . It basically requires the service to write a message to a socket every X second, if some environment variables are set. While present since a long time, the newer v209 version provides a helper function to implement it, by moving the parsing logic in a library.
So here is 2 patches for tor :
The first one implement the Notify protocol for systemd, thus permitting people to use Type=notify in the systemd unit ( see http://www.freedesktop.org/software/systemd/man/systemd.service.html for the detail, as well as the rather lengthy debate on Debian init system for Jessie ). The patch is not doing much or adding much features, but I guess some people would prefer to have this Type of systemd unit rather than simple as it could prevent some race condition if a service requires tor to be really started and working, before being started himself. It also add status line to systemd, but that's not a feature that is currently used much ( I do hope maybe some higher level tool like cockpit would use it later ).
The 2nd one is adding a event to the main loop to ping the watchdog on a regular basis, using the new function in libsystemd-daemon. So this way, if tor is stuck, it will be restarted. I guess I do not have to explain how and why this improve tor :)
So far, I only have been able to test the first one on my Fedora 20 and I am waiting for package to test the 2nd one in real life. However, in order to release early, release often, I upload them here for review.
**Trac**:
**Username**: miscTor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11120Write a proposal for client-side key pinning2020-06-27T14:03:21ZNick MathewsonWrite a proposal for client-side key pinningProposal 220 suggests that we pin RSA and Ed25519 identity keys to one another authority-side. Roger suggested to me that we also consider doing client-side identity pinning.Proposal 220 suggests that we pin RSA and Ed25519 identity keys to one another authority-side. Roger suggested to me that we also consider doing client-side identity pinning.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11144Have a better way to manage torrc.sample2020-06-27T14:03:20ZNick MathewsonHave a better way to manage torrc.sampleIt's difficult to make changes to torrc.sample, since IIUC it's also used as the basis for the default torrc on Debian (and elsewhere?), so when we make cosmetic changes to it, users everywhere are forced to rebuild their configuration.
...It's difficult to make changes to torrc.sample, since IIUC it's also used as the basis for the default torrc on Debian (and elsewhere?), so when we make cosmetic changes to it, users everywhere are forced to rebuild their configuration.
Perhaps we should have a torrc that's the one we edit frequently, which we treat as a real sample configuration, and which we give to users who haven't installed tor before or made changes to the default torrc?Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11157Write a proposal for chaining consensus hashes2020-06-27T14:03:19ZNick MathewsonWrite a proposal for chaining consensus hashesFrom discussion at the dev meting
It would be good if each consensus contained a hash of the last consensus, so that we could more easily authenticate long periods of the consensus chain.
I forget what else this was supposed to be good...From discussion at the dev meting
It would be good if each consensus contained a hash of the last consensus, so that we could more easily authenticate long periods of the consensus chain.
I forget what else this was supposed to be good for.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11243Don't fetch any descriptor which we already fetched and found to be ill-formed2020-06-27T14:03:18ZNick MathewsonDon't fetch any descriptor which we already fetched and found to be ill-formedIt's hard to add code that makes a previously valid descriptor invalid (as we'd like to do for legacy/trac#7484 and legacy/trac#9286), since doing so can put us in a loop where we download the descriptor, get it, reject it, and download ...It's hard to add code that makes a previously valid descriptor invalid (as we'd like to do for legacy/trac#7484 and legacy/trac#9286), since doing so can put us in a loop where we download the descriptor, get it, reject it, and download it again.
Instead, we should record that the descriptor with some given hash is simply invalid. That's easy for microdescriptors, but a bit harder for router descriptors, since the hash doesn't include the signature itself. So we need to check the signature in that case before rejecting.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11291Support group readable hidden service directories2020-06-27T14:03:17ZTracSupport group readable hidden service directoriesIf a Tor users wishes to use a system Tor with a user service they may encounter problems with not being able to utilize the hidden service due to directory permissions.
An option "HiddenServiceDirGroupReadable" similar to "ControlPortF...If a Tor users wishes to use a system Tor with a user service they may encounter problems with not being able to utilize the hidden service due to directory permissions.
An option "HiddenServiceDirGroupReadable" similar to "ControlPortFileGroupReadable" and "CookieAuthFileGroupReadable" would resolve this issue.
**Trac**:
**Username**: anonTor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11302connection_handle_write_impl() should handle orconns properly if getsockopt()...2020-06-27T14:03:16ZAndrea Shepardconnection_handle_write_impl() should handle orconns properly if getsockopt() failsThe function connection_handle_write_impl() in connection.c contains this code:
```
/* Sometimes, "writable" means "connected". */
if (connection_state_is_connecting(conn)) {
if (getsockopt(conn->s, SOL_SOCKET, SO_ERROR, (void*)&e, &l...The function connection_handle_write_impl() in connection.c contains this code:
```
/* Sometimes, "writable" means "connected". */
if (connection_state_is_connecting(conn)) {
if (getsockopt(conn->s, SOL_SOCKET, SO_ERROR, (void*)&e, &len) < 0) {
log_warn(LD_BUG, "getsockopt() syscall failed");
if (CONN_IS_EDGE(conn))
connection_edge_end_errno(TO_EDGE_CONN(conn));
connection_mark_for_close(conn);
return -1;
}
```
This might close an orconn out from under the channel layer improperly. It should test for orconns and call connection_or_connect_failed() in that case rather than connection_mark_for_close() directly. Created pursuant to connection_mark_for_close() audit task legacy/trac#7472.Tor: 0.2.6.x-finalAndrea ShepardAndrea Shepardhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11446Remove Windows CE support2021-09-16T14:35:28ZNick MathewsonRemove Windows CE supportLong ago we merged some patches to support WinCE. I am pretty sure that nobody actually uses Tor on WinCE now, and I doubt that the code works any more. We should just strip it out.Long ago we merged some patches to support WinCE. I am pretty sure that nobody actually uses Tor on WinCE now, and I doubt that the code works any more. We should just strip it out.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11447Find a better value for MAX_REND_FAILURES2020-06-27T14:03:12ZNick MathewsonFind a better value for MAX_REND_FAILURESFor a while, MAX_REND_FAILURES was set to 30. That's clearly wrong; in legacy/trac#4241 we set it to 8. But is 8 the right value? We should investigate actual failure rates and pick a value that's more in tune with what we're actually ...For a while, MAX_REND_FAILURES was set to 30. That's clearly wrong; in legacy/trac#4241 we set it to 8. But is 8 the right value? We should investigate actual failure rates and pick a value that's more in tune with what we're actually seeing in the wild.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11454If two auth certs are both old but were generated nearby in time, we keep both2020-06-27T14:03:11ZRoger DingledineIf two auth certs are both old but were generated nearby in time, we keep bothIn trusted_dirs_remove_old_certs() we check if
```
(cert_published + OLD_CERT_LIFETIME < newest_published)) {
```
when deciding whether to discard an old cert from our cache.
We don't check it at all with respect to current ...In trusted_dirs_remove_old_certs() we check if
```
(cert_published + OLD_CERT_LIFETIME < newest_published)) {
```
when deciding whether to discard an old cert from our cache.
We don't check it at all with respect to current time.
So if an authority generates a signing key in January, and then generates ten more signing keys within a week, and now it's April, we'll still keep all of them until they expire or until a new signing key shows up that's more than 7 days newer than them.
This cannot be the right logic.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11457Making a signing cert in the future will make everybody discard your real sig...2020-06-27T14:03:11ZRoger DingledineMaking a signing cert in the future will make everybody discard your real signing cert and then want it againRun an authority, with a normal signing authority_certificate. Then move your date into the future (has to be more than one week in the future), and generate and use another signing cert. Relays, clients, and other directory authorities ...Run an authority, with a normal signing authority_certificate. Then move your date into the future (has to be more than one week in the future), and generate and use another signing cert. Relays, clients, and other directory authorities will smoothly upgrade to your new one, and (barring issues like legacy/trac#11454) throw out your old signing cert.
Then throw out your shiny new one, and go back to the one you had been using. Other Tors (dir auths, relays, clients) will say "oh hey, a signature from a cert I don't recognize, let me fetch that". So far so good.
Then 60 seconds later they'll discard this cert, because they know a newer one. Oops.
But this is where is gets good. Your authority discards this older cert too. So do other authorities. And relays.
And then everybody wants a copy and nobody has one, so every 60 seconds everybody asks the next layer up in the dir hierarchy. Everybody's logs are filled with
```
Apr 09 03:44:55.000 [warn] Received http status code 404 ("Not found") from server '127.0.0.1:3002' while fetching "/tor/keys/fp-sk/AD23D263206B997C73AF9B488322E91766748C2C-4335577168B0C0C22AC4A1A0707DD72F41CC8DA6".
```
each minute.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11485support unix-sockets as hidden-service endpoints2020-06-27T14:03:10Zmeejahsupport unix-sockets as hidden-service endpointsIt would be nice if hidden-service setup supported proxying to a local unix-socket. nginx, Twisted (and probably others) support this for HTTP for example.
This would reduce the chances of "accidentally" listening on a public TCP port (...It would be nice if hidden-service setup supported proxying to a local unix-socket. nginx, Twisted (and probably others) support this for HTTP for example.
This would reduce the chances of "accidentally" listening on a public TCP port (and eases the task of verifying this) and is somewhat faster.
I'm unsure if it's better to have a new config-item, or overlap with the existing hidden-service listening specification.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11582"getinfo address" reports wrong IP address after it has changed2020-06-27T14:03:06Zra"getinfo address" reports wrong IP address after it has changed
The "getinfo address" Tor control command reports the client's IP address.
After the client's IP address has changed, the control command falsely reports the last resolved address without ever updating it.
The attached patch resets t...
The "getinfo address" Tor control command reports the client's IP address.
After the client's IP address has changed, the control command falsely reports the last resolved address without ever updating it.
The attached patch resets the last resolved address on an IP address change, resulting in "getinfo address" reporting the correct IP.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11598Investigate using of TLSv1_method instead of SSLv23_method2020-06-27T14:03:06ZcypherpunksInvestigate using of TLSv1_method instead of SSLv23_methodtortls.c
```
#if 0
/* Tell OpenSSL to only use TLS1. This may have subtly different results
* from SSLv23_method() with SSLv2 and SSLv3 disabled, so we need to do some
* investigation before we consider adjusting it. It should b...tortls.c
```
#if 0
/* Tell OpenSSL to only use TLS1. This may have subtly different results
* from SSLv23_method() with SSLv2 and SSLv3 disabled, so we need to do some
* investigation before we consider adjusting it. It should be compatible
* with existing Tors. */
if (!(result->ctx = SSL_CTX_new(TLSv1_method())))
goto error;
#endif
```
s23_*.c files of OpenSSL code doesn't seems like many eyes will looking at.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11674Document TOR_PT_PROXY in 'pt-spec.txt'.2020-06-27T14:03:03ZGeorge KadianakisDocument TOR_PT_PROXY in 'pt-spec.txt'.legacy/trac#8403 was great, but since we decided to implement the PT-outgoing-proxy feature we should also mention how it works in `pt-spec.txt` (since that's where people who want to develop PTs look at)legacy/trac#8403 was great, but since we decided to implement the PT-outgoing-proxy feature we should also mention how it works in `pt-spec.txt` (since that's where people who want to develop PTs look at)Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11679Download status for consensus scheduled as generic2020-06-27T14:03:03ZcypherpunksDownload status for consensus scheduled as genericCurrently download status scheduled as generic (DL_SCHED_GENERIC = 0);
```
/** Download status for the current consensus networkstatus. */
static download_status_t consensus_dl_status[N_CONSENSUS_FLAVORS];
```
Before [implementing](https...Currently download status scheduled as generic (DL_SCHED_GENERIC = 0);
```
/** Download status for the current consensus networkstatus. */
static download_status_t consensus_dl_status[N_CONSENSUS_FLAVORS];
```
Before [implementing](https://gitweb.torproject.org/tor.git/commitdiff/851a980065e6b2df8d7cb35a22d0675b8918214b) of consensus for md it was DL_SCHED_CONSENSUS:
```
static download_status_t consensus_dl_status = { 0, 0, DL_SCHED_CONSENSUS };
```
That means unfriendly schedule for client with fragile network connection.
```
/** Schedule for when clients should download things in general. */
static const int client_dl_schedule[] = {
0, 0, 60, 60*5, 60*10, INT_MAX
};
```
vs.
```
/** Schedule for when clients should download consensuses. */
static const int client_consensus_dl_schedule[] = {
0, 0, 60, 60*5, 60*10, 60*30, 60*60, 60*60, 60*60, 60*60*3, 60*60*6, 60*60*12
};
```
Tor will reset download status by `networkstatus_reset_download_failures` once a hour so client will have a chance to retry, so no unresolved state actually.
Is it worth to initialize download status for consensus schedule? Or to rename schedule if planned to use it for certs only?Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11683Stop caching extra-info documents on directory mirrors2020-06-27T14:03:03ZKarsten LoesingStop caching extra-info documents on directory mirrorsI suggest stopping to cache extra-info documents on directory mirrors.
Most clients don't need extra-info documents for their normal operation. The only use case that comes to mind is external tools configuring a local tor client to pr...I suggest stopping to cache extra-info documents on directory mirrors.
Most clients don't need extra-info documents for their normal operation. The only use case that comes to mind is external tools configuring a local tor client to provide them with extra-info documents. Note that we wouldn't break these tools, because they could still fetch from the directory authorities. Though I assume there are very few requests for extra-info documents in the network.
There are also not many directory mirrors in the network that serve extra-info documents: in the first weeks of April 2014, only 0.46% of server descriptors contained the `"caches-extra-info"` line, so 0.46% * 5,000 = 23 relays. Note that 9 of these are directory authorities and only 14 are directory mirrors.
But still, these 14 directory mirrors need to keep their cache up-to-date by fetching extra-info documents from the directory authorities. If there are fewer than 14 clients downloading extra-info documents from the caches, the caches put even more load on directory authorities just to keep their caches recent.
All in all, I'd say let's get rid of extra-info documents on directory mirrors. I can write a patch, unless somebody else enjoys removing (mostly) unused code as much as I do.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11737Damage of cached hte_hash values for HTs leads to undefined behavior2020-06-27T14:03:03ZcypherpunksDamage of cached hte_hash values for HTs leads to undefined behaviorLow budget memory modules affected by [soft errors](https://en.wikipedia.org/wiki/Soft_error)
Broken hte_hash value indirectly but drastically changes logic of code. Tor should to fix damaged hte_hash values or assert on failure. Or to b...Low budget memory modules affected by [soft errors](https://en.wikipedia.org/wiki/Soft_error)
Broken hte_hash value indirectly but drastically changes logic of code. Tor should to fix damaged hte_hash values or assert on failure. Or to be ready for such damages so it wasn't reason of another looks alike random bugs.
For example usage of HT_NEXT(_RMV) for iterating over hash table with broken hash values leads to shortage or infinite loops.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11787Can we save huge amounts of directory bandwith with Z_NO_FLUSH?2020-06-27T14:03:02ZNick MathewsonCan we save huge amounts of directory bandwith with Z_NO_FLUSH?It seems our default argument when compressing with zlib is Z_SYNC_FLUSH. That's not ideal, though: in theory we would get better compression by using Z_NO_FLUSH. But, how much better? And would that work with our code, or would we ne...It seems our default argument when compressing with zlib is Z_SYNC_FLUSH. That's not ideal, though: in theory we would get better compression by using Z_NO_FLUSH. But, how much better? And would that work with our code, or would we need other changes?
We should at least investigate this in 0.2.5, though if the fix is nontrivial, it can wait for 0.2.6.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11790Our zlib deflate objects require lots of memory per directory connection2020-06-27T14:03:02ZNick MathewsonOur zlib deflate objects require lots of memory per directory connectionCompressing descriptors on the fly requires a lot of memory with zlib's default settings. According to zconf.h:
```
/* The memory requirements for deflate are (in bytes):
(1 << (windowBits+2)) + (1 << (memLevel+9))
that i...Compressing descriptors on the fly requires a lot of memory with zlib's default settings. According to zconf.h:
```
/* The memory requirements for deflate are (in bytes):
(1 << (windowBits+2)) + (1 << (memLevel+9))
that is: 128K for windowBits=15 + 128K for memLevel = 8 (default values)
plus a few kilobytes for small objects.
```
We are using windowbits == 15 and memLevel == 8. This might explain in part why busy directories are so memory-hungry. In addition to our investigations for legacy/trac#11787, we should see whether we can safely reduce this to 32K or so with windowBits == 12 and memlevel == 5. It appears in preliminary investigation that this compression level would not hurt compression very much (0-5% for microdescs, 3-7% for server descriptors).
We could also choose our window size and memlevel based on current memory availability.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11791Our zlib deflate objects require lots of memory per directory connection2020-06-27T14:03:01ZNick MathewsonOur zlib deflate objects require lots of memory per directory connectionCompressing descriptors on the fly requires a lot of memory with zlib's default settings. According to zconf.h:
```
/* The memory requirements for deflate are (in bytes):
(1 << (windowBits+2)) + (1 << (memLevel+9))
that i...Compressing descriptors on the fly requires a lot of memory with zlib's default settings. According to zconf.h:
```
/* The memory requirements for deflate are (in bytes):
(1 << (windowBits+2)) + (1 << (memLevel+9))
that is: 128K for windowBits=15 + 128K for memLevel = 8 (default values)
plus a few kilobytes for small objects.
```
We are using windowbits == 15 and memLevel == 8. This might explain in part why busy directories are so memory-hungry. In addition to our investigations for legacy/trac#11787, we should see whether we can safely reduce this to 32K or so with windowBits == 12 and memlevel == 5. It appears in preliminary investigation that this compression level would not hurt compression very much (0-5% for microdescs, 3-7% for server descriptors).
We could also choose our window size and memlevel based on current memory availability.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11792Consider directory connections zlib buffers when handling OOM2020-06-27T14:03:01ZNick MathewsonConsider directory connections zlib buffers when handling OOMOur current OOM handler code looks at edge connections and circuit queues when deciding whether to declare OOM and when finding circuits to kill. It should also consider killing directory connections, and consider the total allocation f...Our current OOM handler code looks at edge connections and circuit queues when deciding whether to declare OOM and when finding circuits to kill. It should also consider killing directory connections, and consider the total allocation for zlib compression objects.
See also legacy/trac#11791Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11824tor_zlib_process fails when trying to finish with no input or output bytes.2020-06-27T14:03:01ZNick Mathewsontor_zlib_process fails when trying to finish with no input or output bytes.zlib reports Z_BUF_ERROR when it is out of input or out of output. Currently, we handle that with:
```
case Z_BUF_ERROR:
if (state->stream.avail_in == 0)
return TOR_ZLIB_OK;
return TOR_ZLIB_BUF_FULL;
```
But tha...zlib reports Z_BUF_ERROR when it is out of input or out of output. Currently, we handle that with:
```
case Z_BUF_ERROR:
if (state->stream.avail_in == 0)
return TOR_ZLIB_OK;
return TOR_ZLIB_BUF_FULL;
```
But that's wrong -- if avail_in is 0, but finish is set, then we are trying to finalize the stream, and we really do have something to write. That test should be `state->stream.avail_in == 0 && !finish`)
Marking this for 0.2.5 even though I am pretty sure this can never actually happen with the way write_to_buf_zlib works: write_to_buf_zlib ensures that we are never trying to write into a completely empty buffer, and zlib says "Z_OK" if you give it even one byte to write into.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12061Support logging to named pipes2020-06-27T14:02:59ZNick MathewsonSupport logging to named pipesWouldn't it be nice to be able to say "Log debug /path/to/a/pipe" ?
See thread beginning at https://lists.torproject.org/pipermail/tor-dev/2014-April/006687.html , which eventually yielded some analysis, and even a possible patch.
[Mak...Wouldn't it be nice to be able to say "Log debug /path/to/a/pipe" ?
See thread beginning at https://lists.torproject.org/pipermail/tor-dev/2014-April/006687.html , which eventually yielded some analysis, and even a possible patch.
[Making a ticket so this doesn't get lost]Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12093MyFamily does not accept fingerprints unless preceeded by $, unlike every oth...2020-06-27T14:02:58Zs7rMyFamily does not accept fingerprints unless preceeded by $, unlike every other optionMyFamily does not accept fingerprints unless preceeded by $, unlike every other option.
Specifying the relays in the family via nickname causes problems as tor does not expand nicknames to fingerprints if relays have Unnamed flag, prev...MyFamily does not accept fingerprints unless preceeded by $, unlike every other option.
Specifying the relays in the family via nickname causes problems as tor does not expand nicknames to fingerprints if relays have Unnamed flag, preventing family to be properly declared.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12194rend_client_note_connection_attempt_ended() gets called redundantly2020-06-27T14:02:56ZAndrea Shepardrend_client_note_connection_attempt_ended() gets called redundantlyWhen hidden service connection attempts fail, rend_client_note_connection_attempt_ended() can get called once from connection_mark_unattached_ap() and then again from rend_client_desc_trynow() after it returns. See the log snippet in le...When hidden service connection attempts fail, rend_client_note_connection_attempt_ended() can get called once from connection_mark_unattached_ap() and then again from rend_client_desc_trynow() after it returns. See the log snippet in legacy/trac#10616 for an example.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12202Refactor: Improve interface of `entry_is_live`2020-06-27T14:02:55ZGeorge KadianakisRefactor: Improve interface of `entry_is_live``entry_is_live()` checks whether a given entry guard can be used. It accepts as arguments a couple of flags that we might want the entry guard to have.
Its signature is:
```
static INLINE const node_t *
entry_is_live(const entry_guard_t...`entry_is_live()` checks whether a given entry guard can be used. It accepts as arguments a couple of flags that we might want the entry guard to have.
Its signature is:
```
static INLINE const node_t *
entry_is_live(const entry_guard_t *e, int need_uptime, int need_capacity,
int assume_reachable, int need_descriptor, const char **msg)
```
Which results in calls like this:
```
if (entry_is_live(entry, 0, 1, 0, !for_directory, &msg))
```
```
if (entry_is_live(e, 0, 1, 0, 0, &msg))
```
```
const node_t *r = entry_is_live(entry, 0, 1, 0, 0, &live_msg);
```
It would probably be better if we turn those boolean flags into a bitstring (maybe similar to `router_crn_flags_t`), so that the calls are more readable.
This is just code refactoring and should result in no behavior changes.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12205Document magic numbers at entry_is_time_to_retry()2020-06-27T14:02:55ZGeorge KadianakisDocument magic numbers at entry_is_time_to_retry()```
if (diff < 6*60*60)
return now > (e->last_attempted + 60*60);
else if (diff < 3*24*60*60)
return now > (e->last_attempted + 4*60*60);
else if (diff < 7*24*60*60)
return now > (e->last_attempted + 18*60*60);
else
...```
if (diff < 6*60*60)
return now > (e->last_attempted + 60*60);
else if (diff < 3*24*60*60)
return now > (e->last_attempted + 4*60*60);
else if (diff < 7*24*60*60)
return now > (e->last_attempted + 18*60*60);
else
return now > (e->last_attempted + 36*60*60);
}
```
This is our entry guard retry logic. We should probably document these numbers, so that they look less magic.Tor: 0.2.6.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/12206Switch to one guard per client2020-06-27T14:02:55ZGeorge KadianakisSwitch to one guard per clientWe should switch to one guard per client as per proposal 236.We should switch to one guard per client as per proposal 236.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12207Improve unittest coverage of entrynodes.c2020-06-27T14:02:55ZGeorge KadianakisImprove unittest coverage of entrynodes.c`entrynodes.c` is not very well tested unfortunately. Only 2% of it is.
As part of the legacy/trac#11480 adventures, we should aim to write some more unit tests.
I'm planning to try to write at least unit tests for `choose_random_entry...`entrynodes.c` is not very well tested unfortunately. Only 2% of it is.
As part of the legacy/trac#11480 adventures, we should aim to write some more unit tests.
I'm planning to try to write at least unit tests for `choose_random_entry_impl()`, which is one of the stars of `entrynodes.c`.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12219Clean dead code from entrynodes.c2020-06-27T14:02:55ZGeorge KadianakisClean dead code from entrynodes.cI see dead code in `entrynodes.c`.
There are three blocks of `#if 0` code. One of them is particularly annoying because it's in the middle of `choose_random_entry_impl()` which is an important function, and it makes it harder to read.
...I see dead code in `entrynodes.c`.
There are three blocks of `#if 0` code. One of them is particularly annoying because it's in the middle of `choose_random_entry_impl()` which is an important function, and it makes it harder to read.
I would say that all dead code needs to go to the graveyard (git history in our case).
(We **might** want to keep the dead code in `control_event_guard_deferred()`, which is currently a NOP, just to show what that function used to be.)Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12226Make Strict{Entry,Exit}Nodes obsolete, rather than synonym for StrictNodes?2020-06-27T14:02:54ZRoger DingledineMake Strict{Entry,Exit}Nodes obsolete, rather than synonym for StrictNodes?Right now if you type "StrictExitNodes 1" you quietly get the behavior that a) this line is ignored for your ExitNodes selection, but b) if you set ExcludeNodes then it interprets it fanatically.
Since StrictExitNodes and StrictEntryNod...Right now if you type "StrictExitNodes 1" you quietly get the behavior that a) this line is ignored for your ExitNodes selection, but b) if you set ExcludeNodes then it interprets it fanatically.
Since StrictExitNodes and StrictEntryNodes have been non-functional in this way for a while, should we make them OBSOLETE() rather than a synonym for a different (albeit similar sounding) config option?Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12376Refactor and unit-test all the code that looks at network interfaces to get c...2021-09-16T14:35:28Zrl1987Refactor and unit-test all the code that looks at network interfaces to get current IPRight now Tor has large hairy functions such as `get_interface_address6()` and `get_interface_addresses_raw()` that attempt to use system-specific API to try and get an IP address of network interface Tor instance is currently using. The...Right now Tor has large hairy functions such as `get_interface_address6()` and `get_interface_addresses_raw()` that attempt to use system-specific API to try and get an IP address of network interface Tor instance is currently using. They should be refactored to improve code readability and maintainability. Also, we need to make sure there are unit tests for this kind of code.Tor: 0.2.6.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/12392Avoid double-backslash in windows tempdir path2020-06-27T14:02:53ZNick MathewsonAvoid double-backslash in windows tempdir pathSee patch from Gisle Vanem at https://lists.torproject.org/pipermail/tor-dev/2014-June/006943.html
I would like to take this in 0.2.6, tweaking the code to act correctly if for some reason GetTempDirA doesn't do what it's specified to d...See patch from Gisle Vanem at https://lists.torproject.org/pipermail/tor-dev/2014-June/006943.html
I would like to take this in 0.2.6, tweaking the code to act correctly if for some reason GetTempDirA doesn't do what it's specified to do, or in case some weird version of windows says that the tempdir is \ or something.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12434Clean up the PT spec2020-06-27T14:02:52ZGeorge KadianakisClean up the PT specWhile the PT spec is not terrible, it's certainly a bit of a mess.
It contains unimplemented stuff that will probably never get implemented. It's all a big blob of text and it doesn't have any sections. It doesn't say anything about Ext...While the PT spec is not terrible, it's certainly a bit of a mess.
It contains unimplemented stuff that will probably never get implemented. It's all a big blob of text and it doesn't have any sections. It doesn't say anything about ExtORPort.
Also, other projects (I2P, psiphon, lantern, uproxy, etc.) want to use these 'Pluggable Transport' things, but they don't like how our pt-spec.txt is Tor specific. We should probably split our current pt-spec.txt to a tor-pt-spec.txt and to a platform-independent pt-spec.txt (that might or might not reside in gitweb.tpo). This is related to legacy/trac#10629.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12439Threading should be required2020-06-27T14:02:52ZNick MathewsonThreading should be requiredLong ago we supported systems where there was no support for threads, or where the threading library was broken. We shouldn't have do that any more: on every OS that matters, threads exist, and the OS supports running threads across mul...Long ago we supported systems where there was no support for threads, or where the threading library was broken. We shouldn't have do that any more: on every OS that matters, threads exist, and the OS supports running threads across multiple CPUs.
This change would make our improved workqueue code much easier.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12463Missing ciphersuite in tor spec2020-06-27T14:02:51ZcypherpunksMissing ciphersuite in tor specOn line 162-164 the tor-spec document mentions:
```
implementations MUST support the SSLv3 ciphersuite
"SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA", and SHOULD support the TLS
ciphersuite "TLS_DHE_RSA_WITH_AES_128_CBC_SHA" if it is available.
``...On line 162-164 the tor-spec document mentions:
```
implementations MUST support the SSLv3 ciphersuite
"SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA", and SHOULD support the TLS
ciphersuite "TLS_DHE_RSA_WITH_AES_128_CBC_SHA" if it is available.
```
The rest of the document mentions SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA and **TLS_DHE_RSA_WITH_AES_256_CBC_SHA**.
PS: Is there a Tor-spec component? I could not find it, so Tor component with keyword spec.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12464When Tor 0.2.6.x is closer to done, profile relays running Tor 0.2.6.x and op...2020-06-27T14:02:51ZNick MathewsonWhen Tor 0.2.6.x is closer to done, profile relays running Tor 0.2.6.x and optimize accordinglySee legacy/trac#11332 for the ticket where we did this in 0.2.5, for experience and ideas.See legacy/trac#11332 for the ticket where we did this in 0.2.5, for experience and ideas.Tor: 0.2.6.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/12485Reduce time to write guard-related changes to the state file2020-06-27T14:02:50ZGeorge KadianakisReduce time to write guard-related changes to the state fileWe have:
```
void
entry_guards_changed(void)
{
time_t when;
entry_guards_dirty = 1;
/* or_state_save() will call entry_guards_update_state(). */
when = get_options()->AvoidDiskWrites ? time(NULL) + 3600 : time(NULL)+600;
or_st...We have:
```
void
entry_guards_changed(void)
{
time_t when;
entry_guards_dirty = 1;
/* or_state_save() will call entry_guards_update_state(). */
when = get_options()->AvoidDiskWrites ? time(NULL) + 3600 : time(NULL)+600;
or_state_mark_dirty(get_or_state(), when);
}
```
Which means that Tor saves guard-related changes to the state file after 10 minutes, or 1 hour if `AvoidDiskWrites` is enabled.
Maybe this time should be reduced, since we are considering guard-related changes as quite important? It would be a pity to settle on a guard node, then close the Tor client fast and lose that information.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12497Write a proposal for how to change the list of private addresses2020-10-05T16:18:27ZAndrea ShepardWrite a proposal for how to change the list of private addressesThere are problems if clients and nodes disagree about which addresses are private; if a client requests an address from a node and the node thinks it's private and rejects it, but the address is not blacklisted in the node's exit policy...There are problems if clients and nodes disagree about which addresses are private; if a client requests an address from a node and the node thinks it's private and rejects it, but the address is not blacklisted in the node's exit policy, the client will falsely reject the exit as misbehaving. We need a proposal to handle this in such a way as to let us update the list of private addresses for such tickets as legacy/trac#7971 without breaking things.Tor: 0.2.6.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12503fgets test gets skipped2020-06-27T14:02:50Zcypherpunksfgets test gets skippedThe test for how fgets handles non-blocking pipes is skipped because it apparently fails.
Included are two patches for consideration;
* 0001 fixes the test by checking its behavior as discussed in legacy/trac#1903, legacy/trac#2045, and...The test for how fgets handles non-blocking pipes is skipped because it apparently fails.
Included are two patches for consideration;
* 0001 fixes the test by checking its behavior as discussed in legacy/trac#1903, legacy/trac#2045, and described by the C99 and C11 standards.
* 0002 uses the test_* macros which the majority of the other tests use. I'm not sure if the tt_* or the test_* functions are preferred.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12509Setting an option clears addressmappings, automapped addresses2020-06-27T14:02:50ZTracSetting an option clears addressmappings, automapped addressesstarting tor with:
tor --DNSPort 9053 --Log "notice syslog" --CookieAuthentication 1
then running:
echo -e 'Authenticate '$(cat /var/tor/control_auth_cookie | xxd -p | tr -d '\n')'\n''SetConf Log="notice syslog"' | ncat 127.0.0.1 ...starting tor with:
tor --DNSPort 9053 --Log "notice syslog" --CookieAuthentication 1
then running:
echo -e 'Authenticate '$(cat /var/tor/control_auth_cookie | xxd -p | tr -d '\n')'\n''SetConf Log="notice syslog"' | ncat 127.0.0.1 9051
clears all addressmappings and makes queries to DNSPort stop responding with automapped addresses.
**Trac**:
**Username**: epochTor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12560Duplicate calls to mark_for_close, both at directory.c:36772020-06-27T14:02:48ZTracDuplicate calls to mark_for_close, both at directory.c:3677[dim. juil. 6 16:47:45 2014] Erreur du programme Tor - Le programme Tor a rencontré une erreur interne. Merci de transmettre le message d'erruer suivant aux développeurs de Tor à bugs.torproject.org: "connection_mark_for_close_internal_(...[dim. juil. 6 16:47:45 2014] Erreur du programme Tor - Le programme Tor a rencontré une erreur interne. Merci de transmettre le message d'erruer suivant aux développeurs de Tor à bugs.torproject.org: "connection_mark_for_close_internal_(): Bug: Duplicate call to connection_mark_for_close at src/or/directory.c:3677 (first at src/or/directory.c:3677)
"\n
**Trac**:
**Username**: BuckmasterTor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12573Dirauths should only assign the HSDir flag to valid relays2020-06-27T14:02:48ZMatthew FinkelDirauths should only assign the HSDir flag to valid relaysCurrently directory authorities assign the HSDir flag to relays if they:
- want to be a HSDir (default)
- are configured to be a relay
- have been up long enough
- are running
These criteria should be augmented and include that the ...Currently directory authorities assign the HSDir flag to relays if they:
- want to be a HSDir (default)
- are configured to be a relay
- have been up long enough
- are running
These criteria should be augmented and include that the relay is valid (or not invalid).Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12585Implement new option SocksSocket2020-06-27T14:02:47ZJacob AppelbaumImplement new option SocksSocketHi,
I've implemented a new way for client applications to speak to Tor. I wanted to lock down applications like web browsers to ensure that they cannot even make AF_INET or AF_INET6 sockets. There is one problem: all those clients need ...Hi,
I've implemented a new way for client applications to speak to Tor. I wanted to lock down applications like web browsers to ensure that they cannot even make AF_INET or AF_INET6 sockets. There is one problem: all those clients need AF_INET to talk to Tor! This patch fixes this issue - if a client is able to make an AF_UNIX socket and it talks to a Tor that supports AF_UNIX, it will be able to use SOCKS to connect to the internet.
I plan to write a patch to torsocks to implement this as a generic client. Later, I suspect we can add support to other applications very easily and then we can lock down those applications or even entire unix uids from being able to make AF_INET/AF_INET6 sockets.
This helps us with AppArmor like issues - AppArmor doesn't have the ability to permit traffic to 127.0.0.1:9050 and to deny it for other addresses. With this implementation, we can simply deny all AF_INET and the application can still communicate with Tor as long as it has AF_UNIX permissions.
This also helps us with iptables issues - there are no generally open TCP/IP sockets for anyone who is able to connect to (for example) 127.0.0.1:9050 - we can control who can read and write to the SocksSocket with unix uid/gid controls.
I've spent about two days testing (on Tails 1.0.1) these patches and loading it with the following configuration file:
```
Socks5Proxy 127.0.0.1:9050
WarnUnsafeSocks 0
SocksPort 0
Log debug stderr
SocksSocket /tmp/testing/SocksSocket
SocksSocket /tmp/testing/SocksSocket1
SocksSocket /tmp/testing/SocksSocket2
SocksSocket /tmp/testing/SocksSocket3
AvoidDiskWrites 1
```
I've been running it in valgrind like so:
```
valgrind --log-file=/tmp/SocksSocket-valgrind-005-with-three-SocksSockets.log -v --leak-check=full --track-origins=yes ./src/or/tor -f torrc.test
```
As I haven't yet implemented the torsocks client side of this, I've been using socat like so:
```
socat -v UNIX-CONNECT:/tmp/testing/SocksSocket TCP-LISTEN:6667,fork,RETRY,reuseaddr,end-close;
```
Finally, I use curl like so to fetch a web page through this totally convoluted mess of AF_*:
```
curl --socks5-hostname 127.0.0.1:6667 https://check.torproject.org;
```
Valgrind reports the following:
```
==15187== Memcheck, a memory error detector
==15187== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==15187== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==15187== Command: ./src/or/tor -f torrc.test
==15187== Parent PID: 29356
==15187==
--15187--
--15187-- Valgrind options:
--15187-- --suppressions=/usr/lib/valgrind/debian-libc6-dbg.supp
--15187-- --log-file=/tmp/SocksSocket-valgrind-005-with-three-SocksSockets.log
--15187-- -v
--15187-- --leak-check=full
--15187-- --track-origins=yes
--15187-- Contents of /proc/version:
--15187-- Linux version 3.14-1-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-2) ) #1 SMP Debian 3.14.5-1 (2014-06-05)
--15187-- Arch and hwcaps: X86, x86-sse1-sse2
--15187-- Page sizes: currently 4096, max supported 4096
--15187-- Valgrind library directory: /usr/lib/valgrind
--15187-- Reading syms from /home/amnesia/Persistent/src/tor/src/or/tor (0x108000)
--15187-- Reading syms from /lib/ld-2.11.3.so (0x4400000)
--15187-- Considering /lib/ld-2.11.3.so ..
--15187-- .. CRC mismatch (computed 19231304 wanted 2b6c260a)
--15187-- Considering /usr/lib/debug/lib/ld-2.11.3.so ..
--15187-- .. CRC is valid
--15187-- Reading syms from /usr/lib/valgrind/memcheck-x86-linux (0x38000000)
--15187-- object doesn't have a dynamic symbol table
--15187-- Reading suppressions file: /usr/lib/valgrind/debian-libc6-dbg.supp
--15187-- Reading suppressions file: /usr/lib/valgrind/default.supp
--15187-- REDIR: 0x4416490 (index) redirected to 0x3803eda3 (vgPlain_x86_linux_REDIR_FOR_index)
--15187-- Reading syms from /usr/lib/valgrind/vgpreload_core-x86-linux.so (0xabcb000)
--15187-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so (0xabd1000)
==15187== WARNING: new redirection conflicts with existing -- ignoring it
--15187-- new: 0x04416490 (index ) R-> 0x0abd4cb0 index
--15187-- REDIR: 0x4416670 (strlen) redirected to 0xabd50f0 (strlen)
--15187-- Reading syms from /usr/lib/libz.so.1.2.3.4 (0xccc3000)
--15187-- Considering /usr/lib/libz.so.1.2.3.4 ..
--15187-- .. CRC mismatch (computed 7be92cfa wanted 329326cb)
--15187-- object doesn't have a symbol table
--15187-- Reading syms from /lib/libm-2.11.3.so (0xccdf000)
--15187-- Considering /lib/libm-2.11.3.so ..
--15187-- .. CRC mismatch (computed 0116a1b2 wanted cca4fc2f)
--15187-- Considering /usr/lib/debug/lib/libm-2.11.3.so ..
--15187-- .. CRC is valid
--15187-- Reading syms from /usr/lib/libevent-1.4.so.2.1.3 (0xcd09000)
--15187-- object doesn't have a symbol table
--15187-- Reading syms from /usr/lib/i686/cmov/libssl.so.0.9.8 (0xcd20000)
--15187-- Considering /usr/lib/i686/cmov/libssl.so.0.9.8 ..
--15187-- .. CRC mismatch (computed 7cd446f3 wanted 6aaecd6b)
--15187-- object doesn't have a symbol table
--15187-- Reading syms from /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xcd70000)
--15187-- Considering /usr/lib/i686/cmov/libcrypto.so.0.9.8 ..
--15187-- .. CRC mismatch (computed a803f391 wanted 934b1db6)
--15187-- object doesn't have a symbol table
--15187-- Reading syms from /lib/librt-2.11.3.so (0xcecd000)
--15187-- Considering /lib/librt-2.11.3.so ..
--15187-- .. CRC mismatch (computed 11db8d18 wanted 4837ea6c)
--15187-- Considering /usr/lib/debug/lib/librt-2.11.3.so ..
--15187-- .. CRC is valid
--15187-- Reading syms from /lib/libdl-2.11.3.so (0xceda000)
--15187-- Considering /lib/libdl-2.11.3.so ..
--15187-- .. CRC mismatch (computed 3740dd8b wanted 09c06eb3)
--15187-- Considering /usr/lib/debug/lib/libdl-2.11.3.so ..
--15187-- .. CRC is valid
--15187-- Reading syms from /lib/libc-2.11.3.so (0xcede000)
--15187-- Considering /lib/libc-2.11.3.so ..
--15187-- .. CRC mismatch (computed 4ef5e22d wanted 481f3942)
--15187-- Considering /usr/lib/debug/lib/libc-2.11.3.so ..
--15187-- .. CRC is valid
--15187-- Reading syms from /lib/libpthread-2.11.3.so (0xd027000)
--15187-- Considering /lib/libpthread-2.11.3.so ..
--15187-- .. CRC mismatch (computed d08a9725 wanted 0065618d)
--15187-- Considering /usr/lib/debug/lib/libpthread-2.11.3.so ..
--15187-- .. CRC is valid
--15187-- Reading syms from /lib/libnsl-2.11.3.so (0xd040000)
--15187-- Considering /lib/libnsl-2.11.3.so ..
--15187-- .. CRC mismatch (computed 65a29afd wanted f8853f76)
--15187-- Considering /usr/lib/debug/lib/libnsl-2.11.3.so ..
--15187-- .. CRC is valid
--15187-- Reading syms from /lib/libresolv-2.11.3.so (0xd05b000)
--15187-- Considering /lib/libresolv-2.11.3.so ..
--15187-- .. CRC mismatch (computed 66a703f9 wanted 6378a0ac)
--15187-- Considering /usr/lib/debug/lib/libresolv-2.11.3.so ..
--15187-- .. CRC is valid
--15187-- REDIR: 0xcf50950 (index) redirected to 0xabd4c20 (index)
--15187-- REDIR: 0xcf52750 (memchr) redirected to 0xabd5830 (memchr)
--15187-- REDIR: 0xcf513f0 (rindex) redirected to 0xabd4b60 (rindex)
--15187-- REDIR: 0xcf51040 (strlen) redirected to 0xabd50b0 (strlen)
--15187-- REDIR: 0xcf4d7c0 (malloc) redirected to 0xabd3ecb (malloc)
--15187-- REDIR: 0xcf52ed0 (memcpy) redirected to 0xabd5870 (memcpy)
--15187-- REDIR: 0xcf55830 (strchrnul) redirected to 0xabd6590 (strchrnul)
--15187-- REDIR: 0xcf4d6e0 (free) redirected to 0xabd3ae5 (free)
--15187-- REDIR: 0xcf52a20 (mempcpy) redirected to 0xabd6600 (mempcpy)
--15187-- REDIR: 0xcf4ced0 (calloc) redirected to 0xabd31af (calloc)
--15187-- Reading syms from /lib/libgcc_s.so.1 (0xd483000)
--15187-- Considering /lib/libgcc_s.so.1 ..
--15187-- .. CRC mismatch (computed 5efc9915 wanted ece5a7a0)
--15187-- object doesn't have a symbol table
--15187-- REDIR: 0xcf4e760 (realloc) redirected to 0xabd3f7a (realloc)
--15187-- REDIR: 0xcf51230 (strncmp) redirected to 0xabd55d0 (strncmp)
--15187-- REDIR: 0xcf52bd0 (stpcpy) redirected to 0xabd6120 (stpcpy)
--15187-- REDIR: 0xcf51310 (strncpy) redirected to 0xabd52f0 (strncpy)
--15187-- REDIR: 0xcf50ac0 (strcmp) redirected to 0xabd56b0 (strcmp)
--15187-- REDIR: 0xcf529c0 (memset) redirected to 0xabd64a0 (memset)
--15187-- REDIR: 0xcf50b40 (strcpy) redirected to 0xabd5130 (strcpy)
--15187-- REDIR: 0xcf55760 (rawmemchr) redirected to 0xabd65c0 (rawmemchr)
--15187-- REDIR: 0xcf52910 (memmove) redirected to 0xabd6510 (memmove)
--15187-- REDIR: 0xcfbc620 (__memcpy_chk) redirected to 0xabd69b0 (__memcpy_chk)
==15187== Conditional jump or move depends on uninitialised value(s)
==15187== at 0x1E8C04: connection_ap_expire_beginning (connection_edge.c:600)
==15187== by 0x13669D: second_elapsed_callback (main.c:1501)
==15187== by 0x25E572: periodic_timer_cb (compat_libevent.c:538)
==15187== by 0xCD0EEE3: event_base_loop (in /usr/lib/libevent-1.4.so.2.1.3)
==15187== by 0x1318E0: do_main_loop (main.c:2028)
==15187== by 0x133BDC: tor_main (main.c:2998)
==15187== by 0x12F7D2: main (tor_main.c:30)
==15187== Uninitialised value was created by a stack allocation
==15187== at 0x1DE763: connection_handle_listener_read (connection.c:1454)
==15187==
--15187-- Discarding syms at 0xd485350-0xd49d738 in /lib/libgcc_s.so.1 due to munmap()
==15187==
==15187== HEAP SUMMARY:
==15187== in use at exit: 3,565 bytes in 29 blocks
==15187== total heap usage: 353,781 allocs, 353,752 frees, 85,358,749 bytes allocated
==15187==
==15187== Searching for pointers to 29 not-freed blocks
==15187== Checked 276,744 bytes
==15187==
==15187== LEAK SUMMARY:
==15187== definitely lost: 0 bytes in 0 blocks
==15187== indirectly lost: 0 bytes in 0 blocks
==15187== possibly lost: 0 bytes in 0 blocks
==15187== still reachable: 3,565 bytes in 29 blocks
==15187== suppressed: 0 bytes in 0 blocks
==15187== Reachable blocks (those to which a pointer was found) are not shown.
==15187== To see them, rerun with: --leak-check=full --show-reachable=yes
==15187==
==15187== ERROR SUMMARY: 660 errors from 1 contexts (suppressed: 37 from 12)
==15187==
==15187== 660 errors in context 1 of 1:
==15187== Conditional jump or move depends on uninitialised value(s)
==15187== at 0x1E8C04: connection_ap_expire_beginning (connection_edge.c:600)
==15187== by 0x13669D: second_elapsed_callback (main.c:1501)
==15187== by 0x25E572: periodic_timer_cb (compat_libevent.c:538)
==15187== by 0xCD0EEE3: event_base_loop (in /usr/lib/libevent-1.4.so.2.1.3)
==15187== by 0x1318E0: do_main_loop (main.c:2028)
==15187== by 0x133BDC: tor_main (main.c:2998)
==15187== by 0x12F7D2: main (tor_main.c:30)
==15187== Uninitialised value was created by a stack allocation
==15187== at 0x1DE763: connection_handle_listener_read (connection.c:1454)
==15187==
--15187--
--15187-- used_suppression: 37 dl-hack3-cond-1
==15187==
==15187== ERROR SUMMARY: 660 errors from 1 contexts (suppressed: 37 from 12)
```
I think that other than that single conditional jump in connection_ap_expire_beginning, there aren't any serious valgrind issues that are related to my patch. Though I admit, I'm not entirely sure of why that valgrind issue is showing up and I'm starting to dig into it now.
I've based my patch on 48d7fceee5e6041ccdd4316f51de0d6b5e1818ed; I'm happy to rebase it if that is useful.
Feedback is appreciated!Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12591Lcov coverage reports2020-06-27T14:02:47ZTracLcov coverage reportsI've implemented a makefile target to generate pretty html output as discussed from [0] on tor-dev. This target basically resets any coverage files, runs ./src/test/test (only) and then generates lcov's internal coverage report, followed...I've implemented a makefile target to generate pretty html output as discussed from [0] on tor-dev. This target basically resets any coverage files, runs ./src/test/test (only) and then generates lcov's internal coverage report, followed by genhtml's HTML coverage report. I've also added a stanza on using lcov via this make target to doc/HACKING.
The implementation of coverage diffs using lcov is something I'm investigating, and will post back here when I have further progress. Initially, i'll just implement the kludge the lcov mailing list via Nick suggests at [1].
[0]: https://lists.torproject.org/pipermail/tor-dev/2014-June/007005.html
[1]: https://lists.torproject.org/pipermail/tor-dev/2014-June/007035.html
Cheers,
daube
**Trac**:
**Username**: daubeTor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12597Make all relays directory servers2020-06-27T14:02:47ZGeorge KadianakisMake all relays directory serversDuring the entry guard discussions, we have decided that it's a good idea to make all relays directory servers. We mainly needed the entry guards to be directories, but it seems easier and more elegant to just turn all relays to director...During the entry guard discussions, we have decided that it's a good idea to make all relays directory servers. We mainly needed the entry guards to be directories, but it seems easier and more elegant to just turn all relays to directory servers.
This is easier nowadays than in the past because `BEGIN_DIR` makes it so that directory servers don't need to have a separate DirPort open. (However, maybe relays get the `V2Dir` flag only if they have a DirPort open?)
Also, since all relays have all the directory documents anyway, it doesn't further bloat their disk to become directory servers.
Putting this in 0.2.6, but probably deferrable.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12657"Tor has unexpectantly exited"2020-06-27T14:02:46Zcypherpunks"Tor has unexpectantly exited"Browser 3.6.2
OS-Win7-Ultimate/SP1
Win7 Firewall
no anti-virus
use bleachbit weekly
The Browser exits every couple of hours leaving a small window message stating "Tor has unexpectantly exited". Firewall on or off makes no difference. ...Browser 3.6.2
OS-Win7-Ultimate/SP1
Win7 Firewall
no anti-virus
use bleachbit weekly
The Browser exits every couple of hours leaving a small window message stating "Tor has unexpectantly exited". Firewall on or off makes no difference. Browser being actively used at the time or not, makes no difference.
LogFile:
7/14/2014 1:34:48 AM.380 [NOTICE] Opening Socks listener on 127.0.0.1:9150
7/14/2014 1:34:48 AM.380 [NOTICE] Pluggable transport proxy (fte exec Tor\PluggableTransports\fteproxy --managed) does not provide any needed transports and will not be launched.
7/14/2014 1:34:48 AM.380 [NOTICE] Pluggable transport proxy (obfs2,obfs3 exec Tor\PluggableTransports\obfsproxy managed) does not provide any needed transports and will not be launched.
7/14/2014 1:34:48 AM.380 [NOTICE] Pluggable transport proxy (flashproxy exec Tor\PluggableTransports\flashproxy-client --register :0 :9000) does not provide any needed transports and will not be launched.
7/14/2014 1:34:49 AM.390 [NOTICE] Bootstrapped 5%: Connecting to directory server.
7/14/2014 1:34:49 AM.390 [WARN] Problem bootstrapping. Stuck at 5%: Connecting to directory server. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 1; recommendation warn)
7/14/2014 1:34:58 AM.386 [NOTICE] We now have enough directory information to build circuits.
7/14/2014 1:34:58 AM.386 [NOTICE] Bootstrapped 80%: Connecting to the Tor network.
7/14/2014 1:34:58 AM.387 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 2; recommendation warn)
7/14/2014 1:34:59 AM.411 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 3; recommendation warn)
7/14/2014 1:34:59 AM.411 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 4; recommendation warn)
7/14/2014 1:34:59 AM.412 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 5; recommendation warn)
7/14/2014 1:34:59 AM.412 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 6; recommendation warn)
7/14/2014 1:34:59 AM.413 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 7; recommendation warn)
7/14/2014 1:34:59 AM.413 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 8; recommendation warn)
7/14/2014 1:34:59 AM.414 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 9; recommendation warn)
7/14/2014 1:34:59 AM.415 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 10; recommendation warn)
7/14/2014 1:34:59 AM.415 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 11; recommendation warn)
7/14/2014 1:34:59 AM.416 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 12; recommendation warn)
7/14/2014 1:34:59 AM.416 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 13; recommendation warn)
7/14/2014 1:35:00 AM.320 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 14; recommendation warn)
7/14/2014 1:35:01 AM.320 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 15; recommendation warn)
7/14/2014 1:35:02 AM.300 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 16; recommendation warn)
7/14/2014 1:35:03 AM.310 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 17; recommendation warn)
7/14/2014 1:35:04 AM.380 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 18; recommendation warn)
7/14/2014 1:35:05 AM.260 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 19; recommendation warn)
7/14/2014 1:35:06 AM.300 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 20; recommendation warn)
7/14/2014 1:35:07 AM.310 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 21; recommendation warn)
7/14/2014 1:35:08 AM.310 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 22; recommendation warn)
7/14/2014 1:35:09 AM.310 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 23; recommendation warn)
7/14/2014 1:35:10 AM.310 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 24; recommendation warn)
7/14/2014 1:35:11 AM.320 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 25; recommendation warn)
7/14/2014 1:35:12 AM.300 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 26; recommendation warn)
7/14/2014 1:35:13 AM.310 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 27; recommendation warn)
7/14/2014 1:35:14 AM.350 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 28; recommendation warn)
7/14/2014 1:35:15 AM.340 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 29; recommendation warn)
7/14/2014 1:35:16 AM.320 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 30; recommendation warn)
7/14/2014 1:35:17 AM.320 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 31; recommendation warn)
7/14/2014 1:35:18 AM.320 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 32; recommendation warn)
7/14/2014 1:35:19 AM.300 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 33; recommendation warn)
7/14/2014 1:35:20 AM.300 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 34; recommendation warn)
7/14/2014 1:35:21 AM.300 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 35; recommendation warn)
7/14/2014 1:35:22 AM.310 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 36; recommendation warn)
7/14/2014 1:35:23 AM.360 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 37; recommendation warn)
7/14/2014 1:35:24 AM.300 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 38; recommendation warn)
7/14/2014 1:35:25 AM.310 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 39; recommendation warn)
7/14/2014 1:35:51 AM.180 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 40; recommendation warn)
7/14/2014 1:35:52 AM.300 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 41; recommendation warn)
7/14/2014 1:35:53 AM.310 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 42; recommendation warn)
7/14/2014 1:35:54 AM.300 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 43; recommendation warn)
7/14/2014 1:35:55 AM.290 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 44; recommendation warn)
7/14/2014 1:35:56 AM.290 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 45; recommendation warn)
7/14/2014 1:36:22 AM.230 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 46; recommendation warn)
7/14/2014 1:36:23 AM.300 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 47; recommendation warn)
7/14/2014 1:36:24 AM.290 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 48; recommendation warn)
7/14/2014 1:36:25 AM.300 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 49; recommendation warn)
7/14/2014 1:36:26 AM.280 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 50; recommendation warn)
7/14/2014 1:36:27 AM.280 [WARN] Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 51; recommendation warn)
7/14/2014 1:36:53 AM.388 [NOTICE] Bootstrapped 85%: Finishing handshake with first hop.
7/14/2014 1:36:56 AM.619 [NOTICE] Bootstrapped 90%: Establishing a Tor circuit.
7/14/2014 1:37:17 AM.935 [WARN] Problem bootstrapping. Stuck at 90%: Establishing a Tor circuit. (CONNECTRESET; CONNECTRESET; count 52; recommendation warn)
7/14/2014 1:37:17 AM.935 [WARN] 1 connections have failed:
7/14/2014 1:37:17 AM.936 [WARN] 1 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in OPEN
7/14/2014 1:37:26 AM.347 [WARN] Problem bootstrapping. Stuck at 90%: Establishing a Tor circuit. (DONE; DONE; count 53; recommendation warn)
7/14/2014 1:37:26 AM.347 [WARN] 2 connections have failed:
7/14/2014 1:37:26 AM.347 [WARN] 1 connections died in state handshaking (TLS) with SSL state SSLv2/v3 read server hello A in HANDSHAKE
7/14/2014 1:37:26 AM.347 [WARN] 1 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in OPEN
7/14/2014 1:37:42 AM.886 [NOTICE] Pluggable transport proxy (fte exec Tor\PluggableTransports\fteproxy --managed) does not provide any needed transports and will not be launched.
7/14/2014 1:37:42 AM.886 [NOTICE] Pluggable transport proxy (obfs2,obfs3 exec Tor\PluggableTransports\obfsproxy managed) does not provide any needed transports and will not be launched.
7/14/2014 1:37:42 AM.886 [NOTICE] Pluggable transport proxy (flashproxy exec Tor\PluggableTransports\flashproxy-client --register :0 :9000) does not provide any needed transports and will not be launched.
7/14/2014 1:37:42 AM.935 [NOTICE] Tor has successfully opened a circuit. Looks like client functionality is working.
7/14/2014 1:37:42 AM.935 [NOTICE] Bootstrapped 100%: Done.
7/14/2014 1:37:54 AM.290 [WARN] onion_skin_client_handshake failed.
7/14/2014 1:37:54 AM.290 [WARN] circuit_finish_handshake failed.
7/14/2014 1:37:54 AM.290 [WARN] connection_edge_process_relay_cell (at origin) failed.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12670HiddenServicePort TARGET IPv6 address2021-07-22T16:26:02ZgrarpampHiddenServicePort TARGET IPv6 addressThe man page HiddenServicePort does not say anything about TARGET being an IPv6 address. Since Tor is becoming IPv6 enabled it probably should (ie: ::1, and precedence). There are some combinations to consider supporting if not already d...The man page HiddenServicePort does not say anything about TARGET being an IPv6 address. Since Tor is becoming IPv6 enabled it probably should (ie: ::1, and precedence). There are some combinations to consider supporting if not already done (latter dependant on host if tor is not bound to both)...
4 -> TARGET 4
6 -> TARGET 6
4 -> TARGET 6
6 -> TARGET 4Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12690Raise the bandwidth threshold for being a guard2020-06-27T14:02:45ZGeorge KadianakisRaise the bandwidth threshold for being a guardFrom proposal236:
```
From dir-spec.txt:
"Guard" -- A router is a possible 'Guard' if its Weighted Fractional
Uptime is at least the median for "familiar" active routers, and if
its bandwidth is at least median or ...From proposal236:
```
From dir-spec.txt:
"Guard" -- A router is a possible 'Guard' if its Weighted Fractional
Uptime is at least the median for "familiar" active routers, and if
its bandwidth is at least median or at least 250KB/s.
When this proposal becomes effective, authorities should change the
bandwidth threshold for being a guard node to 2000KB/s instead of
250KB/s.
```Tor: 0.2.6.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12691does not build with clang2020-06-27T14:02:45Zweasel (Peter Palfrader)does not build with clangOn master, tor's test suite does not build with clang on i386. The 0.2.5.x tree is fine.
From https://jenkins.torproject.org/job/tor-ci-linux-master-clang/ARCHITECTURE=i386,SUITE=sid/6/console:
```
19:56:16 src/test/test_util.c:2407:13...On master, tor's test suite does not build with clang on i386. The 0.2.5.x tree is fine.
From https://jenkins.torproject.org/job/tor-ci-linux-master-clang/ARCHITECTURE=i386,SUITE=sid/6/console:
```
19:56:16 src/test/test_util.c:2407:13: error: implicit conversion loses integer precision: 'off_t' (aka 'long long') to 'long' [-Werror,-Wshorten-64-to-32]
19:56:16 tt_int_op(tor_fd_getpos(fd), ==, strlen(message));
19:56:16 ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
19:56:16 ./src/ext/tinytest_macros.h:158:22: note: expanded from macro 'tt_int_op'
19:56:16 tt_assert_test_type(a,b,#a" "#op" "#b,long,(val1_ op val2_), \
19:56:16 ^
19:56:16 ./src/ext/tinytest_macros.h:144:26: note: expanded from macro 'tt_assert_test_type'
19:56:16 tt_assert_test_fmt_type(a,b,str_test,type,test,type,fmt, \
19:56:16 ^
19:56:16 ./src/ext/tinytest_macros.h:116:16: note: expanded from macro 'tt_assert_test_fmt_type'
19:56:16 type val1_ = (a); \
19:56:16 ^
19:56:16 src/test/test_util.c:2409:16: error: implicit conversion loses integer precision: '__off64_t' (aka 'long long') to 'long' [-Werror,-Wshorten-64-to-32]
19:56:16 tt_int_op(st.st_size, ==, strlen(message));
19:56:16 ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
19:56:16 ./src/ext/tinytest_macros.h:158:22: note: expanded from macro 'tt_int_op'
19:56:16 tt_assert_test_type(a,b,#a" "#op" "#b,long,(val1_ op val2_), \
19:56:16 ^
19:56:16 ./src/ext/tinytest_macros.h:144:26: note: expanded from macro 'tt_assert_test_type'
19:56:16 tt_assert_test_fmt_type(a,b,str_test,type,test,type,fmt, \
19:56:16 ^
19:56:16 ./src/ext/tinytest_macros.h:116:16: note: expanded from macro 'tt_assert_test_fmt_type'
19:56:16 type val1_ = (a); \
19:56:16 ^
19:56:16 src/test/test_util.c:2413:13: error: implicit conversion loses integer precision: 'off_t' (aka 'long long') to 'long' [-Werror,-Wshorten-64-to-32]
19:56:16 tt_int_op(tor_fd_getpos(fd), ==, 0);
19:56:16 ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
19:56:16 ./src/ext/tinytest_macros.h:158:22: note: expanded from macro 'tt_int_op'
19:56:16 tt_assert_test_type(a,b,#a" "#op" "#b,long,(val1_ op val2_), \
19:56:16 ^
19:56:16 ./src/ext/tinytest_macros.h:144:26: note: expanded from macro 'tt_assert_test_type'
19:56:16 tt_assert_test_fmt_type(a,b,str_test,type,test,type,fmt, \
19:56:16 ^
19:56:16 ./src/ext/tinytest_macros.h:116:16: note: expanded from macro 'tt_assert_test_fmt_type'
19:56:16 type val1_ = (a); \
19:56:16 ^
19:56:16 src/test/test_util.c:2415:16: error: implicit conversion loses integer precision: '__off64_t' (aka 'long long') to 'long' [-Werror,-Wshorten-64-to-32]
19:56:16 tt_int_op(st.st_size, ==, 0);
19:56:16 ~~~~~~~~~~~~~^~~~~~~~~~~~~~~
19:56:16 ./src/ext/tinytest_macros.h:158:22: note: expanded from macro 'tt_int_op'
19:56:16 tt_assert_test_type(a,b,#a" "#op" "#b,long,(val1_ op val2_), \
19:56:16 ^
19:56:16 ./src/ext/tinytest_macros.h:144:26: note: expanded from macro 'tt_assert_test_type'
19:56:16 tt_assert_test_fmt_type(a,b,str_test,type,test,type,fmt, \
19:56:16 ^
19:56:16 ./src/ext/tinytest_macros.h:116:16: note: expanded from macro 'tt_assert_test_fmt_type'
19:56:16 type val1_ = (a); \
19:56:16 ^
19:56:16 src/test/test_util.c:2420:13: error: implicit conversion loses integer precision: 'off_t' (aka 'long long') to 'long' [-Werror,-Wshorten-64-to-32]
19:56:16 tt_int_op(tor_fd_getpos(fd), ==, strlen(message2));
19:56:16 ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
19:56:16 ./src/ext/tinytest_macros.h:158:22: note: expanded from macro 'tt_int_op'
19:56:16 tt_assert_test_type(a,b,#a" "#op" "#b,long,(val1_ op val2_), \
19:56:16 ^
19:56:16 ./src/ext/tinytest_macros.h:144:26: note: expanded from macro 'tt_assert_test_type'
19:56:16 tt_assert_test_fmt_type(a,b,str_test,type,test,type,fmt, \
19:56:16 ^
19:56:16 ./src/ext/tinytest_macros.h:116:16: note: expanded from macro 'tt_assert_test_fmt_type'
19:56:16 type val1_ = (a); \
19:56:16 ^
19:56:16 src/test/test_util.c:2422:16: error: implicit conversion loses integer precision: '__off64_t' (aka 'long long') to 'long' [-Werror,-Wshorten-64-to-32]
19:56:16 tt_int_op(st.st_size, ==, strlen(message2));
19:56:16 ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
19:56:16 ./src/ext/tinytest_macros.h:158:22: note: expanded from macro 'tt_int_op'
19:56:16 tt_assert_test_type(a,b,#a" "#op" "#b,long,(val1_ op val2_), \
19:56:16 ^
19:56:16 ./src/ext/tinytest_macros.h:144:26: note: expanded from macro 'tt_assert_test_type'
19:56:16 tt_assert_test_fmt_type(a,b,str_test,type,test,type,fmt, \
19:56:16 ^
19:56:16 ./src/ext/tinytest_macros.h:116:16: note: expanded from macro 'tt_assert_test_fmt_type'
19:56:16 type val1_ = (a); \
19:56:16 ^
19:56:16 6 errors generated.
```Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12693autoreconf 2.62 can't handle AS_VAR_IF in our configure.ac2020-06-27T14:02:45ZRoger Dingledineautoreconf 2.62 can't handle AS_VAR_IF in our configure.ac```
configure.ac:607: error: possibly undefined macro: AS_VAR_IF If this
token and others are legitimate, please use m4_pattern_allow. See the
Autoconf documentation.
autoreconf-2.62: /usr/local/bin/autoconf-2.62 failed with exit status:...```
configure.ac:607: error: possibly undefined macro: AS_VAR_IF If this
token and others are legitimate, please use m4_pattern_allow. See the
Autoconf documentation.
autoreconf-2.62: /usr/local/bin/autoconf-2.62 failed with exit status: 1
```
http://www.winehq.org/pipermail/wine-devel/2010-May/083662.html indicates that autoreconf 2.62 can't handle AS_VAR_IF.
We introduced AS_VAR_IF in two places in git commit 21ac2928 which went into Tor 0.2.5.2-alpha.
If this is easy to fix, it seems wise to do so -- we have some relays (including at least one directory authority) that are still on autoreconf 2.62.Tor: 0.2.6.x-finalJacob AppelbaumJacob Appelbaumhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12728Spaces mistakenly interpreted as part of MyFamily line2020-06-27T14:02:44ZRoger DingledineSpaces mistakenly interpreted as part of MyFamily lineIn config.c in check_nickname_list() we have
```
smartlist_split_string(sl, lst, ",",
SPLIT_SKIP_SPACE|SPLIT_IGNORE_BLANK|SPLIT_STRIP_SPACE, 0);
```
Then in router.c in router_rebuild_descriptor() we have
```
smartlist_split_s...In config.c in check_nickname_list() we have
```
smartlist_split_string(sl, lst, ",",
SPLIT_SKIP_SPACE|SPLIT_IGNORE_BLANK|SPLIT_STRIP_SPACE, 0);
```
Then in router.c in router_rebuild_descriptor() we have
```
smartlist_split_string(family, options->MyFamily, ",",
SPLIT_SKIP_SPACE|SPLIT_SKIP_SPACE|SPLIT_IGNORE_BLANK, 0);
```
Which one of these things is not like the other?
And do we have any other bugs like this?Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12751systemd unit file could use more filesystem namespace hardening options2020-06-27T14:02:43Zintrigerisystemd unit file could use more filesystem namespace hardening optionssystemd has nice features to restrict what part of the filesystem a service has read-only or read-write access to (ReadOnlyDirectories, ReadWriteDirectories) that we could use. Also InaccessibleDirectories could be made a bit more restri...systemd has nice features to restrict what part of the filesystem a service has read-only or read-write access to (ReadOnlyDirectories, ReadWriteDirectories) that we could use. Also InaccessibleDirectories could be made a bit more restrictive.Tor: 0.2.6.x-finalintrigeriintrigerihttps://gitlab.torproject.org/tpo/core/tor/-/issues/12752stem: Microdescript bandwidth considered unmeasured by default2020-06-27T14:02:43ZGeorge Kadianakisstem: Microdescript bandwidth considered unmeasured by defaultReading https://stem.torproject.org/api/descriptor/router_status_entry.html#stem.descriptor.router_status_entry.RouterStatusEntryMicroV3 gave me the impression that `measured` would contain the bandwidth referenced in microdescriptor con...Reading https://stem.torproject.org/api/descriptor/router_status_entry.html#stem.descriptor.router_status_entry.RouterStatusEntryMicroV3 gave me the impression that `measured` would contain the bandwidth referenced in microdescriptor consensuses (since AFAIK the bandwidth in consensuses is **measured**), however it seems that stem puts the bandwidth in `bandwidth` (considering it unmeasured):
The code of stem is here:
```
if w_key == "Bandwidth":
if not (w_value and w_value.isdigit()):
if not validate:
return
raise ValueError("%s 'Bandwidth=' entry needs to have a numeric value: w %s" % (desc._name(), value))
desc.bandwidth = int(w_value)
elif w_key == "Measured":
if not (w_value and w_value.isdigit()):
if not validate:
return
raise ValueError("%s 'Measured=' entry needs to have a numeric value: w %s" % (desc._name(), value))
desc.measured = int(w_value)
elif w_key == "Unmeasured":
if validate and w_value != "1":
raise ValueError("%s 'Unmeasured=' should only have the value of '1': w %s" % (desc._name(), value))
desc.is_unmeasured = True
else:
desc.unrecognized_bandwidth_entries.append(w_entry)
```
which basically saves stuff to `bandwidth` except if an explicit `Measured` appears which makes it save to `measured`. OTOH, Tor assumes measured by default, and only adds the `Unmeasured` string if it's not:
```
/* Now the weight line. */
if (rs_out.has_bandwidth) {
int unmeasured = rs_out.bw_is_unmeasured &&
consensus_method >= MIN_METHOD_TO_CLIP_UNMEASURED_BW;
smartlist_add_asprintf(chunks, "w Bandwidth=%d%s\n",
rs_out.bandwidth_kb,
unmeasured?" Unmeasured=1":"");
}
```
I think the correct fix here is to assume that microdedescriptor bandwidth is `measured`, except if the `Unmeasured=1` string is present.Tor: 0.2.6.x-finalSebastian HahnSebastian Hahn