Re: [tor-bugs] #9701 [Applications/Tor Browser]: Prevent TorBrowser from creating clipboardcache turds

[Tor Bug Tracker & Wiki]

#9701: Prevent TorBrowser from creating clipboardcache turds
-+-
 Reporter:  cypherpunks  |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-disk-leak, interview, tbb-   |  Actual Points:
  firefox-patch, TorBrowserTeam201501|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

 * status:  closed => reopened
 * resolution:  fixed =>
 * severity:   => Normal


Comment:

 i had this happen using the webconsole copying a large section of de-
 obfuscated html with torbrowser 6.5.1

--
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] #13790 [Core Tor/Tor]: Refactor and add comments to new_route_len()

[Tor Bug Tracker & Wiki]

#13790: Refactor and add comments to new_route_len()
-+-
 Reporter:  dgoulet  |  Owner:
 |  catalyst
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  026-deferrable,  |  Actual Points:
  tor-03-unspecified-201612  |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-

Comment (by catalyst):

 Comment thread is still visible at
 
https://gitlab.com/cdlxxvi/tor/commit/11ffddf92a1aec121d6685d99b5306839f99b282#note_26287570
 if it turns out to be hard to find after my recent force-push.

--
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] #13790 [Core Tor/Tor]: Refactor and add comments to new_route_len()

[Tor Bug Tracker & Wiki]

#13790: Refactor and add comments to new_route_len()
-+-
 Reporter:  dgoulet  |  Owner:
 |  catalyst
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  026-deferrable,  |  Actual Points:
  tor-03-unspecified-201612  |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-

Comment (by catalyst):

 I responded to the GitLab comment and will soon push a rebased and revised
 patch series. Hopefully it won't make the comment thread vanish.

--
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] #21730 [Metrics/Metrics website]: Include metrics-lib's JavaDocs on the Metrics website

[Tor Bug Tracker & Wiki]

#21730: Include metrics-lib's JavaDocs on the Metrics website
-+--
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

 * status:  assigned => needs_review


Comment:

 A first suggestion:

 Please find three commits [https://gitweb.torproject.org/user/iwakeh
 /metrics-web.git/log/?h=task-21730 here] that implement the metrics-lib
 javadoc inclusion and prepare onionoo and collector web page integration
 (#21551).

 (I didn't run the war in tomcat.  There was a white space warning for the
 servlets in some of the latest commits on master.)

--
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] #21272 [Metrics]: Onionperf deployment

[Tor Bug Tracker & Wiki]

#21272: Onionperf deployment
-+--
 Reporter:  hiro |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by hiro):

 Ok I think what is missing is a port forwarding so that 8080 is forwarded
 to 80.
 More soon.

--
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] #21828 [Internal Services/Service - git]: Please create user repository 'tor' for iwakeh

[Tor Bug Tracker & Wiki]

#21828: Please create user repository 'tor' for iwakeh
-+
 Reporter:  iwakeh   |  Owner:  tor-gitadm
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 i.e.

 `user/iwakeh/tor.git` with description "iwakeh's personal tor repository"

 Thanks a lot!

--
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] #18589 [Applications/Tor Browser]: Tor browser writes SiteSecurityServiceState.txt with usage history

[Tor Bug Tracker & Wiki]

#18589: Tor browser writes SiteSecurityServiceState.txt with usage history
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-disk-leak |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gacar):

 Although the number of preloaded STS sites is small, popular STS sites are
 more likely to be included in the preload list:

 || '''Site rank''' || '''# of preloaded STS sites[[BR]]/[[BR]]# of STS
 enabled sites''' ||
 || Top 10 || 33% ||
 || Top 100 || 24% ||
 || Top 1K || 16.5% ||
 || Top 10K || 12.5% ||
 || Top 100K || 8.5% ||
 || Top 1M || 4.7% (1883/39408) ||

 Anyways, I think the privacy risk of revealing browsing history still
 outweighs the potential security benefits.

 PS: I should also note that I couldn't completely reproduce the problem
 with 6.5.1 and 7.0a2 on Linux 64. Although I visited several sites that
 send HSTS headers, only a few TPO and AMO-related domains
 (aus1.torproject.org, www.torproject.org, aus1.torproject.org) added to
 the SiteSecurityServiceState.txt  (something to do with the chrome vs
 content connections?).

