Re: [tor-bugs] #28677 [Applications/Tor Browser]: Missing bundles after building alpha releases

[Tor Bug Tracker & Wiki]

#28677: Missing bundles after building alpha releases
---+--
 Reporter:  gk |  Owner:  tbb-team
 Type:  defect | Status:  closed
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  tbb-rbm, TorBrowserTeam201812  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gk):

 * status:  new => closed
 * keywords:  tbb-rbm => tbb-rbm, TorBrowserTeam201812
 * resolution:   => fixed


Comment:

 This got fixed in commit e9a2fc5a9d9ee5571ca6daf94ac367e14732cd50 on
 `master`

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #26858, #28540, #25702, #26843, ...

[Tor Bug Tracker & Wiki]

Batch modification to #26858, #28540, #25702, #26843, #25794, #26574, #26861, 
#27045, #27125, #27265, #27828, #28075, #28185, #28546, #28573, #28608 by gk:


Comment:
Move review tickets to Decemeber.

--
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] #26843 [Applications/Tor Browser]: TBA: Investigate how Mozilla Fennec provides localization

[Tor Bug Tracker & Wiki]

#26843: TBA: Investigate how Mozilla Fennec provides localization
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201811R,   |  Actual Points:
  TBA-a2, GeorgKoppen201811  |
Parent ID:  #26782   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Okay, I have an updated branch for review, `bug_26843_v6`
 (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/commit/?h=bug_26843_v6=1313336490abb4773e20d40347db79e46c26727e).

 Compared to `bug_26843_v5` it is rebased on the latest `master` and
 contains an indication in the bundle name that the .apk is actually not a
 single-locale one, using "multi" as Mozilla does.

--
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] #28612 [Core Tor/Tor]: Tor start via Windows service fails

[Tor Bug Tracker & Wiki]

#28612: Tor start via Windows service fails
+
 Reporter:  Vort|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.5.5-alpha
 Severity:  Normal  | Resolution:
 Keywords:  windows nt-service  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by Vort):

 * status:  needs_information => new


Comment:

 With fresh build `cpuworker_queue_work` bug popped out again.
 Let's switch to it. Here is the trace with `__asm__("int3");` added:
 {{{
 Thread 4 received signal SIGTRAP, Trace/breakpoint trap.
 [Switching to Thread 64900.0x1181c]
 cpuworker_queue_work (priority=priority@entry=WQ_PRI_LOW,
 fn=fn@entry=0x47b020 ,
 reply_fn=reply_fn@entry=0x47cd30 ,
 arg=arg@entry=0x285b530) at src/core/mainloop/cpuworker.c:502
 502   tor_assert(threadpool);
 (gdb) bt
 #0  cpuworker_queue_work (priority=priority@entry=WQ_PRI_LOW,
 fn=fn@entry=0x47b020 ,
 reply_fn=reply_fn@entry=0x47cd30 ,
 arg=arg@entry=0x285b530) at src/core/mainloop/cpuworker.c:502
 #1  0x0047d7ef in consensus_diff_queue_diff_work
 (diff_to=0x139ab10,
 diff_from=0x1405930) at src/feature/dircache/consdiffmgr.c:1718
 #2  consdiffmgr_rescan_flavor_ (flavor=FLAV_MICRODESC)
 at src/feature/dircache/consdiffmgr.c:1013
 #3  consdiffmgr_rescan () at src/feature/dircache/consdiffmgr.c:1127
 #4  0x621d4b30 in ?? () from D:\Tor\libevent-2-1-6.dll
 #5  0x621d5504 in ?? () from D:\Tor\libevent-2-1-6.dll
 #6  0x004149bf in run_main_loop_once ()
 at src/core/mainloop/mainloop.c:2926
 #7  run_main_loop_until_done () at src/core/mainloop/mainloop.c:2988
 #8  do_main_loop () at src/core/mainloop/mainloop.c:2883
 #9  0x004f4916 in nt_service_body (argc=,
 argv=) at src/app/main/ntmain.c:301
 #10 0x07fefdb1a82d in SECHOST!RegisterServiceCtrlHandlerExA ()
from C:\Windows\SYSTEM32\sechost.dll
 #11 0x778759cd in KERNEL32!BaseThreadInitThunk ()
from C:\Windows\system32\kernel32.dll
 #12 0x779d385d in ntdll!RtlUserThreadStart ()
from C:\Windows\SYSTEM32\ntdll.dll
 #13 0x in ?? ()
 Backtrace stopped: previous frame inner to this frame (corrupt stack?)
 (gdb) p threadpool
 $1 = (threadpool_t *) 0x0
 (gdb)
 }}}

 What I see is that `threadpool` should be initialized in `cpu_init`
 function.
 Which is called from `run_tor_main_loop` function.

 But it have no chance to be executed because `do_main_loop` is already
 fired by `nt_service_body`.

--
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] #28300 [Core Tor/Stem]: Scrolling support for tor-prompt is needed

[Tor Bug Tracker & Wiki]

#28300: Scrolling support for tor-prompt is needed
---+--
 Reporter:  wagon  |  Owner:  atagar
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:  Tor: 0.3.4.8
 Severity:  Normal | Resolution:  wontfix
 Keywords:  tor-prompt |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by wagon):

 > Inverse situation is with Tor version: it is shown in `/var/lib/tor
 /cached-microdesc-consensus` but Nyx does not show it in information about
 relays (connections window). Can relay's Tor version be learned from
 `ControlPort` too?
 See ticket #28676.

--
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] #28676 [Core Tor/Tor]: Tor versions of Tor nodes should be accessible through ControlPort

[Tor Bug Tracker & Wiki]

