Tor Bug Tracker & Wiki: Ticket Queryhttps://trac.torproject.org/projects/tor/query?status=!closed&version=Tor%3A+0.2.9.1-alpha&order=status
The Tor Project: anonymity onlineen-USTor Bug Tracker & Wiki/images/tor-logo.pnghttps://trac.torproject.org/projects/tor/query?status=!closed&version=Tor%3A+0.2.9.1-alpha&order=status
Trac 1.2https://trac.torproject.org/projects/tor/ticket/19926
https://trac.torproject.org/projects/tor/ticket/19926#19926: BUG warning in connection_ap_attach_pending: waiting for rendezvous desc :*Wed, 17 Aug 2016 03:03:21 GMTcypherpunks<p>
connection_ap_attach_pending: Bug: 0x613000b8d680 is no longer in circuit_wait. Its current state is waiting for rendezvous desc. Why is it on pending_entry_connections? (on Tor 0.2.9.1-alpha f6c7e131a1ceb178)
Yeah, why?
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/19926#changeloghttps://trac.torproject.org/projects/tor/ticket/29830
https://trac.torproject.org/projects/tor/ticket/29830#29830: Use UndefinedBehaviorSanitizer when the UBSan configure checks pass, rather than the ASan configure checksWed, 20 Mar 2019 09:04:16 GMTteor<p>
configure: stop using UBSan when the compiler only supports ASan
When activating the undefined behaviour sanitiser (UBSan), configure.ac
checked the address sanitiser (ASan) variables, instead of the UBSan
variables.
Fixes bug (this one); bugfix on 0.2.9.1-alpha.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/29830#changeloghttps://trac.torproject.org/projects/tor/ticket/24815
https://trac.torproject.org/projects/tor/ticket/24815#24815: Validate shared random state dates before each voting periodSat, 06 Jan 2018 22:57:43 GMTteor<p>
When tor's clock jumps, the shared random state can get out of sync with the current round.
</p>
<p>
This happens to me on a test authority on a laptop that sleeps regularly. But it could also happen to authorities that miss a voting round because they are under heavy load. (I have seen clock jumps happen on Linux and BSD under the recent heavy load.)
</p>
<p>
I see this message when I restart my authority:
</p>
<pre class="wiki">Jan 07 09:48:13.179 [info] or_state_load: Loaded state from "/Users/USER/tor/auth/auth-sr-3e/state"
Jan 07 09:48:14.977 [info] disk_state_validate: SR: Disk state valid after/until times are invalid.
Jan 07 09:48:14.984 [info] sr_state_update: SR: State prepared for upcoming voting period (2018-01-06 23:00:00). Upcoming phase is reveal (counters: 0 commit &amp; 1 reveal rounds).
Jan 07 09:48:16.026 [info] or_state_save: Saved state to "/Users/USER/tor/auth/auth-sr-3e/state"
</pre><p>
Even though this message was logged just before I killed it:
</p>
<pre class="wiki">Jan 07 09:47:45.328 [info] or_state_save: Saved state to "/Users/USER/tor/auth/auth-sr-3e/state"
</pre>Resultshttps://trac.torproject.org/projects/tor/ticket/24815#changeloghttps://trac.torproject.org/projects/tor/ticket/29831
https://trac.torproject.org/projects/tor/ticket/29831#29831: Backport "enable expensive hardening message is wrong with static library builds"Wed, 20 Mar 2019 09:06:49 GMTteor<p>
If we backport <a class="closed ticket" href="https://trac.torproject.org/projects/tor/ticket/24558" title="#24558: defect: enable expensive hardening message is wrong with static library builds (closed: fixed)">#24558</a> to 0.2.9, then <a class="needs_revision ticket" href="https://trac.torproject.org/projects/tor/ticket/29528" title="#29528: defect: UndefinedBehaviorSanitizer errors should fail the unit tests (needs_revision)">#29528</a> should be a trivial merge forward.
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/29831#changeloghttps://trac.torproject.org/projects/tor/ticket/29832
https://trac.torproject.org/projects/tor/ticket/29832#29832: Use the correct library names when UBSan isn't supportedWed, 20 Mar 2019 09:33:52 GMTteor<p>
More typos
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/29832#changeloghttps://trac.torproject.org/projects/tor/ticket/25784
https://trac.torproject.org/projects/tor/ticket/25784#25784: Misleading error message when asking for IPv6 in a network with no IPv6-capable exitsThu, 12 Apr 2018 00:50:22 GMTpastly<p>
I created a small test Tor network. 3 authorities, 7 relays, 3 exits. Great.
</p>
<p>
I didn't set <code>IPv6Exit 1</code> on any of the exits.
</p>
<p>
I had a client try to request <code>::1</code> over this Tor network on a hand crafted circuit (it makes sense to ask an exit to connect to localhost when this is all local ... trust me). I got the following confusing error message on the client.
</p>
<blockquote class="citation">
<p>
[warn] I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's not going to work. Did you perhaps ask for an IPv6 address on an IPv4Only port, or vice versa?
</p>
</blockquote>
<p>
I think it's important to point out (again) that I was hand crafting these circuits and was not considering IPv6 support. That said, I don't know what Tor would do if I let it make the circuit for me and it couldn't find an IPv6-supporting exit.
</p>
<p>
As you can see, I'm talking myself out of this being a bug and it just being me screwing things up for myself. I was encouraged to make a ticket though, so here we are.
</p>
<p>
If rewriting the error message is the solution, maybe after fixing the "fulfil" typo, we should add "It's also possible we couldn't find any exits supporting the IP version you want to use"
</p>
<p>
I'm picking 0.3.5.x-final just because I've been told you have to pick a milestone or else your tickets generally fall through the cracks. :)
</p>
Resultshttps://trac.torproject.org/projects/tor/ticket/25784#changelog