Re: [tor-bugs] #18329 [Core Tor/Tor]: Let bridges indicate when they don't want BridgeDB to distribute their address

[Tor Bug Tracker & Wiki]

#18329: Let bridges indicate when they don't want BridgeDB to distribute their
address
--+
 Reporter:  karsten   |  Owner:
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bridge, stem  |  Actual Points:
Parent ID:| Points:  .2 remaining
 Reviewer:  nickm |Sponsor:
--+

Comment (by isis):

 Replying to [comment:34 atagar]:
 > Thanks Isis, looks good to me.

 Okay, thanks for reviewing! The torspec patch is in my `ticket18329_02`
 [https://gitweb.torproject.org/user/isis/torspec.git/commit/?h=ticket18329_02
 branch] (based on David's branch from above).

 So the next step is to go over Roger's patch again and see what needs
 tweaking.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by mikeperry):

 nickm: based on behavior, #17592 and #17604 are bugfixes on 0.2.5.5-alpha.
 that is the last time we changed that behavior (for #6799)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21654 [Core Tor/Tor]: Don't use fgets() when we might get EAGAIN

[Tor Bug Tracker & Wiki]

#21654: Don't use fgets() when we might get EAGAIN
---+
 Reporter:  nickm  |  Owner:  ahf
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  TorCoreTeam201703  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by ahf):

 A test was added for the `EAGAIN` behaviour with `fgets()` on non-blocking
 I/O in commit `8ee559bd` on Fri Oct 8 21:31:15 2010.

 It seems the behaviour was mentioned during the code review by Nick in bug
 #1903 and also mentioned in #2045, so this have been an issue on and off
 since at least tor-0.2.3.1-alpha.

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

Re: [tor-bugs] #21585 [Core Tor/Tor]: Check code that uses consensus membership to find clients

[Tor Bug Tracker & Wiki]

#21585: Check code that uses consensus membership to find clients
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  triaged-out-20170308  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+--

Comment (by mikeperry):

 #16861 added such a consensus check to update the is_client flag, btw.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #7869 [Core Tor/Tor]: ntor-onion-key is padded with an equal sign

[Tor Bug Tracker & Wiki]

#7869: ntor-onion-key is padded with an equal sign
-+-
 Reporter:  rransom  |  Owner:
 |  Jigsaw52
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, easy, intro,  |  Actual Points:
  tor-03-unspecified-201612  |
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+-
Changes (by catalyst):

 * status:  needs_review => needs_revision
 * reviewer:   => catalyst
 * cc: catalyst (added)
 * milestone:  Tor: unspecified => Tor: 0.3.2.x-final


Comment:

 [responding to a ping on IRC]

 Thanks for the patch!  0.3.1.x is in feature freeze so I'm putting this in
 0.3.2.x for now.  (Though it might make it into 0.3.1.x if there is time?
 It doesn't seem urgent to get into 0.3.1.x but feel free to explain if you
 disagree.)  #21872 means we have nicer macros for statically computing
 buffer lengths for various encodings, so I think it would be good to use
 them for this patch.  Also I think `base64_encode()` appends a NUL
 terminator so we can probably delete the code that separately adds one.

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

Re: [tor-bugs] #22262 [Applications/Tor Browser Sandbox]: Tor Browser Sandbox should offer the possibility to download the Tor Browser from mirrors

[Tor Bug Tracker & Wiki]

#22262: Tor Browser Sandbox should offer the possibility to download the Tor
Browser from mirrors
--+-
 Reporter:  blockflare|  Owner:  yawning
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #20792| Points:
 Reviewer:|Sponsor:
--+-
Changes (by yawning):

 * parent:   => #20792


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22266 [Core Tor/Tor]: fix the jump-to-80% issue

[Tor Bug Tracker & Wiki]

