Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:43:58Zhttps://gitlab.torproject.org/legacy/trac/-/issues/15157Spec issues with consensus' new 'package' field2020-06-13T14:43:58ZDamian JohnsonSpec issues with consensus' new 'package' fieldHi Nick. Brought these up on irc but moving to a ticket. Our consensus' new unused [packages field](https://gitweb.torproject.org/torspec.git/commit/?id=ab6453476066fd1bf5c8cb577863c0cdd5079e0f) has some spec issues...
* It isn't very f...Hi Nick. Brought these up on irc but moving to a ticket. Our consensus' new unused [packages field](https://gitweb.torproject.org/torspec.git/commit/?id=ab6453476066fd1bf5c8cb577863c0cdd5079e0f) has some spec issues...
* It isn't very future proof. It's fine for now, but I'm not sure how it could validly have new attributes in the future.
* Presently it necessitates at least one DIGEST entry. Think that's probably a mistake.
* 'one or more non-=, non-" " characters' => That's too imprecise. For instance, it allows newlines which I'm sure wouldn't really be valid.
* It would be nice if it said if a DIGESTTYPE can appear multiple times. I'd like to model this as a hash but I'm not sure if DIGESTTYPE are unique.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/13966Publish guidelines for reporting exploits2020-06-15T23:22:43ZTracPublish guidelines for reporting exploitsThere exists no easy to find documentation (on the wiki nor elsewhere) that advises how to report a suspected Tor (proxy, browser, bundle, transport...) exploit. And no search on keyservers shows up a 'security' key for a tor-sec@torproj...There exists no easy to find documentation (on the wiki nor elsewhere) that advises how to report a suspected Tor (proxy, browser, bundle, transport...) exploit. And no search on keyservers shows up a 'security' key for a tor-sec@torproject.org or similar account.
A blueprint for working this task could be: Just figure out how we've been handling exploit reporting in the past (tor-assistants@ maybe?) and make sure it's a consensus, and write it down in the wiki.
**Trac**:
**Username**: michaelTor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/13802Add general trace-event logging instrumentation to Tor2020-06-13T14:40:27ZDavid Gouletdgoulet@torproject.orgAdd general trace-event logging instrumentation to TorRelevant to #13792, we (nickm and I) discussed what would be the way to collect and gather those statistics and measurements in a private network for performance analysis and debugging.
This would be completely deactivated at compile ti...Relevant to #13792, we (nickm and I) discussed what would be the way to collect and gather those statistics and measurements in a private network for performance analysis and debugging.
This would be completely deactivated at compile time meaning tracepoints would be NOP. You would have to explicitly enable that feature during the configure process.
We think the best way to go with that, in terms of code, is to go in a header with something that could look like this:
```
#ifdef TOR_USE_LTTNG
tracepoint_aname(arg1, arg2, [...]) tracepoint(aname, arg1, arg2, ...)
#else
tracepoint_aname(arg1, arg2, [...])
#endif
```
The really good thing about this approach is that 1) everything is centralized in one place, 2) you NOP the call if not configured thus no performance issue, 3) We can support lots of different tracers as well as shadow. It provides a simple way to hook any other tool in the trace event facility of the code.Tor: 0.3.1.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/13790Refactor and add comments to new_route_len()2020-06-13T14:40:22ZDavid Gouletdgoulet@torproject.orgRefactor and add comments to new_route_len()(function in src/or/circuitbuild.c)
At the moment, this function is kind of scary and it should be refactored and heavily documented to avoid future confusion. (This ticket exists because two different developers at different time span ...(function in src/or/circuitbuild.c)
At the moment, this function is kind of scary and it should be refactored and heavily documented to avoid future confusion. (This ticket exists because two different developers at different time span over a week expressed concerns about the behavior of HS and this function).
Bit of info on `new_route_len()`, this function is called to possibly extend a circuit with an extra hop that matches specific purpose(s). Right now it's testing the given purpose if it is *not* ESTABLISH_INTRO and TESTING, it will extend it to 4 hops (with exit information).
However, there are other purposes that do NOT need 4 hops. Fortunately, it seems that there are no code paths that end up calling this function with exit info and a purpose that should not be extended (investigated by special, sysrqb, asn and me). But, we all agree that this is very fragile thus the purpose condition in this function should be applied on only purposes that need 4 hops.
Furthermore, add more comments to make sure no more confusion happens with that fairly important function.Tor: 0.3.1.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/13339Prop140: Complete Consensus diffs / Merge GSoC project2020-06-13T14:39:24ZmvdanProp140: Complete Consensus diffs / Merge GSoC projectGoogle Summer of Code finished over a month ago, and during this time I've been tidying up my code a bit and reading it for the merge. You will find it on github:
https://github.com/mvdan/tor
This ticket is for the sole purpose of foll...Google Summer of Code finished over a month ago, and during this time I've been tidying up my code a bit and reading it for the merge. You will find it on github:
https://github.com/mvdan/tor
This ticket is for the sole purpose of following the merge process and its progress. But as always I'm on IRC and mail if you want to contact me directly.
I just rebased against master this morning. Nick and Sebastian have been reviewing my code over the summer, but of course more sets of eyes are needed.
The test coverage for the diff generation and application is fine (see test_consdiff.c), but there aren't any tests for the stuff I wrote to wire it into serving and fetching consensus diffs. Not really sure how to go about that, can't really promise I'd have the time to dive into it.
And regarding commit messages and changelog entries, I pretty much went with my instinct. Chances are they can be improved - the commit messages for future reference and the changelog entries for future release changelogs - so criticism is welcome.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/12970dir-spec's a-line shouldn't mention portlists2020-06-13T14:38:07ZDamian Johnsondir-spec's a-line shouldn't mention portlistsReally quick thing [spotted by joelanders](https://trac.torproject.org/projects/tor/ticket/9380#comment:24). The dir-spec's [description of an a-line](https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l1591) says...
```
...Really quick thing [spotted by joelanders](https://trac.torproject.org/projects/tor/ticket/9380#comment:24). The dir-spec's [description of an a-line](https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l1591) says...
```
Address and portlist are as for "or-address" as specified in
section 2.1.1.
```
Unless I'm missing something this (and or-address) only accept a single address:port, not a list of ports.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/12931TOR_PT_SERVER_TRANSPORT_OPTIONS are not escaped according to pt-spec.txt2020-06-13T14:38:03ZYawning AngelTOR_PT_SERVER_TRANSPORT_OPTIONS are not escaped according to pt-spec.txtpt-spec.txt:
```
"TOR_PT_SERVER_TRANSPORT_OPTIONS" -- A semicolon-separated list
of <key>:<value> pairs, where <key> is a transport name and
<value> is a k=v string value with options that are to be passed
to t...pt-spec.txt:
```
"TOR_PT_SERVER_TRANSPORT_OPTIONS" -- A semicolon-separated list
of <key>:<value> pairs, where <key> is a transport name and
<value> is a k=v string value with options that are to be passed
to the transport. Colons, semicolons, equal signs and backslashes
MUST be escaped with a backslash. TOR_PT_SERVER_TRANSPORT_OPTIONS
is optional and might not be present in the environment of the
proxy if no options are need to be passed to transports.
```
or/transports.c:get_transport_options_for_server_proxy()
```
char *escaped_opts = tor_escape_str_for_pt_args(options, ":;\\");
```
Equal signs are not escaped. I'm not sure if anything will break with different behavior.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/8240Raise our guard rotation period, if appropriate2022-03-22T13:02:42ZRoger DingledineRaise our guard rotation period, if appropriateTariq's COGS paper from WPES 2012 shows that a significant component of guard churn is due to voluntary rotation, rather than actual network changes:
http://freehaven.net/anonbib/#wpes12-cogs
In short, if the target client makes sensiti...Tariq's COGS paper from WPES 2012 shows that a significant component of guard churn is due to voluntary rotation, rather than actual network changes:
http://freehaven.net/anonbib/#wpes12-cogs
In short, if the target client makes sensitive connections continuously every day for months, and you (the attacker) run some fast guards, the odds get pretty good that you'll become the client's guard at some point and get to do a correlation attack.
We could argue that the "continuously every day for months" assumption is unrealistic, so in practice we don't know how bad this issue really is. But for hidden services, it could well be a realistic assumption.
There are going to be (at least) two problems with raising the guard rotation period. The first is that we unbalance the network further wrt old guards vs new guards, and I'm not sure by how much, so I'm not sure how much our bwauth measurers will have to compensate. The second (related) problem is that we'll expand the period during which new guards don't get as much load as they will eventually get. This issue already results in confused relay operators trying to shed their Guard flag so they can resume having load.
In sum, if we raise the rotation period enough that it really results in load changes, then we could have unexpected side effects like having the bwauths raise the weights of new (and thus totally unloaded) guards to huge numbers, thus ensuring that anybody who rotates a guard will basically for sure get one of these new ones.
The real plan here needs a proposal, and should be for 0.2.5 or later. I wonder if we can raise it 'some but not too much' in the 0.2.4 timeframe though?Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6892improve torify manpage to say different connections may be over the same circ...2020-06-13T14:22:59Zweasel (Peter Palfrader)improve torify manpage to say different connections may be over the same circuit.Linus Lüssing would like the torify manpage to spell out that it does not do anything to make different torify calls unlinkable.
Probably not an unreasonable request.
For details of his request see
http://bugs.debian.org/681123
Cheers...Linus Lüssing would like the torify manpage to spell out that it does not do anything to make different torify calls unlinkable.
Probably not an unreasonable request.
For details of his request see
http://bugs.debian.org/681123
Cheers,
weaselTor: 0.3.1.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/6298Tests should not depend on localhost==127.0.0.1 (Test 'addr/basic' failure in...2020-06-13T14:20:52ZAndrea ShepardTests should not depend on localhost==127.0.0.1 (Test 'addr/basic' failure in tor master)I just built branch 'master' (revision 46434ecf5b6f1ad88deb86fdac044c41ae4b534b) from the tor.git repository with gcc 4.5.3 on x86_64-linux using this configure line:
CC="gcc -m64 -mtune=core2" PKG_CONFIG_LIBDIR=/usr/lib64/pkgconfig PKG...I just built branch 'master' (revision 46434ecf5b6f1ad88deb86fdac044c41ae4b534b) from the tor.git repository with gcc 4.5.3 on x86_64-linux using this configure line:
CC="gcc -m64 -mtune=core2" PKG_CONFIG_LIBDIR=/usr/lib64/pkgconfig PKG_CONFIG_PATH=/usr/share/pkgconfig ./configure --prefix=/usr --libdir=/usr/lib64 --libexecdir=/usr/libexec64 --sysconfdir=/etc --localstatedir=/var --build=x86_64-linux --host=x86_64-linux --disable-linker-hardening --disable-asciidoc
This causes a test suite failure I haven't seen before:
addr/basic:
FAIL test_addr.c:36: assert((u32) == (0x7f000001u)): 2851995905 vs 2130706433
[basic FAILED]
Turns out the DNS in this hotel *resolves localhost to 169.254.1.1*. This is horribly wrong, of course, and I should have had a proper /etc/hosts for it anyway (*lashes self with wet noodle*), but why does the test suite depend on stuff random machines elsewhere on the network do at all to pass? Shouldn't we mock this stuff somehow?Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/4998MyFamily as a list2020-06-13T14:17:04Zweasel (Peter Palfrader)MyFamily as a listHi,
MyFamily currently is a config string. It'd be nice if it was a line list like RecommendedVersions as that would make configuration files a bit more readable.Hi,
MyFamily currently is a config string. It'd be nice if it was a line list like RecommendedVersions as that would make configuration files a bit more readable.Tor: 0.3.1.x-finalJigsaw52Jigsaw52https://gitlab.torproject.org/legacy/trac/-/issues/2045Make tor_check_port_forwarding handle incomplete lines2020-06-13T15:09:26ZSteven MurdochMake tor_check_port_forwarding handle incomplete linesThe code for parsing the output of tor-fw-helper uses fgets() on a non-blocking file descriptor to fetch each line of output. This appears to not handle incomplete lines properly. Rather than buffering data until a complete line is retur...The code for parsing the output of tor-fw-helper uses fgets() on a non-blocking file descriptor to fetch each line of output. This appears to not handle incomplete lines properly. Rather than buffering data until a complete line is returned, fgets will return an incomplete line and set errno to be EAGAIN. fgets() should be replaced with something which can handle incomplete lines.
Issue was originally raised by nickm in bug #1903 and there is some further discussion in that ticket.Tor: 0.3.1.x-finalSteven MurdochSteven Murdochhttps://gitlab.torproject.org/legacy/trac/-/issues/1922torrc.d-style configuration directories2020-06-13T16:52:58ZTractorrc.d-style configuration directoriestorrc.d-style configuration directories
**Trac**:
**Username**: aa138346torrc.d-style configuration directories
**Trac**:
**Username**: aa138346Tor: 0.3.1.x-finalJigsaw52Jigsaw52https://gitlab.torproject.org/legacy/trac/-/issues/1121reason unexpected while uploading descriptor2020-06-13T14:02:49ZTracreason unexpected while uploading descriptorHi,
since i upgraded my relay to 0.2.2.5-alpha i am getting these warn message below.
Oct 12 13:15:10.985 [notice] Bootstrapped 90%: Establishing a Tor circuit.
Oct 12 13:15:18.207 [notice] Tor has successfully opened a circuit. Looks...Hi,
since i upgraded my relay to 0.2.2.5-alpha i am getting these warn message below.
Oct 12 13:15:10.985 [notice] Bootstrapped 90%: Establishing a Tor circuit.
Oct 12 13:15:18.207 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Oct 12 13:15:18.207 [notice] Bootstrapped 100%: Done.
Oct 12 13:16:09.666 [warn] http status 404 ("Not Found") reason unexpected while uploading descriptor to server '194.109.206.212:80').
Oct 12 13:16:17.277 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent.
Oct 12 13:16:18.508 [notice] Performing bandwidth self-test...done.
Oct 12 13:17:10.924 [warn] http status 404 ("Not Found") reason unexpected while uploading descriptor to server '194.109.206.212:80').
Oct 12 13:23:16.169 [warn] http status 404 ("Not Found") reason unexpected while uploading descriptor to server '194.109.206.212:80').
Some kind of new bug?
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: dragonflyTor: 0.3.1.x-final