#28676: Tor versions of Tor nodes should be accessible through ControlPort
--+--
 Reporter:  wagon |  Owner:  arma
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by wagon):

 > I'd like to build an abstraction layer over all available directory
 documents (like #25999, but inside tor).
 I have another idea. We have some trade-off between internal Tor's
 complexity and Tor's network performance. We need some balance which will
 make Tor support and development effective and convenient.

 Microdescriptors were added to Tor code long time ago (10 years?), when
 internet in general and Tor network in particular were 10-20 times slower
 than now (you can check metrics graphs). Amount of Tor nodes increased
 only 3 times during this period. Now we could remove this redundancy by
 moving to single type descriptors which will be not as small as
 microdescriptors but will be complete. We need de-duplication.

 Then, on top of these simplified descriptors you could make some
 abstraction layer for `ControlPort`. As concerns its current state, there
 are also other issues, e.g. with
 
[[https://trac.torproject.org/projects/tor/ticket/28300#comment:4|status/version/num-{concurring,versioning}]]
 and with
 [[https://trac.torproject.org/projects/tor/ticket/28300#comment:6|"Option/*"]]
 values (I'm not sure I have to create separate tickets about that).

 P.S. I wonder why `ControlPort` can only be binded to loopback interface.
 Is it a bug or feature? I assume that in some environments, where Tor is
 controlled by a remote machine, it would be convenient to bind to another
 IP than 127.0.0.1 (firewall redirection can be used to overcome this
 difficulty, but direct binding is simpler to setup).

--
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] #27919 [Applications/Tor Browser]: Backport SSL status API to Tor Browser alpha

[Tor Bug Tracker & Wiki]

#27919: Backport SSL status API to Tor Browser alpha
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201812R,   |  Actual Points:
  GeorgKoppen201811  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  TorBrowserTeam201811, GeorgKoppen201811 =>
 TorBrowserTeam201812R, GeorgKoppen201811
 * cc: mcs, brade (added)
 * status:  needs_information => needs_review


Comment:

 Okay, this works with `bug_27919_v3`
 (https://gitweb.torproject.org/user/gk/tor-
 browser.git/log/?h=bug_27919_v3) (last six commits authored by Shane
 Caraveo). I backported the patch for the main bug
 (https://bugzilla.mozilla.org/show_bug.cgi?id=1322748) and all the child
 bugs that we need. Please review.

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

Re: [tor-bugs] #28675 [Core Tor/Tor]: Deprecate standard cookie authentication

[Tor Bug Tracker & Wiki]

#28675: Deprecate standard cookie authentication
+--
 Reporter:  wagon   |  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by arma):

 Replying to [comment:8 teor]:
 > But we need to allow other apps time to transition.

 I wonder if there are any apps that still use the old approach.

 > I suggest that we warn in 0.3.5 (long-term support), and remove in
 0.4.0.

 Sounds great.

--
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] #28675 [Core Tor/Tor]: Deprecate standard cookie authentication

[Tor Bug Tracker & Wiki]

#28675: Deprecate standard cookie authentication
+--
 Reporter:  wagon   |  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by wagon):

 LGTM. After that `control-spec.txt` should be also properly adjusted.

--
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] #5185 [Core Tor/Tor]: Implement ‘safe cookie authentication’ in Tor

[Tor Bug Tracker & Wiki]

#5185: Implement ‘safe cookie authentication’ in Tor
-+
 Reporter:  rransom  |  Owner:  (none)
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.2.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:  security-fix tor-client  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by arma):

 * priority:  Very High => Medium
 * severity:  Blocker => Normal


--
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] #5185 [Core Tor/Tor]: Implement ‘safe cookie authentication’ in Tor

[Tor Bug Tracker & Wiki]

#5185: Implement ‘safe cookie authentication’ in Tor
-+
 Reporter:  rransom  |  Owner:  (none)
 Type:  enhancement  | Status:  closed
 Priority:  Very High|  Milestone:  Tor: 0.2.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Blocker  | Resolution:  implemented
 Keywords:  security-fix tor-client  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by arma):

 * severity:   => Blocker


Comment:

 Replying to [comment:6 nickm]:
 > 13:27 < nickm> [...] Removing it before 0.2.4.x-rc, yes.

 #28675 looks like a fine opportunity for removing it.

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

Re: [tor-bugs] #28675 [Core Tor/Tor]: Deprecate standard cookie authentication

[Tor Bug Tracker & Wiki]

#28675: Deprecate standard cookie authentication
+--
 Reporter:  wagon   |  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by teor):

 Replying to [comment:4 arma]:
 > For more context, it looks like that sentence went into control-spec in
 commit {{{c402bdfe}}} in Feb 2012.
 >
 > It looks like SAFECOOKIE went in during 0.2.2.x and 0.2.3.x, which is a
 long time ago now.

 So all supported Tor versions support SAFECOOKIE. (As of December 2018, we
 support 0.2.9, and 0.3.3 and later.)

 > Re timeframe, Nick said on #5185: "Removing it before 0.2.4.x-rc, yes"
 >
 > I think removing it any time now is a fine plan.

 But we need to allow other apps time to transition.

 I suggest that we warn in 0.3.5 (long-term support), and remove in 0.4.0.

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

Re: [tor-bugs] #28675 [Core Tor/Tor]: Deprecate standard cookie authentication

[Tor Bug Tracker & Wiki]

#28675: Deprecate standard cookie authentication
+--
 Reporter:  wagon   |  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by wagon):

 Good. Thank you!

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

Re: [tor-bugs] #28675 [Core Tor/Tor]: Deprecate standard cookie authentication

[Tor Bug Tracker & Wiki]

#28675: Deprecate standard cookie authentication
+--
 Reporter:  wagon   |  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arma):

 * status:  assigned => new


Comment:

 Please don't assign random tickets to me -- it will slow them down, not
 speed them up.

--
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] #28675 [Core Tor/Tor]: Deprecate standard cookie authentication

[Tor Bug Tracker & Wiki]

#28675: Deprecate standard cookie authentication
+--
 Reporter:  wagon   |  Owner:  arma
 Type:  enhancement | Status:  assigned
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by arma):

 For more context, it looks like that sentence went into control-spec in
 commit {{{c402bdfe}}} in Feb 2012.

 It looks like SAFECOOKIE went in during 0.2.2.x and 0.2.3.x, which is a
 long time ago now.

 Re timeframe, Nick said on #5185: "Removing it before 0.2.4.x-rc, yes"

 I think removing it any time now is a fine plan.

--
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] #28675 [Core Tor/Tor]: Deprecate standard cookie authentication

[Tor Bug Tracker & Wiki]

#28675: Deprecate standard cookie authentication
+--
 Reporter:  wagon   |  Owner:  (none)
 Type:  enhancement | Status:  assigned
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arma):

 * owner:  arma => (none)


--
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] #27417 [Core Tor/Tor]: refactor conn_close_if_marked() in main.c

[Tor Bug Tracker & Wiki]

#27417: refactor conn_close_if_marked() in main.c
--+
 Reporter:  cyberpunks|  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  refactor  |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by teor):

 * milestone:  Tor: unspecified => Tor: 0.4.0.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] #28599 [Core Tor/Tor]: bandwidth-file-spec.txt: bandwidth-avg is not calculated from any bandwidth burst option

[Tor Bug Tracker & Wiki]

#28599: bandwidth-file-spec.txt: bandwidth-avg is not calculated from any 
bandwidth
burst option
--+
 Reporter:  juga  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:  #25925| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  new => closed
 * resolution:   => not a bug


Comment:

 If RelayBandwidthRate or RelayBandwidthBurst are missing from tor's
 config, the other option is used. RelayBandwidthRate must be less than or
 equal to RelayBandwidthBurst, or Tor won't start:
 
https://github.com/torproject/tor/blob/2b2b97484ad07c91ac410735a96fe8710e60cf23/src/app/config/config.c#L3936

 So I think the spec is accurate, but the calculations are done in a few
 different places.

--
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] #28692 [Core Tor/sbws]: sbws should set ConnectionPadding 0

[Tor Bug Tracker & Wiki]