#22266: fix the jump-to-80% issue
---+
 Reporter:  catalyst   |  Owner:
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  usability, ux  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by dcf):

 Replying to [ticket:22266 catalyst]:
 > If enough existing directory information is available, the bootstrap
 progress as reported to the logs and the control connection jumps from 0%
 to 80% almost immediately.  This is misleading and causes user
 frustration, as reported by Linda's study.

 I was one of the people who helped with the study. As I understand it, the
 problem has more to do with Tor Launcher than with tor. I don't think the
 problem has to do with cached directory information. Rather, it is that
 Tor Launcher resets the state of the progress bar to 0% every time the
 progress screen is displayed, even though the tor process's (hidden)
 percentage is greater than 0%.

 Imagine you start bootstrapping and watch the progress bar get to 60%,
 then you get impatient and hit Cancel. (tor is in fact still bootstrapping
 in the background even though the GUI doesn't reflect that.) You fiddle
 with the configuration and try to bootstrap again. At this point, the
 progress bar misleadingly shows 0%, even though the tor process is still
 at 60%. Now, as soon as tor makes a little more progress (say to 65%), the
 progress bar will immediately update itself to the new value, giving the
 effect of a jump from 0% to 65% when it should have been from 60% to 65%.
 What users found misleading was the progress bar going back to 0% after
 they changed the configuration; even though in reality the percentage
 hadn't changed or had even increased, they assumed that their
 configuration changes had caused bootstrapping to make negative progress.

 I thought that the solution would be to have Tor Launcher either cache its
 last seen progress percentage, so it can reinitialize the progress bar
 properly, or else have some background listener that tracks the percentage
 status even when the progress bar is not actually on screen.

 I might be misinterpreting the ticket description.

 > When bootstrapping with existing directory information, we should
 rescale the progress numbers so they advance on something resembling a
 linear time scale, which is probably closer to what users expect to see.

 Does that mean that if bootstrapping got to 60%, was cancelled, and then
 restarted, that the progress bar would visually reset back to 0%, but that
 the remaining 40% would be stretched to fit a 0–100 scale? E.g. 60%→0%,
 70%→25%, 80%→50%, 90%→75%, 100%→100%?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18329 [Core Tor/Tor]: Let bridges indicate when they don't want BridgeDB to distribute their address

[Tor Bug Tracker & Wiki]

#18329: Let bridges indicate when they don't want BridgeDB to distribute their
address
--+
 Reporter:  karsten   |  Owner:
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bridge, stem  |  Actual Points:
Parent ID:| Points:  .2 remaining
 Reviewer:  nickm |Sponsor:
--+

Comment (by atagar):

 Thanks Isis, looks good to me.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22253 [Core Tor/Tor]: Resolve TROVE-2017-002

[Tor Bug Tracker & Wiki]

#22253: Resolve TROVE-2017-002
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Major | Resolution:  fixed
 Keywords:|  Actual Points:  .2
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 See ticket #22246 for actual details.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22246 [Core Tor/Tor]: ASSERT failure on v0.3.0.6

[Tor Bug Tracker & Wiki]

#22246: ASSERT failure on v0.3.0.6
+
 Reporter:  tmpname0901 |  Owner:
 Type:  defect  | Status:  closed
 Priority:  High|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.0.6
 Severity:  Major   | Resolution:  fixed
 Keywords:  tor-hs prop224  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:  SponsorR-can
+
Changes (by nickm):

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


Comment:

 This was caused by failure to initialize the hidden service descriptor
 cache.  Because the assert was remotely reachable, we worked on the fix
 offline. The fix is now available in tor 0.3.0.7, and in the branch
 bug22246_030 in my public repository.

 This issue is TROVE-2017-002

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22253 [Core Tor/Tor]: Resolve TROVE-2017-002

[Tor Bug Tracker & Wiki]

#22253: Resolve TROVE-2017-002
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Major | Resolution:  fixed
 Keywords:|  Actual Points:  .2
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  accepted => closed
 * resolution:   => fixed
 * actualpoints:   => .2


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

Re: [tor-bugs] #18329 [Core Tor/Tor]: Let bridges indicate when they don't want BridgeDB to distribute their address

[Tor Bug Tracker & Wiki]

#18329: Let bridges indicate when they don't want BridgeDB to distribute their
address
--+
 Reporter:  karsten   |  Owner:
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bridge, stem  |  Actual Points:
Parent ID:| Points:  .2 remaining
 Reviewer:  nickm |Sponsor:
--+

Comment (by isis):

 Replying to [comment:30 atagar]:
 > > Damian, does that look okay from Stem's point of view? (Also, does
 this text make enough sense to the type of bridge operator who wants to
 micromanage their bridge?)
 >
 > Hi Isis, looks good except that we should specify what characters future
 methods can consist of. For instance, can future method names have spaces
 in it?

 Ah, good point. I'll specify printable ascii, no whitespace, plus `-` and
 `_`. So `(KeywordChar | _)+` (and we'll optionally lowercase the letters
 input from the torrc).  Does that sound okay?

 > > Each "method" describes how...
 >
 > Use of the word 'each' here confuses me since the field can only appear
 once, and according to this can have only one value on this line.

 You're right, that should be taken out. (I first started writing something
 where the user could specify multiple comma-separated methods, e.g.
 `email,https` would choose email or https, but the logic for this is
 complicated and confusing, so I revised to allow just one "method".)

 Here's the new draft:

 {{{
 "bridge-distribution-request" SP Method NL

 [At most once]

 The "Method" describes how a Bridge address is distributed by
 BridgeDB. Recognized methods are: "none", "any", "https", "email",
 "moat", "hyphae". If set to "none", BridgeDB will avoid
 distributing
 your bridge address. If set to "any", BridgeDB will choose how to
 distribute your bridge address. Choosing any of the other methods
 will
 tell BridgeDB to distribute your bridge via a specific method:

   - "https" specifies distribution via the web interface at
  https://bridges.torproject.org;
   - "email" specifies distribution via the email autoresponder at
 brid...@torproject.org;
   - "moat" specifies distribution via an interactive menu inside
 Tor
 Browser; and
   - "hyphae" specifies distribution via a cryptographically-
 secure,
 invitation-based system.

 Potential future "Method" specifiers must be as follows:
 Method = (KeywordChar | "_") +

 (Default: "any")
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18329 [Core Tor/Tor]: Let bridges indicate when they don't want BridgeDB to distribute their address

[Tor Bug Tracker & Wiki]

#18329: Let bridges indicate when they don't want BridgeDB to distribute their
address
--+
 Reporter:  karsten   |  Owner:
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bridge, stem  |  Actual Points:
Parent ID:| Points:  .2 remaining
 Reviewer:  nickm |Sponsor:
--+
Changes (by dcf):

 * cc: catalyst (removed)


Comment:

 Replying to [comment:5 arma]:
 > My {{{feature18329}}} branch implements this feature.
 >
 > There's a new BridgeDistribution torrc option, and it passes along its
 argument into the new bridge-distribution-request line in the bridge
 descriptor.

 
https://gitweb.torproject.org/arma/tor.git/commit/?h=feature18329=da46e73142bd522f8ac7dfc9d1f113c6281aea85

 Do we care about potentially having different distribution settings for
 the potentially multiple transports that may be defined in torrc? If
 someone has both `ServerTransportPlugin obfs3` and `ServerTransportPlugin
 obfs4`, say, there would be no way to give them different
 `BridgeDistribution` settings.

 Currently some torrc options are keyed on transport name (e.g.
 [https://www.torproject.org/docs/tor-manual.html.en#ServerTransportPlugin
 ServerTransportPlugin], [https://www.torproject.org/docs/tor-
 manual.html.en#ServerTransportListenAddr ServerTransportListenAddr],
 [https://www.torproject.org/docs/tor-manual.html.en#ServerTransportOptions
 ServerTransportOptions]). Ought `BridgeDistribution` to be like that too,
 or is it too niche a use case?

 By transport name would be the finest possible granularity. It would be
 cool if you could run multiple instances of obfs4 with different
 `BridgeDistribution` options, but you can't actually express multiple
 instances of the same transport name in torrc (see #11211). So if someone
 wanted to do that, they would have to run multiple instances of tor with
 multiple fingerprints anyway.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18329 [Core Tor/Tor]: Let bridges indicate when they don't want BridgeDB to distribute their address

[Tor Bug Tracker & Wiki]

#18329: Let bridges indicate when they don't want BridgeDB to distribute their
address
--+
 Reporter:  karsten   |  Owner:
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bridge, stem  |  Actual Points:
Parent ID:| Points:  .2 remaining
 Reviewer:  nickm |Sponsor:
--+
Changes (by isis):

 * cc: catalyst (added)


Comment:

 (Oops, I accidentally removed catalyst! Sorry!)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18329 [Core Tor/Tor]: Let bridges indicate when they don't want BridgeDB to distribute their address

[Tor Bug Tracker & Wiki]

#18329: Let bridges indicate when they don't want BridgeDB to distribute their
address
--+
 Reporter:  karsten   |  Owner:
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bridge, stem  |  Actual Points:
Parent ID:| Points:  .2 remaining
 Reviewer:  nickm |Sponsor:
--+

Comment (by atagar):

 > Damian, does that look okay from Stem's point of view? (Also, does this
 text make enough sense to the type of bridge operator who wants to
 micromanage their bridge?)

 Hi Isis, looks good except that we should specify what characters future
 methods can consist of. For instance, can future method names have spaces
 in it?

 > Each "method" describes how...

 Use of the word 'each' here confuses me since the field can only appear
 once, and according to this can have only one value on this line.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #1922 [Core Tor/Tor]: torrc.d-style configuration directories

[Tor Bug Tracker & Wiki]

#1922: torrc.d-style configuration directories
-+-
 Reporter:  aa138346 |  Owner:
 |  Jigsaw52
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, intro,   |  Actual Points:
  tor-03-unspecified-201612  |
Parent ID:   | Points:  medium
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Pulling this back for consideration in 0.3.1, since the feature window
 isn't _quite_ closed yet. :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22149 [Core Tor/Tor]: prop140: Update dir-spec with prop140 protocols

[Tor Bug Tracker & Wiki]

#22149: prop140: Update dir-spec with prop140 protocols
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords:  TorCoreTeam201705  |  Actual Points:  .3
Parent ID:  #13339 | Points:  .3
 Reviewer: |Sponsor:  Sponsor4
---+
Changes (by nickm):

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


Comment:

 squashed and 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] #22148 [Core Tor/Tor]: prop140: conformance to proposal, unhandled corner cases

[Tor Bug Tracker & Wiki]

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

 * status:  merge_ready => closed
 * resolution:   => implemented
 * actualpoints:  .5 => .7


Comment:

 prop140_aftermath_url_v3 created, reviewed, merged, and fixed. :)

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

Re: [tor-bugs] #18329 [Core Tor/Tor]: Let bridges indicate when they don't want BridgeDB to distribute their address

[Tor Bug Tracker & Wiki]

#18329: Let bridges indicate when they don't want BridgeDB to distribute their
address
--+
 Reporter:  karsten   |  Owner:
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bridge, stem  |  Actual Points:
Parent ID:| Points:  .2 remaining
 Reviewer:  nickm |Sponsor:
--+
Changes (by isis):

 * cc: catalyst (removed)


Comment:

 Replying to [comment:21 arma]:
 > […]
 >
 > I don't think it would solve much to use numbers, and I think it would
 indeed hurt the usability.

 That's fair; you've got me convinced that the numbers thing would be bad
 usability-wise.

 However, I'm still against "any bytes, any length, yolo."

 > The BridgeDB behavior can be very simple: if the field is there and
 bridgedb recognizes the value in the field, do the right thing with it,
 else if the field is there and bridgedb doesn't recognize it, don't
 distribute that bridge.

 Why would we waste bandwidth passing around descriptors with junk in them?
 Why not just filter the junk during descriptor creation?

 > Nick, what did you mean by "with Tor restricted to only accept
 recognized names if they appear in torrc"? You're hoping that we teach Tor
 more about the possible values of the field, and that it says something
 like "nope, never heard of that one, you can't set it" for ones it doesn't
 know about? Does that mean that people running Tor on (say) version
 0.3.1.x will need to upgrade in order to list a name that we started using
 while (say) Tor 0.3.2.x was current? Why would we do that?

 Not to speak for Nick, but I think he meant just as you described: tor
 will say, "If you try to set a value which isn't in the list of things I
 recognise, I'm going to not include it in your descriptor."

 To make this simpler moving forward, the whitelist should currently
 include the following recognised values: `none`, `any`, `https`, `email`,
 `moat`, and `hyphae`. The default is `any`.

 This covers all current distributors, and the two which are planned for
 this year.  (`moat` is the new distributor which sends Tor Launcher a
 CAPTCHA via a meek channel, and essentially acts exactly like the `https`
 distributor, but in XUL rather than HTML, in Tor Launcher. `hyphae` is the
 social distributor mentioned in #7520 and
 [https://patternsinthevoid.net/hyphae detailed here].) If we need to add a
 new distributor in the future — which I don't expect — you're correct that
 we'll need to get it added to tor's distributor whitelist. This is
 solvable by opening a ticket to get the new name added to the list, before
 starting work to build the distributor; this way, the name is likely
 recognised by the time the distributor is deployed.

 > I agree with Damian that we could be a bit clearer on the torspec side.
 I think what dgoulet was going for was the same spec as the Contact field
 has. From Tor's perspective, it is essentially an "anything goes" string.
 We could change it to say "set of 'key and optional value' fields" or
 something if we liked, but I think the only effect of trying to constrain
 it here will be producing bugs in stem later if we decide to change it.
 Damian, what would you like to see the spec for the Contact field look
 like? Then we can use that here too.

 Here's draft text describing the torrc option:

 {{{
 "bridge-distribution-request" SP method NL

[At most once]

Each "method" describes how a Bridge address is distributed by
 BridgeDB.
Recognized methods are: "none", "any", "https", "email", "moat",
 "hyphae".
If set to "none", BridgeDB will avoid distributing your bridge address.
If set to "any", BridgeDB will choose how to distribute your bridge
address. Choosing any of the other methods will tell BridgeDB to
 distribute
your bridge via a specific method:

   * "https" specifies distribution via the web interface at
  https://bridges.torproject.org;
   * "email" specifies distribution via the email autoresponder at
 brid...@torproject.org;
   * "moat" specifies distribution via an interactive menu inside Tor
 Browser; and
   * "hyphae" specifies distribution via a cryptographically-secure,
 invitation-based system.

(Default: "any")
 }}}

 Damian, does that look okay from Stem's point of view? (Also, does this
 text make enough sense to the type of bridge operator who wants to
 micromanage their bridge?)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list

Re: [tor-bugs] #18329 [Core Tor/Tor]: Let bridges indicate when they don't want BridgeDB to distribute their address

[Tor Bug Tracker & Wiki]

#18329: Let bridges indicate when they don't want BridgeDB to distribute their
address
--+
 Reporter:  karsten   |  Owner:
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bridge, stem  |  Actual Points:
Parent ID:| Points:  .2 remaining
 Reviewer:  nickm |Sponsor:
--+
Changes (by catalyst):

 * cc: catalyst (added)


Comment:

 The character set stuff should probably move to #18938?

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by nickm):

 `prop140_aftermath_cfg` merged cleanly and pushed.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18329 [Core Tor/Tor]: Let bridges indicate when they don't want BridgeDB to distribute their address

[Tor Bug Tracker & Wiki]

#18329: Let bridges indicate when they don't want BridgeDB to distribute their
address
--+
 Reporter:  karsten   |  Owner:
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bridge, stem  |  Actual Points:
Parent ID:| Points:  .2 remaining
 Reviewer:  nickm |Sponsor:
--+

Comment (by isis):

 Replying to [comment:25 Sebastian]:
 > I'm strongly considering a proposal where any document we produce must
 be valid utf-8. This has a pretty small fallout currently (only 2 relays'
 descriptors would be rejected). I think we should just fix that mistake
 once and for all.

 +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] #21668 [Core Tor/Tor]: Prop278: Update cached_dir_t and related types to no longer assume single compresison method

[Tor Bug Tracker & Wiki]

#21668: Prop278: Update cached_dir_t and related types to no longer assume 
single
compresison method
+--
 Reporter:  ahf |  Owner:  ahf
 Type:  task| Status:  closed
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  implemented
 Keywords:  TorCoreTeam201703, prop278  |  Actual Points:
Parent ID:  #21667  | Points:  2
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by nickm):

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


