Re: [tor-bugs] #16606 [Applications/Tor Messenger]: Temporary XMPP accounts

[Tor Bug Tracker & Wiki]

#16606: Temporary XMPP accounts
+
 Reporter:  cypherpunks |  Owner:  (none)
 Type:  enhancement | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by sukhbir):

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


Comment:

 We can always improve this later, but I am happy that we have basic
 support for this feature: XMPP accounts with randomly generated username
 and passwords and automatic in-band registration.

 [https://gitweb.torproject.org/tor-messenger-
 build.git/commit/?id=a0c459f20779f10a13d9045ae7ef63efeb8423e5 a0c459f]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23293 [Internal Services/Tor Sysadmin Team]: Add Steph, our Comms Director, to grants@ email alias

[Tor Bug Tracker & Wiki]

#23293: Add Steph, our Comms Director, to grants@ email alias
-+-
 Reporter:  t0mmy|  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Comms stuff comes up in grant applications from time to time, so it'd be
 useful for Steph to be able to follow the conversations. She's
 st...@torproject.org.

 Thx!

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

Re: [tor-bugs] #23145 [Applications/Orbot]: Orfox UserAgent is very old. Please upgrade to modern version (52 or above).

[Tor Bug Tracker & Wiki]

#23145: Orfox UserAgent is very old. Please upgrade to modern version (52 or
above).
+---
 Reporter:  cypherpunks |  Owner:  n8fr8
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:  duplicate
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
Changes (by cypherpunks):

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


Comment:

 duplicate of #23144

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

Re: [tor-bugs] #22543 [Applications/Tor Browser]: Tor Browser 7.0 shows window resize warning on every new window for a few seconds

[Tor Bug Tracker & Wiki]

#22543: Tor Browser 7.0 shows window resize warning on every new window for a 
few
seconds
-+-
 Reporter:  teor |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-7.0-issues, tbb-   |  Actual Points:
  regression |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 See #22989 for a fix to all of the above-mentioned issues.

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

Re: [tor-bugs] #22989 [Applications/Tor Browser]: TBB Size 1000x610 Mac

[Tor Bug Tracker & Wiki]

#22989: TBB Size 1000x610 Mac
-+-
 Reporter:  Dbryrtfbcbhgf|  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-fingerprinting-resolution, tbb-  |  Actual Points:
  torbutton, TorBrowserTeam201708R   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 Replying to [comment:20 cypherpunks]:
 > Does this also fix #22543?

 Yes, my testing indicates that it does fix that ticket as well as the
 issues in ticket:22543#comment:2 and ticket:22543#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] #23292 [Applications/Tor Browser]: Noscript does not stop a web video's audio from playing even though it is blocked

[Tor Bug Tracker & Wiki]

#23292: Noscript does not stop a web video's audio from playing even though it 
is
blocked
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by Dbryrtfbcbhgf):

 * Attachment "yes.avi.2pass.webmvp8.webm" added.


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

[tor-bugs] #23292 [Applications/Tor Browser]: Noscript does not stop a web video's audio from playing even though it is blocked

[Tor Bug Tracker & Wiki]

#23292: Noscript does not stop a web video's audio from playing even though it 
is
blocked
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Noscript does not stop a webm video's audio from playing even though it is
 blocked, and Tor Browser Bundle's security setting is set to high.

 1. Open Tor Browser Bundle.

 2. Set its security to high.

 3. Drag the webm that I attached onto Tor Browser Bundle.

 4. The audio of the video should play even though it should be blocked.

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

Re: [tor-bugs] #17242 [Core Tor/Tor]: prop224: Implement client support

[Tor Bug Tracker & Wiki]

#17242: prop224: Implement client support
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  enhancement   | Status:
  |  needs_review
 Priority:  Very High |  Milestone:  Tor:
  |  0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, prop224, review-group-22  |  Actual Points:
Parent ID:  #12424| Points:  parent
 Reviewer:|Sponsor:  SponsorR-
  |  must
--+

Comment (by nickm):

 status: I have reviewed up to but not including a3d7f53b

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

Re: [tor-bugs] #22974 [Applications/Tor Browser]: NoScript (and Tor Browser) vulnerable to Mozilla Add-On Code Execution

[Tor Bug Tracker & Wiki]

#22974: NoScript (and Tor Browser) vulnerable to Mozilla Add-On Code Execution
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [comment:4 cypherpunks]:
 > Replying to [comment:2 gk]:
 > > That's the plan. We'll start with HTTPS-Everywhere (hopefully soon,
 #10394 is the ticket for that) and do the same with NoScript afterwards.
 >
 > I'm all for that, but how will you deal with HTTPS-Everywhere ruleset
 updates? In many cases, some sites may break with HTTPS-E and have
 subsequent ruleset updates that fix them. With one HTTPS-E update
 corresponding to a TB release, it would mean that for quiet some time (~2
 months) some sites may be broken with TB.

 Yes, which is why we did not do that step yet. HTTPS-Everywhere will have
 a ruleset updater. Once this is ready we'll stop letting HTTPS-Everywhere
 update itself once a new version is out.

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

Re: [tor-bugs] #23258 [Applications/Tor Browser]: HTTPS Everywhere is not working when noscript is enabled globally

[Tor Bug Tracker & Wiki]

#23258: HTTPS Everywhere is not working when noscript is enabled globally
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  TorBrowserTeam201708  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [comment:33 legind]:
 > With NoScript, much of the code is still in the XPCOM wrapper.  That's
 why it continues to work.
 >
 > On all pure WebExtensions I've tested in ESR with JavaScript disabled,
 I've seen the same result.  I've tested with uBlock Origin, Disconnect,
 Ghostery, Privacy Badger.  All the same: no functionality, unresponsive.
 >
 > As I've mentioned the way to fix this is to pick one of the following:
 >
 > 1. Backport the Firefox 54 fix to Tor Browser
 > 2. Wait for Firefox to backport the fix, which given their
 responsiveness lately I doubt will be very effective
 > 3. Make a new TB release with `5.2.21`, removing the update channel and
 using the new rulesets in `2017.8.19`.
 >
 > Option 3 is out of my hands, but I've provided build instructions above.
 Of course I'm willing to help if you run into any issues.

 Thanks. My current plan is to backport the patch and, after some testing,
 get a new stable release out (probably next week).

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

Re: [tor-bugs] #23276 [Core Tor/Tor]: RELAY_CONNECTED cells responding to RELAY_BEGIN_DIR cells don't have a payload

[Tor Bug Tracker & Wiki]

#23276: RELAY_CONNECTED cells responding to RELAY_BEGIN_DIR cells don't have a
payload
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  tor-spec, review-group-22  |  Actual Points:
Parent ID:  #18856 | Points:  0.2
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

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


Comment:

 done in 24fe028fbfd594ad559254b67243a26d6838a457

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

Re: [tor-bugs] #22891 [Core Tor/Tor]: Add GitLab CI configs

[Tor Bug Tracker & Wiki]

#22891: Add GitLab CI configs
-+-
 Reporter:  catalyst |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ci, continuous-integration,  |  Actual Points:
  testing, best-practice, unit-testing, new- |
  developers, review-group-22|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by hiro):

 * cc: dgoulet, ahf (added)


Comment:

 Yes, the idea is that you can run a set of task inside a container. This
 tasks include tests and build and also syncing from torgit master.

 I think ahf and dgoulet might be able to evaluate if this is what they
 wanted to begin with.

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