#28692: sbws should set ConnectionPadding 0
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 See also #28694, where we'll also want to set CircuitPadding 0 (or
 whatever the option ends up being called).

--
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] #28610 [Core Tor/Tor]: will WTF-PAD impair bandwidth scanning?

[Tor Bug Tracker & Wiki]

#28610: will WTF-PAD impair bandwidth scanning?
--+
 Reporter:  starlight |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 We should keep this ticket open, so we think about which kinds of circuits
 we enable padding on, and how those machines should work.

 I suggest that we should enable padding by default on all circuits that
 might need anonymity.

--
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] #28610 [Core Tor/Tor]: will WTF-PAD impair bandwidth scanning?

[Tor Bug Tracker & Wiki]

#28610: will WTF-PAD impair bandwidth scanning?
--+
 Reporter:  starlight |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 I opened #28692 to set ConnectionPadding 0 in sbws' tor instance.
 I couldn't find an equivalent option for circuit padding, so I added
 #28693 for Tor, and #28694 for sbws.

--
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] #28694 [Core Tor/sbws]: When CircuitPadding is implemented in Tor, set it to 0 in sbws

[Tor Bug Tracker & Wiki]

#28694: When CircuitPadding is implemented in Tor, set it to 0 in sbws
-+-
 Reporter:  teor |  Owner:  (none)
 Type:   | Status:  new
  enhancement|
 Priority:  Medium   |  Milestone:  sbws: 1.0.x-final
Component:  Core |Version:
  Tor/sbws   |   Keywords:  wtf-pad, tor-relay, tor-cell,
 Severity:  Normal   |  padding
Actual Points:   |  Parent ID:  #28693
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 In #28693, we will implement a tor option for circuit padding.
 When that option is implemented, we should set it to 0 in sbws.

--
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] #28693 [Core Tor/Tor]: Add an option to disable circuit padding

[Tor Bug Tracker & Wiki]

#28693: Add an option to disable circuit padding
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.0.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  wtf-pad, tor-relay, tor-cell,
 Severity:  Normal   |  padding
Actual Points:   |  Parent ID:  #28632
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We need an option like ConnectionPadding to disable circuit padding.
 Do we also need ReducedCircuitPadding for mobile?

--
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] #28692 [Core Tor/sbws]: sbws should set ConnectionPadding 0

[Tor Bug Tracker & Wiki]

#28692: sbws should set ConnectionPadding 0
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 Now here's a challenge: sbws should set ConnectionPadding 0 if the option
 is supported by Tor.
 If the option isn't supported by Tor, then sbws should just continue.

 You can test with Tor 0.2.9 (no padding support) and Tor 0.3.3 or later
 (padding support).

 Here's a few things to try:
 * set the config option, and ignore the exception that stem returns for
 unsupported config options
 * use GETINFO config/names to see if the option is supported

--
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] #28692 [Core Tor/sbws]: sbws should set ConnectionPadding 0

[Tor Bug Tracker & Wiki]

#28692: sbws should set ConnectionPadding 0
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+---
 There's no reason to pad connections in sbws: sbws is not trying to avoid
 netflow logs.
 Padding can waste bandwidth, and reduce scanner accuracy,

--
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] #28612 [Core Tor/Tor]: Tor start via Windows service fails

[Tor Bug Tracker & Wiki]

#28612: Tor start via Windows service fails
+
 Reporter:  Vort|  Owner:  (none)
 Type:  defect  | Status:  needs_information
 Priority:  Medium  |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.5.5-alpha
 Severity:  Normal  | Resolution:
 Keywords:  windows nt-service  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by teor):

 * status:  new => needs_information


Comment:

 That's a really odd error:
 * all of those values are integers, so there shouldn't be a floating-point
 error
 * cfg->rate is checked for zero here:
 
https://github.com/torproject/tor/blob/02ba0a2dbbe1032b56d0ba17468f2ee0d95e4f1b/src/lib/evloop/token_bucket.c#L40

 I think we're going to need full logs or more information to diagnose this
 error.

--
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] #28614 [Core Tor/Tor]: Can't parse networkstatus consensus time

[Tor Bug Tracker & Wiki]

#28614: Can't parse networkstatus consensus time
-+
 Reporter:  Vort |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  040-rc-must, regression  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by teor):

 * keywords:   => 040-rc-must, regression


--
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] #28623 [Core Tor/Tor]: use documentation IP ranges for documentation (manpage)

[Tor Bug Tracker & Wiki]

#28623: use documentation IP ranges for documentation (manpage)
--+--
 Reporter:  nusenu|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy, doc |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * keywords:   => easy, doc


--
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] #28624 [Core Tor/Tor]: Should we remember dormant state on restart?

[Tor Bug Tracker & Wiki]

#28624: Should we remember dormant state on restart?
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+

Comment (by teor):

 > (2) ...I was going to use an example here of Tor bundled with an app,
 like Brave or Briar, but I think in this case the app should be
 responsible for making Tor behave politely to the Tor network.

 Here's the alternative we'll probably end up deploying:
 Tor should behave politely by default. If an app breaks that politeness,
 the app is responsible for managing the breakage. If an app breaks when
 tor is polite, the app is responsible for managing its own breakage.

--
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] #28636 [Core Tor/Tor]: Address WTF-PAD comments by Nick (2018-11-27 over IRC) (was: Address comments by Nick (2018-11-27 over IRC))

[Tor Bug Tracker & Wiki]

#28636: Address WTF-PAD comments by Nick (2018-11-27 over IRC)
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding|
Parent ID:  #28632   | Points:
 Reviewer:   |Sponsor:
-+-

--
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] #28654 [Core Tor/Tor]: Allow relays to serve future consensuses

[Tor Bug Tracker & Wiki]

#28654: Allow relays to serve future consensuses
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bootstrap, clock-skew, tor-guard,|  Actual Points:
  usability, ux, s8-errors, 035-roadmap- |
  subtask, 035-triaged-in-20180711,  |
  s8-bootstrap   |
Parent ID:  #28591   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 This ticket can close when #28591 closes.

--
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] #28659 [Core Tor/Tor]: Appveyor CI: error removing temporary directories - permission denied

[Tor Bug Tracker & Wiki]

#28659: Appveyor CI: error removing temporary directories - permission denied
-+-
 Reporter:  rl1987   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  appveyor ci 034-backport |  Actual Points:
  035-backport 040-backport  |
Parent ID:  #28668   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:   => #28668


--
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] #28664 [Core Tor/Tor]: Describe consensus digest calculation

[Tor Bug Tracker & Wiki]

#28664: Describe consensus digest calculation
---+
 Reporter:  atagar |  Owner:  (none)
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-spec, doc  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * status:  new => needs_revision


