Re: [tor-bugs] #22206 [Core Tor/Tor]: Fetching compressed consensus behaves unpredictably strange

[Tor Bug Tracker & Wiki]

#22206: Fetching compressed consensus behaves unpredictably strange
--+
 Reporter:  Sebastian |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * cc: ahf (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22202 [Internal Services/Tor Sysadmin Team]: Please create email alias for Tommy

[Tor Bug Tracker & Wiki]

#22202: Please create email alias for Tommy
-+
 Reporter:  ewyatt   |  Owner:  tpa
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

 * status:  new => closed
 * resolution:   => fixed


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22186 [Internal Services/Tor Sysadmin Team]: Apache HTTP Server

[Tor Bug Tracker & Wiki]

#22186: Apache HTTP Server
-+-
 Reporter:  sainslie |  Owner:  tpa
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by weasel):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 Please provide incremental changes to the existing headers, indicate which
 service they are for, and what the changes are doing, exactly, instead of
 just dumping a huge security.conf we can't possibly use this way on us.

 Thanks for trying to help

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20319 [Internal Services/Tor Sysadmin Team]: set HPKP headers on onionoo

[Tor Bug Tracker & Wiki]

#20319: set HPKP headers on onionoo
-+-
 Reporter:  weasel   |  Owner:  tpa
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by weasel):

 Thanks for trying to help, sainslie, but apache is not anywhere in that
 stack.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22203 [Core Tor/Tor]: Should a hup reload the geoip files?

[Tor Bug Tracker & Wiki]

#22203: Should a hup reload the geoip files?
--+-
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Description changed by arma:

Old description:

> In config.c in config_maybe_load_geoip_files_() we have this line:
> {{{
>   /*  Reload GeoIPFile on SIGHUP. -NM */
> }}}
>
> and sure enough, it looks like there's nothing in main.c's do_hup() that
> would make us reload the geoip files.
>
> It would be relatively easy to do I think:
> * In do_hup(), right around the call to routerlist_reset_warnings(), we
> call something in geoip.c that tells it to no longer consider itself
> initialized. Maybe that call is something like clear_geoip_db().
> * Then in config_maybe_load_geoip_files_(), since geoip_is_loaded()
> returns 0, it loads them.
>
> Things get tricky though: catalyst asked if reloading the geoip files
> messes up the statistics gathering.
>
> If reloading the geoip files *does* mess up statistics gathering, we have
> ourselves a minor bug, since config_maybe_load_geoip_files_() does reload
> them if the GeoIPFile location changes.
>
> But it turns out to be more complicated than that, since
> geoip_load_file() only clears selective things: it clears
> geoip_ipv4_entries and geoip_ipv6_entries, but it leaves geoip_countries
> alone! And I see elsewhere, at the bottom of geoip_note_client_seen(),
> that we are keeping statistics directly in the geoip_countries smartlist:
> {{{
>   geoip_country_t *country = smartlist_get(geoip_countries,
> country_idx);
>   ++country->n_v3_ns_requests;
> }}}
>
> So we would not want to call clear_geoip_db() on hup, or we'd lose some
> stats.
>
> I guess that means if we want to make do_hup reload the geoip stats file,
> the better (non-invasive) plan is to have a boolean
> want_to_reload_geoip{4,6} in geoip.c that we turn on in do_hup, and then
> we check the right boolean in geoip_is_loaded().
>
> I think there's a big argument for growing some good unit tests here,
> around "what happens when we reload this, collect those stats, reload
> that, examine those other stats, etc", so things are either subtly broken
> right now, or awfully fragile.

New description:

 In config.c in config_maybe_load_geoip_files_() we have this line:
 {{{
   /*  Reload GeoIPFile on SIGHUP. -NM */
 }}}

 and sure enough, it looks like there's nothing in main.c's do_hup() that
 would make us reload the geoip files.

 It would be relatively easy to do I think:
 * In do_hup(), right around the call to routerlist_reset_warnings(), we
 call something in geoip.c that tells it to no longer consider itself
 initialized. Maybe that call is something like clear_geoip_db().
 * Then in config_maybe_load_geoip_files_(), since geoip_is_loaded()
 returns 0, it loads them.

 Things get tricky though: catalyst asked if reloading the geoip files
 messes up the statistics gathering.

 If reloading the geoip files *does* mess up statistics gathering, we have
 ourselves a minor bug, since config_maybe_load_geoip_files_() does reload
 them if the GeoIPFile location changes.

 But it turns out to be more complicated than that, since geoip_load_file()
 only clears selective things: it clears geoip_ipv4_entries and
 geoip_ipv6_entries, but it leaves geoip_countries alone! And I see
 elsewhere, at the bottom of geoip_note_client_seen(), that we are keeping
 statistics directly in the geoip_countries smartlist:
 {{{
   geoip_country_t *country = smartlist_get(geoip_countries,
 country_idx);
   ++country->n_v3_ns_requests;
 }}}

 So we would not want to call clear_geoip_db() on hup, or we'd lose some
 stats.

 I guess that means if we want to make do_hup reload the geoip stats file,
 the better (non-invasive) plan is to have a boolean
 want_to_reload_geoip{4,6} in geoip.c that we turn on in do_hup, and then
 we check the right boolean in geoip_is_loaded().

 I think there's a big argument for growing some good unit tests here,
 around "what happens when we reload this, collect those stats, reload
 that, examine those other stats, etc", since things are either subtly
 broken right now, or awfully fragile.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22206 [Core Tor/Tor]: Fetching compressed consensus behaves unpredictably strange

[Tor Bug Tracker & Wiki]

#22206: Fetching compressed consensus behaves unpredictably strange
--+
 Reporter:  Sebastian |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by yawning):

 https://hg.python.org/cpython/file/tip/Lib/http/client.py#l1172

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22206 [Core Tor/Tor]: Fetching compressed consensus behaves unpredictably strange

[Tor Bug Tracker & Wiki]

#22206: Fetching compressed consensus behaves unpredictably strange
--+
 Reporter:  Sebastian |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by Sebastian):

 Ok, my jessie stuff sat behind a proxy doing who knows what. So the
 behaviour I'm seeing on jessie is the same as arma, at least.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22206 [Core Tor/Tor]: Fetching compressed consensus behaves unpredictably strange

[Tor Bug Tracker & Wiki]

#22206: Fetching compressed consensus behaves unpredictably strange
--+
 Reporter:  Sebastian |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by yawning):

 The code MUST respond to `.z` GETs/`Accept-Encoding: identity` requests
 with a response consisting of zlib compressed payload, because the
 identity transform of a `.z` file is a `.z` file, not plaintext.

 The code MAY responmd to `.z` GETs/`Accept-Encoding:` that does not
 include `identity` requests by doing an extra compression pass on the `.z`
 payload.  Alternatively, it could return an error (`406 Not Acceptable`
 seems like the right one?).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22206 [Core Tor/Tor]: Fetching compressed consensus behaves unpredictably strange

[Tor Bug Tracker & Wiki]

#22206: Fetching compressed consensus behaves unpredictably strange
--+
 Reporter:  Sebastian |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by yawning):

 or/directory.c:directory_handle_command_get()
 {{{
   if ((header = http_get_header(headers, "Accept-Encoding: "))) {
 compression_methods_supported = parse_accept_encoding_header(header);
 tor_free(header);
   } else {
 compression_methods_supported = (1u << NO_METHOD);
 if (zlib_compressed_in_url)
   compression_methods_supported |= (1u << ZLIB_METHOD);
   }
 }}}

 That's at least one of the problems.  If `zlib_compressed_in_url` is set,
 the data to be transferred before `Accept-Encoding: ` is taken into
 account should be zlib compressed payload.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22206 [Core Tor/Tor]: Fetching compressed consensus behaves unpredictably strange

[Tor Bug Tracker & Wiki]

#22206: Fetching compressed consensus behaves unpredictably strange
--+
 Reporter:  Sebastian |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by Sebastian):

 Note that the headers aren't necessarily relevant, my jessie's headers are
 these (according to a wget to a nc -l arma set up for me):

 {{{
 GET /foo.z HTTP/1.1
 User-Agent: Wget/1.16 (linux-gnu)
 Accept: */*
 Host: 128.31.0.47:5
 Cache-Control: max-age=259200
 Connection: keep-alive
 }}}

 yet that wget fetches an uncompressed file.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22206 [Core Tor/Tor]: Fetching compressed consensus behaves unpredictably strange

[Tor Bug Tracker & Wiki]

#22206: Fetching compressed consensus behaves unpredictably strange
--+
 Reporter:  Sebastian |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 My wget on jessie (the one that behaves ok) is sending these headers:
 {{{
 GET /tor/status-vote/current/consensus.z HTTP/1.1
 User-Agent: Wget/1.16 (linux-gnu)
 Accept: */*
 Host: 128.31.0.39:9131
 Connection: Keep-Alive
 }}}

 I assume the other wgets (the ones that misbehave) are setting an Accept-
 Encoding header.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18100 [Core Tor/Tor]: src/or/connection_edge.c typo

[Tor Bug Tracker & Wiki]

#18100: src/or/connection_edge.c typo
-+-
 Reporter:  jirib|  Owner:
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.9
 Severity:  Normal   | Resolution:
 Keywords:  isaremoved, nickwants029, lorax, |  Actual Points:
  tor-03-unspecified-201612  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:20 d4fq0fQAgoJ]:
 > System: Linux 4.10.5-1-ARCH x86_64, tor 0.2.9.9
 >
 > It appears to me that TPROXYing only works for me when connection
 tracking is active. When I apply the patch TPROXYing works for me no
 matter if conntection tracking is active or not.
 >
 > ...
 > Looking at the code it seems that getsockopt() is called. The patch
 activates a code path where getsockname() is called instead which seems to
 make it work even if no connection tracking is active. Maybe the author of
 that code can shed more light into that?

 I think the behaviour you describe is what we want.

 I re-wrote the code to make it behave consistently and improve how it was
 structured back in early 2016.

 I don't know enough about transparent proxying to say anything else with
 any confidence.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22206 [Core Tor/Tor]: Fetching compressed consensus behaves unpredictably strange

[Tor Bug Tracker & Wiki]

