Re: [tor-bugs] #25985 [Obfuscation/Snowflake]: Add AMP cache as another domain fronting option with Google

[Tor Bug Tracker & Wiki]

#25985: Add AMP cache as another domain fronting option with Google
---+--
 Reporter:  twim   |  Owner:  (none)
 Type:  project| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 Replying to [comment:17 twim]:
 > Replying to [comment:16 dcf]:
 > >  *
 
[https://github.com/nogoegst/snowflake/commit/ce1e2e24d9bd39ad51c82006213dc7a1f1e4776f
 #diff-79897051d7aac1f314600a930afebe9aR275 In the "/client/amp/" path],
 I'm not sure if a trailing slash is significant, but all the entries
 should either have a trailing slash or not have one.
 >
 > This is just how it works. '/client' handles only this exact path, while
 '/client/amp/' handles everything with this prefix and sets up a redirect
 from '/client/amp/' to '/client/amp/'.

 Great, thanks. I was wondering whether we should add a trailing slash to
 the other entries but it sounds like it should be exactly the way you
 wrote it. `"/client/amp/"` gets a trailing slash because it takes
 additional information in the rest of the URL path; all the others do not
 get a trailing slash because we only want to match those exact paths.

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

Re: [tor-bugs] #25985 [Obfuscation/Snowflake]: Add AMP cache as another domain fronting option with Google

[Tor Bug Tracker & Wiki]

#25985: Add AMP cache as another domain fronting option with Google
---+--
 Reporter:  twim   |  Owner:  (none)
 Type:  project| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 I'm sorry for being harsh in my previous response. I don't mean to give
 the impression that I don't appreciate the work you're doing. I'm overly
 sensitive on this point because it was my failure to be firm with the
 flash proxy source code that led it to becoming an overly abstracted,
 tightly coupled mess.

 I'm not against refactoring, even as part of this ticket. But I have to
 insist on functional changes and refactoring changes being in separate
 commits. For one thing, it enables discussing the functional and
 refactoring changes separately. But for another, it helps me reconstruct
 your thinking to justify the changes. Look at it from my point of view.
 When I'm reviewing code I would rather see steps A→B→C, where B is simple
 but introduces some obvious code duplication, and C refactors the
 duplication; than see A→C where I have to mentally reconstruct B in order
 to fully understand the change. It's better for `git blame` purposes too.
 I know you know these things too; I'm not trying to explain it to you,
 just letting you know what I value as a code reviewer.

 WRT external interfaces, I know the programmer's instinct is always to
 generalize, generalize as soon as possible and promote interfaces to
 public APIs. I prefer to keep interfaces private whenever possible, not
 expose unneeded functionality, and only make an interface generic and
 external after it has endured some internal battle testing. You don't
 really know what you want from an external API until you have used it
 privately for a while anyway. And if it turns out that you never really
 need to make it public, that's even better, because every public interface
 is an ongoing maintenance burden. This is just my point of view and I
 respect that people can think differently. I'm not ''too'' worried about
 the external amper dep, because we can always remove it if we find it
 necessarily, when we eventually add TLS fingerprint camouflage or
 something like that. It just means an additional new sub-project in the
 Tor Browser build--it all adds up.

 Anyway, I already like your branch in
 
[https://github.com/nogoegst/snowflake/commits/b75253ba55bde140be733c4cf5425fc1aab161c4
 b75253ba55] better. I'll find some time to look at it. Maybe arlolra or
 someone else can look too. My time for this is very very limited but I am
 excited about the AMP Cache development.

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

Re: [tor-bugs] #25144 [Metrics/Statistics]: op-us onionperf instance spends much of its time at 100% timeout failure: why?

[Tor Bug Tracker & Wiki]

#25144: op-us onionperf instance spends much of its time at 100% timeout 
failure:
why?
+--
 Reporter:  arma|  Owner:  metrics-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by cypherpunks):

 op-us is on a streak of timeouts again that started on April 19, 2018
 through the latest data point, a running total of 21 days and going.

 https://metrics.torproject.org/torperf-
 failures.html?start=2018-04-12&end=2018-05-12&source=op-
 us&server=public&filesize=50kb

 op-hk and op-nl are experiencing spikes at the same time but not
 constantly like op-us is.

 Days before that started, the number of bridges fell quickly on April 15
 and 16:
 - https://metrics.torproject.org/bridges-
 ipv6.html?start=2018-04-12&end=2018-04-19
 -
 https://metrics.torproject.org/networksize.html?start=2018-04-01&end=2018-05-01
 The loss of bridges might be explained by Google and Amazon stopping
 domain fronting on April 13 (#25804) and announcing it the week of April
 23 (https://signal.org/blog/looking-back-on-the-front/ ) respectively.
 The working idea is that their decision is a result of a Russian court
 banning Telegram messenger on April 13 and the collateral damage from the
 ensuing cat-and-mouse game between Telegram servers and Roskomnadzor, the
 Russian internet censorship body, blocking IP subnets.

 However, the sudden loss of bridges might not be related to the timeouts
 of op-us starting April 19.  The wiki:doc/MetricsTimeline hasn't been
 updated with clues either.

 According to #21653 and wiki:org/operations/services/onionperf, op-us is
 in Washington, DC at https://op-us.onionperf.torproject.net/ and
 https://199.119.112.144, Allied Telecom Group, LLC, Radio Free Asia, not
 at Google, Amazon, or Azure.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26086 [- Select a component]: Please make P.T. the baseline to hinder petty despots and save lives

[Tor Bug Tracker & Wiki]

#26086: Please make P.T. the baseline to hinder petty despots and save lives
--+--
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Very High |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Critical  |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Even obfs4 is broken to the NSA; therefore, how does using it as the
 minimum baseline expose the Tor Project to legal issues such as
 accusations of violating CALEA or hindering BULLRUN? If making a default
 password for public obfs4 bridges isn't feasible, please at least use
 obfs2 or something, rather than nothing. Doing so will save lives in
 brutal dictatorships that call for the execution of whistleblowers and
 order assassinations based on metadata. Some petty tyrannies such as in
 Egypt rely on C.O.T.S. (e.g. Finfisher/Eagle/etc.), which are less
 advanced than NSA spyware.

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

Re: [tor-bugs] #22079 [Community]: Community governance documents

[Tor Bug Tracker & Wiki]

#22079: Community governance documents
---+
 Reporter:  alison |  Owner:  alison
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Community  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by catalyst):

 Replying to [comment:4 alison]:
 > what happens when a councilmember resigns?
 [...]
 > maybe instead we should revise the CC guidelines to have a countback,
 which means filling vacancies with the person who received the next
 highest votes.
 I would suggest not doing a countback.  It's quite possible that people's
 opinions about candidates would have changed since the vote was taken,
 especially if significant time has passed.

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

Re: [tor-bugs] #22079 [Community]: Community governance documents

[Tor Bug Tracker & Wiki]

#22079: Community governance documents
---+
 Reporter:  alison |  Owner:  alison
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Community  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by arma):

 * status:  reopened => new


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

Re: [tor-bugs] #26076 [Core Tor/Tor]: AppVeyor CI: Tor didn't declare that there would be no encryption FAIL src/test/test_keygen.sh (exit status: 5)

[Tor Bug Tracker & Wiki]

#26076: AppVeyor CI: Tor didn't declare that there would be no encryption FAIL
src/test/test_keygen.sh (exit status: 5)
-+-
 Reporter:  saper|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Very Low |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, tor-testing, 034-roadmap-|  Actual Points:
  subtask, 034-triage-20180328,  |
  034-included-20180328  |
Parent ID:  #25549   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by saper):

 Maybe we have some trouble creating reliable temporary directories? During
 https://ci.appveyor.com/project/torproject/tor/build/1.0.12 the first run
 completed, but for the second we get "Tor didn't declare that there would
 be no encryption" which happens when the data directory and the keys
 folder do already exist. (Just a guess).

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

Re: [tor-bugs] #15260 [Core Tor/Stem]: Banner for tutorials

[Tor Bug Tracker & Wiki]

#15260: Banner for tutorials
---+--
 Reporter:  atagar |  Owner:  atagar
 Type:  enhancement| Status:  reopened
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  website easy   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by atagar):

 * keywords:   => website easy
 * status:  closed => reopened
 * resolution:  fixed =>


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

Re: [tor-bugs] #22079 [Community]: Community governance documents

[Tor Bug Tracker & Wiki]

#22079: Community governance documents
---+--
 Reporter:  alison |  Owner:  alison
 Type:  project| Status:  reopened
 Priority:  Medium |  Milestone:
Component:  Community  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by atagar):

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


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

Re: [tor-bugs] #25985 [Obfuscation/Snowflake]: Add AMP cache as another domain fronting option with Google

[Tor Bug Tracker & Wiki]

#25985: Add AMP cache as another domain fronting option with Google
---+--
 Reporter:  twim   |  Owner:  (none)
 Type:  project| Status:  reopened
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by dcf):

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


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

Re: [tor-bugs] #25985 [Obfuscation/Snowflake]: Add AMP cache as another domain fronting option with Google

[Tor Bug Tracker & Wiki]

#25985: Add AMP cache as another domain fronting option with Google
---+--
 Reporter:  twim   |  Owner:  (none)
 Type:  project| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by dcf):

 * status:  reopened => needs_review


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

Re: [tor-bugs] #25750 [Applications/Tor Launcher]: update Tor Launcher for ESR 60

[Tor Bug Tracker & Wiki]