Comment:

 It turns out that this information is already in directory-signature at
 the end of 3.4.1:
 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2441

 So I would like to to make these changes:
 * update consensus-digest, additional-digest, and vote-digest to point to
 3.4.1, with a short note
 * update extra-info-digest to point to 2.1.2 (which points to 1.3)
 * update 1.3 to point to 3.4.1 for digests

 Alternately, we could move the info about digests from 3.4.1 to 1.3, with
 a short note in 3.4.1.
 Then we'd have to update the consensus diff format to point to 1.3 instead
 of 3.4.1:
 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n3484

 Do you think we should say "network-status-version" instead of "the
 beginning of the document"?

--
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] #28668 [Core Tor/Tor]: If a Tor unit test causes a BUG log, it should fail

[Tor Bug Tracker & Wiki]

#28668: If a Tor unit test causes a BUG log, it should fail
+
 Reporter:  teor|  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by teor):

 In that ticket, we fixed all the bug warnings, but *didn't* make tests
 fail on BUG().

 This time, we should fix all the bug warnings, and make the tests fail on
 BUG().

--
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] #28675 [Core Tor/Tor]: Deprecate standard cookie authentication (was: Tor needs torrc option to disable standard cookie authentication)

[Tor Bug Tracker & Wiki]

#28675: Deprecate standard cookie authentication
+--
 Reporter:  wagon   |  Owner:  arma
 Type:  enhancement | Status:  assigned
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by teor):

 * keywords:   => technical-debt
 * version:  Tor: 0.3.4.9 =>


Comment:

 We usually don't have options to deprecate features. Instead, we warn that
 the feature will be removed, then we remove the feature, and tell people
 to use an older release.

--
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] #25925 [Core Tor/sbws]: bwauth improvements (ex-parent ticket for SoP planned tasks)

[Tor Bug Tracker & Wiki]

#25925: bwauth improvements (ex-parent ticket for SoP planned tasks)
---+---
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  sbws: unspecified
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * milestone:   => sbws: unspecified


--
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] #7177 [Core Tor/sbws]: Understand how accurate the bandwidth authority estimates are

[Tor Bug Tracker & Wiki]

#7177: Understand how accurate the bandwidth authority estimates are
---+---
 Reporter:  karsten|  Owner:  (none)
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:  sbws: unspecified
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #25925 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * milestone:   => sbws: unspecified


--
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] #28663 [Core Tor/sbws]: sbws stops accumulating, silently

[Tor Bug Tracker & Wiki]

#28663: sbws stops accumulating, silently
---+---
 Reporter:  stefani|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28639 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * parent:   => #28639


Comment:

 This could be #28639 or a separate bug.

--
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] #28691 [Core Tor/DirAuth]: dirauth longclaw network connectivity impaired

[Tor Bug Tracker & Wiki]

#28691: dirauth longclaw network connectivity impaired
--+
 Reporter:  starlight |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #28639| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * parent:   => #28639


Comment:

 This is probably #28639 or #28663.

--
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] #23588 [Core Tor/Tor]: Write fascist_firewall_choose_address_ls() and use it in hs_get_extend_info_from_lspecs()

[Tor Bug Tracker & Wiki]

#23588: Write fascist_firewall_choose_address_ls() and use it in
hs_get_extend_info_from_lspecs()
-+-
 Reporter:  teor |  Owner:  neel
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:
  ipv6, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:  #23493   | Points:  1
 Reviewer:  teor |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 Thanks, just two more tweaks left.

 This branch will need a merge or a rebase before we merge it into master.
 I'm happy to do the merge in a new pull request, once we get the logging
 sorted.

--
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] #28691 [Core Tor/DirAuth]: dirauth longclaw network connectivity impaired

[Tor Bug Tracker & Wiki]

#28691: dirauth longclaw network connectivity impaired
--+
 Reporter:  starlight |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * cc: micah, juga (added)


Comment:

 This could be a sbws bug.

--
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] #28690 [Applications/Tor Browser]: Problems running, installing and updating Torbrowser

[Tor Bug Tracker & Wiki]

#28690: Problems running, installing and updating Torbrowser
--+--
 Reporter:  justmeee  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

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


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

Re: [tor-bugs] #23588 [Core Tor/Tor]: Write fascist_firewall_choose_address_ls() and use it in hs_get_extend_info_from_lspecs()

[Tor Bug Tracker & Wiki]

#23588: Write fascist_firewall_choose_address_ls() and use it in
hs_get_extend_info_from_lspecs()
-+-
 Reporter:  teor |  Owner:  neel
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:
  ipv6, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:  #23493   | Points:  1
 Reviewer:  teor |Sponsor:
-+-
Changes (by neel):

 * status:  needs_revision => needs_review


Comment:

 I have added the needed changes to `fascist_firewall_choose_address_ls()`.

 I have also added the new warnings to `hs_get_extend_info_from_lspecs()`
 and added a test for the missing legacy ID as the last commit. The
 unreachable IP address warning is untested for now.

 Setting as needs review.

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

Re: [tor-bugs] #27086 [Core Tor/Tor]: Write unit tests for fascist_firewall_choose_address_ls() and hs_get_extend_info_from_lspecs()

[Tor Bug Tracker & Wiki]

#27086: Write unit tests for fascist_firewall_choose_address_ls() and
hs_get_extend_info_from_lspecs()
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  duplicate
  ipv6, 034-triage-20180328, |  Actual Points:
  034-removed-20180328   |
Parent ID:  #23588   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by neel):

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


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

[tor-bugs] #28691 [Core Tor/DirAuth]: dirauth longclaw network connectivity impaired

[Tor Bug Tracker & Wiki]

#28691: dirauth longclaw network connectivity impaired
---+--
 Reporter:  starlight  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Component:  Core Tor/DirAuth
  Version: |   Severity:  Normal
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 For quite some time the longclaw dirauth has apparently been operating
 with badly degraded network connectivity resulting in degraded consensus
 votes.  Per

 https://consensus-health.torproject.org/#overlap

 {{{
Only in vote  In vote and consensus   Only in consensus
===   =   =
 longclaw 10 Authority
  3 BadExit
1 Exit857 Exit
5 Fast754 Fast!4857 Fast
21 Guard  453 Guard   !2028 Guard
4 HSDir   476 HSDir   !2952 HSDir
  6472 Running!13 Running
52 Stable 5412 Stable !26 Stable
1 V2Dir   6443 V2Dir
  7439 Valid
  117 FallbackDir
  67 Unmeasured
38 DescMismtch0 DescMismtch

 }}}

 Of particular note longclaw marks close to 5000 relays as "not fast"
 compare to the consensus where other authorities see no more than about
 100 as not fast w/r/t the overall consensus.  A close correlation exists
 between "not fast" relays in longclaw's consensus and relays omitted by
 the SBWS scanner associated with this authority.  Longclaw dirauth is not
 voting 2000 guard relay as such.

--
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] #28690 [- Select a component]: Problems running, installing and updating Torbrowser

[Tor Bug Tracker & Wiki]