#22206: Fetching compressed consensus behaves unpredictably strange
--+
 Reporter:  Sebastian |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 I've left moria1 running the shiny new code (git commit 2e4f3b36), so
 others can make progress on the ticket.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22206 [Core Tor/Tor]: Fetching compressed consensus behaves unpredictably strange

[Tor Bug Tracker & Wiki]

#22206: Fetching compressed consensus behaves unpredictably strange
--+
 Reporter:  Sebastian |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 {{{
  Content-Encoding: identity
  network-status-version 3
  vote-status consensus
  consensus-method 25Y
  that does not look like the identity encoding of a .z file to me
  so tor is spitting back uncompressed data at me
  wget is setting `Accept-Encoding: identity`
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22206 [Core Tor/Tor]: Fetching compressed consensus behaves unpredictably strange

[Tor Bug Tracker & Wiki]

#22206: Fetching compressed consensus behaves unpredictably strange
--+
 Reporter:  Sebastian |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 {{{git show 1bc2}}} has all the keywords I would expect to search for.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #22206 [Core Tor/Tor]: Fetching compressed consensus behaves unpredictably strange

[Tor Bug Tracker & Wiki]

#22206: Fetching compressed consensus behaves unpredictably strange
--+
 Reporter:  Sebastian |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 This morning, we had this fun notice from doctor:

 {{{
 ERROR: Unable to retrieve the consensus from moria1
 (http://128.31.0.39:9131/tor/status-vote/current/consensus.z): Error -3
 while decompressing data: incorrect header check
 ERROR: Unable to retrieve the vote from moria1
 (http://128.31.0.39:9131/tor/status-vote/current/authority.z): Error -3
 while decompressing data: incorrect header check
 }}}

 The file from that hour is available at
 http://seul.org/~arma/consensus-20170508.z.

 The next weird thing is that using three different wget versions from
 different platforms, using

 {{{
 wget http://128.31.0.39:9131/tor/status-vote/current/consensus.z
 }}}

 to fetch a consensus from moria gives an uncompressed file. yawning and I
 can reproduce that, arma can not. Something fishy seems to be going on?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22206>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22205 [Applications/Tor Browser Sandbox]: Figure out how to fix `crypto/tls`.

[Tor Bug Tracker & Wiki]

#22205: Figure out how to fix `crypto/tls`.
--+-
 Reporter:  yawning   |  Owner:  yawning
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by yawning):

 Since we attempt to play nice and use the CDN for downloads, any tweaks to
 the cipher suite list need to take what the CDN runs into account.  A
 quick check suggests that at least `aus1.torproject.org` does not support
 `
 `TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305` or
 `TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305`, though most accesses to that
 particular host will be via the onion sans-TLS, so it matters the least.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #22205 [Applications/Tor Browser Sandbox]: Figure out how to fix `crypto/tls`.

[Tor Bug Tracker & Wiki]

#22205: Figure out how to fix `crypto/tls`.
--+-
 Reporter:  yawning   |  Owner:  yawning
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Most of the Go crypto isn't constant time.  I'm not sure if this matters
 for the install/version check/update and validation mechanisms, but if
 there is an easy way to fix this problem, it would be the sensible thing
 to do.

 The status as of today is:

  * RSA - Vartime.
  * ECC - X25519/P-224/P-256 constant time.
  * AES - Vartime unless there is AES-NI.
  * GHASH - Vartime unless there is PCLMULQDQ (AES-NI).
  * Poly1305/ChaCha20 - Constant time.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #22204 [Core Tor/Tor]: I can't list a relay in my EntryNodes if it doesn't have the Guard flag

[Tor Bug Tracker & Wiki]

#22204: I can't list a relay in my EntryNodes if it doesn't have the Guard flag
--+--
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.6
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 In the past, I could do

 {{{
 src/or/tor entrynodes moria1
 }}}

 and voila, I would begin using my Tor with moria1 as my entry node.

 In the new world order, post prop#271 I assume, I instead get this
 complaint:
 {{{
 May 08 20:27:42.394 [warn] Your configuration excludes 100% of all
 possible guards. That's likely to make you stand out from the rest of the
 world.
 May 08 20:27:42.394 [notice] Starting with guard context "restricted"
 May 08 20:27:42.405 [notice] Bootstrapped 80%: Connecting to the Tor
 network
 May 08 20:27:43.425 [warn] Failed to find node for hop 0 of our path.
 Discarding this circuit.
 }}}
 and then I never bootstrap.

 This is clearly a regression. Is it intentional, and I should go read
 guard-spec.txt for why, or is it accidental?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20319 [Internal Services/Tor Sysadmin Team]: set HPKP headers on onionoo

[Tor Bug Tracker & Wiki]

#20319: set HPKP headers on onionoo
-+-
 Reporter:  weasel   |  Owner:  tpa
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by sainslie):

 * status:  new => merge_ready


Comment:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 I implemented it.
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQIcBAEBAgAGBQJZEQwBAAoJEM18vpeSzTzCQ4YQALDBYQQOnVfw7EL5KxzLOrBc
 GgbLeC3ya1uh/5y0JC+3fBQS03Mjt057U7jPaJUbvYp3wdv4i8kWI2FwEI2kdD1y
 bNjDKLJVEm1nLrDTK7Ns7Jn5tWbOk6ERC43ahrl8TVuqr6tSMgn00pUkkiYbQnql
 ks7jS9Ev1R30s8WF41v65ooFcrCR2n4PykLAQAugEpc2USz8B+jdx6pNs8HO5XC6
 615fLEHx+oSHCUzvOF6kAb/M0Ec3ZpEBlMPLNFQyYCZBTdeUCziQ1mH7wLB8wKef
 27PfwKnU7NM1WeH80M94if5QbE3rg3pkDkvHsxDzmfOGosF9glEpdInW1Dx1PhHE
 itaVM/I9LXTydtQICYn6WSRxUIVcga5oIJHo8xBDUacNLUX2WebEeuq2327M7WGY
 Xb+p4igk4Wo5GJDnMNgxAWjLicmo86oo5ej4d9eIhy2biHIiexiAoLOgJfdvTAIr
 qKwWxJ/85Dqz3H9ibhOtvT556UY4xak40a+ghZTFMNebTyDtCBl4b0BjTgx6TErT
 UhPbQmFB+lRshlDZx98ZUc/VgMnR8yRdiDiJ+V3ORoIzjtNWYymYdoUhdDb6DPeS
 FtzSNJTq6eRorlEpH4tOKMihJTyEPOf6gluOCyZflBZJPP6M4fCNnL6VpvCaj0+P
 sJxy5rqiEB2iCiRiX88L
 =V4sg
 -END PGP SIGNATURE-

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #22203 [Core Tor/Tor]: Should a hup reload the geoip files?

[Tor Bug Tracker & Wiki]

#22203: Should a hup reload the geoip files?
--+-
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 In config.c in config_maybe_load_geoip_files_() we have this line:
 {{{
   /*  Reload GeoIPFile on SIGHUP. -NM */
 }}}

 and sure enough, it looks like there's nothing in main.c's do_hup() that
 would make us reload the geoip files.

 It would be relatively easy to do I think:
 * In do_hup(), right around the call to routerlist_reset_warnings(), we
 call something in geoip.c that tells it to no longer consider itself
 initialized. Maybe that call is something like clear_geoip_db().
 * Then in config_maybe_load_geoip_files_(), since geoip_is_loaded()
 returns 0, it loads them.

 Things get tricky though: catalyst asked if reloading the geoip files
 messes up the statistics gathering.

 If reloading the geoip files *does* mess up statistics gathering, we have
 ourselves a minor bug, since config_maybe_load_geoip_files_() does reload
 them if the GeoIPFile location changes.

 But it turns out to be more complicated than that, since geoip_load_file()
 only clears selective things: it clears geoip_ipv4_entries and
 geoip_ipv6_entries, but it leaves geoip_countries alone! And I see
 elsewhere, at the bottom of geoip_note_client_seen(), that we are keeping
 statistics directly in the geoip_countries smartlist:
 {{{
   geoip_country_t *country = smartlist_get(geoip_countries,
 country_idx);
   ++country->n_v3_ns_requests;
 }}}

 So we would not want to call clear_geoip_db() on hup, or we'd lose some
 stats.

 I guess that means if we want to make do_hup reload the geoip stats file,
 the better (non-invasive) plan is to have a boolean
 want_to_reload_geoip{4,6} in geoip.c that we turn on in do_hup, and then
 we check the right boolean in geoip_is_loaded().

 I think there's a big argument for growing some good unit tests here,
 around "what happens when we reload this, collect those stats, reload
 that, examine those other stats, etc", so things are either subtly broken
 right now, or awfully fragile.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22202 [Internal Services/Tor Sysadmin Team]: Please create email alias for Tommy

[Tor Bug Tracker & Wiki]

#22202: Please create email alias for Tommy
-+-
 Reporter:  ewyatt   |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Sounds good -- an email forward is all that's needed at this point, not a
 whole ldap account. (I just spoke to Tommy to confirm.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #22202 [Internal Services/Tor Sysadmin Team]: Please create email alias for Tommy

[Tor Bug Tracker & Wiki]

#22202: Please create email alias for Tommy
-+-
 Reporter:  ewyatt   |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Tommy is our new writer/editor. Here's his info:
 Thank you!


 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 First name: Tommy
 Last name: Collison
 Desired uid/email alias: tom...@torproject.org
 Forwarding address: to...@collison.ie
 GPG public key fingerprint: BB4B 1E3A B96C 3FCD 0482  89E0 1A91 F49B A783
 00BD
 -BEGIN PGP SIGNATURE-

 iQIcBAEBCgAGBQJZEP1JAAoJELoMlAD4D5HO5nIP/0D5Cq6qzuB/nT9HmUOoBiiH
 xc7m3V8+LF8z4MeDJBuIPimNwTcPo/ndYiG7++sqDTiLSA1lkX35J2xRCTb3YrMI
 N3xlTcYwbMdsvsAhPQmSMH1I0ujGw3X8vNoSS8mQpjo2nJeB2QlsxBXZE9VPyNoR
 VlGYT5Gal4LCG6ioaD/v/BGWuS/A2Jq+1W02lCum5BqPPMBREEmRwE3FMArqYVyC
 8XbczfmZ0Rw8OEDJYLZb4/Ah1X/GwrNCvW04X2ixOBCnbtlxl28Syv8MuZ2FFhXi
 p4WbI88aBvp9ErKssVx4mvcZHGSqvIHTeGOjD7+nySqdOnBA91r4INXrYyQehwDG
 J/jQCUN0pC6TJ3XCCh/yrGSA63na9fRJMSuaNo9p1CL8yTUmUxFU5NgmsicUGmEE
 vnwAK88hH7lZlTXFPD3gjrnLxHCFoVMc5fVXGGWDhwJlC8niQPhtx+5EqaxZ/PHc
 Rw7dlr8SCOyZwC/Y1fbasulNLqOmeAlZYRVtCynyPAd8d24im9h8Mvq43bazTKxC
 +fCXRw91WwkBibNK1bb8FZnMgMOGQzPBiFWyrUSC7A9jijmI31Cj5vNHjdlnAURC
 3InWaVl+UC+vIOUPjeEO0KlSmnA7VE6AK0rpQ9xlCNQglPxDgCvXhIK63P4N4TGv
 hMT5KvsPfc/e1qiVCOuC
 =A0qp

 -END PGP SIGNATURE-
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22177 [Core Tor/Tor]: Remove dead code in test_options_validate_impl()

[Tor Bug Tracker & Wiki]

#22177: Remove dead code in test_options_validate_impl()
--+
 Reporter:  ahf   |  Owner:  ahf
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by catalyst):

 * cc: catalyst (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20534 [Core Tor/Tor]: Revise hard-coded download schedules

[Tor Bug Tracker & Wiki]

#20534: Revise hard-coded download schedules
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  accepted
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, CoreTorTeam201611,   |  Actual Points:
  triaged-out-20170124, 031-reach|
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by catalyst):

 * cc: catalyst (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22101 [Core Tor/Tor]: Can't have relative DataDirectory with CookieAuthentication enabled

[Tor Bug Tracker & Wiki]

#22101: Can't have relative DataDirectory with CookieAuthentication enabled
--+
 Reporter:  pastly|  Owner:  Jigsaw52
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by Jigsaw52):

 Yes, the problem only happens when RunAsDaemon is set.

 What happens is that, when RunAsDaemon is set, the relative paths are
 relative to the DataDirectory but when RunAsDaemon is not set, they are
 relative to the tor starting directory.

 I tried to fix the issue by making the relative paths always relative to
 the tor starting directory.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #22201 [User Experience/Website]: Wireframes for community.torproject.org subpages

[Tor Bug Tracker & Wiki]

#22201: Wireframes for community.torproject.org subpages
-+--
 Reporter:  linda|  Owner:  antonela
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #22121
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 = Objective =

 Design how to lay out the content for dev.torproject.org's subpages:

 * __community.torproject.org/volunteer__: a page that encourages
 volunteers, tells what it's like, and houses the community council, and
 behavioral guidelines materials.
 * __community.torproject.org/outreach__:  a page hosting all images,
 videos, audio, request for pamphlets, worksheets, papers, tutorials, etc.
 related to community. I think a way to organize all of this would be the
 main challenge.
 * __community.torproject.org/help__: To be completely honest with you, I
 don't know how I feel about a call for help page because it has to
 constantly be maintained. Plus, I think that the better thing to do is to
 just get in contact with the community team lead right away and they can
 just inform the people of what needs to be done. So instead of listing a
 bunch of tasks, let's  design something that gets the user to get in
 contact with the community team lead in the least frictionless way.

 = Definitions =

 * wireframes are rough sketches that illustrate the general idea of the
 design. A wireframe lets you talk about content placement and layout while
 abstracting finer details such as font, color, styling, and other
 considerations.

 = Methodology =

 Antonela will independently sketch her best first design of the sub pages,
 according to previous sitemapping and content organization work. Linda
 will then review her design, make comments, and Antonela will iterate once
 before counting it done for this ticket. But this will just result in the
 initial designs, and these designs will be iterated on some more with
 feedback from stakeholders.

 = Results =

 ''Linda will place wireframes here once the task is complete. ''

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18797 [Metrics/metrics-lib]: create a DescriptorGenerator?

[Tor Bug Tracker & Wiki]

#18797: create a DescriptorGenerator?
-+-
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by atagar):

 Thanks Isis! The trixy scheme I planned was to send you a BrideDB patch to
 use Stem's new descriptor creation once it had signing support. That way I
 can make sure the new functions meet your needs as well as mine, and
 adjust them if not.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #22200 [User Experience/Website]: Wireframes for support.torproject.org subpages

[Tor Bug Tracker & Wiki]

#22200: Wireframes for support.torproject.org subpages
-+
 Reporter:  linda|  Owner:  linda,
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #22121
   Points:   |   Reviewer:
  Sponsor:   |
-+
 = Objective =

 Design how to lay out the content for dev.torproject.org's subpages:

 The support page is a bit different, since we plan for all the support
 subpages look the same, with different content in the middle. I think that
 the work I'd be doing for the subpages is to 1) make wireframes that
 explains what that really means 2) make wireframes that shows the
 interactivity between page components and 3) decide what is going to go on
 the sidebar as topics, and to organize all the information in a way that
 makes sense.

 = Definitions =

 * wireframes are rough sketches that illustrate the general idea of the
 design. A wireframe lets you talk about content placement and layout while
 abstracting finer details such as font, color, styling, and other
 considerations.

 = Methodology =

 Linda will independently sketch her best first design of the sub pages,
 according to previous sitemapping and content organization work. Antonela
 will then review her design, make comments, and Linda will iterate once
 before counting it done for this ticket. But this will just result in the
 initial designs, and these designs will be iterated on some more with
 feedback from stakeholders.

 = Results =

 ''Linda will place wireframes here once the task is complete. ''

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #22199 [User Experience/Website]: Wireframes for dev.torproject.org subpages

[Tor Bug Tracker & Wiki]

#22199: Wireframes for dev.torproject.org subpages
-+--
 Reporter:  linda|  Owner:  antonela
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #22121
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 = Objective =

 Design how to lay out the content for dev.torproject.org's subpages:

 * __dev.torproject.org/teams__: putting the team roadmap and projects for
 each team is actually pretty intense to update/maintain at the website
 level. Developers also didn't want this, so I think this page can just
 include detailed descriptions of the teams.
 * __dev.torproject.org/getting-started__: we link to git, irc, and trac on
 the dev landing banner. I think this page can explain the technology that
 we use to do the work, organizational-wide. I would like for this to have
 two functions 1) give a basic overview of what the thing does (i.e. "we
 use IRC for almost all live communication") 2) link to external links to
 help them get started (i.e. a tutorial on IRC from irc people)  and 3) why
 we use it (i.e. "Although it's behind the times, we choose it because of
 these security properties.").
 * __dev.torproject.org/resources__: a page that houses links to all the
 important manuals and tutorials here. We're not going to create new
 tutorials or go through the trouble of updating it on the website if they
 update their link, etc. What's important for this page is that there might
 be lots and lots of links here, so we should have it organized in a way
 that people can easily find what they need.

 = Definitions =

 * wireframes are rough sketches that illustrate the general idea of the
 design. A wireframe lets you talk about content placement and layout while
 abstracting finer details such as font, color, styling, and other
 considerations.

 = Methodology =

 Antonela will independently sketch her best first design of the sub pages,
 according to previous sitemapping and content organization work. Linda
 will then review her design, make comments, and Antonela will iterate once
 before counting it done for this ticket. But this will just result in the
 initial designs, and these designs will be iterated on some more with
 feedback from stakeholders.

 = Results =

 ''Linda will place wireframes here once the task is complete. ''

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18797 [Metrics/metrics-lib]: create a DescriptorGenerator?

[Tor Bug Tracker & Wiki]

#18797: create a DescriptorGenerator?
-+-
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by isis):

 Hey, thanks for getting this conversation started!  Leekspin can do
 signing, but it's a bit out of date in terms of missing some newly-
 introduced fields in descriptors.  Also, leekspin was primarily meant to
 generate bridge descriptors, and then later HS descriptors, to fuzz the
 parsers.

 I'm happy to expand leekspin, or combine it into something else, as long
 as I can still fuzz test BridgeDB's parsers and logic with it.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21969 [Core Tor/Tor]: We're missing descriptors for some of our primary entry guards

[Tor Bug Tracker & Wiki]

#21969: We're missing descriptors for some of our primary entry guards
---+
 Reporter:  asn|  Owner:
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-guard, tor-bridge  |  Actual Points:
Parent ID: | Points:  1.5
 Reviewer: |Sponsor:  SponsorU
---+

Comment (by alecmuffett):

 The log messages in my case are:

 {{{
 May 03 08:58:45.000 [notice] Heartbeat: Tor's uptime is 12:00 hours, with
 6 circuits open. I've sent 2.28 MB and received 9.59 MB.
 May 03 09:21:47.000 [notice] Our directory information is no longer up-to-
 date enough to build circuits: We're missing descriptors for some of our
 primary entry guards
 May 03 09:21:47.000 [notice] I learned some more directory information,
 but not enough to build a circuit: We're missing descriptors for some of
 our primary entry guards
 May 03 09:21:48.000 [notice] We now have enough directory information to
 build circuits.
 May 03 09:58:45.000 [notice] Heartbeat: Tor's uptime is 13:00 hours, with
 7 circuits open. I've sent 2.44 MB and received 10.39 MB.
 May 03 10:11:48.000 [notice] Tor has successfully opened a circuit. Looks
 like client functionality is working.
 May 03 10:11:48.000 [notice] Tor has successfully opened a circuit. Looks
 like client functionality is working.
 May 03 10:58:45.000 [notice] Heartbeat: Tor's uptime is 14:00 hours, with
 6 circuits open. I've sent 2.54 MB and received 10.49 MB.
 }}}

 ...and then later...

 {{{
 May 04 17:25:50.000 [notice] Our directory information is no longer up-to-
 date enough to build circuits: We're missing descriptors for some of our
 primary entry guards
 May 04 17:25:50.000 [notice] I learned some more directory information,
 but not enough to build a circuit: We're missing descriptors for some of
 our primary entry guards
 May 04 17:58:48.000 [notice] Heartbeat: Tor's uptime is 1 day 21:00 hours,
 with 3 circuits open. I've sent 6.51 MB and received 25.41 MB.
 }}}

 ...with no subsequent `We now have enough...`

 At the risk of sounding facile, what about replacing the `some of our
 primary` message with a `N-out-of-M` fraction?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #22198 [User Experience/Website]: Wireframes for torproject.org subpages

[Tor Bug Tracker & Wiki]

#22198: Wireframes for torproject.org subpages
-+
 Reporter:  linda|  Owner:  linda
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #22121
   Points:   |   Reviewer:
  Sponsor:   |
-+
 = Objective =

 Design how to lay out the content for torproject.org's subpages:

 * __torproject.org/download__: a page dedicated to just downloading Tor
 Browser, similar to https://www.mozilla.org/en-US/firefox/new/, but with
 more instructions since there are failure cases.
 * __torproject.org/about__: a page with all the institutional stuff--
 mission statement, disclaimers, tax statements, employee numbers, etc.
 * __torproject.org/people__: a page with all the people in tor. The board,
 employees, sponsors, and any relevant people.
 * __torproject.org/press__: a list of all the press we got, a huge list of
 stuff and I need to organize all the articles.
 * __torproject.org/contact__: a page that shows various contact points
 (executive director, head of board, hr, support, etc.) for Tor, with the
 aim to list everyone contactable here (kind of like a public address
 book).

 = Definitions =

 * wireframes are rough sketches that illustrate the general idea of the
 design. A wireframe lets you talk about content placement and layout while
 abstracting finer details such as font, color, styling, and other
 considerations.

 = Methodology =

 Linda will independently sketch her best first design of the sub pages,
 according to previous sitemapping and content organization work. Antonela
 will then review her design, make comments, and Linda will iterate once
 before counting it done for this ticket. But this will just result in the
 initial designs, and these designs will be iterated on some more with
 feedback from stakeholders.

 = Results =

 ''Linda will place wireframes here once the task is complete. ''

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by mrphs):

 * cc: mrphs (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22077 [User Experience/Website]: Wireframes for the landing pages of torproject.org portals

[Tor Bug Tracker & Wiki]

#22077: Wireframes for the landing pages of torproject.org portals
-+
 Reporter:  linda|  Owner:  linda
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:  #22121   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by linda):

 * type:  defect => task


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22077 [User Experience/Website]: Wireframes for the landing pages of torproject.org portals

[Tor Bug Tracker & Wiki]

#22077: Wireframes for the landing pages of torproject.org portals
-+
 Reporter:  linda|  Owner:  linda
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:  #22121   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by linda):

 * status:  assigned => closed
 * resolution:   => fixed


Old description:

> = Objective =
>
> Design how to lay out the most important content for torproject.org,
> dev.torproject.org, support.torproject.org, and community.torproject.org.
>
> = Definitions =
>
> * wireframes are rough sketches that illustrate the general idea of the
> design. A wireframe lets you talk about content placement and layout
> while abstracting finer details such as font, color, styling, and other
> considerations.
> * landing pages are the official terms for the "front page" of a website.
> If you visit torproject.org, the first page that you see is the landing
> page.
> * portals refer to the different subsites mentioned above (dev, support,
> community)
>
> = Methodology =
>
> Linda and Antonela will independently sketch their best first design of
> the four landing pages, limiting themselves to including only the content
> deemed important for the front page on #21950. They will compare their
> designs, talk about why they made the design choices that they did, and
> then collaboratively work on a final design from those two independent
> designs.
>
> = Results =
>
> ''Linda will put the wireframes here once she is done.''

New description:

 = Objective =

 Design how to lay out the most important content for torproject.org,
 dev.torproject.org, support.torproject.org, and community.torproject.org.

 = Definitions =

 * wireframes are rough sketches that illustrate the general idea of the
 design. A wireframe lets you talk about content placement and layout while
 abstracting finer details such as font, color, styling, and other
 considerations.
 * landing pages are the official terms for the "front page" of a website.
 If you visit torproject.org, the first page that you see is the landing
 page.
 * portals refer to the different subsites mentioned above (dev, support,
 community)

 = Methodology =

 Linda and Antonela will independently sketch their best first design of
 the four landing pages, limiting themselves to including only the content
 deemed important for the front page on #21950. They will compare their
 designs, talk about why they made the design choices that they did, and
 then collaboratively work on a final design from those two independent
 designs.

 = Results =

 We have the first iteration of the landing pages. We'll reach out for
 feedback, update them, and repeat this process a couple times.

 [[Image(INITIAL-tpo-landing.png,500px)]]

 [[Image(INITIAL-dev-landing.png,500px)]]

 [[Image(INITIAL-support-landing.png,500px)]]

 [[Image(INITIAL-community-landing.png,500px)]]

 You can find the the
 [https://trac.torproject.org/projects/tor/attachment/ticket/22077/INITIAL-
 tpo-landing-page-wireframes.sketch sketch file] and the
 [https://trac.torproject.org/projects/tor/attachment/ticket/22077/INITIAL-
 tpo-landing-page-wireframes.pdf pdf of the pages] here.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by alecmuffett):

 * cc: alec.muffett@… (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21886 [Applications/Tor Browser]: Downloading of binary files stalls at 0/0 bytes in Tor Browser based on ESR52 with e10s off

[Tor Bug Tracker & Wiki]

#21886: Downloading of binary files stalls at 0/0 bytes in Tor Browser based on
ESR52 with e10s off
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  defect   | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-7.0-must-alpha,   |  Actual Points:
  ff52-esr, TorBrowserTeam201705,|
  GeorgKoppen201705  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by mcs):

 Replying to [comment:21 gk]:
 > Well, that's not the same as in the attachment which is why I was
 asking.

 Ah. I forgot that we posted a patch in an attachment (work in progress)
 and then later we posted a pointer to what we thought was a better patch.
 The main difference between the two patches is where our hook is added
 (`nsExternalHelperAppService::DoContent()` vs.
 `nsExternalAppHandler::OnStartRequest()`). But you probably already knew
 that...

 Do you know if the patch we posted in the attachment fixes this bug on
 Linux? We did not try it because we were hoping to find a fix for #21766
 as well, on all platforms.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22193 [Metrics/Onionoo]: add html IDs to the onionoo website for direct referencing

[Tor Bug Tracker & Wiki]

#22193: add html IDs to the onionoo website for direct referencing
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Sure, we could add ids.  For example, `consensus_weight_fraction` could
 get id `#details_relay_consensus_weight_fraction` or
 `#weights_relay_consensus_weight_fraction`, depending on which field you
 meant in your example above.

 Adding these ids would not be possible fully automatically, but it
 shouldn't be terribly hard.  Would the format above be useful?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18797 [Metrics/metrics-lib]: create a DescriptorGenerator?

[Tor Bug Tracker & Wiki]

#18797: create a DescriptorGenerator?
-+-
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by karsten):

 Thanks, atagar, for sharing your experience here!  I have to admit that
 this is not top priority for us at the moment, so we might continue using
 real descriptors or partial descriptor for testing rather than generating
 our own.  But let's keep this ticket open, and if we find out new use
 cases (or a bunch of free development time), we can start hacking on this!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21934 [Metrics/metrics-lib]: Allow extra arguments in lines containing comma-separated key-value lists

[Tor Bug Tracker & Wiki]

#21934: Allow extra arguments in lines containing comma-separated key-value 
lists
-+---
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Possibly related question that came to mind the other day: do we need to
 include lines with extra arguments in `Descriptor#getUnrecognizedLines()`?
 Or do we need another method `Descriptor#getPartiallyUnrecognizedLines()`?
 Or can we safely drop those extra arguments on the floor?  See also
 `TorperfResults#getUnrecognizedKeys()` which is somewhat related here, but
 not exactly the same.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22122 [Metrics/metrics-lib]: Add support for six new key-value pairs added by OnionPerf

[Tor Bug Tracker & Wiki]

#22122: Add support for six new key-value pairs added by OnionPerf
-+---
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Thanks for looking!  Squashed and pushed to master.

 What other renaming needs to be done?  Note that we don't need to rename
 everything, because we're still supporting parsing of historic Torperf
 files and because we're still using the Torperf format that OnionPerf
 kindly produces for us (rather than OnionPerf's own format).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21569 [Applications/Tor Browser]: Investigate and neuter fingerprinting potential of Permissions API

[Tor Bug Tracker & Wiki]

#21569: Investigate and neuter fingerprinting potential of Permissions API
-+-
 Reporter:  gk   |  Owner:
 |  arthuredelstein
 Type:  task | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must-alpha,|  Actual Points:
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by arthuredelstein):

 Replying to [comment:9 mcs]:
 > Kathy and I started to review this but got stuck on a couple of things:
 > * Where is the file `file_firstPartySpecial.html`?
 > * Should the commented out lines (e.g., for geolocation) be removed from
 `browser_permissions.js`?
 > * `PrincipalOriginAttributes::StripUserContextId()` is now an empty
 function. Is that correct?

 Thanks for noticing these things. I have cleaned them up now. Here's the
 new version:
 https://github.com/arthuredelstein/tor-browser/commit/21569+4

 Note here I am enabling isolation of permissions both by first party
 domain and container ID. As Tor Browser doesn't use containers, the change
 to container behavior should have no effect. But I took this approach
 (changing both things) because it makes writing a test with Mozilla's
 existing isolation test framework straightforward. If Mozilla decides to
 apply first-party isolation to permissions, but not to apply it to
 containers, then they will need to modify the framework. (Although my
 recommendation would be to isolate permissions by containers as well.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21766 [Applications/Tor Browser]: Tor Browser based on ESR52 with e10s enabled crashed while trying to download a file

[Tor Bug Tracker & Wiki]

#21766: Tor Browser based on ESR52 with e10s enabled crashed while trying to
download a file
-+-
 Reporter:  gk   |  Owner:  mcs
 Type:  defect   | Status:
 |  assigned
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must-alpha, tbb-   |  Actual Points:
  e10s, tbb-crash, TorBrowserTeam201705  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by mcs):

 * cc: torland (added)


Comment:

 #22195 is a duplicate.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21569 [Applications/Tor Browser]: Investigate and neuter fingerprinting potential of Permissions API

[Tor Bug Tracker & Wiki]

#21569: Investigate and neuter fingerprinting potential of Permissions API
-+-
 Reporter:  gk   |  Owner:
 |  arthuredelstein
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must-alpha,|  Actual Points:
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by arthuredelstein):

 * status:  needs_information => needs_review


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22195 [Applications/Tor Browser]: Torbrowser 7.0a3: Gah. Your tab just crashed.

[Tor Bug Tracker & Wiki]

#22195: Torbrowser 7.0a3: Gah. Your tab just crashed.
--+---
 Reporter:  torland   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by mcs):

 * status:  new => closed
 * resolution:   => duplicate


Comment:

 This is a duplicate of #21766.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20683 [Applications/Tor Browser]: Integrate selfrando into the alpha Linux 64bit builds

[Tor Bug Tracker & Wiki]

#20683: Integrate selfrando into the alpha Linux 64bit builds
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, GeorgKoppen201704, |  Actual Points:
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by gk):

 Thanks. I cherry-picked the commit to `master` (commit
 332c5b6c16f1b0915f537a4ad5af48295f80c733) and waiting for a proper tag
 from the selfrando folks for the alpha before closing this ticket.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20822 [Core Tor/Tor]: Follow-up tasks for prop271 (new guard API) implementation

