mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-27 13:53:31 +01:00
Bridges now behave like clients with respect to time intervals for
downloading new consensus documents. Bridge users now wait until the end of the interval, so their bridge will be sure to have a new consensus document. svn:r12696
This commit is contained in:
parent
b277954501
commit
75c38a2c88
@ -17,6 +17,12 @@ Changes in version 0.2.0.13-alpha - 2007-12-??
|
|||||||
- Stop being so aggressive about fetching v2 dir info if your
|
- Stop being so aggressive about fetching v2 dir info if your
|
||||||
DirPort is on but your ORPort is off.
|
DirPort is on but your ORPort is off.
|
||||||
|
|
||||||
|
o Major features:
|
||||||
|
- Bridges now behave like clients with respect to time intervals for
|
||||||
|
downloading new consensus documents. Bridge users now wait until
|
||||||
|
the end of the interval, so their bridge will be sure to have a
|
||||||
|
new consensus document.
|
||||||
|
|
||||||
o Minor bugfixes:
|
o Minor bugfixes:
|
||||||
- The fix in 0.2.0.12-alpha cleared the "hsdir" flag in v3 network
|
- The fix in 0.2.0.12-alpha cleared the "hsdir" flag in v3 network
|
||||||
consensus documents when there are too many relays at a single
|
consensus documents when there are too many relays at a single
|
||||||
|
@ -24,11 +24,13 @@ Status: Open
|
|||||||
1.1. PublishServerDescriptor
|
1.1. PublishServerDescriptor
|
||||||
|
|
||||||
To configure your relay to be a bridge relay, just add
|
To configure your relay to be a bridge relay, just add
|
||||||
|
BridgeRelay 1
|
||||||
PublishServerDescriptor bridge
|
PublishServerDescriptor bridge
|
||||||
to your torrc. This will cause your relay to publish its descriptor
|
to your torrc. This will cause your relay to publish its descriptor
|
||||||
to the bridge authorities rather than to the default authorities.
|
to the bridge authorities rather than to the default authorities.
|
||||||
|
|
||||||
Alternatively, you can say
|
Alternatively, you can say
|
||||||
|
BridgeRelay 1
|
||||||
PublishServerDescriptor 0
|
PublishServerDescriptor 0
|
||||||
which will cause your relay to not publish anywhere. This could be
|
which will cause your relay to not publish anywhere. This could be
|
||||||
useful for private bridges.
|
useful for private bridges.
|
||||||
@ -40,28 +42,17 @@ Status: Open
|
|||||||
can supply their bridge users with cached copies of all the various
|
can supply their bridge users with cached copies of all the various
|
||||||
Tor network information.
|
Tor network information.
|
||||||
|
|
||||||
Right now (0.2.0.11-alpha) we require that bridges turn their DirPort on
|
As for Tor 0.2.0.13-alpha, bridges will answer begin_dir questions
|
||||||
-- which means both that we answer BEGIN_DIR requests and that we fetch
|
(and cache dir info they see so the answers will be more useful)
|
||||||
and cache directory information in an aggressive way like other servers.
|
whether their DirPort is enabled or not. (After all, we don't care if
|
||||||
|
they have an open or reachable DirPort to answer begin_dir questions.)
|
||||||
|
|
||||||
But:
|
We need to investigate if there are any anonymity worries with answering
|
||||||
a) we don't enforce that DirPort is on, since it's not clear how to
|
BEGIN_DIR requests when our DirPort is off. I claim that we don't open
|
||||||
detect if the user meant to be a bridge. So it's easy to set up a bridge
|
any new attacks: it's still a fine question to ask what partitioning
|
||||||
relay that silently refuses BEGIN_DIR requests and is thus useless.
|
attacks there are when you can query a Tor client about its current
|
||||||
b) We don't actually care if they have an open or reachable DirPort. So
|
directory opinions, but these attacks already exist when DirPort is on.
|
||||||
at some point we should separate having an open DirPort from answering
|
We should investigate this in 0.2.1.x.
|
||||||
directory questions. Which leads to:
|
|
||||||
c) We need to investigate if there are any anonymity worries with
|
|
||||||
answering BEGIN_DIR requests when our DirPort is off. If there aren't,
|
|
||||||
we should drop the DirPort requirement.
|
|
||||||
|
|
||||||
I claim that we don't open any new attacks by answering BEGIN_DIR
|
|
||||||
questions when DirPort is off: it's still a fine question to ask what
|
|
||||||
partitioning attacks there are when you can query a Tor client about
|
|
||||||
its current directory opinions, but these attacks already exist when
|
|
||||||
DirPort is on.
|
|
||||||
|
|
||||||
We need to answer this issue in 0.2.0.x.
|
|
||||||
|
|
||||||
1.3. Exit policy
|
1.3. Exit policy
|
||||||
|
|
||||||
|
@ -1096,8 +1096,11 @@ dirserv_dump_directory_to_string(char **dir_out,
|
|||||||
int
|
int
|
||||||
directory_fetches_from_authorities(or_options_t *options)
|
directory_fetches_from_authorities(or_options_t *options)
|
||||||
{
|
{
|
||||||
|
/* XXX if options->FetchDirInfoEagerly, return 1 */
|
||||||
if (options->DirPort == 0)
|
if (options->DirPort == 0)
|
||||||
return 0;
|
return 0;
|
||||||
|
if (options->BridgeRelay == 1)
|
||||||
|
return 0;
|
||||||
/* XXX if dirport not advertised, return 0 too */
|
/* XXX if dirport not advertised, return 0 too */
|
||||||
if (!server_mode(options))
|
if (!server_mode(options))
|
||||||
return 0;
|
return 0;
|
||||||
|
@ -1058,12 +1058,21 @@ update_consensus_networkstatus_fetch_time(time_t now)
|
|||||||
/* But only in the first half-interval after that. */
|
/* But only in the first half-interval after that. */
|
||||||
dl_interval = interval/2;
|
dl_interval = interval/2;
|
||||||
} else {
|
} else {
|
||||||
/* Give all the caches enough time to download the consensus.*/
|
/* We're an ordinary client or a bridge. Give all the caches enough
|
||||||
|
* time to download the consensus. */
|
||||||
start = c->fresh_until + (interval*3)/4;
|
start = c->fresh_until + (interval*3)/4;
|
||||||
/* But download the next one before this one is expired. */
|
/* But download the next one well before this one is expired. */
|
||||||
dl_interval = ((c->valid_until - start) * 7 )/ 8;
|
dl_interval = ((c->valid_until - start) * 7 )/ 8;
|
||||||
/* XXX020 do something different if
|
|
||||||
* directory_fetches_dir_info_like_bridge_user() */
|
/* If we're a bridge user, make use of the numbers we just computed
|
||||||
|
* to choose the rest of the interval *after* them. */
|
||||||
|
if (directory_fetches_dir_info_like_bridge_user(options)) {
|
||||||
|
/* Give all the *clients* enough time to download the consensus. */
|
||||||
|
start = start + dl_interval + CONSENSUS_MIN_SECONDS_BEFORE_CACHING;
|
||||||
|
/* But try to get it before ours actually expires. */
|
||||||
|
dl_interval = (c->valid_until - start) -
|
||||||
|
CONSENSUS_MIN_SECONDS_BEFORE_CACHING;
|
||||||
|
}
|
||||||
}
|
}
|
||||||
if (dl_interval < 1)
|
if (dl_interval < 1)
|
||||||
dl_interval = 1;
|
dl_interval = 1;
|
||||||
|
Loading…
Reference in New Issue
Block a user