#28690: Problems running, installing and updating Torbrowser
---+--
 Reporter:  justmeee   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Immediate  |  Component:  - Select a component
  Version: |   Severity:  Critical
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 Windows 7, 64-bit, Torbrowser

 I'm having problems getting it to run and install.

 See previous ticket here for history, we thought it was fixed but not
 quite: https://trac.torproject.org/projects/tor/ticket/28211#ticket

 Granted the newer version does not have that first hang up issue, so that
 part is better; however the problem now is getting it to install, run and
 update.

 You may also want to look into why Torbrowser keeps triggering virus
 alerts so others don't have that issue.  I use Trend Micro if it matters.

 So what happened is the computer restarted and removed those two items
 mentioned in the previous ticket, then TorBrowser stopped working
 completely.

 So i restored them, which also adds them to the exception list so they
 don't get flagged again, but still the browser would not work again.

 Then I reinstalled it (Note: as far as installation goes, the only version
 that does NOT give me any errors during install is that link you gave me,
 the 8.0a8 - as of today, all of the others, including the Dec 2 nightlies,
 still will Not install).

 So I reinstalled the 8.0a8 but now it will not update.  I got the
 following message:
 "There were problems checking for, downloading or installing this update.
 Tor Browser could not be updated because:
 The updated could not be installed (patch apply failed)."

 Then it tells me it will try to upload a full version, but then the update
 keeps getting stuck, first around only 290KB, so I close the update then
 start again, then it gets stuck again around 5MB, so I close the update
 window a second time and go back to help/about to get it going again.  I
 may have to do it a third/fourth time.

 The last time (the previous ticket) I did get these errors, but last time
 I just kept closing the trying again and again until it eventually
 installed, which took about 7 attempts in total.  However this time, it's
 not working at all.

 I tried turning off the virus protections and doing a fresh install.

 Even after turning off virus protection and trying a fresh install, I get
 the same errors and stalls during update attempts.  Plus even with the
 virus protection off, the other versions will not install just like
 before, only 8.0a8 will install.

 So at this time, I'm using 8.0a8 since it's the only version 8 I can use,
 unless I go back to 7.*.

 Some help please?

--
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] #28027 [Core Tor/Tor]: Tor keeps opening circuits while waiting for bridge descriptors

[Tor Bug Tracker & Wiki]

#28027: Tor keeps opening circuits while waiting for bridge descriptors
-+-
 Reporter:  dgoulet  |  Owner:  neel
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, regression, tor-guard,   |  Actual Points:
  033-backport, 034-backport, 035-backport   |
Parent ID:   | Points:
 Reviewer:  teor |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => needs_information


Comment:

 Hi,

 I just need to check that you've tested this case with the latest code:

 > The tricky part will be to confirm that tor does at some point realizes
 it can complete circuits once the bridge is usable and thus the HS
 subsystem can start building circuits.

 Replying to [comment:8 neel]:
 > Also, this patch works from bridge to non-bridge, and non-bridge to
 bridge with a onion service.

 When you've tested this case, please put the ticket into merge_ready?

--
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] #23588 [Core Tor/Tor]: Write fascist_firewall_choose_address_ls() and use it in hs_get_extend_info_from_lspecs()

[Tor Bug Tracker & Wiki]

#23588: Write fascist_firewall_choose_address_ls() and use it in
hs_get_extend_info_from_lspecs()
-+-
 Reporter:  teor |  Owner:  neel
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:
  ipv6, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:  #23493   | Points:  1
 Reviewer:  teor |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 We just need a few tweaks to the log messages: if the remote side sends
 bad data, it's a protocol warning, not a bug warning. (This was my mistake
 in my last review.)

 Maybe we should also log warnings when we don't have a legacy ID or a
 reachable IP address?
 * a missing legacy ID is a protocol warning
 * an unreachable IP address is an info-level warning (not a bug and not a
 protocol warning, because it can happen without any side doing the wrong
 thing)
 
https://github.com/torproject/tor/pull/256/commits/d838a4beab1737faff1840666ec8dce1200881d8
 #diff-b2566dcf1fb829adf3289823089d4ad4R1752

--
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] #28592 [Core Tor/Tor]: Spurious coverity memory leak error in memoize_protover_summary()

[Tor Bug Tracker & Wiki]

#28592: Spurious coverity memory leak error in memoize_protover_summary()
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  teor  |Sponsor:
--+
Changes (by nickm):

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


Comment:

 I think the assertion should be fine in this case, under the theory that
 it is about a single function doing what it is supposed to do. Merging!

--
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] #28592 [Core Tor/Tor]: Spurious coverity memory leak error in memoize_protover_summary()

[Tor Bug Tracker & Wiki]

#28592: Spurious coverity memory leak error in memoize_protover_summary()
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  teor  |Sponsor:
--+
Changes (by teor):

 * reviewer:  teor, nickm => teor


--
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] #28592 [Core Tor/Tor]: Spurious coverity memory leak error in memoize_protover_summary()

[Tor Bug Tracker & Wiki]

#28592: Spurious coverity memory leak error in memoize_protover_summary()
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  teor, nickm   |Sponsor:
--+
Changes (by teor):

 * status:  needs_review => merge_ready


Comment:

 I think nickm will review this before it gets merged.
 Is there a non-fatal alternative to the assert?

--
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] #28689 [Core Tor/Tor]: doc: cached-routers has been gone for a long time

[Tor Bug Tracker & Wiki]

#28689: doc: cached-routers has been gone for a long time
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:  doc   |  Actual Points:  0.1
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 lgtm; merged!

--
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] #28689 [Core Tor/Tor]: doc: cached-routers has been gone for a long time

[Tor Bug Tracker & Wiki]

#28689: doc: cached-routers has been gone for a long time
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  doc   |  Actual Points:  0.1
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  assigned => needs_review


Comment:

 See:
 https://github.com/torproject/tor/pull/559

--
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] #28689 [Core Tor/Tor]: doc: cached-routers has been gone for a long time

[Tor Bug Tracker & Wiki]

#28689: doc: cached-routers has been gone for a long time
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  doc
Actual Points:  0.1   |  Parent ID:
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+


--
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] #28598 [Core Tor/sbws]: Should torflow scaling use the consensus bandwidth when it is measured?

[Tor Bug Tracker & Wiki]

#28598: Should torflow scaling use the consensus bandwidth when it is measured?
--+
 Reporter:  juga  |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  sbws:
  |  1.0.x-final
Component:  Core Tor/sbws |Version:
 Severity:  Normal| Resolution:
 Keywords:  sbws-1.0-must-moved-20181128  |  Actual Points:
Parent ID:  #28588| Points:
 Reviewer:  teor  |Sponsor:
--+