[Tor Bug Tracker & Wiki]

#20822: Follow-up tasks for prop271 (new guard API) implementation
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  project  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, triaged-out-20170124, |  Actual Points:
  031-reach, TorCoreTeam201705   |
Parent ID:   | Points:  parent
 Reviewer:   |Sponsor:
-+-
Changes (by isis):

 * cc: isis (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21756 [Applications/Tor Browser]: HTTP Authentication data is still sent to third parties with ESR 52 based Tor Browser

[Tor Bug Tracker & Wiki]

#21756: HTTP Authentication data is still sent to third parties with ESR 52 
based
Tor Browser
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must-alpha,|  Actual Points:
  TorBrowserTeam201705   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by arthuredelstein):

 I think further loopholes are unlikely, but I think I should look for them
 nonetheless, just in case.

 So I think, in the interest of getting as many patches as possible into
 the alpha, I should postpone working on this again until after the alpha
 deadline.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #12600, #17193, #11101

[Tor Bug Tracker & Wiki]

Batch modification to #12600, #17193, #11101 by isis:
milestone to Tor: 0.3.2.x-final

Comment:
Deferring to 0.3.2

--
Tickets URL: 

Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21871 [Core Tor/Tor]: prop224: Change descriptor format for legacy encryption key

[Tor Bug Tracker & Wiki]

