Re: [tor-bugs] #27696 [Applications/Tor Launcher]: unable to open browser

[Tor Bug Tracker & Wiki]

#27696: unable to open  browser
---+---
 Reporter:  satish_chandra |  Owner:  brade
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-usability apparmor |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by traumschule):

 * keywords:   => tbb-usability apparmor
 * priority:  Immediate => Medium
 * status:  new => needs_information
 * component:  - Select a component => Applications/Tor Launcher
 * owner:  (none) => brade


Comment:

 Thanks for reporting this!

 Which OS are you on? Also are you sure, that you did not accidentally
 click twice on the icon, please describe what you did before this
 happened.

 Possible duplicate of #27476 or #12941

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27696 [- Select a component]: unable to open browser

[Tor Bug Tracker & Wiki]

#27696: unable to open  browser
--+
 Reporter:  satish_chandra|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 "Tor Browser is already running, but is not responding. The old Tor
 Browser process must be closed to open a new window." this message is
 being displayed in a dialogue box and asks me to close the browser
 whenever I try to open the browser[[Image()]]

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

Re: [tor-bugs] #27097 [Applications/Tor Browser]: Add "Tor News" newsletter signup link in Tor Browser

[Tor Bug Tracker & Wiki]

#27097: Add "Tor News" newsletter signup link in Tor Browser
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-fundraising,|  Actual Points:
  TorBrowserTeam201809R, tbb-8.0.1-can   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by steph):

 Looks great, thank you!

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

Re: [tor-bugs] #17393 [Webpages/Website]: Make the various javascript on Tor sites be LibreJS-compatible?

[Tor Bug Tracker & Wiki]

#17393: Make the various javascript on Tor sites be LibreJS-compatible?
+--
 Reporter:  arma|  Owner:  traumschule
 Type:  enhancement | Status:  needs_review
 Priority:  Low |  Milestone:  WebsiteV3
Component:  Webpages/Website|Version:
 Severity:  Minor   | Resolution:
 Keywords:  defer-new-website, website-bug  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  hiro|Sponsor:
+--

Comment (by traumschule):

 Time for another test round:
 [http://savannah.gnu.org/forum/forum.php?forum_id=9239 LibreJS 7.17]

 This release introduces a new interface for management of the
 whitelist/blacklist, along with several bug fixes:
 * Temporary hiding complain to owner feature until ready for prime time.
 * Adjust directory layout and packaging to allow Storage.js to be shared
 with the settings page in the xpi release.
 * Refactored panel visual styles to be reused by the settings page.
 * Support for batch async list operations.
 * Fix navigating the same url with # erases activity report 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] #27681 [Applications/Tor Browser]: Tor Browser fail to load TLS1.3 websites SSL_ERROR_PROTOCOL_VERSION_ALERT

[Tor Bug Tracker & Wiki]

#27681: Tor Browser fail to load TLS1.3 websites 
SSL_ERROR_PROTOCOL_VERSION_ALERT
--+--
 Reporter:  cypherpunks3  |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by traumschule):

 Duplicate means that this is being worked on in another ticket, so don't
 worry, it is on the radar!
 Next time filing a ticket please take the effort to search for similar
 issues first, describe the problem and how you expect it being solved.

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

Re: [tor-bugs] #27503 [Applications/Tor Browser]: Disabling accessibility on Windows breaks screen readers

[Tor Bug Tracker & Wiki]

#27503: Disabling accessibility on Windows breaks screen readers
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-8.0-issues, tbb-regression  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by arma):

 I talked to a Windows user today on #tor who uses a screen reader and was
 reporting that Tor Browser 8 doesn't work for them. They reported that the
 Firefox ESR does work for them.

 I guess it's because Firefox ESR is built with clang, and we want to build
 with mingw, for reproducible build purposes?

 In any case, count another user affected by this bug.

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

Re: [tor-bugs] #27687 [Core Tor/Tor]: rust protover accepts non ASCII in protocol names

[Tor Bug Tracker & Wiki]

#27687: rust protover accepts non ASCII in protocol names
-+-
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, protover, 033-backport,|  Actual Points:
  034-backport   |
Parent ID:  #27316   | Points:
 Reviewer:  teor |Sponsor:
-+-
Changes (by teor):

 * status:  needs_revision => merge_ready


Comment:

 Replying to [comment:3 cyberpunks]:
 > Replying to [comment:2 teor]:
 > >  If this branch is already on the latest 0.3.3, can you try merging to
 0.3.4 and master, and provide branches for the non-trivial merges?
 >
 > Done. The conflicts in master were due to the rustfmt changes.

 Thanks!

 I just realised that Appveyor doesn't run rust, so I think we're fine to
 merge rust-protokeyword1 into 0.3.3 and forward, and rust-
 protokeyword1-035 into master. (rust-protokeyword1-034 seems like a
 trivial merge?)

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

Re: [tor-bugs] #27662 [Core Tor/Tor]: refactor networkstatus_parse_vote_from_string()

[Tor Bug Tracker & Wiki]

#27662: refactor networkstatus_parse_vote_from_string()
-+-
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  technical-debt, refactor, long-  |  Actual Points:
  functions, cthulhucode |
Parent ID:  #22408   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cyberpunks):

 Replying to [comment:3 teor]:
 > Hi,
 >
 > The unit tests fail CI on rust builds with:

 That was a failure from the master branch that was fixed since then, not
 related to this refactor.

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

Re: [tor-bugs] #22076 [Webpages/Website]: adjust text shown on screen based on size of text

[Tor Bug Tracker & Wiki]

#22076: adjust text shown on screen based on size of text
--+-
 Reporter:  efittery  |  Owner:  traumschule
 Type:  enhancement   | Status:  reopened
 Priority:  Medium|  Milestone:  WebsiteV3
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  website-bug   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by traumschule):

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


Comment:

 This got reverted:
 
https://gitweb.torproject.org/project/web/webwml.git/commit/?id=da4db986ea33e18bc9eebc6784e7d5dbdd752bf3
 
http://jqs44zhtxl2uo6gk.onion/project/web/webwml.git/commit/?id=da4db986ea33e18bc9eebc6784e7d5dbdd752bf3

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

Re: [tor-bugs] #27662 [Core Tor/Tor]: refactor networkstatus_parse_vote_from_string()

[Tor Bug Tracker & Wiki]

#27662: refactor networkstatus_parse_vote_from_string()
-+-
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  technical-debt, refactor, long-  |  Actual Points:
  functions, cthulhucode |
Parent ID:  #22408   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 Hi,

 The unit tests fail CI on rust builds with:
 {{{
 protover/vote:
   FAIL src/test/test_protover.c:175: assert(result OP_EQ ""):  vs
 <>
   [vote FAILED]
 }}}
 https://travis-ci.org/teor2345/tor/jobs/428431227#L6130
 https://travis-ci.org/teor2345/tor/builds/428431225

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

Re: [tor-bugs] #27247 [Core Tor/Tor]: Clients are using RAM for cached_dir_t

[Tor Bug Tracker & Wiki]

#27247: Clients are using RAM for cached_dir_t
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  035-roadmap-master, 035-triaged- |  Actual Points:
  in-20180711|
Parent ID:  #27243   | Points:
 Reviewer:  teor |Sponsor:
 |  Sponsor8
-+-
Changes (by teor):

 * status:  needs_review => merge_ready


