Re: [tor-bugs] #23820 [Core Tor/Tor]: Make sure v3 single onion services and v3 onion service clients only send IPv4 addresses

[Tor Bug Tracker & Wiki]

#23820: Make sure v3 single onion services and v3 onion service clients only 
send
IPv4 addresses
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion, ipv6  |  Actual Points:  1
Parent ID:  #23493   | Points:  1
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by teor):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:5 dgoulet]:
 > @teor, I can fix those if you have no time but just let me know what you
 think about them. If you do fix them, I propose we go in Gitlab mode next
 time.

 I have just resurrected my gitlab and pushed the updated branch to
 bug23820_032.
 (oniongit.eu will have to wait for #24106.)

 > * To be clear, I know Tor can't extend to an IPv6 so this should NEVER
 happened in theory right? (in get_lspecs_from_extend_info())
 >
 > {{{
 > +  if (BUG(!tor_addr_is_v4(>addr))) {
 > +return;
 > +  }
 > }}}

 See the function comment:
 {{{
Clients never make
  * direct connections to rendezvous points, so they should always have an
  * IPv4 address in ei.
 }}}

 But this comment only describes the *current* implementation. I can't rely
 on the behaviour of future implementations, because we know we want to add
 IPv6 all over the place.

 Also, clients and services can already make direct IPv6 connections using
 the addr in ei, and mis-handling that caused #23493, so we need a check
 for IPv6.

 > * The `intro1_data` is initialized with `setup_introduce1_data()` which
 guarantee that the link specifier list will be a valid smartlist pointer
 and never uninit. So here, I would remove the NULL check so we don't hide
 bugs.
 >
 > {{{
 > +  if (!intro1_data.link_specifiers ||
 > +  !smartlist_len(intro1_data.link_specifiers)) {
 > }}}

 I don't think we should trust future implementations of
 `setup_introduce1_data()` to hand us a non-NULL pointer.

 We're logging a warning if either the NULL check or the length check
 fails. I wrapped the NULL check in a BUG(), so we can distinguish these
 two cases.

 [bug23820_032 f31094c1d5] fixup! Remove buggy IPv6 and ed25519 handling
 from get_lspecs_from_extend_info()

 > * We could have a function that returns a static string for this so we
 make sure that every logs will have the same keywords. Something like
 `service_type_str()`
 >
 > {{{
 > service->config.is_single_onion ? "direct" : "multi-hop"
 > }}}

 These are the wrong strings to log anyway: when we implement falling back
 to a 3-hop path in #23818, we will want to log both the anonymity of the
 service, and the number of paths in this circuit. Right now, we can only
 log single onion vs hidden.

 [bug23820_032 6157b05aad] fixup! Improve v3 onion service logging for
 intro and rend points

 > * I'm skeptical that this will help our logging. I think base32 would be
 closer to the onion address than the hex string:
 >
 > {{{
 > +   safe_str_client(hex_str((const char
 *)service_pk->pubkey,
 > +   ED25519_PUBKEY_LEN)));
 > }}}

 Someone wrote a really nice hs_build_address() function, so I'll just use
 that ;-)

 [bug23820_032 6157b05aad] fixup! Improve v3 onion service logging for
 intro and rend points

 > * Hmm this is possible that is SingleHopMode 0 and NonAnonymous 1 ? ...
 Looking at `rend_service_non_anonymous_mode_enabled()` seems to me that
 they have to be consistent?
 >
 > {{{
 > +  log_warn(LD_CONFIG, "IPv6-only v3 single onion services are not "
 > +   "supported. Set HiddenServiceSingleHopMode 0 and "
 > +   "HiddenServiceNonAnonymousMode 1, or set ClientUseIPv4
 1.");
 > }}}

 Yes, that's a typo.

 It does make me wonder whether having 2 options for the same thing is
 actually less safe, because it makes it more likely we will introduce
 bugs.

 [bug23820_032 ea1d68c857] fixup! Stop users configuring IPv6-only v3
 single onion services

--
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] #24106 [Internal Services/Service - git]: Please make teor an oniongit account

[Tor Bug Tracker & Wiki]

#24106: Please make teor an oniongit account
-+--
 Reporter:  teor |  Owner:  hiro
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by arma):

 * status:  new => assigned
 * owner:  tpa => hiro
 * component:  Internal Services/Tor Sysadmin Team => Internal
 Services/Service - git


Comment:

 I'm moving this one over to the service-git component, even though that's
 not quite right, because it is more right than the sysadmin-team
 component.

 (This ticket is about changing the configurations on a service that we
 run, not about changing any of the underlying computers that run the
 services.)

--
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] #24108 [Core Tor/Tor]: Write a design document for the bandwidth control port interface for Android devices

[Tor Bug Tracker & Wiki]

#24108: Write a design document for the bandwidth control port interface for
Android devices
---+
 Reporter:  ahf|  Owner:  nickm
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  s8-control, s8-201711  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor8
---+
Changes (by ahf):

 * status:  new => assigned
 * owner:  (none) => nickm


Comment:

 Assigning to Nick.

--
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] #24108 [Core Tor/Tor]: Write a design document for the bandwidth control port interface for Android devices

[Tor Bug Tracker & Wiki]

#24108: Write a design document for the bandwidth control port interface for
Android devices
--+---
 Reporter:  ahf   |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  s8-control, s8-201711
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor8  |
--+---
 We should investigate and write a design document for a bandwidth control
 port interface for Tor on Android devices. Ideally in a manner that might
 be useful on iOS as well.

 Ideas that could be worth taking into account:

 - Only download certain objects when we have "good" internet connectivity?
 - Should we listen to online/offline information from the platform? Could
 this be used to isolate users and make them unable to connect to the
 network?

 Some documents that might relevant for Android:

 - https://developer.android.com/training/monitoring-device-state
 /connectivity-monitoring.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

Re: [tor-bugs] #24107 [Core Tor/Tor]: Write a design document for the control interface for enhanced battery awareness on Android devices

[Tor Bug Tracker & Wiki]

#24107: Write a design document for the control interface for enhanced battery
awareness on Android devices
---+---
 Reporter:  ahf|  Owner:  nickm
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  s8-battery, s8-control, s8-201711  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor8
---+---
Changes (by ahf):

 * status:  new => assigned
 * owner:  (none) => nickm


Comment:

 Assigning to Nick.

--
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] #24107 [Core Tor/Tor]: Write a design document for the control interface for enhanced battery awareness on Android devices

[Tor Bug Tracker & Wiki]

#24107: Write a design document for the control interface for enhanced battery
awareness on Android devices
---+---
 Reporter:  ahf|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.3.4.x-final
Component:  Core   |Version:
  Tor/Tor  |
 Severity:  Normal |   Keywords:  s8-battery, s8-control, s8-201711
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor:  Sponsor8   |
---+---
 We should begin writing a design document for the control interface for
 enhanced control of battery utilisation.

 We should investigate how Tor and Orbot currently interacts with the
 platform and how this could be improved. Ideally in a manner that
 potentially could become useful for other mobile platforms such as iOS as
 well.

 Android documents that might be worth reading for better knowledge of
 platform features when it comes to standby:

 - https://developer.android.com/training/monitoring-device-state/doze-
 standby.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] #24106 [Internal Services/Tor Sysadmin Team]: Please make teor an oniongit account

[Tor Bug Tracker & Wiki]

#24106: Please make teor an oniongit account
-+-
 Reporter:  teor |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 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] #23856 [Core Tor/Tor]: Reduce relay bandwidth stats interval to 24 hours

[Tor Bug Tracker & Wiki]

#23856: Reduce relay bandwidth stats interval to 24 hours
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  guard-discovery-stats  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:  SponsorQ
---+

Comment (by teor):

 I emailed tor-dev@ about this change, including a summary of my comment
 above:
 https://lists.torproject.org/pipermail/tor-dev/2017-November/012538.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] #24105 [Internal Services/Tor Sysadmin Team]: disable ldap accounts for old https-everywhere people

[Tor Bug Tracker & Wiki]

#24105: disable ldap accounts for old https-everywhere people
-+-
 Reporter:  arma |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Following on from #24051, I talked to legind and we agreed to keep two
 ldap accounts for https everywhere devs (primary maintainer and a backup
 for bus factor).

 So, let's disable the others:
 schoen
 dtauerbach
 micah
 pde
 yan

 And as before, if your name is in this list, don't worry, the goal here is
 to reduce our security vulnerability surface area for accounts that aren't
 in active use, and this is an easy operation to reverse if you want the
 account to become in active use 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] #24104 [Core Tor/Tor]: Delay descriptor bandwidth reporting on large relays

[Tor Bug Tracker & Wiki]