Re: [tor-bugs] #23258 [Applications/Tor Browser]: HTTPS Everywhere is not working when noscript is enabled globally

[Tor Bug Tracker & Wiki]

#23258: HTTPS Everywhere is not working when noscript is enabled globally
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  TorBrowserTeam201708  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by legind):

 With NoScript, much of the code is still in the XPCOM wrapper.  That's why
 it continues to work.

 On all pure WebExtensions I've tested in ESR with JavaScript disabled,
 I've seen the same result.  I've tested with uBlock Origin, Disconnect,
 Ghostery, Privacy Badger.  All the same: no functionality, unresponsive.

 As I've mentioned the way to fix this is to pick one of the following:

 1. Backport the Firefox 54 fix to Tor Browser
 2. Wait for Firefox to backport the fix, which given their responsiveness
 lately I doubt will be very effective
 3. Make a new TB release with `5.2.21`, removing the update channel and
 using the new rulesets in `2017.8.19`.

 Option 3 is out of my hands, but I've provided build instructions above.
 Of course I'm willing to help if you run into any issues.

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

Re: [tor-bugs] #22839 [Core Tor/Tor]: Build tor with Rust code enabled on Windows

[Tor Bug Tracker & Wiki]

#22839: Build tor with Rust code enabled on Windows
-+-
 Reporter:  isis |  Owner:  snoek
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, windows, tor-build, review-|  Actual Points:
  group-22   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorZ
-+-

Comment (by nickm):

 I've opened a separate ticket for the test-memwipe fix, and backported the
 commit for it: #23291 .

 The remaining commit to review here is
 15bd1dba51cddceb526909e13c25be1990427541.  I'm cherry-picking that one to
 master as 2e99f839e97e2b.  Thanks!

 Is this ticket ready to close?

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

Re: [tor-bugs] #23291 [Core Tor/Tor]: unintentional undefined behaviore in test-memwipe.c

[Tor Bug Tracker & Wiki]

#23291: unintentional undefined behaviore in test-memwipe.c
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  028-backport 029-backport|  Actual Points:
  030-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 I've cherry-picked the patch into a new branch with a changes file, as
 `bug23291_028` in my public repository.  I'm merging it to 0.3.1 and
 forward, but maybe we want to backport it more?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23291 [Core Tor/Tor]: unintentional undefined behaviore in test-memwipe.c

[Tor Bug Tracker & Wiki]

#23291: unintentional undefined behaviore in test-memwipe.c
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 While working on #22839, snoek found a bug in test-memwipe.c:

 >The last test, test_memwipe, segfaulted. This only happened with Rust
 built in. It turns out this was caused by the uninitialized buf in
 check_heap_buffer being smaller than the mem addresses being scanned. I
 know we're doing some dirty stuff there, but I don't think trying to read
 past the length of the buffer was intended. At least to me it seems fair
 enough for the program to segfault. I put in the obvious fix, which might
 be horribly wrong.


 It looks fine to me, so I'm going to give it a bug number and backport 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] #22891 [Core Tor/Tor]: Add GitLab CI configs

[Tor Bug Tracker & Wiki]

#22891: Add GitLab CI configs
-+-
 Reporter:  catalyst |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ci, continuous-integration,  |  Actual Points:
  testing, best-practice, unit-testing, new- |
  developers, review-group-22|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Hm. I don't know all the docker+ssh stuff, so I'll assume it's right. The
 rest seems plausible.

 What does this imply for people's branches when uploaded to gitlab?
 Everything builds inside a container?

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

Re: [tor-bugs] #23258 [Applications/Tor Browser]: HTTPS Everywhere is not working when noscript is enabled globally

[Tor Bug Tracker & Wiki]

#23258: HTTPS Everywhere is not working when noscript is enabled globally
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  TorBrowserTeam201708  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by boklm):

 #23290 is 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

Re: [tor-bugs] #23290 [HTTPS Everywhere/EFF-HTTPS Everywhere]: https-everywhere windows breaksup

[Tor Bug Tracker & Wiki]

#23290: https-everywhere windows breaksup
-+-
 Reporter:  cypherpunks  |  Owner:  jsha
 Type:  defect   | Status:  closed
 Priority:  Immediate|  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere | Resolution:
 Severity:  Critical |  duplicate
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

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


Comment:

 This is a duplicate of #23258.

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

Re: [tor-bugs] #23233 [Core Tor/Tor]: Unexpected BUG violation in hsv3 decriptor decoding

[Tor Bug Tracker & Wiki]

#23233: Unexpected BUG violation in hsv3 decriptor decoding
-+-
 Reporter:  haxxpop  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, easy, tor-hs, 031-backport  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorR-must
-+-
Changes (by nickm):

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


Comment:

 (We'll need to backport to 0.3.0 as well if it turns out that these
 warnings happen in practice: otherwise people will freak out.)

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

Re: [tor-bugs] #23233 [Core Tor/Tor]: Unexpected BUG violation in hsv3 decriptor decoding

[Tor Bug Tracker & Wiki]

#23233: Unexpected BUG violation in hsv3 decriptor decoding
-+-
 Reporter:  haxxpop  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, easy, tor-hs, 031-backport  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorR-must
-+-

Comment (by nickm):

 ok, merged to 0.3.1.

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

Re: [tor-bugs] #23290 [HTTPS Everywhere/EFF-HTTPS Everywhere]: https-everywhere windows breaksup

[Tor Bug Tracker & Wiki]

#23290: https-everywhere windows breaksup
---+--
 Reporter:  cypherpunks|  Owner:  jsha
 Type:  defect | Status:  new
 Priority:  Immediate  |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS Everywhere  |Version:
 Severity:  Critical   | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cypherpunks):

 * Attachment "https-everywhere breaksup windows.jpg" added.


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

[tor-bugs] #23290 [HTTPS Everywhere/EFF-HTTPS Everywhere]: https-everywhere windows breaksup

[Tor Bug Tracker & Wiki]

#23290: https-everywhere windows breaksup
---+--
 Reporter:  cypherpunks|  Owner:  jsha
 Type:  defect | Status:  new
 Priority:  Immediate  |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS Everywhere  |Version:
 Severity:  Critical   |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 https-everywhere is not working inside TBB windows version whether the
 stable or the tester.

 find out the attached photo.

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

Re: [tor-bugs] #22974 [Applications/Tor Browser]: NoScript (and Tor Browser) vulnerable to Mozilla Add-On Code Execution

[Tor Bug Tracker & Wiki]