#21871: prop224: Change descriptor format for legacy encryption key
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #21888   | Points:  3
 Reviewer:   |Sponsor:  SponsorR-must
-+
Changes (by dgoulet):

 * status:  needs_revision => needs_information


Comment:

 Responded. It pushed two fixup commits but an open question for the last
 comment on the certificate reject time.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22197 [Obfuscation]: Audit all of our Go code that uses `crypto/aes`.

[Tor Bug Tracker & Wiki]

#22197: Audit all of our Go code that uses `crypto/aes`.
-+-
 Reporter:  yawning  |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by yawning):

 For the non-TLS cases, a constant time AES could be easily substituted
 (and I have one for Go, though performance is not great).  Making Go's TLS
 safe against timing attacks will require forking the TLS stack in the
 runtime library.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21969 [Core Tor/Tor]: We're missing descriptors for some of our primary entry guards

[Tor Bug Tracker & Wiki]

#21969: We're missing descriptors for some of our primary entry guards
---+
 Reporter:  asn|  Owner:
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-guard, tor-bridge  |  Actual Points:
Parent ID: | Points:  1.5
 Reviewer: |Sponsor:  SponsorU
---+
Changes (by isis):

 * cc: isis (added)
 * keywords:  tor-guard => tor-guard, tor-bridge


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21415 [Core Tor/Tor]: tor_bug_occurred_: Bug: src/or/entrynodes.c:1845: select_entry_guard_for_circuit: Non-fatal assertion !(!guard_has_descriptor(guard)) failed.

