- tor-commits - lists.torproject.org

[tor/maint-0.2.2] fix some comments before they create conflicts
by arma＠torproject.org 26 Apr '11

26 Apr '11

commit 9d673dcd206289bceb8f5ff527e63336ef0a50b9 Author: Roger Dingledine <arma(a)torproject.org> Date: Tue Apr 26 11:28:49 2011 -0400 fix some comments before they create conflicts --- src/or/rephist.c | 44 +++++++++++++++++++++++--------------------- 1 files changed, 23 insertions(+), 21 deletions(-) diff --git a/src/or/rephist.c b/src/or/rephist.c index 524cd1d..5703e3e 100644 --- a/src/or/rephist.c +++ b/src/or/rephist.c @@ -992,10 +992,10 @@ find_next_with(smartlist_t *sl, int i, const char *prefix) return -1; } -/** How many bad times has parse_possibly_bad_iso_time parsed? */ +/** How many bad times has parse_possibly_bad_iso_time() parsed? */ static int n_bogus_times = 0; /** Parse the ISO-formatted time in s into *time_out, but - * rounds any pre-1970 date to Jan 1, 1970. */ + * round any pre-1970 date to Jan 1, 1970. */ static int parse_possibly_bad_iso_time(const char *s, time_t *time_out) { @@ -1288,7 +1288,7 @@ commit_max(bw_array_t *b) b->total_in_period = 0; } -/** Shift the current observation time of 'b' forward by one second. */ +/** Shift the current observation time of b forward by one second. */ static INLINE void advance_obs(bw_array_t *b) { @@ -1318,16 +1318,16 @@ advance_obs(bw_array_t *b) static INLINE void add_obs(bw_array_t *b, time_t when, uint64_t n) { - /* Don't record data in the past. */ - if (when<b->cur_obs_time) - return; + if (when < b->cur_obs_time) + return; /* Don't record data in the past. */ + /* If we're currently adding observations for an earlier second than * 'when', advance b->cur_obs_time and b->cur_obs_idx by an - * appropriate number of seconds, and do all the other housekeeping */ - while (when>b->cur_obs_time) { + * appropriate number of seconds, and do all the other housekeeping. */ + while (when > b->cur_obs_time) { /* Doing this one second at a time is potentially inefficient, if we start with a state file that is very old. Fortunately, it doesn't seem to - show up in profiles, so we can just ignore it for now. */ + show up in profiles, so we can just ignore it for now. */ advance_obs(b); } @@ -1375,7 +1375,7 @@ bw_arrays_init(void) dir_write_array = bw_array_new(); } -/** We read num_bytes more bytes in second when. +/** Remember that we read num_bytes bytes in second when. * * Add num_bytes to the current running total for when. * @@ -1396,7 +1396,7 @@ rep_hist_note_bytes_written(size_t num_bytes, time_t when) add_obs(write_array, when, num_bytes); } -/** We wrote num_bytes more bytes in second when. +/** Remember that we wrote num_bytes bytes in second when. * (like rep_hist_note_bytes_written() above) */ void @@ -1406,8 +1406,8 @@ rep_hist_note_bytes_read(size_t num_bytes, time_t when) add_obs(read_array, when, num_bytes); } -/** We wrote num_bytes more directory bytes in second when. - * (like rep_hist_note_bytes_written() above) +/** Remember that we wrote num_bytes directory bytes in second + * when. (like rep_hist_note_bytes_written() above) */ void rep_hist_note_dir_bytes_written(size_t num_bytes, time_t when) @@ -1415,8 +1415,8 @@ rep_hist_note_dir_bytes_written(size_t num_bytes, time_t when) add_obs(dir_write_array, when, num_bytes); } -/** We read num_bytes more directory bytes in second when. - * (like rep_hist_note_bytes_written() above) +/** Remember that we read num_bytes directory bytes in second + * when. (like rep_hist_note_bytes_written() above) */ void rep_hist_note_dir_bytes_read(size_t num_bytes, time_t when) @@ -1511,7 +1511,8 @@ rep_hist_fill_bandwidth_history(char *buf, size_t len, const bw_array_t *b) } /** Allocate and return lines for representing this server's bandwidth - * history in its descriptor. + * history in its descriptor. We publish these lines in our extra-info + * descriptor. */ char * rep_hist_get_bandwidth_lines(void) @@ -1559,7 +1560,7 @@ rep_hist_get_bandwidth_lines(void) } /** Write a single bw_array_t into the Values, Ends, Interval, and Maximum - * entries of an or_state_t. */ + * entries of an or_state_t. Done before writing out a new state file. */ static void rep_hist_update_bwhist_state_section(or_state_t *state, const bw_array_t *b, @@ -1619,7 +1620,8 @@ rep_hist_update_bwhist_state_section(or_state_t *state, smartlist_add(*s_maxima, cp); } -/** Update state with the newest bandwidth history. */ +/** Update state with the newest bandwidth history. Done before + * writing out a new state file. */ void rep_hist_update_state(or_state_t *state) { @@ -1643,7 +1645,7 @@ rep_hist_update_state(or_state_t *state) } /** Load a single bw_array_t from its Values, Ends, Maxima, and Interval - * entries in an or_state_t. */ + * entries in an or_state_t. Done while reading the state file. */ static int rep_hist_load_bwhist_state_section(bw_array_t *b, const smartlist_t *s_values, @@ -1718,7 +1720,7 @@ rep_hist_load_bwhist_state_section(bw_array_t *b, return retval; } -/** Set bandwidth history from our saved state. */ +/** Set bandwidth history from the state file we just loaded. */ int rep_hist_load_state(or_state_t *state, char **err) { @@ -1766,7 +1768,7 @@ static smartlist_t *predicted_ports_times=NULL; static void add_predicted_port(time_t now, uint16_t port) { - /* XXXX we could just use uintptr_t here, I think. */ + /* XXXX we could just use uintptr_t here, I think. -NM */ uint16_t *tmp_port = tor_malloc(sizeof(uint16_t)); time_t *tmp_time = tor_malloc(sizeof(time_t)); *tmp_port = port;

1 0

[tor/master] Fix more of bug 2704
by nickm＠torproject.org 26 Apr '11

26 Apr '11

commit 6fde2b46d2cc2345ec955b1ed9674a777e5e8716 Author: Sebastian Hahn <sebastian(a)torproject.org> Date: Tue Apr 26 15:33:08 2011 +0200 Fix more of bug 2704 The last entry of the *Maxima values in the state file was inflated by a factor of NUM_SECS_ROLLING_MEASURE (currently 10). This could lead to a wrong maximum value propagating through the state file history. --- changes/bug2704 | 5 +++++ src/or/rephist.c | 3 ++- 2 files changed, 7 insertions(+), 1 deletions(-) diff --git a/changes/bug2704 b/changes/bug2704 new file mode 100644 index 0000000..821b38b --- /dev/null +++ b/changes/bug2704 @@ -0,0 +1,5 @@ + o Major bugfixes: + - When writing our maximum bw for the current interval to the state + file, don't wrongly inflate that value by a factor of 10 anymore. + Fixes more of bug 2704. + diff --git a/src/or/rephist.c b/src/or/rephist.c index fb091d5..9146fce 100644 --- a/src/or/rephist.c +++ b/src/or/rephist.c @@ -1614,7 +1614,8 @@ rep_hist_update_bwhist_state_section(or_state_t *state, } tor_asprintf(&cp, U64_FORMAT, U64_PRINTF_ARG(b->total_in_period & ~0x3ff)); smartlist_add(*s_values, cp); - tor_asprintf(&cp, U64_FORMAT, U64_PRINTF_ARG(b->max_total & ~0x3ff)); + maxval = b->max_total / NUM_SECS_ROLLING_MEASURE; + tor_asprintf(&cp, U64_FORMAT, U64_PRINTF_ARG(maxval & ~0x3ff)); smartlist_add(*s_maxima, cp); }

1 0

[tor/master] Merge remote-tracking branch 'sebastian/bug2704' into maint-0.2.2
by nickm＠torproject.org 26 Apr '11

26 Apr '11

commit f083347adf40164aac3b77d118ec372c89178d5a Merge: 4c789ec 6fde2b4 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Apr 26 11:07:48 2011 -0400 Merge remote-tracking branch 'sebastian/bug2704' into maint-0.2.2 changes/bug2704 | 5 +++++ src/or/rephist.c | 3 ++- 2 files changed, 7 insertions(+), 1 deletions(-)

1 0

[tor/master] Fix compilation in last patch
by nickm＠torproject.org 26 Apr '11

26 Apr '11

commit 1cff525973c9e3934a4e1661b721b8a13d20ff72 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Apr 26 11:14:46 2011 -0400 Fix compilation in last patch --- src/or/rephist.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/or/rephist.c b/src/or/rephist.c index 9146fce..524cd1d 100644 --- a/src/or/rephist.c +++ b/src/or/rephist.c @@ -1570,6 +1570,7 @@ rep_hist_update_bwhist_state_section(or_state_t *state, { char *cp; int i,j; + uint64_t maxval; if (*s_values) { SMARTLIST_FOREACH(*s_values, char *, val, tor_free(val)); @@ -1603,7 +1604,6 @@ rep_hist_update_bwhist_state_section(or_state_t *state, /* Set i to first position in circular array */ i = (b->num_maxes_set <= b->next_max_idx) ? 0 : b->next_max_idx; for (j=0; j < b->num_maxes_set; ++j,++i) { - uint64_t maxval; if (i >= NUM_TOTALS) i = 0; tor_asprintf(&cp, U64_FORMAT, U64_PRINTF_ARG(b->totals[i] & ~0x3ff));

1 0

[tor/master] Merge remote-tracking branch 'origin/maint-0.2.2'
by nickm＠torproject.org 26 Apr '11

26 Apr '11

commit 6a726d34e175e40cbf86617f9f9c761b52929f96 Merge: 075d904 1cff525 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Apr 26 11:15:03 2011 -0400 Merge remote-tracking branch 'origin/maint-0.2.2' changes/bug2704 | 5 +++++ src/or/rephist.c | 5 +++-- 2 files changed, 8 insertions(+), 2 deletions(-)

1 0

[tor/maint-0.2.2] Fix compilation in last patch
by nickm＠torproject.org 26 Apr '11

26 Apr '11

commit 1cff525973c9e3934a4e1661b721b8a13d20ff72 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Apr 26 11:14:46 2011 -0400 Fix compilation in last patch --- src/or/rephist.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/or/rephist.c b/src/or/rephist.c index 9146fce..524cd1d 100644 --- a/src/or/rephist.c +++ b/src/or/rephist.c @@ -1570,6 +1570,7 @@ rep_hist_update_bwhist_state_section(or_state_t *state, { char *cp; int i,j; + uint64_t maxval; if (*s_values) { SMARTLIST_FOREACH(*s_values, char *, val, tor_free(val)); @@ -1603,7 +1604,6 @@ rep_hist_update_bwhist_state_section(or_state_t *state, /* Set i to first position in circular array */ i = (b->num_maxes_set <= b->next_max_idx) ? 0 : b->next_max_idx; for (j=0; j < b->num_maxes_set; ++j,++i) { - uint64_t maxval; if (i >= NUM_TOTALS) i = 0; tor_asprintf(&cp, U64_FORMAT, U64_PRINTF_ARG(b->totals[i] & ~0x3ff));

1 0

[tor/maint-0.2.2] Fix more of bug 2704
by nickm＠torproject.org 26 Apr '11

26 Apr '11

commit 6fde2b46d2cc2345ec955b1ed9674a777e5e8716 Author: Sebastian Hahn <sebastian(a)torproject.org> Date: Tue Apr 26 15:33:08 2011 +0200 Fix more of bug 2704 The last entry of the *Maxima values in the state file was inflated by a factor of NUM_SECS_ROLLING_MEASURE (currently 10). This could lead to a wrong maximum value propagating through the state file history. --- changes/bug2704 | 5 +++++ src/or/rephist.c | 3 ++- 2 files changed, 7 insertions(+), 1 deletions(-) diff --git a/changes/bug2704 b/changes/bug2704 new file mode 100644 index 0000000..821b38b --- /dev/null +++ b/changes/bug2704 @@ -0,0 +1,5 @@ + o Major bugfixes: + - When writing our maximum bw for the current interval to the state + file, don't wrongly inflate that value by a factor of 10 anymore. + Fixes more of bug 2704. + diff --git a/src/or/rephist.c b/src/or/rephist.c index fb091d5..9146fce 100644 --- a/src/or/rephist.c +++ b/src/or/rephist.c @@ -1614,7 +1614,8 @@ rep_hist_update_bwhist_state_section(or_state_t *state, } tor_asprintf(&cp, U64_FORMAT, U64_PRINTF_ARG(b->total_in_period & ~0x3ff)); smartlist_add(*s_values, cp); - tor_asprintf(&cp, U64_FORMAT, U64_PRINTF_ARG(b->max_total & ~0x3ff)); + maxval = b->max_total / NUM_SECS_ROLLING_MEASURE; + tor_asprintf(&cp, U64_FORMAT, U64_PRINTF_ARG(maxval & ~0x3ff)); smartlist_add(*s_maxima, cp); }

1 0

[tor/maint-0.2.2] Merge remote-tracking branch 'sebastian/bug2704' into maint-0.2.2
by nickm＠torproject.org 26 Apr '11

26 Apr '11

commit f083347adf40164aac3b77d118ec372c89178d5a Merge: 4c789ec 6fde2b4 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Apr 26 11:07:48 2011 -0400 Merge remote-tracking branch 'sebastian/bug2704' into maint-0.2.2 changes/bug2704 | 5 +++++ src/or/rephist.c | 3 ++- 2 files changed, 7 insertions(+), 1 deletions(-)

1 0

r24678: {projects} Improve style more (projects/articles/browser-privacy)
by Robert Ransom 26 Apr '11

26 Apr '11

Author: rransom Date: 2011-04-26 15:06:46 +0000 (Tue, 26 Apr 2011) New Revision: 24678 Modified: projects/articles/browser-privacy/W3CIdentity.tex Log: Improve style more Modified: projects/articles/browser-privacy/W3CIdentity.tex =================================================================== --- projects/articles/browser-privacy/W3CIdentity.tex 2011-04-26 15:06:06 UTC (rev 24677) +++ projects/articles/browser-privacy/W3CIdentity.tex 2011-04-26 15:06:46 UTC (rev 24678) @@ -251,9 +251,9 @@ the cache to store identifiers. It does this by limiting the scope of the cache to the top-level origin in the URL bar. This has the effect that commonly sourced content elements are fetched and cached repeatedly, but this -is the desired property. Each of these prevalent content elements can be -crafted to include unique identifiers for each user, tracking users who -attempt to avoid tracking by clearing cookies. +is necessary to prevent linkability: each of these content elements can be +crafted to include an identifier unique to each user, thus tracking users who +attempt to avoid tracking by clearing normal cookies. The Mozilla development wiki describes an origin model improvement for cookie transmission @@ -266,7 +266,7 @@ current site. % XXXX I can't tell what this paragraph is supposed to mean. --RR -Similarly, one could imagine this two level dual-keyed origin isolation being +Similarly, one could imagine this two-level dual-keyed origin isolation being deployed to improve similar issues with DOM Storage and cryptographic tokens. Making the origin model for browser identifiers more closely match user

1 0

r24677: {projects} Fix style issues (projects/articles/browser-privacy)
by Robert Ransom 26 Apr '11

26 Apr '11

Author: rransom Date: 2011-04-26 15:06:06 +0000 (Tue, 26 Apr 2011) New Revision: 24677 Modified: projects/articles/browser-privacy/W3CIdentity.tex Log: Fix style issues Modified: projects/articles/browser-privacy/W3CIdentity.tex =================================================================== --- projects/articles/browser-privacy/W3CIdentity.tex 2011-04-26 15:05:12 UTC (rev 24676) +++ projects/articles/browser-privacy/W3CIdentity.tex 2011-04-26 15:06:06 UTC (rev 24677) @@ -313,12 +313,16 @@ standards coordination. Of the major private browsing modes, Google Chrome's Incognito Mode comes the -closest to conveying the idea of ``identity'' to the user, and the +closest to conveying the idea of ``identity'' to the user, and its implementation is also simple as a result. The Incognito Mode window is a -separate, stylized window that clearly conveys an alternate identity is in use -for this window, which can be used concurrent to the non-private identity. -The better UI appears to lead to less mode error (where the user forgets their -private browsing state) compared to other browsers\cite{private-browsing}. +separate, stylized window which clearly conveys that an alternate identity +is in use +in this window, which can be used concurrently with the non-private identity. +The better UI appears to lead to less mode error (in which the user forgets +whether +private browsing is enabled) than other browsers' private browsing +modes\cite{private-browsing}. +% XXXX ‘mode error’? The Mozilla Weave project appears to be proposing an identity-oriented method of managing, syncing, and storing authentication tokens, and also has use

1 0