Comment:

 The original fix was #20667, I think caching consensuses in RAM on clients
 was a mistake in that branch.

 I asked some questions on the pull request - in particular, I think this
 branch disables consensus diffs and if-modified-since headers on clients
 with `FetchUselessDescriptors 1`.

 Even so, I would happily merge this code as-is.

 (I will pull out my test bandwidth authority, and test master and this
 branch, but that's going to take a few days.)

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

Re: [tor-bugs] #27175 [Applications/Tor Browser]: NoScript plugin does not save per-site permissions/settings when tor browser closes

[Tor Bug Tracker & Wiki]

#27175: NoScript plugin does not save per-site permissions/settings when tor
browser closes
-+-
 Reporter:  tor-user-1234|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  noscript, tbb-regression,|  Actual Points:
  tbb-8.0-issues |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks_reply):

 Only some comments:

 Replying to [comment:10 arthuredelstein]:
 > But, yes, I am very hesitant to give users the means to persist their
 per-site settings, especially when the per-site settings are not first-
 party isolated.
 ABE in NoScript 5 was able to implement first-party-keyed policy.
 > If a user decides to whitelist Google, then every website that embeds a
 Google ad can detect this. I am even worried about an opt-in solution
 because users often don't properly understand the downsides.
 It also had this "Block scripting in whitelisted subdocuments of non-
 whitelisted pages" setting, which is not first-party isolation/keying but
 related (and I think similar to the kind of problem decomposition used by
 uMatrix). I wonder how it's handled now.
 > At the same time, I also sympathize with donnm's comment:9 that it is
 inconvenient to have to redo per-site settings each time Tor Browser is
 restarted.
 I use the highest level in torbutton slider and I don't care about
 persisting the per-site policy, I always keep the whitelist empty and only
 very seldom use temporary permissions which are revoked once done with the
 page Certainly "new identity" must also at least clear all temporary
 permissions. However, there were at least in NoScript 5 many other
 configuration knobs that applied globally and which I used to tighten with
 respect to vanilla TOr Browser (yes, I know that changed my profile).
 Maybe there should be a way to persist at least that kind of settings.

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

Re: [tor-bugs] #27616 [Applications/Tor Browser]: Double-check Rust code for potential proxy bypass in ESR 60

[Tor Bug Tracker & Wiki]

#27616: Double-check Rust code for potential proxy bypass in ESR 60
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #22176| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sysrqb):

 Replying to [comment:2 gk]:
 > See the second part of comment:15:ticket:22176

 Okay, I started with gk's 3) from that ticket. First, I enumerated all
 packages and their dependencies (not including the vendored crates). From
 these packages, I searched for all occurrences of "tcp", "udp", "socket",
 "bind", "connect", "listener", "send", "recv", and "stream". (I don't
 claim these are the only functions/methods that can be used for
 transmitting a message).

 I found these are the in-tree packages (not vendored in
 `third_party/rust`):
 {{{
 media/mp4parse-rust/mp4parse_capi
 servo/support/gecko/nsstring
 xpcom/rust/nserror
 netwerk/base/rust-helper
 xpcom/rust/xpcom
 xpcom/rust/xpcom/xpcom_macros
 modules/libpref/parser
 netwerk/base/rust-url-capi
 dom/webauthn/u2f-hid-rs
 servo/ports/geckolib
 }}}

 For each of those packages, I ran
 {{{
 $ grep -rni -E "tcp|udp|socket|bind|connect|listener|send|recv|stream" $p
 }}}

 (where `$p` was each directory path from above).

 Many of the results were false-positives. In particular, `bind` matched
 many incstances of "binding" or "bindgen". So, excluding those:
 {{{
 $ grep -rni -E "tcp|udp|socket|bind|connect|listener|send|recv|stream" $p
 | grep -v -E "[bB]inding|[bB]indgen" | grep -ni --color=always -E
 "tcp|udp|socket|bind|connect|listener|send|recv|stream"
 }}}

 These directories didn't contain any matches:
 {{{
 servo/support/gecko/nsstring
 xpcom/rust/nserror
 netwerk/base/rust-helper
 modules/libpref/parser
 netwerk/base/rust-url-capi
 servo/ports/geckolib
 }}}

 `media/mp4parse-rust/mp4parse_capi` has instances of "stream" (but that's
 not surprising considering it's doc comment says "Parses ISO Base Media
 Format aka video/mp4 streams."). All instances of `stream` are from audio
 (FLAC) track information.

 `xpcom/rust/xpcom/xpcom_macros` has a occurrence of "bind" and a few
 instances of "stream". "bind" is related to FFI, and "stream" are
 `TokenStream`s.

 `dom/webauthn/u2f-hid-rs` has "send" and "recv", but these are methods
 called on a `std::sync::mpsc::channel`. There is another wrapper method
 `sendrecv` that calls `U2FHIDCont::write` and `U2FHIDInit::read` for
 reading/writing the U2F device. These read/write methods specifically take
 a device as the first argument. Using this for making network calls seems
 very difficult (without digging too deep).

 (to be continued.)

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

Re: [tor-bugs] #27591 [Applications/Tor Launcher]: TB: Offer an option to disable updates on first start (was: Usability for blind users / TB 7.5 updates itself although updates are disabled)

[Tor Bug Tracker & Wiki]

#27591: TB: Offer an option to disable updates on first start
---+--
 Reporter:  traumschule|  Owner:  tbb-team
 Type:  enhancement| Status:  reopened
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by traumschule):

 * status:  closed => reopened
 * resolution:  worksforme =>
 * component:  Applications/Tor Browser => Applications/Tor Launcher
 * type:  defect => enhancement


Old description:

> A blind windows user told on IRC that TB 8.0 does not work with NVda
> Screenreader (#27503) and that TB 7.5 updated itself although updates
> were disabled.
> > Please do something with Tor browser 8.0 for Windows acessibility. It's
> not accessible to blind users of NVda Screanreader.
> > I tried install 7.5 but after disable update it started updater. I dont
> know how i can properly disable it.
> and left shortly after. Maybe the option was not obvious enough at first.
> We could try to improve usability for blind users.

New description:

 A blind windows user told on IRC that TB 8.0 does not work with NVda
 Screenreader (#27503) and that TB 7.5 updated itself although updates were
 disabled.
 > Please do something with Tor browser 8.0 for Windows acessibility. It's
 not accessible to blind users of NVda Screanreader.
 > I tried install 7.5 but after disable update it started updater. I dont
 know how i can properly disable it.
 and left shortly after. Maybe the option was not obvious enough at first.

 We could (try to improve usability for blind users and) add a checkbox on
 the first Tor Launcher screen to disable updates.

--

Comment:

 Rebranding this to keep above valuable input visible.

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

Re: [tor-bugs] #27482 [Applications/Tor Browser]: tor browser 8 - crash on startup on osx 10.9

[Tor Bug Tracker & Wiki]

#27482: tor browser 8 - crash on startup on osx 10.9
-+-
 Reporter:  user_1234|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-8.0-issues, tbb-regression,  |  Actual Points:
  TorBrowserTeam201809, tbb-8.0.1-can|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * cc: nicola (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] #27693 [Applications/Tor Browser]: tor.real doesn't start on MacOSX 9 after upgrading to 8.0

[Tor Bug Tracker & Wiki]

#27693: tor.real doesn't start on MacOSX 9 after upgrading to 8.0
--+--
 Reporter:  nicola|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:  Tor: 0.3.4.8
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mcs):

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


Comment:

 This bug is being tracked in #27482. The short story is that Tor Browser
 8.0.1, which is coming soon, will include a new Tor which will fix this
 problem.

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

Re: [tor-bugs] #27427 [Applications/Tor Browser]: [PATCH] Fix NoScript IPC for about:blank by whitelisting messages

[Tor Bug Tracker & Wiki]

#27427: [PATCH] Fix NoScript IPC for about:blank by whitelisting messages
-+-
 Reporter:  rustybird|  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201809R,   |  Actual Points:
  tbb-8.0.1-can  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks3):

 Replying to [comment:8 rustybird]:
 > the race much less likely to be "won" by the bug, but not impossible.
 Which could mean that it occasionally affects real websites as well.
 Hopefully, the patch fixes all of those cases.

 Ok. And your fix is to ignore the message? Isn't it evident that there's a
 concurrency bug in NoScript that should be fixed? Just quickly skimming
 over the code I can see that handling a `fetchChildPolicy` message
 involves objects that are mutated (I suppose initialised) in `init`, the
 function that sends `started` when completes. Do you see?

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

Re: [tor-bugs] #27687 [Core Tor/Tor]: rust protover accepts non ASCII in protocol names

[Tor Bug Tracker & Wiki]

#27687: rust protover accepts non ASCII in protocol names
-+-
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, protover, 033-backport,|  Actual Points:
  034-backport   |
Parent ID:  #27316   | Points:
 Reviewer:  teor |Sponsor:
-+-

Comment (by cyberpunks):

 Replying to [comment:2 teor]:
 >  If this branch is already on the latest 0.3.3, can you try merging to
 0.3.4 and master, and provide branches for the non-trivial merges?

 Done. The conflicts in master were due to the rustfmt changes.

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