#25750: update Tor Launcher for ESR 60
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:
|  needs_revision
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201805  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by sysrqb):

 Replying to [comment:20 mcs]:
 > Replying to [comment:19 igt0]:
 > > I took a quick look in the code and I have a question about
 d104e7ecd35b2dbd38cdc9988fbd5924857d857d, does it load all the default
 properties every time the browser is restarted?
 >
 > Yes, I think so. Do you think that is a problem? I suspect that is what
 the code that Mozilla removed did too.

 Yes, that was my understanding.

 >
 > If addressing this for Torbutton is really messy, maybe we should put
 more effort into reverting the Mozilla patch that removed support for
 default preferences (doing so would fix #26039 as well). But I defer to
 Matt who already tried that approach.

 Basically, after Mozilla removed this functionality, they simplified the
 remaining code (inlining other functions because now they only have a
 single call site, deleting and refactoring other functions). From what I
 saw, as I began reverting the commit and integrating the code into the
 current logic, it was a bit complicated - so I decided implementing the
 loading in the extension was much, much easier.

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

Re: [tor-bugs] #25750 [Applications/Tor Launcher]: update Tor Launcher for ESR 60

[Tor Bug Tracker & Wiki]

#25750: update Tor Launcher for ESR 60
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:
|  needs_revision
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201805  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by sysrqb):

 Replying to [comment:18 mcs]:
 > Replying to [comment:17 sysrqb]:
 [snip]
 >
 > Here are a few general comments I should have made earlier (sorry!):
 > * Please wrap lines before 80 columns when possible.
 > * Please follow the brace style used in the files (different than what
 Mozilla uses, but mixing at this point could cause confusion).
 > * Please update the copyright year near the top of the files that you
 modify.

 All done, thanks for catching those.

 >
 [snip]
 > > This was a little tricky because torlauncher uses preferences very
 early in its initialization (such as initializing the TorLauncherLogger
 module). As a result, I moved loading the prefs into the TorProcessService
 constructor. In addition, now an exception is thrown if certain methods
 are called before we load the default prefs (get{Bool,Int,Char}Pref(),
 TorStartAndControlTor(), etc).
 > >
 > > I think we want Tor Browser to fail closed in these situations.
 Further, I think we want Tor Browser failing closed if any of the
 TorLauncher default prefs are invalid or aren't set for any reason.
 >
 > You are right — this is tricky.  Thanks for your work on it. Kathy and I
 think what you did is good, but we would rather not throw exceptions from
 the get...Pref() functions. Callers all pass a default default anyway, and
 may not handle exceptions well. Plus, in our testing, the exception you
 added to the `TorProcessService` constructor effectively disables Tor
 Launcher.

 The problem I see with relying on the default value passed into
 get...Pref() is they aren't always the same as the default value in
 prefs.js. One obvious answer is "then we should make sure they stay
 synchronized", but that comes with other problems.

 And, indeed, TorLauncher throwing the exception (and nothing catching it)
 has exactly the result we want. By this, I mean it "disables Tor Launcher"
 and Tor Browser fails closed (assuming there aren't any proxy-bypass
 vulns, etc). We should have a better user experience in this situation,
 but I'm not sure how we should do that yet.

 I deleted the exception throw in the `get...Pref()` methods, as you
 suggested.

 > A bonus is that we should be able to use the logging module inside
 `loadDefaultPreferences()` and related code.
 >

 Yes, that would be a bonus, but that is difficult to do correctly without
 moving around more logic because there's a cyclic dependency here. Within
 `TLLoggerInternal._init()` we get the default prefs for `LogLevel` and
 `LogMethod`. If we want logging capability while we load the default prefs
 then we must initialize `TLLoggerInternal` first.

 I decided against moving around the code, and instead I left the
 `getIntPref()` calls as-is. This means the log level and log method are
 not set by the prefs.js value.

 >
 > > > 6) For d1efcd33ca6389479337f70a603c73c8264888b8:
 > > > * Mozilla now uses Services.intl.DateTimeFormat(). We should too.
 See: https://hg.mozilla.org/releases/mozilla-beta/rev/650bd331efd0
 > > > * I don't think we should add a blank line after this one:
 > > >   let fracSecsStr = ...
 > > > (that declaration is tied to the `for` loop that follows immediately
 after).
 >
 > While testing that code inside a browser built with Arthur's `25543+10`
 branch from #25543, we found that we had to make two changes:
 > * Add `Cu.import("resource://gre/modules/Services.jsm");`
 > * Change to `const dateTimeFormatter = new
 Services.intl.DateTimeFormat(undefined, {`
 > (the second change is necessary because of
 https://hg.mozilla.org/releases/mozilla-
 beta/diff/94788650b26b/browser/base/content/pageinfo/pageInfo.js)
 >
 > BUT: the date format generated by the new code is a lot different than
 what we had before. Can you see if we can maintain the same format?
 > Old: `5/9/18, 21:06:51.000 [NOTICE] Bootstrapped 100%: Done`
 > New: `May 9, 2018 at 9:06:17 PM UTC.323 [NOTICE] Bootstrapped 100%:
 Done`
 >

 Ah, good catch. I...missed that. The problem here is Firefox now formats
 the date/time according to the configured locale. We do have the option of
 hard coding the date/time format, but that is not the direction Mozilla
 are going in with respect to handling date/time format.

 > Finally, please let us k

Re: [tor-bugs] #15260 [Core Tor/Stem]: Banner for tutorials

[Tor Bug Tracker & Wiki]

#15260: Banner for tutorials
---+
 Reporter:  atagar |  Owner:  atagar
 Type:  enhancement| Status:  closed
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by cypherpunks):

 * keywords:  website easy =>
 * status:  new => closed
 * resolution:   => fixed


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

Re: [tor-bugs] #22079 [Community]: Community governance documents

[Tor Bug Tracker & Wiki]

#22079: Community governance documents
---+-
 Reporter:  alison |  Owner:  alison
 Type:  project| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Community  |Version:
 Severity:  Normal | Resolution:  wontfix
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by cypherpunks):

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


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

Re: [tor-bugs] #25985 [Obfuscation/Snowflake]: Add AMP cache as another domain fronting option with Google

[Tor Bug Tracker & Wiki]

#25985: Add AMP cache as another domain fronting option with Google
---+
 Reporter:  twim   |  Owner:  (none)
 Type:  project| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by cypherpunks):

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


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

Re: [tor-bugs] #26079 [Metrics/Relay Search]: Expand text for Unmeasured flag to explain it can happen to older relays too

[Tor Bug Tracker & Wiki]

#26079: Expand text for Unmeasured flag to explain it can happen to older relays
too
--+---
 Reporter:  irl   |  Owner:  irl
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by cypherpunks):

 * status:  accepted => needs_information


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

Re: [tor-bugs] #26080 [Applications/Tor Browser]: torbrowser 7.5.4 update seems to generate file with unique uuid in it

[Tor Bug Tracker & Wiki]

#26080: torbrowser 7.5.4 update seems to generate file with unique uuid in it
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

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


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

Re: [tor-bugs] #18361 [Applications/Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  1000 light years
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * status:  reopened => needs_review


Comment:

 All of you must submit to Google and also Cloudflare!!

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

Re: [tor-bugs] #23840 [Community/Tor Support]: Google's reCAPTCHA fails 100%

[Tor Bug Tracker & Wiki]

#23840: Google's reCAPTCHA fails 100%
+-
 Reporter:  cypherpunks |  Owner:  hiro
 Type:  defect  | Status:  closed
 Priority:  Immediate   |  Milestone:
Component:  Community/Tor Support   |Version:
 Severity:  Blocker | Resolution:  wontfix
 Keywords:  cloudflare,google,captcha,noscript  |  Actual Points:
Parent ID:  #18361  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by cypherpunks):

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


Comment:

 Become a bot to solve the captcha automatically

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

Re: [tor-bugs] #24321 [Applications/Tor Browser]: Include Cloudflare's Official "Privacy Pass" addon to end Cloudflare captcha madness!

[Tor Bug Tracker & Wiki]

#24321: Include Cloudflare's Official "Privacy Pass" addon to end Cloudflare
captcha madness!
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  closed
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:  cloudflare,mitm   |  Actual Points:
Parent ID:  #18361| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

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


Comment:

 Who cares?

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

Re: [tor-bugs] #23141 [Applications/Tor Browser]: Cloudflare breaks loading the chat on http://www.goftesh.com/

[Tor Bug Tracker & Wiki]

#23141: Cloudflare breaks loading the chat on http://www.goftesh.com/
--+---
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:  cloudflare,mitm   |  Actual Points:
Parent ID:  #18361| Points:
 Reviewer:|Sponsor:
--+---
Changes (by cypherpunks):

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


Comment:

 http://www.goftesh.com/ is not loading anymore.

 Yell to website owner.

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

Re: [tor-bugs] #22582 [Applications/Tor Browser]: www.nexusmods.com not working properly in TOR

[Tor Bug Tracker & Wiki]

#22582: www.nexusmods.com not working properly in TOR
---+---
 Reporter:  WalrusInAnus   |  Owner:  tbb-team
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
   |  worksforme
 Keywords:  tbb-usability-website, cloudflare  |  Actual Points:
Parent ID:  #18361 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by cypherpunks):

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


Comment:

 works for 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] #24351 [Applications/Tor Browser]: Block Global Active Adversary Cloudflare

[Tor Bug Tracker & Wiki]

#24351: Block Global Active Adversary Cloudflare
-+-
 Reporter:  nullius  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:  user
 Keywords:  security, privacy, anonymity, mitm,  |  disappeared
  cloudflare |  Actual Points:
