Custom Query (26254 matches)


Show under each result:

Results (31 - 33 of 26254)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Ticket Resolution Summary Owner Reporter
#976 fixed complete nonfunction on fresh install Aerospaced


MS XP home V 2002 SP2

Firefox/3.1b3 GTB5

XML Parsing Error: undefined entity Location: jar:file:///C:/Program%20Files/Mozilla%20Firefox%203.1%20Beta%203/chrome/toolkit.jar!/content/global/netError.xhtml Line Number 60, Column 12: <title>&loadError.label;</title>

When I turn it on and try to go to Google homepage via any means I get the above error. All results for any website similar to above.

[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]

#988 fixed Different TLS certs for incoming vs outgoing arma

We should learn to present different TLS certs for incoming connections vs outgoing connections.

The motivating example is bridges. They want to show the same identity to people who connect, yet behave like clients when they connect to other relays (e.g. change keys when they change IP addresses).

(Of course, this change would provide a new way to test for bridges: if a Tor connects to you, connect back and see if the cert is different. But at least that's an active test that requires the bridge to connect to you first. But then, the attack I describe above only kicks in when the bridge connects to you. Hm.)

[Automatically added by flyspray2trac: Operating System: All]

#997 fixed Hidden services fail to load if you have a stale descriptor karsten arma

Using git head.

In connection_ap_handshake_rewrite_and_attach(), we check rend_cache_lookup_entry(). If >0 (meaning we have a rend descriptor), we then evaluate:

/ How long after we receive a hidden service descriptor do we consider

  • it valid? */


if (now - entry->received < NUM_SECONDS_BEFORE_HS_REFETCH) {

and if it's stale (we got it more than 15 minutes ago), we call

log_info(LD_REND, "Stale descriptor %s. Re-fetching.",



However, in rend_client_refetch_v2_renddesc() we don't care whether it's stale. Towards the top of the function we call:

if (rend_cache_lookup_entry(rend_query->onion_address, -1, &e) > 0) {

log_info(LD_REND, "We would fetch a v2 rendezvous descriptor, but we "

"already have that descriptor here. Not fetching.");



So now that we don't try to fetch v0 rend descriptors, that means that Tor simply times out on all socks requests to hidden services for which we have a stale descriptor.

Presumably this is a bug on 0.2.1.x and 0.2.0.x too.

My original rend desc design was "if you have a fresh one, use it. If you have one but it's stale, fetch a new one; then whether you get a new one or no, use the one you have." We seem to have clobbered that design in (r13540) when we added support for v0 and v2 rend descs. In any case, refetching after 15 minutes was cheap back in the days of Tor 0.0.9, but is expensive now.

So the two extremes we have are: 1) connection_ap_handshake_rewrite_and_attach() which says "it's stale after 15 minutes; try to fetch a new one if it's stale" and 2) / Time period for which a v2 descriptor will be valid. */ #define REND_TIME_PERIOD_V2_DESC_VALIDITY (24*60*60)

Do we want something in between?

(Thanks to neoeinstein for tracking down the bug.)

[Automatically added by flyspray2trac: Operating System: All]

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Note: See TracQuery for help on using queries.