--
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] #18002 [Archived/operations]: move away from OFTC to new functional, Tor-friendly IRC network

[Tor Bug Tracker & Wiki]

#18002: move away from OFTC to new functional, Tor-friendly IRC network
-+---
 Reporter:  adrelanos|  Owner:
 Type:  task | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Archived/operations  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  None
-+---

Comment (by cypherpunks):

 (quotes collection):
 "Sign in to OFTC with your Google+ OAuth"
 As of 2017-03-26, NickServ will require nick verification via
 services.oftc.net for the +R user mode. This affects channels using the +M
 and +R channel modes.
 a lot of ordinary new participants will just walk away because
 verification is oppressive
 but not to spammers etc, who are more highly motivated
 well and #tor will just stay +R, which harms it the most due to it being
 full of people who often do not want javascript enabled :/

--
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] #18589 [Applications/Tor Browser]: Tor browser writes SiteSecurityServiceState.txt with usage history

[Tor Bug Tracker & Wiki]

#18589: Tor browser writes SiteSecurityServiceState.txt with usage history
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-disk-leak |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gacar):

 Replying to [comment:10 gk]:
 > We might want to look at the amount of sites that provide HSTS/HPKP
 headers while not being on the preload list. If the amount of those sites
 is small (or if the amount of those sites in the top 1,000,000 sites is
 small?) we might want to think about clearing the state after a session as
 well.


 I compared the preloaded STS sites on mozilla-central [0] to top 1 million
 sites that send STS headers [1].

 There were:
 * 18317 preload sites
 * 39408 sites that send STS headers in top million

 Only 1883 of the 39408 STS sites found in the preloaded list. I took
 `include_subdomains` into consideration when matching the domains in two
 list.

 [0]: https://hg.mozilla.org/mozilla-
 central/file/tip/security/manager/ssl/nsSTSPreloadList.inc
 [1]: https://scans.io/study/scott-top-one-million (version: 14/3/2017)

--
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] #21827 [Metrics/Onionoo]: add recommended_version to bridge details document

[Tor Bug Tracker & Wiki]

#21827: add recommended_version to bridge details document
-+--
 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:   |
-+--
 Relays have a recommended_version flag, bridges should have it 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] #21771 [Core Tor/Tor]: Cannot change bridge (with Tor 0.3.0.4-rc)

[Tor Bug Tracker & Wiki]

#21771: Cannot change bridge (with Tor 0.3.0.4-rc)
-+
 Reporter:  torvlnt33r   |  Owner:  asn
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.0.4-rc
 Severity:  Normal   | Resolution:  fixed
 Keywords:  bridge 030-backport  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+
Changes (by nickm_mobile):

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


Comment:

 Cherry-picked to maint-0.3.0 and merged forward!

--
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] #21825 [Core Tor/Tor]: no symbol warning for hs_service.c

[Tor Bug Tracker & Wiki]

#21825: no symbol warning for hs_service.c
--+
 Reporter:  Sebastian |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by asn):

 * keywords:   => tor-hs
 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.0.x-final


Old description:

> During compilation, this warning is thrown:
>
> ranlib: file: src/or/libtor.a(hs_service.o) has no symbols
> Probably because there is no content other than unit tests.

New description:

 During compilation, this warning is thrown:

 ranlib: file: src/or/libtor.a(hs_service.o) has no symbols
 Probably because there is no content other than unit tests.

 (Also see the duplicate #21826 for more info)

--

--
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] #21826 [Core Tor/Tor]: clang warnings because of "empty" hs_service.c file in 0.3.0