Parent ID:  #18361   | Points:  1000
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

 * status:  reopened => closed
 * resolution:   => user disappeared


Comment:

 Piece of shit ticket and useless add-on. Nullius is dead

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

Re: [tor-bugs] #26083 [Obfuscation/Obfsproxy]: Bridge detector. Fake?

[Tor Bug Tracker & Wiki]

#26083: Bridge detector. Fake?
---+-
 Reporter:  cypherpunks|  Owner:  cypherpunks
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Obfsproxy  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by cypherpunks):

 * Attachment "link.txt" added.

 link to code

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

Re: [tor-bugs] #25651 [Core Tor/Tor]: Handle incoming extend2/extended2 fragmented requests/replies. (prop249)

[Tor Bug Tracker & Wiki]

#25651: Handle incoming extend2/extended2 fragmented requests/replies. (prop249)
-+-
 Reporter:  nickm|  Owner:  isis
 Type:  enhancement  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-cell, tor-circuit, trunnel, 034  |  Actual Points:
  -roadmap-subtask, 034-triage-20180328, |
  034-included-20180328  |
Parent ID:  #24986   | Points:  3
 Reviewer:   |Sponsor:
 |  SponsorM-can
-+-
Changes (by isis):

 * milestone:  Tor: 0.3.4.x-final => Tor: 0.3.5.x-final


Comment:

 I've made progress on this in my `bug25651` WIP branch, but there's not
 much point trying to rush this into 034, since a bunch of the other #24986
 child tickets have been deferred to 035.

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

Re: [tor-bugs] #24990 [Core Tor/Tor]: Write a proposal for a post-quantum lattice KEX

[Tor Bug Tracker & Wiki]

#24990: Write a proposal for a post-quantum lattice KEX
-+-
 Reporter:  isis |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  proposal cryptography post-quantum   |  Actual Points:
  needs-proposal 035-roadmap-proposed|
Parent ID:  #24985   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor3
-+-
Changes (by nickm):

 * milestone:   => Tor: unspecified


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

Re: [tor-bugs] #25942 [Core Tor/Tor]: Fix win32 test failure for crypto/openssl_version

[Tor Bug Tracker & Wiki]

#25942: Fix win32 test failure for crypto/openssl_version
+--
 Reporter:  isis|  Owner:  (none)
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.4.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.3.3.5-rc
 Severity:  Normal  | Resolution:
 Keywords:  tor-ci tor-windows tor-testing  |  Actual Points:
Parent ID:  #25549  | Points:  1
 Reviewer:  |Sponsor:
+--

Comment (by nickm):

 I think I'm supposed to wait on this one until the parent ticket is ready
 -- but please let me know if I'm wrong about that.

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

Re: [tor-bugs] #25654 [Core Tor/Tor]: Create a testing-only handshake for shaking the bugs out of wide create cells (prop249)

[Tor Bug Tracker & Wiki]

#25654: Create a testing-only handshake for shaking the bugs out of wide create
cells (prop249)
-+-
 Reporter:  nickm|  Owner:  isis
 Type:  enhancement  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-cell, tor-circuit, trunnel, 034  |  Actual Points:
  -roadmap-subtask, 034-triage-20180328, |
  034-included-20180328  |
Parent ID:  #24986   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by isis):

 * milestone:  Tor: 0.3.4.x-final => Tor: 0.3.5.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] #25942 [Core Tor/Tor]: Fix win32 test failure for crypto/openssl_version

[Tor Bug Tracker & Wiki]

#25942: Fix win32 test failure for crypto/openssl_version
+--
 Reporter:  isis|  Owner:  (none)
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.4.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.3.3.5-rc
 Severity:  Normal  | Resolution:
 Keywords:  tor-ci tor-windows tor-testing  |  Actual Points:
Parent ID:  #25549  | Points:  1
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

 * milestone:   => Tor: 0.3.4.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] #25654 [Core Tor/Tor]: Create a testing-only handshake for shaking the bugs out of wide create cells (prop249)

[Tor Bug Tracker & Wiki]

#25654: Create a testing-only handshake for shaking the bugs out of wide create
cells (prop249)
-+-
 Reporter:  nickm|  Owner:  isis
 Type:  enhancement  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-cell, tor-circuit, trunnel, 034  |  Actual Points:
  -roadmap-subtask, 034-triage-20180328, |
  034-included-20180328  |
Parent ID:  #24986   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by isis):

 * type:  defect => enhancement


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

Re: [tor-bugs] #25139 [Core Tor/Tor]: Link protocol negotiation without common version

[Tor Bug Tracker & Wiki]

#25139: Link protocol negotiation without common version
---+---
 Reporter:  atagar |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Low|  Milestone:  Tor:
   |  0.3.5.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Minor  | Resolution:
 Keywords:  spec-compliance protocol easy  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * keywords:   => spec-compliance protocol easy
 * milestone:   => Tor: 0.3.5.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] #24619 [Core Tor/Tor]: Tor 0.3.1.9 exited unexpectedly on Windows

[Tor Bug Tracker & Wiki]

#24619: Tor 0.3.1.9 exited unexpectedly on Windows
--+--
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.9
 Severity:  Major | Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * milestone:   => Tor: unspecified


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

Re: [tor-bugs] #24990 [Core Tor/Tor]: Write a proposal for a post-quantum lattice KEX

[Tor Bug Tracker & Wiki]

#24990: Write a proposal for a post-quantum lattice KEX
-+-
 Reporter:  isis |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  proposal cryptography post-quantum   |  Actual Points:
  needs-proposal 035-roadmap-proposed|
Parent ID:  #24985   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor3
-+-
Changes (by nickm):

 * keywords:  proposal cryptography post-quantum => proposal cryptography
 post-quantum needs-proposal 035-roadmap-proposed


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

Re: [tor-bugs] #25573 [Core Tor/Tor]: Create a RELAY_COMMAND_END_ACK cell type

[Tor Bug Tracker & Wiki]

#25573: Create a RELAY_COMMAND_END_ACK cell type
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery-stats 035-roadmap-   |  Actual Points:
  proposed needs-proposal|
Parent ID:  #25574   | Points:
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-
Changes (by nickm):

 * keywords:  guard-discovery-stats => guard-discovery-stats 035-roadmap-
 proposed needs-proposal
 * milestone:   => Tor: unspecified


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

Re: [tor-bugs] #25756 [Core Tor/Tor]: EARLY_CONSENSUS_NOTICE_SKEW of 60 is too strict for some drifting dirauth clocks

[Tor Bug Tracker & Wiki]

#25756: EARLY_CONSENSUS_NOTICE_SKEW of 60 is too strict for some drifting 
dirauth
clocks
-+-
 Reporter:  Dbryrtfbcbhgf|  Owner:
 |  catalyst
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.25-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  clock-skew, s8-errors, 034-roadmap-  |  Actual Points:
  proposed   |
Parent ID:   | Points:
 Reviewer:  isis |Sponsor:
 |  Sponsor8-can
-+-
Changes (by nickm):

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


Comment:

 Merging!

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

Re: [tor-bugs] #25939 [Core Tor/Tor]: A Tor commit seems to have broken creation of V3 onion services with stem

[Tor Bug Tracker & Wiki]

#25939: A Tor commit seems to have broken creation of V3 onion services with 
stem
+--
 Reporter:  maqp|  Owner:  dgoulet
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:  Tor:
|  0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Major   | Resolution:
 Keywords:  034-must regression tor-hs  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:  Sponsor8
+--

Comment (by maqp):

 Atagar: Just confirming we get the same error message.

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

Re: [tor-bugs] #22685 [Core Tor/Tor]: policy for acceptable licenses from contributors

[Tor Bug Tracker & Wiki]

#22685: policy for acceptable licenses from contributors
-+-
 Reporter:  catalyst |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-triage-20180328, 034-must,   |  implemented
  policy |  Actual Points:
Parent ID:  #26085   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Parent merged to master.

 IMO a license rationale is out of scope for this ticket: I also like 3BSD
 for Tor, but not necessarily for the same reasons anybody else does. :)

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

Re: [tor-bugs] #26085 [Core Tor/Tor]: Add a "CONTRIBUTING" file

[Tor Bug Tracker & Wiki]

#26085: Add a "CONTRIBUTING" file
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 okay, merged to master, and URL tweaked!

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

Re: [tor-bugs] #25985 [Obfuscation/Snowflake]: Add AMP cache as another domain fronting option with Google

[Tor Bug Tracker & Wiki]

#25985: Add AMP cache as another domain fronting option with Google
---+
 Reporter:  twim   |  Owner:  (none)
 Type:  project| Status:  needs_revision
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by twim):

 Replying to [comment:16 dcf]:
 > I've only taken a quick look. Here is some preliminary feedback.
 Thanks for the feedback!
 >  * Changing POST to use only status code 200 breaks backward
 compatibility. I'm opposed to this change. At any rate, it would require
 matching changes in /proxy and /proxy-go. But it's better to remain
 compatible.
 >  * Try to minimize the extent of changes. This ticket shouldn't require
 any changes to `clientOffers`, so I'm skeptical if I see any changes
 there. Don't worry about code duplication. Go ahead and write duplicative
 code. If needed, we can deduplicate in a refactoring. I expect that the
 new feature in the broker will require 1 or 2 new functions and one new
 line in `main`. It's fine if AMP uses JSON and POST does not. If there are
 code architecture changes they need to be in a separate commit from the
 functional changes.

 The point was to retain some of backward compatibility so old clients are
 able to connect to a broker.
 I've added status codes back.


 >  * I'd prefer not to depend on an external amper, if we can reasonably
 include the necessary code here.
 I think it's better to move codec logic out out the scope of snowflake
 itself. In case of amper the library handles domain fronting (which is not
 typical), adding padding and other. Anyway I just don't see the point of
 copy-pasting code if we can just vendor it.

 >  * `-codec=post` and `-codec=amp` is a nice idea. The `-help` hint
 should list all the possible values.
 Fixed.

 >  *
 
