Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2022-02-17T11:05:53Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33451Write a script to install git tools and hooks2022-02-17T11:05:53ZNick MathewsonWrite a script to install git tools and hooksWe shouldn't run this automatically because of security issues, but it would be nice to have an automatic install tool.We shouldn't run this automatically because of security issues, but it would be nice to have an automatic install tool.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/30642Add an ed25519-identity file to the data directory2021-09-12T21:12:59ZteorAdd an ed25519-identity file to the data directoryRelays print their RSA fingerprint to a "fingerprint" file in their data directory.
We need an equivalent file for base-64 encoded ed25519 public keys.Relays print their RSA fingerprint to a "fingerprint" file in their data directory.
We need an equivalent file for base-64 encoded ed25519 public keys.Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33226Prop 311: 5. Declare Support for Subprotocol Version "Relay=3"2020-07-02T19:46:44ZteorProp 311: 5. Declare Support for Subprotocol Version "Relay=3"This ticket depends on relay IPv6 extends in #33220.
We reserve Tor subprotocol "Relay=3" for tor versions where:
* relays may perform IPv6 extends, and
* bridges might not perform IPv6 extends,
as described in this proposal.
See p...This ticket depends on relay IPv6 extends in #33220.
We reserve Tor subprotocol "Relay=3" for tor versions where:
* relays may perform IPv6 extends, and
* bridges might not perform IPv6 extends,
as described in this proposal.
See proposal 311, section 5:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n601Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32040HS intro padding machine reactivates after receiving INTRODUCE_ACK2020-06-16T11:27:52ZGeorge KadianakisHS intro padding machine reactivates after receiving INTRODUCE_ACKWhile reseaching wtf-pad I noticed that the intro machines display a weird shutdown/reactivation pattern.
In particular, what happens is that after INTRODUCE1 is sent, the machine starts up and sends all its padding, and then shuts down...While reseaching wtf-pad I noticed that the intro machines display a weird shutdown/reactivation pattern.
In particular, what happens is that after INTRODUCE1 is sent, the machine starts up and sends all its padding, and then shuts down. Then when INTRODUCE_ACK arrives, it reactivates (probably because INTRODUCE_ACK is part of the accepted purposes and the machine is shutdown/freed at that time) and sends again padding, then again shuts down...
This does not work as intended and causes extra cells to fly in with a pattern that probably does not help them blend in.
Here are some Tor logs (with padanalysis incoming/outgoing cells logs):
```
Oct 11 13:25:54.000 [warn] outgoing-cell: EXTEND2 0
Oct 11 13:25:54.000 [warn] incoming-cell: EXTENDED2 0 66
Oct 11 13:25:54.000 [warn] outgoing-cell: EXTEND2 0
Oct 11 13:25:54.000 [warn] incoming-cell: EXTENDED2 0 66
Oct 11 13:25:57.000 [warn] outgoing-cell: EXTEND 0
Oct 11 13:25:58.000 [warn] incoming-cell: EXTENDED 0 148
Oct 11 13:25:58.000 [warn] outgoing-cell: INTRODUCE1 4
Oct 11 13:25:58.000 [warn] outgoing-cell: PADDING_NEGOTIATE 4
Oct 11 13:25:58.000 [warn] incoming-cell: PADDING_NEGOTIATED 4 4
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: PADDING_NEGOTIATED 4 4
Oct 11 13:25:58.000 [info] circpad_handle_padding_negotiated(): Received STOP command on PADDING_NEGOTIATED for circuit 5
Oct 11 13:25:58.000 [info] circpad_circuit_machineinfo_free_idx(): Freeing padding info idx 0 on circuit 5 (7)
Oct 11 13:25:58.000 [warn] incoming-cell: INTRODUCE_ACK 4 0
Oct 11 13:25:58.000 [info] rend_client_introduction_acked(): Received ack. Telling rend circ...
Oct 11 13:25:58.000 [info] circpad_setup_machine_on_circ(): Registering machine client_ip_circ to origin circ 5 (8)
Oct 11 13:25:58.000 [info] circpad_node_supports_padding(): Checking padding: supported
Oct 11 13:25:58.000 [info] circpad_negotiate_padding(): Negotiating padding on circuit 5 (8), command 2
Oct 11 13:25:58.000 [warn] outgoing-cell: 8 PADDING_NEGOTIATE 4
Oct 11 13:25:58.000 [info] circpad_machine_spec_transition(): Circuit 5 circpad machine 0 transitioning from 0 to 1
Oct 11 13:25:58.000 [info] circpad_marked_circuit_for_padding(): Circuit 5 is not marked for close because of a pending padding machine in index 0.
Oct 11 13:25:58.000 [warn] incoming-cell: PADDING_NEGOTIATED 4 4
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: PADDING_NEGOTIATED 4 4
Oct 11 13:25:58.000 [info] circpad_handle_padding_negotiated(): Received STOP command on PADDING_NEGOTIATED for circuit 5
Oct 11 13:25:58.000 [info] circpad_circuit_machineinfo_free_idx(): Freeing padding info idx 0 on circuit 5 (15)
...
Oct 11 13:36:11.000 [info] circuit_mark_for_close_(): Circuit 4130340667 (id: 5) marked for close at src/core/or/circuituse.c:1509 (orig reason: 9, new reason: 0)
```
I'm not sure what the fix should be here. It might be that we need to remove INTRODUCE_ACK from the list of accepted purposes, but if we do that then if INTRODUCE_ACK arrives earlier we will stop padding after. Hmm.Tor: 0.4.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/32542hs-v3: Add the 2 missing SOCKS extended errors from prop3042020-06-16T01:10:52ZDavid Gouletdgoulet@torproject.orghs-v3: Add the 2 missing SOCKS extended errors from prop304The two missing codes are the intro failure and RP failure.
```
* X'F2' Onion Service Introduction Failed
Client failed to introduce to the service meaning the descriptor was
found but the service is not anymore at the ...The two missing codes are the intro failure and RP failure.
```
* X'F2' Onion Service Introduction Failed
Client failed to introduce to the service meaning the descriptor was
found but the service is not anymore at the introduction points. The
service has likely changed its descriptor or is not running.
* X'F3' Onion Service Rendezvous Failed
Client failed to rendezvous with the service which means that the client
is unable to finalize the connection.
```Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/14389little-t-tor: Provide support for better TBB UI of hidden service client auth...2020-06-16T01:02:43ZGeorge Kadianakislittle-t-tor: Provide support for better TBB UI of hidden service client authorization**This is the network-team-side of ticket #30237.
**
The current hidden service spec allows clients to authenticate themselves using auth-cookies. The future proposal 224 will allow clients to authenticate using username/password or pubk...**This is the network-team-side of ticket #30237.
**
The current hidden service spec allows clients to authenticate themselves using auth-cookies. The future proposal 224 will allow clients to authenticate using username/password or pubkey.
Currently users have to edit their torrc and add HidServAuth lines for the hidden services that require authorization. In the future, it would be nicer if TBB had an interface for users to type in their authorization credentials.
Tor knows whether an HS needs authorization, because the intro list is encrypted. Tor would have to somehow transfer this knowledge to TBB, so that the browser can present a nice UI that the user can fill on the go.
Furthermore, with the future username/password authorization and this UI improvement, it won't be necessary for people to write on their torrc which hidden services they visit and what's their auth-cookie.
This is a ticket about finding out what mods need to happen in little-t-tor, and coordinating the development of this feature.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/33669"Pluggable Transport process terminated" but Tor keeps on going (and of cours...2020-06-13T18:21:52ZRoger Dingledine"Pluggable Transport process terminated" but Tor keeps on going (and of course doesn't work)In https://trac.torproject.org/projects/tor/ticket/33336#comment:20 I encountered the unfortunate situation where my snowflake client exited:
```
Feb 25 14:36:24.458 [warn] Pluggable Transport process terminated with status code 512
```
...In https://trac.torproject.org/projects/tor/ticket/33336#comment:20 I encountered the unfortunate situation where my snowflake client exited:
```
Feb 25 14:36:24.458 [warn] Pluggable Transport process terminated with status code 512
```
It still remains unclear whether snowflake had a bug that crashed it, or if Tor has a bug that made it close the socket to snowflake.
But either way, after this event Tor quietly cries to itself:
```
Feb 25 14:36:44.825 [warn] The connection to the SOCKS5 proxy server at 127.0.0.1:45527 just failed. Make sure that the proxy server is up and running.
```
and Tor Browser has no idea this is happening, or that trying to use Tor is now hopeless.
We should figure out something smarter that Tor should do in this situation. Perhaps it should exit, forcing the user to notice? Perhaps it should emit an event that Tor Browser picks up on? Maybe we have an even better idea?Tor: 0.4.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/30971Rebuild the fallback list in late 2019 or early 20202020-06-13T16:06:46ZteorRebuild the fallback list in late 2019 or early 2020Late in 2019, or early in 2020, we should rebuild the fallback list again.
We usually do this when 25% or more go down.
(When 25% of fallbacks are down, a warning is logged daily in #tor-bots on IRC, and via email to the fallback mainta...Late in 2019, or early in 2020, we should rebuild the fallback list again.
We usually do this when 25% or more go down.
(When 25% of fallbacks are down, a warning is logged daily in #tor-bots on IRC, and via email to the fallback maintainers.)
Here are the instructions for running a rebuild:
https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallbackDirectoryMirrors
See the child tickets for each step.Tor: 0.4.4.x-finalhttps://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/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/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/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/33400hs-v3: Log why we can't upload a descriptor2020-06-13T15:53:40ZDavid Gouletdgoulet@torproject.orghs-v3: Log why we can't upload a descriptorWe still have report of services that stop working and the logs suggest they simply stopped uploading their descriptors.
We need to know why and thus add logging. TIcket #24346 had an attempt at it but it was abandoned. I'm reviving the...We still have report of services that stop working and the logs suggest they simply stopped uploading their descriptors.
We need to know why and thus add logging. TIcket #24346 had an attempt at it but it was abandoned. I'm reviving the logging part due to still getting reports of the issue.
Logging the reason is tricky due to the rate and multiple descriptor object.Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://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/33285Make sure relay protocol lists are sorted2020-06-13T15:53:39ZteorMake sure relay protocol lists are sortedTor's directory specification says that protocols should be sorted by keyword:
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n802
But many relays current protocol lists are:
`Cons=1-2 ... Relay=1-2 Padding=2 FlowCtrl=1`
W...Tor's directory specification says that protocols should be sorted by keyword:
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n802
But many relays current protocol lists are:
`Cons=1-2 ... Relay=1-2 Padding=2 FlowCtrl=1`
We should sort these lists, and make sure they stay sorted.Tor: 0.4.4.x-finalteorteorhttps://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/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.org