Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:53:49Zhttps://gitlab.torproject.org/legacy/trac/-/issues/34446TestingTorNetwork should not set AssumeReachable 12020-06-13T15:53:49ZNick MathewsonTestingTorNetwork should not set AssumeReachable 1For S55 we are trying to get self-tests and remote-tests working with IPv6. To make sure we've succeed, we need to try them with Chutney. But to try them with chutney, we need them to be enabled.
With #33583 we removed AssumeReachable...For S55 we are trying to get self-tests and remote-tests working with IPv6. To make sure we've succeed, we need to try them with Chutney. But to try them with chutney, we need them to be enabled.
With #33583 we removed AssumeReachable from the chutney configurations. But that didn't actually have any effect, since `AssumeReachable 1` is implicit in `TestingTorNetwork 1`.Tor: 0.4.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34445Split assumereachable into self and authority components2020-06-13T15:53:48ZNick MathewsonSplit assumereachable into self and authority componentsThis option governs both "should I check if I, a relay, reachable" and "should I, an authority, check if relays are reachable"? These should really be separated.
Calling this S55-must since we need it for chutney-ipv6 stuff.This option governs both "should I check if I, a relay, reachable" and "should I, an authority, check if relays are reachable"? These should really be separated.
Calling this S55-must since we need it for chutney-ipv6 stuff.Tor: 0.4.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34433Replace clang-format.sh with a faster, better version2020-06-13T15:53:47ZNick MathewsonReplace clang-format.sh with a faster, better versionWe need to replace clang-format.sh with a version that meets our use-cases.
Notably:
* we need to be able to check whether anything is misformatted without actually reformatting it.
* we need to be able to look at only those files th...We need to replace clang-format.sh with a version that meets our use-cases.
Notably:
* we need to be able to check whether anything is misformatted without actually reformatting it.
* we need to be able to look at only those files that are staged to be committed, so that our git hooks can work.
* we need a mode to reformat everything that has changed in git, so that we can run a quick "reformat everything" command without scanning the entire repostiory (which takes around 60 seconds for me).Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34412Additonal unit tests for functions related to ipv6 self-test2020-06-13T15:53:47ZNick MathewsonAdditonal unit tests for functions related to ipv6 self-testSee #33222 and #34200 for lists of functions that did not get unit tests as part of the #34200 merge.See #33222 and #34200 for lists of functions that did not get unit tests as part of the #34200 merge.Tor: 0.4.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/34400control: HSFETCH command fails to validate v2 addresses2020-06-13T15:53:46ZDavid Gouletdgoulet@torproject.orgcontrol: HSFETCH command fails to validate v2 addressesIn `handle_control_hsfetch()`:
```
} else if (strcmpstart(arg1, v2_str) == 0 &&
rend_valid_descriptor_id(arg1 + v2_str_len) &&
base32_decode(digest, sizeof(digest), arg1 + v2_str_len,
...In `handle_control_hsfetch()`:
```
} else if (strcmpstart(arg1, v2_str) == 0 &&
rend_valid_descriptor_id(arg1 + v2_str_len) &&
base32_decode(digest, sizeof(digest), arg1 + v2_str_len,
REND_DESC_ID_V2_LEN_BASE32) ==
REND_DESC_ID_V2_LEN_BASE32) {
```
The above snippet is how we validate the v2 address for the `HSFETCH` command. The `base32_decode()` function returns the number of bytes _decoded_ and thus it should returns on success `sizeof(digest)`, not the total length of the base32 address (20 vs 32).
Issue was introduced in commit `a517daa56f5848d25ba79617a1a7b82ed2b0a7c0` meaning since 0.4.1.1-alpha (ticket #28913).
I noticed this because I recently updated the bad HSDirscanner Tor to use our latest and it broke the scanner.Tor: 0.4.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/34384AppVeyor builds are failing2020-06-13T15:53:45ZAlexander Færøyahf@torproject.orgAppVeyor builds are failingOur AppVeyor builds are failing. It looks like the issue is related to us not updating Pacman before we install our dependencies.Our AppVeyor builds are failing. It looks like the issue is related to us not updating Pacman before we install our dependencies.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/34382Don't require M_SYSCALL in sandbox.c2020-06-13T15:53:45ZNick MathewsonDon't require M_SYSCALL in sandbox.cIn sandbox.c, we have a platform-dependent M_SYSCALL macro that is used to extract the syscall from a ucontext_t pointer.
But we only use this value for debugging. Perhaps instead we should make it optional, so that platforms where we ...In sandbox.c, we have a platform-dependent M_SYSCALL macro that is used to extract the syscall from a ucontext_t pointer.
But we only use this value for debugging. Perhaps instead we should make it optional, so that platforms where we don't have it defined can still build with m_syscall.
See also #32904 and #30987Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34381Shellcheck warnings for no-longer-existent contrib scripts2020-06-13T15:53:44ZcShellcheck warnings for no-longer-existent contrib scripts```
% shellcheck --version
ShellCheck - shell script analysis tool
version: 0.7.1
```
Running `make check` results in a few warnings for both `contrib/dist/suse/tor.sh` and `contrib/dist/tor.sh`, namely SC2034 (unused variables) and SC2...```
% shellcheck --version
ShellCheck - shell script analysis tool
version: 0.7.1
```
Running `make check` results in a few warnings for both `contrib/dist/suse/tor.sh` and `contrib/dist/tor.sh`, namely SC2034 (unused variables) and SC2039 (POSIX incompatibilities). If shellcheck is right, then I can gladly go ahead and address these warnings in a PR.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/34376Space out src/feature/stats/rephist.c2020-06-13T15:53:44ZNeel Chauhanneel@neelc.orgSpace out src/feature/stats/rephist.chttps://gitlab.torproject.org/legacy/trac/-/issues/34375Remove 0.4.1 from git-list-tor-branches.sh and add 0.4.42020-06-13T15:53:44ZNick MathewsonRemove 0.4.1 from git-list-tor-branches.sh and add 0.4.4Now that 0.4.1 is EOL, we can remove it from git-list-tor-branches.Now that 0.4.1 is EOL, we can remove it from git-list-tor-branches.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34357Reject relays running 0.4.12020-06-13T15:53:43ZNick MathewsonReject relays running 0.4.1Now that 0.4.1 has reached end-of-life, it's time for directory authorities to stop accepting relays running it.
See #32672 for the last time we did this.
Looking at the graphs, I don't see a significant change in the drop-off rate for...Now that 0.4.1 has reached end-of-life, it's time for directory authorities to stop accepting relays running it.
See #32672 for the last time we did this.
Looking at the graphs, I don't see a significant change in the drop-off rate for deprecated versions in between when we announced that they were deprecated, and when we finally removed them. Maybe this time we should just send out an announcment, wait a month, then reject the relays?Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/34311Space out code in relay.c2020-06-13T15:53:42ZNeel Chauhanneel@neelc.orgSpace out code in relay.cYes, I do understand that Tor is working on automatic code checks for things like code spacing and that I should work on that instead of sending spacing patches, but I still noticed a lot of spacing issues in relay.c (more than normal) s...Yes, I do understand that Tor is working on automatic code checks for things like code spacing and that I should work on that instead of sending spacing patches, but I still noticed a lot of spacing issues in relay.c (more than normal) so I just **had** to submit this.
My PR fixes all (or at least most) of relay.c.Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/34303Find out why onion service measurements have gotten slower2020-06-13T15:53:42ZKarsten LoesingFind out why onion service measurements have gotten slowerToday I changed the ["Time to download files over Tor" graph](https://metrics.torproject.org/torperf.html) to include version 3 onion service measurements.
By chance, I also looked at the [onion server measurements](https://metrics.torp...Today I changed the ["Time to download files over Tor" graph](https://metrics.torproject.org/torperf.html) to include version 3 onion service measurements.
By chance, I also looked at the [onion server measurements](https://metrics.torproject.org/torperf.html?start=2020-02-25&end=2020-05-25&server=onion&filesize=50kb) and found that the onion service measurements made by op-nl2, op-us2, and op-hk2 have gotten much slower as compared to their op-nl, op-us, and op-hk predecessors.
I'm 95% certain that this is not a bug in the graphs.
My current best guess is that something in `tor` has changed. I'd like to set up a small number of experimental OnionPerf instances all in the same place but with different `tor` versions. Any suggestions on locations (Amsterdam, Florida, Hong Kong) or `tor` versions?
This is also relevant to Sponsor 59 in order to make sure that our current measurements are going to be a baseline for future experiments. Classifying as potential defect.Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/34299man page has wrong default for MinUptimeHidServDirectoryV22020-06-13T15:53:41ZRoger Dingledineman page has wrong default for MinUptimeHidServDirectoryV2In #14149 (Tor 0.2.6.3-alpha) we changed the default for MinUptimeHidServDirectoryV2 to 96 hours, to reflect that the directory authorities had already changed it manually. We changed the spec too. But we forgot to change the man page.In #14149 (Tor 0.2.6.3-alpha) we changed the default for MinUptimeHidServDirectoryV2 to 96 hours, to reflect that the directory authorities had already changed it manually. We changed the spec too. But we forgot to change the man page.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/34255Doxygen warnings on 0.4.32020-06-13T15:53:40ZNick MathewsonDoxygen warnings on 0.4.3There are some doxygen warnings about unclosed or unbalanced groups.There are some doxygen warnings about unclosed or unbalanced groups.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34254Jenkins fails with hs_service.c:3118:3: error: comparison of unsigned express...2020-06-13T15:53:40ZGeorge KadianakisJenkins fails with hs_service.c:3118:3: error: comparison of unsigned expression < 0 is always false```
11:23:10 ../tor/src/feature/hs/hs_service.c: In function 'log_cant_upload_desc':
11:23:10 ../tor/src/feature/hs/hs_service.c:3118:3: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
```
https://jenk...```
11:23:10 ../tor/src/feature/hs/hs_service.c: In function 'log_cant_upload_desc':
11:23:10 ../tor/src/feature/hs/hs_service.c:3118:3: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
```
https://jenkins.torproject.org/job/tor-ci-windows-master/659/consoleFull
Seems to be a by-product of #33400.Tor: 0.4.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/34251Fix edge case handling in Rust protover is supported2020-06-13T15:53:39ZteorFix edge case handling in Rust protover is supportedTor's Rust FFI for protocol_list_supports_protocol_or_later() returns true for the empty protocol list.
In C, the function returns false, but this behaviour is undocumented.
This bug doesn't affect protocol_list_supports_protocol() in ...Tor's Rust FFI for protocol_list_supports_protocol_or_later() returns true for the empty protocol list.
In C, the function returns false, but this behaviour is undocumented.
This bug doesn't affect protocol_list_supports_protocol() in Rust, because the Rust error checks are done in a different order.
I'll add a quick fix to #33222, but someone else will need to do the backport. We might want to do the Rust error checks in the same order, too.Tor: 0.4.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/34249Make sure the C and Rust protovers can't get out of sync2020-06-13T15:53:38ZteorMake sure the C and Rust protovers can't get out of syncThere is a recurring bug, where we modify the C protover, but forget the Rust protover. (See #34248, #33285, #29631 for similar issues.)
We could fix the underlying issue by fetching the string from a common location, using C's `#includ...There is a recurring bug, where we modify the C protover, but forget the Rust protover. (See #34248, #33285, #29631 for similar issues.)
We could fix the underlying issue by fetching the string from a common location, using C's `#include` or Rust's `include_str!()`.
Then we could test that C and Rust are the same by putting a copy of the protover string in the unit tests, and making sure that it matches the currently supported protocol versions.
This fix and test will be important for proposal 318, because it will modify both protocol version implementations:
https://github.com/torproject/torspec/blob/master/proposals/318-limit-protovers.mdTor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34248Declare HSIntro=5 in Tor's rust protover implementation2020-06-13T15:53:38ZteorDeclare HSIntro=5 in Tor's rust protover implementationMy protover tests for #33222 fail in Rust, because Tor's rust protover doesn't declare HSIntro=5.
I'll do a quick fix in #33222, but I want to leave the backport to David.My protover tests for #33222 fail in Rust, because Tor's rust protover doesn't declare HSIntro=5.
I'll do a quick fix in #33222, but I want to leave the backport to David.Tor: 0.4.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/34246Add a link to the formatted architecture docs in src/mainpage.md2020-06-13T15:53:37ZteorAdd a link to the formatted architecture docs in src/mainpage.mdWhen I open up src/mainpage.md. it's obviously meant to be formatted by a markdown parser. (And GitHub's markdown doesn't seem to handle "@" directives.)
Can you add a link to the formatted output at the top of mainpage.md ?When I open up src/mainpage.md. it's obviously meant to be formatted by a markdown parser. (And GitHub's markdown doesn't seem to handle "@" directives.)
Can you add a link to the formatted output at the top of mainpage.md ?Tor: 0.4.4.x-final