[https://github.com/nogoegst/snowflake/commit/ce1e2e24d9bd39ad51c82006213dc7a1f1e4776f
 #diff-f9646f10eb8f3471d08ae2de44a3eaf9R100 BrokerChannel.RoundTrip]: it
 seems like this `switch` would be better done in `main` by setting a
 function pointer on `bc`. (Should fail immediately in `main` if the
 command line is bad.)

 Command line should check these values if it needs to. The thing here is
 that this function pointers are messy and are being created in init
 function while the they do depend on BrokerContext state.

 >  *
 
[https://github.com/nogoegst/snowflake/commit/ce1e2e24d9bd39ad51c82006213dc7a1f1e4776f
 #diff-79897051d7aac1f314600a930afebe9aR275 In the "/client/amp/" path],
 I'm not sure if a trailing slash is significant, but all the entries
 should either have a trailing slash or not have one.

 This is just how it works. '/client' handles only this exact path, while
 '/client/amp/' handles everything with this prefix and sets up a redirect
 from '/client/amp/' to '/client/amp/'.

 >  * Is it possible to avoid the vendoring changes, or at least get them
 in separate commits so they're separable from the functional changes?

 Right, I decided to leave vendoring for another ticket.

 > The biggest thing for me is to avoid making unnecessary code changes and
 to keep backward compatibility. If you absolutely need a refactoring
 change, you can do it as a separate commit preliminary to making your
 functional changes. It should be of a nature that we would want the
 refactoring even if we weren't going to add the AMP feature. But I feel
 it's less risky (= more likely to get the patch accepted) to add the new
 feature first, in a minimal patch with clearly defined boundaries, and
 then refactor later.

 It's not that much of refactoring though. I'm not liking idea of creating
 duplicate code and adding completely different code - it becomes
 unmaintainable pretty quickly and 'refactor later' never comes.

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

Re: [tor-bugs] #22079 [Community]: Community governance documents

[Tor Bug Tracker & Wiki]

#22079: Community governance documents
---+
 Reporter:  alison |  Owner:  alison
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Community  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by catalyst):

 Replying to [comment:13 atagar]:
 > Another thing that was mentioned on irc was to simplify the process of
 making small amendments. Maybe something similar to our membership
 addition policy (if nobody objects then it happens, otherwise it proceeds
 with a standard voting process).
 I added a patch with suggested changes for implementing a fast tracking
 process for proposals.

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

Re: [tor-bugs] #22079 [Community]: Community governance documents

[Tor Bug Tracker & Wiki]

#22079: Community governance documents
---+
 Reporter:  alison |  Owner:  alison
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Community  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by catalyst):

 * Attachment "0001-Fast-tracking-of-proposals.patch" 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] #25994 [Core Tor/Tor]: test_channel: keep time constant when running channel/outbound_cell

[Tor Bug Tracker & Wiki]

#25994: test_channel: keep time constant when running channel/outbound_cell
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-ci, tor-tests-coverage, tor- |  Actual Points:
  tests-unit |
Parent ID:  #25908   | Points:
 Reviewer:  mikeperry|Sponsor:
 |  Sponsor3-can
-+-
Changes (by nickm):

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


Comment:

 Per discussion on IRC, I'd rather not actually trigger ewma scaling code
 here, since it was only ever triggered by accident, and this test doesn't
 actually do anything to check it for correctness.

 > Otherwise, merge ready.

 Merging this to master.

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

Re: [tor-bugs] #21346 [Core Tor/Tor]: Clients with NoIPv4Traffic should only choose IPv6-supporting Exits

[Tor Bug Tracker & Wiki]

#21346: Clients with NoIPv4Traffic should only choose IPv6-supporting Exits
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, 031-deferred-20170425, |  Actual Points:
  032-unreached  |
Parent ID:  #21311   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  assigned => needs_review
 * milestone:  Tor: unspecified => Tor: 0.3.4.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] #26071 [Internal Services/Tor Sysadmin Team]: Please give Tommy LDAP access

[Tor Bug Tracker & Wiki]

#26071: Please give Tommy LDAP access
-+-
 Reporter:  phoul|  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 +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] #26083 [Obfuscation/Obfsproxy]: Bridge detector. Fake?

[Tor Bug Tracker & Wiki]

#26083: Bridge detector. Fake?
---+-
 Reporter:  cypherpunks|  Owner:  cypherpunks
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Obfsproxy  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by cypherpunks):

 [https://link.springer.com/article/10.1007/s11227-018-2268-y Real-time
 identification of three Tor pluggable transports using machine learning
 techniques]
 > We report an empirical study on detection of three widely used Tor
 pluggable transports, namely Obfs3, Obfs4, and ScrambleSuit using four
 learning algorithms. We investigate the performance of Adaboost and Random
 Forests as two ensemble methods. In addition, we study the effectiveness
 of SVM and C4.5 as well-known parametric and nonparametric classifiers.
 These algorithms use general statistics of first few packets of the
 inspected flows. Experimental results conducted on real traffics show that
 all the adopted algorithms can perfectly detect the desired traffics by
 only inspecting first 10–50 packets. The trained classifiers can readily
 be employed in modern network switches and intelligent traffic monitoring
 systems.
 > Computer Engineering Department Bu-Ali Sina University Hamedan Iran

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

Re: [tor-bugs] #1749 [Core Tor/Tor]: Split relay and link crypto across multiple CPU cores

[Tor Bug Tracker & Wiki]

#1749: Split relay and link crypto across multiple CPU cores
-+-
 Reporter:  nickm|  Owner:
 |  chelseakomlo
 Type:  project  | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, term-project-ideas,   |  Actual Points:
  threads, performance   |
Parent ID:   | Points:  10
 Reviewer:   |Sponsor:
-+-
Changes (by Samdney):

 * cc: Samdney (added)


Comment:

 Add me as observer. I already spend some time with this. Maybe I can 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] #13737 [Core Tor/Tor]: Move circuit building crypto to worker

[Tor Bug Tracker & Wiki]

#13737: Move circuit building crypto to worker
-+-
 Reporter:  dgoulet  |  Owner:  yawning
 Type:  enhancement  | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, tor-hs, multicore,   |  Actual Points:
  performance, tor-dos, term-project-ideas   |
  intro  |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
 |  SponsorU-can
-+-
Changes (by chelseakomlo):

 * cc: chelseakomlo (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] #22079 [Community]: Community governance documents

[Tor Bug Tracker & Wiki]

#22079: Community governance documents
---+
 Reporter:  alison |  Owner:  alison
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Community  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by arma):

 Another area we should clarify when we're doing a round of revisions for
 our policies:

 The community council election process uses our voting mechanism, and our
 voting mechanism includes a one week period post-vote where people can
 check that their votes were counted and raise the alarm if something went
 wrong. But the community council election process doesn't specify whether,
 when using the voting mechanism, it means to bring in all the other
 aspects of the voting mechanism like this one-week period.

 In my opinion if we're going to be using our voting mechanism for
 something, we need to include the one-week post-vote period too. But
 discussions with other Tor people indicate that understandings and
 expectations varied for this one. So we should make it more clear in the
 next round.

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

Re: [tor-bugs] #22079 [Community]: Community governance documents

[Tor Bug Tracker & Wiki]

#22079: Community governance documents
---+
 Reporter:  alison |  Owner:  alison
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Community  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by arma):

 Replying to [comment:20 catalyst]:
 > Replying to [comment:19 atagar]:
 > > Hi Roger. Sorry, not sure I follow. I read that as saying that
 enacting new policies needs a 2/3 super majority. As you cited those had
 options to reject the policy and keep the status quo.
 > I interpret it as enacting a policy effectively requires a 2/3
 supermajority if there is only one proposal (no alternatives) and no
 abstentions.  (Abstentions seem to have the interesting effect of diluting
 reject/no-action votes.)
 >
 > For the CoC/SoV votes, I would say the "take no action" alternative was
 the "b. I do not approve of the proposal." option.  Similarly, for the
 membership policy vote, I think the "take no action" option would have
 been "B. I reject the attached proposal."

 Yep, I agree with all of this. I think we should be aware of, and maybe
 help voters be aware of too, the fact that the "no" option in these votes
 only needs 1/3 of the votes to be the winner.

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

Re: [tor-bugs] #25994 [Core Tor/Tor]: test_channel: keep time constant when running channel/outbound_cell

[Tor Bug Tracker & Wiki]

#25994: test_channel: keep time constant when running channel/outbound_cell
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, tor-tests-coverage, tor- |  Actual Points:
  tests-unit |
Parent ID:  #25908   | Points:
 Reviewer:  mikeperry|Sponsor:
 |  Sponsor3-can
-+-
Changes (by mikeperry):

 * status:  needs_review => needs_information


Comment:

 This looks simple enough to me. One question though: why not roll time
 forward enough for scale_active_circuits() to get called, so that we at
 least verify that it does not interfere with cell delivery on the channel?
 Unless that doesn't make sense, and there is no possible way it could.

 Otherwise, merge ready.

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