Re: [tor-bugs] #27316 [Core Tor/Tor]: protover.c accepts arbitrary bytes in protocol names

[Tor Bug Tracker & Wiki]

#27316: protover.c accepts arbitrary bytes in protocol names
-+-
 Reporter:  cyberpunks   |  Owner:
 |  cyberpunks
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.4-alpha
 Severity:  Normal   | Resolution:
 Keywords:  protover, 029-backport,  |  Actual Points:
  032-backport, 033-backport, 034-backport   |
Parent ID:   | Points:
 Reviewer:  teor |Sponsor:
-+-

Comment (by cyberpunks):

 Oops. Rebased, was only supposed to have one commit there.

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

Re: [tor-bugs] #27689 [Core Tor/sbws]: Round bandwidth in bandwidth files with other algorithm

[Tor Bug Tracker & Wiki]

#27689: Round bandwidth in bandwidth files with other algorithm
---+
 Reporter:  juga   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords:  prop276|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * keywords:   => prop276


Comment:

 This is proposal 276:
 https://gitweb.torproject.org/torspec.git/tree/proposals/276-lower-bw-
 granularity.txt

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

Re: [tor-bugs] #27687 [Core Tor/Tor]: rust protover accepts non ASCII in protocol names

[Tor Bug Tracker & Wiki]

#27687: rust protover accepts non ASCII in protocol names
-+-
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, protover, 033-backport,|  Actual Points:
  034-backport   |
Parent ID:  #27316   | Points:
 Reviewer:  teor |Sponsor:
-+-
Changes (by teor):

 * status:  new => needs_revision
 * reviewer:   => teor
 * milestone:   => Tor: 0.3.5.x-final


Comment:

 This branch doesn't merge cleanly into master, I think because some other
 fixes have already been merged to master, or because of code formatting.
 Can you rebase this branch on the latest maint-0.3.3?

 If this branch is already on the latest 0.3.3, can you try merging to
 0.3.4 and master, and provide branches for the non-trivial merges?

 I opened a pull request for this branch on 0.3.3 here:
 https://github.com/torproject/tor/pull/333

 Once the merge conflicts are fixed, we can merge to 0.3.4 to get Appveyor
 CI as well.

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

Re: [tor-bugs] #27139 [Core Tor/Tor]: macOS i386 fails time unit tests

[Tor Bug Tracker & Wiki]

#27139: macOS i386 fails time unit tests
-+
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  accepted
 Priority:  Medium   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, macos, i386  |  Actual Points:
Parent ID:  #27296   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by nickm):

 I think the second one may also be due to rounding error in that function.

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

Re: [tor-bugs] #27316 [Core Tor/Tor]: protover.c accepts arbitrary bytes in protocol names

[Tor Bug Tracker & Wiki]

#27316: protover.c accepts arbitrary bytes in protocol names
-+-
 Reporter:  cyberpunks   |  Owner:
 |  cyberpunks
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.4-alpha
 Severity:  Normal   | Resolution:
 Keywords:  protover, 029-backport,  |  Actual Points:
  032-backport, 033-backport, 034-backport   |
Parent ID:   | Points:
 Reviewer:  teor |Sponsor:
-+-
Changes (by teor):

 * keywords:
 protover, 029-backport, 032-backport, 033-backport, 034-backport,
 unicode
 => protover, 029-backport, 032-backport, 033-backport, 034-backport
 * status:  needs_review => needs_revision
 * milestone:  Tor: unspecified => Tor: 0.3.5.x-final


Comment:

 > Can this make it to 0.3.5?

 The 0.3.5 feature freeze is today (Friday 14 September).

 But bug fixes are not features, so we review them and backport them to
 previous releases as needed.

 I tried reviewing this branch, but it seems to contain a whole bunch of
 fixes. Most of the fixes have other tickets. Can you provide one branch
 per fix, with no other fixes?

 If there are dependencies, can you say which branches depend on other
 branches, so that I know which branches to review first?

 Also, we try not to use `tor_assert()` for non-fatal bugs, because it
 terminates the process. Instead, we use `tor_assert_nonfatal()`, or
 `if(BUG()) { /* action on failure */ }`.

 This branch doesn't merge cleanly into master, I think because some of the
 fixes have already been merged to master. Can you rebase this branch on
 the latest maint-0.2.9?

 I opened a pull request for this branch on 0.2.9 here:
 https://github.com/torproject/tor/pull/332

 Once the merge conflicts are fixed, we can merge to 0.3.4 to get Appveyor
 CI as well.

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

Re: [tor-bugs] #27139 [Core Tor/Tor]: macOS i386 fails time unit tests

[Tor Bug Tracker & Wiki]

#27139: macOS i386 fails time unit tests
-+
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  accepted
 Priority:  Medium   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, macos, i386  |  Actual Points:
Parent ID:  #27296   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

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


Comment:

 The first one is probably due to monotime_coarse_diff_msec32_() having
 some rounding error.  I think that should be easy to resolve.

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

Re: [tor-bugs] #21530 [Core Tor/Tor]: Make ExitRelay 0 the default when there is no exit policy

[Tor Bug Tracker & Wiki]

#21530: Make ExitRelay 0 the default when there is no exit policy
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-exit tor-relay configuration |  Actual Points:
  usability expectations |
Parent ID:   | Points:  1
 Reviewer:  mikeperry|Sponsor:
-+-

Comment (by neel):

 I have pushed the changes.

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

Re: [tor-bugs] #27661 [Core Tor/Tor]: use C99 bool from stdbool.h instead of int everywhere

[Tor Bug Tracker & Wiki]

#27661: use C99 bool from stdbool.h instead of int everywhere
-+-
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  coccinelle, tor-client, technical-   |  Actual Points:
  debt, c99  |
Parent ID:  #13260   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 I'm fine with returning a bool from functions that are logically boolean,
 but we shouldn't change the convention for functions where "0" indicates
 success and "-1" indicates an error.

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

Re: [tor-bugs] #27644 [Core Tor/Tor]: wrong documentation of networkstatus_read_cached_consensus_impl

[Tor Bug Tracker & Wiki]

#27644: wrong documentation of networkstatus_read_cached_consensus_impl
--+
 Reporter:  cyberpunks|  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:  #27629| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

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


Comment:

 This was merged as part of #27630.

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

Re: [tor-bugs] #27417 [Core Tor/Tor]: refactor conn_close_if_marked() in main.c

[Tor Bug Tracker & Wiki]

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

Comment (by cyberpunks):

 Replying to [comment:6 mikeperry]:
 > This is failing make check-spaces :/

 In crypto_util.c, a file the patches never touched?

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

Re: [tor-bugs] #27670 [Core Tor/Tor]: Memleak on tor master 95fcad4088eba52e

[Tor Bug Tracker & Wiki]

#27670: Memleak on tor master 95fcad4088eba52e
---+---
 Reporter:  dgoulet|  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.5.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  regression, memleak, 035-must  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 I think coverity found this leak (or a similar leak) as CID 1439317:

 /src/core/mainloop/connection.c: 2910 in retry_all_listeners()

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

Re: [tor-bugs] #26368 [Core Tor/Tor]: Consider circuit isolation when closing redundant intro points

[Tor Bug Tracker & Wiki]

#26368: Consider circuit isolation when closing redundant intro points
-+-
 Reporter:  sysrqb   |  Owner:  neel
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-client, 035-roadmap- |  Actual Points:
  proposed, tbb-needs|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by neel):

 * status:  needs_revision => 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] #26368 [Core Tor/Tor]: Consider circuit isolation when closing redundant intro points

[Tor Bug Tracker & Wiki]

#26368: Consider circuit isolation when closing redundant intro points
-+-
 Reporter:  sysrqb   |  Owner:  neel
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-client, 035-roadmap- |  Actual Points:
  proposed, tbb-needs|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by neel):

 I have pushed these changes.

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

Re: [tor-bugs] #27139 [Core Tor/Tor]: macOS i386 fails time unit tests

[Tor Bug Tracker & Wiki]

#27139: macOS i386 fails time unit tests
-+
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, macos, i386  |  Actual Points:
Parent ID:  #27296   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by nickm):

 I've started investigating these more closely.

 One thing that would be helpful here would be to know which values
 mach_timebase_info() puts into its output on this platforms.

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