Comment (by teor):

 I did some more review on the pull request.

 We can't leave the names for #28684, because:
 * #28684 might take a long time, and
 * this patch adds keys to the bandwidth file. Changing keys in the
 bandwidth file is a breaking change.

 Here's what I think:

 In sbws, "bw" means "The measured bandwidth of this relay." (for the next
 vote).
 https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-spec.txt
 So we can't use "bandwidth" like stem does.

 Here's what I suggest:
 * cons_bw: the bandwidth of this relay in the consensus
 * cons_bw_is_unmeasured: is this relay is unmeasured in the consensus?

--
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] #28684 [Core Tor/sbws]: Make sbws easy to understand and maintain

[Tor Bug Tracker & Wiki]

#28684: Make sbws easy to understand and maintain
---+---
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: unspecified
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 But no-one is parsing the bandwidth file yet, so if we want to make major
 changes, now would be a good 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] #28684 [Core Tor/sbws]: Make sbws easy to understand and maintain

[Tor Bug Tracker & Wiki]

#28684: Make sbws easy to understand and maintain
---+---
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: unspecified
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 These are some good ideas. But they might take a long time to do.

 Do you want to do them after sbws 1.1?

 If we just want to change variable names, we can do the changes in any
 version.
 If we want to change the keys in the data file, we should write code that
 reads the old keys, or do the changes in sbws 2.0.
 If we want to change the keys in the bandwidth file, we could do the
 changes in sbws 2.0 and bandwidth file format 2.0.

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

Re: [tor-bugs] #28676 [Core Tor/Tor]: Tor versions of Tor nodes should be accessible through ControlPort

[Tor Bug Tracker & Wiki]

#28676: Tor versions of Tor nodes should be accessible through ControlPort
--+--
 Reporter:  wagon |  Owner:  arma
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 There are a few bugs where Tor has access to different consensus and
 descriptor flavours, but doesn't provide all the information in them. (Or
 accesses different documents in the wrong order.)

 I'd like to build an abstraction layer over all available directory
 documents (like #25999, but inside tor). We already have the node
 abstraction, but it duplicates some data, and modifies other data. So it
 isn't quite what we want.

 We could use the new abstraction internally within tor, whenever we access
 data from a parsed directory document. And we could also use it to
 implement a new control port command, or fix the existing control port
 commands.

--
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] #28687 [Internal Services/Service - lists]: Grant Erin list maintainer access

[Tor Bug Tracker & Wiki]

#28687: Grant Erin list maintainer access
---+
 Reporter:  atagar |  Owner:  qbi
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by qbi):

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


Comment:

 I sent Erin an email with the passwords.

--
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] #28686 [Internal Services/Service - lists]: Please create a tor-employees@ list

[Tor Bug Tracker & Wiki]

#28686: Please create a tor-employees@ list
---+-
 Reporter:  atagar |  Owner:  qbi
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by atagar):

 
[https://trac.torproject.org/projects/tor/wiki/doc/emailLists?action=diff=145
 Added]. Erin. please be aware that email lists default to being open (ie,
 anyone can subscribe). If you'd like I'd be happy to configure this list
 to match tor-internal@ (minus its membership). That's probably closer to
 the initial configuration you intend.

 If you'd like to go that route let me know, and once the settings match
 all you would need to do is fill in the membership you want it to have.

--
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] #28686 [Internal Services/Service - lists]: Please create a tor-employees@ list

[Tor Bug Tracker & Wiki]

#28686: Please create a tor-employees@ list
---+-
 Reporter:  atagar |  Owner:  qbi
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by atagar):

 Thanks Jens! This is an administrative list (like tor-board@). I'll add it
 to the wiki.

 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] #28686 [Internal Services/Service - lists]: Please create a tor-employees@ list

[Tor Bug Tracker & Wiki]

#28686: Please create a tor-employees@ list
---+-
 Reporter:  atagar |  Owner:  qbi
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by qbi):

 * cc: ewyatt (added)


Comment:

 I created the list, see https://lists.torproject.org/cgi-
 bin/mailman/listinfo/tor-employees
 Currently it has pretty much default settings. So Erin please either set
 some custom values or specify what you like and I'll do it for you.

 However I'm unsure where to make the entry at
 https://trac.torproject.org/projects/tor/wiki/doc/emailLists
 Could one of you please clarify what kind of list it will be?
 Announcement, discussion, etc.?

--
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] #28687 [Internal Services/Service - lists]: Grant Erin list maintainer access

[Tor Bug Tracker & Wiki]

#28687: Grant Erin list maintainer access
---+-
 Reporter:  atagar |  Owner:  qbi
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by atagar):

 Ah ha! Thanks Roger. Added ewy...@torproject.org to the administrator and
 moderator addresses for tor-project@, tor-team@, and tor-internal@. As for
 giving her the individual list passwords unfortunately I'm forgetting
 where those are (iirc weasel had them in an unlisted git repo, but I've
 forgotten its uri since I always use the listowner credential). Do you
 recall where those are?

--
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] #28687 [Internal Services/Service - lists]: Grant Erin list maintainer access

[Tor Bug Tracker & Wiki]

#28687: Grant Erin list maintainer access
---+-
 Reporter:  atagar |  Owner:  qbi
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by arma):

 (i guess technically you only need to do (b))

--
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] #28687 [Internal Services/Service - lists]: Grant Erin list maintainer access

[Tor Bug Tracker & Wiki]

#28687: Grant Erin list maintainer access
---+-
 Reporter:  atagar |  Owner:  qbi
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by arma):

 Atagar: I think you might be able to do this yourself, by (a) adding Erin
 to the "The list administrator email addresses" set on e.g.
 https://lists.torproject.org/cgi-bin/mailman/admin/tor-project and then
 (b) telling Erin the admin password for the list.

--
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] #28687 [Internal Services/Service - lists]: Grant Erin list maintainer access

[Tor Bug Tracker & Wiki]

#28687: Grant Erin list maintainer access
---+-
 Reporter:  atagar |  Owner:  qbi
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by qbi):

 Could you please clarify what you mean by "maintainer"?
 thx

--
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] #28688 [Core Tor/Torsocks]: torsocks: Unsupported syscall errors in version 2.3.0

[Tor Bug Tracker & Wiki]

#28688: torsocks: Unsupported syscall errors in version 2.3.0
---+--
 Reporter:  yurivict271|  Owner:  dgoulet
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Torsocks  |Version:  Tor: 0.3.4.9
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by yurivict271):

 See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233736

--
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] #28688 [Core Tor/Torsocks]: torsocks: Unsupported syscall errors in version 2.3.0

[Tor Bug Tracker & Wiki]