Comment:

 Merged as part of #21667

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21667 [Core Tor/Tor]: Prop278: Handle new headers in directory.c

[Tor Bug Tracker & Wiki]

#21667: Prop278: Handle new headers in directory.c
+--
 Reporter:  ahf |  Owner:  ahf
 Type:  task| Status:  closed
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  implemented
 Keywords:  TorCoreTeam201703, prop278  |  Actual Points:
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by nickm):

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


Comment:

 Squashed and merged. Wooo!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18938 [Core Tor/Tor]: Authorities should reject non-ASCII content in ExtraInfo descriptors

[Tor Bug Tracker & Wiki]

#18938: Authorities should reject non-ASCII content in ExtraInfo descriptors
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  needs-proposal, isaremoved,  |  Actual Points:
  tor-03-unspecified-201612  |
Parent ID:  #18656   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by catalyst):

 * cc: catalyst (added)


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

Re: [tor-bugs] #1922 [Core Tor/Tor]: torrc.d-style configuration directories

[Tor Bug Tracker & Wiki]

#1922: torrc.d-style configuration directories
-+-
 Reporter:  aa138346 |  Owner:
 |  Jigsaw52
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, intro,   |  Actual Points:
  tor-03-unspecified-201612  |
Parent ID:   | Points:  medium
 Reviewer:   |Sponsor:
-+-
Changes (by Jigsaw52):

 * status:  needs_revision => needs_review