#24104: Delay descriptor bandwidth reporting on large relays
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  guard-discovery-stats  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:
---+

Comment (by teor):

 Also, relays will re-post their descriptors when any important config
 items change. But I think that's out of scope for 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] #22342 [Core Tor/Tor]: Add a nice append-only stringbuffer, and refactor code to use it

[Tor Bug Tracker & Wiki]

#22342: Add a nice append-only stringbuffer, and refactor code to use it
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-24  |  Actual Points:  .2
Parent ID:   | Points:
 Reviewer:  isis |Sponsor:
-+

Comment (by arma):

 {{{
 +/** Return a heap-allocated string containing the contents of buf
 + * contents.
 }}}
 might want one fewer word too.

 Overall it looks like a fine useful feature. I did not hunt in detail for
 bugs though. :)

--
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] #15618 [Core Tor/Tor]: Tried to establish rendezvous on non-OR circuit with purpose Acting as rendevous (pending)

[Tor Bug Tracker & Wiki]

#15618: Tried to establish rendezvous on non-OR circuit with purpose Acting as
rendevous (pending)
-+-
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs needs-insight needs-  |  Actual Points:
  diagnosis  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by s7r):

 Replying to [comment:34 dgoulet]:
 > Hey s7r! You seems to have DEBUG logs there, you think you can attach
 them (or send them to me private if sensitive) to me. I would like to see
 a bit more of the inners of tor service side for this?
 >

 Yes I have :) been hunting this for some time now. Was lucky to catch it
 live so immediately switched to debug log level. Got about 2 GB of debug
 logs (uncompressed).

 I will send them to you via a secure channel, first because they might be
 sensitive for whoever was using this relay and second because I feel
 something very strange is going on and I don't want to tip anyone off
 which relays keep eyes on this.

 > The fact that we see that "sometimes" and we see it in burst tells me
 that it is likely someone doing that either on purpose or a VERY buggy
 implementation. The tor client can't open 300 circuit to a service in a
 relatively short amount of time and all have the bug for those... seems
 VERY unlikely, we would see that more often.
 >
 > Those 300 warnings are spread out how over time?

 Indeed I would say VERY VERY unlikely. It's maybe more than that, in less
 than 24 hours.

--
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] #24040 [Applications/Tor Browser]: TorBrowser under Whonix crashes at riot.im/app

[Tor Bug Tracker & Wiki]

#24040: TorBrowser under Whonix crashes at riot.im/app
--+---
 Reporter:  user  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by user):

 1. debian-8 bridges with outbound firewall restrictions --> no riot.im
 crash
 2. reinstall and then update whonix workstation VM --> riot.im still
 crashes
 3. copy torbrowser from whonix VM to debian-9 VM, redo connection setup
 --> no riot.im crash

 Regarding desktop notifications, the choice doesn't matter.

 Regarding the difference between whonix torbrowser vs non-whonix, all I
 know is the whonix version connects to a tor instance that runs in a
 separate whonix gateway VM (which is why I had to redo the connection
 setup in (3)).

--
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] #20020 [Core Tor/Tor]: Strange Warning: "Couldn't add re-parsed router: Some certs on this router are expired."

[Tor Bug Tracker & Wiki]

#20020: Strange Warning: "Couldn't add re-parsed router: Some certs on this 
router
are expired."
-+-
 Reporter:  torland  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.7
 Severity:  Normal   | Resolution:
 Keywords:  prop220-fallout, usability,  |  Actual Points:
  logging, relay |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by s7r):

 Confirmed this today on `0.3.2.2-alpha-dev (git-51e47481fc6f131d)` hosting
 a bridge. Nothing seams to have happened besides the warn log message.

--
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] #21001 [Core Tor/Chutney]: Test that recent tor clients can use microdescriptors when configured to only use IPv6

[Tor Bug Tracker & Wiki]

#21001: Test that recent tor clients can use microdescriptors when configured to
only use IPv6
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6  |  Actual Points:
Parent ID:  #17011| Points:  0.5
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 Let's do this by creating new networks that use microdescriptors, and then
 changing the 0.3.2 code to use the new network names.

--
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] #21000 [Core Tor/Chutney]: Make chutney select different options depending on the tor version

[Tor Bug Tracker & Wiki]

#21000: Make chutney select different options depending on the tor version
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * parent:  #21001 =>


Comment:

 One way to do this for #21001 is to create new md-networks in chutney, and
 make newer versions of tor use them.

--
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] #24100 [Core Tor/Tor]: Support exit notice page in multiple multiple languages

[Tor Bug Tracker & Wiki]

#24100: Support exit notice page in multiple multiple languages
--+
 Reporter:  anadahz   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  i18n  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 See https://github.com/chgans/tor-exit-notice and forks for other examples

--
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] #23641 [Core Tor/Tor]: prop224: Fake client auth lines do not actually provide obfuscation

[Tor Bug Tracker & Wiki]

#23641: prop224: Fake client auth lines do not actually provide obfuscation
+
 Reporter:  asn |  Owner:  dgoulet
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal  | Resolution:  wontfix
 Keywords:  prop224 tor-hs  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  asn |Sponsor:
+
Changes (by asn):

 * status:  needs_information => closed
 * resolution:   => wontfix


Comment:

 I'm fine with not implementing this ticket, since it does not seem to be
 that useful due to comment:7.

 I'm gonna close it but feel free to open it if you disagree!

--
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] #23856 [Core Tor/Tor]: Reduce relay bandwidth stats interval to 24 hours

[Tor Bug Tracker & Wiki]

#23856: Reduce relay bandwidth stats interval to 24 hours
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  guard-discovery-stats  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:  SponsorQ
---+

Comment (by teor):

 arma and nickm and I had an irc conversation about this today:

 Replying to [comment:12 teor]:
 > The relevant constants in tor are:
 >
 > NUM_SECS_BW_SUM_INTERVAL and maybe we will need to increase
 NUM_SECS_BW_SUM_IS_VALID to remember 2-4 days of daily bandwidth, rather
 than just one day:
 > https://gitweb.torproject.org/tor.git/tree/src/or/rephist.c#n1242

 NUM_SECS_BW_SUM_INTERVAL 24 hours
 /* similar to the 6 periods * 4 hours we had before */
 NUM_SECS_BW_SUM_IS_VALID 5 days

 > And maybe we should also change MAX_BANDWIDTH_CHANGE_FREQ, otherwise
 relays will report bandwidth spikes every 20 minutes in their descriptors.
 But we should be careful here, because this affects the bandwidth
 authority system. But it seems that at least an hour would be reasonable:
 > https://gitweb.torproject.org/tor.git/tree/src/or/router.c#n2516

 /* descriptor bandwidth changes propagate to clients between:
  * 10 minutes (upload right before vote, then client bootstrap from
 authority)
  * 3 hours (upload just after vote, then client fetch from mirror as late
 as possible)
  * after they are uploaded by relays. There's no point in reporting them
 much more often
  * than this, because the feedback loop only runs at this speed. */
 MAX_BANDWIDTH_CHANGE_FREQ 3 hours

 arma believes relays that already have enough measured bandwidth are able
 to share their bandwidths less often (that is, when they are Fast or Guard
 or Measured or something), or share them after a larger change. (That is,
 arma said that small relays should share it more often, and I inverted his
 logic and set a minimum instead.)

 I agree, but I'm not sure how much more delay or how much more bandwidth
 we can allow. So let's take this change in 0.3.2, and do some analysis for
 0.3.3. I split this part off into #24104.

--
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] #24104 [Core Tor/Tor]: Delay descriptor bandwidth reporting on large relays

[Tor Bug Tracker & Wiki]

#24104: Delay descriptor bandwidth reporting on large relays
--+---
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  guard-discovery-stats
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+---
 In #23856, we:
 * reduced the bandwidth stats interval from 4 hours to 24 hours, and
 * reduced urgent (2x change) descriptor bandwidth reports from every 20
 minutes to every 3 hours.

 But we think we can make descriptor bandwidth reports even slower on large
 relays, because they have less need to ramp up their bandwidth.

 Here are our options:
 * don't report until the change is larger, for example, 4x
 * don't report for longer, for example, every 6 hours or 24 hours
 * delay the reporting of the *first* large change, as well as subsequent
 large changes

 Here are the open questions:
 * tor traffic has a daily cycle, so do we need to report large bandwidth
 changes multiple times a day to cope with this? (I think the answer is
 "no", because small changes are already reported every 18 hours on the
 standard descriptor schedule, and that seems to work fine. And large
 changes are already reported once, then the delay is imposed.)

--
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] #21394 [Core Tor/Tor]: connection timeouts are affecting Tor Browser usability

[Tor Bug Tracker & Wiki]

#21394: connection timeouts are affecting Tor Browser usability
-+-
 Reporter:  arthuredelstein  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-performance, tbb-usability,  |  Actual Points:
  performance, tbb-needs |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by Sebastian):

 #18580 could be very relevant 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] #24025 [Core Tor/Tor]: Log warning: Inconsistent ed25519 identities in the nodelist