#28688: torsocks: Unsupported syscall errors in version 2.3.0
--+---
 Reporter:  yurivict271   |  Owner:  dgoulet
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  Core Tor/Torsocks
  Version:  Tor: 0.3.4.9  |   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
 Copied from the downstream bug report:
 {{{
 After upgrading to torsocks-2.3.0, I get an error when using torify:

 $ torify git clone https://github.com/freebsd/poudriere.git
 1543787510 WARNING torsocks[25796]: [syscall] Unsupported syscall number
 20. Denying the call (in tsocks_syscall() at syscall.c:568)
 Cloning into 'poudriere'...
 1543787510 WARNING torsocks[25796]: [syscall] Unsupported syscall number
 2. Denying the call (in tsocks_syscall() at syscall.c:568)
 error: cannot fork() for git-remote-https: Function not implemented

 The same command works with torsocks 2.2.0.

 syscall number 2 is fork. There have been some changes to syscall.c which
 may cause this issue.
 }}}

--
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] #28687 [Internal Services/Service - lists]: Grant Erin list maintainer access

[Tor Bug Tracker & Wiki]

#28687: Grant Erin list maintainer access
---+-
 Reporter:  atagar |  Owner:  qbi
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 Hi Jens, as Tor's HR director lets grant Erin maintainer access for tor-
 project@, tor-team@, and tor-internal@.

 I will remain the primary maintainer of these lists, and hopefully she'll
 keep me in the loop when she makes changes. But there's no need for me to
 actively stand in the way. As tor's HR director Erin should have access.

 Erin, I'd prefer if you continue to go to me for
 subscription/unsubscription requests so I can keep our lists consistently
 configured, but if there's emergent changes you need made then feel free
 to inform me what ya tweaked after the fact.

 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

[tor-bugs] #28686 [Internal Services/Service - lists]: Please create a tor-employees@ list

[Tor Bug Tracker & Wiki]

#28686: Please create a tor-employees@ list
---+-
 Reporter:  atagar |  Owner:  qbi
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 Hi Jens, just a quick request for a new email list that would make Erin's
 life easier..

 > What is the list name?

 tor-employ...@lists.torproject.org

 > What is the email address of the list maintainer?

 ewy...@torproject.org

 > What is a one sentence description of the list?

 Tor employees.

 

 In the past I was the chief critic of such a list but I was wrong. Lacking
 this list creates extra work for poor Erin, and the prospective concerns I
 had about community cohesion are things we can address if they arise. It's
 silly of me to make Erin's life harder on a hypothetical.

 Erin will administer the list, and use it to provide HR notifications.

 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] #28685 [Applications/Tor Browser]: Tor Browser for Android needs a more dynamic Build ID

[Tor Bug Tracker & Wiki]

#28685: Tor Browser for Android needs a more dynamic Build ID
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, |  Actual Points:
  TorBrowserTeam201812   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * cc: boklm (added)
 * keywords:  tbb-mobile => tbb-mobile, tbb-rbm, TorBrowserTeam201812
 * component:  Applications/rbm => Applications/Tor Browser
 * owner:  boklm => tbb-team
 * priority:  Medium => High


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

Re: [tor-bugs] #28508 [Core Tor/Stem]: Stem not checking for 'cached-microdescs.new' correctly

[Tor Bug Tracker & Wiki]

#28508: Stem not checking for 'cached-microdescs.new' correctly
---+
 Reporter:  opara  |  Owner:  atagar
 Type:  defect | Status:  closed
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by opara):

 Thanks! Works great now.

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

[tor-bugs] #28685 [Applications/rbm]: Tor Browser for Android needs a more dynamic Build ID

[Tor Bug Tracker & Wiki]

#28685: Tor Browser for Android needs a more dynamic Build ID
--+
 Reporter:  sysrqb|  Owner:  boklm
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/rbm  |Version:
 Severity:  Normal|   Keywords:  tbb-mobile
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Currently, the build id only changes when the Firefox version changes and
 when the copyright year changes. Unfortunately, when building the APK,
 Mozilla expect the build id changes between every build. They use the
 build id and derive the Android version code (version number) from this.
 Unfortunately, they only use part of the buildid and they discard lower
 bits. This doesn't fit well with the current `get-moz-build-date` script
 because:
   1) if the firefox build date and copyright year remain the same, then
 the build id remains the same
   2) if the patch version increases (such as 60.3.0 to 60.3.1), then the
 Android version code doesn't change (due to discarded lower bits)

 I think we can solve 1. by incorporating the tor browser version number
 into the calculation. Solving 2. may require multiplying by at least 3600
 (therefore offsets the division by 60*60), i think.
 https://gitweb.torproject.org/tor-
 browser.git/tree/python/mozbuild/mozbuild/android_version_code.py?h=tor-
 browser-60.3.0esr-8.5-1#n33

 {{{
 $ perl get-moz-build-date 2018 60.3.0
 export MOZ_BUILD_DATE=20180204040101

 $ python python/mozbuild/mozbuild/android_version_code.py --verbose
 --with-android-cpu-arch armeabi-v7a --with-android-min-sdk-version 16
 --with-android-max-sdk-version 26 20180204040101
 2015539361


 $ perl get-moz-build-date 2018 60.3.1
 export MOZ_BUILD_DATE=20180204040201

 $ python python/mozbuild/mozbuild/android_version_code.py --verbose
 --with-android-cpu-arch armeabi-v7a --with-android-min-sdk-version 16
 --with-android-max-sdk-version 26 20180204040201
 2015539361


 $ perl get-moz-build-date 2018 60.4.0
 export MOZ_BUILD_DATE=20180204050101

 $ python python/mozbuild/mozbuild/android_version_code.py --verbose
 --with-android-cpu-arch armeabi-v7a --with-android-min-sdk-version 16
 --with-android-max-sdk-version 26 20180204050101
 2015539369
 }}}

 Notice the android version code is the same for `60.3.0` and `60.3.1`.

 Currently, the script with the current Tor Browser Build ID is:
 {{{
 import math
 import time

 fmt = '%Y%m%d%H%M%S'
 buildid = "20180204040101"
 V1_CUTOFF = 2015080100

 build = time.strptime(str(buildid), fmt)
 cutoff = time.strptime(str(V1_CUTOFF), fmt)

 base = int(math.floor((time.mktime(build) - time.mktime(cutoff)) / (60.0 *
 60.0)))
 version = 0b010
 version |= base << 3
 version |= 1 << 0
 print(version)
 }}}

 Something else I noticed is this current scheme only provides 8 android
 version codes between 60.3.0 (2015539361) and 60.4.0 (2015539369). We
 probably want more than that - but this may be accomplished when adjusting
 the other bits.

--
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] #28417 [Community/Translations]: Translate glossary / browser manual translates 'Circuit' inconsistently

[Tor Bug Tracker & Wiki]

#28417: Translate glossary / browser manual translates 'Circuit' inconsistently
+--
 Reporter:  traumschule |  Owner:  traumschule
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Community/Translations  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by traumschule):

 * status:  assigned => needs_review


Comment:

 Leaning towards "Kanal" and propose this fix before closing:
 https://github.com/traumschule/tor-translation/compare/tbmanual-
 contentspot

 Had to create a commit because Transifex didn't accept changes, or is
 there another resource for the manual?
 https://www.transifex.com/otf/torproject/tor-misc-tor-browser-manualpot/
 > This resource currently is not accepting translations.