#22974: NoScript (and Tor Browser) vulnerable to Mozilla Add-On Code Execution
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:2 gk]:
 > That's the plan. We'll start with HTTPS-Everywhere (hopefully soon,
 #10394 is the ticket for that) and do the same with NoScript afterwards.

 I'm all for that, but how will you deal with HTTPS-Everywhere ruleset
 updates? In many cases, some sites may break with HTTPS-E and have
 subsequent ruleset updates that fix them. With one HTTPS-E update
 corresponding to a TB release, it would mean that for quiet some time (~2
 months) some sites may be broken with TB.

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

Re: [tor-bugs] #17381 [Applications/Tor Browser]: Adapting the gitian/*.sh release scripts

[Tor Bug Tracker & Wiki]

#17381: Adapting the gitian/*.sh release scripts
--+---
 Reporter:  boklm |  Owner:  boklm
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #17379| Points:
 Reviewer:|Sponsor:
--+---

Comment (by boklm):

 The `incrementals`, `update_responses` and `dmg2mar` makefile targets have
 been added by commits de3f97f325df5465fa49b7c8ca2ff229b670b207,
 a510614a08cedcb99a03329acb8fa0bd165314e6 and
 93bb526421830f185c431d9064043e54c38d6bab.

 The makefile rules that are still missing are `signmar`, `sign` and
 `match`.

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

Re: [tor-bugs] #23105 [Core Tor/Tor]: Bug: outgoing relay cell sent from src/or/relay.c:836 has n_chan==NULL.

[Tor Bug Tracker & Wiki]

#23105: Bug: outgoing relay cell sent from src/or/relay.c:836 has n_chan==NULL.
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.5-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by cypherpunks):

 * version:  Tor: 0.3.1.4-alpha => Tor: 0.3.1.5-alpha


Comment:

 Got (again) the exact same [warn] messages 5 times right before a

 {{{Your network connection speed appears to have changed. Resetting
 timeout to 60s after 18 timeouts and 355 buildtimes.}}}

 Not sure if this was due to that, anyway the [warn] message said,

 {{{[warn] circuit_package_relay_cell(): Bug: outgoing relay cell sent from
 src/or/relay.c:836 has n_chan==NULL. Dropping. (on Tor 0.3.1.5-alpha
 83389502ee631465)}}}

 So I'm putting {{{Tor 0.3.1.5-alpha}}} as the version.

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

Re: [tor-bugs] #22779 [Core Tor/Tor]: choose_good_entry_server() is no longer used to choose entry guards

[Tor Bug Tracker & Wiki]

#22779: choose_good_entry_server() is no longer used to choose entry guards
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  maybe-030-backport, review-group-22  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:  asn  |Sponsor:
 |  SponsorV
-+-
Changes (by asn):

 * reviewer:   => asn


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

Re: [tor-bugs] #19418 [Core Tor/Tor]: i2d_RSAPublicKey retval ignored in multiple callsites

[Tor Bug Tracker & Wiki]

#19418: i2d_RSAPublicKey retval ignored in multiple callsites
-+-
 Reporter:  asn  |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bug-bounty, disaster-waiting-|  Actual Points:
  to-happen, review-group-22 |
Parent ID:   | Points:  0.5
 Reviewer:  asn  |Sponsor:
 |  SponsorV-can
-+-
Changes (by asn):

 * reviewer:   => asn


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

Re: [tor-bugs] #23123 [Core Tor/Tor]: Cannibalized HS circuit don't have their timestamp_dirty updated

[Tor Bug Tracker & Wiki]

#23123: Cannibalized HS circuit don't have their timestamp_dirty updated
-+
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-circuit  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by dgoulet):

 * cc: mikeperry, arma (added)


Comment:

 CCing couple of people that could help review the proposed fix.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23289 [Applications/Orbot]: Improving HS reachability in Orbot/Android

[Tor Bug Tracker & Wiki]

#23289: Improving HS reachability in Orbot/Android
+
 Reporter:  n8fr8   |  Owner:  n8fr8
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  |   Keywords:  orbot, mobile, android
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+
 Orbot received a pull request here: https://github.com/n8fr8/orbot/pull/83
 with proposed modifications to improve reachability of an HS running on
 the device. We asked Michael Rogers from the Briar Project to review this
 proposal, since his team has done the most with HS on mobile. The PR
 details and his comments are inline below.

 While these improvements seem worthwhile from a usability perspective,
 there are concerns about impact on anonymity, as always.

 

 The issue at the moment is that while the device is sleeping for long
 periods of time, it is possible for the HS to become unreachable as a
 result of Tor detecting a clock jump of length greater than
 `NUM_JUMPED_SECONDS_BEFORE_WARN` (100 seconds) upon waking up, which
 then closes all circuits. Another issue is that if the device was woken
 up by incoming network traffic, the device only stays awake for about a
 second before going back to sleep, which isn't enough time for Tor to
 rebuild the intro circuits, and thus the HS is no longer reachable until
 Tor is able to rebuild the circuits.

 I attempt to improve this situation in two ways:

 1. Increase `NUM_JUMPED_SECONDS_BEFORE_WARN` from 100 seconds to 600
 seconds to avoid triggering the clock-jumped-close-all-circuits code
 every time the device wakes up from sleep.
 2. Add a new command (`MARKCONNFORWAKELOCK`) and event (`WAKELOCK`) to
 the control port to allow Tor to synchronously signal Orbot to hold wake
 lock on behalf of Tor (since it isn't possible to hold a wake lock from
 native code). A wake lock is acquired at the start of a event callback,
 then released when libevent returns from its event loop when there are
 no active events. This prevents the device from sleeping when Tor still
 has work to do.

 

 Comments from Michael@BriarProject:

 Thanks for passing this on. I've also been looking into this problem
 lately. Comments inline below.

 On 11/08/17 12:00, Nathan of Guardian wrote:

 1. Increase `NUM_JUMPED_SECONDS_BEFORE_WARN` from 100 seconds to 600
 seconds to avoid triggering the clock-jumped-close-all-circuits code
 every time the device wakes up from sleep.


 Is there something that makes 600 seconds qualitatively better than 100
 seconds, or is this just a workaround for short sleeps?

 2. Add a new command (`MARKCONNFORWAKELOCK`) and event (`WAKELOCK`) to
 the control port to allow Tor to synchronously signal Orbot to hold
 wake
 lock on behalf of Tor (since it isn't possible to hold a wake lock
 from
 native code). A wake lock is acquired at the start of a event
 callback,
 then released when libevent returns from its event loop when there are
 no active events. This prevents the device from sleeping when Tor
 still
 has work to do.


 I like the underlying idea here, but this way of implementing it seems
 risky.

 The problem is that Tor is driven by two kinds of events: incoming
 network traffic and libevent timers. When the device is asleep, incoming
 traffic will briefly wake it, so you can grab a wake lock until Tor
 finishes its work. But if a libevent timer expires during sleep, the
 device won't be woken. The timer will be handled next time the device
 wakes for some other reason.

 I think this is a potential risk to anonymity, because it will result in
 externally visible behaviour, such as circuit teardowns, happening in
 correlated bursts when the device wakes up. And those bursts can be
 triggered by sending traffic to the device.

 Tor expects timers to run at the scheduled time. That's why it panics
 and tears everything down if the clock jumps by 100 seconds. Suppressing
 that panic response seems like a bad idea. More generally, ignoring the
 assumption behind the panic response seems like a bad idea.

 What would be a better idea?

 Briar holds a wake lock whenever Tor is connected to the network, but
 that kills the battery, so we have to find another way.

 If we could put Tor into some kind of "idle mode", where it would shut
 down all circuit building and other timer-driven behaviour, then it
 might be safe to let the device sleep until it was woken by incoming
 traffic. We could ask the guard for keepalives, say once every five
 minutes, to ensure that periodic tasks like fetching the consensus and
 uploading HS descriptors would have a chance to run even if there was no
 

Re: [tor-bugs] #23056 [Core Tor/Tor]: prop224: Intro point aren't transfered between services on HUP

[Tor Bug Tracker & Wiki]

#23056: prop224: Intro point aren't transfered between services on HUP
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  needs_revision
 Priority:  High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+
Changes (by asn):

 * priority:  Medium => High


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