[Tor Bug Tracker & Wiki]

#21826: clang warnings because of "empty" hs_service.c file in 0.3.0
--+
 Reporter:  asn   |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:  SponsorR-can
--+
Changes (by asn):

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


Comment:

 Ugh this is a duplicate of #21825.

--
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] #21826 [Core Tor/Tor]: clang warnings because of "empty" hs_service.c file in 0.3.0

[Tor Bug Tracker & Wiki]

#21826: clang warnings because of "empty" hs_service.c file in 0.3.0
--+
 Reporter:  asn   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:  SponsorR-can
--+
Description changed by asn:

Old description:

> Currently (in 0.3.0) the code in `hs_service.c` is disabled using '#ifdef
> TOR_UNIT_TESTS` and is only used for unittests. We will remove these
> `#ifdef` guards in 0.3.2 when we merge the rest of the service-side code.
>
> Unfortunately, as it seems having an empty .c file is no good, since
> empty translation units (i.e. files) are undefined behavior in C.
>
> Sebastian pointed this out, and said that his clang is throwing warnings
> at him because of that. He says that compilation proceeds normally, but
> it might be a good thing to fix anyhow.
>
> We could fix this by adding a static variable on top to silence the
> warning, or by removing the #ifdef guards.

New description:

 Currently (in 0.3.0) the code in `hs_service.c` is disabled using `#ifdef
 TOR_UNIT_TESTS` and is only used for unittests. We will remove these
 `#ifdef` guards in 0.3.2 when we merge the rest of the service-side code.

 Unfortunately, as it seems having an empty .c file is no good, since empty
 translation units (i.e. files) are undefined behavior in C.

 Sebastian pointed this out, and said that his clang is throwing warnings
 at him because of that. He says that compilation proceeds normally, but it
 might be a good thing to fix anyhow.

 We could fix this by adding a static variable on top to silence the
 warning, or by removing the #ifdef guards.

--

--
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] #21826 [Core Tor/Tor]: clang warnings because of "empty" hs_service.c file in 0.3.0

[Tor Bug Tracker & Wiki]

#21826: clang warnings because of "empty" hs_service.c file in 0.3.0
--+
 Reporter:  asn   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-hs
Actual Points:|  Parent ID:
   Points:  0.1   |   Reviewer:
  Sponsor:  SponsorR-can  |
--+
 Currently (in 0.3.0) the code in `hs_service.c` is disabled using '#ifdef
 TOR_UNIT_TESTS` and is only used for unittests. We will remove these
 `#ifdef` guards in 0.3.2 when we merge the rest of the service-side code.

 Unfortunately, as it seems having an empty .c file is no good, since empty
 translation units (i.e. files) are undefined behavior in C.

 Sebastian pointed this out, and said that his clang is throwing warnings
 at him because of that. He says that compilation proceeds normally, but it
 might be a good thing to fix anyhow.

 We could fix this by adding a static variable on top to silence the
 warning, or by removing the #ifdef guards.

--
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] #21771 [Core Tor/Tor]: Cannot change bridge (with Tor 0.3.0.4-rc)

[Tor Bug Tracker & Wiki]

#21771: Cannot change bridge (with Tor 0.3.0.4-rc)
-+
 Reporter:  torvlnt33r   |  Owner:  asn
 Type:  defect   | Status:  needs_review
 Priority:  Very High|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.0.4-rc
 Severity:  Normal   | Resolution:
 Keywords:  bridge 030-backport  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+
Changes (by asn):

 * status:  assigned => needs_review