--
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] #23922 [Community/Tor Browser Manual]: The Uninstalling page does not mention the TorBrowser-Data directory on OSX

[Tor Bug Tracker & Wiki]

#23922: The Uninstalling page does not mention the TorBrowser-Data directory on 
OSX
--+--
 Reporter:  boklm |  Owner:  traumschule
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Community/Tor Browser Manual  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #24231| Points:
 Reviewer:|Sponsor:
--+--
Changes (by traumschule):

 * status:  assigned => needs_review


Comment:

 https://github.com/torproject/manual/pull/9

--
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] #28684 [Core Tor/sbws]: Make sbws easy to understand and maintain

[Tor Bug Tracker & Wiki]

#28684: Make sbws easy to understand and maintain
---+---
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: unspecified
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by juga):

 Pad with some ideas: https://pad.riseup.net/p/rGfvR7ZsvtoZ

--
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] #28684 [Core Tor/sbws]: Make sbws easy to understand and maintain

[Tor Bug Tracker & Wiki]

#28684: Make sbws easy to understand and maintain
---+---
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: unspecified
Component:  Core Tor/sbws  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+---
 There was not an initial design and we are still adding functionality.
 Some of the new functionality require modifying several parts of the code
 and it's becoming harder to maintain and understand.
 This ticket is to identify the changes needed (refactors, etc.).

--
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] #28683 [Internal Services/Tor Sysadmin Team]: Please update ip for op-us.onionperf.tp.o

[Tor Bug Tracker & Wiki]

#28683: Please update ip for op-us.onionperf.tp.o
-+-
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Greenhost has migrated US VPSs, so op-us has a new ip: 37.218.241.144
 Please update op-us.onionperf.tp.o.
 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] #27620 [Core Tor/Tor]: Use trunnel to parse and generate SOCKS wire format in tor-resolve

[Tor Bug Tracker & Wiki]

#27620: Use trunnel to parse and generate SOCKS wire format in tor-resolve
-+-
 Reporter:  rl1987   |  Owner:  rl1987
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  trunnel wireformat socks tor-|  Actual Points:
  resolve security   |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-

Comment (by nickm):

 Replying to [comment:12 nickm]:
 > Made a squashed & rebased version as
 https://github.com/torproject/tor/pull/556 .
 >
 > So far the only suggestions I have are:
 >
 >   * We should be using strlcpy, not strncpy.

 Though actually, tor_strdup() would be fine here, since the trunnel
 "getstr" functions return nul-terminated strings.

 >   * If we allow socks4_server_reply_version to be zero, then we'll need
 to explicitly set it to 4 in proto_socks.c so that we're sending the right
 value from Tor, right?

 Oh. apparently we don't do that.  That's okay.

 >   * Do we have a ticket for adding tests for tor-resolve?

 Yes, #27854, a child of this ticket.

 > I'll make all the above changes before merging, if the CI passes.

 Done, merged.

--
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] #27620 [Core Tor/Tor]: Use trunnel to parse and generate SOCKS wire format in tor-resolve

[Tor Bug Tracker & Wiki]

#27620: Use trunnel to parse and generate SOCKS wire format in tor-resolve
-+-
 Reporter:  rl1987   |  Owner:  rl1987
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  trunnel wireformat socks tor-|  implemented
  resolve security   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by nickm):

 * status:  merge_ready => 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] #27854 [Core Tor/Tor]: Integration test(s) for tor-resolve

[Tor Bug Tracker & Wiki]

#27854: Integration test(s) for tor-resolve
---+---
 Reporter:  rl1987 |  Owner:  rl1987
 Type:  enhancement| Status:  accepted
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.0.x-final
Component:  Core Tor/Tor   |Version:  Tor: unspecified
 Severity:  Normal | Resolution:
 Keywords:  socks tor-resolve testing  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * parent:  #27620 =>


Comment:

 Unparenting.

--
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] #28624 [Core Tor/Tor]: Should we remember dormant state on restart?

[Tor Bug Tracker & Wiki]

#28624: Should we remember dormant state on restart?
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Replying to [comment:4 arma]:
 > So would that mean that by default, Tor never remembers its dormant
 state across restarts? (Or more precisely, never reacts to dormancy info
 in the state file on startup.)
 >
 > That would seem to not cover the "some linux distro includes a Tor
 client package by default" use case, right? It's more oriented towards
 specific Tor installs that know they want to be special?

 Right.  We could change the default later on, but I thought that for now,
 we're better off making this an off-by-default feature.

 On IRC, you said:

 > i am a bit suspicious also of the 'auto' choice being 'yes if my state
 file is from yesterday
 > because we do have a new bit of info from yesterday, and that new bit is
 "i just started tor"
 > and often, when i start tor, it's because now i plan to use it

 To clarify, the "auto" choice is "be active if I was active when I shut
 down, ''and'' I shut down recently".  Or if you prefer "be dormant if the
 state file was old, or if I was dormant in the old state file."

 I'm also concerned about whether this is the best approach, but I think
 that other choices won't work for the use cases we have.  If every startup
 makes tor active, then we won't actually have time to go dormant.

 I guess another possibility might be to remember the total number of hours
 Tor has been running without user activity, and let that build up
 cumulatively over invocations.  In this case, "auto" might mean simply
 "remember if we were active", and we might additionally track in our state
 file the cumulative number of minutes that Tor has run without seeing user
 activity.

--
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] #28682 [- Select a component]: Carml lacks PGP singatures and instructions for secure installation

[Tor Bug Tracker & Wiki]

#28682: Carml lacks PGP singatures and instructions for secure installation
--+--
 Reporter:  wagon |  Owner:  meejah
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:  carml |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * cc: meejah (added)
 * component:  Core Tor => - Select a component


Comment:

 Is there a better place for this, meejah?

--
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] #28229 [Core Tor/Tor]: Possible race condition opening SOCKS Port in test_rebind.py

[Tor Bug Tracker & Wiki]

#28229: Possible race condition opening SOCKS Port in test_rebind.py
-+
 Reporter:  teor |  Owner:  rl1987
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.5.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, 035-can  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  teor |Sponsor:
-+

Comment (by nickm):

 I think this build log might have an example of the failure: https
 ://travis-ci.org/torproject/tor/jobs/462336253

--
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] #28681 [Metrics/Relay Search]: reflected XSS metrics.torproject.org

[Tor Bug Tracker & Wiki]

#28681: reflected XSS metrics.torproject.org
---+--
 Reporter:  0x539h |  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Metrics/Relay Search   |Version:
 Severity:  Major  | Resolution:
 Keywords:  xss, cross-site scripting  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by arma):

 * owner:  (none) => metrics-team
 * version:  sbws: unspecified =>
 * component:  - Select a component => Metrics/Relay Search
 * sponsor:  Sponsor2 =>


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