Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:53:40Zhttps://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-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/34245Declare variables in for loops in rend_service_dump_stats()2020-06-13T15:53:37ZNeel Chauhanneel@neelc.orgDeclare variables in for loops in rend_service_dump_stats()Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/34238Space out some function calls in parse_short_policy()2020-06-13T15:53:36ZNeel Chauhanneel@neelc.orgSpace out some function calls in parse_short_policy()Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/34237Fix spacing in if statement in tor_version_parse()2020-06-13T15:53:36ZNeel Chauhanneel@neelc.orgFix spacing in if statement in tor_version_parse()This if statement in tor_version_parse():
```
if ( hexlen == 0 || (hexlen % 2) == 1)
```
should be:
```
if (hexlen == 0 || (hexlen % 2) == 1)
```This if statement in tor_version_parse():
```
if ( hexlen == 0 || (hexlen % 2) == 1)
```
should be:
```
if (hexlen == 0 || (hexlen % 2) == 1)
```Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/34236Fix spacing in if statement in port_parse_config()2020-06-13T15:53:35ZNeel Chauhanneel@neelc.orgFix spacing in if statement in port_parse_config()This line in `port_parse_config()`:
```
if ( has_used_unix_socket_only_option && ! unix_socket_path) {
```
should be:
```
if (has_used_unix_socket_only_option && !unix_socket_path) {
```This line in `port_parse_config()`:
```
if ( has_used_unix_socket_only_option && ! unix_socket_path) {
```
should be:
```
if (has_used_unix_socket_only_option && !unix_socket_path) {
```Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/34233Fix use of == in configure.ac2020-06-13T15:53:35ZNick MathewsonFix use of == in configure.acA user points out that we're now using == in configure.ac, which isn't portable.
We'll need to backport a fix everywhere that we backported our #34078 fix.A user points out that we're now using == in configure.ac, which isn't portable.
We'll need to backport a fix everywhere that we backported our #34078 fix.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34232Make summarize_protover_flags() handle NULL and empty string the same2020-06-13T15:53:34ZteorMake summarize_protover_flags() handle NULL and empty string the samesummarize_protover_flags(NULL, NULL) doesn't set protocols_known, but summarize_protover_flags("", "") does.
While this situation probably won't happen in practice, it could be a source of subtle bugs.
And we have a general guideline t...summarize_protover_flags(NULL, NULL) doesn't set protocols_known, but summarize_protover_flags("", "") does.
While this situation probably won't happen in practice, it could be a source of subtle bugs.
And we have a general guideline that functions should treat NULL and "" in similar ways. (Or the difference should be clearly documented.)
So we should ignore "" protovers, the same way we ignore NULL protovers. (Relays with empty protovers won't end up in the consensus, and clients can't use them for anything. So this change should have no real impact.)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/34220Return to stem master once stem issue 63 is resolved.2020-06-13T15:53:34ZNick MathewsonReturn to stem master once stem issue 63 is resolved.When stem fixes https://github.com/torproject/stem/issues/63 , we should revert the travis.yml change of #34204.When stem fixes https://github.com/torproject/stem/issues/63 , we should revert the travis.yml change of #34204.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34211Add support for control signals (ex. Ctrl+C) in Windows2020-06-13T15:53:33ZTracAdd support for control signals (ex. Ctrl+C) in WindowsHi everyone!
I am working on a [cross-platform Tor controller/wrapper](https://github.com/DcodingTheWeb/ProxAllium/tree/next-gen), and I encountered a minor inconvenience while writing code for stopping Tor in Windows.
Currently the on...Hi everyone!
I am working on a [cross-platform Tor controller/wrapper](https://github.com/DcodingTheWeb/ProxAllium/tree/next-gen), and I encountered a minor inconvenience while writing code for stopping Tor in Windows.
Currently the only way to gracefully terminate Tor in Windows is to use the control port to issue the `SIGINT` signal, it would be beneficial for 3rd party programs which work with Tor to be able to invoke this procedure by using the native "control signals" provided to console programs in Windows.
I have made a patch which implements this functionality, I will post it soon, I am creating this ticket so that I can create a corresponding file in the `changes` directory :)
Thanks to nickm for some pointers about using the libevent `event_active` function to trigger the event, I decided to use the `activate_signal` function as it internally calls the suggested function and simplifies the code.
**Trac**:
**Username**: TheDcoderTor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/34204Downgrade Travis stem version to a commit where tests pass.2020-06-13T15:53:32ZNick MathewsonDowngrade Travis stem version to a commit where tests pass.Due to https://github.com/torproject/stem/issues/63 our CI is failing. Let's downgrade to a working version of Stem unless it gets fixed right away.
I have a test PR at https://github.com/torproject/tor/pull/1889 ; if CI passes, I'll m...Due to https://github.com/torproject/stem/issues/63 our CI is failing. Let's downgrade to a working version of Stem unless it gets fixed right away.
I have a test PR at https://github.com/torproject/tor/pull/1889 ; if CI passes, I'll make PRs for the other branches and put this in needs_review.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34200Refactor tor's circuit path node selection checks2020-06-13T15:53:32ZteorRefactor tor's circuit path node selection checksIn #33222, we added an extra "can extend over IPv6" check to tor's circuit path node selection code.
To make sure it's applied consistently, I did a refactor of that code, so all those checks are in one function.In #33222, we added an extra "can extend over IPv6" check to tor's circuit path node selection code.
To make sure it's applied consistently, I did a refactor of that code, so all those checks are in one function.Tor: 0.4.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/34167PublishServerDescriptor via IPv62020-06-13T15:53:30ZTracPublishServerDescriptor via IPv6let my relay node configurable by what protocol the upload to authorities is done. similiar to
```
PublishServerDescriptor
```
option.
perhaps add option like
```
PublishServerDescriptorProtocol auto|4|6|or
# This option specifi...let my relay node configurable by what protocol the upload to authorities is done. similiar to
```
PublishServerDescriptor
```
option.
perhaps add option like
```
PublishServerDescriptorProtocol auto|4|6|or
# This option specifies how descriptors Tor will publish when acting as
# a relay. You can
# choose multiple arguments, separated by commas.
#
# If this option is set to 4, Tor will publish its
# descriptors to any directories over IPv4. (This is useful if you're not IPv6 connectable
# out your server, or if you're using a IPv6 Translation Tunnel)
# Otherwise, Tor will publish its
# descriptors via IPv6. The default is "auto", which
# means "if running as a relay or bridge, publish descriptors to the
# appropriate authorities over what's reachable". Other possibilities are "or", meaning
# "publish as if you're a OnionService", "publish over onion circuit".
```
_may Sponsor55 or prop311-prop313 already covered if i missed or could be relevant for_
**Trac**:
**Username**: ϲypherpunksTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/34139Build Tor without warnings or test failures with OpenSSL 3.0.02020-06-13T15:53:30ZNick MathewsonBuild Tor without warnings or test failures with OpenSSL 3.0.0According to the OpenSSL release strategy [release-strat] they're planning to release openssl 3.0.0 in early Q4 of this year.
Currently, many of the APIs that Tor uses are deprecated in OpenSSL 3.0.0-alpha [openssl-3]. It's still poss...According to the OpenSSL release strategy [release-strat] they're planning to release openssl 3.0.0 in early Q4 of this year.
Currently, many of the APIs that Tor uses are deprecated in OpenSSL 3.0.0-alpha [openssl-3]. It's still possible to build Tor with it, but you get a lot of deprecated-item warnings. We should fix those warnings before OpenSSL 3 is released.
Further, if we build without fatal warnings, there are some test failures. We should see if they are tor bugs or new openssl bugs, and fix them in the first case or report them in the second.
I don't think we necessarily need to backport this: OpenSSL 1.1 will be supported until 2023-09-11 [release-strat], whereas support for 0.3.5 is scheduled to end on 2020-02-02.
[release-strat] https://www.openssl.org/policies/releasestrat.html
[openssl-3] https://www.openssl.org/blog/blog/2020/04/23/OpenSSL3.0Alpha1/Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/34137Make sure inform_testing_reachability() reports the correct ports2020-06-13T15:53:29ZteorMake sure inform_testing_reachability() reports the correct portsIn #33222, we added IPv6 ORPort support to inform_testing_reachability(). But that function checks the ORPorts and DirPort itself, rather than logging the reachability checks that were actually launched.
We'd like to pass flags so that ...In #33222, we added IPv6 ORPort support to inform_testing_reachability(). But that function checks the ORPorts and DirPort itself, rather than logging the reachability checks that were actually launched.
We'd like to pass flags so that it logs the actual reachability tests that are being run. (Rather than re-checking the relay's own routerinfo, which may have changed since the most recent reachability checks were launched.)
But inform_testing_reachability() is called when:
* the first circuit finishes building, or
* tor is reconfigured, and some circuits have already finished building.
So we need to do a bit of a refactor.
The refactor should preserve this behaviour:
* don't log until after the first circuit has finished building (rather than logging as soon as we start building reachability circuits)
And introduce this new behaviour:
* log the ports that were tested recently, rather than the ports that are currently available.
As an alternative, we could move some of the logging into the functions that actually launch the checks. And elevate some of those logs to notice level. (Note that these checks can be launched from at least 4 different locations in tor's code.)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/34133Tor documentation missing sandbox and %include limitations2020-06-13T15:53:28ZJigsaw52Tor documentation missing sandbox and %include limitationsThe tor manpage and documentation do not tell the user that is not possible to add new configuration files to %included directories in its config files when the seccomp sandbox is enabled.The tor manpage and documentation do not tell the user that is not possible to add new configuration files to %included directories in its config files when the seccomp sandbox is enabled.Tor: 0.4.4.x-final