Comment:

 I've fixed most of the issues. Comments below:

 1. I find my version easier to read but I changed it back for consistency
 sake since this pattern is used on other places too.

 2. Done.

 3. and 4. I agree with the suggestion to expose the two APIs for
 config_get_lines and I implemented it. config_get_lines_include processes
 includes while config_get_lines is the same as before.

 5. Done.

 6. Done.

 7. I don't understand this one. I sort the list right after the calling
 tor_listdir().

 8. I do not like the paths ending in /*  because it might mislead users
 into thinking the * wildcard will work for any pattern. However, I added
 tests to make sure ending the path with PATH_SEPARATOR is supported as it
 is any easy way to tell a directory and a regular file apart. I left
 automatic detection of file/directory.

 9. Added support for quoted paths. Added tests for it too.

 I've merged with the current master and squashed all my changes here:
 https://github.com/Jigsaw52/tor/tree/torrc-dir-fix-1922_squashed

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22232 [Applications/Tor Launcher]: gather info on how Tor Launcher uses bootstrap status messages

[Tor Bug Tracker & Wiki]

#22232: gather info on how Tor Launcher uses bootstrap status messages
---+---
 Reporter:  catalyst   |  Owner:  brade
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  usability, ux  |  Actual Points:
Parent ID:  #21951 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by brade):

 To start monitoring events, Tor Launcher issues the following control port
 command: `SETEVENTS STATUS_CLIENT NOTICE WARN ERR`
 Tor Launcher then looks for `650` responses.

 When one of the following responses is received, it is logged to the
 browser console and added to an in-memory log buffer (which is used to
 implement "copy log"):
 `WARN`, `ERR`, `DEBUG`, `INFO`, `NOTICE`

 Tor Launcher also issues a `GETINFO status/bootstrap-phase` command soon
 after the control port connection has been established.

 When a `STATUS_CLIENT` message is received, Tor Launcher uses the info
 contained within the message to detect bootstrap errors and to show
 progress. The `GETINFO status/bootstrap-phase` response is used for this
 same purpose (both kinds of response messages are parsed and processeed by
 the same code).

 Tor Launcher maintains two important pieces of state information about the
 bootstrap process:
 * mIsBootstrapDone (Boolean) This is set to true when a `STATUS_CLIENT`
 `BOOTSTRAP` event with `PROGRESS=100` is received.  It is set to false
 when any other `STATUS_CLIENT` `BOOTSTRAP` event is received.
 * mBootstrapErrorOccurred (Boolean) This is set to true when a
 `STATUS_CLIENT` `BOOTSTRAP` event with a severity of `WARN` or `ERR`, and
 `RECOMMENDATION` of `warn` is received. It is set to false when
 mIsBootstrapDone is set to true as well as after the user makes changes to
 their settings (after a `SAVECONF` is done).


 Replying to [ticket:22232 catalyst]:
 > Does the progress bar currently map phase numbers directly into percent-
 done on the bar?
 Tor Launcher uses the `PROGRESS` field of the STATUS_CLIENT event for
 displaying the percent-done on the bar. Do those numbers directly
 correspond to phases?


 > Does it do anything with `TAG=` keywords in the BOOTSTRAP messages?
 The `TAG=` keywords are used for two purposes:
 1. The values are mapped to localized strings and displayed in the
 progress window.
 2. The `TAG` value along with `REASON` is used to suppress repeated
 errors. When Tor Launcher sets mBootstrapErrorOccurred to true (see
 above), an error is shown to the user unless the previous error displayed
 had the same `TAG` and `REASON` values.


 > Does it do anything with `SUMMARY=` strings other than displaying them
 in the dialog box?
 No. If Tor Launcher can't map the `TAG` to a localized string, it will
 display the SUMMARY text instead; otherwise, it is not used at all.


 > How does it know when to display the "copy logs" button with the warning
 icon?
 The "copy log" button is displayed with the warning icon when Tor Launcher
 detects a bootstrap error (see mBootstrapErrorOccurred above) or when it
 receives a log message event with severity of `WARN` or `ERR`.


 > Which other of the `BOOTSTRAP` keywords does it use and how?
 The severity value within a `STATUS_CLIENT` `BOOTSTRAP` event is used to
 detect bootstrap errors (as described above) and also to determine the
 level for local logging.

 When displaying errors, Tor Launcher tries to map the `REASON` values to
 localized strings. If this fails, the `WARNING` text is displayed instead.
 `HOSTADDR` is appended to the error text when it is present.

 `RECOMMENDATION` is part of the information that is used to determine if a
 bootstrap error has occurred (as described above).


 > Does it use any other asynchronous control protocol messages?
 Only the log events that were mentioned above.

 Mark and I know this is somewhat complicated, so we expect some follow up
 questions.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21667 [Core Tor/Tor]: Prop278: Handle new headers in directory.c

[Tor Bug Tracker & Wiki]

#21667: Prop278: Handle new headers in directory.c
+--
 Reporter:  ahf |  Owner:  ahf
 Type:  task| Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorCoreTeam201703, prop278  |  Actual Points:
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by ahf):

 Patch to fix test execution landed. Not exactly as per the instructions
 since a lot of the code in `handle_get_current_consensus()` does various
 NULL checks for `cached_consensus`, so we need to inject a consensus
 anyway - unless I'm overseeing 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] #21329 [Core Tor/Stem]: onions/detached and onions/current should return empty lists instead of errors

[Tor Bug Tracker & Wiki]

#21329: onions/detached and onions/current should return empty lists instead of
errors
---+
 Reporter:  meejah |  Owner:
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Stem  |Version:  Tor: 0.2.7.5
 Severity:  Normal | Resolution:  fixed
 Keywords:  controller |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by meejah):

 I believe this bug first existed in 0.2.7.5 and commit
 915c7438a77edfaf3103b69cb494a4f069a79a0c

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21329 [Core Tor/Stem]: onions/detached and onions/current should return empty lists instead of errors

[Tor Bug Tracker & Wiki]

#21329: onions/detached and onions/current should return empty lists instead of
errors
---+
 Reporter:  meejah |  Owner:
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Stem  |Version:  Tor: 0.2.7.5
 Severity:  Normal | Resolution:  fixed
 Keywords:  controller |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by meejah):

 * version:  Tor: 0.2.9.9 => Tor: 0.2.7.5


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22217 [Metrics/metrics-lib]: Parse new padding-counts lines

[Tor Bug Tracker & Wiki]

#22217: Parse new padding-counts lines
-+---
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * status:  needs_review => 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] #20546 [Metrics/CollecTor]: implement CleanUtils

[Tor Bug Tracker & Wiki]

#20546: implement CleanUtils
---+--
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-help   |  Actual Points:
Parent ID:  #20518 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by iwakeh):

 * status:  assigned => needs_review
 * keywords:   => metrics-help


Comment:

 What's open:

 * almost 300 checkstyle complaints (line lengths, indentation, and
 whitespace mostly)
 * use getFileName method in FileVisitor
 * verify tests and try to adapt them more closely to CollecTor use cases

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22255 [Core Tor/Tor]: Frequent OOM kills of tor precess

[Tor Bug Tracker & Wiki]

#22255: Frequent OOM kills of tor precess
--+
 Reporter:  DeS   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by DeS):

 Before problems occured following ubuntu updates where installed

 {{{
 2017-05-06 06:50:53 status installed man-db:amd64 2.6.7.1-1ubuntu1
 2017-05-06 06:50:53 status installed login:amd64 1:4.1.5.1-1ubuntu9.4
 2017-05-06 06:50:53 status installed man-db:amd64 2.6.7.1-1ubuntu1
 2017-05-06 06:50:53 status installed ureadahead:amd64 0.100.0-16
 2017-05-06 06:50:53 status installed passwd:amd64 1:4.1.5.1-1ubuntu9.4
 2017-05-06 13:29:10 status installed install-info:amd64 5.2.0.dfsg.1-2
 2017-05-06 13:29:11 status installed man-db:amd64 2.6.7.1-1ubuntu1
 2017-05-06 13:29:11 status installed bash:amd64 4.3-7ubuntu1.6
 2017-05-10 06:26:21 status installed librtmp0:amd64
 2.4+20121230.gitdf6c518-1ubuntu0.1
 2017-05-10 06:26:21 status installed libfreetype6:amd64 2.5.2-1ubuntu2.8
 2017-05-10 06:26:22 status installed libc-bin:amd64 2.19-0ubuntu6.11

 }}}
 Do you think one of these update packages could have trigged this
 behaviour ?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22149 [Core Tor/Tor]: prop140: Update dir-spec with prop140 protocols

[Tor Bug Tracker & Wiki]

#22149: prop140: Update dir-spec with prop140 protocols
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201705  |  Actual Points:  .3
Parent ID:  #13339 | Points:  .3
 Reviewer: |Sponsor:  Sponsor4
---+

Comment (by nickm):

 branch updated; I should do a corresponding update for the comma issue
 once the other prop#278 and prop#140 stuff is 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] #22149 [Core Tor/Tor]: prop140: Update dir-spec with prop140 protocols

[Tor Bug Tracker & Wiki]

#22149: prop140: Update dir-spec with prop140 protocols
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201705  |  Actual Points:  .3
Parent ID:  #13339 | Points:  .3
 Reviewer: |Sponsor:  Sponsor4
---+

Comment (by nickm):

 ok.  IMO it's fine to have it start accepting commas, since currently
 nothing sends more than one X-Or-Diff-From-Consensus value anyway.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22267 [Applications/Tor Browser]: Windows build of esr52 Tor Browser has no DEP/ASLR

[Tor Bug Tracker & Wiki]

#22267: Windows build of esr52 Tor Browser has no DEP/ASLR
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201705, tbb-security,  |  Actual Points:
  ff52-esr, tbb-7.0-must |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  TorTeam201705, tbb-security, tbb-hardened, ff52-esr,
 tbb-7.0-must => TorBrowserTeam201705, tbb-security, ff52-esr,
 tbb-7.0-must


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22262 [Applications/Tor Browser Sandbox]: Tor Browser Sandbox should offer the possibility to download the Tor Browser from mirrors

[Tor Bug Tracker & Wiki]

#22262: Tor Browser Sandbox should offer the possibility to download the Tor
Browser from mirrors
--+-
 Reporter:  blockflare|  Owner:  yawning
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by yawning):

 This sort of thing is kind of covered/touched on by #20792.

 It will only happen if there is an easy way to query the URL(s) for the
 current bundle/signature that factors in mirrors, a la the
 `downloads.json` file that lives on `aus1.torproject.org`, that is
 sufficiently trusted.  Where the bundle/signature is downloaded from is
 basically irrelevant if adversaries can block `aus1.torproject.org`.

 It's not something I'm going to fight for or push for, so it's up to
 someone else to make the appropriate metadata happen, document it, keep
 the metadata up to date, and point me at the documentation (or provide a
 patch) if they want this functionality.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22266 [Core Tor/Tor]: fix the jump-to-80% issue

[Tor Bug Tracker & Wiki]

#22266: fix the jump-to-80% issue
---+
 Reporter:  catalyst   |  Owner:
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  usability, ux  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by mcs):

 * cc: brade, mcs (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] #22265 [User Experience/Website]: write high-level overview of bootstrap process

[Tor Bug Tracker & Wiki]

#22265: write high-level overview of bootstrap process
-+--
 Reporter:  catalyst |  Owner:  catalyst
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by mcs):

 * cc: brade, mcs (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] #22267 [Applications/Tor Browser]: Windows build of esr52 Tor Browser has no DEP/ASLR

[Tor Bug Tracker & Wiki]

#22267: Windows build of esr52 Tor Browser has no DEP/ASLR
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  TorTeam201705, tbb-
 Severity:  Normal   |  security, tbb-hardened, ff52-esr,
 |  tbb-7.0-must
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 The `firefox.exe` binary in doesn't have DEP and ASLR enabled.

 It seems to affect only the binaries from the firefox part, as the
 `tor.exe` binary has DEP/ASLR enabled.

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

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

[Tor Bug Tracker & Wiki]

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

 * owner:   => asn
 * status:  new => assigned


Comment:

 Reassigning with permission; 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] #22255 [Core Tor/Tor]: Frequent OOM kills of tor precess

[Tor Bug Tracker & Wiki]

#22255: Frequent OOM kills of tor precess
--+
 Reporter:  DeS   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * component:  Core Tor => Core Tor/Tor


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

Re: [tor-bugs] #22255 [Core Tor]: Frequent OOM kills of tor precess

[Tor Bug Tracker & Wiki]

#22255: Frequent OOM kills of tor precess
--+
 Reporter:  DeS   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by DeS):

 I uploaded the output of a script I made. It shows memory usage as result
 of following commands and runs every 60 seconds.

 {{{
 
 #!/bin/bash -e

 export LC_ALL=C
 FILE=/home/user/mem.log
 echo "  date time $(free -m | grep total | sed -E 's/^
 (.*)/\1/g')" >>$FILE
 while true; do
 echo "$(date '+%Y-%m-%d %H:%M:%S') $(/usr/bin/free -m | grep Mem: |
 sed 's/Mem://g')" >>$FILE
 echo "$(date '+%Y-%m-%d %H:%M:%S') $(/usr/bin/free -m | grep Swap: |
 sed 's/Swap://g')" >>$FILE
 sleep 60
 done


 }}}
 You can see it starts 3 days ago. Always the amount is quite stable around
 usage of 1563 Mbyte.
 If you fast forward to
 [https://trac.torproject.org/projects/tor/attachment/ticket/22255/mem.log#L4448
 Line 4448 of mem.log] which is about 1 hour before this documented OOM you
 will see a fast increase of the memory usage to 3706 Mbyte before the
 process is killed.

 Many thanks for your support and help

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

Re: [tor-bugs] #22006 [Core Tor/Tor]: prop224: Validate ed25519 pubkeys to remove torsion component

[Tor Bug Tracker & Wiki]

#22006: prop224: Validate ed25519 pubkeys to remove torsion component
+
 Reporter:  asn |  Owner:  asn
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs prop224 ed25519  |  Actual Points:
Parent ID:  #21888  | Points:
 Reviewer:  |Sponsor:  SponsorR-can
+
Changes (by nickm):

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


Comment:

 asn says this is ok to defer

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #10286 [Applications/Tor Browser]: Touch events leak absolute screen coordinates

[Tor Bug Tracker & Wiki]

#10286: Touch events leak absolute screen coordinates
-+-
 Reporter:  mikeperry|  Owner:
 |  arthuredelstein
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-fingerprinting-resolution,   |  Actual Points:
  ff52-esr, tbb-testcase, tbb-firefox-patch, |
  tbb-7.0-must-alpha, TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by mcs):

 Replying to [comment:33 gk]:
 > Good theory. Do you mind filing an upstream bug for that? Meanwhile, I
 applied the patches to `tor-browser-52.1.0esr-7.0-2` (commits
 1b6559c0763f2ae0c9ad56307642e6d6462c3ede,
 331f089d6b6ba62463d8362d7ca01641a4cc92dc, and
 00d2bfb5067659c352690c06cb85a8b76bc7addb).

 Kathy and I confirmed that the problem does not occur on an older non-
 Retina MacBook Pro, and then I created
 https://bugzilla.mozilla.org/show_bug.cgi?id=1364969

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18329 [Core Tor/Tor]: Let bridges indicate when they don't want BridgeDB to distribute their address

[Tor Bug Tracker & Wiki]

#18329: Let bridges indicate when they don't want BridgeDB to distribute their
address
--+
 Reporter:  karsten   |  Owner:
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bridge, stem  |  Actual Points:
Parent ID:| Points:  .2 remaining
 Reviewer:  nickm |Sponsor:
--+

Comment (by atagar):

 I'd love that. Definitely has my vote! :P

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22266 [Core Tor/Tor]: fix the jump-to-80% issue

[Tor Bug Tracker & Wiki]

#22266: fix the jump-to-80% issue
--+
 Reporter:  catalyst  |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  usability, ux
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 If enough existing directory information is available, the bootstrap
 progress as reported to the logs and the control connection jumps from 0%
 to 80% almost immediately.  This is misleading and causes user
 frustration, as reported by Linda's study.

 When bootstrapping with existing directory information, we should rescale
 the progress numbers so they advance on something resembling a linear time
 scale, which is probably closer to what users expect to see.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22265 [User Experience/Website]: write high-level overview of bootstrap process

[Tor Bug Tracker & Wiki]

#22265: write high-level overview of bootstrap process
-+--
 Reporter:  catalyst |  Owner:  catalyst
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 There needs to be a better high-level overview of the bootstrap process so
 developers, users, and UX people can have a better mental model of what's
 going on, what can go wrong, and how to fix it when it does.

 Probably should be a wiki page unless someone has a better idea of where
 to put it.  There is some text in `control-spec.txt` that is a decent
 starting point, but could use more elaboration of background material.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21846 [Core Tor/Torflow]: BwAuthority can't be run out of the box without manual work

[Tor Bug Tracker & Wiki]

#21846: BwAuthority can't be run out of the box without manual work
---+--
 Reporter:  davidwf|  Owner:  aagbsn
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/Torflow   |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer:  chelseakomlo, tom  |Sponsor:
---+--

Comment (by chelseakomlo):

 Replying to [comment:11 davidwf]:

 > > In stop_scan.sh: ...
 >
 > stop_scan.sh is actually just copy and pasted from the first lines of
 the run_scan.sh. I don't disagree with anything you said, but I'm not
 confident that I can make those changes in a way that works reliably
 without digging too deeply past the initial scope of "get this working on
 a laptop".

 If we don't want to introduce tech debt in multiple places, stop_scan.sh
 doesn't need to be added as part of this patch, but I agree having this as
 a convenience would be useful.

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

Re: [tor-bugs] #22245 [Core Tor/Tor]: Logic error with monthly accounting

[Tor Bug Tracker & Wiki]

#22245: Logic error with monthly accounting
---+---
 Reporter:  arma   |  Owner:
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  029-backport 030-backport  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * status:  new => needs_review
 * keywords:   => 029-backport 030-backport
 * milestone:  Tor: 0.3.1.x-final => Tor: 0.3.0.x-final


Comment:

 I've made the suggested fix in a branch `bug22245_024`.  I suggest that we
 backport no farther than 0.2.9.  I've merged this in master.  Marking for
 possible 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] #22244 [Core Tor/Tor]: tor_assert(strchr(cp, ':')+2) is never going to do what we want

[Tor Bug Tracker & Wiki]

#22244: tor_assert(strchr(cp, ':')+2) is never going to do what we want
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 in master 0e348720fc3a4d fixes this; not planning to backport.  I took
 Roger's solution above, since it looks fine to me

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22217 [Metrics/metrics-lib]: Parse new padding-counts lines

[Tor Bug Tracker & Wiki]

#22217: Parse new padding-counts lines
-+---
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 Please find four commits in [https://gitweb.torproject.org/user/iwakeh
 /metrics-lib.git/?h=task-22217 my repo branch].

 Open topics I noticed in other parts of the code:
 The empty key issue seems to also apply to comma separated key-value pairs
 and maybe others.  Similarly repeated keys.  New ticket?

 It would be good to add the check for the correct exception string also to
 other test methods in ExtraInfoDescriptorTest.  Another 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] #18100 [Core Tor/Tor]: src/or/connection_edge.c typo

[Tor Bug Tracker & Wiki]

#18100: src/or/connection_edge.c typo
---+---
 Reporter:  jirib  |  Owner:
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.0.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.2.9.9
 Severity:  Normal | Resolution:
 Keywords:  029-backport 030-backport  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * keywords:  isaremoved, nickwants029, lorax, tor-03-unspecified-201612 =>
 029-backport 030-backport
 * status:  merge_ready => needs_review
 * milestone:  Tor: 0.3.1.x-final => Tor: 0.3.0.x-final


Comment:

 Okay, sounds good.  I've put your patch in a new branch `bug18100_029` in
 my public repository, along with a commit message and a changes file. I'm
 merging it into master now. If nothing goes wrong (and I don't expect it
 will) we can backport to 0.2.9 and 0.3.0.  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] #22148 [Core Tor/Tor]: prop140: conformance to proposal, unhandled corner cases

[Tor Bug Tracker & Wiki]

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

Comment (by nickm):

 ok; I'll aim to merge these and resolve conflicts after the #21667 merge.

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => merge_ready


Comment:

 Both `prop140_aftermath_cfg` and `prop140_aftermath_url` looks good. It
 also fixes one of my questions on #22149.

 This looks like it will cause some conflicts for the changes in #21667,
 but that should be easy to handle.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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: #22101, #22102, #17903, #18320, ...

[Tor Bug Tracker & Wiki]

Batch modification to #22101, #22102, #17903, #18320, #19487, #19661, #21310, 
#1922, #20424, #8453, #17847, #20456 by nickm:
milestone to Tor: 0.3.2.x-final

Comment:
0.3.1 feature freeze today: these don't seem like they will be all sorted out 
in time. Let's try to make progress in 0.3.2. 

--
Tickets URL: 

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

Re: [tor-bugs] #22149 [Core Tor/Tor]: prop140: Update dir-spec with prop140 protocols

[Tor Bug Tracker & Wiki]

#22149: prop140: Update dir-spec with prop140 protocols
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201705  |  Actual Points:  .3
Parent ID:  #13339 | Points:  .3
 Reviewer: |Sponsor:  Sponsor4
---+

Comment (by ahf):

 The code does:

 {{{
 3661   smartlist_split_string(hex_digests, hdr, " ",
 3662  SPLIT_SKIP_SPACE|SPLIT_IGNORE_BLANK, -1);
 }}}

 So no ",".

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22149 [Core Tor/Tor]: prop140: Update dir-spec with prop140 protocols

[Tor Bug Tracker & Wiki]

#22149: prop140: Update dir-spec with prop140 protocols
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201705  |  Actual Points:  .3
Parent ID:  #13339 | Points:  .3
 Reviewer: |Sponsor:  Sponsor4
---+

Comment (by nickm):

 Replying to [comment:4 ahf]:
 > Generally looks good. Two questions:
 >
 > 1) This patch marks prop140 as closed, but do we support the `/tor
 /status-vote/current/consensus/diff//.z` paths already?

 Not until we merge one of the branches in #22149 ; I'm not planning to
 merge this branch until #22149 is done

 > 2) This is in the nitpick category. Do we want to change the delimiter
 in `X-Or-Diff-From-Consensus` to use "," and optionally " " like in the
 rest of HTTP?

 Huh. I think right now it allows either in the code; I guess we should
 change the spec to match.

 > Catalyst also commented on a possible typo above.

 Agreed, will fix before merge.

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

Re: [tor-bugs] #22149 [Core Tor/Tor]: prop140: Update dir-spec with prop140 protocols

[Tor Bug Tracker & Wiki]

#22149: prop140: Update dir-spec with prop140 protocols
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201705  |  Actual Points:  .3
Parent ID:  #13339 | Points:  .3
 Reviewer: |Sponsor:  Sponsor4
---+
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 Generally looks good. Two questions:

 1) This patch marks prop140 as closed, but do we support the `/tor/status-
 vote/current/consensus/diff//.z` paths already?

 2) This is in the nitpick category. Do we want to change the delimiter in
 `X-Or-Diff-From-Consensus` to use "," and optionally " " like in the rest
 of HTTP?

 Catalyst also commented on a possible typo above.

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

Re: [tor-bugs] #20270 [Core Tor/Tor]: "Descriptor is missing an ntor curve25519 onion key" message too noisy?

[Tor Bug Tracker & Wiki]

#20270: "Descriptor is missing an ntor curve25519 onion key" message too noisy?
-+-
 Reporter:  arma |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  easy, triage-out-030-201612  |  Actual Points:  .1
  TorCoreTeam201705 029-backport 030-backport|
Parent ID:   | Points:  .2
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Trying this in 0.3.1, after review from ln5.  If nothing breaks, let's
 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] #22264 [Core Tor/Tor]: Remove old cached_dir_t code

[Tor Bug Tracker & Wiki]

#22264: Remove old cached_dir_t code
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #21667 [Core Tor/Tor]: Prop278: Handle new headers in directory.c

[Tor Bug Tracker & Wiki]

#21667: Prop278: Handle new headers in directory.c
+--
 Reporter:  ahf |  Owner:  ahf
 Type:  task| Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorCoreTeam201703, prop278  |  Actual Points:
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by nickm):

 My branch `21667_2_testing` fixes 2 of the failing tests, and adds 
 comments explaining how to fix the other 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] #21668 [Core Tor/Tor]: Prop278: Update cached_dir_t and related types to no longer assume single compresison method

[Tor Bug Tracker & Wiki]

#21668: Prop278: Update cached_dir_t and related types to no longer assume 
single
compresison method
+--
 Reporter:  ahf |  Owner:  ahf
 Type:  task| Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorCoreTeam201703, prop278  |  Actual Points:
Parent ID:  #21667  | Points:  2
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by nickm):

 * status:  assigned => needs_review
 * parent:   => #21667


Comment:

 Included in #21667

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22264 [Core Tor/Tor]: Remove old cached_dir_t code

[Tor Bug Tracker & Wiki]

#22264: Remove old cached_dir_t code
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 I'm pretty sure that with the completion of prop 278, we no longer use the
 old cached_dir_t code for anything at all. Let's rip it out!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21667 [Core Tor/Tor]: Prop278: Handle new headers in directory.c

[Tor Bug Tracker & Wiki]

#21667: Prop278: Handle new headers in directory.c
+--
 Reporter:  ahf |  Owner:  ahf
 Type:  task| Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorCoreTeam201703, prop278  |  Actual Points:
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by nickm):

 patches look fine -- once the tests are working, let's merge.

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

Re: [tor-bugs] #22254 [Applications/Tor Browser]: Our extensions get disabled in the Tor Browser 7.0a4 release candidate

[Tor Bug Tracker & Wiki]

#22254: Our extensions get disabled in the Tor Browser 7.0a4 release candidate
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Blocker   | Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mcs):

 Replying to [comment:3 gk]:
 > `pref()` does not like a `;` between pref name and value. Blah.

 Blah indeed. Apparently that was an easy typo to miss since at least three
 of us failed to notice 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] #21667 [Core Tor/Tor]: Prop278: Handle new headers in directory.c

[Tor Bug Tracker & Wiki]

#21667: Prop278: Handle new headers in directory.c
+--
 Reporter:  ahf |  Owner:  ahf
 Type:  task| Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorCoreTeam201703, prop278  |  Actual Points:
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by ahf):

 * status:  needs_revision => needs_review


Comment:

 Patches added to GL - your comments should be addressed as well.

 5 of the `dir_handle_get/...` tests are currently failing, looking into
 that now.

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

Re: [tor-bugs] #22207 [Core Tor/Tor]: Add bridge authority fingerprint to sanitized bridge network statuses

[Tor Bug Tracker & Wiki]

#22207: Add bridge authority fingerprint to sanitized bridge network statuses
--+--
 Reporter:  karsten   |  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  intro |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by karsten):

 * component:  Metrics/CollecTor => Core Tor/Tor


Comment:

 Sounds good!

 This ticket was originally supposed to track changes to CollecTor's bridge
 descriptor sanitizer to include the bridge authority fingerprint in
 network statuses produced by current and older tor versions.  But let's
 tackle the Core/Tor Tor side of things first, and we'll implement the same
 thing in CollecTor after that.  Changing component to Core Tor/Tor.

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  accepted => needs_information


Comment:

 Putting this into needs_information. I want to keep an eye on this as we
 try it in practice, but I think that the current approach will likely turn
 out to be okay.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by asn):

 Replying to [comment:13 s7r]:
 > asn: you could be right with the second theory. Maybe the descriptors
 that need to be fetched are not even available, because the guard is not
 running in current consensus. This is based on a log analysis I just did
 now:
 >

 For the record, the theory is that since primary guards is just an ordered
 subset of guards that have been used in the past, there is no guarantee
 that the primary guards are currently online or in the consensus. Hence,
 this can occur naturally if your primary guards or bridges are offline.

 I'm not sure if this is the only possible way that our logic can introduce
 big bootstrapping delays, but it seems like a plausible one.

 Perhaps to address this for the non-bridge case, we should count a primary
 guard descriptor as missing (for the purposes of
 `guard_selection_have_enough_dir_info_to_build_circuits()`) only if that
 guard is present in the consensus. For the case of bridges, it might make
 sense to relax or disable our dir info requirements completely.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22253 [Core Tor/Tor]: Resolve TROVE-2017-002

[Tor Bug Tracker & Wiki]

#22253: Resolve TROVE-2017-002
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #18988 [Core Tor/Tor]: log error level messages if relay (self) is not in consensus

[Tor Bug Tracker & Wiki]

#18988: log error level messages if relay (self) is not in consensus
---+---
 Reporter:  cypherpunks|  Owner:
 Type:  enhancement| Status:
   |  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  easy, nickm-deferred-20161017  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * milestone:  Tor: 0.3.1.x-final => 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] #20575 [Core Tor/Tor]: Delete HTTPProxy from Tor config manual, and Tor itself

[Tor Bug Tracker & Wiki]

#20575: Delete HTTPProxy from Tor config manual, and Tor itself
---+
 Reporter:  cypherpunks|  Owner:  dgoulet
 Type:  task   | Status:  needs_information
 Priority:  High   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  triage-out-030-201612  |  Actual Points:
Parent ID: | Points:  .2
 Reviewer: |Sponsor:
---+
Changes (by nickm):

 * milestone:  Tor: 0.3.1.x-final => 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] #22122 [Metrics/metrics-lib]: Add support for six new key-value pairs added by OnionPerf

[Tor Bug Tracker & Wiki]

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

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


Comment:

 Replying to [comment:8 iwakeh]:
 > Replying to [comment:7 karsten]:
 > > Replying to [comment:6 iwakeh]:
 > > > I think there should be an OnionperfResult class that also supports
 the old torperf format.
 > > >
 > > > Eventually, there might be more use cases for the additional data in
 onionperf measurements.
 > > > And, onionperf already adds many keys that are not part of the
 torperf format.
 > > >
 > > > So, all 'torperf' should become 'onionperf' soon.
 > >
 > > After giving this some thoughts I think it's more complicated than
 this.  The reason is that we're using OnionPerf in a kind of Torperf-
 compatibility mode right now, where it uses the same measurement setup
 (with static downloads of 50KB, 1MB, 5MB files) and produces the same data
 format with only minimal additions.
 > >
 > > But we'll soon want to add more realistic measurement setups
 (simulated website downloads), produce a richer data format (probably JSON
 based, IIRC), and present more useful measurement results on Tor Metrics.
 That's what we'll want to call OnionPerf, not what we're doing right now.
 And we'll still want to refer to past measurements and data formats as
 Torperf.
 >
 > Valid concerns.
 >
 > >
 > > How about we:
 > >  1. change the type annotation in .tpf files produced by OnionPerf to
 `@type torperf 1.1`, because that format is still backward compatible to
 `@type torperf 1.0` but adds new fields that a parser for the old format
 does not recognize;
 >
 > Agreed.

 Opened #22263 for this.

 > >  2. keep referring to everything in CollecTor that downloads from
 OnionPerf instances as OnionPerf, because we're really downloading from
 that new tool, not from the old Torperf tool;
 >
 > Agreed.

 Nothing to be done here.

 > >  3. update https://collector.torproject.org/#type-torperf to say that
 these are "Torperf and OnionPerf Measurement Results" and specify what
 fields are new in version 1.1;
 >
 > Agreed.

 Also part of #22263.

 > >  4. leave metrics-lib's `TorperfResults` unchanged and just say that
 it supports new fields added in version 1.1;
 >
 > Agreed.

 Nothing to be done here.  We don't explicitly say which minor versions are
 supported.  Maybe we should, but in that case we should do that for all
 descriptor types.  In any case, this shouldn't block closing this ticket.

 > >  5. rename metrics-web's `onionperf.csv` (beta) to `torperf2.csv`,
 because it still uses the same measurement setup and data format as the
 former `torperf.csv`.  It just adds a new column that makes it backward-
 incompatible with `torperf.csv`.
 >
 > I would suggest `torperf-1.1.csv` to reflect the type version.

 Done.

 > > And how about once we're moving to more complex measurement setups and
 a richer data format in OnionPerf we call that `@type onionperf 1.0`,
 `OnionPerfMeasurement`, `onionperf.csv`, and so on.
 > >
 > > What do you think?
 >
 > That all makes sense. Fine.

 Okay, great.  I think we're done here now.  Thanks for reviewing!
 Closing.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22263 [Metrics/CollecTor]: Raise @type torperf version produced by OnionPerf from 1.0 to 1.1

[Tor Bug Tracker & Wiki]

#22263: Raise @type torperf version produced by OnionPerf from 1.0 to 1.1
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 [https://gitweb.torproject.org/karsten/metrics-db.git/log/?h=task-22263 My
 branch task-22263] contains the website changes for that last step there.
 We should do the others first, 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

[tor-bugs] #22263 [Metrics/CollecTor]: Raise @type torperf version produced by OnionPerf from 1.0 to 1.1

[Tor Bug Tracker & Wiki]

#22263: Raise @type torperf version produced by OnionPerf from 1.0 to 1.1
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 OnionPerf adds a few keys to Torperf's `@type torperf 1.0` format that
 parsers for that version don't recognize.  That's what we have the version
 number for.  We should change that annotation to `@type torperf 1.1` to
 reflect this backward-compatible format change.

 Next steps:
  - Change version number in the OnionPerf sources.
  - Update to latest OnionPerf on our three OnionPerf instances and produce
 new .tpf files on our OnionPerf instances back to April 11, 2017.
  - Download updated .tpf files in CollecTor and re-create tarballs.
  - Update CollecTor website to describe new keys in version 1.1 (branch
 follows in a bit).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18329 [Core Tor/Tor]: Let bridges indicate when they don't want BridgeDB to distribute their address

[Tor Bug Tracker & Wiki]

#18329: Let bridges indicate when they don't want BridgeDB to distribute their
address
--+
 Reporter:  karsten   |  Owner:
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bridge, stem  |  Actual Points:
Parent ID:| Points:  .2 remaining
 Reviewer:  nickm |Sponsor:
--+

Comment (by Sebastian):

 I'm strongly considering a proposal where any document we produce must be
 valid utf-8. This has a pretty small fallout currently (only 2 relays'
 descriptors would be rejected). I think we should just fix that mistake
 once and for all.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22253 [Core Tor/Tor]: Resolve TROVE-2017-002

[Tor Bug Tracker & Wiki]

#22253: Resolve TROVE-2017-002
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Major | Resolution:
 Keywords:|  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] #18329 [Core Tor/Tor]: Let bridges indicate when they don't want BridgeDB to distribute their address

[Tor Bug Tracker & Wiki]

#18329: Let bridges indicate when they don't want BridgeDB to distribute their
address
--+
 Reporter:  karsten   |  Owner:
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bridge, stem  |  Actual Points:
Parent ID:| Points:  .2 remaining
 Reviewer:  nickm |Sponsor:
--+

Comment (by atagar):

 The mistake was letting these fields be so ill defined that they can be
 anything. Even garbage that is completely nonsensical and unparseable.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22262 [Applications/Tor Browser Sandbox]: Tor Browser Sandbox should offer the possibility to download the Tor Browser from mirrors

[Tor Bug Tracker & Wiki]

#22262: Tor Browser Sandbox should offer the possibility to download the Tor
Browser from mirrors
--+-
 Reporter:  blockflare|  Owner:  yawning
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 If someone is in a censored area (and he doesn't know how to setup system
 tor with bridges) then it would be much better to offer him the
 possibility to download the Tor Browser from a mirror (in particular the
 github mirror)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21320 [Applications/Tor Browser]: Glyphs/Dingbats in uBlock Origin TBB not displaying in Gnu+Linux

[Tor Bug Tracker & Wiki]

#21320: Glyphs/Dingbats in uBlock Origin TBB not displaying in Gnu+Linux
--+--
 Reporter:  vegansalad|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #18364| Points:
 Reviewer:|Sponsor:
--+--

Comment (by blockflare):

 Replying to [comment:1 cypherpunks]:
 > Don't use uBlock in TBB.

 It's included by default in Tails.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22260 [Internal Services/Schleuder]: Schleuder does not decrypt and re-encrypt attachments

[Tor Bug Tracker & Wiki]

#22260: Schleuder does not decrypt and re-encrypt attachments
-+--
 Reporter:  teor |  Owner:  hiro
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Schleuder  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by hiro):

 Thanks Teor for reporting this. I will look into it and get in touch with
 the schleuder people too.

 -hiro/silvia

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22105 [Core Tor/Tor]: define a more generic LIBFUZZER = ... in Makefile.in

[Tor Bug Tracker & Wiki]

#22105: define a more generic LIBFUZZER = ... in Makefile.in
--+
 Reporter:  toralf|  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.6
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  .1
 Reviewer:|Sponsor:
--+
Changes (by arma):

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


Comment:

 I'm moving to the current upcoming milestone, so this ticket doesn't get
 lost. People can move it to 0.3.2 if they want.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21809 [Core Tor/Tor]: Tor sometimes waits much longer than ShutdownWaitLength

[Tor Bug Tracker & Wiki]

#21809: Tor sometimes waits much longer than ShutdownWaitLength
---+---
 Reporter:  teor   |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.0.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.2.9.10
 Severity:  Normal | Resolution:
 Keywords:  regression, 029-backport?  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:
---+---

Comment (by arma):

 What sorts of things will we need before we can make progress here?

 It seems to me that we're going to need a relay operator who experiences
 it consistently, for starters.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18329 [Core Tor/Tor]: Let bridges indicate when they don't want BridgeDB to distribute their address

[Tor Bug Tracker & Wiki]

#18329: Let bridges indicate when they don't want BridgeDB to distribute their
address
--+
 Reporter:  karsten   |  Owner:
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bridge, stem  |  Actual Points:
Parent ID:| Points:  .2 remaining
 Reviewer:  nickm |Sponsor:
--+

Comment (by arma):

 Replying to [comment:22 atagar]:
 > It was a mistake to allow the contact and platform fields to be so
 nebulous. Hopefully we won't do that with any new ones. ;)

 What was the mistake?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18329 [Core Tor/Tor]: Let bridges indicate when they don't want BridgeDB to distribute their address

[Tor Bug Tracker & Wiki]

#18329: Let bridges indicate when they don't want BridgeDB to distribute their
address
--+
 Reporter:  karsten   |  Owner:
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bridge, stem  |  Actual Points:
Parent ID:| Points:  .2 remaining
 Reviewer:  nickm |Sponsor:
--+

Comment (by atagar):

 > Damian, what would you like to see the spec for the Contact field look
 like? Then we can use that here too.

 Hi Roger, the contact and platform fields would be particularly bad ones
 to emulate. They're the only fields in the spec that allow arbitrary bytes
 (they don't even need to be any form of recognizable text... and due to
 that in practice sometimes aren't).

 It was a mistake to allow the contact and platform fields to be so
 nebulous. Hopefully we won't do that with any new ones. ;)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21554 [Core Tor/Tor]: Inventory proposals that need merging into specs ; merge them.

[Tor Bug Tracker & Wiki]

#21554: Inventory proposals that need merging into specs ; merge them.
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  task   | Status:  accepted
 Priority:  High   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201703  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by arma):

 How are we doing on these (for 0.3.0)? Are we about to have another pile
 of them waiting for us with 0.3.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] #22255 [Core Tor]: Frequent OOM kills of tor precess

[Tor Bug Tracker & Wiki]

#22255: Frequent OOM kills of tor precess
--+
 Reporter:  DeS   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Replying to [comment:5 ryru]:
 > The system has about 4 GB memory:

 It looks from your earlier log like it takes 12 hours or something before
 it dies?

 Can you track the memory size over that 12 hours? That is, is it fine
 until suddenly everything goes bad, or does it slowly grow?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22255 [Core Tor]: Frequent OOM kills of tor precess

[Tor Bug Tracker & Wiki]

#22255: Frequent OOM kills of tor precess
--+
 Reporter:  DeS   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Replying to [comment:5 ryru]:
 > we have not tried the MaxMemInQueues setting yet. It is unset, therefor
 Tor should pick a proper configuration based on the physically available
 memory, shouldn't it?

 There's a notice-level log when Tor starts up, telling you what value it
 picked, e.g.
 {{{
 May 10 03:34:40.480 [notice] Based on detected system memory,
 MaxMemInQueues is set to 8192 MB. You can override this by setting
 MaxMemInQueues by hand.
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #17605 [Core Tor/Tor]: Tell caches to remove X-Your-Address-Is from Tor Directory documents

[Tor Bug Tracker & Wiki]

#17605: Tell caches to remove X-Your-Address-Is from Tor Directory documents
-+-
 Reporter:  teor |  Owner:  jryans
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-auth, isaremoved,|  Actual Points:
  tor-03-unspecified-201612, review-group-15 |
Parent ID:   | Points:  2
 Reviewer:  nickm|Sponsor:
-+-

Comment (by arma):

 Replying to [comment:1 yawning]:
 > I would vote for: `Pragma: no-cache` *and* `Cache-Control: no-store`
 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.2) in
 responses.

 Maybe somebody wants to put together a short branch that adds those
 headers to directory responses when they come over an unencrypted channel?
 It seems everybody here agrees with that component (or is that 'nobody
 disagrees').

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22255 [Core Tor]: Frequent OOM kills of tor precess

[Tor Bug Tracker & Wiki]

#22255: Frequent OOM kills of tor precess
--+
 Reporter:  DeS   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by ryru):

 The system has about 4 GB memory:

   # cat /proc/meminfo
   MemTotal:3877580 kB
   MemFree: 2250280 kB

 We run this configuration since mid 2015.

 No, we have not tried the MaxMemInQueues setting yet. It is unset,
 therefor Tor should pick a proper configuration based on the physically
 available memory, shouldn't it?

 Many thanks for your support!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20532 [Core Tor/Tor]: Make sure directory_initiate_request handles pluggable transports correctly

[Tor Bug Tracker & Wiki]

#20532: Make sure directory_initiate_request handles pluggable transports 
correctly
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bridge-client, bridge-bypass,|  Actual Points:
  triage-out-030-201612  |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Can somebody summarize what the issue is? Maybe asn can, since he
 confirmed it?

 (I agree, on first glance #20531 is worth checking.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20575 [Core Tor/Tor]: Delete HTTPProxy from Tor config manual, and Tor itself

[Tor Bug Tracker & Wiki]

#20575: Delete HTTPProxy from Tor config manual, and Tor itself
---+
 Reporter:  cypherpunks|  Owner:  dgoulet
 Type:  task   | Status:  needs_information
 Priority:  High   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  triage-out-030-201612  |  Actual Points:
Parent ID: | Points:  .2
 Reviewer: |Sponsor:
---+

Comment (by arma):

 We can also deprecate ReachableDirAddresses for the same reason.

 Though, a tiny gotcha: if we're wanting to warn about use of
 ReachableDirAddresses, notice that FascistFirewall 1, which we still
 should support, auto-sets ReachableDirAddresses, and we shouldn't warn if
 the only reason it's set is because of FascistFirewall.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20575 [Core Tor/Tor]: Delete HTTPProxy from Tor config manual, and Tor itself

[Tor Bug Tracker & Wiki]

#20575: Delete HTTPProxy from Tor config manual, and Tor itself
---+
 Reporter:  cypherpunks|  Owner:  dgoulet
 Type:  task   | Status:  needs_information
 Priority:  High   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  triage-out-030-201612  |  Actual Points:
Parent ID: | Points:  .2
 Reviewer: |Sponsor:
---+

Comment (by arma):

 I think we should deprecate both httpproxy and httpproxyauthenticator,
 with intent to remove them when nobody complains.

 They are options from back in the day when client directory interactions
 happened over http, so we needed to survive having a local proxy in
 between us and the web.

 I think the chances that some relay operator ran across them and decided
 to send their relay descriptor uploads via an http proxy are basically
 zero. (Or, if somebody did, they need to stop.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22261 [Metrics/Atlas]: Please remove the $ from atlas family fingerprints

[Tor Bug Tracker & Wiki]

#22261: Please remove the $ from atlas family fingerprints
---+-
 Reporter:  teor   |  Owner:  irl
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by cypherpunks):

 The dollar signs are added by Onionoo (see
 https://onionoo.torproject.org/details?fields=effective_family=10)
 so it would probably be better to fix Onionoo instead.

 Keep this ticket open though because Atlas needs some cleaning up once
 Onionoo fixes the 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

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

[Tor Bug Tracker & Wiki]

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

Comment (by arma):

 Nick asked if we could defer this one to 0.3.2, and based on my current
 understanding of the ticket, my answer was "no, this looks like a serious
 bug that needs attention".

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18320 [Core Tor/Tor]: Clear old entries from the key-pinning journal file

[Tor Bug Tracker & Wiki]

#18320: Clear old entries from the key-pinning journal file
-+-
 Reporter:  teor |  Owner:
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dos, TorCoreTeam201607, review-  |  Actual Points:
  group-3, nickm-deferred-20161005   |
Parent ID:   | Points:  3
 Reviewer:  dgoulet  |Sponsor:
-+-

Comment (by arma):

 I don't see a rush to get this one into 0.3.1.

 But it might also be wise to grab onto it pretty soon in 0.3.2, before the
 code diverges too much from the patches 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] #18329 [Core Tor/Tor]: Let bridges indicate when they don't want BridgeDB to distribute their address

[Tor Bug Tracker & Wiki]

#18329: Let bridges indicate when they don't want BridgeDB to distribute their
address
--+
 Reporter:  karsten   |  Owner:
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bridge, stem  |  Actual Points:
Parent ID:| Points:  .2 remaining
 Reviewer:  nickm |Sponsor:
--+

Comment (by arma):

 Looks like we're trying to make this ticket more complicated than it is.

 The {{{feature18329}}} branch is almost entirely about the new torrc
 option, so yes, it is all user-facing. I think we should stick with words,
 like "none", "email", "https", which makes it easily extensible to more
 values, without messing with Tor at all, if the future brings us new
 distribution strategies.

 (If we used numbers instead, we would need to let the user configure a
 number that this Tor version doesn't know about, so people can choose
 other distribution approaches later. But then you'd need to keep everybody
 synchronized on what the numbers mean, and people could still list numbers
 that you haven't picked a definition for yet. tl;dr, I don't think it
 would solve much to use numbers, and I think it would indeed hurt the
 usability.)

 The BridgeDB behavior can be very simple: if the field is there and
 bridgedb recognizes the value in the field, do the right thing with it,
 else if the field is there and bridgedb doesn't recognize it, don't
 distribute that bridge.

 I agree with Damian that we could be a bit clearer on the torspec side. I
 think what dgoulet was going for was the same spec as the Contact field
 has. From Tor's perspective, it is essentially an "anything goes" string.
 We could change it to say "set of 'key and optional value' fields" or
 something if we liked, but I think the only effect of trying to constrain
 it here will be producing bugs in stem later if we decide to change it.
 Damian, what would you like to see the spec for the Contact field look
 like? Then we can use that here too.

 Nick, what did you mean by "with Tor restricted to only accept recognized
 names if they appear in torrc"? You're hoping that we teach Tor more about
 the possible values of the field, and that it says something like "nope,
 never heard of that one, you can't set it" for ones it doesn't know about?
 Does that mean that people running Tor on (say) version 0.3.1.x will need
 to upgrade in order to list a name that we started using while (say) Tor
 0.3.2.x was current? Why would we do that?

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