[Tor Bug Tracker & Wiki]

#21415: tor_bug_occurred_: Bug: src/or/entrynodes.c:1845:
select_entry_guard_for_circuit: Non-fatal assertion
!(!guard_has_descriptor(guard)) failed.
--+
 Reporter:  cypherpunks   |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.3-alpha
 Severity:  Normal| Resolution:  fixed
 Keywords:  030-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:  asn   |Sponsor:
--+
Changes (by isis):

 * cc: isis (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #16225 [Metrics/metrics-lib]: Unify exception/error handling in metrics-lib

[Tor Bug Tracker & Wiki]

#16225: Unify exception/error handling in metrics-lib
-+---
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Replying to [comment:8 karsten]:
 > Replying to [comment:6 iwakeh]:
 > > Regarding the code-example: [...]
 >
 > Yes, you're right, this issue is orthogonal and should be discussed on a
 different ticket.  I'll create one.

 Added as #22196.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #22197 [Obfuscation]: Audit all of our Go code that uses `crypto/aes`.

[Tor Bug Tracker & Wiki]

#22197: Audit all of our Go code that uses `crypto/aes`.
-+-
 Reporter:  yawning  |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 The implementation is not constant time (and neither is the GHASH provided
 by `crypto/cipher`) without AES-NI/PCLMULQDQ or equivalent.  I do not
 believe that we use either in a situation where it matters, but we should
 double check to confirm this.  This affects any uses of the raw primitive,
 when wrapped in the various block cipher modes, and when used via TLS.

 Known uses:

  * obfs2
  * obfs3
  * scramblesuit
  * meek without a helper

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #22196 [Metrics/metrics-lib]: Configure descriptor sources using method chaining

[Tor Bug Tracker & Wiki]

#22196: Configure descriptor sources using method chaining
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 The two descriptor sources `DescriptorReader` and `DescriptorParser` are
 instantiated by `DescriptorSourceFactory`, configured, and then executed.
 This requires state checks and leads to quite verbose application code.
 An exception to this is `DescriptorCollector` which is state-less but
 which has a method with 5 parameters, which also does not produce very
 readable code.

 We should consider switching to configuring descriptor sources using
 method chanining.  [https://gitweb.torproject.org/user/karsten/metrics-
 lib.git/commit/?h=task-16225=f8c5862bbdfa0acefbbbd7d4899b997077c20196
 Here's a code sample] from a few months ago, written for another ticket.

 iwakeh rightly
 [https://trac.torproject.org/projects/tor/ticket/16225#comment:6 commented
 on that other ticket]: "configuration of a descriptor source by fluent-
 style (or method chaining) is fine, but metrics-lib currently has the
 DescriptorSourceFactory approach, which would need to be adapted. That is,
 I see two things: the ideas around the code of DescriptorSourceBuilder are
 ideas about a new way of configuration and not exception/error handling in
 metrics-lib, i.e. a different ticket (there is one for redesign of the
 interface hierarchy, I'll look for it). Second, the current configuration
 and descriptor source instanciation need to be considered together (in
 that other ticket)."

 Not assigning to a milestone on purpose.  This likely needs more thoughts
 before we can write code and make plans for releasing that.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #16861 [Core Tor/Tor]: Pad Tor connections to collapse netflow records

[Tor Bug Tracker & Wiki]

#16861: Pad Tor connections to collapse netflow records
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  028-triage, 028-triaged, |  implemented
  pre028-patch, 201511-deferred, |  Actual Points:
  201512-deferred, tor-guard, TorCoreTeam-   |
  postponed-201604, nickm-deferred-20160905, |
  review-group-9, nickm-deferred-20161005|
Parent ID:   | Points:  6
 Reviewer:  nickm|Sponsor:
-+-
Changes (by nickm):

 * status:  merge_ready => closed
 * resolution:   => implemented


Comment:

 Merging this, at last!  Also merging mikeperry/padding_spec to torspec.
 Thanks for all the hard work here.  This is big, so let's keep an eye on
 it.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #17604 [Core Tor/Tor]: Try to use only one canonical connection

[Tor Bug Tracker & Wiki]

#17604: Try to use only one canonical connection
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorCoreTeam-postponed-201604,|  Actual Points:
  nickm-deferred-20160905, review-group-9,   |
  nickm-deferred-20161005, sponsor2  | Points:  see-
Parent ID:  #16861   |  parent
 Reviewer:  nickm|Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => closed
 * resolution:   => fixed


Comment:

 merging parent

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #17592 [Core Tor/Tor]: Clean up connection timeout logic

[Tor Bug Tracker & Wiki]

#17592: Clean up connection timeout logic
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorCoreTeam-postponed-201604,|  Actual Points:
  nickm-deferred-20160905, review-group-9,   |
  nickm-deferred-20161005, sponsor2  | Points:  see-
Parent ID:  #16861   |  parent
 Reviewer:  nickm|Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => closed
 * resolution:   => fixed


Comment:

 merging parent

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21678 [Core Tor/Tor]: Unify Windows and Unix API for tor_read_all_handle() in util.c

[Tor Bug Tracker & Wiki]

#21678: Unify Windows and Unix API for tor_read_all_handle() in util.c
--+
 Reporter:  ahf   |  Owner:  ahf
 Type:  enhancement   | Status:  accepted
 Priority:  Low   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by ahf):

 * milestone:  Tor: 0.3.1.x-final => Tor: 0.3.2.x-final


Comment:

 Postponing this to 0.3.2.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18100 [Core Tor/Tor]: src/or/connection_edge.c typo

[Tor Bug Tracker & Wiki]

#18100: src/or/connection_edge.c typo
-+-
 Reporter:  jirib|  Owner:
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.9
 Severity:  Normal   | Resolution:
 Keywords:  isaremoved, nickwants029, lorax, |  Actual Points:
  tor-03-unspecified-201612  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * cc: teor (added)


Comment:

 teor -- can you comment on d4fq0fQAgoJ's questions above before I merge?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21943 [Core Tor/Tor]: (Sandbox) Caught a bad syscall attempt (syscall getpid)

[Tor Bug Tracker & Wiki]

#21943: (Sandbox) Caught a bad syscall attempt (syscall getpid)
-+-
 Reporter:  ageisp0lis   |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.10
 Severity:  Normal   | Resolution:  fixed
 Keywords:  sandbox seccomp2 getpid  |  Actual Points:  .1
  029-backport 030-backport AffectsTails |
Parent ID:   | Points:  .1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  merge_ready => closed
 * resolution:   => fixed
 * milestone:  Tor: 0.3.1.x-final => Tor: 0.2.9.x-final


Comment:

 Merged to 0.2.9 and forwards.  Thanks!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21838 [Applications/Tor Browser]: Gitian VM creation fails on Ubuntu 16.x machines in the unmount step

[Tor Bug Tracker & Wiki]

#21838: Gitian VM creation fails on Ubuntu 16.x machines in the unmount step
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-gitian|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by boklm):

 I am able to reproduce this error in an Ubuntu 16.10 VM. It seems to be
 caused by `/usr/sbin/update-grub` returning a error when run inside the
 wheezy chroot, and then the cleanup after this error not unmounting things
 in the right order.

 I have not been able to find why update-grub is failing when we are using
 Ubuntu 16.10. The logs only say this:
 {{{
 2017-05-05 13:51:00,774 DEBUG   : ['chroot', '/tmp/tmpdGQM2s', '/usr/sbin
 /update-grub', '-y']
 2017-05-05 13:51:00,779 INFO: Searching for GRUB installation
 directory ... found: /boot/grub
 2017-05-05 13:51:00,886 INFO: Probing devices to guess BIOS drives.
 This may take a long time.
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18100 [Core Tor/Tor]: src/or/connection_edge.c typo

[Tor Bug Tracker & Wiki]

#18100: src/or/connection_edge.c typo
-+-
 Reporter:  jirib|  Owner:
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.9
 Severity:  Normal   | Resolution:
 Keywords:  isaremoved, nickwants029, lorax, |  Actual Points:
  tor-03-unspecified-201612  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 lgtm;

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22195 [Applications/Tor Browser]: Torbrowser 7.0a3: Gah. Your tab just crashed.

[Tor Bug Tracker & Wiki]

#22195: Torbrowser 7.0a3: Gah. Your tab just crashed.
--+--
 Reporter:  torland   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by torland):

 * owner:   => tbb-team
 * component:  - Select a component => Applications/Tor Browser


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21943 [Core Tor/Tor]: (Sandbox) Caught a bad syscall attempt (syscall getpid)

[Tor Bug Tracker & Wiki]

#21943: (Sandbox) Caught a bad syscall attempt (syscall getpid)
-+-
 Reporter:  ageisp0lis   |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.10
 Severity:  Normal   | Resolution:
 Keywords:  sandbox seccomp2 getpid  |  Actual Points:  .1
  029-backport 030-backport AffectsTails |
Parent ID:   | Points:  .1
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 lgtm;

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #21209, #21212, #21213, #19537, ...

[Tor Bug Tracker & Wiki]

Batch modification to #21209, #21212, #21213, #19537, #20822, #20832 by nickm:
keywords to TorCoreTeam201705
milestone to Tor: 0.3.2.x-final

Comment:
These are things I should work on during May, but they're prep work for 0.3.2 
and beyond.

--
Tickets URL: 

Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #19984, #20356, #20895, #19307

[Tor Bug Tracker & Wiki]

Batch modification to #19984, #20356, #20895, #19307 by nickm:
milestone to Tor: 0.3.2.x-final

Comment:
I don't think these are happening in 0.3.1

--
Tickets URL: 

Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22148 [Core Tor/Tor]: prop140: conformance to proposal, unhandled corner cases

[Tor Bug Tracker & Wiki]

#22148: prop140: conformance to proposal, unhandled corner cases
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  .5
Parent ID:  #13339| Points:  .5
 Reviewer:  ahf   |Sponsor:  Sponsor4
--+
Changes (by ahf):

 * reviewer:   => ahf


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21888 [Core Tor/Tor]: prop224: Groundwork for service implementation

[Tor Bug Tracker & Wiki]

#21888: prop224: Groundwork for service implementation
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #20657   | Points:  6
 Reviewer:   |Sponsor:  SponsorR-must
-+
Changes (by dgoulet):

 * milestone:  Tor: 0.3.1.x-final => Tor: 0.3.2.x-final


Comment:

 One child tickets is in 032 and most likely we'll get more of those in the
 coming weeks.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21693 [Core Tor/Tor]: prop224: HS descriptors do wasteful double-base64 encoding

[Tor Bug Tracker & Wiki]

#21693: prop224: HS descriptors do wasteful double-base64 encoding
--+
 Reporter:  asn   |  Owner:  asn
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, prop224, 031-stretch  |  Actual Points:
Parent ID:| Points:  4
 Reviewer:|Sponsor:  SponsorR-can
--+
Changes (by asn):

 * milestone:  Tor: 0.3.1.x-final => Tor: 0.3.2.x-final


Comment:

 Deferring to 0.3.2 for now.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21886 [Applications/Tor Browser]: Downloading of binary files stalls at 0/0 bytes in Tor Browser based on ESR52 with e10s off

[Tor Bug Tracker & Wiki]

#21886: Downloading of binary files stalls at 0/0 bytes in Tor Browser based on
ESR52 with e10s off
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  defect   | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-7.0-must-alpha,   |  Actual Points:
  ff52-esr, TorBrowserTeam201705,|
  GeorgKoppen201705  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by gk):

 Replying to [comment:20 mcs]:
 > Replying to [comment:19 gk]:
 > > Alright, I think I have figured out all the pieces involved. The
 problem starts with https://bugzilla.mozilla.org/show_bug.cgi?id=1321528
 being fixed in https://hg.mozilla.org/releases/mozilla-
 beta/rev/1c4863a4ff98 AND NoScript 2.9.5.2rc3 (commit
 9eab569b1d443456325e2b253f2cca65eb453c30 in the git repo at
 https://github.com/avian2/noscript). The whole suspend/resume mechanism
 got introduced there to fix the mediasource blocking for us. ;)
 >
 > Interesting. NoScript's role is confusing to me. Are you saying that
 NoScript relies on the fix for
 https://bugzilla.mozilla.org/show_bug.cgi?id=1321528 and that the same
 Mozilla fix causes this bug?

 No, NoScript does not rely on the fix. But it does channel
 suspense/resumse things starting with 2.9.5 (and the fixup in 2.9.5.2rc3)
 which is causing the problems. The Mozilla bugfix is the necessery bit on
 Mozilla's side to trigger the problem: if either that or Noscript is
 missing (or NoScript before 2.9.5.2rc3 is installed) the problem in this
 bug goes away.

 > > While I don't have assembled all of the pieces to a coherent picture
 yet, the proposed attached fix seems to be a good idea to me. mcs/brade:
 That one works across different platforms, right? If so, do you think you
 want to propose that one for review?
 >
 > No, the fix we proposed does not work on Linux (at least not for us).
 See comment:16.

 Well, that's not the same as in the attachment which is why I was asking.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22172 [Core Tor/Tor]: prop140: What to do when a diff fails to apply?

[Tor Bug Tracker & Wiki]

#22172: prop140: What to do when a diff fails to apply?
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #13339| Points:
 Reviewer:|Sponsor:  Sponsor4
--+
Changes (by nickm):

 * owner:   => nickm
 * status:  new => accepted


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #22195 [- Select a component]: Torbrowser 7.0a3: Gah. Your tab just crashed.

[Tor Bug Tracker & Wiki]

#22195: Torbrowser 7.0a3: Gah. Your tab just crashed.
--+-
 Reporter:  torland   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Major |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 When I try to download a file with Torbrowser 7.0a3 Torbrowser allways
 crashes and displays the message "Gah. Your tab just crashed."

 When starting Torbrowser with --verbose it shows

 ###!!! [Parent][DispatchAsyncMessage] Error:
 PExternalHelperApp::Msg_DivertToParentUsing Route error: message sent to
 unknown actor ID


 ###!!! [Parent][MessageChannel] Error:
 (msgtype=0x43,name=PCompositorBridge::Msg_DidComposite) Channel error:
 cannot send/recv

 [Parent 22474] WARNING: pipe error (52): Connection reset by peer: file
 /home/debian/build/tor-
 browser/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 322

 ###!!! [Parent][MessageChannel] Error:
 (msgtype=0x2C006E,name=PBrowser::Msg_ParentActivated) Channel error:
 cannot send/recv

 I have the impression that this happens since I was updated from the
 Harden channel to Alpha.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20683 [Applications/Tor Browser]: Integrate selfrando into the alpha Linux 64bit builds

[Tor Bug Tracker & Wiki]

#20683: Integrate selfrando into the alpha Linux 64bit builds
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, GeorgKoppen201704, |  Actual Points:
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by boklm):

 Replying to [comment:22 gk]:
 > `bug_20683_v9` (https://gitweb.torproject.org/user/gk/tor-browser-
 bundle.git/commit/?h=bug_20683_v9=e799bdfe114bc2103699014a0fe65b7a9542d2ba)
 is up for review. It fixes the compilation issue in comment:20 with a
 binutils patch and bumps the selfrando commit to fix a crash encountered
 while testing.

 This patch looks good to me.

 I also opened #22194 to apply the same changes into `tor-browser-
 build.git`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #22194 [Applications/Tor Browser]: Integrate selfrando into tor-browser-build.git

[Tor Bug Tracker & Wiki]

#22194: Integrate selfrando into tor-browser-build.git
--+
 Reporter:  boklm |  Owner:  boklm
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
  |  TorBrowserTeam201705
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 We should integrate the changes from #20683 into the rbm based build.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20114 [Applications/Tor Check]: check.torproject.org false-negatives "not connected through tor"

[Tor Bug Tracker & Wiki]

#20114: check.torproject.org false-negatives  "not connected through tor"
+-
 Reporter:  6h72Q484AddGha8H|  Owner:  arlolra
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Check  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-

Comment (by cypherpunks):

 again:

  Sorry. You are not using Tor.
 Your IP address appears to be: 138.197.4.77

 atlas sees two exits at that IP:
 https://atlas.torproject.org/#search/138.197.4.77

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22115 [Applications/Tor Browser]: Use i386 containers for building Tor Browser on linux32 and win32

[Tor Bug Tracker & Wiki]

#22115: Use i386 containers for building Tor Browser on linux32 and win32
--+
 Reporter:  boklm |  Owner:  boklm
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam201705  |  Actual Points:
Parent ID:  #17379| Points:
 Reviewer:|Sponsor:
--+
Changes (by boklm):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 This is done in commits d067aa03629fb87c47acf19f81ed51940ebc3ebb and
 bb32ec91b538ab17d309b645787149ff376d58e9.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21905 [Applications/Tor Browser]: Allow third-party cookies as we are isolating them to the first party in ESR52

[Tor Bug Tracker & Wiki]

#21905: Allow third-party cookies as we are isolating them to the first party in
ESR52
-+--
 Reporter:  gk   |  Owner:  tbb-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability-website, ff52-esr  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by cypherpunks):

 As ip-check.info states, this is equal to #21756 in tracking aspect. So,
 no problem to enable it.
 Also torbutton requires some clean up, as it still uses
 `privacy.thirdparty.isolate`, resulting in:
 {{{
 15:25:20.836 NS_ERROR_UNEXPECTED: Component returned failure code:
 0x8000 (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getIntPref] 1
 torbutton.js:155
 torbutton_unique_pref_observer.observe
 chrome://torbutton/content/torbutton.js:155:40
 set_valueFromPreferences
 chrome://global/content/bindings/preferences.xml:364:13
 _setValue chrome://global/content/bindings/preferences.xml:191:15
 set_value chrome://global/content/bindings/preferences.xml:198:8
 userChangedValue
 chrome://global/content/bindings/preferences.xml:1281:15
 onxblcommand
 chrome://global/content/bindings/preferences.xml:1315:9
 }}}
 from
 {{{
 switch (data) {
 case "network.cookie.cookieBehavior":
 var val =
 m_tb_prefs.getIntPref("network.cookie.cookieBehavior");
 var block_thirdparty =
 m_tb_prefs.getIntPref("privacy.thirdparty.isolate") !== 0;
 if (val == 0 && block_thirdparty) // Allow all cookies
   m_tb_prefs.setIntPref("privacy.thirdparty.isolate", 0);
 else if (val == 1 && !block_thirdparty) // Block third
 party cookies
   m_tb_prefs.setIntPref("privacy.thirdparty.isolate", 2);
 break;
 case "privacy.thirdparty.isolate":
 torbutton_update_thirdparty_prefs();
 break;
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #19842 [Metrics/metrics-lib]: offer a `LenientParser` option with metrics-lib

[Tor Bug Tracker & Wiki]

#19842: offer a `LenientParser` option with metrics-lib
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * status:  new => needs_information


Comment:

 Hmm, I don't know how to proceed with this issue.  A few thoughts:

  - We should only use new properties for new implementations of a parser
 or reader, not for a config option.  If we want a config option, let's add
 a method to the descriptor source.
  - `DescriptorReaderImpl` internally uses a `DescriptorParser` for parsing
 descriptor.  If we just want to switch to another parser, let's create a
 method `DescriptorReader#setDescriptorParser()`.  Or let's use
 `DescriptorSourceFactory` internally to create a parser instance rather
 than instantiating `DescriptorParserImpl` directly.
  - The case of non-ASCII characters in statistics lines seems rather
 special, and doesn't seem worth adding an option that 99.9% of users won't
 care about.  We could generalize and provide an option to not fail
 descriptor parsing if a single line cannot be parsed, or something like
 that.
  - If non-ASCII characters in statistics line are spec-conformant, let's
 fix metrics-lib by default.  I don't recall whether that's the case.  But
 if it's a spec violation, let's treat this case as any other spec
 violation.
  - How much do we still care about this issue?  Is there a current use
 case that would justify putting in the effort?  If yes, okay.  But if not,
 let's just close this ticket.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22193 [Metrics/Onionoo]: add html IDs to the onionoo website for direct referencing

[Tor Bug Tracker & Wiki]

#22193: add html IDs to the onionoo website for direct referencing
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by cypherpunks):

 https://lists.torproject.org/pipermail/metrics-team/2017-May/000339.html

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #22193 [Metrics/Onionoo]: add html IDs to the onionoo website for direct referencing

[Tor Bug Tracker & Wiki]

#22193: add html IDs to the onionoo website for direct referencing
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 > Hi,
 >
 > I'd like to link different tor specific terms (like CW, effective
 > family, ...) to the description on your pages.
 >
 > I noticed the individual items (ie. consensus_weight_fraction) on [1]
 > are not link-able since they do not have an html id.
 >
 > Would it be possible to automatically (without a lot of effort) add ids
 > so one can link to them directly?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21886 [Applications/Tor Browser]: Downloading of binary files stalls at 0/0 bytes in Tor Browser based on ESR52 with e10s off