Re: [tor-bugs] #26030 [Metrics/Website]: Delete "Tor Messenger downloads and updates" section

[Tor Bug Tracker & Wiki]

#26030: Delete "Tor Messenger downloads and updates" section
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by irl):

 * status:  needs_information => new


Comment:

 The ticket would be blocked by the remaining child ticket, but I think we
 should still keep this ticket open in case anybody would like to object,
 with some reasons we haven't thought of, to the removal of the page.

 Producing the final analysis is independent of that analysis being
 published, so these tasks shouldn't block on each other and should be done
 when it's easiest to do. This means there could be a gap between the final
 analysis being written and it being published.

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

Re: [tor-bugs] #26046 [Metrics/Website]: Add text to the Tor Messenger downloads page to explain it is no longer developed

[Tor Bug Tracker & Wiki]

#26046: Add text to the Tor Messenger downloads page to explain it is no longer
developed
-+--
 Reporter:  irl  |  Owner:  metrics-team
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #26030   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by irl):

 * status:  needs_review => merge_ready


Comment:

 This 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] #26035 [Metrics/Statistics]: Streamline sample quantile types used in the various modules

[Tor Bug Tracker & Wiki]

#26035: Streamline sample quantile types used in the various modules
+---
 Reporter:  karsten |  Owner:  iwakeh
 Type:  enhancement | Status:  accepted
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:  Sponsor13
+---

Comment (by iwakeh):

 This turned out to be longer than intended:

 a) ​Advertised bandwidth distribution:
  * With the notation in comment:1 the Java code uses essentially `result =
 val(floor((N-1)*percentile))` [https://gitweb.torproject.org/metrics-
 
web.git/tree/src/main/java/org/torproject/metrics/stats/advbwdist/Main.java#n124
 about here].
  * [https://gitweb.torproject.org/metrics-
 web.git/tree/src/main/R/advbwdist/aggregate.R#n13 R code] takes the median
 of the Java calculated percentiles.
 b) ​Advertised bandwidth of n-th fastest relays uses the resulting data
 from a).
 c) ​Fraction of connections used uni-/bidirectionally:
 [https://gitweb.torproject.org/metrics-
 
web.git/tree/src/main/java/org/torproject/metrics/stats/connbidirect/Main.java#n468
 Uses Java] and calculates `result = val(floor(N*percentile))` for the
 three percentiles .25, .5, and .75.
 d) ​Time to download files over Tor: uses percentile_cont
 e) ​Unique .onion addresses (version 2 only):
 [https://gitweb.torproject.org/metrics-
 
web.git/tree/src/main/java/org/torproject/metrics/stats/hidserv/Aggregator.java#n165
 The code] doesn't seem to calculate quartiles, rather checks that the
 interval is contained in the 25% to 75% interval of the fraction sum.
 Hmm, what am I missing here?
 f) Onion-service traffic (versions 2 and 3): same as e).

 In total, the Java calculations a) and c) use a discrete version of median
 calculation and differ in 'slight index shifting'.
 The calculations in e) and f) are not really 'quartiles'.
 The remaining calculations use R's median and postgresql percentile_cont,
 where R's standard median is calculated (in pseude code) as
 {{{
 #!C
 first = floor(percentile * N);
 second = ceil(percentile * N);
 /* if first==second the value of first is used. */
 if (first==second) {
   result = val(first);
 } else { /* if first and second differ, take the average. */
   result = val(first) + (0.5 * (val(second) - val(first)));
 }
 }}}

 So R's standard median is the same as 50%-percentile of type R-2 and also
 coincides with 50%-percentile of type R-7.

 There is a variety there.  The discrete types are easier to compute (when
 trying to reproduce the results for example).  Introducing the
 interpolation (or continuous) type in Java would mean to complicate the
 current code a little, but could be done w/o commons-math.
 Of course, the two calculations in a) and c) should be the same, but
 that's only a minor change and not related to the choice of percentile
 calculation.

 === I: R-1
 If we decide to use the discrete R-1 throughout.  If so, we'd need to
 * replace percentile_cont by percentile_dics, and
 * replace R's median function throughout by the 50%-percentile type R-1
 provided by utility function named `metricsmedian`.

 === II: R-7
 If we decide to use of the proportionate interpolation method R-7
 throughout, there are these work packages:

 * implement a simple utility interpolation function for Java (similar to
 postgresql's approach)
 * and make use of it in a) and c).
 * replace R's median function throughout by the 50%-percentile type R-7
 provided by  utility function named `metricsmedian`.


 In both cases the calculations e) and f) stay as they are, but need more
 documentation.


 
 PS: (Trucks often have a spare tire mounted somewhere, and in some
 countries they use three wheeled trucks ;-)

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

Re: [tor-bugs] #25756 [Core Tor/Tor]: EARLY_CONSENSUS_NOTICE_SKEW of 60 is too strict for some drifting dirauth clocks

[Tor Bug Tracker & Wiki]

#25756: EARLY_CONSENSUS_NOTICE_SKEW of 60 is too strict for some drifting 
dirauth
clocks
-+-
 Reporter:  Dbryrtfbcbhgf|  Owner:
 |  catalyst
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.25-alpha
 Severity:  Normal   | Resolution:
 Keywords:  clock-skew, s8-errors, 034-roadmap-  |  Actual Points:
  proposed   |
Parent ID:   | Points:
 Reviewer:  isis |Sponsor:
 |  Sponsor8-can
-+-
Changes (by isis):

 * status:  needs_review => merge_ready


Comment:

 Replying to [comment:20 catalyst]:
 > Patches at https://github.com/torproject/tor/pull/84
 >
 > The Travis failure is the existing Rust distcheck issue.

 LGTM!

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

Re: [tor-bugs] #24658 [Core Tor/Tor]: Split/refactor crypto.h into smaller separate modules

[Tor Bug Tracker & Wiki]

#24658: Split/refactor crypto.h into smaller separate modules
-+-
 Reporter:  isis |  Owner:
 |  ffmancera
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-crypto, refactor, review-|  Actual Points:
  group-32, review-group-34, |
  033-triage-20180320, 033-included-20180320 |
Parent ID:   | Points:
 Reviewer:  nickm, isis  |Sponsor:
 |  Sponsor8-can
-+-
Changes (by isis):

 * status:  needs_review => needs_revision


Comment:

 I've left my review [https://github.com/torproject/tor/pull/105 here].
 There's just a couple small changes that need to be addressed. For the
 moved code, I've verified it's identical using a mix between good ol'
 `diff` and `git show -p --color-moved`.

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

Re: [tor-bugs] #24763 [Core Tor/Tor]: Tor make check FAIL: src/test/test (on OSX)

[Tor Bug Tracker & Wiki]

#24763: Tor make check FAIL: src/test/test (on OSX)
-+-
 Reporter:  lL__ |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.13
 Severity:  Normal   | Resolution:  user
 Keywords:  tor, make, check, failed,|  disappeared
  034-triage-20180328|  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_information => closed
 * resolution:   => user disappeared


Comment:

 Please reopen this ticket if you can reproduce the bug and find a copy of
 your test-suite.log file to upload.

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

Re: [tor-bugs] #22685 [Core Tor/Tor]: policy for acceptable licenses from contributors

[Tor Bug Tracker & Wiki]

#22685: policy for acceptable licenses from contributors
-+-
 Reporter:  catalyst |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-triage-20180328, 034-must,   |  Actual Points:
  policy |
Parent ID:  #26085   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 I think the parent (#26085) will do what this ticket is wanting.

 As for the rationale for why we chose 3-clause bsd: in my opinion there
 are two scenarios that free software licenses are helpful for: (1) if
 there are no tools that do what you want, and your goal is to maximize the
 chances that some tool comes into existence to do what you want, use
 3-clause bsd. Whereas (2) if the world already has some tools that do what
 you want, and your goal is to maximize the chances that the best one is
 free software, use gpl.

 Our general outlook for Tor is that we're still in scenario one: our
 world's main challenge is that there aren't enough tools for good metadata
 security, full stop, rather than that there are some tools for good
 metadata security but the best ones aren't free.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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: #2149, #10059, #24586, #24986, ...

[Tor Bug Tracker & Wiki]

Batch modification to #2149, #10059, #24586, #24986, #25493, #25648, #25649, 
#25650, #25652, #25653, #25655, #25656, #25657 by nickm:
type to enhancement
milestone to Tor: 0.3.5.x-final

Comment:
These are still worth doing, but I don't see them as likely to happen before 
our freeze in 4 days, and nobody is currently assigned to them. Deferring them 
to 0.3.5

--
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] #17949 [Core Tor/Tor]: Make loopback address search more accurate

[Tor Bug Tracker & Wiki]

#17949: Make loopback address search more accurate
-+-
 Reporter:  teor |  Owner:  rl1987
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy tor-client tor-relay loopback   |  Actual Points:
  weird-configuration|
Parent ID:  #17991   | Points:
 Reviewer:  ahf, teor, isis  |Sponsor:
-+-
Changes (by isis):

 * status:  needs_review => merge_ready


Comment:

 Let a review on the ticket, it mostly LGTM but there's one commit with
 some cross platform specific stuff (0b121a10) that I'm not sure I fully
 understand.

 Tentatively setting as merge_ready if ahf and teor agree.

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

Re: [tor-bugs] #26085 [Core Tor/Tor]: Add a "CONTRIBUTING" file

[Tor Bug Tracker & Wiki]