Re: [tor-bugs] #23233 [Core Tor/Tor]: Unexpected BUG violation in hsv3 decriptor decoding

[Tor Bug Tracker & Wiki]

#23233: Unexpected BUG violation in hsv3 decriptor decoding
-+-
 Reporter:  haxxpop  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, easy, tor-hs, 031-backport  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorR-must
-+-

Comment (by asn):

 OK. Also pushed `bug23233_031` which is based on `maint-0.3.1`!
 Feel free to use it if you think backporting to 0.3.1 is good.

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

[tor-bugs] #23288 [Core Tor/Tor]: refactor temporary file cleanup and make it more consistent

[Tor Bug Tracker & Wiki]

#23288: refactor temporary file cleanup and make it more consistent
--+---
 Reporter:  catalyst  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  intro refactor technical-debt
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 #23271 is an example of a temporary file that doesn't properly get cleaned
 up.  We should consider refactoring the creation and destruction of
 temporary files so they get cleaned up consistently.

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

Re: [tor-bugs] #23271 [Core Tor/Tor]: control_auth_cookie isn't deleted when tor stops

[Tor Bug Tracker & Wiki]

#23271: control_auth_cookie isn't deleted when tor stops
--+--
 Reporter:  yurivict271   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.10
 Severity:  Normal| Resolution:
 Keywords:  easy tor-control  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by catalyst):

 * status:  needs_information => new


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

Re: [tor-bugs] #23097 [Core Tor/Tor]: The circuit timeout prediction is not working properly

[Tor Bug Tracker & Wiki]

#23097: The circuit timeout prediction is not working properly
---+---
 Reporter:  dgoulet|  Owner:  (none)
 Type:  defect | Status:  needs_review
 Priority:  Very High  |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  031-backport, review-group-22  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by dgoulet):

 Oh hey! So I had a commit in the #20657 branch that got merged two weeks
 ago that actually kind of does what you propose. See:

 {{{
 400ba2f6 N 2017-08-04 prop224: Always note down the use of internal
 circuit [David Goulet]
 }}}

 The note internal has been put in `needs_hs_server_circuits()`.

 Ok? Bad? And probably worth a change file if we keep it that way!

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

Re: [tor-bugs] #23233 [Core Tor/Tor]: Unexpected BUG violation in hsv3 decriptor decoding

[Tor Bug Tracker & Wiki]

#23233: Unexpected BUG violation in hsv3 decriptor decoding
-+-
 Reporter:  haxxpop  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, easy, tor-hs, 031-backport  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorR-must
-+-

Comment (by dgoulet):

 Didn't realize it's in 030... I vote for 031 backport but not 030 which is
 stable already.

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

Re: [tor-bugs] #21846 [Core Tor/Torflow]: BwAuthority can't be run out of the box without manual work

[Tor Bug Tracker & Wiki]

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

Comment (by tom):

 When I lost the bwauth box that my bwauth was runnign on, I lost the
 ability to keep working on this. Now that I have a new box I can resume
 the bwauth queue of patches. Feel free to bug me ~weekly about them.

 I'm going to try running a second bwauth (on the same box), see if that
 causes any abnormalities in the existing one, compare results, and then
 start testing 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] #22836 [Metrics/Metrics website]: Parse CollecTor's index.json and provide our own directory listing

[Tor Bug Tracker & Wiki]

#22836: Parse CollecTor's index.json and provide our own directory listing
-+--
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Heh, the good old index-handling classes discussion. We really disagree
 how to move forward there, don't we? :)

 So, I went back and forth about this, too.

 On the one hand the corresponding classes in metrics-lib are not part of
 the API yet, and they're not ready for that. (For example, I'd like to
 avoid that applications instantiate their own `*Node` classes. My
 preferred model would be that we provide some kind of `IndexGenerator`
 that takes one or more directories from the file system and generates a
 `*Node` structure and `index.json*` files from that. And an `IndexParser`
 would take an `index.json` file as input (or download it from a server)
 and provide a `*Node` structure as output. And all `*Node` classes would
 be interfaces, not classes, and they'd be located in packages that are
 part of the API.) But I can't really work on finalizing these classes
 enough to make them part of the API at this point. I'm trying to clean up
 a few things before the next Tor meeting, and making Tor Metrics the only
 user-facing website is one of them.

 On the other hand I agree that duplicating or triplicating code is bad. To
 be fair, we're talking about 20 lines of code here, so the risk for bugs
 is relatively low (though not zero).

 I can see two ways forward: a) We accept these 20 lines of duplicate code
 for now and plan to replace those classes with ones from metrics-lib once
 they're part of the API. b) We use types from metrics-lib despite them not
 being part of the API yet and put up a big warning sign that things might
 break if metrics-lib changes.

 What's your preference?

 Did you find anything else, or did you not look further after finding
 these internal `*Node` classes? :)

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

Re: [tor-bugs] #23260 [Core Tor]: Encoding onion key creation date in the url

[Tor Bug Tracker & Wiki]

#23260: Encoding onion key creation date in the url
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224 needs-design tricky  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  new => needs_information


Comment:

 I also don't see how encoding the creation date of the .onion key in the
 address will allow a user to distinguish a real address or a phishing
 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] #23233 [Core Tor/Tor]: Unexpected BUG violation in hsv3 decriptor decoding

[Tor Bug Tracker & Wiki]

#23233: Unexpected BUG violation in hsv3 decriptor decoding
-+-
 Reporter:  haxxpop  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, easy, tor-hs, 031-backport  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorR-must
-+-
Changes (by asn):

 * status:  needs_revision => needs_review


Comment:

 Oops forgot the changes file! I pushed one now on the same branch.

 Also, this bug is indeed present even in 0.3.0 IIRC. I wonder if we should
 backport this warning. I'd go for "no" since it's not a security issue,
 just a spammable warning. If you think otherwise, let me know and I will
 happily create 0.3.1 and 0.3.0 branches.

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

Re: [tor-bugs] #23238 [Applications/Quality Assurance and Testing]: Using Application Verifier Within Your Software Development Lifecycle

[Tor Bug Tracker & Wiki]

#23238: Using Application Verifier Within Your Software Development Lifecycle
-+-
 Reporter:  cypherpunks  |  Owner:  boklm
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing|
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 #16027

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

Re: [tor-bugs] #23233 [Core Tor/Tor]: Unexpected BUG violation in hsv3 decriptor decoding

[Tor Bug Tracker & Wiki]

#23233: Unexpected BUG violation in hsv3 decriptor decoding
-+-
 Reporter:  haxxpop  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, easy, tor-hs, 031-backport  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorR-must
-+-
Changes (by dgoulet):

 * keywords:  prop224,easy => prop224, easy, tor-hs, 031-backport
 * cc: dgoulet (removed)


Comment:

 ACK.

 For the backport, I think we should do it because 031 is in -alpha and
 avoiding stacktrace in lots of log files because someone is having fun
 uploading malformed descriptors...

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

Re: [tor-bugs] #22989 [Applications/Tor Browser]: TBB Size 1000x610 Mac

[Tor Bug Tracker & Wiki]

#22989: TBB Size 1000x610 Mac
-+-
 Reporter:  Dbryrtfbcbhgf|  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-fingerprinting-resolution, tbb-  |  Actual Points:
  torbutton, TorBrowserTeam201708R   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Does this also fix #22543?

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