[Tor Bug Tracker & Wiki]

#24025: Log warning: Inconsistent ed25519 identities in the nodelist
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-relay |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 We don't actually use the NoEdConsensus flag for anything yet.
 So yes, let's downgrade the warning.
 (And instead, let's get ed keys in the consensus #23170, and ditch the
 flag #24103.)

--
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] #24103 [Core Tor/Tor]: Remove the NoEdConsensus flag

[Tor Bug Tracker & Wiki]

#24103: Remove the NoEdConsensus flag
-+-
 Reporter:  teor |  Owner:  (none)
 Type:   | Status:  new
  enhancement|
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  prop224 tor-dirauth tor-hs ed25519
 Severity:  Normal   |  needs-proposal TorCoreTeam201711.1
Actual Points:   |  Parent ID:  #23170
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 When we have ed keys in the consensus, we won't need this flag any more.
 And so we won't need to write any code to actually use it in relays or
 clients.

--
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] #22342 [Core Tor/Tor]: Add a nice append-only stringbuffer, and refactor code to use it

[Tor Bug Tracker & Wiki]

#22342: Add a nice append-only stringbuffer, and refactor code to use it
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-24  |  Actual Points:  .2
Parent ID:   | Points:
 Reviewer:  isis |Sponsor:
-+
Changes (by isis):

 * status:  needs_review => merge_ready


Comment:

 In commit 68a90d09 you've got a docstring where you're doing the thing
 where you start a sentence and then I'm not sure what hap

 {{{
 /** Add a nul-terminated string to buf, but */
 }}}

 Other than that, everything looks great! The new API looks much cleaner,
 especially in the directory code. :)

--
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] #24100 [Core Tor/Tor]: Support exit notice page in multiple multiple languages

[Tor Bug Tracker & Wiki]

#24100: Support exit notice page in multiple multiple languages
--+
 Reporter:  anadahz   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  i18n  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 this is about this file:
 https://gitweb.torproject.org/tor.git/plain/contrib/operator-tools/tor-
 exit-notice.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] #24102 [Core Tor/Tor]: Help DirAuths rejecting certain relays based on their properties

[Tor Bug Tracker & Wiki]

#24102: Help DirAuths rejecting certain relays based on their properties
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 There is an ongoing group of bad exit relays that are removed from the
 network by dir auths and added on the next day with new keys and IPs.

 This a slow and manual process and puts tor users at risk.

 Allow dirauths to reject relays based on their properties before they are
 included in consensuses and distributed to clients.
 The rejected relay should get an immediate feedback about their rejection
 when uploading the descriptor.

 Properties can be:
 * IPv4 / IPv6 address
 * AS number
 * AS name
 * (partial) ContactInfo
 * (partial) nickname
 * exit policy
 * OS
 * tor version
 * OR port
 * Dir Port
 * first seen date



 This ticket is about providing a configuration possibility for dirauths to
 reject relays based on a set of properties **IFF** they would actually use
 such a feature.

 Examples:
 * reject new (fingerprint never seen before) relays added in AS 123
 **and** exit policy ...
 * reject new relays with nickname "abc" and contactinfo "123"


 each rule should have an expiry time (i.e 10 days, 1 month, ..)

--
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] #24026 [Webpages/Website]: Update "donate options" page

[Tor Bug Tracker & Wiki]

#24026: Update "donate options" page
--+-
 Reporter:  steph |  Owner:  hiro
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by steph):

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


--
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] #24026 [Webpages/Website]: Update "donate options" page

[Tor Bug Tracker & Wiki]

#24026: Update "donate options" page
--+--
 Reporter:  steph |  Owner:  hiro
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by hiro):

 Please verify that everything is done.

--
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] #24101 [Metrics/Bot]: tell me country percentage not just absolute number

[Tor Bug Tracker & Wiki]

#24101: tell me country percentage not just absolute number
-+-
 Reporter:  arma |  Owner:  irl
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Bot  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
  1304 relays in Germany are contributing 4.6GiB/s bandwidth
 to the #Tor network. https://atlas.torproject.org/#search/country:de

 could become

  1304 relays in Germany are contributing 4.6GiB/s bandwidth
 (19.9%) to the #Tor network.
 https://atlas.torproject.org/#search/country:de

 I'm not sure the right way to phrase it -- originally I had in mind just
 to hear one percentage, which is the percentage of total bandwidth that
 4.6GiB represents. But there are also other percentages we might try to
 work in, e.g.

  1304 relays in Germany are contributing 4.6GiB/s bandwidth
 (23.6%, 22.6%, 6.9%) to the #Tor network.
 https://atlas.torproject.org/#search/country:de

--
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] #24100 [Core Tor/Tor]: Support exit notice page in multiple multiple languages

[Tor Bug Tracker & Wiki]

#24100: Support exit notice page in multiple multiple languages
--+
 Reporter:  anadahz   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  i18n
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Do we have plan to support tor exit notice (HTML) pages in multiple
 languages, and what is the best way to ship this together with the tor
 package/release?

 Example Tor exit notice in [https://0xacab.org/tortola/exit-
 notice/blob/master/nodos/gabriela/index.html Castelanno].

--
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] #21509 [Core Tor/Tor]: Fuzz v3 hidden services

[Tor Bug Tracker & Wiki]

#21509: Fuzz v3 hidden services
---+
 Reporter:  teor   |  Owner:  nickm
 Type:  task   | Status:  accepted
 Priority:  High   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  fuzz, prop224, tor-hs  |  Actual Points:
Parent ID: | Points:  2
 Reviewer: |Sponsor:  SponsorR-can
---+

Comment (by nickm):

 I've attached the gcov output of running the fuzz_static_testcases.sh
 script on hs_descriptor.c with the current fuzzing corpus.  Note that this
 doesn't actually fuzz -- it just shows us what our current corpus reaches.
 But it looks like we're at least getting inside decode_intro_points() a
 little?   We should add some seed elements to the corpus that trigger more
 of it getting parsed, though.

--
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] #21509 [Core Tor/Tor]: Fuzz v3 hidden services

[Tor Bug Tracker & Wiki]

#21509: Fuzz v3 hidden services
---+
 Reporter:  teor   |  Owner:  nickm
 Type:  task   | Status:  accepted
 Priority:  High   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  fuzz, prop224, tor-hs  |  Actual Points:
Parent ID: | Points:  2
 Reviewer: |Sponsor:  SponsorR-can
---+
Changes (by nickm):

 * Attachment "hs_descriptor.c.gcov" 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] #23623 [Core Tor/Tor]: hs: Cache current time period number and SRV start time

[Tor Bug Tracker & Wiki]

#23623: hs: Cache current time period number and SRV start time
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-sr, prop224  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+
Changes (by dgoulet):

 * status:  needs_revision => needs_review


Comment:

 Ok tests fixed! That was a bit tricky. Everytime we mock a consensus, we
 have to recalculate its voting schedule for this kind of test now.

 See branch: `ticket23623_032_01`

--
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] #21394 [Core Tor/Tor]: connection timeouts are affecting Tor Browser usability

[Tor Bug Tracker & Wiki]

#21394: connection timeouts are affecting Tor Browser usability
-+-
 Reporter:  arthuredelstein  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-performance, tbb-usability,  |  Actual Points:
  performance, tbb-needs |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 I looked more closely at timeouts for example.com:
 100-second timeouts: 7.13%
 10 seconds -> 100 seconds successes: 5.21%
 Total responses later than 10 seconds: 12.34%
 That's actually worse than the 9.03% seen in comment:27, though it's
 important to not this is not weighted by consensus weights but treats all
 exits equally.

 For bare IP address:
 100-second timeouts: 1.00%
 10 seconds -> 100 second successes: 2.45%
 Total responses later than 10 seconds: 3.45%.

 Again, this is worse than comment:27, but the discrepancy shows the
 importance of DNS to delayed responses.

--
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] #24026 [Webpages/Website]: Update "donate options" page

[Tor Bug Tracker & Wiki]

#24026: Update "donate options" page
--+--
 Reporter:  steph |  Owner:  hiro
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by steph):

 * owner:  (none) => hiro
 * status:  new => assigned


--
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] #24082 [Core Tor/Tor]: uninitialized value in networkstatus_parse_vote_from_string() via fuzz_consensus.c

[Tor Bug Tracker & Wiki]