#26085: Add a "CONTRIBUTING" file
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Looks good to me!

 (A tiny change I would suggest, or just fix myself later on, is to remove
 the ".html.en" the volunteer url. That way if we ever resume doing
 translations in the future, readers can get whichever language their
 browser is configured to ask for.)

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

Re: [tor-bugs] #25061 [Core Tor/Tor]: Relays consider it a bootstrapping failure if they can't extend for somebody else's circuit

[Tor Bug Tracker & Wiki]

#25061: Relays consider it a bootstrapping failure if they can't extend for
somebody else's circuit
-+-
 Reporter:  arma |  Owner:
 |  catalyst
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  backport-032, 033-backport,  |  Actual Points:
  stability, 033-triage-20180320,|
  033-included-20180320, s8-errors, bootstrap|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by catalyst):

 There are four places that call control_event_bootstrap_prob_or():

 * `connection_or_about_to_close()` in connection_or.c
 - This seems to have a fair amount of code in the TLS handshake
   failure case, which could probably be factored out.  It also
   calls channel_closed() before any of the other stuff, which
   maybe should be reordered?
 - It's only really called through connection_unlink() in main.c.

 * `connection_or_connect_failed()` in connection_or.c
 - This fairly simple function has multiple callers

 * `connection_or_connect()` in connection_or.c
 - This seems to only handle the case where a PT proxy is missing.
   Notably, it does NOT call `authdir_mode_tests_reachability()`.

 * `connection_or_client_learned_peer_id()` in connection_or.c
 - This seems to be when a router cert has an unexpected ID.

 I'm thinking of ways to move the logic that currently calls
 `control_event_bootstrap_prob_or()` into either the channel layer or even
 higher.  I think having the callers of `control_event_bootstrap_prob_or()`
 call `authdir_mode_tests_reachability()` themselves is unnecessary when
 `control_event_bootstrap_prob_or()` itself could probably safely do so.
 (The one case above where the caller doesn't call
 `authdir_mode_tests_reachability()` is a pluggable transport situation,
 and dirauths don't use pluggable transports that I know of.)

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

Re: [tor-bugs] #17949 [Core Tor/Tor]: Make loopback address search more accurate

[Tor Bug Tracker & Wiki]

#17949: Make loopback address search more accurate
-+-
 Reporter:  teor |  Owner:  rl1987
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy tor-client tor-relay loopback   |  Actual Points:
  weird-configuration|
Parent ID:  #17991   | Points:
 Reviewer:  ahf, teor, isis  |Sponsor:
-+-

Comment (by isis):

 @rl1987 Where did ahf's original review go?

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

Re: [tor-bugs] #25794 [Applications/Tor Browser]: Sanitize PointerEvent

[Tor Bug Tracker & Wiki]

#25794: Sanitize PointerEvent
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff60-esr, tbb-fingerprinting  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Description changed by arthuredelstein:

Old description:

> Simon alerted me to the fact that PointerEvents have been enabled in
> Firefox 59 (ttps://bugzilla.mozilla.org/show_bug.cgi?id=1411467). We
> should sanitize events these under privacy.resistFingerprinting = true.
>
> https://developer.mozilla.org/en-US/docs/Web/API/Pointer_events

New description:

 Simon alerted me to the fact that PointerEvents have been enabled in
 Firefox 59 (https://bugzilla.mozilla.org/show_bug.cgi?id=1411467). We
 should sanitize events these under privacy.resistFingerprinting = true.

 https://developer.mozilla.org/en-US/docs/Web/API/Pointer_events

--

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

Re: [tor-bugs] #22685 [Core Tor/Tor]: policy for acceptable licenses from contributors

[Tor Bug Tracker & Wiki]

#22685: policy for acceptable licenses from contributors
-+-
 Reporter:  catalyst |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-triage-20180328, 034-must,   |  Actual Points:
  policy |
Parent ID:  #26085   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  accepted => needs_review


Comment:

 Parent is now in needs_review

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

Re: [tor-bugs] #26085 [Core Tor/Tor]: Add a "CONTRIBUTING" file

[Tor Bug Tracker & Wiki]

#26085: Add a "CONTRIBUTING" file
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  new => needs_review


Comment:

 See my branch `contributing`.

 I realize that I am touching on bikeshed issues here, so let's try to get
 something good enough merged, and defer perfection until later.

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

Re: [tor-bugs] #26083 [Obfuscation/Obfsproxy]: Bridge detector. Fake?

[Tor Bug Tracker & Wiki]

#26083: Bridge detector. Fake?
---+-
 Reporter:  cypherpunks|  Owner:  cypherpunks
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Obfsproxy  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by cypherpunks):

 [https://citizenlab.ca/wp-content/uploads/2018/04/PLANET-NETSWEEPER_-
 FILTERING-PROCESS-1.jpg How it works]

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

Re: [tor-bugs] #22685 [Core Tor/Tor]: policy for acceptable licenses from contributors

[Tor Bug Tracker & Wiki]

#22685: policy for acceptable licenses from contributors
-+-
 Reporter:  catalyst |  Owner:  nickm
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-triage-20180328, 034-must,   |  Actual Points:
  policy |
Parent ID:  #26085   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * parent:   => #26085


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26085 [Core Tor/Tor]: Add a "CONTRIBUTING" file

[Tor Bug Tracker & Wiki]

#26085: Add a "CONTRIBUTING" file
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Github expects there to be a top-level file named "CONTRIBUTING" or
 "CONTRIBUTING.md" with instructions on how to get started.  We should
 create such a file, and have it send new developers to our documentation.

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

Re: [tor-bugs] #25903 [Core Tor/Tor]: Add OVERHEAD and DELIVERED fields to CIRC_BW events

[Tor Bug Tracker & Wiki]

#25903: Add OVERHEAD and DELIVERED fields to CIRC_BW events
--+
 Reporter:  mikeperry |  Owner:  mikeperry
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  034-roadmap-proposed  |  Actual Points:
Parent ID:  #25546| Points:
 Reviewer:  isis  |Sponsor:
--+
Changes (by mikeperry):

 * status:  needs_information => needs_review


Comment:

 Ok nickm says:
 {{{
 16:52 <+nickm> mikeperry: are you asking about wide-create stuff?
 16:52 <+nickm> that doesn't affect relay payload sizes; they remain the
 same as before
 }}}

 This makes sense. It isn't the relay payload size that will change with
 wide creates. You simply have the ability to split a create over multiple
 relay cells, whose payload body max will still be RELAY_PAYLOAD_SIZE.

 So this code will continue to work correctly in that case, properly
 measuring overhead and delivered data.

 Setting to needs_review in case you have other issues. If not, please set
 to merge_ready.

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

Re: [tor-bugs] #25694 [Applications/Tor Browser]: Activity 3.1: Improve the user experience of updating Tor Browser

[Tor Bug Tracker & Wiki]

#25694: Activity 3.1: Improve the user experience of updating Tor Browser
--+---
 Reporter:  isabela   |  Owner:  antonela
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor17
--+---

Comment (by antonela):

 As was decided at last meeting, I have been working with FF60 UI/UX

 So far, we have this user flow once TB opens

 https://trac.torproject.org/projects/tor/attachment/ticket/25694/25694-2.png

 We also discussed to remove the 'Never check for updates' and 'Check for
 updates but let you choose to install them' user options in
 `about:preferences`. In that case, the user flow is going to look like

 https://trac.torproject.org/projects/tor/attachment/ticket/25694/25694-3.png

 Considerations using FF60 Update flow

 **Tor Browser is Outdated**

 When Tor Browser tells to users that an update is available and users
 delay the restart by clicking [not now], I propose to:
 1. load a new tab with 1.0 and keep the red restart notification at the
 Menu button OR
 2. keep the red dot at the Menu button without load a new tab.

 If we will keep the notification at the Menu button, what does happen when
 the user wants to open the menu? Has FF60 a kind of notification bar as we
 have now?

 https://trac.torproject.org/projects/tor/attachment/ticket/25694/TTB-
 restart-menu.png

 If not, could the warning notification bubble be placed at the Tor Button?
 Could we have a notification banner like the menu button have right now
 but at the Tor Button Menu? If you think this is the way, I'll mockup it.

 **Downloading Package Feedback**

 Check
 
[1.1](https://trac.torproject.org/projects/tor/attachment/ticket/25694/1.1.2.png)
 and
 
[1.1.2](https://trac.torproject.org/projects/tor/attachment/ticket/25694/1.1.3.png).
 We can use the same doorhanger to keep the activity on the same side of
 the window and use the Download icon to illustrate what is happening under
 the hoods.

 This proposal is useful because we are using a default browser behavior
 for downloading so users can easily identify that a download is
 progressing. Right after it finishes, we should open the Menu icon's
 doorhanger like img 1.2. I made two options:
 
[1.2A](https://trac.torproject.org/projects/tor/attachment/ticket/25694/1.2A.png)
 and
 
[1.2B](https://trac.torproject.org/projects/tor/attachment/ticket/25694/1.2B.png).

 Another option could be using the same icon we have by default at the Menu
 icon and then open a doorhanger explaining the downloading. A ↓ icon,
 instead of the ↑ used now, makes more sense for users to illustrate that
 something is downloading.

 **Tor Browser is Updated**

 It is fancy what Firefox has right now

 
https://trac.torproject.org/projects/tor/attachment/ticket/25694/Captura%20de%20pantalla%202018-05-11%20a%20la(s)%2010.43.26%20AM.png

 But it seems like it has some of the problems mentioned above, eg. line of
 death. So, my proposal here is: once user restarts, the message in
 `about:tor` updates and we keep for a few seconds a Check icon at the
 right Menu button. I'm not sure how Firefox is showing any feedback at
 menu icon by default (or if they are doing it at least), but I made a blue
 and green options for 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] #25903 [Core Tor/Tor]: Add OVERHEAD and DELIVERED fields to CIRC_BW events

[Tor Bug Tracker & Wiki]

#25903: Add OVERHEAD and DELIVERED fields to CIRC_BW events
--+
 Reporter:  mikeperry |  Owner:  mikeperry
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  034-roadmap-proposed  |  Actual Points:
Parent ID:  #25546| Points:
 Reviewer:  isis  |Sponsor:
--+
Changes (by mikeperry):

 * status:  needs_revision => needs_information


Comment:

 Hrmm. Right now there are no relay cell payloads larger than
 RELAY_PAYLOAD_SIZE, and checks against this max are earlier in all of the
 code that calls this function.

 Is this your only issue with the branch? IMO, in that case we should merge
 this, and then change this and the other checks on relay payload length to
 whatever mechanism we have for specifying the new max length depending on
 cell type once that invariant changes. Right now, we don't seem to have an
 alternative mechanism.

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

Re: [tor-bugs] #24204 [Core Tor/Tor]: Improve the in-process Tor API: create owning control port

[Tor Bug Tracker & Wiki]

#24204: Improve the in-process Tor API: create owning control port
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  accepted
 Priority:  Very Low |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, s8-api,  |  Actual Points:
  034-triage-20180328|
Parent ID:  #25510   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-
Changes (by nickm):

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


Comment:

 I think this would be useful, but none of our current downstream
 developers seem so keen on it yet. I don't have time to finish it before
 the freeze for 0.3.4.

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

Re: [tor-bugs] #26083 [Obfuscation/Obfsproxy]: Bridge detector. Fake?

[Tor Bug Tracker & Wiki]

#26083: Bridge detector. Fake?
---+-
 Reporter:  cypherpunks|  Owner:  cypherpunks
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Obfsproxy  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by cypherpunks):

 Replying to [comment:3 cypherpunks]:
 > > You set the owner
 > Automatically assigned by selecting Obfuscation/Obfsproxy Component
 That's still applies for "you".

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

Re: [tor-bugs] #26072 [Core Tor/Tor]: Malformed connected cell closes connection but code continues

[Tor Bug Tracker & Wiki]

#26072: Malformed connected cell closes connection but code continues
---+---
 Reporter:  mikeperry  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  034-must spec-conformance  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * keywords:   => 034-must spec-conformance
 * milestone:   => Tor: 0.3.4.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] #25694 [Applications/Tor Browser]: Activity 3.1: Improve the user experience of updating Tor Browser

[Tor Bug Tracker & Wiki]

#25694: Activity 3.1: Improve the user experience of updating Tor Browser
--+---
 Reporter:  isabela   |  Owner:  antonela
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor17
--+---
Changes (by antonela):

 * Attachment "TTB-restart-menu.png" 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] #26068 [Metrics/Website]: better describe bridges vs. relays in the glosary

[Tor Bug Tracker & Wiki]

#26068: better describe bridges vs. relays in the glosary
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * cc: metrics-team (added)


Comment:

 Agreed, the definitions are slightly confusing. Here's what we have right
 now:

 ''bridge: a relay whose existence is non-public and which can therefore
 provide access for blocked clients, often in combination with pluggable
 transports, which registers itself with the bridge authority.''

 ''relay: a publicly-listed node in the Tor network that forwards traffic
 on behalf of clients, and that registers itself with the directory
 authorities.''

 I wonder if we should say ''server'' rather than ''node'' or even
 ''relay'' as the broader term for a relay-or-bridge thing. After all, we
 also have a "Server" category on the website that includes relays and
 bridges.

 irl, would you be able to check what the other glossaries use here? Would
 this change move us further into their direction or in an opposite
 direction?

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

Re: [tor-bugs] #25694 [Applications/Tor Browser]: Activity 3.1: Improve the user experience of updating Tor Browser

[Tor Bug Tracker & Wiki]

#25694: Activity 3.1: Improve the user experience of updating Tor Browser
--+---
 Reporter:  isabela   |  Owner:  antonela
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor17
--+---
Changes (by antonela):

 * Attachment "Captura de pantalla 2018-05-11 a la(s) 10.43.26 AM.png"
 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] #25694 [Applications/Tor Browser]: Activity 3.1: Improve the user experience of updating Tor Browser

[Tor Bug Tracker & Wiki]

#25694: Activity 3.1: Improve the user experience of updating Tor Browser
--+---
 Reporter:  isabela   |  Owner:  antonela
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor17
--+---
Changes (by antonela):

 * Attachment "25694-3.png" 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] #25694 [Applications/Tor Browser]: Activity 3.1: Improve the user experience of updating Tor Browser