Re: [tor-bugs] #23258 [Applications/Tor Browser]: HTTPS Everywhere is not working when noscript is enabled globally

[Tor Bug Tracker & Wiki]

#23258: HTTPS Everywhere is not working when noscript is enabled globally
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  TorBrowserTeam201708  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [comment:29 cypherpunks]:
 > Replying to [comment:16 gk]:
 > > So, the startup delay is not related to the whitelisting but to the
 new HTTPS-E itself. :/
 >
 > Or maybe you were using Medium or High security settings and there's no
 JIT whitelist for webextensions just like it was the case with pdfjs?

 No, that's on level "low". Actually, getting NoScript to work on higher
 security slider settings shows the same effect. Thus, that's very likely
 due to the new HTTPS-Everywhere.

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

Re: [tor-bugs] #23287 [Webpages/Blog]: Cannot save new blog post draft

[Tor Bug Tracker & Wiki]

#23287: Cannot save new blog post draft
---+--
 Reporter:  steph  |  Owner:  hiro
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by hiro):

 * status:  new => assigned


Comment:

 Hi,

 Have you tried saving a blog post without a title? The error says that the
 title field can't be blank. I have tested saving a post and it worked ok.
 Could you try again by adding a title?

 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] #23258 [Applications/Tor Browser]: HTTPS Everywhere is not working when noscript is enabled globally

[Tor Bug Tracker & Wiki]

#23258: HTTPS Everywhere is not working when noscript is enabled globally
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  TorBrowserTeam201708  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:18 legind]:
 You treat users as beta-testers and then want somebody help you, right?
 Or ESR users are not users for you as for Mozilla, maybe?

 If you really want to fix this, you can make a new release and put
 refreshed 5.2.21 in it, then postpone updates from EFF for TBB channels
 like it was before (ticket:10394#comment:7 if it's still available), and
 then make a new release with the latest updates for all clients which
 unaffected.

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

Re: [tor-bugs] #23248 [Webpages/Website]: Add templates to media.torproject.org

[Tor Bug Tracker & Wiki]

#23248: Add templates to media.torproject.org
--+
 Reporter:  steph |  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by hiro):

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


Comment:

 Here they are: !https://media.torproject.org/templates/

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

Re: [tor-bugs] #22989 [Applications/Tor Browser]: TBB Size 1000x610 Mac

[Tor Bug Tracker & Wiki]

#22989: TBB Size 1000x610 Mac
-+-
 Reporter:  Dbryrtfbcbhgf|  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-fingerprinting-resolution, tbb-  |  Actual Points:
  torbutton, TorBrowserTeam201708R   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * keywords:  tbb-fingerprinting-resolution, tbb-torbutton => tbb-
 fingerprinting-resolution, tbb-torbutton, TorBrowserTeam201708R
 * status:  assigned => 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] #22989 [Applications/Tor Browser]: TBB Size 1000x610 Mac

[Tor Bug Tracker & Wiki]

#22989: TBB Size 1000x610 Mac
-+-
 Reporter:  Dbryrtfbcbhgf|  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-fingerprinting-resolution, tbb-  |  Actual Points:
  torbutton  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 Here's a patch for review:

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

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

Re: [tor-bugs] #23258 [Applications/Tor Browser]: HTTPS Everywhere is not working when noscript is enabled globally

[Tor Bug Tracker & Wiki]

#23258: HTTPS Everywhere is not working when noscript is enabled globally
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  TorBrowserTeam201708  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:16 gk]:
 > So, the startup delay is not related to the whitelisting but to the new
 HTTPS-E itself. :/

 Or maybe you were using Medium or High security settings and there's no
 JIT whitelist for webextensions just like it was the case with pdfjs?

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

Re: [tor-bugs] #16513 [Metrics/Onionoo]: Make writing of the out/ directory from the status/ directory deterministic

[Tor Bug Tracker & Wiki]

#16513: Make writing of the out/ directory from the status/ directory 
deterministic
-+
 Reporter:  karsten  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Blocker  | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by iwakeh):

 * severity:   => Blocker


Comment:

 This includes comparing the various documents from different instances
 after deployment in order to find out if all is as 'deterministic' as
 expected.

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

Re: [tor-bugs] #23274 [Applications/Orbot]: Rebase using Firefox Klar

[Tor Bug Tracker & Wiki]

#23274: Rebase using Firefox Klar
+
 Reporter:  cypherpunks |  Owner:  n8fr8
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by n8fr8):

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


Comment:

 We are constantly working to keep Orfox up to date with Tor Browser, which
 is currently at Firefox ESR 52.3 release. ESR 55 is coming next.

 Klar, aka "Focus", is a webkit-based browser, completely different from
 standard Firefox and Tor Browser. However, we have added Orbot integration
 support for it, and are working with Mozilla on having that feature
 released.

 https://github.com/mozilla-mobile/focus-android/pull/825

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

Re: [tor-bugs] #23241 [Applications/Tor Browser]: "This page isn't redirecting properly" errors in TorBrowser but not in Firefox

[Tor Bug Tracker & Wiki]

#23241: "This page isn't redirecting properly" errors in TorBrowser but not in
Firefox
--+--
 Reporter:  msfc  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 https://bugzilla.mozilla.org/show_bug.cgi?id=787970

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

Re: [tor-bugs] #23287 [Webpages/Blog]: Cannot save new blog post draft

[Tor Bug Tracker & Wiki]

#23287: Cannot save new blog post draft
---+--
 Reporter:  steph  |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by steph):

 * Attachment "Screen Shot 2017-08-21 at 10.29.20 AM.png" added.

 Error message

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

[tor-bugs] #23287 [Webpages/Blog]: Cannot save new blog post draft

[Tor Bug Tracker & Wiki]

#23287: Cannot save new blog post draft
---+--
 Reporter:  steph  |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 In Tor Browser, any entered text disappears.

 In Opera, I can add text, but when I tried to save and keep unpublished, I
 received the attached error message.

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

[tor-bugs] #23286 [Metrics/CollecTor]: use index-json classes from metrics-lib

[Tor Bug Tracker & Wiki]

#23286: use index-json classes from metrics-lib
---+-
 Reporter:  iwakeh |  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  CollecTor 1.3.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 In order to avoid code duplication replace all classes that are
 duplicating code from metrics-lib.

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

Re: [tor-bugs] #22836 [Metrics/Metrics website]: Parse CollecTor's index.json and provide our own directory listing

[Tor Bug Tracker & Wiki]

#22836: Parse CollecTor's index.json and provide our own directory listing
-+--
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 Replying to [comment:2 karsten]:
 > I implemented this. Please review [https://gitweb.torproject.org/karsten
 /metrics-
 web.git/commit/?h=task-22836=12a42e61db528c30171170e358498d0210bfec41
 commit 12a42e61 in my task-22836 branch] and admire
 
[https://trac.torproject.org/projects/tor/attachment/ticket/22836/task-22836-screenshot.png
 this screenshot] for an example of it will look like.
 >
 > Once this is merged and deployed we can remove all web elements from
 CollecTor that have the sole purpose of making its directory listings
 prettier.

 This gain does not justify implementing the JSON-index-handling a third
 time, in addition with slight differences.  Even now as we're working
 toward using an internal API of metrics-lib and metrics-lib already
 supplies convenient [https://gitweb.torproject.org/metrics-
 lib.git/tree/src/main/java/org/torproject/descriptor/index/IndexNode.java#n83
 methods for retrieving index.json*].
 (metrics-lib has a way better coverage in addition.)

 The change to the FileNode class only seems to concern the comparison.
 This leads to the question of either using this type of comparison also in
 metrics-lib (small new ticket) or simply providing a Comparator for the
 sorting needed here.

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #17242, #23097, #22891, #22407, ...