Re: [tor-bugs] #27661 [Core Tor/Tor]: use C99 bool from stdbool.h instead of int everywhere

[Tor Bug Tracker & Wiki]

#27661: use C99 bool from stdbool.h instead of int everywhere
-+-
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  coccinelle, tor-client, technical-   |  Actual Points:
  debt, c99  |
Parent ID:  #13260   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 When returning a boolean from a function, bool is the best we can do.

 In a struct, a 1-bit field is better (`unsigned int foo : 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] #27073 [Core Tor/Tor]: conditionvar_timeout intermittently fails on maint-0.3.3

[Tor Bug Tracker & Wiki]

#27073: conditionvar_timeout intermittently fails on maint-0.3.3
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.8
 Severity:  Normal   | Resolution:
 Keywords:  tor-test, 029-backport 032-backport  |  Actual Points:
  033-backport 034-backport  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  accepted => 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] #27073 [Core Tor/Tor]: conditionvar_timeout intermittently fails on maint-0.3.3

[Tor Bug Tracker & Wiki]

#27073: conditionvar_timeout intermittently fails on maint-0.3.3
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.8
 Severity:  Normal   | Resolution:
 Keywords:  tor-test, 029-backport 032-backport  |  Actual Points:
  033-backport 034-backport  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  regression?, tor-test => tor-test, 029-backport 032-backport
 033-backport 034-backport
 * owner:  (none) => nickm
 * status:  new => accepted


Comment:

 Oh, I've found two problems here: first, the  test launches 4 threads, but
 it doesn't make sure they're all done initializing before it starts
 signalling them.  That probably isn't what's going wrong here.

 The problem is that waiting for 200 msec is not enough when the system is
 under heavy load.  Instead, we should watch for the threads exiting, and
 require that they do so in some reasonable amount of time, but put the
 boundary very high on what counts as "reasonable".

 I've got a patch for the test to do this in `bug27073_029`, with PR at
 https://github.com/torproject/tor/pull/331

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27695 [Applications/Tor Browser]: Cannot change Tor Identity in V. 8.0

[Tor Bug Tracker & Wiki]

#27695: Cannot change Tor Identity  in V. 8.0
--+--
 Reporter:  bakertaylor   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  |   Keywords:  Identity
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor2  |
--+--
 Users cannot easily change Tor Identity due to removal/modification of the
 onion button. Changing Tor Identity is a necessary security precaution in
 certain use cases. Modification should be made to reincorporate this
 important feature.

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

Re: [tor-bugs] #27647 [Core Tor/Tor]: When randomly choosing IPv4 or IPv6, set IPv6 probability based on IPv6 weight

[Tor Bug Tracker & Wiki]

#27647: When randomly choosing IPv4 or IPv6, set IPv6 probability based on IPv6
weight
-+--
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client ipv6  |  Actual Points:
Parent ID:  #17835   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by teor):

 (Currently, relays can't be IPv6-only, but bridges can be configured as
 IPv6-only.)

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

Re: [tor-bugs] #27427 [Applications/Tor Browser]: [PATCH] Fix NoScript IPC for about:blank by whitelisting messages

[Tor Bug Tracker & Wiki]

#27427: [PATCH] Fix NoScript IPC for about:blank by whitelisting messages
-+-
 Reporter:  rustybird|  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201809R,   |  Actual Points:
  tbb-8.0.1-can  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * status:  assigned => needs_review


Comment:

 After testing in Tor Browser, Rusty Bird's patch looks good to me. I
 changed it to use the better JS equality operator, but otherwise it's the
 same:

 Here it is rebased to origin/master:

 https://github.com/arthuredelstein/torbutton/commit/27427

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

Re: [tor-bugs] #26381 [Applications/Tor Browser]: about:tor page does not load on first start on Windows and browser is stuck in endless reload cycle

[Tor Bug Tracker & Wiki]

#26381: about:tor page does not load on first start on Windows and browser is 
stuck
in endless reload cycle
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton, ff60-esr, |  Actual Points:
  TorBrowserTeam201809   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by pospeselr):

 Replying to [comment:31 brade]:
 > * Startup of components that have the `profile-after-change` category.
 We think this one is an issue. For example, after applying the proposed
 fix we saw the update service attempt an update ping while the Tor
 Launcher initial configuration window was open.

 This does seem to be a problem, and it doesn't seem like we can fix it in
 the extension.  Went through this today and can confirm, tor-launcher
 blocks on 'profile-after-change' until the network settings dialog is
 dismissed, which allows the update service and what-not to complete after
 a tor connection has been set up.

 I've done some digging into the original proposed patch (moving the
 sandbox init up before DoStartup) and I can confirm that it does configure
 all of the directories correctly, except for the
 NS_APP_USER_PROFILE_50_DIR directory, which will probably cause some
 issues (though it seems to be init'd sometime between the entry into
 DoStartup and the first service initialization in there).  I'll see if we
 can encourage NS_APP_USER_PROFILE_50_DIR to be defined earlier tomorrow.

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

Re: [tor-bugs] #27417 [Core Tor/Tor]: refactor conn_close_if_marked() in main.c

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => needs_revision


Comment:

 cyberpunks: This is failing make check-spaces :/

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

Re: [tor-bugs] #27175 [Applications/Tor Browser]: NoScript plugin does not save per-site permissions/settings when tor browser closes

[Tor Bug Tracker & Wiki]

#27175: NoScript plugin does not save per-site permissions/settings when tor
browser closes
-+-
 Reporter:  tor-user-1234|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  noscript, tbb-regression,|  Actual Points:
  tbb-8.0-issues |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 Replying to [comment:8 gk]:
 > Replying to [comment:7 arthuredelstein]:
 > > It is possible to implement a modified security slider mechanism that
 would allow NoScript to retain per-site settings. But the question is
 whether it is actually desirable to do this, as saving per-site settings
 would (1) violate disk hygiene and (2) serve as a long-term fingerprinting
 vulnerability (at least, as long as NoScript is not first-party isolated).
 >
 > So, you are arguing that this is a feature of Tor Browser 8 and we
 should keep the status quo?

 Well, feature is too strong a word because it happened more or less
 incidentally as a result of NoScript's new architecture. :) And given the
 current UI of NoScript, it's very confusing to users because it looks as
 though per-site settings in NoScript should persist.

 But, yes, I am very hesitant to give users the means to persist their per-
 site settings, especially when the per-site settings are not first-party
 isolated. If a user decides to whitelist Google, then every website that
 embeds a Google ad can detect this. I am even worried about an opt-in
 solution because users often don't properly understand the downsides.

 At the same time, I also sympathize with donnm's comment:9 that it is
 inconvenient to have to redo per-site settings each time Tor Browser is
 restarted.

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

Re: [tor-bugs] #25090 [Applications/Tor Browser]: Make sure IPFS & co in addons are shoved up through Tor and don't leak in ESR60

[Tor Bug Tracker & Wiki]

#25090: Make sure IPFS & co in addons are shoved up through Tor and don't leak 
in
ESR60
+--
 Reporter:  cypherpunks |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff60-esr, tbb-proxy-bypass  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arthuredelstein):

 * cc: arthuredelstein (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] #23512 [Core Tor/Tor]: Bandwidth stats info leak upon close of circuits with queued cells

[Tor Bug Tracker & Wiki]

#23512: Bandwidth stats info leak upon close of circuits with queued cells
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bug-bounty, congestion-attack,   |  Actual Points:
  research, watermark, tor-stats, guard- |
  discovery-stats, 034-triage-20180328,  |
  034-removed-20180328   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-
Changes (by mikeperry):

 * status:  needs_revision => needs_review


Comment:

 Ok, finally have a test for it: https://github.com/torproject/tor/pull/330

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

Re: [tor-bugs] #27482 [Applications/Tor Browser]: tor browser 8 - crash on startup on osx 10.9

[Tor Bug Tracker & Wiki]

#27482: tor browser 8 - crash on startup on osx 10.9
-+-
 Reporter:  user_1234|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-8.0-issues, tbb-regression,  |  Actual Points:
  TorBrowserTeam201809, tbb-8.0.1-can|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by catalyst):

 #27693 seems to be a duplicate.

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

[tor-bugs] #27694 [Core Tor/Tor]: what happens if we have both a firewall-bypass proxy and a pluggable transport?

[Tor Bug Tracker & Wiki]

#27694: what happens if we have both a firewall-bypass proxy and a pluggable
transport?
--+--
 Reporter:  catalyst  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-pt, proxy
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Tor Launcher seems to let you configure both a "proxy" and a "bridge"
 (typically a PT bridge).  Does this do anything useful?  arma thinks it
 might just catch fire.  We might want to make this do something useful.
 e.g., what if you need to use an HTTP proxy to get out of your network,
 and obfs4 to connect to a relay?

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

Re: [tor-bugs] #27693 [Applications/Tor Browser]: tor.real doesn't start on MacOSX 9 after upgrading to 8.0

[Tor Bug Tracker & Wiki]

#27693: tor.real doesn't start on MacOSX 9 after upgrading to 8.0
--+--
 Reporter:  nicola|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:  Tor: 0.3.4.8
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

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


Comment:

 Is Tor Browser built to target OSX 10.9?  In theory, ever since #26876 was
 fixed, Tor should be able to work fine if you build it targeting an older
 OSX SDK.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27693 [Core Tor/Tor]: tor.real doesn't start on MacOSX 9 after upgrading to 8.0

[Tor Bug Tracker & Wiki]

#27693: tor.real doesn't start on MacOSX 9 after upgrading to 8.0
--+--
 Reporter:  nicola|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.8
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 When I start TorBrowser, it is unable to start the tor daemon.
 When run via CLI, the error is:

 {{{
 $ /Applications/TorBrowser-old.app/Contents/MacOS/Tor/tor.real
 dyld: lazy symbol binding failed: Symbol not found: _mach_approximate_time
   Referenced from: /Applications/TorBrowser-
 old.app/Contents/MacOS/Tor/tor.real
   Expected in: /usr/lib/libSystem.B.dylib

 dyld: Symbol not found: _mach_approximate_time
   Referenced from: /Applications/TorBrowser-
 old.app/Contents/MacOS/Tor/tor.real
   Expected in: /usr/lib/libSystem.B.dylib

 Trace/BPT trap: 5
 }}}

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

Re: [tor-bugs] #27224 [Core Tor/Tor]: Call node_get_all_orports() less from node_is_a_configured_bridge()

[Tor Bug Tracker & Wiki]

#27224: Call node_get_all_orports() less from node_is_a_configured_bridge()
-+-
 Reporter:  nickm|  Owner:  rl1987
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  035-roadmap-master, 035-triaged- |  implemented
  in-20180711|  Actual Points:
Parent ID:  #26630   | Points:
 Reviewer:  teor |Sponsor:
 |  Sponsor8
-+-
Changes (by nickm):

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


Comment:

 To test this, when I squashed the branch, I tried taking only the unit
 tests, with none of the bridges.c changes, and making sure that they
 passed on the old bridges.c code as well as the new.  They did!  So,
 that's good.

 But then I was worried that you hadn't tested the case where a bridge had
 a matching address but a mismatched digest. In fact, I thought it wouldn't
 work, since I had forgotten how
 `get_configured_bridge_by_addr_port_digest` actually behaved... So I added
 a test for that too -- and the code still passes before and after.

 Nicely done!  I think this code is correct.

 I'm merging `bug27224_take2_squashed` to master now.  It's the same as
 your branch, squashed and rearranged, with an extra test.

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

Re: [tor-bugs] #26146 [Applications/Tor Browser]: Setting `general.useragent.override` does not spoof the platform part anymore in ESR 60 which is confusing

[Tor Bug Tracker & Wiki]

#26146: Setting `general.useragent.override` does not spoof the platform part
anymore in ESR 60 which is confusing
-+-
 Reporter:  gk   |  Owner:  mcs
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, tbb-fingerprinting-os, |  Actual Points:
  tbb-8.0-issues, tbb-8.0.1-can, |
  TorBrowserTeam201809R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by tom):

 Replying to [comment:58 mcs]:
 > Here is a patch for review:
 > https://gitweb.torproject.org/user/brade/tor-
 browser.git/commit/?h=bug26146-01=c8751602f218f40ff243d63de8e8fbcc7e651230
 > Please read the commit message to learn what it does.

 Aside from the exact value of the header, which I did not research the
 correct value for, 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] #27239 [Applications/Tor Browser]: TB team feedback on jump-to-80% work

[Tor Bug Tracker & Wiki]

#27239: TB team feedback on jump-to-80% work
-+-
 Reporter:  isabela  |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  usability, ux, ux-team, bootstrap,   |  Actual Points:
  035-roadmap-master, 035-triaged-in-20180711,   |
  s8-bootstrap, TorBrowserTeam201809 |
Parent ID:  #22266   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by catalyst):

 Added new ticket #27691 which might be a significant behavior change
 (reset to zero progress for "significant" changes) from Tor Launcher's
 perspective.  I'm not sure whether we should try to get it into 0.3.5
 though.

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

Re: [tor-bugs] #27691 [Core Tor/Tor]: reset bootstrap progress when enough things change

[Tor Bug Tracker & Wiki]

#27691: reset bootstrap progress when enough things change
-+-
 Reporter:  catalyst |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  usability, ux, ux-team, bootstrap,   |  Actual Points:
  035-roadmap-master, 035-triaged-in-20180711,   |
  s8-bootstrap   |
Parent ID:  #22266   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by catalyst):

 Upon reviewing the comments in #22266 some more, it seems like users may
 be upset by seeing progress reset to zero after making a configuration
 change.

 I think it's an accurate reflection of what's going on.  Going to the
 config dialog sets DisableNetwork=1 and tears down the circuits and TCP
 connections, which have to be set up again.

 Maybe if there's additional UI in Tor Launcher to show the existence of
 cached directory info, that will make it less likely for users to be
 frustrated by apparently negative progress?  That's a longer term change,
 though.

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

Re: [tor-bugs] #27342 [Core Tor/sbws]: sbws poor error handling

[Tor Bug Tracker & Wiki]

#27342: sbws poor error handling
---+
 Reporter:  gabe   |  Owner:  pastly
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by juga):

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


Comment:

 Fixed #comment:4 in https://github.com/torproject/sbws/pull/258

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

Re: [tor-bugs] #27175 [Applications/Tor Browser]: NoScript plugin does not save per-site permissions/settings when tor browser closes

[Tor Bug Tracker & Wiki]

#27175: NoScript plugin does not save per-site permissions/settings when tor
browser closes
-+-
 Reporter:  tor-user-1234|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  noscript, tbb-regression,|  Actual Points:
  tbb-8.0-issues |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by donnm):

 I think it should be possible to save NoScript preferences across
 sessions. After upgrading from 7.x where this seemed to be the case it is
 irritating to have to disable scripts each time on sites where you do not
 want scripts running. I understand that this can be used for
 fingerprinting, so perhaps the slider idea is the best, and the option is
 opt-in.

 Is there a temporary workaround? Other addons I have installed (yes I am
 aware of the risks) keep settings across sessions.

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

Re: [tor-bugs] #23512 [Core Tor/Tor]: Bandwidth stats info leak upon close of circuits with queued cells (was: Bandwidth stats watermark can be induced using OOM killer)

[Tor Bug Tracker & Wiki]

#23512: Bandwidth stats info leak upon close of circuits with queued cells
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bug-bounty, congestion-attack,   |  Actual Points:
  research, watermark, tor-stats, guard- |
  discovery-stats, 034-triage-20180328,  |
  034-removed-20180328   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-

Comment (by mikeperry):

 Updating the title because this vuln is more general than the oomkiller.
 It can be triggered many, many ways.

 An updated fix for the general issue (based on discussion with dgoulet) is
 at https://github.com/mikeperry-tor/tor/commits/bug23512-v2-032

 I am going to spend a bit seeing if I can use the tests in test_relay.c to
 exercise that code.

 I am ok with this missing 0.3.5.1 for now, but I really think we should
 backport this far enough for relay operators to pick up, though.

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

Re: [tor-bugs] #27108 [Core Tor/sbws]: Implement torflow's scaling method in sbws

[Tor Bug Tracker & Wiki]

#27108: Implement torflow's scaling method in sbws
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords: |  Actual Points:
Parent ID:  #27107 | Points:
 Reviewer: |Sponsor:
---+-
Changes (by juga):

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


Comment:

 Child tickets are now closed

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27692 [Core Tor/sbws]: Update documentation with torflow scaling and other changes

[Tor Bug Tracker & Wiki]

#27692: Update documentation with torflow scaling and other changes
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #27107
   Points: |   Reviewer:
  Sponsor: |
---+-


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

Re: [tor-bugs] #26146 [Applications/Tor Browser]: Setting `general.useragent.override` does not spoof the platform part anymore in ESR 60 which is confusing

[Tor Bug Tracker & Wiki]

#26146: Setting `general.useragent.override` does not spoof the platform part
anymore in ESR 60 which is confusing
-+-
 Reporter:  gk   |  Owner:  mcs
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, tbb-fingerprinting-os, |  Actual Points:
  tbb-8.0-issues, tbb-8.0.1-can, |
  TorBrowserTeam201809R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by watt):

 Replying to [comment:60 mcs]:
 > Replying to [comment:59 watt]:
 > > Replying to [comment:58 mcs]:
 > > > Please read the commit message to learn what it does.
 > > Do you really think "Windows NT 6.1" is WinXP? lol
 >
 > Not any longer :)
 > I confused 5.1 and 6.1.
 ...and platform https://bugzilla.mozilla.org/show_bug.cgi?id=1472618

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

Re: [tor-bugs] #21530 [Core Tor/Tor]: Make ExitRelay 0 the default when there is no exit policy

[Tor Bug Tracker & Wiki]

#21530: Make ExitRelay 0 the default when there is no exit policy
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-exit tor-relay configuration |  Actual Points:
  usability expectations |
Parent ID:   | Points:  1
 Reviewer:  mikeperry|Sponsor:
-+-

Comment (by arma):

 Right, hm. I think the main scenario we want to try to handle is the one
 where a relay operator intends to be running an exit relay, and even
 checked the exit policy on their relay and confirmed that it was what they
 wanted, but they haven't messed with the ExitRelay config option. In this
 case, when they upgrade, their exit policy will silently become something
 different than it used to be, and it would be smart for us to think
 through how they're supposed to learn about this surprise.

 One option would be to make it very obvious in the ChangeLog, like turn it
 into a Major thing rather than a Minor thing. That's good but not enough
 imo.

 Another option would be some log lines to help them know what's happening.
 I think there's a lot to be said for a notice-level log explaining *why*
 we decided to set the exit policy to reject-all.

 We could imagine fancier approaches, like looking at the TorVersion line
 in the state file and giving them a warning if they have the right
 combination of config settings. But doing that warning only once (before
 the TorVersion in the state file gets updated, that is) is risky since
 it's so easy to miss warnings. So I think this approach wouldn't be worth
 building.

 Another option would be to have some script that looks at the network for
 relays that used to be exits using the default exit policy, and then
 stopped being exits when they moved to this new version. Then we contact
 those people to let them know about the potential surprise. That option
 would be a winner except: what do we do about the people who don't set a
 usable ContactInfo?

 Summary: my suggestion would be to add the notice-level log explaining why
 we're opting not to be an exit relay (that log line will be helpful to
 relay operators forever), and then also monitor the network and reach out
 to relays that look like they got hit with this surprise.

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

Re: [tor-bugs] #27338 [Core Tor/sbws]: How long should sbws keep measured and observed bandwidths?

[Tor Bug Tracker & Wiki]

#27338: How long should sbws keep measured and observed bandwidths?
---+-
 Reporter:  teor   |  Owner:  (none)
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords: |  Actual Points:
Parent ID:  #27108 | Points:
 Reviewer: |Sponsor:
---+-
Changes (by juga):

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


Comment:

 Assing child #27346 to parent #27107, since this is implemented

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

Re: [tor-bugs] #27363 [Core Tor/sbws]: Make the sbws node cap a proportion of the capped bandwidth

[Tor Bug Tracker & Wiki]

#27363: Make the sbws node cap a proportion of the capped bandwidth
---+--
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws 1.1
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #27107 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by juga):

 * parent:   => #27107


Comment:

 Assign parent #27107

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27691 [Core Tor/Tor]: reset bootstrap progress when enough things change

[Tor Bug Tracker & Wiki]

#27691: reset bootstrap progress when enough things change
-+-
 Reporter:   |  Owner:  (none)
  catalyst   |
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  usability, ux, ux-team, bootstrap,
 Severity:  Normal   |  035-roadmap-master, 035-triaged-in-20180711,
 |  s8-bootstrap
Actual Points:   |  Parent ID:  #22266
   Points:   |   Reviewer:
  Sponsor:   |
  Sponsor8   |
-+-
 Right now, setting DisableNetwork=1 doesn't reset the bootstrap progress
 indicator.  It probably should, because all network connections to bridges
 or relays will close.  This will improve the user experience once we have
 #27103 in place, because then the earlier progress shown will be the
 initial network connection that everything else depends on.

 We probably also want to reset the bootstrap progress when a configuration
 change causes us to disconnect from all our guards.

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

Re: [tor-bugs] #27346 [Core Tor/sbws]: Improve sbws bandwidth accuracy

[Tor Bug Tracker & Wiki]

#27346: Improve sbws bandwidth accuracy
---+--
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws 1.1
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #27107 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by juga):

 * parent:  #27338 => #27107


Comment:

 Change parent to #27107, since #27338 is implemented

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

Re: [tor-bugs] #27338 [Core Tor/sbws]: How long should sbws keep measured and observed bandwidths?

[Tor Bug Tracker & Wiki]

#27338: How long should sbws keep measured and observed bandwidths?
---+-
 Reporter:  teor   |  Owner:  (none)
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #27108 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by juga):

 Implemented in https://github.com/torproject/sbws/pull/256

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27690 [Core Tor/Tor]: Update bandwidth-file-spec with scaling methods

[Tor Bug Tracker & Wiki]

#27690: Update bandwidth-file-spec with scaling methods
--+--
 Reporter:  juga  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-spec, tor-bwauth
Actual Points:|  Parent ID:  #27107
   Points:|   Reviewer:
  Sponsor:|
--+--
 As commented in #27338, and implemented in #27337 and #27336 we should
 update the spec with the scaling method we would use.
 Since currently it's possible to generate the bandwidth files using
 different scaling methods, we should first decide which one to use during
 the transition from torflow to sbws and which one we would use after the
 transition.

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

Re: [tor-bugs] #17873 [Core Tor/Tor]: replacing 0.0.0.0 listeners at runtime fails

[Tor Bug Tracker & Wiki]

#17873: replacing 0.0.0.0 listeners at runtime fails
-+-
 Reporter:  cypherpunks  |  Owner:  rl1987
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, port, bind, switching,   |  implemented
  035-triaged-in-20180711|  Actual Points:
Parent ID:   | Points:
 Reviewer:  ahf  |Sponsor:
-+-

Comment (by nickm):

 Incidentally, I thought you might like to know: The tests on this branch
 increased our overall coveralls.io test coverage by 1.73%.  (Nice!)

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

Re: [tor-bugs] #26146 [Applications/Tor Browser]: Setting `general.useragent.override` does not spoof the platform part anymore in ESR 60 which is confusing

[Tor Bug Tracker & Wiki]

#26146: Setting `general.useragent.override` does not spoof the platform part
anymore in ESR 60 which is confusing
-+-
 Reporter:  gk   |  Owner:  mcs
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, tbb-fingerprinting-os, |  Actual Points:
  tbb-8.0-issues, tbb-8.0.1-can, |
  TorBrowserTeam201809R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:59 watt]:
 > Replying to [comment:58 mcs]:
 > > Please read the commit message to learn what it does.
 > Do you really think "Windows NT 6.1" is WinXP? lol

 Not any longer :)
 I confused 5.1 and 6.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] #23846 [Core Tor/Tor]: Option to build Tor with -fPIC (Use libtool for building shared library?)

[Tor Bug Tracker & Wiki]

#23846: Option to build Tor with -fPIC (Use libtool for building shared 
library?)
-+-
 Reporter:  hellais  |  Owner:  nickm
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, s8-api,  |  implemented
  034-triage-20180328, 034-included-20180402,|  Actual Points:
  034-roadmap-subtask, 035-roadmap-subtask, 035  |
  -triaged-in-20180711   |
Parent ID:  #25510   | Points:
 Reviewer:  ahf  |Sponsor:
 |  Sponsor8
-+-
Changes (by nickm):

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


Comment:

 Okay -- I've added comments to explain my thinking there, and merged to
 master.  Thanks!

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

Re: [tor-bugs] #27688 [Core Tor/sbws]: Easy graph generation and obtain statistics

[Tor Bug Tracker & Wiki]

#27688: Easy graph generation and obtain statistics
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords: |  Actual Points:
Parent ID:  #27108 | Points:
 Reviewer: |Sponsor:
---+-
Changes (by juga):

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


Comment:

 Implemented in https://github.com/torproject/sbws/pull/253

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

Re: [tor-bugs] #27336 [Core Tor/sbws]: Does sbws need a node cap?

[Tor Bug Tracker & Wiki]

#27336: Does sbws need a node cap?
---+-
 Reporter:  teor   |  Owner:  juga
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords: |  Actual Points:
Parent ID:  #27107 | Points:
 Reviewer: |Sponsor:
---+-
Changes (by juga):

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


Comment:

 Removed child #27363 since it does not need to be implemented for the MVP

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

Re: [tor-bugs] #27363 [Core Tor/sbws]: Make the sbws node cap a proportion of the capped bandwidth

[Tor Bug Tracker & Wiki]

#27363: Make the sbws node cap a proportion of the capped bandwidth
---+--
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws 1.1
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by juga):

 * parent:  #27336 =>


Comment:

 Remove parent #27336, since the parent is implemented for the MVP, and
 this does not need to be implemented for the MVP

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

Re: [tor-bugs] #27108 [Core Tor/sbws]: Implement torflow's scaling method in sbws

[Tor Bug Tracker & Wiki]

#27108: Implement torflow's scaling method in sbws
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #27107 | Points:
 Reviewer: |Sponsor:
---+-
Changes (by juga):

 * status:  needs_review => accepted


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

Re: [tor-bugs] #27135 [Core Tor/sbws]: Write descriptor bandwidths average in raw results

[Tor Bug Tracker & Wiki]

#27135: Write descriptor bandwidths average in raw results
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords: |  Actual Points:
Parent ID:  #27108 | Points:
 Reviewer: |Sponsor:
---+-
Changes (by juga):

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


Comment:

 Implemented in https://github.com/torproject/sbws/pull/251

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

Re: [tor-bugs] #27337 [Core Tor/sbws]: Round relay bandwidths in bandwidth files

[Tor Bug Tracker & Wiki]

#27337: Round relay bandwidths in bandwidth files
---+-
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords: |  Actual Points:
Parent ID:  #27108 | Points:
 Reviewer: |Sponsor:
---+-
Changes (by juga):

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


Comment:

 Implemented in https://github.com/torproject/sbws/pull/255
 Created #27689 to implement what is commented in #comment:3

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

[tor-bugs] #27689 [Core Tor/sbws]: Round bandwidth in bandwidth files with other algorithm

[Tor Bug Tracker & Wiki]

#27689: Round bandwidth in bandwidth files with other algorithm
---+
 Reporter:  juga   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/sbws  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 as commented in
 https://trac.torproject.org/projects/tor/ticket/27337#comment:3

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

Re: [tor-bugs] #23846 [Core Tor/Tor]: Option to build Tor with -fPIC (Use libtool for building shared library?)

[Tor Bug Tracker & Wiki]

#23846: Option to build Tor with -fPIC (Use libtool for building shared 
library?)
-+-
 Reporter:  hellais  |  Owner:  nickm
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, s8-api,  |  Actual Points:
  034-triage-20180328, 034-included-20180402,|
  034-roadmap-subtask, 035-roadmap-subtask, 035  |
  -triaged-in-20180711   |
Parent ID:  #25510   | Points:
 Reviewer:  ahf  |Sponsor:
 |  Sponsor8
-+-
Changes (by dgoulet):

 * status:  needs_review => needs_information


Comment:

 Quick question on the PR. Else 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] #26146 [Applications/Tor Browser]: Setting `general.useragent.override` does not spoof the platform part anymore in ESR 60 which is confusing

[Tor Bug Tracker & Wiki]

#26146: Setting `general.useragent.override` does not spoof the platform part
anymore in ESR 60 which is confusing
-+-
 Reporter:  gk   |  Owner:  mcs
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, tbb-fingerprinting-os, |  Actual Points:
  tbb-8.0-issues, tbb-8.0.1-can, |
  TorBrowserTeam201809R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by watt):

 Replying to [comment:58 mcs]:
 > Please read the commit message to learn what it does.
 Do you really think "Windows NT 6.1" is WinXP? lol

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

Re: [tor-bugs] #27336 [Core Tor/sbws]: Does sbws need a node cap?

[Tor Bug Tracker & Wiki]

#27336: Does sbws need a node cap?
---+-
 Reporter:  teor   |  Owner:  juga
 Type:  enhancement| Status:  accepted
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #27107 | Points:
 Reviewer: |Sponsor:
---+-
Changes (by juga):

 * status:  needs_review => accepted
 * owner:  (none) => juga


Comment:

 Implemented in https://github.com/torproject/sbws/pull/254.

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

Re: [tor-bugs] #27601 [Applications/Tor Browser]: growl a-like browser notifications are not working anymore on macOS with Tor Browser 8

[Tor Bug Tracker & Wiki]

#27601: growl a-like browser notifications are not working anymore on macOS with
Tor Browser 8
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-8.0-issues, tbb-regression,  |  Actual Points:
  tbb-8.0.1-can  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Kathy and I did some triage of this ticket because we thought it might be
 a macOS-only bug, but that is probably not true. It seems to be related to
 first party isolation of permissions. Using the following page for
 testing, notifications started to work after I changed
 `privacy.firstparty.isolate` to `false`:
 https://developer.mozilla.org/en-US/docs/Web/API/notification

 On that page, grant permission for notifications when prompted and then
 click the "Notify me!" button.

 Arthur, any ideas?

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

Re: [tor-bugs] #26470 [Core Tor/Tor]: WARN: Saying "HTTP/1.0 405 Method Not Allowed\r\n\r\n" WARN: connection_mark_unattached_ap_(): Bug: stream (marked at src/or/connection_edge.c:2551) sending two s

[Tor Bug Tracker & Wiki]

#26470: WARN: Saying "HTTP/1.0 405 Method Not Allowed\r\n\r\n"  WARN:
connection_mark_unattached_ap_(): Bug: stream (marked at
src/or/connection_edge.c:2551) sending two socks replies? (on Tor
0.3.3.5-rc 81d71f0d41adf0d8)
-+-
 Reporter:  Tai683   |  Owner:  nickm
 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:  Minor| Resolution:
 Keywords:  032-backport 033-backport|  Actual Points:
  034-backport fast-fix  |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Merging to master; marking for  backport.

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

Re: [tor-bugs] #27678 [Core Tor/Tor]: Emit CIRC_BW event early for dropped cells

[Tor Bug Tracker & Wiki]

#27678: Emit CIRC_BW event early for dropped cells
--+
 Reporter:  mikeperry |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by mikeperry):

 Ok I addressed asn's questions and requests for clarifying code comments
 in that PR. I pushed fixups to mikeperry-github/ticket27678 and mentioned
 the fixups in the PR.

 https://github.com/torproject/tor/pull/329 is the new PR with the squashed
 branch mikeperry-github/ticket27678-squashed (0 delta to mikeperry-
 github/ticket27678).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27688 [Core Tor/sbws]: Easy graph generation and obtain statistics

[Tor Bug Tracker & Wiki]

#27688: Easy graph generation and obtain statistics
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #27108
   Points: |   Reviewer:
  Sponsor: |
---+-
 to compare with current torflow results.

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

Re: [tor-bugs] #27108 [Core Tor/sbws]: Implement torflow's scaling method in sbws

[Tor Bug Tracker & Wiki]

#27108: Implement torflow's scaling method in sbws
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #27107 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by juga):

 Implemented in https://github.com/torproject/sbws/pull/252.

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

Re: [tor-bugs] #27186 [Core Tor/Tor]: Inform users about configuration file and directory includes

[Tor Bug Tracker & Wiki]

#27186: Inform users about configuration file and directory includes
--+
 Reporter:  UntoSten  |  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Low   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:  implemented
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by nickm):

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


Comment:

 added a changes file and merged.  I think we'll want to tweak the wording
 over time, but having this message is a strict improvement over not having
 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] #26470 [Core Tor/Tor]: WARN: Saying "HTTP/1.0 405 Method Not Allowed\r\n\r\n" WARN: connection_mark_unattached_ap_(): Bug: stream (marked at src/or/connection_edge.c:2551) sending two s

[Tor Bug Tracker & Wiki]

#26470: WARN: Saying "HTTP/1.0 405 Method Not Allowed\r\n\r\n"  WARN:
connection_mark_unattached_ap_(): Bug: stream (marked at
src/or/connection_edge.c:2551) sending two socks replies? (on Tor
0.3.3.5-rc 81d71f0d41adf0d8)
-+-
 Reporter:  Tai683   |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.5-rc
 Severity:  Minor| Resolution:
 Keywords:  032-backport 033-backport|  Actual Points:
  034-backport fast-fix  |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

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


Comment:

 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] #27630 [Core Tor/Tor]: use strcmpstart() in rend_parse_v2_service_descriptor

[Tor Bug Tracker & Wiki]

#27630: use strcmpstart() in rend_parse_v2_service_descriptor
--+
 Reporter:  cyberpunks|  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:|  Actual Points:
Parent ID:  #27629| Points:
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by nickm):

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


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] #26146 [Applications/Tor Browser]: Setting `general.useragent.override` does not spoof the platform part anymore in ESR 60 which is confusing

[Tor Bug Tracker & Wiki]

#26146: Setting `general.useragent.override` does not spoof the platform part
anymore in ESR 60 which is confusing
-+-
 Reporter:  gk   |  Owner:  mcs
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, tbb-fingerprinting-os, |  Actual Points:
  tbb-8.0-issues, tbb-8.0.1-can, |
  TorBrowserTeam201809R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * keywords:  ff60-esr, tbb-fingerprinting-os, tbb-8.0-issues, tbb-8.0.1-can
 =>
 ff60-esr, tbb-fingerprinting-os, tbb-8.0-issues, tbb-8.0.1-can,
 TorBrowserTeam201809R
 * status:  assigned => needs_review


Comment:

 Here is a patch for review:
 https://gitweb.torproject.org/user/brade/tor-
 browser.git/commit/?h=bug26146-01=c8751602f218f40ff243d63de8e8fbcc7e651230
 Please read the commit message to learn what it 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] #23512 [Core Tor/Tor]: Bandwidth stats watermark can be induced using OOM killer

[Tor Bug Tracker & Wiki]

#23512: Bandwidth stats watermark can be induced using OOM killer
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bug-bounty, congestion-attack,   |  Actual Points:
  research, watermark, tor-stats, guard- |
  discovery-stats, 034-triage-20180328,  |
  034-removed-20180328   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-
Changes (by dgoulet):

 * status:  needs_review => needs_revision


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

Re: [tor-bugs] #23512 [Core Tor/Tor]: Bandwidth stats watermark can be induced using OOM killer

[Tor Bug Tracker & Wiki]

#23512: Bandwidth stats watermark can be induced using OOM killer
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bug-bounty, congestion-attack,   |  Actual Points:
  research, watermark, tor-stats, guard- |
  discovery-stats, 034-triage-20180328,  |
  034-removed-20180328   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-

Comment (by dgoulet):

 After discussion with mike on IRC, we'll go back in revision mode for a
 series of fixes.

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

Re: [tor-bugs] #27386 [Core Tor/sbws]: Move scaling method inside V3BWFile

[Tor Bug Tracker & Wiki]

#27386: Move scaling method inside V3BWFile
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords: |  Actual Points:
Parent ID:  #27108 | Points:
 Reviewer: |Sponsor:
---+-
Changes (by juga):

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


Comment:

 https://github.com/torproject/sbws/pull/251

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

Re: [tor-bugs] #27685 [Core Tor/Tor]: Memory leak in tortls/openssl/context_new

[Tor Bug Tracker & Wiki]

#27685: Memory leak in tortls/openssl/context_new
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 merged!

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

Re: [tor-bugs] #27684 [Core Tor/Tor]: Memory leak in tortls/openssl/try_to_extract_certs_from_tls

[Tor Bug Tracker & Wiki]

#27684: Memory leak in tortls/openssl/try_to_extract_certs_from_tls
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 merged!

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

Re: [tor-bugs] #27655 [Core Tor/Tor]: TB 8.5a1 fails to load reachable onion services

[Tor Bug Tracker & Wiki]

#27655: TB 8.5a1 fails to load reachable onion services
--+---
 Reporter:  traumschule   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by traumschule):

 * component:  Applications/Tor Browser => Core Tor/Tor


Comment:

 i boldly claim that this issue is not caused by TB, but is inherent in
 tor's network architecture, because it regularly happens with tor nightly
 as well:

 {{{
 ~/tor/webwml$ torsocks git pull
 1536852541 ERROR torsocks[22353]: Connection timed out (in
 socks5_recv_connect_reply() at socks5.c:553)
 fatal: unable to access
 'http://dccbbv6cooddgcrq.onion/project/web/webwml.git/': Couldn't connect
 to server
 ~/tor/webwml$ torsocks git pull
 1536858225 ERROR torsocks[22766]: Connection timed out (in
 socks5_recv_connect_reply() at socks5.c:553)
 fatal: unable to access
 'http://dccbbv6cooddgcrq.onion/project/web/webwml.git/': Couldn't connect
 to server
 }}}

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

Re: [tor-bugs] #27386 [Core Tor/sbws]: Move scaling method inside V3BWFile

[Tor Bug Tracker & Wiki]

#27386: Move scaling method inside V3BWFile
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #27108 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by juga):

 https://github.com/torproject/sbws/pull/251

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

Re: [tor-bugs] #27685 [Core Tor/Tor]: Memory leak in tortls/openssl/context_new

[Tor Bug Tracker & Wiki]

#27685: Memory leak in tortls/openssl/context_new
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by ahf):

 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] #27630 [Core Tor/Tor]: use strcmpstart() in rend_parse_v2_service_descriptor

[Tor Bug Tracker & Wiki]

#27630: use strcmpstart() in rend_parse_v2_service_descriptor
--+
 Reporter:  cyberpunks|  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #27629| Points:
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by dgoulet):

 * reviewer:   => dgoulet


Comment:

 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] #27684 [Core Tor/Tor]: Memory leak in tortls/openssl/try_to_extract_certs_from_tls

[Tor Bug Tracker & Wiki]

#27684: Memory leak in tortls/openssl/try_to_extract_certs_from_tls
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by ahf):

 * status:  assigned => merge_ready


Comment:

 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] #27684 [Core Tor/Tor]: Memory leak in tortls/openssl/try_to_extract_certs_from_tls

[Tor Bug Tracker & Wiki]

#27684: Memory leak in tortls/openssl/try_to_extract_certs_from_tls
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Please see branch `bug27684` for the fix to this one.

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

Re: [tor-bugs] #27685 [Core Tor/Tor]: Memory leak in tortls/openssl/context_new

[Tor Bug Tracker & Wiki]

#27685: Memory leak in tortls/openssl/context_new
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  assigned => needs_review


Comment:

 Fix for this one in branch `bug27685`.

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

Re: [tor-bugs] #27684 [Core Tor/Tor]: Memory leak in tortls/openssl/try_to_extract_certs_from_tls

[Tor Bug Tracker & Wiki]

#27684: Memory leak in tortls/openssl/try_to_extract_certs_from_tls
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 These tests are only run on openssl <= 1.0.2

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

Re: [tor-bugs] #27687 [Core Tor/Tor]: rust protover accepts non ASCII in protocol names

[Tor Bug Tracker & Wiki]

#27687: rust protover accepts non ASCII in protocol names
-+-
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, protover, 033-backport,|  Actual Points:
  034-backport   |
Parent ID:  #27316   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cyberpunks):

 See branch rust-protokeyword1 at ​https://gitgud.io/onionk/tor.git

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