[Tor Bug Tracker & Wiki]

#25694: Activity 3.1: Improve the user experience of updating Tor Browser
--+---
 Reporter:  isabela   |  Owner:  antonela
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor17
--+---
Changes (by antonela):

 * Attachment "25694-2.png" 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] #26030 [Metrics/Website]: Delete "Tor Messenger downloads and updates" section

[Tor Bug Tracker & Wiki]

#26030: Delete "Tor Messenger downloads and updates" section
-+---
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 So, we might be able to resolve #26046 shortly, but it probably makes more
 sense to produce the static analysis just before we take the graph
 offline. Just saying, once #26046 is resolved, this ticket is not
 actionable anymore.

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

Re: [tor-bugs] #26046 [Metrics/Website]: Add text to the Tor Messenger downloads page to explain it is no longer developed

[Tor Bug Tracker & Wiki]

#26046: Add text to the Tor Messenger downloads page to explain it is no longer
developed
-+--
 Reporter:  irl  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #26030   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * cc: metrics-team (added)
 * status:  new => needs_review


Comment:

 Please review and revise [https://gitweb.torproject.org/karsten/metrics-
 web.git/commit/?h=task-26046&id=0060ed5155f015d481f719c59aadb22114cd4dbf
 commit 0060ed5 in my task-26046 branch] with a text suggestion.

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

Re: [tor-bugs] #26083 [Obfuscation/Obfsproxy]: Bridge detector. Fake?

[Tor Bug Tracker & Wiki]

#26083: Bridge detector. Fake?
---+-
 Reporter:  cypherpunks|  Owner:  cypherpunks
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Obfsproxy  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by cypherpunks):

 If someone plans to test it, patch code bug by:
 {{{
  if obfs4_detected == 1:
 + obfs4_detected = 0
   s = socks.socksocket()
 }}}

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

Re: [tor-bugs] #26030 [Metrics/Website]: Delete "Tor Messenger downloads and updates" section

[Tor Bug Tracker & Wiki]

#26030: Delete "Tor Messenger downloads and updates" section
-+---
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Ah, those other two tickets are child tickets. Just seeing that now.
 Hmmm...

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

Re: [tor-bugs] #26030 [Metrics/Website]: Delete "Tor Messenger downloads and updates" section

[Tor Bug Tracker & Wiki]

#26030: Delete "Tor Messenger downloads and updates" section
-+---
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * status:  reopened => needs_information


Comment:

 Thanks for opening those two tickets. Do we need to keep this ticket open?
 If not, can you close it? If yes, can you include a short summary what we
 need to do and when? 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] #26032 [Metrics/ExoneraTor]: suggestion URL is broken (duplicate [[]])

[Tor Bug Tracker & Wiki]

#26032: suggestion URL is broken (duplicate [[]])
+
 Reporter:  cypherpunks |  Owner:  iwakeh
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by karsten):

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


Comment:

 Fix looks good! Merged and deployed. Thanks! 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] #26084 [Core Tor/Nyx]: Graph not updating on Tor 0.3.4.0-alpha-dev

[Tor Bug Tracker & Wiki]

#26084: Graph not updating on Tor 0.3.4.0-alpha-dev
--+
 Reporter:  cypherpunks   |  Owner:  atagar
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:  graph |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by cypherpunks):

 * Attachment "nyx2.png" 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] #26084 [Core Tor/Nyx]: Graph not updating on Tor 0.3.4.0-alpha-dev

[Tor Bug Tracker & Wiki]

#26084: Graph not updating on Tor 0.3.4.0-alpha-dev
--+
 Reporter:  cypherpunks   |  Owner:  atagar
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal|   Keywords:  graph
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 I decided to test out git version of Tor (Tor version 0.3.4.0-alpha-dev
 (git-382beb93cb4110b2)).

 After the upgrade, the nyx graph no longer updates at all. It's all blank.
 Affects not only the bandwidth graph but it doesn't work on "resources" or
 "connections" either.

 It was working fine on Tor 0.3.3.5-rc.

 I have nyx 2.0.4 and Python 2.7.15

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

Re: [tor-bugs] #26083 [Obfuscation/Obfsproxy]: Bridge detector. Fake?

[Tor Bug Tracker & Wiki]

#26083: Bridge detector. Fake?
---+-
 Reporter:  cypherpunks|  Owner:  cypherpunks
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Obfsproxy  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by cypherpunks):

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


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

Re: [tor-bugs] #26083 [Obfuscation/Obfsproxy]: Bridge detector. Fake?

[Tor Bug Tracker & Wiki]

#26083: Bridge detector. Fake?
---+-
 Reporter:  cypherpunks|  Owner:  asn
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Obfsproxy  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by cypherpunks):

 > You set the owner
 Automatically assigned by selecting Obfuscation/Obfsproxy Component

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

