Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-07-31T12:42:39Zhttps://gitlab.torproject.org/legacy/trac/-/issues/20284consensus weight case 2b3 does not follow dir-spec2020-07-31T12:42:39Zpastlyconsensus weight case 2b3 does not follow dir-spec[dir-spec](https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2681) says the following.
```
If M > T/3, then the Wmd weight above will become negative. Set it to 0
in this case:
Wmd = 0
Wgd = weight_scale - Wed
```
The ...[dir-spec](https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2681) says the following.
```
If M > T/3, then the Wmd weight above will become negative. Set it to 0
in this case:
Wmd = 0
Wgd = weight_scale - Wed
```
The code dutifully sets `Wmd` to 0, but neglects `Wgd`.
I assume the spec is correct and the intended behavior. Branch incoming once I get a ticket number.Tor: unspecifiedpastlypastlyhttps://gitlab.torproject.org/legacy/trac/-/issues/33262Prop 313: 3. Write a Script that Counts IPv6 Relays in the Consensus2020-07-02T19:47:20ZteorProp 313: 3. Write a Script that Counts IPv6 Relays in the ConsensusWe want to write a script that generates statistics for relays that:
1. have an IPv6 ORPort,
2. support IPv6 clients,
3. support IPv6 reachability checks, and
4. support IPv6 reachability checks, and IPv6 clients.
The first two ...We want to write a script that generates statistics for relays that:
1. have an IPv6 ORPort,
2. support IPv6 clients,
3. support IPv6 reachability checks, and
4. support IPv6 reachability checks, and IPv6 clients.
The first two statistics have no dependencies. The last two statistics depend on the "Relay=3" subprotocol in #33226.
The script should calculate:
* the number of relays, and
* the consensus weight fraction of relays.
In order to provide easy access to these statistics, we propose
that the script should:
* download a consensus (or read an existing consensus), and
* calculate and report these statistics.
We could write this script using Python 3 and Stem:
https://stem.torproject.org
The following consensus weight fractions should divide by the total
consensus weight:
* have an IPv6 ORPort (all relays have an IPv4 ORPort), and
* support IPv6 reachability checks (all relays support IPv4 reachability).
The following consensus weight fractions should divide by the
"usable Guard" consensus weight:
* support IPv6 clients, and
* support IPv6 reachability checks and IPv6 clients.
"Usable Guards" have the Guard flag, but do not have the Exit flag. If the
Guard also has the BadExit flag, the Exit flag should be ignored.
The script should check that Wgd is 0. If it is not, the script
should log a warning about the accuracy of the "Usable Guard" statistics.
See proposal 313, section 3:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt#n82Tor: unspecifiedhttps://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/32204Create either a query or event-based API to allow controllers (particularly T...2020-06-16T01:28:32ZrichardCreate either a query or event-based API to allow controllers (particularly Tor Browser) to reliably get circuit informationCurrently we can not get the address or type of a bridge by id/fingerprint if the bridge entry in torrc does not have the fingerprint string provided. This info is needed for the circuit display in Tor Browser, which currently just displ...Currently we can not get the address or type of a bridge by id/fingerprint if the bridge entry in torrc does not have the fingerprint string provided. This info is needed for the circuit display in Tor Browser, which currently just displays 'Bridge' without the address or type information.
Tor Browser currently gets the circuit display information by first requesting the circuit for a given first-party domain/nonce pair. This returns an array of fingerprints. We then get the list of bridges stored in the torrc file via `GETCONF bridge`. We compare each bridge's id to each node in the circuit. If a match if sound we know the node is a bridge and we display its information. Otherwise, we assume it is a relay and we query the information from tor via `GETINFO ns/id/$fingerprint`.
With the change in #32125 we now infer that if the GETINFO call fails, it's because the id we've received is actually a Bridge whose info we do not know.
Some possible options:
- Tor updates the torrc with the Bridge's fingerprint once it is known. Tor Browser's logic doesn't change but there will be a window when a user looking at the circuit display will just see 'Bridge' rather than the full set of information.
- Tor adds a new query API that allows us to get Bridge information in a similar fashion to how we currently get relay information. The repeated GETCONF for bridges goes away and we now for each id in the circuit, we just try querying bridge info and if that fails we then query relay info.
- Tor Browser listens for the 'figured out the fingerprint for this bridge event' (which I believe currently just logs?) and maintains some in-memory map/cache of fingerprint to { type, ip, geolocation }. I'd really rather not do this.
- Add a 'verbose' circuit query API, where we just provide the domain/nonce pair and you give us the required data all at once. This would simplify Tor Browser code and would require less back-and-forth between tor and Tor Browser.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/16651Tor fails to build on OpenBSD 5.8 due to libevent config options2020-06-16T01:26:59ZteorTor fails to build on OpenBSD 5.8 due to libevent config optionsCan we apply the patch in this thread?
http://lists.nycbug.org/pipermail/tor-bsd/2015-July/000328.htmlCan we apply the patch in this thread?
http://lists.nycbug.org/pipermail/tor-bsd/2015-July/000328.htmlTor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/23378Call "Sandbox 1" no longer an experimental feature?2020-06-16T01:25:01ZRoger DingledineCall "Sandbox 1" no longer an experimental feature?Right now the man page says that Sandbox is an experimental feature.
What needs to happen for us to stop calling it experimental?
We should sort out a roadmap and then we can know when we've gotten there.Right now the man page says that Sandbox is an experimental feature.
What needs to happen for us to stop calling it experimental?
We should sort out a roadmap and then we can know when we've gotten there.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/30382prop304: Implement SOCKS new HS error code2020-06-16T01:13:05ZGeorge Kadianakisprop304: Implement SOCKS new HS error codeFor TB to be able to alert the user that they need to input their client auth credentials we need an appropriate control port event.
In particular:
1) When Tor fails to decrypt the second layer of desc encryption, we issue the `CLIENT_...For TB to be able to alert the user that they need to input their client auth credentials we need an appropriate control port event.
In particular:
1) When Tor fails to decrypt the second layer of desc encryption, we issue the `CLIENT_AUTH_NEEDED <onion> <reason>` event. Tor does not go to fetch more descs from the hsdir for this onion.
2) At the same time, we store the broken descriptor into the hs cache, with a special flag that says "missing client auth" and hence `desc` is `NULL`.
3) When TB intercepts the event it presents the user with a dialogue (#30237) and adds any client auth creds with the commands from #30381.
4) As part of the #30381 commands the descriptor is decrypted.
5) TB issues another SOCKS request which uses the right descriptor and goes forward.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/28805ControlPort has undocumented behavior2020-06-16T01:13:04ZTracControlPort has undocumented behavior== Problem 1
`ControlPort`'s value can be set to address:port though `man torrc` says that only port can be specified.
== Problem 2
Option `ControlPort` can be set few times to bind to different "address:port"s. This is also not docum...== Problem 1
`ControlPort`'s value can be set to address:port though `man torrc` says that only port can be specified.
== Problem 2
Option `ControlPort` can be set few times to bind to different "address:port"s. This is also not documented. Other options which can be set multiple times are explicitly documented with a statement like
```
This directive can be specified multiple times to bind to multiple addresses/ports
```
for `SocksPort`.
Original comment about these issues is [[http://ea5faa5po25cf7fb.onion/projects/tor/ticket/28676#comment:15|here]].
**Trac**:
**Username**: wagonTor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/32546hs-v3: Report invalid onion address SOCKS5 extended error code2020-06-16T01:10:52ZDavid Gouletdgoulet@torproject.orghs-v3: Report invalid onion address SOCKS5 extended error codeFrom prop304, continuing on after #30382, add a new error code to indicate invalid address.
This is the little-t tor side of #30022.From prop304, continuing on after #30382, add a new error code to indicate invalid address.
This is the little-t tor side of #30022.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://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/19642Add a descriptor line for Single Onion Services2020-06-16T01:09:59ZteorAdd a descriptor line for Single Onion ServicesSome of the things we want to do with Single Onion Services (like #17945) only work if clients know they're connecting to a Single Onion Service.
But it's hard to add an extra line to the existing HS descriptor format.
So it would be g...Some of the things we want to do with Single Onion Services (like #17945) only work if clients know they're connecting to a Single Onion Service.
But it's hard to add an extra line to the existing HS descriptor format.
So it would be great if we could make this change when we implement the prop224 descriptor format.Tor: 0.3.0.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/2716When we conclude a relay is unreachable, we give it free uptime2020-06-16T01:00:19ZRoger DingledineWhen we conclude a relay is unreachable, we give it free uptimeIn researching #2714 (for #2709), I noticed:
```
Mar 10 15:44:21.000 [info] dirserv_orconn_tls_done(): Found router MesBotEU1 to be reachable. Yay.
Mar 10 16:24:04.000 [info] run_connection_housekeeping(): Expiring non-open OR connection...In researching #2714 (for #2709), I noticed:
```
Mar 10 15:44:21.000 [info] dirserv_orconn_tls_done(): Found router MesBotEU1 to be reachable. Yay.
Mar 10 16:24:04.000 [info] run_connection_housekeeping(): Expiring non-open OR connection to fd 1245 (78.47.251.152:667).
Mar 10 16:44:40.000 [info] run_connection_housekeeping(): Expiring non-open OR connection to fd 990 (78.47.251.152:667).
Mar 10 16:50:01.000 [info] rep_hist_note_router_unreachable(): Router EABCA5F5D71D926C4A425E09C8C7F3AA46850EF6 is now non-Running: it had previously been Running since 2011-03-09 19:41:41. Its total weighted uptime is 1412377/1426655.
Mar 10 17:02:48.000 [info] dirserv_orconn_tls_done(): Found router MesBotEU1 to be reachable. Yay.
Mar 10 17:02:48.000 [info] rep_hist_note_router_reachable(): Router EABCA5F5D71D926C4A425E09C8C7F3AA46850EF6 is now Running; it had been down since 2011-03-10 16:50:01.
```
We do a reachability test every 21.3 minutes, so with REACHABLE_TIMEOUT at 45 minutes, that means you can fail one or two reachability tests and still get counted up. Fine.
But when you fail *more* than that, and we conclude you're down, should we assume you were up for the entire grace period?
Seems like we should conclude you went (retroactively) down at the first failed test -- 16:24:04 in this case.
While I'm at it, what happened to the reachability test around 16:04? I couldn't find any evidence of it in my logs. (But there are millions of lines here, so maybe I just didn't look carefully enough.)
(For the record, MesBotEU1 thinks it was up the whole time.)Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28624Should we remember dormant state on restart?2020-06-16T01:00:03ZRoger DingledineShould we remember dormant state on restart?One of the core ideas of #2149 was for Tor to remember its dormancy across restarts. As of the finishing of #2149, Tor will go dormant 24 hours after startup if it's seen no activity -- but if you start it again, it'll be active for 24 h...One of the core ideas of #2149 was for Tor to remember its dormancy across restarts. As of the finishing of #2149, Tor will go dormant 24 hours after startup if it's seen no activity -- but if you start it again, it'll be active for 24 hours again. So people who restart their computers, or their Tor-including apps, will continue putting load on the Tor network.
So I am opening this ticket to not forget that second piece of it.
The first question is around the engineering side: when we go dormant, do we write that fact into our state file? And when we change our mind, I guess we clear it? Do we also write it when the controller commands us to go dormant? I guess yes.
The second question is about how thorough we want to be. Specifically, if we're expecting that people will restart their Tor, what about people who never leave their Tor going for a full 24 hours? Those people will never switch to a dormant state. Is that ok? The fix would be to record "partial progress towards going dormant" in the state file, which is kind of ugly but also doable.
The third question is around how to handle it when we start up and the state file says we were dormant. Continuing to stay dormant seems like the clear right behavior -- because after all, we can wake up and start bootstrapping if we actually get an application level request. But I guess that means we don't even try to bootstrap? Are there controller apps like Tor Launcher and Nyx that wait for the 100% bootstrap message and tell you that your Tor is broken if it doesn't happen? Is there something we can give those apps instead that will satisfy them that Tor is "acting as intended"? Is there some simple "connect to a relay and do a handshake with it once" thing that we can do instead on startup, to satisfy ourselves that Tor *could* work if we wanted it to? Or should we stay totally isolated from the network when we start up in dormant state?
I think some of these are ux questions, and answering them might be easier if we pick a couple of specific use cases for dormant mode. Here are two:
(1) What if some linux distro includes a Tor client package by default, and users can configure their apps to use it but many users don't. In that case we'd have thousands or millions of Tor clients installed but not usefully using the Tor network. And our primary goal there would be to make those Tors go totally quiet after a while. This was the original motivation for #2149.
(2) ...I was going to use an example here of Tor bundled with an app, like Brave or Briar, but I think in this case the app should be responsible for making Tor behave politely to the Tor network.
So I think use case (1) is the one to focus on, and that also simplifies the ux questions.Tor: 0.4.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/26360Transport plugins deadlock if they write too much to stderr2020-06-16T00:48:26ZDavid Fifielddcf@torproject.orgTransport plugins deadlock if they write too much to stderr[launch_managed_proxy](https://gitweb.torproject.org/tor.git/tree/src/or/transports.c?id=bc951e83aac770d123118bf485d14490c2539048#n516), via [tor_spawn_background](https://gitweb.torproject.org/tor.git/tree/src/common/util.c?id=bc951e83a...[launch_managed_proxy](https://gitweb.torproject.org/tor.git/tree/src/or/transports.c?id=bc951e83aac770d123118bf485d14490c2539048#n516), via [tor_spawn_background](https://gitweb.torproject.org/tor.git/tree/src/common/util.c?id=bc951e83aac770d123118bf485d14490c2539048#n4232), opens a pipe from the child process's stderr, but never reads from the pipe. If the child process writes too much to its stderr, eventually an OS buffer fills up and the child process hangs. This manifests in the tor log as "No running bridges."
Seems like this has always been a problem, but it only showed up recently with Snowflake, which by default logs to stderr and is more chatty than past transports have been. See #25600. The problem went away when instructing snowflake-client to log to a file instead of to stderr.
Ccing ahf as suggested by arma.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25977Cross-compiling tor rust for macOS is broken2020-06-16T00:46:42ZGeorg KoppenCross-compiling tor rust for macOS is brokenUsing our cross-compile setup for compiling tor with Rust support for macOS results in a build failure. It seems the macOS cross-compile Rust support is missing:
```
CCLD src/tools/tor-resolve
/var/tmp/dist/macosx-toolchain/cctools...Using our cross-compile setup for compiling tor with Rust support for macOS results in a build failure. It seems the macOS cross-compile Rust support is missing:
```
CCLD src/tools/tor-resolve
/var/tmp/dist/macosx-toolchain/cctools/bin/x86_64-apple-darwin10-ranlib: file: src/or/libtor.a(protover.o) has no symbols
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
/var/tmp/dist/macosx-toolchain/cctools/bin/x86_64-apple-darwin10-ranlib: file: src/or/libtor-testing.a(src_or_libtor_testing_a-protover.o) has no symbols
x86_64-apple-darwin10-ranlib: file: src/or/libtor.a(protover.o) has no symbols
CCLD src/test/test-child
CCLD src/test/test-switch-id
x86_64-apple-darwin10-ranlib: file: src/or/libtor-testing.a(src_or_libtor_testing_a-protover.o) has no symbols
CCLD src/test/test-timers
CCLD src/test/test-ntor-cl
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
CCLD src/test/test-hs-ntor-cl
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
CCLD src/test/test-bt-cl
CCLD src/test/fuzz/fuzz-consensus
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
CCLD src/test/fuzz/fuzz-descriptor
CCLD src/test/fuzz/fuzz-diff
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
CCLD src/test/fuzz/fuzz-diff-apply
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
CCLD src/test/fuzz/fuzz-extrainfo
CCLD src/test/fuzz/fuzz-hsdescv2
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
CCLD src/test/fuzz/fuzz-hsdescv3
CCLD src/test/fuzz/fuzz-http
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
CCLD src/test/fuzz/fuzz-http-connect
CCLD src/test/fuzz/fuzz-iptsv2
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
Undefined symbols for architecture x86_64:
"_protocol_list_supports_protocol_or_later", referenced from:
_summarize_protover_flags in libtor-testing.a(src_or_libtor_testing_a-routerparse.o)
"_protocol_list_supports_protocol", referenced from:
_summarize_protover_flags in libtor-testing.a(src_or_libtor_testing_a-routerparse.o)
ld: symbol(s) not found for architecture x86_64
clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation)
Makefile:4715: recipe for target 'src/test/fuzz/fuzz-descriptor' failed
make[1]: *** [src/test/fuzz/fuzz-descriptor] Error 1
make[1]: *** Waiting for unfinished jobs....
Undefined symbols for architecture x86_64:
"_protocol_list_supports_protocol_or_later", referenced from:
_summarize_protover_flags in libtor-testing.a(src_or_libtor_testing_a-routerparse.o)
"_protocol_list_supports_protocol", referenced from:
_summarize_protover_flags in libtor-testing.a(src_or_libtor_testing_a-routerparse.o)
ld: symbol(s) not found for architecture x86_64
clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation)
Makefile:4705: recipe for target 'src/test/fuzz/fuzz-consensus' failed
make[1]: *** [src/test/fuzz/fuzz-consensus] Error 1
Undefined symbols for architecture x86_64:
"_protover_get_supported_protocols", referenced from:
_router_build_fresh_descriptor in libtor-testing.a(src_or_libtor_testing_a-router.o)
"_protocol_list_supports_protocol_or_later", referenced from:
Undefined symbols for architecture x86_64:
"_protover_get_supported_protocols", referenced from:
_router_build_fresh_descriptor in libtor-testing.a(src_or_libtor_testing_a-router.o)
_summarize_protover_flags in libtor-testing.a(src_or_libtor_testing_a-routerparse.o)
"_protover_all_supported", referenced from:
_handle_missing_protocol_warning_impl in libtor-testing.a(src_or_libtor_testing_a-networkstatus.o)
"_protocol_list_supports_protocol_or_later", referenced from:
_summarize_protover_flags in libtor-testing.a(src_or_libtor_testing_a-routerparse.o)
"_protocol_list_supports_protocol", referenced from:
"_protover_all_supported", referenced from:
_summarize_protover_flags in libtor-testing.a(src_or_libtor_testing_a-routerparse.o)
_handle_missing_protocol_warning_impl in libtor-testing.a(src_or_libtor_testing_a-networkstatus.o)
"_protocol_list_supports_protocol", referenced from:
ld: symbol(s) not found for architecture x86_64
_summarize_protover_flags in libtor-testing.a(src_or_libtor_testing_a-routerparse.o)
clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation)
Makefile:4785: recipe for target 'src/test/fuzz/fuzz-http-connect' failed
make[1]: *** [src/test/fuzz/fuzz-http-connect] Error 1
ld: symbol(s) not found for architecture x86_64
clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [src/test/fuzz/fuzz-http] Error 1
Makefile:4775: recipe for target 'src/test/fuzz/fuzz-http' failed
make[1]: Leaving directory '/var/tmp/build/tor-master'
make: *** [all] Error 2
```Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/25895Cross-compiling tor rust for Windows is broken2020-06-16T00:46:29ZGeorg KoppenCross-compiling tor rust for Windows is brokenI managed to cross-compile at least a rust compiler for 64bit Windows but tor is not prepared for that:
```
x86_64-w64-mingw32-gcc -mwindows -fstack-protector-all -Wstack-protector --param ssp-buffer-size=4 -fno-strict-overflow -Wno-mis...I managed to cross-compile at least a rust compiler for 64bit Windows but tor is not prepared for that:
```
x86_64-w64-mingw32-gcc -mwindows -fstack-protector-all -Wstack-protector --param ssp-buffer-size=4 -fno-strict-overflow -Wno-missing-field-initializers -Wformat -Wformat-security -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-all -Wstack-protector --param ssp-buffer-size=1 -fasynchronous-unwind-tables -Wall -fno-strict-aliasing -Waddress -Warray-bounds -Wdate-time -Wdouble-promotion -Wduplicated-cond -Wextra -Wfloat-conversion -Wignored-attributes -Winit-self -Wlogical-op -Wmissing-field-initializers -Wmissing-format-attribute -Wmissing-noreturn -Wnormalized=nfkc -Wnull-dereference -Woverlength-strings -Woverride-init -Wshadow -Wshift-count-negative -Wshift-count-overflow -Wshift-negative-value -Wshift-overflow=2 -Wsizeof-array-argument -Wstrict-overflow=1 -Wsuggest-attribute=format -Wsuggest-attribute=noreturn -Wswitch-bool -Wsync-nand -Wtrampolines -Wunused-but-set-parameter -Wunused-but-set-variable -Wunused-const-variable=2 -Wunused-local-typedefs -Wvariadic-macros -W -Wfloat-equal -Wundef -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -Wredundant-decls -Wchar-subscripts -Wcomment -Wformat=2 -Wwrite-strings -Wnested-externs -Wbad-function-cast -Wswitch-enum -Waggregate-return -Wpacked -Wunused -Wunused-parameter -Wold-style-definition -Wmissing-declarations -mwindows -Wl,--dynamicbase -Wl,--nxcompat -Wl,--enable-reloc-section -lssp -L/var/tmp/dist/mingw-w64/gcclibs -Wl,--nxcompat -Wl,--dynamicbase -o src/tools/tor-resolve.exe src/tools/tor-resolve.o src/common/libor.a src/common/libor-ctime.a ./src/rust/target/release/tor_rust.lib -lws2_32 -luserenv
x86_64-w64-mingw32-gcc: error: ./src/rust/target/release/tor_rust.lib: No such file or directory
```
We don't want to have a *lib file I think. What we get instead when cross-compiling (libtor_rust.a) looks actually promising.Tor: 0.3.4.x-finalAlex XuAlex Xuhttps://gitlab.torproject.org/legacy/trac/-/issues/9382Crash in Tor on Windows2020-06-15T23:47:09ZTracCrash in Tor on WindowsFaulting application name: tor.exe, version: 0.0.0.0, time stamp: 0x5177f094
Faulting module name: tor.exe, version: 0.0.0.0, time stamp: 0x5177f094
Exception code: 0x40000015
Fault offset: 0x00064e01
Faulting process id: 0x160c
Faulting...Faulting application name: tor.exe, version: 0.0.0.0, time stamp: 0x5177f094
Faulting module name: tor.exe, version: 0.0.0.0, time stamp: 0x5177f094
Exception code: 0x40000015
Fault offset: 0x00064e01
Faulting process id: 0x160c
Faulting application start time: 0x01ce8fc9235599b0
Faulting application path: C:\Users\Public\Tor Browser\App\tor.exe
Faulting module path: C:\Users\Public\Tor Browser\App\tor.exe
Report Id: 94073d30-fbbc-11e2-87ca-90fba62c9f2a
Fault bucket , type 0
Event Name: APPCRASH
Response: Not available
Cab Id: 0
Problem signature:
P1: tor.exe
P2: 0.0.0.0
P3: 5177f094
P4: tor.exe
P5: 0.0.0.0
P6: 5177f094
P7: 40000015
P8: 00064e01
P9:
P10:
Analysis symbol:
Rechecking for solution: 0
Report Id: 94073d30-fbbc-11e2-87ca-90fba62c9f2a
Report Status: 0
**Trac**:
**Username**: badadimTor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/171Mac startup script failing on OSX 10.42020-06-15T23:45:59ZTracMac startup script failing on OSX 10.4From memory Tor stopped working after I did the latest OSX 10.4 upgrades. It now fails to start from the startup script with the error
<MACHINE>:~ <USER>$ Jul 22 14:26:57.559 [notice] Tor v0.1.0.12. This is experimental software. Do no...From memory Tor stopped working after I did the latest OSX 10.4 upgrades. It now fails to start from the startup script with the error
<MACHINE>:~ <USER>$ Jul 22 14:26:57.559 [notice] Tor v0.1.0.12. This is experimental software. Do not rely on it for strong anonymity.
Jul 22 14:26:57.576 [err] switch_id(): Error setting GID: Operation not permitted
Jul 22 14:26:57.577 [err] init_from_config(): Acting on config options left us in a broken state. Dying.
However running /Library/Tor/tor as my user it has no such problem.
Jul 22 14:33:26.843 [notice] Tor v0.1.0.12. This is experimental software. Do not rely on it for strong anonymity.
Jul 22 14:33:26.846 [notice] Initialized libevent version 1.1a using method poll
Jul 22 14:33:33.862 [notice] Tor has successfully opened a circuit. Looks like it's working.
I have removed and reinstalled Tor since doing the OSX upgrades as well as trying the 0.1.1 version, both failing to start.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: dledmondsAndrew LewmanAndrew Lewman