[Tor Bug Tracker & Wiki]

#21886: Downloading of binary files stalls at 0/0 bytes in Tor Browser based on
ESR52 with e10s off
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  defect   | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-7.0-must-alpha,   |  Actual Points:
  ff52-esr, TorBrowserTeam201705,|
  GeorgKoppen201705  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by mcs):

 Replying to [comment:19 gk]:
 > Alright, I think I have figured out all the pieces involved. The problem
 starts with https://bugzilla.mozilla.org/show_bug.cgi?id=1321528 being
 fixed in https://hg.mozilla.org/releases/mozilla-beta/rev/1c4863a4ff98 AND
 NoScript 2.9.5.2rc3 (commit 9eab569b1d443456325e2b253f2cca65eb453c30 in
 the git repo at https://github.com/avian2/noscript). The whole
 suspend/resume mechanism got introduced there to fix the mediasource
 blocking for us. ;)

 Interesting. NoScript's role is confusing to me. Are you saying that
 NoScript relies on the fix for
 https://bugzilla.mozilla.org/show_bug.cgi?id=1321528 and that the same
 Mozilla fix causes this bug?

 > While I don't have assembled all of the pieces to a coherent picture
 yet, the proposed attached fix seems to be a good idea to me. mcs/brade:
 That one works across different platforms, right? If so, do you think you
 want to propose that one for review?

 No, the fix we proposed does not work on Linux (at least not for us). See
 comment:16.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21969 [Core Tor/Tor]: We're missing descriptors for some of our primary entry guards