Comment:

 Replying to [comment:7 asn]:
 > With Nick we discussed that the right fix is probably to implement the
 original intention of the code snippet here:
 > {{{
 > get_max_sample_size(guard_selection_t *gs,
 > int n_guards)
 > {
 > ...
 >   /* With bridges, max_sample is "all of them" */
 >   if (using_bridges)
 > return n_guards;
 > }}}
 >
 > and actually make the max_sample size be "all of them" in the bridge
 case instead of just being the number of bridges in torrc.
 >
 > Possible implementations:
 >
 > a) The obvious (but slightly dirty) way of doing this would be to change
 `return n_guards` above to `return INT_MAX`. I verified that this would
 fix the bug of this ticket.
 >

 Please check my branch `bug21771` for a fix using logic (a) 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] #21817 [Applications/Tor Browser]: Immediate failure on valid website page

[Tor Bug Tracker & Wiki]

#21817: Immediate failure on valid website page
--+---
 Reporter:  portajon  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by mcs):

 * status:  new => needs_information
 * cc: mcs (added)


Comment:

 I think the website is blocking access via the Tor Network.
 That page appeared to load correctly after I reconfigured Tor Browser
 6.5.1 to connect directly to the Internet, bypassing Tor (this is not
 recommended of course),

 Have you tried contacting the credit union to ask if they are blocking
 access via Tor?

--
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] #21757 [Core Tor/Tor]: Using Pluggable Transports on tor master is broken

[Tor Bug Tracker & Wiki]

#21757: Using Pluggable Transports on tor master is broken
--+
 Reporter:  gk|  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_mobile):

 * status:  needs_review => assigned


Comment:

 Merged this to master; leaving this ticket open and assigned to 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] #21771 [Core Tor/Tor]: Cannot change bridge (with Tor 0.3.0.4-rc)

[Tor Bug Tracker & Wiki]

#21771: Cannot change bridge (with Tor 0.3.0.4-rc)
-+
 Reporter:  torvlnt33r   |  Owner:  asn
 Type:  defect   | Status:  assigned
 Priority:  Very High|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.0.4-rc
 Severity:  Normal   | Resolution:
 Keywords:  bridge 030-backport  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+

Comment (by asn):

 With Nick we discussed that the right fix is probably to implement the
 original intention of the code snippet here:
 {{{
 get_max_sample_size(guard_selection_t *gs,
 int n_guards)
 {
 ...
   /* With bridges, max_sample is "all of them" */
   if (using_bridges)
 return n_guards;
 }}}

 and actually make the max_sample size be "all of them" in the bridge case
 instead of just being the number of bridges in torrc.

 Possible implementations:

 a) The obvious (but slightly dirty) way of doing this would be to change
 `return n_guards` above to `return INT_MAX`. I verified that this would
 fix the bug of this ticket.

 b) If we want a nicer semantic than `INT_MAX` we could perhaps return the
 number of bridges in our torrc ''plus'' the number of currently sampled
 bridges.

 c) The third alternative would be to return `DFLT_MAX_SAMPLE_SIZE` but
 that would not actually fix all edge cases, since if our sampled guard
 list contains lots of old bridges we could actually hit the limit.

 Personally, I think going with (a) and a small comment describing the
 logic is fine. Alternatively, we could go with (b) if we want to seem
 smarter.

 I can write a quick patch here after we decide on the approach.

--
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] #21771 [Core Tor/Tor]: Cannot change bridge (with Tor 0.3.0.4-rc)

[Tor Bug Tracker & Wiki]

#21771: Cannot change bridge (with Tor 0.3.0.4-rc)
-+
 Reporter:  torvlnt33r   |  Owner:  asn
 Type:  defect   | Status:  assigned
 Priority:  Very High|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.0.4-rc
 Severity:  Normal   | Resolution:
 Keywords:  bridge 030-backport  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+

Comment (by nickm_mobile):

 I talked with asn a little and here's what I think we decided:  That (a)
 is the better approach, and that the right solution is to make the sample
 size unlimited for bridges.

--
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] #21771 [Core Tor/Tor]: Cannot change bridge (with Tor 0.3.0.4-rc)

[Tor Bug Tracker & Wiki]