Re: [tor-bugs] #26060 [Core Tor/Stem]: Invalid [Length] field when receiving RELAY cells via stem.client.Circuit

[Tor Bug Tracker & Wiki]

#26060: Invalid [Length] field when receiving RELAY cells via 
stem.client.Circuit
---+
 Reporter:  plcp   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  client |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by plcp):

 Here is a little demo:

 {{{
 git clone "https://git.torproject.org/stem.git"; stem-client
 ln -s stem-client/stem
 virtualenv venv
 source venv/bin/activate
 pip install -r ./stem-client/requirements.txt
 tor PublishServerDescriptor 0 AssumeReachable 1 ExitRelay 0
 ProtocolWarnings 1 SafeLogging 0 LogTimeGranularity 1 PidFile "$(mktemp)"
 SOCKSPort 0 ContactInfo n...@example.com
  DataDirectory "$(mktemp -d)" ORPort 9050 DirPort 9051 Log "err stderr" &

 wget https://raw.githubusercontent.com/plcp/tor-
 scripts/master/stem_26060_issue.py
 python stem_26060_issue.py
 }}}

 You should obtain something like that:
 {{{
 Before repacking:
 Cell headers:
  - circ_id: 8000
  - command: 03
 RELAY headers:
  - command: 6e
  - recognized:  eab1
  - stream_id:   c650
  - digest:  7e0f68b7
  - length:  68e4

 After repacking:
 Cell headers:
  - circ_id: 8000
  - command: 03
 RELAY headers:
  - command: 6e
  - recognized:  eab1
  - stream_id:   c650
  - digest:  7e0f68b7
  - length:  01f2 !! corrupted !!

 After decryption:
 Cell headers:
  - circ_id: 8000
  - command: 03
 RELAY headers:
  - command: 04   RELAY_CONNECTED
  - recognized:  
  - stream_id:   0001
  - digest:  a0b49e85
  - length:  6916 !! corrupted !!

 Digest (from the RELAY cell):   a0b49e85
 Digest (computed length):   db7932a8
 Digest (expected length):   a0b49e85
 }}}

 I've managed to fix this issue as follows:
 https://github.com/plcp/stem-
 client/commit/0e2ec2627df05ffcbd2d93be52b862e111bb400b

 (note that I'm only using `stem.client.cell` and thus haven't modified
 `stem.client.Circuit` accordingly)

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

Re: [tor-bugs] #18589 [Applications/Tor Browser]: Tor browser writes SiteSecurityServiceState.txt with usage history

[Tor Bug Tracker & Wiki]

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

Comment (by bloginfo):

 You can disable this history , by giving the false value to the
 [https://www.dsfc.net/logiciel-libre/firefox-logiciel-libre/collecte-
 sites-tls-
 
firefox/#Desactiver_la_collecte_des_sites_dans_le_fichier_SiteSecurityServiceStatetxt
 network.stricttransportsecurity.preloadlist] key in !about:config.

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

Re: [tor-bugs] #26083 [Obfuscation/Obfsproxy]: Bridge detector. Fake?

[Tor Bug Tracker & Wiki]

#26083: Bridge detector. Fake?
---+-
 Reporter:  cypherpunks|  Owner:  asn
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Obfsproxy  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by cypherpunks):

 Here's the code in case Pastebin or someone else deletes it with a DMCA,

 {{{
 #!text/x-python
 import os
 import socks
 import socket
 import sys
 import time

 obfs4_detected = 0

 host =  sys.argv[1]
 port = int(sys.argv[2])
 print "Wait for 100 sec. Verify target: " +host, port
 s = socks.socksocket()
 s.set_proxy(socks.SOCKS5, "127.0.0.1", 9150)
 s.connect((host, port))
 rand_string = os.urandom(16384)
 s.send(rand_string)
 s.settimeout(15)
 try:
  data = s.recv(16384)
  if data == "":
   obfs4_detected = 1

 except socket.timeout:
  obfs4_detected = 0

 s.close()

 if obfs4_detected == 1:
  s = socks.socksocket()
  s.set_proxy(socks.SOCKS5, "127.0.0.1", 9150)
  s.connect((host, port))

  rand_string = os.urandom(8191)
  s.send(rand_string)
  start = time.time()
  s.settimeout(95)
  try:
   data = s.recv(16384)
   if data == "":
end = time.time()
delta = end - start
if delta >= 29:
 obfs4_detected = 1

  except socket.timeout:
   obfs4_detected = 0

  s.close()

 if obfs4_detected:
  print "DETECTED!111"
 else:
  print "NOT OBFS4?"
 }}}

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

Re: [tor-bugs] #26083 [Obfuscation/Obfsproxy]: Bridge detector. Fake?

[Tor Bug Tracker & Wiki]

#26083: Bridge detector. Fake?
---+-
 Reporter:  cypherpunks|  Owner:  asn
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Obfsproxy  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by cypherpunks):

 You set the owner as `asn`, he's not the right person for something like
 this. Maybe `yawning` can take a look?

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

Re: [tor-bugs] #25750 [Applications/Tor Launcher]: update Tor Launcher for ESR 60

[Tor Bug Tracker & Wiki]

#25750: update Tor Launcher for ESR 60
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:
|  needs_revision
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201805  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by mcs):

 Replying to [comment:19 igt0]:
 > I took a quick look in the code and I have a question about
 d104e7ecd35b2dbd38cdc9988fbd5924857d857d, does it load all the default
 properties every time the browser is restarted?

 Yes, I think so. Do you think that is a problem? I suspect that is what
 the code that Mozilla removed did too.

 If addressing this for Torbutton is really messy, maybe we should put more
 effort into reverting the Mozilla patch that removed support for default
 preferences (doing so would fix #26039 as well). But I defer to Matt who
 already tried that approach.

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

Re: [tor-bugs] #26002 [Metrics/Statistics]: Simplify graph with number of bytes spent on answering directory requests

[Tor Bug Tracker & Wiki]

#26002: Simplify graph with number of bytes spent on answering directory 
requests
+--
 Reporter:  karsten |  Owner:  karsten
 Type:  enhancement | Status:  accepted
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by karsten):

 Here's a graph comparing current (light blue) and suggested (light red)
 approach over the years. It only shows four weeks in the respective
 Aprils, and some years are missing, because I ran out of disk space. But
 the general idea should be clear.

 [[Image(dirbytes.2.png, 700px)]]

 I think this looks okay, so I'll go ahead and re-import the rest of the
 data. This will probably take 1--2 weeks.

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

Re: [tor-bugs] #26074 [Applications/Tor Browser]: I tried to go to a v2 onion and Tor Browser Bundle crashed

[Tor Bug Tracker & Wiki]

#26074: I tried to go to a v2 onion and Tor Browser Bundle crashed
--+---
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by mcs):

 * status:  new => needs_information


Comment:

 Replying to [comment:1 Dbryrtfbcbhgf]:
 > Can the attachment
 
https://trac.torproject.org/projects/tor/attachment/ticket/26074/firefox_2018-05-10
 -152238_Jackis-MacBook-Pro.crash.zip be removed, it has my Macbook's name?
 the other file is the correct one.

 Done.

 Can you reproduce this crash?
 Does it occur for all v2 .onions that you visit?

 I tried visiting the Facebook .onion and several Tor Project services on a
 macOS 10.13.4 system but could not produce a crash.

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

Re: [tor-bugs] #26002 [Metrics/Statistics]: Simplify graph with number of bytes spent on answering directory requests

[Tor Bug Tracker & Wiki]

#26002: Simplify graph with number of bytes spent on answering directory 
requests
+--
 Reporter:  karsten |  Owner:  karsten
 Type:  enhancement | Status:  accepted
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by karsten):

 * Attachment "dirbytes.2.png" 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] #26073 [Applications/Tor Browser]: patch tor-browser-build.git for Firefox 60 ESR

[Tor Bug Tracker & Wiki]

#26073: patch tor-browser-build.git for Firefox 60 ESR
+--
 Reporter:  arthuredelstein |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201805, ff60-esr  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by mcs):

 Replying to [comment:3 cypherpunks]:
 > Replying to [comment:1 arthuredelstein]:
 > > Some obvious things are broken, including:
 > Torlauncher as well:
 >
 > [[Image(https://i.stack.imgur.com/pH5kS.png)]]

 That Tor Launcher problem is caused by the issue described in #26039.

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

Re: [tor-bugs] #26056 [Core Tor/Stem]: Stem should optionally timeout when building circuits

[Tor Bug Tracker & Wiki]

#26056: Stem should optionally timeout when building circuits
---+
 Reporter:  pastly |  Owner:  atagar
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  controller |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by pastly):

 Oh man this is great. It felt good deleting all the code I just wrote.

 One thing though: it always times out immediately in the first `raise
 stem.Timeout(...)`. I think `time_left` is calculated incorrectly and
 should be done like this.

 {{{
 (venv-editable) [matt@zen stem]$ git diff
 diff --git a/stem/control.py b/stem/control.py
 index 244aed0b..a9d33749 100644
 --- a/stem/control.py
 +++ b/stem/control.py
 @@ -4025,7 +4025,7 @@ def _get_with_timeout(event_queue, timeout,
 start_time):
"""

if timeout:
 -time_left = time.time() - start_time - timeout
 +time_left = timeout - (time.time() - start_time)

  if time_left <= 0:
raise stem.Timeout('Reached our %0.1f second timeout' % timeout)
 }}}

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