Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2021-11-15T18:55:15Zhttps://gitlab.torproject.org/legacy/trac/-/issues/15545Document TOR_PT_EXIT_ON_STDIN_CLOSE in the pt-spec.2021-11-15T18:55:15ZYawning AngelDocument TOR_PT_EXIT_ON_STDIN_CLOSE in the pt-spec.This is the ticket for the documentation side of the `TOR_PT_EXIT_ON_STDIN_CLOSE` and associated behavior that was implemented as part of #15435.
`pt-spec.txt` needs to document that if the env var is set to `1`, then PTs should assume ...This is the ticket for the documentation side of the `TOR_PT_EXIT_ON_STDIN_CLOSE` and associated behavior that was implemented as part of #15435.
`pt-spec.txt` needs to document that if the env var is set to `1`, then PTs should assume that tor will keep stdin open, and to treat stdin being closed as the same as a `SIGTERM` (graceful shutdown immediately).Tor: 0.2.8.x-finalYawning AngelYawning Angelhttps://gitlab.torproject.org/legacy/trac/-/issues/11150Remove client code for connecting to and using 0.2.2 servers2020-07-31T12:53:28ZNick MathewsonRemove client code for connecting to and using 0.2.2 serversWe can finally drop support for the client-side V2 link handshake!We can finally drop support for the client-side V2 link handshake!Tor: 0.2.8.x-finalTvdWTvdWhttps://gitlab.torproject.org/legacy/trac/-/issues/14881incorrect defaults when producing bandwidth-weights line in directory footer2020-07-31T12:42:39ZRob Jansenincorrect defaults when producing bandwidth-weights line in directory footerWhen running Tor in small testing networks, much of the time the bandwidth-weights line does not appear in the directory-footer in the consensus files. The log file shows messages like this:
```
Consensus with empty bandwidth: G=852123 ...When running Tor in small testing networks, much of the time the bandwidth-weights line does not appear in the directory-footer in the consensus files. The log file shows messages like this:
```
Consensus with empty bandwidth: G=852123 M=0 E=0 D=569253 T=1421376
```
The code that counts up these bandwidth values is in `networkstatus_compute_consensus` in `dirvote.c`, specifically around [line 1590 in Tor master as of now](https://gitweb.torproject.org/tor.git/tree/src/or/dirvote.c#n1590).
The code that prints this error is in `networkstatus_compute_bw_weights_v10` in `dirvote.c`.
I believe that it is an error not to produce bandwidth-weights in the event that we have no knowledge of bandwidth for a given position. For example, if D is zero because there are no nodes that serve as exits+guards, shouldn't we just adjust the weights accordingly? We may still have functional guards and functional exits just because we have no node that serves as both.
Since this is for weighting purposes, why are T, D, E, G, and M all initialized to 0 instead of 1? I think the default weight should be 1, meaning all positions are selected equally, and any bandwidth above 1 should be used to increase the weight. Does this sound right?
If that is not desired, then I request that we at least initialize these values to one for testing networks. One patch is attached for each of these options.Tor: 0.3.0.x-finalpastlypastlyhttps://gitlab.torproject.org/legacy/trac/-/issues/12538Make all relays automatically be dir caches2020-06-13T18:13:30ZcypherpunksMake all relays automatically be dir cachesDuring 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.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17158Run an opt-in process for fallback directories2020-06-13T18:13:30ZteorRun an opt-in process for fallback directories
* Draft an email requesting that relay operators opt-in their ID and IP as a fallback directory
* Convince someone @ torproject.org to send the email to tor-relays
* someone @ torproject.org collates responses and adds them to the white...
* Draft an email requesting that relay operators opt-in their ID and IP as a fallback directory
* Convince someone @ torproject.org to send the email to tor-relays
* someone @ torproject.org collates responses and adds them to the whitelist
* Once we have enough whitelist entries, we merge the whitelisted fallback directories into the codeTor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/16792Have a way to mark lines as "unreachable by unit tests"2020-06-13T15:15:02ZNick MathewsonHave a way to mark lines as "unreachable by unit tests"It would be great to have a way to tell the test coverage code "this line won't be reached by tests, so don't worry about it." This would let us have a prayer of reaching 100%.It would be great to have a way to tell the test coverage code "this line won't be reached by tests, so don't worry about it." This would let us have a prayer of reaching 100%.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/15055Implement ed25519 link handshake2020-06-13T15:05:30ZNick MathewsonImplement ed25519 link handshakeIn #12498 , we implement a new identity key type. Now it's time to use it in a proper handshake as documented in proposal 220.In #12498 , we implement a new identity key type. Now it's time to use it in a proper handshake as documented in proposal 220.Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/15056Support ed25519 identities for circuit extension2020-06-13T15:04:05ZNick MathewsonSupport ed25519 identities for circuit extensionOnce #12498 is merged and #15055 is done, we can use ed25519 in circuit extension as documented in proposal 220.Once #12498 is merged and #15055 is done, we can use ed25519 in circuit extension as documented in proposal 220.Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/12595Finalize design for improved guard-node behavior2020-06-13T14:58:35ZGeorge KadianakisFinalize design for improved guard-node behaviorBugs like #12466 and #12450 have made it clear that the data structures and methods of the guard nodes code are not very robust. To fix those tickets with the current data structures, we would need even more kludges that would lower the ...Bugs like #12466 and #12450 have made it clear that the data structures and methods of the guard nodes code are not very robust. To fix those tickets with the current data structures, we would need even more kludges that would lower the code quality.
This is a ticket about finding a more elegant approach to keeping entry guards and directory guards.
I'm putting this in 0.2.6 milestone because it's important, but it might get deferred if it's too much work.Tor: 0.3.0.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/17153tor test networks should allow IPv6 private addresses2020-06-13T14:54:58Zteortor test networks should allow IPv6 private addresses`net/nodes/003br/notice.log:Sep 25 09:42:34.000 [warn] Unable to use configured IPv6 address "[::1]" in a descriptor. Skipping it. Try specifying a globally reachable address explicitly.`
I'm sure there's a tor option that allows privat...`net/nodes/003br/notice.log:Sep 25 09:42:34.000 [warn] Unable to use configured IPv6 address "[::1]" in a descriptor. Skipping it. Try specifying a globally reachable address explicitly.`
I'm sure there's a tor option that allows private addresses in descriptors for IPv4. It should do that for IPv6 as well.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/16861Pad Tor connections to collapse netflow records2020-06-13T14:54:41ZMike PerryPad Tor connections to collapse netflow recordsThe collection of traffic statistics from routers is quite common. Recently, there was a minor scandal when a University network administrator upstream of UtahStateExits (and UtahStateMeekBridge) posted that they had collected over 360G ...The collection of traffic statistics from routers is quite common. Recently, there was a minor scandal when a University network administrator upstream of UtahStateExits (and UtahStateMeekBridge) posted that they had collected over 360G of netflow records to boingboing:
https://lists.torproject.org/pipermail/tor-relays/2015-August/007575.html
Unfortunately, the comment has since disappeared, but the tor-relays archives preserve it.
This interested me, so I asked some questions about the defaults and record resolution, and did some additional searching. It turns out that Cisco IOS routers have an "inactive flow timeout" that by default is 15 seconds, and it can't be set lower than 10 seconds. What this timeout does is cause the router to emit a new netflow "record" for a connection that is idle for that long, even if it stays open. Several other routers have similar settings. The Fortinet default is also 15 seconds for this. For Juniper, it is also 30 seconds (but Juniper routers can set it as low as 4 seconds).
With this information, I decided to write a patch that sends padding on a client's Tor connection bidirectionally at a random interval that we can control from the consensus, with a default of 4s-14s. It only sends padding if the connection is idle. It does not pad connections that are used only for tunneled directory traffic.
It also gives us the ability to control how long we keep said connections open. Since the default netflow settings for Cisco also generate a record for active flows after 30 minutes, it doesn't make a whole lot of sense to pad beyond that point.
This should mean that the total overhead for this defense is very low, especially since we have recently moved to only one guard. Well under 50 bytes/second for at most 30 minutes.
I still have a few questions, though, which is why I put so many people in Cc to this ticket. I will put my questions in the first comment.Tor: 0.3.1.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/17076Improve coverage on src/or/config.c (options_validate)2020-06-13T14:53:30ZTracImprove coverage on src/or/config.c (options_validate)The changes are in the branch "options_test"
https://github.com/twstrike/tor_for_patching/tree/options_test
**Trac**:
**Username**: rjuniorThe changes are in the branch "options_test"
https://github.com/twstrike/tor_for_patching/tree/options_test
**Trac**:
**Username**: rjuniorTor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/15775Add IPv4 Fallback Directory List to tor, active by default2020-06-13T14:51:37ZteorAdd IPv4 Fallback Directory List to tor, active by defaultweasel writes on tor-dev:
Tor has included a feature to fetch the initial consensus from nodes
other than the authorities for a while now. We just haven't shipped a
list of alternate locations for clients to go to yet.
Reasons why we ...weasel writes on tor-dev:
Tor has included a feature to fetch the initial consensus from nodes
other than the authorities for a while now. We just haven't shipped a
list of alternate locations for clients to go to yet.
Reasons why we might want to ship tor with a list of additional places
where clients can find the consensus is that it makes authority
reachability and BW less important.
At the last Tor dev meeting we came up with a list of arbitrary
requirements that nodes should meet to be included in this list.
We want them to have been around and using their current key, address,
and port for a while now (120 days), and have been running, a guard, and
a v2 directory mirror for most of that time.
I have written a script to come up with a list of notes that match our
criteria. It's currently at
https://www.palfrader.org/volatile/fallback-dir/get-fallback-dir-candidates
It currently produces
https://www.palfrader.org/volatile/2015-04-17-VjBkc8DWV8c/list
See https://lists.torproject.org/pipermail/tor-dev/2015-April/008674.html
This file current has 329 entries, and takes up approximately 32kB.
If we hard-coded it in the binary like the authorities, it would increase the binary size by approximately 2% on my platform.
Edit: nickm favours putting it in `torrc.defaults`
Edit 2: weasel notes `torrc.defaults` is for package maintainers. Putting it in a list of strings in the code. Much like the authorities.
Do we expect this in by 0.2.7?
Edit: Yes
Do we want to work on a signed file first (#15774)?
(A signed file needs a well-defined threat model and signature verification has to work without access to the authorities or fallback directories.)
Edit: No clear threat model, defer.Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/3199Refactor periodic events2020-06-13T14:51:07ZNick MathewsonRefactor periodic eventsRight now we invoke a truly huge array of things from second_elapsed_callback() and run_scheduled_events(). There are at least 23 separate static time_t values that we do a comparison against every time a second elapses.
This is a real...Right now we invoke a truly huge array of things from second_elapsed_callback() and run_scheduled_events(). There are at least 23 separate static time_t values that we do a comparison against every time a second elapses.
This is a really goofy way to handle periodic events. Let's refactor this to instead use libevent's timing code. In addition, we could make the timers first-class, so as to allow better introspection of Tor's status wrt each timer.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17183Add exit-policy/reject-private so stem can discover ExitPolicyRejectPrivate r...2020-06-13T14:51:06ZteorAdd exit-policy/reject-private so stem can discover ExitPolicyRejectPrivate rulesAdd controller getinfo exit-policy/reject-private for the reject rules added by ExitPolicyRejectPrivate. This makes it easier for stem to display exit policies. Add unit tests for getinfo exit-policy/*.Add controller getinfo exit-policy/reject-private for the reject rules added by ExitPolicyRejectPrivate. This makes it easier for stem to display exit policies. Add unit tests for getinfo exit-policy/*.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17223tortls.c compile errors on git master/current2020-06-13T14:49:48ZTractortls.c compile errors on git master/currentHi,
On NetBSD 6_Stable (i386) compiling against openssl git master/current,
I have been receiving the following errors for a couple of days:
CC src/common/tortls.o
In file included from src/common/tortls.c:75:0:
src/common/tor...Hi,
On NetBSD 6_Stable (i386) compiling against openssl git master/current,
I have been receiving the following errors for a couple of days:
CC src/common/tortls.o
In file included from src/common/tortls.c:75:0:
src/common/tortls.h:139:15: error: conflicting types for 'SSL_SESSION_get_master_key'
/usr/local/ssl/include/openssl/ssl.h:1658:15: note: previous declaration of 'SSL_SESSION_get_master_key' was here
src/common/tortls.c: In function 'log_cert_lifetime':
src/common/tortls.c:2139:3: warning: passing argument 1 of 'X509_get_notBefore' discards qualifiers from pointer target type
/usr/local/ssl/include/openssl/x509.h:694:13: note: expected 'struct X509 *' but argument is of type 'const struct X509 *'
src/common/tortls.c:2147:3: warning: passing argument 1 of 'X509_get_notAfter' discards qualifiers from pointer target type
/usr/local/ssl/include/openssl/x509.h:696:12: note: expected 'struct X509 *' but argument is of type 'const struct X509 *'
src/common/tortls.c: In function 'check_cert_lifetime_internal':
src/common/tortls.c:2309:3: warning: passing argument 1 of 'X509_get_notBefore' discards qualifiers from pointer target type
/usr/local/ssl/include/openssl/x509.h:694:13: note: expected 'struct X509 *' but argument is of type 'const struct X509 *'
src/common/tortls.c:2314:3: warning: passing argument 1 of 'X509_get_notAfter' discards qualifiers from pointer target type
/usr/local/ssl/include/openssl/x509.h:696:12: note: expected 'struct X509 *' but argument is of type 'const struct X509 *'
src/common/tortls.c: At top level:
src/common/tortls.h:139:15: warning: 'SSL_SESSION_get_master_key' used but never defined
Makefile:3222: recipe for target 'src/common/tortls.o' failed
gmake[1]: *** [src/common/tortls.o] Error 1
gmake[1]: Leaving directory '/usr/local/src/tor'
Makefile:1855: recipe for target 'all' failed
gmake: *** [all] Error 2
I understand maintaining sync (tor/openssl - master branches) is not the
primary concern of the effort, but thought I would bring this to your attention.
--gene
**Trac**:
**Username**: yancmTor: 0.2.8.x-finalYawning AngelYawning Angelhttps://gitlab.torproject.org/legacy/trac/-/issues/17188Tor should warn users when traveling backwards through time2020-06-13T14:49:41ZTracTor should warn users when traveling backwards through timeAn attacker can do evil things by rewinding a user's clock, without having to own their machine (e.g., NTP attacks).
Tor maintains a monotonic clock to prevent rewinding attacks while Tor is running. Tor also keeps some persistent info...An attacker can do evil things by rewinding a user's clock, without having to own their machine (e.g., NTP attacks).
Tor maintains a monotonic clock to prevent rewinding attacks while Tor is running. Tor also keeps some persistent information about the user's time in the state file, in the LastWritten field.
On launch, if Tor sees that the system time has been rewound to before the LastWritten time, it should warn the user that something strange is happening. However, Tor should not update the monotonic clock or fail to launch, since the user may have changed the time deliberately.
**Trac**:
**Username**: hdevalenceTor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17085Improve coverage on src/common/util_process.c2020-06-13T14:49:13ZTracImprove coverage on src/common/util_process.cThe changes are in the branch "util_process_tests"
https://github.com/twstrike/tor_for_patching/tree/util_process_tests
**Trac**:
**Username**: rjuniorThe changes are in the branch "util_process_tests"
https://github.com/twstrike/tor_for_patching/tree/util_process_tests
**Trac**:
**Username**: rjuniorTor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17084Improve coverage on src/common/util_format.c2020-06-13T14:49:12ZTracImprove coverage on src/common/util_format.cThe changes are in the branch "util_format_tests"
https://github.com/twstrike/tor_for_patching/tree/util_format_tests
**Trac**:
**Username**: rjuniorThe changes are in the branch "util_format_tests"
https://github.com/twstrike/tor_for_patching/tree/util_format_tests
**Trac**:
**Username**: rjuniorTor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17082Improve coverage on src/common/tortls.c2020-06-13T14:49:12ZTracImprove coverage on src/common/tortls.cThe changes are in the branch "tortls_tests"
https://github.com/twstrike/tor_for_patching/tree/tortls_tests
**Trac**:
**Username**: rjuniorThe changes are in the branch "tortls_tests"
https://github.com/twstrike/tor_for_patching/tree/tortls_tests
**Trac**:
**Username**: rjuniorTor: 0.2.8.x-final