#21771: Cannot change bridge (with Tor 0.3.0.4-rc)
-+
 Reporter:  torvlnt33r   |  Owner:  asn
 Type:  defect   | Status:  assigned
 Priority:  Very High|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.0.4-rc
 Severity:  Normal   | Resolution:
 Keywords:  bridge 030-backport  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+

Comment (by asn):

 OK here is some recon.

 It seems like we are continuously hitting the following code path with
 this bug:
 {{{
 [warn] Not expanding the guard sample any further; just hit the maximum
 sample threshold of 1
 }}}

 which brings us to the following code:
 {{{
   smartlist_t *eligible_guards = get_eligible_guards(options, gs,
 &n_guards);
 ...
   const int max_sample = get_max_sample_size(gs, n_guards);
 ...
 /* Has our sample grown too large to expand? */
 if (n_sampled >= max_sample) {
   log_warn(LD_GUARD, "Not expanding the guard sample any further; "
"just hit the maximum sample threshold of %d",
max_sample);
   goto done;
 }
 }}}

 with `get_max_sample_size()` like this:
 {{{
 get_max_sample_size(guard_selection_t *gs,
 int n_guards)
 {
 ...
   /* With bridges, max_sample is "all of them" */
   if (using_bridges)
 return n_guards;
 }}}

 and `get_eligible_guards()` sets `n_guards` like this:
 {{{
   if (gs->type == GS_TYPE_BRIDGE) {
 const smartlist_t *bridges = bridge_list_get();
 SMARTLIST_FOREACH_BEGIN(bridges, bridge_info_t *, bridge) {
   ++n_guards;
   if (NULL != get_sampled_guard_for_bridge(gs, bridge)) {
 continue;
   }
   smartlist_add(eligible_guards, bridge);
 } SMARTLIST_FOREACH_END(bridge);
 }}}

 So in our case, because we swapped bridge X for bridge Y, the above code
 will only do a single smartlist loop (since only Y is in our bridge list),
 and it will set `n_guards` to 1.

 But since our sampled guards list already contains bridge X, tor will
 refuse to add bridge Y since we "just hit the maximum sample threshold of
 1".

 Some suggested ways forward:
 a) We could reconsider how `get_max_sample_size()` handles the bridge
 case.
 b) We could edit `get_eligible_guards()` so that it also takes into
 account our sampled guards and not just the size of our bridge list (i.e.
 how many bridges are in our torrc).

--
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] #21272 [Metrics]: Onionperf deployment

[Tor Bug Tracker & Wiki]

#21272: Onionperf deployment
-+--
 Reporter:  hiro |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by robgjansen):

 According to [http://199.119.112.144:8081/op-us-1048576-2017-03-26.tpf a
 .tpf file  from 2017-03-26], the client is now correctly requesting port
 80 for non-onion downloads. (It is still requesting 8080 for onion
 downloads, but that should not affect affect path selection for onion
 service circuits.)

 Unfortunately, it looks like all of the downloads are now timing out,
 since the data shows `DIDTIMEOUT=1` for all entries in the .tpf file. More
 debugging is needed.

--
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] #21788 [Core Tor/Tor]: Very small memory leak with --verify-config

[Tor Bug Tracker & Wiki]

#21788: Very small memory leak with --verify-config
--+
 Reporter:  Jigsaw52  |  Owner:  Jigsaw52
 Type:  defect| Status:  closed
 Priority:  Very Low  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Trivial   | Resolution:  fixed
 Keywords:  memory leak   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm_mobile):

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


Comment:

 Merged, changes file 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] #21823 [Core Tor/Tor]: tor FTBFS on clang/i386

[Tor Bug Tracker & Wiki]

#21823: tor FTBFS on clang/i386
--+
 Reporter:  weasel|  Owner:  nickm_mobile
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm_mobile):

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


Comment:

 1d617e3ed0a6c380d1bde9654a518c8a83d21db3 should fix this.  Thanks for the
 report!

--
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