[Tor Bug Tracker & Wiki]

Batch modification to #17242, #23097, #22891, #22407, #23276 by nickm:


--
Tickets URL: 

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

Re: [tor-bugs] #23232 [Core Tor/Tor]: misleading log message related to used SSL vendor

[Tor Bug Tracker & Wiki]

#23232: misleading log message related to used SSL vendor
--+
 Reporter:  toralf|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.5-alpha
 Severity:  Trivial   | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Is it?  I don't know if it is.  Does LibreSSL always include the fast ecdh
 implementation, or never include it, or something else?

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

Re: [tor-bugs] #23233 [Core Tor/Tor]: Unexpected BUG violation in hsv3 decriptor decoding

[Tor Bug Tracker & Wiki]

#23233: Unexpected BUG violation in hsv3 decriptor decoding
--+
 Reporter:  haxxpop   |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  prop224,easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  SponsorR-must
--+
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Looks okay to me, but: this `if (BUG(!sig_start))` code is also present in
 0.3.1.  Should this be backported?  If so it needs a changes file.

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

Re: [tor-bugs] #23277 [Core Tor/Tor]: ApplicationControlSocket: the way for apps to control Tor

[Tor Bug Tracker & Wiki]

#23277: ApplicationControlSocket: the way for apps to control Tor
--+--
 Reporter:  yurivict271   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * milestone:   => Tor: unspecified


Comment:

 To clarify -- this is a proposal for a new interface for opening
 controlport sockets, but actually any new features in how they can be
 opened?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23285 [Metrics/Metrics website]: Provide an index.json file on Tor Metrics containing stats files

[Tor Bug Tracker & Wiki]

#23285: Provide an index.json file on Tor Metrics containing stats files
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 We have been discussing separating the data-aggregating part of metrics-
 web from the website part in the past. Here's a plan to make this happen:

  - We provide a new index file on Tor Metrics containing all stats files
 specified on the [https://metrics.torproject.org/stats.html Statistics]
 page, including path, size, and last-modified time. Example (with just a
 single file):

 {{{
 {
   "index_created": "2017-08-21 13:10",
   "path": "https://metrics.torproject.org;,
   "directories": [
 {
   "path": "stats",
   "files": [
 {
   "path": "servers.csv",
   "size": 4794794,
   "last_modified": "2017-08-21 00:29"
 }
   ]
 }
   ]
 }
 }}}

  - The new index file will be available under
 `https://metrics.torproject.org/index/index.json` (does not exist yet) as
 well as `.gz`, `.xz`, etc.

  - The new file will be written right after running the periodic update
 twice per day as part of [https://gitweb.torproject.org/metrics-
 web.git/tree/shared/bin/99-copy-stats-files.sh this script].

  - We might even include an `"implementation_version"` field as discussed
 in #21414.

  - We start using that file by putting a new table at the top of the
 [https://metrics.torproject.org/stats.html Statistics] page that lists all
 available files together with their size, last update time, and link to
 their specification. Like a table of contents. So far so good, this is not
 yet worth the effort. That comes next!

  - In the next step we write a little internal downloader that is part of
 the website part of metrics-web. That downloader periodically fetches the
 `index.json` file to see if there are updates to stats files. If there
 are, it downloads these files and stores them locally for rserve to
 produce new graphs based on the new data.

  - Now we can set up a second metrics-web instance somewhere that has the
 sole purpose of aggregating data. We might want to call it
 `https://metrics2.torproject.org/` (or some other name, if we can settle
 on one). We point the periodic downloader to that host and fetch newly
 updated CSV files from there. And we turn off data-aggregating modules on
 the actual Tor Metrics website host. (Maybe it's easier to find a smaller
 host for the website and move that part, while keeping the data-
 aggregating parts in place. Whatever.)

 Does this make sense?

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

Re: [tor-bugs] #23276 [Core Tor/Tor]: RELAY_CONNECTED cells responding to RELAY_BEGIN_DIR cells don't have a payload

[Tor Bug Tracker & Wiki]

#23276: RELAY_CONNECTED cells responding to RELAY_BEGIN_DIR cells don't have a
payload
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec  |  Actual Points:
Parent ID:  #18856| Points:  0.2
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 That sounds like a good fix.

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

Re: [tor-bugs] #22891 [Core Tor/Tor]: Add GitLab CI configs

[Tor Bug Tracker & Wiki]

#22891: Add GitLab CI configs
-+-
 Reporter:  catalyst |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ci continuous-integration testing|  Actual Points:
  best-practice unit-testing new-developers  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  new => 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] #23253 [Core Tor/Tor]: BridgeAuth goes offline when it has an expired ed25519_signing_cert

[Tor Bug Tracker & Wiki]

#23253: BridgeAuth goes offline when it has an expired ed25519_signing_cert
-+-
 Reporter:  isis |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridgeauth, tor-dirauth, tor-|  Actual Points:
  ed25519-keys   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorM-can
-+-
Changes (by nickm):

 * status:  new => needs_information
 * milestone:   => Tor: 0.3.2.x-final


Comment:

 Is this a 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] #23234 [Core Tor/Tor]: Possible problem with bootstrapping logic (Problem bootstrapping. Stuck at 53%: Loading relay descriptors. (No route to host; NOROUTE; count 7; recommendation war

[Tor Bug Tracker & Wiki]

#23234: Possible problem with bootstrapping logic (Problem bootstrapping. Stuck 
at
53%: Loading relay descriptors. (No route to host; NOROUTE; count 7;
recommendation warn)
-+-
 Reporter:  s7r  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  bootstrap dirguard bridge needs- |  Actual Points:
  insight 031-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  bootstrap => bootstrap dirguard bridge needs-insight
 031-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] #23280 [Core Tor/Tor]: Censorship resistant onion sites

[Tor Bug Tracker & Wiki]

#23280: Censorship resistant onion sites
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  needs-proposal tor-hs censorship  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * keywords:   => needs-proposal tor-hs censorship
 * milestone:   => Tor: unspecified


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

Re: [tor-bugs] #23250 [Core Tor/Tor]: tor-0.3.0.10: test failure on NetBSD

[Tor Bug Tracker & Wiki]

#23250: tor-0.3.0.10: test failure on NetBSD
-+-
 Reporter:  wiz  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bsd test 032-backport 031-backport   |  Actual Points:
  030-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  bsd test => bsd test 032-backport 031-backport 030-backport
 * milestone:  Tor: unspecified => Tor: 0.3.3.x-final


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

Re: [tor-bugs] #23116 [Core Tor/Tor]: tor stops responding to Ctrl-C and circuits while in infinite descriptor download loop

[Tor Bug Tracker & Wiki]

#23116: tor stops responding to Ctrl-C and circuits while in infinite descriptor
download loop
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor:
  |  0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.9
 Severity:  Normal| Resolution:
 Keywords:  needs-insight needs-analysis  |  Actual Points:
Parent ID:  #16844| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * keywords:   => needs-insight needs-analysis
 * priority:  Medium => High


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