#24082: uninitialized value in networkstatus_parse_vote_from_string() via
fuzz_consensus.c
--+
 Reporter:  catalyst  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 merged to 0.3.2 and 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] #24099 [Core Tor/Tor]: tor should remove empty/invalid consensus cache files (Unable to map file from consensus cache: Numerical result out of range)

[Tor Bug Tracker & Wiki]

#24099: tor should remove empty/invalid consensus cache files (Unable to map 
file
from consensus cache: Numerical result out of range)
--+
 Reporter:  Hello71   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:   => Tor: 0.3.2.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] #24097 [Core Tor/Tor]: evdns_callback(): Bug: eventdns returned no addresses or error

[Tor Bug Tracker & Wiki]

#24097: evdns_callback(): Bug: eventdns returned no addresses or error
--+
 Reporter:  toralf|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:   => Tor: 0.3.2.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] #21509 [Core Tor/Tor]: Fuzz v3 hidden services

[Tor Bug Tracker & Wiki]

#21509: Fuzz v3 hidden services
---+
 Reporter:  teor   |  Owner:  nickm
 Type:  task   | Status:  accepted
 Priority:  High   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  fuzz, prop224, tor-hs  |  Actual Points:
Parent ID: | Points:  2
 Reviewer: |Sponsor:  SponsorR-can
---+
Changes (by nickm):

 * priority:  Very High => High
 * status:  merge_ready => accepted


Comment:

 merged to 0.3.2!

 Sounds like you think there's more work, so putting this back in
 "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] [Tor Bug Tracker & Wiki] Batch modify: #23684, #23845, #23846, #23847, ...

[Tor Bug Tracker & Wiki]

Batch modification to #23684, #23845, #23846, #23847, #23900 by ahf:


--
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] #22605 [Core Tor/Tor]: sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/tor/torrc.d/

[Tor Bug Tracker & Wiki]

#22605: sandbox_intern_string(): Bug: No interned sandbox parameter found for
/etc/tor/torrc.d/
-+-
 Reporter:  toralf   |  Owner:  dgoulet
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  sandbox, regression, 031-backport,   |  Actual Points:
  032-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  sandbox, regression, 031-backport, 032-backport, review-
 group-24 => sandbox, regression, 031-backport, 032-backport


--
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] #22605 [Core Tor/Tor]: sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/tor/torrc.d/

[Tor Bug Tracker & Wiki]

#22605: sandbox_intern_string(): Bug: No interned sandbox parameter found for
/etc/tor/torrc.d/
-+-
 Reporter:  toralf   |  Owner:  dgoulet
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  sandbox, regression, 031-backport,   |  Actual Points:
  032-backport, review-group-24  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 b76a161e019dd808119f9e6d3bfa54990e7dcb2c is the merge commit for putting
 this into master.  Might need to look at that one if we do choose to
 backport.

--
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] #22605 [Core Tor/Tor]: sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/tor/torrc.d/

[Tor Bug Tracker & Wiki]

#22605: sandbox_intern_string(): Bug: No interned sandbox parameter found for
/etc/tor/torrc.d/
-+-
 Reporter:  toralf   |  Owner:  dgoulet
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  sandbox, regression, 031-backport,   |  Actual Points:
  032-backport, review-group-24  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 The branch is now `fix-torrcd-sandbox-22605v2` in my public repository --
 I added a changes 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] #21509 [Core Tor/Tor]: Fuzz v3 hidden services

[Tor Bug Tracker & Wiki]

#21509: Fuzz v3 hidden services
---+
 Reporter:  teor   |  Owner:  nickm
 Type:  task   | Status:  merge_ready
 Priority:  Very High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  fuzz, prop224, tor-hs  |  Actual Points:
Parent ID: | Points:  2
 Reviewer: |Sponsor:  SponsorR-can
---+
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 Great addition!

 This will allow us to test the `decode_superencrypted()` function but most
 of it is `tokenize_string()`. So a good next step would be to explicitly
 fuzz `decode_intro_points()` which happens if the super encrypted section
 is properly decrypted and decoded. See `desc_decode_encrypted_v3()`

 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] #22605 [Core Tor/Tor]: sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/tor/torrc.d/

[Tor Bug Tracker & Wiki]

#22605: sandbox_intern_string(): Bug: No interned sandbox parameter found for
/etc/tor/torrc.d/
-+-
 Reporter:  toralf   |  Owner:  dgoulet
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  sandbox, regression, 031-backport,   |  Actual Points:
  032-backport, review-group-24  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Oh hey; 0.3.3 is open.  Merging it there.  Marking for possible 0.3.2
 backport, though I lean towards "no backport" 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] #13605 [Core Tor/Tor]: Create a client/relay-side ReducedExitPolicy

[Tor Bug Tracker & Wiki]