[Tor Bug Tracker & Wiki]

#21969: We're missing descriptors for some of our primary entry guards
--+
 Reporter:  asn   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-guard |  Actual Points:
Parent ID:| Points:  1.5
 Reviewer:|Sponsor:  SponsorU
--+

Comment (by catalyst):

 I have noticed a few problems that I think are likely related.

 I attached a log of a failed bootstrap with obfs4.  (Tor Browser 7.0a3
 with defaults obfs4 bridge configuration)  It appears to have gotten stuck
 because none of the selected guards was reachable when trying to download
 the consensus.  (The guards look like they are selected prior to
 determining their reachability, which I vaguely recall is a countermeasure
 against some kinds of attacks, but is potentially a usability problem
 during bootstrap.)

 Note that two of the guards have the same fingerprint
 (`A832D176ECD5C7C6B58825AE22FC4C90FA249637`), and seem to be multiple
 ports on the same IP according to the TBB-generated torrc.  Maybe we
 should prevent this during guard selection?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #16225 [Metrics/metrics-lib]: Unify exception/error handling in metrics-lib

[Tor Bug Tracker & Wiki]

#16225: Unify exception/error handling in metrics-lib
-+---
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Replying to [comment:6 iwakeh]:
 > Ok, I start from the opposite direction and hopefully we meet in the
 perfect middle :-)

 Okay, let's try that! :)

 > The use-case this ticket mostly refers to is bulk processing, i.e. there
 is a bunch of descriptors somewhere (file system, remote server) and
 metrics-lib fetches, synchronizes, and parses these files. One constraint
 is that there will always be some descriptors that cannot be parsed.

 Agreed.

 > From this scenario, I would conclude that methods like readDescriptors,
 parseDescriptors, collectDescriptors don't throw
 DescriptorParseExceptions, but simply process as much as possible and
 provide a list of problematic descriptors at the end, which the API using
 program can choose to ignore or process.
 > Does this sound like the right use-case description?

 It does sound like the right use-case description!

 The part that needs more thoughts is when and how we should provide
 problematic descriptors and related error cases.  Providing them at the
 end can easily lead to out-of-memory situations, because we might have to
 keep more and more problematic descriptors in memory until we're finally
 done parsing.  Maybe we can include problematic descriptors in line with
 non-problematic ones.

 How about this: whenever we can't parse a descriptor, we include a
 `Descriptor` instance with the raw contents we cannot parse in the
 descriptor queue.  And we include a new method `Descriptor#getException()`
 that returns the `DescriptorParseException` that we ran into, or `null` if
 we didn't run into an exception while parsing.

 Similarly, if we run into an exception while downloading files from a
 remote server or while reading files from the file system, so before
 splitting contents into descriptor-sized chunks and attempting to parse
 those, we include a `Descriptor` instance without descriptor contents and
 with just the exception.

 I could see how this works even without breaking existing code, because
 any code processing `Descriptor` instances should check whether they're
 `instanceof` whatever they had hoped to get before casting the instance
 and accessing its getters.  At least that's what I'm doing, and I'm
 skipping any unexpected descriptors.  If an application would want to
 learn more about reasons why a descriptor was skipped, it can log the
 exception or handle it otherwise.  It can even distinguish between I/O and
 parse exceptions.  But if it doesn't care as much, it can simply rely on
 `Descriptor` subtypes to be valid, parsed descriptors.

 > Regarding the code-example:  configuration of a descriptor source by
 fluent-style (or method chaining) is fine, but metrics-lib currently has
 the DescriptorSourceFactory approach, which would need to be adapted.
 That is, I see two things:  the ideas around the code of
 DescriptorSourceBuilder are ideas about a new way of configuration and not
 exception/error handling in metrics-lib, i.e. a different ticket (there is
 one for redesign of the interface hierarchy, I'll look for it).  Second,
 the current configuration and descriptor source instanciation need to be
 considered together (in that other ticket).

 Yes, you're right, this issue is orthogonal and should be discussed on a
 different ticket.  I'll create one.

 Thanks for your very valuable input above!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22192 [User Experience/Website]: Update tor-mirrors.csv / mirror site

[Tor Bug Tracker & Wiki]

#22192: Update tor-mirrors.csv / mirror site
-+---
 Reporter:  Samdney  |  Owner:  Sebastian
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by Samdney):

 Since the upload doesn't work, you can find the file here, now:

 https://github.com/Samdney/tormirrors/blob/master/mirrors_20170508.csv

 :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22182 [Community/Outreach]: Revision of perl script for updating mirror page on website

[Tor Bug Tracker & Wiki]