Re: [tor-bugs] #23260 [Core Tor]: Encoding onion key creation date in the url

[Tor Bug Tracker & Wiki]

#23260: Encoding onion key creation date in the url
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224 needs-design tricky  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:   => prop224 needs-design tricky
 * milestone:   => Tor: 0.3.2.x-final


Comment:

 How would that be authenticated?  That is, if I see an address that says
 it was created on August 1, how do I know that's true?

 I'm putting this into 0.3.2.x since that's our last chance to change the
 .onion address format for a while, but I'm thinking we probably won't be
 able to get it to work on time unless there's an easy way to do 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] #23237 [Core Tor/Tor]: Add 'GETINFO ip-to-country/available'

[Tor Bug Tracker & Wiki]

#23237: Add 'GETINFO ip-to-country/available'
--+
 Reporter:  atagar|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  easy tor-control  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Yes, we should totally do this. Anybody have a moment, or should I take it
 on?

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

Re: [tor-bugs] #23275 [Core Tor/Tor]: Consensus diffs are generated even if DirCache and DirPort are 0

[Tor Bug Tracker & Wiki]

#23275: Consensus diffs are generated even if DirCache and DirPort are 0
--+
 Reporter:  teor  |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  031-backport  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:  Sponsor4
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #23263 [Applications/Tor Browser]: Rip out startup GfxSanityTest entirely

[Tor Bug Tracker & Wiki]

#23263: Rip out startup GfxSanityTest entirely
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * status:  needs_information => new


Comment:

 It runs at every startup and gives
 {{{
 Cannot play media. No decoders for requested formats: video/mp4
 sanitytest.html
 }}}
 on machines without mp4 support.

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

Re: [tor-bugs] #23244 [Metrics/Onionoo]: Onionoo documents should be the same accross all tp.o instances

[Tor Bug Tracker & Wiki]

#23244: Onionoo documents should be the same accross all tp.o instances
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:  duplicate
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

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


Comment:

 Sounds good to me. Thanks for checking! Closing.

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

Re: [tor-bugs] #22989 [Applications/Tor Browser]: TBB Size 1000x610 Mac

[Tor Bug Tracker & Wiki]

#22989: TBB Size 1000x610 Mac
-+-
 Reporter:  Dbryrtfbcbhgf|  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-fingerprinting-resolution, tbb-  |  Actual Points:
  torbutton  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Resolving #23264 as 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

Re: [tor-bugs] #23264 [Applications/Tor Browser]: Tor Browser size issue

[Tor Bug Tracker & Wiki]

#23264: Tor Browser size issue
--+---
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 Tor Browser should not necessarily round your content window dimensions to
 1000x600. Rather, what it does and should do is rounding the dimensions to
 multiples of 200x100. Thus having something like 1000x800 is perfectly
 fine. Resolving this as a duplicate of #22989 then. If I missed something,
 please say so and reopen 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] #23263 [Applications/Tor Browser]: Rip out startup GfxSanityTest entirely

[Tor Bug Tracker & Wiki]

#23263: Rip out startup GfxSanityTest entirely
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information


Comment:

 But that does not run until someone at least sets `sanity-test.running` to
 `true` manually? Or am I missing something?

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

Re: [tor-bugs] #23115 [Applications/Tor Browser]: If "Tor is not working in this browser", don't download an update

[Tor Bug Tracker & Wiki]

#23115: If "Tor is not working in this browser", don't download an update
--+---
 Reporter:  teor  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information


Comment:

 Replying to [comment:4 teor]:
 > Replying to [comment:3 teor]:
 > > Replying to [comment:2 gk]:
 > > > Was it really not working and it downloaded bypassing Tor? That
 would be a serious bug. Or was that just the `about:tor` page that was
 misleading but the updater did do the correct thing?
 > >
 > > I don't know: I was concerned that these conflicting messages could
 happen. I didn't check which one was correct.
 >
 > This is reproducible, at least on my machine.

 How? By just taking a sufficiently outdated Tor Browser? (If so, which
 version did you test with again? 7.5a1?)

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

Re: [tor-bugs] #23245 [Applications/Tor Browser]: Tor Browser can't launch Tor or modify torrc when there's another Tor Browser instance running in another session on Linux

[Tor Bug Tracker & Wiki]

#23245: Tor Browser can't launch Tor or modify torrc when there's another Tor
Browser instance running in another session on Linux
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 Tor Browser can't be used in multi-user mode right now. We are still
 thinking about that feature over in #17769. Marking this bug as a
 duplicate of that ticket.

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

Re: [tor-bugs] #17769 [Applications/Tor Browser]: Think of ways to make Tor Browser multi-user aware

[Tor Bug Tracker & Wiki]

#17769: Think of ways to make Tor Browser multi-user aware
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 #23245 is 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

Re: [tor-bugs] #23241 [Applications/Tor Browser]: "This page isn't redirecting properly" errors in TorBrowser but not in Firefox

[Tor Bug Tracker & Wiki]

#23241: "This page isn't redirecting properly" errors in TorBrowser but not in
Firefox
--+--
 Reporter:  msfc  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:   => tbb-usability-website
 * version:  Tor: unspecified =>


Comment:

 Hm. Disabling NoScript or HTTPS-Everywhere does not help. Nor does
 enabling 3rd party cookies. I wonder what causes this problem then...
 Akamai interfering maybe?

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

Re: [tor-bugs] #23219 [Applications/Tor Browser]: CSS issues with

[Tor Bug Tracker & Wiki]

#23219: CSS issues with 
--+--
 Reporter:  rngnrs|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 Looking over the bug (https://bugzilla.mozilla.org/show_bug.cgi?id=605985)
 and following the discussion in comment 88 ff. it seems to me Mozilla made
 the decision to land all relevant patches (not just the two ones you
 mentioned in comment:5) in Firefox 54 as they were kind of dependent and
 chances were high that they would run into regressions if done otherwise.

 I think we should follow Mozilla here and not land just those two patch
 sets. Unfortunately, there are now quite some patches involved and some
 bugs are still open which complicates the whole issue. It think we should
 not take the risk involved in the backoprt and wait until this is
 available when we switch to ESR 59. Sorry for that.

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

Re: [tor-bugs] #23282 [Applications/Tor Browser]: Add option to permanently block resizes of the Tor Browser's default window 1000x600 size

[Tor Bug Tracker & Wiki]

#23282: Add option to permanently block resizes of the Tor Browser's default 
window
1000x600 size
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  closed
 Priority:  Very Low  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by gk):

 Replying to [comment:3 cypherpunks]:
 > Also `dom.disable_window_move_resize` looks worth enabling.

 I am not sure about that one. We had some discussion in #9881 and IIRC it
 did not look that appealing back then due to different browser behavior
 with that preference enabled.

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

Re: [tor-bugs] #16465 [Applications/Tor Browser]: windows get resized when not desired

[Tor Bug Tracker & Wiki]

#16465: windows get resized when not desired
--+---
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by cypherpunks):

 * status:  new => needs_information
 * severity:   => Normal


Comment:

 Is this still an issue?

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

Re: [tor-bugs] #20129 [Applications/Tor Browser]: Lock Tor Browser window in-place

[Tor Bug Tracker & Wiki]

#20129: Lock Tor Browser window in-place
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 #23282 is 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

Re: [tor-bugs] #23282 [Applications/Tor Browser]: Add option to permanently block resizes of the Tor Browser's default window 1000x600 size

[Tor Bug Tracker & Wiki]

#23282: Add option to permanently block resizes of the Tor Browser's default 
window
1000x600 size
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  closed
 Priority:  Very Low  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 Replying to [comment:2 cypherpunks]:
 > Not OP, but it's a duplicate of #20129.

 Oh, yes, good catch. 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] #23282 [Applications/Tor Browser]: Add option to permanently block resizes of the Tor Browser's default window 1000x600 size

[Tor Bug Tracker & Wiki]

#23282: Add option to permanently block resizes of the Tor Browser's default 
window
1000x600 size
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  needs_information
 Priority:  Very Low  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by cypherpunks):

 * status:  reopened => needs_information


Comment:

 Also `dom.disable_window_move_resize` looks worth enabling.

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

Re: [tor-bugs] #23282 [Applications/Tor Browser]: Add option to permanently block resizes of the Tor Browser's default window 1000x600 size

[Tor Bug Tracker & Wiki]

#23282: Add option to permanently block resizes of the Tor Browser's default 
window
1000x600 size
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  reopened
 Priority:  Very Low  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

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


Comment:

 Not OP, but it's a duplicate of #20129.

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

Re: [tor-bugs] #23235 [Applications/Tor Browser]: Add Searxes, multiple search engine hosted on Tor Hidden Sercice

[Tor Bug Tracker & Wiki]

#23235: Add Searxes, multiple search engine hosted on Tor Hidden Sercice
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 Duplicate of #19208.

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

Re: [tor-bugs] #19208 [Applications/Tor Browser]: add searx search engine

[Tor Bug Tracker & Wiki]

#19208: add searx search engine
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Minor | Resolution:
 Keywords:  searx |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 #23235 is 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

Re: [tor-bugs] #23282 [Applications/Tor Browser]: Add option to permanently block resizes of the Tor Browser's default window 1000x600 size

[Tor Bug Tracker & Wiki]

#23282: Add option to permanently block resizes of the Tor Browser's default 
window
1000x600 size
--+
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  closed
 Priority:  Very Low  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

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


Comment:

 I guess you want to have an option to stop the resizing at all (not just
 to 1000x600 as it happens with your setup)? In that case
 `extensions.torbutton.resize_new_windows` on `about:config` should do the
 trick.

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

Re: [tor-bugs] #23244 [Metrics/Onionoo]: Onionoo documents should be the same accross all tp.o instances

[Tor Bug Tracker & Wiki]

#23244: Onionoo documents should be the same accross all tp.o instances
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 Replying to [comment:7 karsten]:
 > Without looking at the differences yet: We might resolve some of them by
 simply doing #22033. And #16513 might take a little more effort but move
 us forward in this direction, too.

 Yes, these two tasks will make lots of diffs go away.  #22033 removes most
 differences left in the clients docs.
 #16513 is important, because we will otherwise see an increase of
 differences in a few weeks for the monthly values, too.
 So, we already have the appropriate tickets, no need to open a new one as
 mentioned above.

 I think this ticket could be closed as the work will be done in the two
 mentioned tickets.

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

Re: [tor-bugs] #23244 [Metrics/Onionoo]: Onionoo documents should be the same accross all tp.o instances

[Tor Bug Tracker & Wiki]

#23244: Onionoo documents should be the same accross all tp.o instances
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Without looking at the differences yet: We might resolve some of them by
 simply doing #22033. And #16513 might take a little more effort but move
 us forward in this direction, too.

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

Re: [tor-bugs] #23244 [Metrics/Onionoo]: Onionoo documents should be the same accross all tp.o instances

[Tor Bug Tracker & Wiki]

#23244: Onionoo documents should be the same accross all tp.o instances
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * status:  new => needs_information


Comment:

 Since both instances use the same geoip database the details doc
 differences reduced quite a bit.

 In total, there is a small percentage when only looking at running nodes:
 {{{
 doc-typecount   different lines percentage
 summary 926225  0.003
 details 9262649 0.070
 bandwd. 9262753 0.081
 weights 6785361 0.053
 clients 248416  0.006
 }}}

 These should be fine with clients when rotating.

 Still some should be investigated like the diffs for details, weights, and
 bandwith. -> new ticket

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #17488, #4943, #9778, #11430, ...

[Tor Bug Tracker & Wiki]

Batch modification to #17488, #4943, #9778, #11430, #16225, #17430, #19183, 
#19616, #19622, #19756, #20430, #20540, #22196, #6856, #8127, #18797 by karsten:


Action: reassign

Comment:
Handing over to metrics-team, because I'm not currently working on this.

--
Tickets URL: 

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

[tor-bugs] #23284 [Internal Services/Service - trac]: Trolls from Olgino are trolling Russia-related issues in Tor bug tracker

[Tor Bug Tracker & Wiki]

#23284: Trolls from Olgino are trolling Russia-related issues in Tor bug tracker
--+-
 Reporter:  cypherpunks   |  Owner:  qbi
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 https://en.wikipedia.org/wiki/Trolls_from_Olgino

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

Re: [tor-bugs] #23280 [Core Tor/Tor]: Censorship resistant onion sites

[Tor Bug Tracker & Wiki]

#23280: Censorship resistant onion sites
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 The pros here are that you only need to implement the thing using stable
 BM interface. Tor will benefit from BM updates. Address-requesting
 messages are mixed with other general-purpose BM messages giving better
 anonymity.

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

Re: [tor-bugs] #23280 [Core Tor/Tor]: Censorship resistant onion sites

[Tor Bug Tracker & Wiki]

#23280: Censorship resistant onion sites
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 I have a better idea. Both user and server start BitMessage. A user sends
 a bitmessage message to the server. The server creates a new .onion
 address for a user and gives it to user. So there is no need to implement
 own BitMessage in tor.

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

Re: [tor-bugs] #22836 [Metrics/Metrics website]: Parse CollecTor's index.json and provide our own directory listing

[Tor Bug Tracker & Wiki]

#22836: Parse CollecTor's index.json and provide our own directory listing
-+--
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 Replying to [comment:2 karsten]:
 > I implemented this. Please review [https://gitweb.torproject.org/karsten
 /metrics-
 web.git/commit/?h=task-22836=12a42e61db528c30171170e358498d0210bfec41
 commit 12a42e61 in my task-22836 branch] and admire
 
[https://trac.torproject.org/projects/tor/attachment/ticket/22836/task-22836-screenshot.png
 this screenshot] for an example of it will look like.

 The screenshot looks good!

 >
 > Once this is merged and deployed we can remove all web elements from
 CollecTor that have the sole purpose of making its directory listings
 prettier.

 Yes, that will be good.

 I'll take a look at the 350+ new/changed lines of code soon.

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

Re: [tor-bugs] #23270 [Core Tor/Tor]: Allow Tor relays to be configured to block selected hidden services, including racist hate sites

[Tor Bug Tracker & Wiki]

#23270: Allow Tor relays to be configured to block selected hidden services,
including racist hate sites
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:  racism, hate, anti-fascism,  |  Actual Points:
  probably-bad-idea, slippery-slope, |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Ticketstarter, everything I wanna say here, is that censorship (you
 propose censorship, even if you claim it is not) is a sign of a fascist
 regime. So if you really want to oppose fascism, you should not propose
 censorship. Your ticket looks like bad trolling. And it is sad to see this
 kind of kidding in such a serious project bug tracker. Shame on 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