#13605: Create a client/relay-side ReducedExitPolicy
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, easy, review-group-18,|  implemented
  review-group-24|  Actual Points:  3
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 I've put my changes (minor) in branch `13605_reduced_exit` in my public
 repository; I've merged a squashed version to master.  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] #24085 [Core Tor/Stem]: Note that 'GETINFO net/listeners/*' specifies 0.0.0.0 (or another local address)

[Tor Bug Tracker & Wiki]

#24085: Note that 'GETINFO net/listeners/*' specifies 0.0.0.0 (or another local
address)
---+
 Reporter:  atagar |  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Minor  | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by atagar):

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


Comment:

 Thanks Tim! Fixed...

 https://gitweb.torproject.org/stem.git/commit/?id=66a9b77

 Feel free to reopen if I'm still missing something.

--
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] #21394 [Core Tor/Tor]: connection timeouts are affecting Tor Browser usability

[Tor Bug Tracker & Wiki]

#21394: connection timeouts are affecting Tor Browser usability
-+-
 Reporter:  arthuredelstein  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-performance, tbb-usability,  |  Actual Points:
  performance, tbb-needs |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 I ran another test, this time with a CircuitStreamTimeout of 100
 (seconds):
 * Raw results:
 https://arthuredelstein.net/tor/21394/exit_results_20171031.json
 * Table for comparison with comment:28:
 
https://docs.google.com/spreadsheets/d/1c3YtAtIVbQXCw6HthQgn5ZYEGuovbfc855IYielIVR4/edit?usp=sharing

 Overall timeout counts:
 Always timed out: 15
 Sometimes timed out: 61
 Never timed out: 706

 The number of stream timeout events were substantially reduced relative to
 comment:27. It's not a perfect comparison because this was done on a
 different day, and the total test time took substantially longer. But it
 does seem to suggest that DNS services for some of the exits are backed
 up, not disabled. Next I can look at the distribution of DNS response
 times. Then I plan to contact some exit relay operators with poor DNS
 response and see if they can investigate why their DNS is very slow or not
 working.

--
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] #23762 [Core Tor/Tor]: hs-v3: Client request with missing dirinfo will always timeout

[Tor Bug Tracker & Wiki]

#23762: hs-v3: Client request with missing dirinfo will always timeout
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs, prop224, tor-client, |  Actual Points:
  review-group-24|
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 squashed and merged into maint-0.3.2 and forward.  Let's hope it's 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

Re: [tor-bugs] #23170 [Core Tor/Tor]: Include ed25519 relay id keys in the consensus

[Tor Bug Tracker & Wiki]

#23170: Include ed25519 relay id keys in the consensus
-+-
 Reporter:  asn  |  Owner:  nickm
 Type:  task | Status:
 |  accepted
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224 tor-dirauth tor-hs ed25519   |  Actual Points:
  needs-proposal TorCoreTeam201711.1 |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorR-can
-+-
Changes (by nickm):

 * keywords:  prop224 tor-dirauth tor-hs ed25519 needs-proposal => prop224
 tor-dirauth tor-hs ed25519 needs-proposal TorCoreTeam201711.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] #22955 [Core Tor/Tor]: Specify how PrivCount will work with Tor

[Tor Bug Tracker & Wiki]

#22955: Specify how PrivCount will work with Tor
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  task | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  privcount, prop280,  |  Actual Points:
  TorCoreTeam201711.1|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorQ-can
-+-
Changes (by nickm):

 * keywords:  privcount, prop280 => privcount, prop280, TorCoreTeam201711.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] #22955 [Core Tor/Tor]: Specify how PrivCount will work with Tor

[Tor Bug Tracker & Wiki]

#22955: Specify how PrivCount will work with Tor
+
 Reporter:  teor|  Owner:  nickm
 Type:  task| Status:  accepted
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  privcount, prop280  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:  SponsorQ-can
+
Changes (by nickm):

 * cc: teor, robgjansen, amj703 (added)
 * owner:  (none) => nickm
 * status:  new => accepted
 * keywords:  privcount => privcount, prop280


Comment:

 I started some work here as prop280, and gotten some feedback.  Carolin
 Zöbelein has also written some outlines for a Shamir-based protocol.  I've
 taken a shot at a variation of a Shamir-based protocol at
 https://github.com/nmathewson/privcount_shamir , where it appears as a
 python prototype.

 Current open question: does Shamir-style secret sharing actually do
 anything to help with the case where some Data Collectors are misbehaving?
 So far as I can tell, it only really helps us handle malfunctioning Tally
 Reporters.

--
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] #24099 [Core Tor/Tor]: tor should remove empty/invalid consensus cache files (Unable to map file from consensus cache: Numerical result out of range)

[Tor Bug Tracker & Wiki]

#24099: tor should remove empty/invalid consensus cache files (Unable to map 
file
from consensus cache: Numerical result out of range)
--+
 Reporter:  Hello71   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Minor |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 I use XFS, which tends to leave newly-written files empty on crash rather
 than non-existent. tor should handle this better.

--
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] #23571 [Core Tor/Tor]: Stop closing channels out from under OR connections in hibernate_go_dormant()

[Tor Bug Tracker & Wiki]

#23571: Stop closing channels out from under OR connections in
hibernate_go_dormant()
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.7-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-relay, tor-client, hibernate,|  Actual Points:  0.2
  review-group-24|
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Squashed as `bug23571_033_squashed` and merged to master. 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] #24018 [Metrics/Statistics]: Automate measuring connection timeouts per exit

[Tor Bug Tracker & Wiki]

#24018: Automate measuring connection timeouts per exit
+--
 Reporter:  arthuredelstein |  Owner:  metrics-team
 Type:  project | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-performance, tbb-needs  |  Actual Points:
Parent ID:  #21394  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by robgjansen):

 TLDR; OnionPerf does not currently do a great job of capturing DNS issues,
 but it could be made to do so.

 OnionPerf works by setting up a [https://github.com/shadow/shadow/wiki/3.3
 -TGen-Config traffic generator (TGen)] client and a server on the machine
 on which OnionPerf is run. OnionPerf makes the server accessible via an
 onion service (no DNS involved) as well as via the regular Internet. The
 client guesses an IP address of the machine on which it is running, and
 makes requests through Tor to that IP address.

 The reason for the above behavior is that it does not depend on the user
 running OnionPerf actually having a domain name registered for the host
 running OnionPerf. I thought that was a usability win, but I can see that
 this means we are missing some important aspect of Tor Browser
 performance.

 In principle, OnionPerf should be able to either pass IP address or domain
 name to Tgen. In the case that it passes a domain name, TGen will
 currently do the lookup itself rather than asking the socks proxy (Tor) to
 do it. In principle, TGen could ask the socks proxy (Tor) to do the lookup
 instead, and in fact the code already exists to do so in order to handle
 .onion fetches.

 Assuming that DNS errors would then be reported by Tor through the control
 port, it would be simple to have OnionPerf parse those errors and include
 them in the [https://metrics.torproject.org/collector.html#torperf output
 files desscribed here], or else in the raw json files that OnionPerf
 produces but Tor metrics does not yet publish.

--
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] #23693 [Core Tor/Tor]: 0.3.1.7: Assertion threadpool failed in cpuworker_queue_work

[Tor Bug Tracker & Wiki]

#23693: 0.3.1.7: Assertion threadpool failed in cpuworker_queue_work
-+-
 Reporter:  alif |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.7
 Severity:  Normal   | Resolution:  fixed
 Keywords:  029-backport, 030-backport,  |  Actual Points:
  031-backport, review-group-24  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 (please reopen if this bug occurs in any version released _after_ today.)

--
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] #23693 [Core Tor/Tor]: 0.3.1.7: Assertion threadpool failed in cpuworker_queue_work

[Tor Bug Tracker & Wiki]

#23693: 0.3.1.7: Assertion threadpool failed in cpuworker_queue_work
-+-
 Reporter:  alif |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.7
 Severity:  Normal   | Resolution:
 Keywords:  029-backport, 030-backport,  |  Actual Points:
  031-backport, review-group-24  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Thanks!  I've merged this to 0.2.9 and 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] #23261 [Applications/Tor Launcher]: implement configuration portion of new Tor Launcher UI

[Tor Bug Tracker & Wiki]

#23261: implement configuration portion of new Tor Launcher UI
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  ux-team, TorBrowserTeam201710R  |  Actual Points:
Parent ID:  #21951  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by mcs):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:33 gk]:
 > Okay. I went over all three commits and they look good to me apart from
 minor issues. Great work! I'll post all my comments here to not have them
 scattered over different tickets.
 >
 > c6fd54b8ba36bf88630db446c68ba8d04ed9727a
 >
 > 1)`` <- whitespace before
 ">"
 > 2) I was a bit confused by the mix of of " />" and "/>", the former
 seems to be for older code? Just as a note that's not something that needs
 to get fixed
 > 3) please fix `TODO2017` items or file new tickets

 We addressed all of the above issues. For consistency, we removed all of
 the extra spaces from the XUL near " />" and ">" (although some are done
 in the other patches). We also reinstated the "For assistance" text and
 inserted the help text that Linda proposed in comment:25 (which should be
 updated after we have a broader discussion about how to improve it).

 We also found and fixed a bug that caused PTs were near the end of the
 list of
 defaults bridges to not be shown in the UI (e.g., snowflake was missing on
 Mac), and we removed some old code that set up the label and access key
 for the built-in  help button (which we no longer use, since we
 now have two buttons).

 > 1ebd091f1e185ccf3ffaa739bf8ec232447ead8a
 >
 > 1) Here you are not doing the "var" -> "let" renaming as in the previous
 commit, any reason for that? (not necessarily something to fix)

 We fixed some more of these in functions that we touched (but not
 everywhere yet).

 > 2) no mixed {} if-else clauses (see `readTorSettings()`)

 Bad habits ;) Fixed.

 > ba78bfa36ebac398511ddde1ece70f82d202383a
 >
 > 1) no mixed {} if-else clauses (see `_configureDefaultBridges` in tl-
 process.js and `showAlert()` in tl-util.jsm)

 Fixed.

 > One bug I found (it's not new though):
 >
 > 1) Start with connecting directly.
 > 2) Open the Tor Launcher network settings in the browser window and
 check the firewall option
 > 3) Click okay and restart the browser
 > 4) Cancel normal start-up and configure bridges (obfs4)
 > 5) Check the Tor Launcher network settings in the browser window and the
 firewall option is now unchecked (which should not be the case)

 Good find. I created #24098.

 > I am still chasing two other bugs which I failed to trigger again, so
 more might come. :)

 Okay. I am sure there are more bugs. We do have a new branch to review
 (still three patches):
 https://gitweb.torproject.org/user/brade/tor-
 launcher.git/log/?h=bug23261-02

--
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] #24098 [Applications/Tor Launcher]: setup wizard loses firewall setting

[Tor Bug Tracker & Wiki]

#24098: setup wizard loses firewall setting
---+---
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+---
 From ticket:23261#comment:33:

 1) Start with connecting directly.
 2) Open the Tor Launcher network settings in the browser window and check
 the firewall option
 3) Click okay and restart the browser
 4) Cancel normal start-up and configure bridges (obfs4)
 5) Check the Tor Launcher network settings in the browser window and the
 firewall option is now unchecked (which should not be the case)

--
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] #24097 [Core Tor/Tor]: evdns_callback(): Bug: eventdns returned no addresses or error

[Tor Bug Tracker & Wiki]

#24097: evdns_callback(): Bug: eventdns returned no addresses or error
--+
 Reporter:  toralf|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.3-alpha
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Got this today for the 1st time IIRC at a stable Gentoo Linux :
 {{{
 ct 31 15:53:47.000 [warn] evdns_callback(): Bug: eventdns returned no
 addresses or error for [scrubbed]! (on Tor 0.3.2.3-alpha 023d756bfc04c244)
 }}}
 I do use dnsmasq with DNSSEC which points to 3x ipv4 and 3x ipv6 DNS
 resolver of my AS.

--
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] #23669 [Internal Services/Tor Sysadmin Team]: Deploy survey microsite to tpo infrastructure

[Tor Bug Tracker & Wiki]

#23669: Deploy survey microsite to tpo infrastructure
-+-
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team  |  Actual Points:
Parent ID:  #23376   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by hiro):

 So, in the end we have weighted the requirements and decided to use this
 instead:

 https://www.limesurvey.org/stable-release

 It is a php app, needs apache and postgres.

 The minimum set of requirements:


  * Minimum 180 MB disk space.
  * MySQL 5.5.3 or later '''OR''' Microsoft SQL Server 2005 or later
 '''OR''' Postgres 9 or later.
  * Minimum PHP 5.5.9 or later; however, we recommend PHP 7.0.0+ with the
 following modules/libraries enabled:
*
 
[https://manual.limesurvey.org/Installation_FAQ#Requirements_page.23What_is_the_mbstring_.28Multibyte_String_Functions.29_library
 mbstring (Multibyte String Functions)] extension library.
* PDO database driver for MySQL (pdo_mysql or pdo_mysqli) or Postgres
 (pdo_pgsql) or MSSQL ([https://php.net/manual/en/ref.pdo-sqlsrv.php
 pdo_sqlsrv] for Windows and [http://www.php.net/manual/en/ref.pdo-
 dblib.php pdo_dblib] for Linux).
* Also, we assume in general that all PHP default libraries are enabled
 (like hash, session etc.).

 I think we could be safe with 2GB diskspace for a long time.

 Let me know if you need anything else.

--
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] #23641 [Core Tor/Tor]: prop224: Fake client auth lines do not actually provide obfuscation

[Tor Bug Tracker & Wiki]

#23641: prop224: Fake client auth lines do not actually provide obfuscation
+
 Reporter:  asn |  Owner:  dgoulet
 Type:  defect  | Status:  needs_information
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  prop224 tor-hs  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  asn |Sponsor:
+

Comment (by dgoulet):

 Yeah either we keep auth line or we do some trick to not require that
 entire section at all Seems we are committed so maybe this whole patch
 is not 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

[tor-bugs] #24096 [Community/Tor Support]: cURL error 7: Can't complete SOCKS5 connection to 0.0.0.0:0. (6)

[Tor Bug Tracker & Wiki]

#24096: cURL error 7: Can't complete SOCKS5 connection to 0.0.0.0:0. (6)
---+---
 Reporter:  ahmad.saeed|  Owner:  phoul
 Type:  defect | Status:  new
 Priority:  Immediate  |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+---
 I'm using TOR with curl on ubuntu and after some specific number of
 requests it gives an error
 cURL error 7: Can't complete SOCKS5 connection to 0.0.0.0:0. (6) (see
 http://curl.haxx.se/libcurl/c/libcurl-errors.html)
 Actually I'm scrapping websites using PHP cURL with TOR as a background
 system service. It goes well until a limited/specific no of requests
 before throwing this error where curl is not able to connect TOR proxy
 through socket

--
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] #23623 [Core Tor/Tor]: hs: Cache current time period number and SRV start time

[Tor Bug Tracker & Wiki]

#23623: hs: Cache current time period number and SRV start time
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-sr, prop224  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+

Comment (by dgoulet):

 See extra commit in branch `ticket23623_032_01`.

 I have still yet to fix the tests. Will get on that 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

Re: [tor-bugs] #23820 [Core Tor/Tor]: Make sure v3 single onion services and v3 onion service clients only send IPv4 addresses

[Tor Bug Tracker & Wiki]

#23820: Make sure v3 single onion services and v3 onion service clients only 
send
IPv4 addresses
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion, ipv6  |  Actual Points:  1
Parent ID:  #23493   | Points:  1
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 @teor, I can fix those if you have no time but just let me know what you
 think about them. If you do fix them, I propose we go in Gitlab mode next
 time.

 * To be clear, I know Tor can't extend to an IPv6 so this should NEVER
 happened in theory right? (in get_lspecs_from_extend_info())

 {{{
 +  if (BUG(!tor_addr_is_v4(>addr))) {
 +return;
 +  }
 }}}

 * The `intro1_data` is initialized with `setup_introduce1_data()` which
 guarantee that the link specifier list will be a valid smartlist pointer
 and never uninit. So here, I would remove the NULL check so we don't hide
 bugs.

 {{{
 +  if (!intro1_data.link_specifiers ||
 +  !smartlist_len(intro1_data.link_specifiers)) {
 }}}

 * We could have a function that returns a static string for this so we
 make sure that every logs will have the same keywords. Something like
 `service_type_str()`

 {{{
 service->config.is_single_onion ? "direct" : "multi-hop"
 }}}

 * I'm skeptical that this will help our logging. I think base32 would be
 closer to the onion address than the hex string:

 {{{
 +   safe_str_client(hex_str((const char *)service_pk->pubkey,
 +   ED25519_PUBKEY_LEN)));
 }}}

 * Hmm this is possible that is SingleHopMode 0 and NonAnonymous 1 ? ...
 Looking at `rend_service_non_anonymous_mode_enabled()` seems to me that
 they have to be consistent?

 {{{
 +  log_warn(LD_CONFIG, "IPv6-only v3 single onion services are not "
 +   "supported. Set HiddenServiceSingleHopMode 0 and "
 +   "HiddenServiceNonAnonymousMode 1, or set ClientUseIPv4
 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] #24095 [Webpages/Website]: Add press clips to website

[Tor Bug Tracker & Wiki]

#24095: Add press clips to website
--+--
 Reporter:  steph |  Owner:  hiro
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by steph):

 * Attachment "Press clips for website - 2017 - new.csv" 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

[tor-bugs] #24095 [Webpages/Website]: Add press clips to website

[Tor Bug Tracker & Wiki]

#24095: Add press clips to website
--+--
 Reporter:  steph |  Owner:  hiro
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Add new clips from attached .csv to the press page. Link article titles to
 URLs and follow page formatting:
 ​​https://www.torproject.org/press/press.html.en

--
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] #23762 [Core Tor/Tor]: hs-v3: Client request with missing dirinfo will always timeout

[Tor Bug Tracker & Wiki]

#23762: hs-v3: Client request with missing dirinfo will always timeout
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, tor-client, |  Actual Points:
  review-group-24|
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => merge_ready
 * reviewer:  asn => dgoulet


Comment:

 Changes lgtm;

 Tests were failing and leaking. See branch with a fixup commit for that:
 `bug23762_032_02`

 Agree on the testing but it ain't easy to test this in unit test which
 requires _many_ thing to interact. We kind of have to bet on our
 integration test and user base for testing :S. However, that code path is
 hit in unit test for sure 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] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors

[Tor Bug Tracker & Wiki]

#23817: Tor re-tries directory mirrors that it knows are missing 
microdescriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-hs, prop224,  |  Actual Points:
  032-backport? 031-backport?|
Parent ID:  #21969   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:9 asn]:
 > Replying to [comment:7 teor]:
 > > Replying to [comment:6 asn]:
 > > > Here is an implementation plan of the failure cache idea from
 comment:4 .
 > > >
 > > > First of all, the interface of the failure cache:
 > > >
 > > >   We introduce a `digest256map_t *md_fetch_fail_cache` which maps
 the 256-bit md hash to a smartlist of dirguards thru which we failed to
 fetch the md.
 > > >
 > > > Now the code logic:
 > > >
 > > > 1) We populate `md_fetch_fail_cache` with dirguards in
 `dir_microdesc_download_failed()`.  We remove them from the failure cache
 in `microdescs_add_to_cache()` when we successfuly add an md to the cache.
 > >
 > > Successfully add *that* md to the cache?
 > > Or any md from that dirguard?
 > >
 >
 > I meant, we remove *that* md from the `md_fetch_fail_cache` if we manage
 to fetch *that* md from any dir.
 >
 > > I think this is ok, as long as we ask for mds in large enough batches.
 > >
 > > > 2) We add another `entry_guard_restriction_t` restriction type in
 `guards_choose_dirguard()`. We currently have one restriction type which
 is designed to restrict guard nodes based on the exit node choice and its
 family. We want another type which uses a smartlist and restricts
 dirguards based on whether we have failed to fetch an md from that
 dirguard. We are gonna use this in step 3.
 > > >
 > > > 3) In `directory_get_from_dirserver()` we query the md failure cache
 and pass any results to `directory_pick_generic_dirserver()` and then to
 `guards_choose_dirguard()` which uses the new restriction type to block
 previously failed dirguards from being selected.
 > >
 > > Do we block dirguards that have failed to deliver an md from downloads
 of that md?
 > > Or do we block dirguards that have failed to deliver any mds from
 downloads of any md?
 > >
 >
 > Yes, that's a good question that I forgot to address in this proposal.
 >
 > I guess my design above was suggesting that we block dirguards "that
 have failed to deliver any mds from downloads of any md", until those mds
 get fetched from another dirserver and get removed from the failure cache.

 I think this is the behaviour we want: trying each dir server for each
 specific md will mean that we time out, because there are more mds than
 there are dir servers.

 There are two cases when this will cause us to fall back to the
 authorities:
 * we download a new consensus from the authorities, and they are the only
 ones with some of the mds in it
 * for some reason, an md referenced in the consensus is not mirrored
 correctly by relays or authorities (this would be a serious bug in tor)

 To avoid this happening when it isn't necessary, we should expire failure
 cache entries after a random time. Maybe it should be the time when we
 expect dir servers to fetch a new consensus and new mds. I think this is
 1-2 hours, but check dir-spec for the exact details. Or we could expire md
 failure caches each time we get a new consensus. That would be easier.

 > That kinda penalizes dirservers that dont have a totally up-to-date md
 cache, which perhaps kinda makes sense. But perhaps before we become so
 strict, we should check whether we can improve the dirserver logic of
 fetching new mds so that they are almost always up-to-date if possible? Or
 we can do this last part after we implement the failure cache proposal?

 No, it's not possible to improve this behaviour without major changes to
 tor. A directory server can't fetch new mds until it fetches a new
 consensus that references them. And these fetches are done at random times
 to avoid flooding authorities with queries.

--
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] #24094 [Core Tor/Torflow]: measured bw percentage is always 100

[Tor Bug Tracker & Wiki]

#24094: measured bw percentage is always 100
--+-
 Reporter:  Sebastian |  Owner:  tom
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Torflow  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Using tor 0.3.1.7, I get this right from the first start:

 NOTICE[Tue Oct 31 12:45:15 2017]:Measured 100.0% of all tor nodes (100.0%
 of previous consensus bw).

 the bwscan-file is produced but only contains 400 lines.

--
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] #23318 [Core Tor/Tor]: compute_weighted_bandwidths: do not add 0.5 to final_weight

[Tor Bug Tracker & Wiki]

#23318: compute_weighted_bandwidths: do not add 0.5 to final_weight
-+-
 Reporter:  cypherpunks  |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  path-selection, 029-backport,|  Actual Points:
  030-backport, 031-backport, review-group-24|
Parent ID:   | Points:  1
 Reviewer:  asn  |Sponsor:
 |  SponsorQ
-+-
Changes (by dgoulet):

 * reviewer:   => asn


Comment:

 Fix lgtm but I think we should give an opportunity to asn to address the
 response to his comment.

--
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] #23693 [Core Tor/Tor]: 0.3.1.7: Assertion threadpool failed in cpuworker_queue_work

[Tor Bug Tracker & Wiki]

#23693: 0.3.1.7: Assertion threadpool failed in cpuworker_queue_work
-+-
 Reporter:  alif |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.7
 Severity:  Normal   | Resolution:
 Keywords:  029-backport, 030-backport,  |  Actual Points:
  031-backport, review-group-24  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 Replying to [comment:8 nickm]:
 > Possible fix in branch `bug23693_029` in my public repository, assuming
 I have the diagnosis right.

 lgtm; I confirm that going from client -> bridge is working properly.

 Agree on the backport.

--
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] #24093 [HTTPS Everywhere/HTTPS Everywhere: Chrome]: How To Download Tor Browser?

[Tor Bug Tracker & Wiki]

#24093: How To Download Tor Browser?
-+-
 Reporter:  liamrandall  |  Owner:  jsha
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
 |  Torbutton: 1.4
Component:  HTTPS Everywhere/HTTPS Everywhere:   |Version:  Tor:
  Chrome |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  assignment writing, assignment   |  worksforme
  help, PHP assignment, assignment writing   |  Actual Points:
  service, best assignment writing services  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

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


Comment:

 Hi spammer. This has to be a spam.

--
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] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors

[Tor Bug Tracker & Wiki]

#23817: Tor re-tries directory mirrors that it knows are missing 
microdescriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-hs, prop224,  |  Actual Points:
  032-backport? 031-backport?|
Parent ID:  #21969   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 Replying to [comment:7 teor]:
 > Replying to [comment:6 asn]:
 > > Here is an implementation plan of the failure cache idea from
 comment:4 .
 > >
 > > First of all, the interface of the failure cache:
 > >
 > >   We introduce a `digest256map_t *md_fetch_fail_cache` which maps the
 256-bit md hash to a smartlist of dirguards thru which we failed to fetch
 the md.
 > >
 > > Now the code logic:
 > >
 > > 1) We populate `md_fetch_fail_cache` with dirguards in
 `dir_microdesc_download_failed()`.  We remove them from the failure cache
 in `microdescs_add_to_cache()` when we successfuly add an md to the cache.
 >
 > Successfully add *that* md to the cache?
 > Or any md from that dirguard?
 >

 I meant, we remove *that* md from the `md_fetch_fail_cache` if we manage
 to fetch *that* md from any dir.

 > I think this is ok, as long as we ask for mds in large enough batches.
 >
 > > 2) We add another `entry_guard_restriction_t` restriction type in
 `guards_choose_dirguard()`. We currently have one restriction type which
 is designed to restrict guard nodes based on the exit node choice and its
 family. We want another type which uses a smartlist and restricts
 dirguards based on whether we have failed to fetch an md from that
 dirguard. We are gonna use this in step 3.
 > >
 > > 3) In `directory_get_from_dirserver()` we query the md failure cache
 and pass any results to `directory_pick_generic_dirserver()` and then to
 `guards_choose_dirguard()` which uses the new restriction type to block
 previously failed dirguards from being selected.
 >
 > Do we block dirguards that have failed to deliver an md from downloads
 of that md?
 > Or do we block dirguards that have failed to deliver any mds from
 downloads of any md?
 >

 Yes, that's a good question that I forgot to address in this proposal.

 I guess my design above was suggesting that we block dirguards "that have
 failed to deliver any mds from downloads of any md", until those mds get
 fetched from another dirserver and get removed from the failure cache.

 That kinda penalizes dirservers that dont have a totally up-to-date md
 cache, which perhaps kinda makes sense. But perhaps before we become so
 strict, we should check whether we can improve the dirserver logic of
 fetching new mds so that they are almost always up-to-date if possible? Or
 we can do this last part after we implement the failure cache proposal?

--
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] #15618 [Core Tor/Tor]: Tried to establish rendezvous on non-OR circuit with purpose Acting as rendevous (pending)

[Tor Bug Tracker & Wiki]

#15618: Tried to establish rendezvous on non-OR circuit with purpose Acting as
rendevous (pending)
-+-
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs needs-insight needs-  |  Actual Points:
  diagnosis  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by dgoulet):

 Hey s7r! You seems to have DEBUG logs there, you think you can attach them
 (or send them to me private if sensitive) to me. I would like to see a bit
 more of the inners of tor service side for this?

 The fact that we see that "sometimes" and we see it in burst tells me that
 it is likely someone doing that either on purpose or a VERY buggy
 implementation. The tor client can't open 300 circuit to a service in a
 relatively short amount of time and all have the bug for those... seems
 VERY unlikely, we would see that more often.

 Those 300 warnings are spread out how over 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] #23623 [Core Tor/Tor]: hs: Cache current time period number and SRV start time

[Tor Bug Tracker & Wiki]

#23623: hs: Cache current time period number and SRV start time
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-sr, prop224  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+
Changes (by asn):

 * status:  needs_review => needs_revision


--
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] #23623 [Core Tor/Tor]: hs: Cache current time period number and SRV start time

[Tor Bug Tracker & Wiki]

#23623: hs: Cache current time period number and SRV start time
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-sr, prop224  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+

Comment (by asn):

 Hmm, seems like we will only recompute voting schedule if we are a dirauth
 with this patch
 because of how `dirvote_recalculate_timing()` works.

 We should probably change that, and document the new voting schedule
 setting behavior in `static voting_schedule_t voting_schedule;`.

--
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] #23856 [Core Tor/Tor]: Reduce relay bandwidth stats interval to 24 hours

[Tor Bug Tracker & Wiki]

#23856: Reduce relay bandwidth stats interval to 24 hours
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  guard-discovery-stats  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:  SponsorQ
---+

Comment (by teor):

 The relevant constants in tor are:

 NUM_SECS_BW_SUM_INTERVAL and maybe we will need to increase
 NUM_SECS_BW_SUM_IS_VALID to remember 2-4 days of daily bandwidth, rather
 than just one day:
 https://gitweb.torproject.org/tor.git/tree/src/or/rephist.c#n1242

 And maybe we should also change MAX_BANDWIDTH_CHANGE_FREQ, otherwise
 relays will report bandwidth spikes every 20 minutes in their descriptors.
 But we should be careful here, because this affects the bandwidth
 authority system. But it seems that at least an hour would be reasonable:
 https://gitweb.torproject.org/tor.git/tree/src/or/router.c#n2516

--
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] #24093 [HTTPS Everywhere/HTTPS Everywhere: Chrome]: How To Download Tor Browser?

[Tor Bug Tracker & Wiki]

#24093: How To Download Tor Browser?
-+-
 Reporter:  liamrandall  |  Owner:  jsha
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Torbutton: 1.4
Component:  HTTPS|Version:  Tor: unspecified
  Everywhere/HTTPS Everywhere:   |   Keywords:  assignment writing,
  Chrome |  assignment help, PHP assignment,
 Severity:  Normal   |  assignment writing service, best
 |  assignment writing services
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 I just wanted to know from where i can download Tor Browser so that i
 could also be able to enjoy the browsing over this browser. I have heard
 about this browser many a times from my colleagues. I want to download to
 watch all my lectures and download it as well so that i could complete my
 programming assignments as well.
 [https://www.britishassignmentwriting.co.uk/ Professional Assignment
 Writing Services For Programming Students]

--
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] #23101 [Core Tor/Tor]: Predict and build specific HS purpose circuits (rather than GENERAL)

[Tor Bug Tracker & Wiki]

#23101: Predict and build specific HS purpose circuits (rather than GENERAL)
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-guard, guard-discovery-  |  Actual Points:
  prop247-controller |
Parent ID:  #9001| Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:1 asn]:
 > One approach here is to indeed define new circuit purposes for HS
 circuits. My main fear here is that these circuit purposes are used for
 tons of things in the codebase (from circuit timeouts, to cannibalization,
 to guard stuff, to stats stuff, to basic circuit functionality state
 machine), and hence adding new purposes means that we need to find
 '''all''' the right places to consider our new purposes which I imagine is
 gonna be a PITA and perhaps error-prone...

 Yes, it will be error-prone. I wonder how we can make this state machine
 easier to modify in future?

 > Another approach would be to use the `hs_ident` and `rend_data` elements
 of the `circuit_t` to distinguish HS circuits from normal circuits. That's
 what most of the code is doing to detect HS rend circuits.

 No, these fields are not populated until the circuit is used for
 rendezvous.
 So they can't be used to identify preemptive circuits that are built with
 vanguards.

--
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] #23641 [Core Tor/Tor]: prop224: Fake client auth lines do not actually provide obfuscation

[Tor Bug Tracker & Wiki]

#23641: prop224: Fake client auth lines do not actually provide obfuscation
+
 Reporter:  asn |  Owner:  dgoulet
 Type:  defect  | Status:  needs_information
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  prop224 tor-hs  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  asn |Sponsor:
+
Changes (by asn):

 * status:  needs_review => needs_information


Comment:

 Do we think this is still worth doing even tho we will not be able to
 remove `str_desc_auth_key` and `str_desc_auth_type` since the code
 requires it? Seems like we are kinda commited to some sort of fake auth
 data anyway, so perhaps we could keep one line of fake auth-client too if
 we need to?

--
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] #22728 [Core Tor/Tor]: Long-lived onion service circuits can enable guard discovery

[Tor Bug Tracker & Wiki]

#22728: Long-lived onion service circuits can enable guard discovery
---+---
 Reporter:  mikeperry  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  guard-discovery-stats, tor-hs  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by asn):

 * cc: asn (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] #23834 [Community/Tor Support]: Edit WeSupportTor

[Tor Bug Tracker & Wiki]

#23834: Edit WeSupportTor
---+--
 Reporter:  cypherpunks|  Owner:  phoul
 Type:  task   | Status:  reopened
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 https://support.mailbox.org/knowledge-base/article/der-tor-exit-node-von-
 mailbox-org


  Öffnen Sie die Konfigurationsdatei torrc mit einem Editor (siehe: Tor
 FAQ). Wenn Sie das TorBrowserBundle nutzen, müssen Sie den TorBrowser
 zuvor einmalig starten und wieder beenden. Dann können Sie die Datei
 Browser/TorBrowser/data/Tor/torrc in einem Texteditor öffnen und folgende
 MapAdressen für mailbox.org und alle Sub-Domains am Ende der Datei
 hinzufügen:

 MapAddress mailbox.org
 mailbox.org.85D4088148B1A6954C9BFFFCA010E85E0AA88FF0.exit
 MapAddress *.mailbox.org
 *.mailbox.org.85D4088148B1A6954C9BFFFCA010E85E0AA88FF0.exit

 Damit wird sichergestellt, dass Ihr Datenverkehr durch das Tor Netzwerk
 bis in unser Datacenter geleitet wird und dort direkt unsere Server
 erreicht. Im weitesten Sinne könnte man das mit einer Art VPN-Verbindung
 direkt in unser Rechenzentrum vergleichen.


 Write in English goddammit.

--
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] #23834 [Community/Tor Support]: Edit WeSupportTor

[Tor Bug Tracker & Wiki]

#23834: Edit WeSupportTor
---+--
 Reporter:  cypherpunks|  Owner:  phoul
 Type:  task   | Status:  reopened
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cypherpunks):

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


Comment:

 Why did you put Mailbox.Org back? Do you really think adding their ".exit"
 rules to torrc is a good idea?

 Someone should add "mailbox.org" to spam filter.

 Reopening this ticket because someone added it 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

[tor-bugs] #24092 [Internal Services/Service - git]: Create a torsocks repo for ln5

[Tor Bug Tracker & Wiki]

#24092: Create a torsocks repo for ln5
-+
 Reporter:  ln5  |  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:   |
-+
 Please create repo

 user/linus/torsocks
 Linus' torsocks repository

--
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] #20892 [Applications/Tor Browser]: tools/update-responses/download_missing_versions fails to download OSX mar files

[Tor Bug Tracker & Wiki]

#20892: tools/update-responses/download_missing_versions fails to download OSX 
mar
files
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201702  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [comment:6 boklm]:
 > An other option would be to use the new `sha256sums-signed-build.txt`
 file, to check the downloads.

 That's a good idea. Waiting for #18925 might still take a while :/

--
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] #22612 [Applications/Tor Browser]: Provide a list sha256's for verified binary downloads from mirrors

[Tor Bug Tracker & Wiki]

#22612: Provide a list sha256's for verified binary downloads from mirrors
---+--
 Reporter:  BenjaminCarr   |  Owner:  tbb-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201710  |  Actual Points:
Parent ID:  #20892 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gk):

 * parent:   => #20892


--
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] #10394 [Applications/Tor Browser]: Torbrowser's updater updates HTTPS-everywhere

[Tor Bug Tracker & Wiki]

#10394: Torbrowser's updater updates HTTPS-everywhere
+--
 Reporter:  StrangeCharm|  Owner:  tbb-team
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-security, TorBrowserTeam201711  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * status:  reopened => assigned
 * keywords:  tbb-security => tbb-security, TorBrowserTeam201711


Comment:

 I heard we are close to be able to test that. Hopefully this can already
 happen in the next regular alpha release. Putting it on our radar for
 November.

--
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] #19926 [Core Tor/Tor]: BUG warning in connection_ap_attach_pending: waiting for rendezvous desc :*

[Tor Bug Tracker & Wiki]

#19926: BUG warning in connection_ap_attach_pending: waiting for rendezvous 
desc :*
-+
 Reporter:  cypherpunks  |  Owner:  dgoulet
 Type:  defect   | Status:  accepted
 Priority:  High |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.2.9.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  bug, regression, tor-hs  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by cypherpunks):

 Well, I don't know. I was that user who reported it in tor blog recently
 and who wrote 2 comments after gk reopened the ticket.


 > A connection in the `RENDDESC_WAIT` state can only get out of that state
 if the descriptor actually arrives at the client or if the SOCKS
 connection is closed.


 I don't know, but... can it be triggered by my `iptables` rules? It is
 well known that `iptables` is too buggy with `--owner` option. It blocks
 many valid packets because of so many reasons... that nobody wants to fix
 them all yet. In my case it is the case too, so I manually block these
 extra packets that do not pass `iptables` anyway. Normally this blocking
 has no effect on any application, but I cannot sure that. If HS is
 accessed many times, some attempts are interrupted and too many fails...
 does it mean that SOCKS connections can be sometimes suddenly interrupted
 and closed?

 I would like to see more detailed tor log options, that will give more
 information about what happens, but which is not so detailed as `info`,
 because `info` gives too much irrelevant information and that information
 cannot be shared because it contains sensitive information. Ideally I
 would be glad to see debug-level logs which can be safely shared with tor
 community without disclosing my tor chains, my guards, and HS I visit.

--
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] #23484 [Webpages/Website]: Add donation banner to homepage for 2017 campaign

[Tor Bug Tracker & Wiki]

#23484: Add donation banner to homepage for 2017 campaign
--+
 Reporter:  arthuredelstein   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  crowdfunding  |  Actual Points:
Parent ID:  #23482| Points:
 Reviewer:|Sponsor:
--+
Changes (by arthuredelstein):

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


Comment:

 Merged by hiro as
 
https://gitweb.torproject.org/project/web/webwml.git/commit/?id=7f17ea251531e45fdf372ee8fd65a02baf9ad3e3.
 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