#22182: Revision of perl script for updating mirror page on website
+-
 Reporter:  Samdney |  Owner:  Samdney
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Community/Outreach  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  #22150  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by dgoulet):

 * component:  - Select a component => Community/Outreach


Comment:

 (Putting that in Community/Outreach so we don't lose this ticket with no
 component. It's probably a bad category but it definitely falls into
 Community.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22106 [Core Tor/Tor]: Initial Rust support

[Tor Bug Tracker & Wiki]

#22106: Initial Rust support
--+
 Reporter:  Sebastian |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by chelseakomlo):

 I tested the functionality of this, and it works well. Having someone more
 familiar with Tor's build system look at this would be great.

 A couple initial thoughts:
 - Having setup instructions would be helpful for those testing it/setting
 up Rust for the first time.
 - I imagine using Sebastian's repository as a git submodule is a good
 short term solution to get us up and running, but having a longer-term
 solution (not tied to a particular user) may be good.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #22192 [User Experience/Website]: Update tor-mirrors.csv / mirror site

[Tor Bug Tracker & Wiki]

#22192: Update tor-mirrors.csv / mirror site
-+---
 Reporter:  Samdney  |  Owner:  Sebastian
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+---
 I had a look at the tor-mirrors mailing list

 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-mirrors

 and found a backlog of entries for

 https://gitweb.torproject.org/project/web/webwml.git/tree/include/tor-
 mirrors.csv

 since September 2016.

 I did a review of the mails on the mailing list for mirror entries.

 You can find the new entries for tor-mirrors.csv in the attached file.
 Please add these entries and then run

 https://gitweb.torproject.org/project/web/webwml.git/tree/update-
 mirrors.pl

 for updating the mirror site

 https://www.torproject.org/getinvolved/mirrors

 Thanks :)!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21886 [Applications/Tor Browser]: Downloading of binary files stalls at 0/0 bytes in Tor Browser based on ESR52 with e10s off

[Tor Bug Tracker & Wiki]

#21886: Downloading of binary files stalls at 0/0 bytes in Tor Browser based on
ESR52 with e10s off
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  defect   | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-7.0-must-alpha,   |  Actual Points:
  ff52-esr, TorBrowserTeam201705,|
  GeorgKoppen201705  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by gk):

 * status:  assigned => needs_information


Comment:

 Alright, I think I have figured out all the pieces involved. The problems
 starts with https://bugzilla.mozilla.org/show_bug.cgi?id=1321528 begin
 fixed with https://hg.mozilla.org/releases/mozilla-beta/rev/1c4863a4ff98
 AND NoScript 2.9.5.2rc3 (commit 9eab569b1d443456325e2b253f2cca65eb453c30
 in the git repo at https://github.com/avian2/noscript). The whole
 suspend/resume mechanism got introduced to fix the mediasource blocking
 for us. ;)

 While I don't have assembled all of the pieces to a coherent picture yet,
 the proposed attached fix seems to be a good idea to me. mcs/brade: That
 one works across different platforms, right? If so, do you think you want
 to propose that one for review?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22122 [Metrics/metrics-lib]: Add support for six new key-value pairs added by OnionPerf

[Tor Bug Tracker & Wiki]

#22122: Add support for six new key-value pairs added by OnionPerf
-+---
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * status:  needs_review => merge_ready


Comment:

 The java side looks fine.  -> merge-ready

 Should the renaming to 'onionperf' everywhere be done in release 2.0.0?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21969 [Core Tor/Tor]: We're missing descriptors for some of our primary entry guards

[Tor Bug Tracker & Wiki]

#21969: We're missing descriptors for some of our primary entry guards
--+
 Reporter:  asn   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-guard |  Actual Points:
Parent ID:| Points:  1.5
 Reviewer:|Sponsor:  SponsorU
--+

Comment (by asn):

 We need to do something smart about this problem...

 I was going to suggest we just drop the non-fatal assert of #21415 and
 only check for the descriptor of the first primary guard (instead of first
 two), but I actually feel I don't understand the issue well enough.

 Perhaps some log messages that show the guard names that are missing
 descriptor would be helpful. Also, I'm wondering why Alec's tor is not
 doing any efforts in fetching the missing descriptors even over multiple
 hour. Maybe we should also log our attempts for fetching descriptors that
 are missing?

 Another theory: Since primary guards come from `CONFIRMED_GUARDS`, there
 is no guarantee that they are currently up and running. Could it be that
 Alec's primary guard was offline and off the consensus at that time,  so
 Alec's tor couldn't even fetch the needed descriptor and proceed?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #19640 [Metrics/metrics-lib]: review and improve interface hierarchy

[Tor Bug Tracker & Wiki]

#19640: review and improve interface hierarchy
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:  metrics-lib 2.0.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * owner:  karsten => metrics-team
 * status:  new => assigned


Comment:

 I'd like us to flesh out how we'd like to improve the interface hierarchy,
 and I'll start by going through the ideas above.

  1. Comment 10 of #19398 says: "There shouldn't be two interfaces
 declaring the very same method; there should be a more structured
 hierarchy for the interfaces, too."  I think I agree in theory, though I'd
 want to discuss how strictly we want to implement this principle.  Here's
 a contrasting principle: let's avoid introducing interfaces that have the
 sole purpose of deduplicating methods.  I think we need to find a middle
 ground here.

  2. The linked comment in `NetworkStatusImpl` seems related to possible
 improvements to the interface hierarchy, though I'd prefer if we address
 that issue after improving the interface hierarchy.

  3. Comment 4 above, splitting `ParseHelper` into interface and
 implementation seems unrelated, unless we're planning to make the
 interface part of the metrics-lib API.  Right now it's solely an
 implementation helper to avoid duplicating code.

  4. #17861 is indeed something where we could improve the interface
 hierarchy, by having a separate interface for each descriptor type.  But
 I'm not sure how to best implement such a new interface.  See the heavy
 overlap between `RelayNetworkStatusVote` and
 `RelayNetworkStatusConsensus`.  A new
 `RelayNetworkStatusMicrodescConsensus` interface following the current
 code practice would basically copy over the entire consensus interface and
 change a method here and there.  We should avoid that.

 In addition to those items, I came up with a few more ideas:

  5. When we added `RelayServerDescriptor`, `RelayExtraInfoDescriptor`,
 `BridgeServerDescriptor`, and `BridgeExtraInfoDescriptor`, we left all
 methods in the superinterfaces `ServerDescriptor` and
 `ExtraInfoDescriptor`.  We should consider moving methods that are
 specific to relays or bridges to the subinterfaces.

  6. We're still using a single `NetworkStatusEntry` for entries in all the
 different network statuses.  We should consider using an interface
 hierarchy there, too, to only provide relevant methods depending on the
 network status at hand.  I started working on a patch, but I'd like to
 keep this discussion on the conceptual level for now.

 And here are some more concrete suggestions for improving the interface
 hierarchy, somewhat overlapping with the ideas above:

  7. Introduce a `NetworkStatus` interface to capture all common parts of
 network statuses in directory protocol versions 2 and 3, including all
 `RelayNetworkStatus*` and `BridgeNetworkStatus`.

  8. Introduce another interface called `NetworkStatusVote` for common
 parts of network statuses in directory protocol version 3, following the
 common part in URLs like `http:///tor/status-
 vote/next/authority.z`.  Though there's the risk that this interface will
 be confused with `RelayNetworkStatusVote`.  Another possible interface
 name could be `RelayNetworkStatusVersion3`, though I'm not a big fan of
 including numbers in type names.

  9. Introduce a new interface `NetworkStatus.Entry` just like
 `ExitList.Entry` and a set of subinterfaces like
 `RelayNetworkStatusConsensus.Entry` to address issue 6 above.  Requires
 some heavy generics lifting.

  10. Use `RelayNetworkStatusConsensus` for the common parts in consensuses
 of any flavor and introduce `RelayNetworkStatusNsConsensus` for unflavored
 /ns-flavored and `RelayNetworkStatusMicrodescConsensus` for microdesc-
 flavored consensuses.  That's basically what we did with adding new
 subinterfaces to `ServerDescriptor`.

 What else can/should we do?  Or which parts should we rather not do?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22106 [Core Tor/Tor]: Initial Rust support

[Tor Bug Tracker & Wiki]

#22106: Initial Rust support
--+
 Reporter:  Sebastian |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 (I hope that other Rust specialists will review this with Sebastian, since
 I'm going to have to be pretty focused on 0.3.1 this week.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21969 [Core Tor/Tor]: We're missing descriptors for some of our primary entry guards

[Tor Bug Tracker & Wiki]

#21969: We're missing descriptors for some of our primary entry guards
--+
 Reporter:  asn   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-guard |  Actual Points:
Parent ID:| Points:  1.5
 Reviewer:|Sponsor:  SponsorU
--+
Changes (by nickm):

 * priority:  Medium => High


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22177 [Core Tor/Tor]: Remove dead code in test_options_validate_impl()

[Tor Bug Tracker & Wiki]

#22177: Remove dead code in test_options_validate_impl()
--+
 Reporter:  ahf   |  Owner:  ahf
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  merge_ready => assigned
 * owner:   => ahf


Comment:

 Merged; making ticket assigned again.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22177 [Core Tor/Tor]: Remove dead code in test_options_validate_impl()

[Tor Bug Tracker & Wiki]

#22177: Remove dead code in test_options_validate_impl()
--+
 Reporter:  ahf   |  Owner:
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 lgtm;

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21744 [Core Tor/Tor]: Build out glossary in torspec

[Tor Bug Tracker & Wiki]

#21744: Build out glossary in torspec
--+
 Reporter:  chelseakomlo  |  Owner:  chelseakomlo
 Type:  project   | Status:  needs_review
 Priority:  Low   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  torspec   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:  Tor: unspecified => Tor: 0.3.1.x-final


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22189 [Core Tor/Tor]: Update to May GeoIP2 database

[Tor Bug Tracker & Wiki]

#22189: Update to May GeoIP2 database
-+-
 Reporter:  karsten  |  Owner:
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client tor-relay 024-backport|  implemented
  025-backport 026-backport 027-backport |  Actual Points:
  028-backport 029-backport  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  new => closed
 * resolution:   => implemented


Comment:

 Merged to 0.2.4 and forward; thank you!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs