date:20170904

Re: [tor-bugs] #23405 [Internal Services/Service - trac]: My trac password was reset: is this a trac bug?

2017-09-04 Thread Tor Bug Tracker & Wiki

#23405: My trac password was reset: is this a trac bug?
--+-
 Reporter:  teor  |  Owner:  qbi
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by qbi):

 * cc: hiro (added)


Comment:

 As far as I remember hiro had a similar issue in the last days.

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

Re: [tor-bugs] #23404 [Applications/Tor Browser]: Noto Sans Buginese missing from macOS font whitelist

2017-09-04 Thread Tor Bug Tracker & Wiki

#23404: Noto Sans Buginese missing from macOS font whitelist
-+-
 Reporter:  arthuredelstein  |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting-font, |  Actual Points:
  TorBrowserTeam201709R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * keywords:  tbb-font-fingerprinting, TorBrowserTeam201709R => tbb-
 fingerprinting-font, TorBrowserTeam201709R


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

Re: [tor-bugs] #23404 [Applications/Tor Browser]: Noto Sans Buginese missing from macOS font whitelist

2017-09-04 Thread Tor Bug Tracker & Wiki

#23404: Noto Sans Buginese missing from macOS font whitelist
-+-
 Reporter:  arthuredelstein  |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-font-fingerprinting, |  Actual Points:
  TorBrowserTeam201709R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * keywords:  tbb-font => tbb-font-fingerprinting, TorBrowserTeam201709R
 * status:  assigned => needs_review


Comment:

 Here's a patch for review:
 https://github.com/arthuredelstein/tor-browser/commit/23404

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23406 [Core Tor/Tor]: Sampled guards are not re-weighted when a new consensus arrives

2017-09-04 Thread Tor Bug Tracker & Wiki

#23406: Sampled guards are not re-weighted when a new consensus arrives
--+---
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.1-alpha
 Severity:  Normal|   Keywords:  path-selection, tor-guard
Actual Points:|  Parent ID:  #23318
   Points:  1 |   Reviewer:
  Sponsor:|
--+---
 Replying to
 [https://trac.torproject.org/projects/tor/ticket/23318#comment:5]:
 > It's not only case when code bypassing limits, as noticed by pastly in
 IRC. Guard nodes weights only if new guard added by
 `entry_guards_expand_sample`. Sample guard or subsets never being re-
 weighted: once sampled non-Exit Guard will be used as Exit+Guard (if
 operator change it policy) by client.

 This is probably the behaviour we want: re-weighting based on the latest
 consensus allows Guard operators to detect exactly when a client downloads
 the next consensus (because it would stop using that Guard).

 That said, keeping old weights might allow attacks based on knowing the
 weightings in a really old consensus.

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

Re: [tor-bugs] #23318 [Core Tor/Tor]: compute_weighted_bandwidths: do not add 0.5 to final_weight

2017-09-04 Thread Tor Bug Tracker & Wiki

#23318: compute_weighted_bandwidths: do not add 0.5 to final_weight
+
 Reporter:  cypherpunks |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.2.4.3-alpha
 Severity:  Normal  | Resolution:
 Keywords:  path-selection  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+
Changes (by teor):

 * priority:  Very High => Medium
 * points:   => 1
 * version:   => Tor: 0.2.4.3-alpha


Comment:

 Replying to [comment:2 cypherpunks]:
 > I think in original code 0.5 contradicts to tor_llround(), it should be
 (int64_t)(weight*this_bw + 0.5) or tor_llround(weight*this_bw)

 I can confirm this bug: `tor_llround(weight*this_bw + 0.5)` returns 1 when
 weight or this_bw are 0, because tor_llround() rounds away from zero. This
 is probably not what we want.

 I split the other bug off into another ticket.

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

Re: [tor-bugs] #23405 [Internal Services/Service - trac]: My trac password was reset: is this a trac bug?

2017-09-04 Thread Tor Bug Tracker & Wiki

#23405: My trac password was reset: is this a trac bug?
--+-
 Reporter:  teor  |  Owner:  qbi
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by teor):

 (There don't appear to be any extra posts from my user, nor have I
 received any password reset emails or similar. So I'm wondering if this is
 some kind of corruption 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] #23397 [Applications/Tor Browser]: NoScript is totally broken in the way it handles URLs (with e.g. https:// inside) (was: NoScript is totally brain damaged with the way it handles URLs

2017-09-04 Thread Tor Bug Tracker & Wiki

#23397: NoScript is totally broken in the way it handles URLs (with e.g. 
https://
inside)
---+--
 Reporter:  cypherpunks|  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-security-slider, noscript  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by teor):

 Or this

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

Re: [tor-bugs] #23347 [Core Tor/Tor]: Using bridges is not working anymore with tor on master

2017-09-04 Thread Tor Bug Tracker & Wiki

#23347: Using bridges is not working anymore with tor on master
--+
 Reporter:  gk|  Owner:  teor
 Type:  defect| Status:
  |  needs_revision
 Priority:  Very High |  Milestone:  Tor:
  |  0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bootstrap, tor-bridge-client  |  Actual Points:  0.5
Parent ID:| Points:  0.5
 Reviewer:  isis  |Sponsor:
--+
Changes (by teor):

 * status:  merge_ready => needs_revision


Comment:

 Replying to [comment:13 nickm]:
 > I'm wondering whether we shouldn't extract the magic pair of calls to
 download_status_implement() and turn them into some other "adjust bridge
 download schedule" function?  Or use two separate schedules?

 I think we should use two separate schedules, like we do for bootstrapping
 consensuses and regular consensuses. This makes the different behavior
 explicit, rather than relying on magic numbers.

 It also allows us to have more fine-grained control over how often we
 retry missing bridge descriptors.

 We could use schedules that match the old behaviour:
 {{{
 TestingMissingBridgeDownloadSchedule 0, 1200, 900, 900, 3600
 TestingBridgeDownloadSchedule 1200, 900, 900, 3600
 /* And in a test network */
 TestingMissingBridgeDownloadSchedule 0, 60, 30, 30, 60
 TestingBridgeDownloadSchedule 60, 30, 30, 60
 }}}

 But we probably want something more like this:
 {{{
 /* If we can't get a bridge descriptor, backoff exponentially, just like
 authority consensus downloads */
 TestingMissingBridgeDownloadSchedule 0, 3, 7, 3600, 10800, 25200, 54000,
 111600, 262800
 /* If the bridge keeps giving us a valid descriptor, it's ok to keep
 asking for one every 6 hours (this gives a bridge client 4 attempts per
 day to refresh each bridge descriptor) */
 TestingBridgeDownloadSchedule 21600, 21600
 /* And in a test network, match authority consensus downloads */
 TestingMissingBridgeDownloadSchedule 0, 0, 5, 10, 15, 20, 30, 60
 TestingBridgeDownloadSchedule 30, 30
 }}}

 Is there any reason that a bridge client with a valid bridge descriptor
 should re-download it every hour?

 I'm happy to make this change, but it will probably be towards the end of
 the week. Feel free to grab this ticket if you want to do it before then.

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

Re: [tor-bugs] #22430 [Core Tor/Chutney]: Add next gen HS support to chutney

2017-09-04 Thread Tor Bug Tracker & Wiki

#22430: Add next gen HS support to chutney
+
 Reporter:  asn |  Owner:  teor
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Chutney|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs prop224 chutney  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  teor|Sponsor:
+
Changes (by teor):

 * status:  needs_review => needs_revision
 * reviewer:   => teor
 * points:   => 1


Comment:

 These lines in torrc_templates/hs-v3.tmpl are redundant, because they are
 already in hs.tmpl:
 {{{
 ${include:common.i}
 SocksPort 0
 Address $ip

 }}}

 I think torrc_templates/single-onion-v3.tmpl can become:
 {{{
 ${include:single-onion.tmpl}
 ${include:hs-v3.tmpl}
 }}}

 Nitpicks:
 networks/hs-v3 should have a newline at the end of the 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

[tor-bugs] #23405 [Internal Services/Service - trac]: My trac password was reset: is this a trac bug?

2017-09-04 Thread Tor Bug Tracker & Wiki

#23405: My trac password was reset: is this a trac bug?
--+-
 Reporter:  teor  |  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:|
--+-
 Hi,

 This morning (Tue  5 Sep 2017 01:00 UTC), I wasn't able to log in with my
 trac password. It appears that it was changed (or corrupted) without my
 knowledge.

 The cypherpunks password worked for me, as did my password when I reset it
 via email to a different password.

 Is this a trac bug, file corruption, or a data breach of some kind?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23404 [Applications/Tor Browser]: Noto Sans Buginese missing from macOS font whitelist

2017-09-04 Thread Tor Bug Tracker & Wiki

#23404: Noto Sans Buginese missing from macOS font whitelist
--+-
 Reporter:  arthuredelstein   |  Owner:  arthuredelstein
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-font
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Tim Huang pointed out that although we are bundling Noto Sans Buginese, I
 seem to have forgotten to add it to the whitelist.

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

Re: [tor-bugs] #23281 [Core Tor/Stem]: py-stem test failures on FreeBSD

2017-09-04 Thread Tor Bug Tracker & Wiki

#23281: py-stem test failures on FreeBSD
--+
 Reporter:  yurivict271   |  Owner:  atagar
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Stem |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  testing, freebsd  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by atagar):

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


Comment:

 My pleasure, thanks for all your patience and help yurivict271!

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

Re: [tor-bugs] #23347 [Core Tor/Tor]: Using bridges is not working anymore with tor on master

2017-09-04 Thread Tor Bug Tracker & Wiki

#23347: Using bridges is not working anymore with tor on master
--+
 Reporter:  gk|  Owner:  teor
 Type:  defect| Status:
  |  merge_ready
 Priority:  Very High |  Milestone:  Tor:
  |  0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bootstrap, tor-bridge-client  |  Actual Points:  0.5
Parent ID:| Points:  0.5
 Reviewer:  isis  |Sponsor:
--+

Comment (by nickm):

 I'm wondering whether we shouldn't extract the magic pair of calls to
 download_status_implement() and turn them into some other "adjust bridge
 download schedule" function?  Or use two separate schedules?

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

Re: [tor-bugs] #23281 [Core Tor/Stem]: py-stem test failures on FreeBSD

2017-09-04 Thread Tor Bug Tracker & Wiki

#23281: py-stem test failures on FreeBSD
--+---
 Reporter:  yurivict271   |  Owner:  atagar
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Stem |Version:
 Severity:  Normal| Resolution:
 Keywords:  testing, freebsd  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by atagar):

 Thanks yurivict271! Think I finally got 'em all. Do the tests now pass for
 you?

 {{{
 ==
 FAIL: test_router_status_entry
 --
 Traceback (most recent call last):
   File "/tmp/stem/test/unit/descriptor/server_descriptor.py", line 296, in
 test_router_status_entry
 self.assertEqual('4F0069BF91C04581B7C3CA9272E2D3228D4EA571',
 desc.digest)
 AssertionError: '4F0069BF91C04581B7C3CA9272E2D3228D4EA571' !=
 'A863EFE8395C41C880782B89B850D20EDD242BDA'
 - 4F0069BF91C04581B7C3CA9272E2D3228D4EA571
 + A863EFE8395C41C880782B89B850D20EDD242BDA

 --
 }}}

 Fixed: https://gitweb.torproject.org/stem.git/commit/?id=982c36e

 {{{
 ==
 ERROR: test_saving_manual_as_config
 --
 Traceback (most recent call last):
   File "/tmp/stem/test/require.py", line 58, in wrapped
 return func(self, *args, **kwargs)
   File "/tmp/stem/test/unit/manual.py", line 205, in
 test_saving_manual_as_config
 manual = stem.manual.Manual.from_man(EXAMPLE_MAN_PATH)
   File "/tmp/stem/stem/manual.py", line 495, in from_man
 categories, config_options = _get_categories(man_output),
 OrderedDict()
   File "/tmp/stem/stem/manual.py", line 666, in _get_categories
 if lines[-1] == '':
 IndexError: list index out of range

 --
 }}}

 Fixed: https://gitweb.torproject.org/stem.git/commit/?id=336a2a8

 {{{
 ==
 ERROR: test_set_conf_when_immutable
 --
 Traceback (most recent call last):
   File "/tmp/stem/test/require.py", line 58, in wrapped
 return func(self, *args, **kwargs)
   File "/tmp/stem/test/integ/control/controller.py", line 778, in
 test_set_conf_when_immutable
 self.assertRaisesRegexp(stem.InvalidArguments, "DisableAllSwap cannot
 be changed while tor's running", controller.set_conf, 'DisableAllSwap',
 '1')
   File "/tmp/stem/stem/util/test_tools.py", line 272, in
 assertRaisesRegexp
 return super(original_type, self).assertRaisesRegexp(exc_type,
 exc_msg, func, *args, **kwargs)
   File "/usr/local/lib/python3.6/unittest/case.py", line 1320, in
 deprecated_func
 return original_func(*args, **kwargs)
   File "/usr/local/lib/python3.6/unittest/case.py", line 1267, in
 assertRaisesRegex
 return context.handle('assertRaisesRegex', args, kwargs)
   File "/usr/local/lib/python3.6/unittest/case.py", line 178, in handle
 callable_obj(*args, **kwargs)
   File "/tmp/stem/stem/control.py", line 2303, in set_conf
 self.set_options({param: value}, False)
   File "/tmp/stem/stem/control.py", line 2412, in set_options
 raise stem.InvalidRequest(response.code, response.message)
 stem.InvalidRequest: Transition not allowed: While Tor is running,
 changing DisableAllSwap is not allowed.

 --
 }}}

 Fixed: https://gitweb.torproject.org/stem.git/commit/?id=1b9a68b

 {{{
 STATIC CHECKS
 * /tmp/stem/cache_manual.py
   line 51   - undefined name 'exc' | print('Cached
 database schema is out of date (was %s, but current version is %s)' %
 (exc.database_schema, stem.manual.SCHEMA_VERSION))
 }}}

 Fixed: https://gitweb.torproject.org/stem.git/commit/?id=1b9a68b

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

Re: [tor-bugs] #23397 [Applications/Tor Browser]: NoScript is totally brain damaged with the way it handles URLs (with e.g. https:// inside) (was: Something is totally brain damaged with the way Tor B

2017-09-04 Thread Tor Bug Tracker & Wiki

#23397: NoScript is totally brain damaged with the way it handles URLs (with 
e.g.
https:// inside)
---+--
 Reporter:  cypherpunks|  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-security-slider, noscript  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 Replying to [comment:4 cypherpunks]:
 > Replying to [comment:3 cypherpunks]:
 > > Workaround: "Temporarily allow all this page" and refresh (F5).
 > Only for High security setting.
 Not only ;)
 > Also I tested it with stable Tor Browser and same problem, so it doesn't
 have to do with the recent Torbutton fix.
 >
 > Also better title is welcome :)
 How about this?

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

Re: [tor-bugs] #22229 [Applications/Tor Messenger]: Compile Linux 64bits versions of Tor Messenger with Selfrando?

2017-09-04 Thread Tor Bug Tracker & Wiki

#9: Compile Linux 64bits versions of Tor Messenger with Selfrando?
+-
 Reporter:  blockflare  |  Owner:  (none)
 Type:  enhancement | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:  implemented
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-

Comment (by cypherpunks):

 Replying to [comment:4 arlolra]:
 > Done in https://gitweb.torproject.org/tor-messenger-
 build.git/commit/?id=f63b980484f55bdf0bab86720587077b4474b679

 Wooho! Thanks 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] #23397 [Applications/Tor Browser]: Something is totally brain damaged with the way Tor Browser handles PDFs at Medium Security Setting

2017-09-04 Thread Tor Bug Tracker & Wiki

#23397: Something is totally brain damaged with the way Tor Browser handles 
PDFs at
Medium Security Setting
---+--
 Reporter:  cypherpunks|  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-security-slider, noscript  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 Replying to [comment:3 cypherpunks]:
 > Workaround: "Temporarily allow all this page" and refresh (F5).
 Only for High security setting.

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

Re: [tor-bugs] #23384 [Applications/Tor Browser]: Configure VM for Tor Browser builds

2017-09-04 Thread Tor Bug Tracker & Wiki

#23384: Configure VM for Tor Browser builds
--+--
 Reporter:  boklm |  Owner:  boklm
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201709  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by boklm):

 * cc: mikeperry (added)


Comment:

 Mike: you can send me your ssh key if you want an account on this machine.

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

Re: [tor-bugs] #21759 [Metrics/CollecTor]: Add persistence for torperf/onionperf

2017-09-04 Thread Tor Bug Tracker & Wiki

#21759: Add persistence for torperf/onionperf
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  CollecTor 1.4.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Okay. I'll write a cheat sheet for release dependencies tomorrow. ;)

 Can you rebase and squash, or should I do that tomorrow? (Will not merge
 before tomorrow anyway.)

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

Re: [tor-bugs] #16596 [Metrics/ExoneraTor]: Change database queries towards making only a single query per request

2017-09-04 Thread Tor Bug Tracker & Wiki

#16596: Change database queries towards making only a single query per request
+
 Reporter:  karsten |  Owner:  karsten
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by karsten):

 Replying to [comment:6 iwakeh]:

 Thanks for starting this review!

 > Already found a bit.  There are also a few things that are part of other
 tickets (#19623, #19624, #21145), which I tried to omit here.

 Okay.

 > ExoneraTorServlet: `exoneratorHost` should not be configured via
 web.xml, rather use simple java properties file or even simpler hard code.
 After all it shouldn't change that often, should it?

 Hmm, right. My idea was that we'll later copy over this servlet to
 metrics-web where it would make a little more sense to make the host name
 configurable. But on second thought that's not really the case. I'll just
 hard-code it.

 > In 'step 3' I see some problems with `null` values, for example,
 `"".equals(null)` would evaluate to false (line 147 following).

 Note that we're using `null` for invalid parameter values and `""` for
 empty parameter values. Do you see actual problems or potential problems
 there?

 In the latter case (potential problems), maybe we can resolve them by
 documenting things a bit better, or by making things clearer in subsequent
 commits.

 In the former case (actual problems), let's of course fix the issues now.
 But I'd have to see the actual problem first.

 > For most exceptions caught the error message should be logged; and, it
 might be time to switch to slf4j-api and logback, now.

 Yes, we can switch to slf4j, though we should do that in a separate commit
 on top of these, probably in a new ticket.

 > In addition, reading the response query should also catch
 RuntimeExceptions (possibly from Gson).

 Ugh, indeed. Will fix. Good '''catch'''. :)

 > The version received should also be logged, if it differs from the known
 version.

 Yep, good idea.

 > The known version(s) could be a constant in `ExoneraTorServlet`; either
 just the major part or all.  This makes it more obvious.

 Also a good idea.

 > QueryServlet: Helper methods ` private String parseTimestampParameter`
 and `private String parseIpParameter` should be `public static` and tests
 should be added.  Similarly, `private String convertIpV*ToHex`, which
 could be combined by simply adding another argument, i.e., `public static
 String convertIpV4ToHex(String relayIp, boolean isIpV4)`.

 Agreed, though let's save that for another ticket and not overload this
 ticket with too many improvements all at once. I know it's tempting. Stay
 strong, we'll eventually fix these things.

 > A `MILLISEC_IN_DAY = 24L * 60L * 60L * 1000L` constant would be useful.

 Agreed. That's probably simple enough for a separate commit on top of this
 branch.

 > Other: Using the object `Boolean exit` for a triplet state is a bit too
 much of a hack.  There could be a simple enum, as simple as, for example,
 `public enum Exit { U, Y, N; }`.

 Ugh, that would turn the JSON field into a string, which doesn't seem very
 intuitive for "is an exit". And whoever processes this JSON will need to
 check for `null` anyway, regardless of boolean or string. In fact, I think
 that we're using the boolean field exactly in the way it's supposed to be
 used: `true` means "is an exit", `false` means "is not an exit", and
 `null` means "we don't know". I think I'd like to leave this one
 unchanged. It's not a hack.

 > Regarding SQL:
 > Order-by statement should be using names not numbers.

 Hmm, now that you mention that, I wonder if we even need results to be
 sorted at all. I'll try to take that out. Otherwise I'd change numbers to
 names in a subsequent commit, because it's not directly related to this
 ticket.

 > Couldn't the exit-information be part of the query already?

 Yes, but I'd like to save database changes for a later ticket. There's so,
 so much more we can do to make the database schema more efficient. (I'd
 have to look at my notes from last year, but I believe that we're storing
 exit information directly in the database rather than the entire raw
 status entry.)

 > (I could also look into providing some patches, if we agree on the
 changes and you don't have the time?)

 I'll try to make changes tomorrow morning. Thanks again for the initial
 review!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___

Re: [tor-bugs] #22699 [Applications/Tor Browser]: Use browser pref for javascript at High Security Level

2017-09-04 Thread Tor Bug Tracker & Wiki

#22699: Use browser pref for javascript at High Security Level
-+-
 Reporter:  mikeperry|  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, tbb-security-slider,   |  Actual Points:
  TorBrowserTeam201708   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Given ticket:23258#comment:22, #23399, #18592 and
 https://bugzilla.mozilla.org/show_bug.cgi?id=971650, this idea doesn't
 look so good. It was discussed in #1811.

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

Re: [tor-bugs] #22752 [Core Tor/Tor]: Assertion failure in consensus_cache_entry_handle_get on Windows

2017-09-04 Thread Tor Bug Tracker & Wiki

#22752: Assertion failure in consensus_cache_entry_handle_get on Windows
--+
 Reporter:  ahf   |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.3-alpha
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:  Sponsor4
--+
Changes (by nickm):

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


Comment:

 Vort: Okay.  I'll take this as likely working.

 Dgoulet: merging now to 0.3.1 and forward; but please let me know if you
 think I didn't get the documentation right in
 948be49ce06f744ca456d20f48bfb6d2f5cfb7d2

 peace!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23403 [Applications/Tor Browser]: Use tor-browser-build/tmp rather than /tmp as default tmp directory

2017-09-04 Thread Tor Bug Tracker & Wiki

#23403: Use tor-browser-build/tmp rather than /tmp as default tmp directory
--+--
 Reporter:  boklm |  Owner:  boklm
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-rbm
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 We are currently using /tmp as the default temporary directory, however it
 seems to be quite common that this directory is mounted on a small tmpfs
 partition, which makes the build fail because of lack of disk space.

 To avoid this, we should instead use a tmp directory inside the `tor-
 browser-build` directory by default.

 https://trac.torproject.org/projects/tor/ticket/23382#comment: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] #23382 [Applications/Tor Browser]: rbm: Error when the tmp_dir directory does not exist

2017-09-04 Thread Tor Bug Tracker & Wiki

#23382: rbm: Error when the tmp_dir directory does not exist
---+--
 Reporter:  boklm  |  Owner:  boklm
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201709  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by boklm):

 I opened #23403 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] #21759 [Metrics/CollecTor]: Add persistence for torperf/onionperf

2017-09-04 Thread Tor Bug Tracker & Wiki

#21759: Add persistence for torperf/onionperf
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  CollecTor 1.4.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Better merge now.

 For releasing metrics-lib using java 7 only the following line needs to be
 added to metrics-lib build.xml
 `  `
 This will override the setting from metrics-base.

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

Re: [tor-bugs] #21759 [Metrics/CollecTor]: Add persistence for torperf/onionperf

2017-09-04 Thread Tor Bug Tracker & Wiki

#21759: Add persistence for torperf/onionperf
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  CollecTor 1.4.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Actually, no, we can't put out metrics-lib 2.1.0 before we put out
 releases for all tools depending on metrics-lib, because of #19617. Let's
 not merge this branch now, or at least not the parts requiring 2.1.0. Or
 let's put in the exception for metrics-lib 2.1.0 to keep using Java 7
 despite the metrics-base update.

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

Re: [tor-bugs] #21759 [Metrics/CollecTor]: Add persistence for torperf/onionperf

2017-09-04 Thread Tor Bug Tracker & Wiki

#21759: Add persistence for torperf/onionperf
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  CollecTor 1.4.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Hrm-okay. Can you rebase and squash? Otherwise I'll do it tomorrow.
 (And let's consider putting out metrics-lib 2.1.0 this 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] #23382 [Applications/Tor Browser]: rbm: Error when the tmp_dir directory does not exist

2017-09-04 Thread Tor Bug Tracker & Wiki

#23382: rbm: Error when the tmp_dir directory does not exist
---+--
 Reporter:  boklm  |  Owner:  boklm
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201709  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by gk):

 I am a fan.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23402 [Internal Services/Tor Sysadmin Team]: Please provide user 'onionoo-unpriv' on oo-hetzner-03 with the same features as on omeiense

2017-09-04 Thread Tor Bug Tracker & Wiki

#23402: Please provide user 'onionoo-unpriv' on oo-hetzner-03 with the same
features as on omeiense
-+-
 Reporter:  iwakeh   |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Currently, onionoo-unpriv on oo-hetzner-03 doesn't has a home directory,
 which for example prevents using crontab.
 Please provide user 'onionoo-unpriv' on oo-hetzner-03 with the same
 features as on omeiense.

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

Re: [tor-bugs] #23402 [Internal Services/Tor Sysadmin Team]: Please provide user 'onionoo-unpriv' on oo-hetzner-03 with the same features as on omeiense

2017-09-04 Thread Tor Bug Tracker & Wiki

#23402: Please provide user 'onionoo-unpriv' on oo-hetzner-03 with the same
features as on omeiense
-+-
 Reporter:  iwakeh   |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Description changed by iwakeh:

Old description:

> Currently, onionoo-unpriv on oo-hetzner-03 doesn't has a home directory,
> which for example prevents using crontab.
> Please provide user 'onionoo-unpriv' on oo-hetzner-03 with the same
> features as on omeiense.

New description:

 Currently, onionoo-unpriv on oo-hetzner-03 doesn't have a home directory,
 which for example prevents using crontab.
 Please provide user 'onionoo-unpriv' on oo-hetzner-03 with the same
 features as on omeiense.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23401 [Applications/Tor Browser]: Add option to download everything needed for the build

2017-09-04 Thread Tor Bug Tracker & Wiki

#23401: Add option to download everything needed for the build
--+--
 Reporter:  boklm |  Owner:  boklm
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-rbm
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 We are currently downloading files in the order in which we use them.

 Some files are downloaded early (files for which we need their checksum to
 compute some output files), while other files are downloaded just before
 their component is built (signature files, or files for which we already
 know the checksum).

 We should add an option to download everything without starting the build,
 which should then allow someone to do the build offline.

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

Re: [tor-bugs] #23359 [Applications/Tor Browser]: HTTPS-Everywhere icon is not shown on first start but on restart

2017-09-04 Thread Tor Bug Tracker & Wiki

#23359: HTTPS-Everywhere icon is not shown on first start but on restart
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Without e10s:
 {{{
 18:39:43.555 NS_ERROR_NOT_AVAILABLE: Component returned failure code:
 0x80040111 (NS_ERROR_NOT_AVAILABLE)
 [nsIDOMWindowUtils.isParentWindowMainWidgetVisible] 1 nsPrompter.js:350
 }}}

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

Re: [tor-bugs] #21759 [Metrics/CollecTor]: Add persistence for torperf/onionperf

2017-09-04 Thread Tor Bug Tracker & Wiki

#21759: Add persistence for torperf/onionperf
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  CollecTor 1.4.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Replying to [comment:15 karsten]:
 > Alright, I finally reviewed your
 [https://gitweb.torproject.org/user/iwakeh/collector.git/log/?h=task-21759-2
 task-21759-2 branch]. Here's what I found:
 >
 >  - The case changes to configuration options (like `"OnionperfActivated"
 -> "OnionPerfActivated"`) deserve a change log entry under "Major
 changes", unless we don't care about case there. Because if we do we'll
 have to inform operators that they'll need to update their configurations.

 Indeed, that is important and should go in the Major-section!  Besides the
 changelog I will also highlight this in the announcement.

 >  - We'll need to put out metrics-lib 2.1.0 before merging at least the
 last commit(s) in your branch. Should we 1) push that forward to get this
 branch merged, 2) merge only commits from this branch that don't require
 m-lib 2.1.0, or 3) put this branch on hold until 2.1.0 is out?

 Just merge all now.  We have releases, thus master can depend on some
 unreleased metrics-lib dev-version, that's fine.  And, other tickets will
 need metrics-lib-2.1.0, too.  We only need to make sure that metrics-lib
 2.1.0 is out before we release CollecTor again.

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

Re: [tor-bugs] #21759 [Metrics/CollecTor]: Add persistence for torperf/onionperf

2017-09-04 Thread Tor Bug Tracker & Wiki

#21759: Add persistence for torperf/onionperf
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  CollecTor 1.4.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Alright, I finally reviewed your
 [https://gitweb.torproject.org/user/iwakeh/collector.git/log/?h=task-21759-2
 task-21759-2 branch]. Here's what I found:

  - The case changes to configuration options (like `"OnionperfActivated"
 -> "OnionPerfActivated"`) deserve a change log entry under "Major
 changes", unless we don't care about case there. Because if we do we'll
 have to inform operators that they'll need to update their configurations.
  - We'll need to put out metrics-lib 2.1.0 before merging at least the
 last commit(s) in your branch. Should we 1) push that forward to get this
 branch merged, 2) merge only commits from this branch that don't require
 m-lib 2.1.0, or 3) put this branch on hold until 2.1.0 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] #23382 [Applications/Tor Browser]: rbm: Error when the tmp_dir directory does not exist

2017-09-04 Thread Tor Bug Tracker & Wiki

#23382: rbm: Error when the tmp_dir directory does not exist
---+--
 Reporter:  boklm  |  Owner:  boklm
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201709  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by boklm):

 Related to this, I'm wondering if we should default to using a `tmp`
 directory inside the `tor-browser-build` directory, rather than `/tmp`, as
 having a small `/tmp` directory (usually in a tmpfs) seems to be quite
 common.

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

Re: [tor-bugs] #10704 [Applications/Tor Browser]: TBB 3.5 hangs under OS X on certain sites (possibly a JavaScript problem)

2017-09-04 Thread Tor Bug Tracker & Wiki

#10704: TBB 3.5 hangs under OS X on certain sites (possibly a JavaScript 
problem)
-+-
 Reporter:  rppl |  Owner:  erinn
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Blocker  | Resolution:  user
 Keywords:  tbb-usability-website, tbb-3.5,  |  disappeared
  tbb-crash, needs-triage|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

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


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

Re: [tor-bugs] #18592 [Applications/Tor Browser]: pdfjs breaks when javascript.enabled=false (was: pdfjs breaks when javascript disabled)

2017-09-04 Thread Tor Bug Tracker & Wiki

#18592: pdfjs breaks when javascript.enabled=false
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

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

Re: [tor-bugs] #23399 [Applications/Tor Browser]: After I updated TBB from 7.0.4 to 7.0.5, the httpseverywhere extension shows up blank

2017-09-04 Thread Tor Bug Tracker & Wiki

#23399: After I updated TBB from 7.0.4 to 7.0.5, the httpseverywhere extension
shows up blank
--+
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by Dbryrtfbcbhgf):

 Replying to [comment:5 gk]:
 > So this is causes by an error in your config and not really a bug,
 right?
 It looks like 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] #22343 [Applications/Tor Browser]: Save as... in the context menu results in using the catch-all circuit

2017-09-04 Thread Tor Bug Tracker & Wiki

#22343: Save as... in the context menu results in using the catch-all circuit
-+-
 Reporter:  gk   |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-linkability, ff52-esr,   |  Actual Points:
  tbb-7.0-must, tbb-7.0-issues, tbb-regression,  |
  tbb-7.0-frequent, TorBrowserTeam201709R|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * keywords:
 tbb-linkability, ff52-esr, tbb-7.0-must, tbb-7.0-issues, tbb-
 regression, tbb-7.0-frequent, TorBrowserTeam201709
 =>
 tbb-linkability, ff52-esr, tbb-7.0-must, tbb-7.0-issues, tbb-
 regression, tbb-7.0-frequent, TorBrowserTeam201709R
 * status:  needs_revision => needs_review


Comment:

 Here's the patch revised to fix the problem found by mcs and brade for an
 image inside an iframe, discussed in comment:25:

 https://github.com/arthuredelstein/tor-browser/commit/22343+7

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

Re: [tor-bugs] #23400 [Applications/Tor Browser]: There is no way to change HTTPS Everywhere's settings

2017-09-04 Thread Tor Bug Tracker & Wiki

#23400: There is no way to change HTTPS Everywhere's settings
--+---
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by gk):

 Replying to [comment:4 Dbryrtfbcbhgf]:
 > Replying to [comment:2 gk]:
 > > Does it show up if you restart Tor Browser?
 > But going the extension tab there is sill no way to edit its settings.

 Yes, that's a HTTPS-Everywhere bug worth filing (or it may already get
 tracked somewhere).

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

Re: [tor-bugs] #23359 [Applications/Tor Browser]: HTTPS-Everywhere icon is not shown on first start but on restart

2017-09-04 Thread Tor Bug Tracker & Wiki

#23359: HTTPS-Everywhere icon is not shown on first start but on restart
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * cc: Dbryrtfbcbhgf (added)


Comment:

 #23400 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] #23400 [Applications/Tor Browser]: There is no way to change HTTPS Everywhere's settings

2017-09-04 Thread Tor Bug Tracker & Wiki

#23400: There is no way to change HTTPS Everywhere's settings
--+---
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  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:

 Okay, then this is a duplicate of #23359.

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

Re: [tor-bugs] #23400 [Applications/Tor Browser]: There is no way to change HTTPS Everywhere's settings

2017-09-04 Thread Tor Bug Tracker & Wiki

#23400: There is no way to change HTTPS Everywhere's settings
--+---
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by Dbryrtfbcbhgf):

 Replying to [comment:2 gk]:
 > Does it show up if you restart Tor Browser?
 No, it does not show up.

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

Re: [tor-bugs] #23400 [Applications/Tor Browser]: There is no way to change HTTPS Everywhere's settings

2017-09-04 Thread Tor Bug Tracker & Wiki

#23400: There is no way to change HTTPS Everywhere's settings
--+---
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information


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

Re: [tor-bugs] #23400 [Applications/Tor Browser]: There is no way to change HTTPS Everywhere's settings

2017-09-04 Thread Tor Bug Tracker & Wiki

#23400: There is no way to change HTTPS Everywhere's settings
--+--
 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:
--+--

Comment (by gk):

 Does it show up if you restart Tor Browser?

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

Re: [tor-bugs] #23399 [Applications/Tor Browser]: After I updated TBB from 7.0.4 to 7.0.5, the httpseverywhere extension shows up blank

2017-09-04 Thread Tor Bug Tracker & Wiki

#23399: After I updated TBB from 7.0.4 to 7.0.5, the httpseverywhere extension
shows up blank
--+
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  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:

 So this is causes by an error in your config and not really a bug, right?

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

Re: [tor-bugs] #23400 [Applications/Tor Browser]: There is no way to change HTTPS Everywhere's settings (was: the httsp everywhere icon in not in the menu bar and does not show up when I click the men

2017-09-04 Thread Tor Bug Tracker & Wiki

#23400: There is no way to change HTTPS Everywhere's settings
--+--
 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:
--+--

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

Re: [tor-bugs] #23400 [Applications/Tor Browser]: the httsp everywhere icon in not in the menu bar and does not show up when I click the menu button, so there is no way to change Https everywhere's se

2017-09-04 Thread Tor Bug Tracker & Wiki

#23400: the httsp everywhere icon in not in the menu bar and does not show up 
when
I click the menu button, so there is no way to change Https everywhere's
settings.
--+--
 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 "bug 1.png" added.

 Photo showing the 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

[tor-bugs] #23400 [Applications/Tor Browser]: the httsp everywhere icon in not in the menu bar and does not show up when I click the menu button, so there is no way to change Https everywhere's settin

2017-09-04 Thread Tor Bug Tracker & Wiki

#23400: the httsp everywhere icon in not in the menu bar and does not show up 
when
I click the menu button, so there is no way to change Https everywhere's
settings.
--+--
 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:|
--+--
 After the reinstall, the httsp everywhere icon in not in the menu bar and
 does not show up when I click the menu button, so there is no way to
 change Https everywhere's settings.
 Going the extension tab there is sill no way to edit its settings.
 I'm on macOS 10.12.6

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

Re: [tor-bugs] #23399 [Applications/Tor Browser]: After I updated TBB from 7.0.4 to 7.0.5, the httpseverywhere extension shows up blank

2017-09-04 Thread Tor Bug Tracker & Wiki

#23399: After I updated TBB from 7.0.4 to 7.0.5, the httpseverywhere extension
shows up blank
--+--
 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:
--+--

Comment (by Dbryrtfbcbhgf):

 Replying to [comment:2 boklm]:
 > Which security level are you using?
 >
 > My Tor Browser updated from 7.0.4 does not have this issue.
 I found what was causing the bug, I went into about:config and set
 javascript-enabled to false before I updated, after the update settings
 javascript-enabled to false causes the bug to occur.

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

Re: [tor-bugs] #23384 [Applications/Tor Browser]: Configure VM for Tor Browser builds

2017-09-04 Thread Tor Bug Tracker & Wiki

#23384: Configure VM for Tor Browser builds
--+--
 Reporter:  boklm |  Owner:  boklm
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201709  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by boklm):

 * cc: gk, arthuredelstein, mcs, brade (added)


Comment:

 I started adding some ansible scripts for doing that in commits
 093a213a2940e5c005e5044bc89b4fbedc46d461 and
 1f108e3d3ddcfeff88c613f99983afc2e41cc273, and I am currently doing a build
 on this machine to check that it is working.

 gk, arthuredelstein, mcs, brade: could you send me the username and ssh
 key you would like to use to access this machine?

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

Re: [tor-bugs] #20781 [Applications/Tor Browser Sandbox]: Figure out how to sandbox meek in a sensible way.

2017-09-04 Thread Tor Bug Tracker & Wiki

#20781: Figure out how to sandbox meek in a sensible way.
--+-
 Reporter:  yawning   |  Owner:  yawning
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:  meek  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by cypherpunks):

 Even with #23362?

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

Re: [tor-bugs] #23399 [Applications/Tor Browser]: After I updated TBB from 7.0.4 to 7.0.5, the httpseverywhere extension shows up blank

2017-09-04 Thread Tor Bug Tracker & Wiki

#23399: After I updated TBB from 7.0.4 to 7.0.5, the httpseverywhere extension
shows up blank
--+--
 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 "bug 1.png" added.


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

Re: [tor-bugs] #23399 [Applications/Tor Browser]: After I updated TBB from 7.0.4 to 7.0.5, the httpseverywhere extension shows up blank

2017-09-04 Thread Tor Bug Tracker & Wiki

#23399: After I updated TBB from 7.0.4 to 7.0.5, the httpseverywhere extension
shows up blank
--+--
 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:
--+--

Comment (by Dbryrtfbcbhgf):

 Replying to [comment:2 boklm]:
 > Which security level are you using?
 >
 > My Tor Browser updated from 7.0.4 does not have this issue.
 High, and I'm on macOS 10.12.6
 After the reinstall, the httsp everywhere icon in not in the menu bar and
 does not show up when I click the menu button, so there is no way to
 change Https everywhere's settings.
 going the extension tab there is sill no way to edit its settings.

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

Re: [tor-bugs] #23399 [Applications/Tor Browser]: After I updated TBB from 7.0.4 to 7.0.5, the httpseverywhere extension shows up blank

2017-09-04 Thread Tor Bug Tracker & Wiki

#23399: After I updated TBB from 7.0.4 to 7.0.5, the httpseverywhere extension
shows up blank
--+--
 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:
--+--

Comment (by boklm):

 Which security level are you using?

 My Tor Browser updated from 7.0.4 does not have this issue.

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

Re: [tor-bugs] #23399 [Applications/Tor Browser]: After I updated TBB from 7.0.4 to 7.0.5, the httpseverywhere extension shows up blank

2017-09-04 Thread Tor Bug Tracker & Wiki

#23399: After I updated TBB from 7.0.4 to 7.0.5, the httpseverywhere extension
shows up blank
--+--
 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:
--+--

Comment (by Dbryrtfbcbhgf):

 Deleting TBB and re-downloading it fixes the issue, but all users that use
 the builtin updater might be effected by this bug.

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

Re: [tor-bugs] #23399 [Applications/Tor Browser]: After I updated TBB from 7.0.4 to 7.0.5, the httpseverywhere extension shows up blank

2017-09-04 Thread Tor Bug Tracker & Wiki

#23399: After I updated TBB from 7.0.4 to 7.0.5, the httpseverywhere extension
shows up blank
--+--
 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 "bug.png" added.

 Photo of the 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

[tor-bugs] #23399 [Applications/Tor Browser]: After I updated TBB from 7.0.4 to 7.0.5, the httpseverywhere extension shows up blank

2017-09-04 Thread Tor Bug Tracker & Wiki

#23399: After I updated TBB from 7.0.4 to 7.0.5, the httpseverywhere extension
shows up blank
--+--
 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:|
--+--
 After I updated TBB from 7.0.4 to 7.0.5, the httpseverywhere extension
 shows up blank when I click on 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] #23387 [Core Tor/Tor]: prop224: HSdir index desynch between client and service

2017-09-04 Thread Tor Bug Tracker & Wiki

#23387: prop224: HSdir index desynch between client and service
-+
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  needs_revision
 Priority:  Very 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:
 Reviewer:   |Sponsor:
-+

Comment (by asn):

 OK based on the comment above, I present a less-radical branch at
 `bug23387_asn`. This branch does not change the way overlap periods are
 detected, but still only rotates descs when exiting overlap periods. It
 also uses valid_after time when computing hsdir indices, and time period
 nums. Seems to work fine in my testing so far.

 I'm now writing a unittest that will test various cases with timing on the
 client and service. It's pretty advanced so I'll probably finish it
 tomorrow or the day after.

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

Re: [tor-bugs] #23398 [Core Tor/Tor]: My relay Consensus Weight went from around 11000 to 20

2017-09-04 Thread Tor Bug Tracker & Wiki

#23398: My relay Consensus Weight went from around 11000 to 20
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by Dbryrtfbcbhgf):

 And the middle probability went to almost 0.

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

[tor-bugs] #23398 [Core Tor/Tor]: My relay Consensus Weight went from around 11000 to 20

2017-09-04 Thread Tor Bug Tracker & Wiki

#23398: My relay Consensus Weight went from around 11000 to 20
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Tor   |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 My relay Consensus Weight went from around 11000 to 20, this happened
 overnight and the relay was online the whole time.
 https://atlas.torproject.org/#details/39F5044735BFA39FD959BB0A1161CC3E51225377

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

Re: [tor-bugs] #23366 [Core Tor/Tor]: test: test_options_validate__outbound_addresses is broken

2017-09-04 Thread Tor Bug Tracker & Wiki

#23366: test: test_options_validate__outbound_addresses is broken
--+
 Reporter:  dgoulet   |  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-test  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 merged!

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

Re: [tor-bugs] #23397 [Applications/Tor Browser]: Something is totally brain damaged with the way Tor Browser handles PDFs at Medium Security Setting

2017-09-04 Thread Tor Bug Tracker & Wiki

#23397: Something is totally brain damaged with the way Tor Browser handles 
PDFs at
Medium Security Setting
---+--
 Reporter:  cypherpunks|  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-security-slider, noscript  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 Workaround: "Temporarily allow all this page" and refresh (F5).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

2017-09-04 Thread Tor Bug Tracker & Wiki

#22891: Add GitLab CI configs
-+-
 Reporter:  catalyst |  Owner:  hiro
 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:  ahf, dgoulet |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_information => 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] #23346 [Core Tor/Tor]: prop224: HSdir set changed detection fails sometimes

2017-09-04 Thread Tor Bug Tracker & Wiki

#23346: prop224: HSdir set changed detection fails sometimes
-+
 Reporter:  asn  |  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:  prop224, tor-hs  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:  SponsorR-can
-+
Changes (by nickm):

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


Comment:

 Hm. This code changes from an `O(n log n)` algorithm (sort and compare) to
 an `O(n^2^)` algorithm (iterate over list, searching second list for each
 element).  I guess that's okay, because these lists are small?

 If that's so, this looks okay to me.  Merging.

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

Re: [tor-bugs] #23331 [Core Tor/Tor]: prop224: Don't build HS desc if we don't have a live consensus

2017-09-04 Thread Tor Bug Tracker & Wiki

#23331: prop224: Don't build HS desc if we don't have a live consensus
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  prop224   |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:  SponsorR-can
--+
Changes (by nickm):

 * status:  merge_ready => needs_revision


Comment:

 I agree with adding the check in hs_service_callback(), but I'm not sure
 it makes sense to remove the one in should_service_upload_descriptor().
 It's a cheap thing to check, and it protects us in case we start calling
 should_service_upload_descriptor() from anywhere else in the codebase.

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

Re: [tor-bugs] #23327 [Core Tor/Tor]: prop224: client-side memleaks on the last hidserv request subsystem

2017-09-04 Thread Tor Bug Tracker & Wiki

#23327: prop224: client-side memleaks on the last hidserv request subsystem
--+
 Reporter:  asn   |  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-hs, prop224, memleak  |  Actual Points:
Parent ID:  #23300| Points:  0.3
 Reviewer:  asn   |Sponsor:
--+
Changes (by nickm):

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


Comment:

 merging!

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

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

2017-09-04 Thread Tor Bug Tracker & Wiki

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

Comment (by nickm):

 lgtm too, but I'll wait to see if you want change anything because of
 asn's question.

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

Re: [tor-bugs] #23361 [Core Tor/Tor]: prop224: client can pick super old rendezvous points

2017-09-04 Thread Tor Bug Tracker & Wiki

#23361: prop224: client can pick super old rendezvous points
-+
 Reporter:  asn  |  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, tor-hs  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:  SponsorR-can
-+
Changes (by nickm):

 * status:  merge_ready => needs_revision


Comment:

 Also, this seems to violate proposal 224 section 4.3, which says that we
 _can_ use older rendezvous points.  Why  did we decide not to do that?

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

Re: [tor-bugs] #23361 [Core Tor/Tor]: prop224: client can pick super old rendezvous points

2017-09-04 Thread Tor Bug Tracker & Wiki

#23361: prop224: client can pick super old rendezvous points
-+
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  merge_ready
 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:
 Reviewer:  asn  |Sponsor:  SponsorR-can
-+

Comment (by nickm):

 Code looks okay.

 This still needs the spec change that teor mentioned above, right?

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

Re: [tor-bugs] #22939 [Applications/Tor Messenger]: Can't configure my OTR key

2017-09-04 Thread Tor Bug Tracker & Wiki

#22939: Can't configure my OTR key
+--
 Reporter:  cypherpunks |  Owner:  (none)
 Type:  task| Status:  closed
 Priority:  High|  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:  user disappeared
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arlolra):

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


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

Re: [tor-bugs] #16596 [Metrics/ExoneraTor]: Change database queries towards making only a single query per request

2017-09-04 Thread Tor Bug Tracker & Wiki

#16596: Change database queries towards making only a single query per request
+--
 Reporter:  karsten |  Owner:  karsten
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by iwakeh):

 Already found a bit.  There are also a few things that are part of other
 tickets (#19623, #19624, #21145), which I tried to omit here.

 ExoneraTorServlet: `exoneratorHost` should not be configured via web.xml,
 rather use simple java properties file or even simpler hard code.  After
 all it shouldn't change that often, should it?

 In 'step 3' I see some problems with `null` values, for example,
 `"".equals(null)` would evaluate to false (line 147 following).

 For most exceptions caught the error message should be logged; and, it
 might be time to switch to slf4j-api and logback, now.

 In addition, reading the response query should also catch
 RuntimeExceptions (possibly from Gson).

 The version received should also be logged, if it differs from the known
 version.
 The known version(s) could be a constant in `ExoneraTorServlet`; either
 just the major part or all.  This makes it more obvious.

 QueryServlet: Helper methods ` private String parseTimestampParameter` and
 `private String parseIpParameter` should be `public static` and tests
 should be added.  Similarly, `private String convertIpV*ToHex`, which
 could be combined by simply adding another argument, i.e., `public static
 String convertIpV4ToHex(String relayIp, boolean isIpV4)`.
 A `MILLISEC_IN_DAY = 24L * 60L * 60L * 1000L` constant would be useful.


 Other: Using the object `Boolean exit` for a triplet state is a bit too
 much of a hack.  There could be a simple enum, as simple as, for example,
 `public enum Exit { U, Y, N; }`.

 Regarding SQL:
 Order-by statement should be using names not numbers.
 Couldn't the exit-information be part of the query already?

 (I could also look into providing some patches, if we agree on the changes
 and you don't have the time?)

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

Re: [tor-bugs] #16596 [Metrics/ExoneraTor]: Change database queries towards making only a single query per request

2017-09-04 Thread Tor Bug Tracker & Wiki

#16596: Change database queries towards making only a single query per request
+
 Reporter:  karsten |  Owner:  karsten
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by iwakeh):

 * status:  needs_review => needs_revision


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

Re: [tor-bugs] #18973 [Applications/Tor Messenger]: Possible authentication bug

2017-09-04 Thread Tor Bug Tracker & Wiki

#18973: Possible authentication bug
+--
 Reporter:  arlolra |  Owner:  arlolra
 Type:  defect  | Status:  closed
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Critical| Resolution:  user disappeared
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arlolra):

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


Comment:

 Not much more to go 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] #22229 [Applications/Tor Messenger]: Compile Linux 64bits versions of Tor Messenger with Selfrando?

2017-09-04 Thread Tor Bug Tracker & Wiki

#9: Compile Linux 64bits versions of Tor Messenger with Selfrando?
+-
 Reporter:  blockflare  |  Owner:  (none)
 Type:  enhancement | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:  implemented
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by arlolra):

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


Comment:

 Done in https://gitweb.torproject.org/tor-messenger-
 build.git/commit/?id=f63b980484f55bdf0bab86720587077b4474b679

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

Re: [tor-bugs] #23360 [Core Tor/Tor]: prop224: Service has dead code which removed a feature

2017-09-04 Thread Tor Bug Tracker & Wiki

#23360: prop224: Service has dead code which removed a feature
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+
Changes (by nickm):

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


Comment:

 squashed and merged

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

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

2017-09-04 Thread Tor Bug Tracker & Wiki

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

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


Comment:

 Merged.  But: Should there be tests here?  And has one of you tried this?
 (having a service and HUPping 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] #23372 [Core Tor/Tor]: test: stack-use-after-scope in hs_service/build_update_descriptors

2017-09-04 Thread Tor Bug Tracker & Wiki

#23372: test: stack-use-after-scope in hs_service/build_update_descriptors
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-test, tor-hs  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * 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] #22752 [Core Tor/Tor]: Assertion failure in consensus_cache_entry_handle_get on Windows

2017-09-04 Thread Tor Bug Tracker & Wiki

#22752: Assertion failure in consensus_cache_entry_handle_get on Windows
--+
 Reporter:  ahf   |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:  Sponsor4
--+

Comment (by Vort):

 > Any results so far?

 4 days of online: no errors in the log file and exactly 256 files in diff-
 cache.

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

Re: [tor-bugs] #23378 [Core Tor/Tor]: Call "Sandbox 1" no longer an experimental feature?

2017-09-04 Thread Tor Bug Tracker & Wiki

#23378: Call "Sandbox 1" no longer an experimental feature?
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:   => Tor: 0.3.3.x-final


Comment:

 In my opinion, we can change it from "experimental" to "linux-only".

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

Re: [tor-bugs] #22752 [Core Tor/Tor]: Assertion failure in consensus_cache_entry_handle_get on Windows

2017-09-04 Thread Tor Bug Tracker & Wiki

#22752: Assertion failure in consensus_cache_entry_handle_get on Windows
--+
 Reporter:  ahf   |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:  Sponsor4
--+
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 Vort: Thanks!  Any results so far?

 dgoulet: I've added another commit to `bug22752_031_simple` with more
 comments.

 I think this is probably good to merge; please let me know some time soon
 if either of you disagree. ;)

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

Re: [tor-bugs] #20234 [Metrics/CollecTor]: Define CollecTor's file-structure protocol

2017-09-04 Thread Tor Bug Tracker & Wiki

#20234: Define CollecTor's file-structure protocol
---+---
 Reporter:  karsten|  Owner:  iwakeh
 Type:  enhancement| Status:  needs_information
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by karsten):

 Replying to [comment:15 iwakeh]:
 > With the new webstats module the path description should be adapted.

 Yes! Should we create a new ticket for that issue, though? Maybe "Extend
 CollecTor's file structure protocol by web server logs"? And do you want
 to prepare patch?

 > Should we use the newfound spec format here?
 >
 > And, add this spec (once it comes in the new format and is adapted) to
 Metrics web?

 Yes, that's a good idea. However, with all the other open issues I'd
 prefer if we can put this one on hold until we have resolved at least some
 of them. How about we update the summary of this ticket to reflect that
 the only remaining task here is to "Prettify CollecTor's file structure
 protocol and put it on Tor Metrics"?

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

Re: [tor-bugs] #22818 [Core Tor/Tor]: Improve documentation for building Tor with Rust

2017-09-04 Thread Tor Bug Tracker & Wiki

#22818: Improve documentation for building Tor with Rust
+--
 Reporter:  chelseakomlo|  Owner:  (none)
 Type:  enhancement | Status:  closed
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.3.1.2-alpha
 Severity:  Normal  | Resolution:  implemented
 Keywords:  rust tor-build docs rust-pilot  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:  SponsorZ
+--
Changes (by nickm):

 * status:  needs_review => closed
 * resolution:   => implemented
 * milestone:  Tor: 0.3.1.x-final => Tor: 0.3.2.x-final


Comment:

 Thanks!  I'm merging this in 0.3.2. We can take more patches here as we
 find 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] #23395 [Webpages/Blog]: Every blog post had its comments set back to 'open'?

2017-09-04 Thread Tor Bug Tracker & Wiki

#23395: Every blog post had its comments set back to 'open'?
---+--
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by hiro):

 I have actually checked this setting directly in drupal DB and it seems
 like it is more complicated than I thought to change this value for single
 posts instead of just having comments closed by default.

 The reason behind this is that with the long and complicated migration
 from the old blog we have some of the data in different tables, so we
 should be a bit careful with changing stuff manually.

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

Re: [tor-bugs] #23395 [Webpages/Blog]: Every blog post had its comments set back to 'open'?

2017-09-04 Thread Tor Bug Tracker & Wiki

#23395: Every blog post had its comments set back to 'open'?
---+--
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by hiro):

 I have reverted comments to closed by default.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

2017-09-04 Thread Tor Bug Tracker & Wiki

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

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


Comment:

 thanks; merged!

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

Re: [tor-bugs] #23397 [Applications/Tor Browser]: Something is totally brain damaged with the way Tor Browser handles PDFs at Medium Security Setting

2017-09-04 Thread Tor Bug Tracker & Wiki

#23397: Something is totally brain damaged with the way Tor Browser handles 
PDFs at
Medium Security Setting
---+--
 Reporter:  cypherpunks|  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-security-slider, noscript  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cypherpunks):

 * keywords:  tbb-security-slider => tbb-security-slider, noscript


Comment:

 {{{
 15:29:06.073 TypeError: keys[0].match(...) is null 1 Main.js:1266:20
 }}}
 instead of reloading this page with JS temporarily enabled at 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] #23126 [Core Tor/Tor]: HSDirs should publish some count about new-style onion addresses

2017-09-04 Thread Tor Bug Tracker & Wiki

#23126: HSDirs should publish some count about new-style onion addresses
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, prop224-extra,  |  Actual Points:
  research   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 So a very very basic statistic here that would give us an idea of the
 adoption of HSv3 services could be:

 a) When a time period completes, every relay '''publishes the number of
 HSv3 blinded keys''' it saw during the previous time period in its extra-
 info desc. Relays also add some laplace noise to obfuscate the original
 number. Time periods start at 12:00 UTC and last 24 hours, so relays can
 publish this statistic once per day.

 b) After we have received all descriptors containing stats from a specific
 time period, we add all the ''unique blinded key counts'' together, and
 publish the aggregate count. We add everything together to remove the
 laplace noise, and also to get a final graphable number. Unfortunately,
 that final number is not the number of unique HSv3 services since HSes
 publish their HS on multiple HSDirs under the same blinded key. However
 this number is definitely related to the number of unique HSes, by
 noticing how this number moves over time, we can certainly spot adoption
 rates of HSv3 services.

 This is a very basic stat that could help us here. Furthermore, we can
 then deploy similar analysis to what we did for the unique v2 .onion
 counts, to weed out the duplicate HSes so that we get a more accurate
 number. And I guess we can use privcount etc. to get an even more accurate
 number.

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

Re: [tor-bugs] #23397 [Applications/Tor Browser]: Something is totally brain damaged with the way Tor Browser handles PDFs at Medium Security Setting

2017-09-04 Thread Tor Bug Tracker & Wiki

#23397: Something is totally brain damaged with the way Tor Browser handles 
PDFs at
Medium Security Setting
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security-slider   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:   => tbb-security-slider
 * severity:  Major => Normal


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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #20636, #21951, #23136, #23261

2017-09-04 Thread Tor Bug Tracker & Wiki

Batch modification to #20636, #21951, #23136, #23261 by gk:


Comment:
Adding to our September 2017 tickets.

--
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] #23262 [Applications/Tor Launcher]: implement integrated progress bar for new Tor Launcher UI

2017-09-04 Thread Tor Bug Tracker & Wiki

#23262: implement integrated progress bar for new Tor Launcher UI
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201709  |  Actual Points:
Parent ID:  #21951 | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--
Changes (by gk):

 * keywords:  ux-team => ux-team, TorBrowserTeam201709
 * sponsor:   => Sponsor4


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

Re: [tor-bugs] #21286 [Applications/Tor Browser]: Have some nightly builds using the new build process

2017-09-04 Thread Tor Bug Tracker & Wiki

#21286: Have some nightly builds using the new build process
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201709  |  Actual Points:
Parent ID:  #17379| Points:
 Reviewer:|Sponsor:  Sponsor4
--+--

Comment (by boklm):

 We have some nightly builds on http://f4amtbsowhix7rrf.onion/, however it
 is currently broken because of lack of disk space.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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: #6119, #16010, #22692, #14205, ...

2017-09-04 Thread Tor Bug Tracker & Wiki

Batch modification to #6119, #16010, #22692, #14205, #16341, #17965, #18599, 
#22343, #22451, #12418, #18925, #20254, #21256, #21286, #21484, #21542, #21657, 
#21674, #21689, #21727, #21850, #21851, #21863, #22070, #22125, #22525, #22581, 
#22586, #22587, #22612, #22651, #22659, #22794, #22854, #23024, #23213 by gk:


Comment:
Items for September 2017.

--
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] #23397 [Applications/Tor Browser]: Something is totally brain damaged with the way Tor Browser handles PDFs at Medium Security Setting

2017-09-04 Thread Tor Bug Tracker & Wiki

#23397: Something is totally brain damaged with the way Tor Browser handles 
PDFs at
Medium Security Setting
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Steps to reproduce the issue:

 1. Open Stock Tor Browser 7.5a4.
 2. Set the security setting to {{{Low}}}.
 3. Visit
 {{{https://web.archive.org/save/https://svn.torproject.org/svn/projects
 /design-paper/tor-design.pdf}}}, after some time PDF should show up.
 4. Set the security setting to {{{Medium}}}.
 5. Refresh the page.
 6. PDF wont show up no matter how much you wait :(

 There's nothing in the stuff that is disabled at {{{Medium}}} security
 setting that would cause the PDF to not show up, so this is most
 definitely 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] #13398 [Applications/Tor Browser]: at startup, browser gleans user FULL NAME (real name, given name) from O/S

2017-09-04 Thread Tor Bug Tracker & Wiki

#13398: at startup, browser gleans user FULL NAME (real name, given name) from 
O/S
--+
 Reporter:  zinc  |  Owner:  pospeselr
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201708  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

 * status:  needs_information => needs_revision


Comment:

 Replying to [comment:23 mcs]:
 > Replying to [comment:22 gk]:
 > > However, after thinking more about this patch I have a bigger concern.
 What is it defending against? I mean, what prevents a rogue extension from
 flipping our pref and just read the values we tried to hide? (I know I
 suggested the pref approach first and should probably have thought more
 about it and not just have recommended the "standard thing" when Firefox
 patches are concerned).
 > >
 > > One could argue that's not possible with the new WebExtensions-based
 add-ons (which is correct) but then I bet those extensions are not allowed
 to extract the info we want to hide in the first place either (but I could
 be wrong about that). So, should we just say this will be fixed when we
 switch to Firefox 59? And, if we really want to defend against that in the
 ESR 52 cycle we would just rip out the offending code (not bothering about
 upstreaming the patch)?
 >
 > So maybe just add #ifdefs for ESR52 to remove the code? I'd still feel
 better if the info was never read (and thus present in memory) in ESR 59
 and later, but in theory the info should not be accessible to
 Webextensions.

 Yes, I think I agree. We could keep the #ifdefs for ESR59 and talk to
 Mozilla folks about it.

 Sorry again, Richard, but we should revise this patch making it more
 straightforward and ignoring upstreaming concerns for now.

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

Re: [tor-bugs] #23213 [Applications/Tor Browser]: Use rbm for our alpha builds

2017-09-04 Thread Tor Bug Tracker & Wiki

#23213: Use rbm for our alpha builds
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201708,|  Actual Points:
  GeorgKoppen201709  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by gk):

 * keywords:  TorBrowserTeam201708 => TorBrowserTeam201708,
   GeorgKoppen201709


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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: #16010, #22692, #22451, #18925, ...

2017-09-04 Thread Tor Bug Tracker & Wiki

Batch modification to #16010, #22692, #22451, #18925, #20254, #21256, #22581, 
#22659 by gk:


Comment:
Moving my tickets to the new month.

--
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] #16106 [Core Tor/Tor]: Sandbox causes crash when creating a hidden service through the control port

2017-09-04 Thread Tor Bug Tracker & Wiki

#16106: Sandbox causes crash when creating a hidden service through the control
port
-+-
 Reporter:  micahlee |  Owner:  (none)
 Type:  defect   | Status:  needs_revision
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.2.5.12
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs client crash sandbox  |  Actual Points:
Parent ID:   | Points:  small/medium
 Reviewer:   |Sponsor:
-+-

Comment (by yawning):

 Is this still even realistically an issue, beyond the fact that it crashes
 when it shouldn't?  Supporting creating HSes with Tor's sandbox enabled
 the hard way (ie: without `ADD_ONION`) is non-trivial for exactly the same
 reasons why #22605 is hard.

 More to the point, `ADD_ONION` works fine and is available on all
 currently supported tor releases except for the 0.2.5.x series...

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

Re: [tor-bugs] #23387 [Core Tor/Tor]: prop224: HSdir index desynch between client and service

2017-09-04 Thread Tor Bug Tracker & Wiki

#23387: prop224: HSdir index desynch between client and service
-+
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  needs_revision
 Priority:  Very 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:
 Reviewer:   |Sponsor:
-+
Changes (by asn):

 * status:  needs_review => needs_revision


Comment:

 Dumping some comments from my review and testing here:

 a) There is no commit msg in `daf72124` of why we don't like the previous
 approach of figuring out whether overlap period just started/ended. I
 don't really like this new approach of checking `consensus->valid_after ==
 tp_start_time`, since there is no guarantee that Tor will get all the
 consensuses: it can skip a consensus, and if it skips the right one then
 we will never detect an overlap change.

 This logic also caused an assert in my testing since we do:
 {{{
 if (!overlap_mode_is_active && !overlap_mode_just_ended) {
   tor_assert(!service->desc_next);
 }}}
 and I accidentally triggered that because I suspended my laptop for 6
 hours, which means that Tor missed the overlap-changing consensus, so it
 never actually rotated descriptors. Not sure how to fix this issue. I
 think the old logic was more robust; not sure why we ditched it.

 b) Also seems like we still need a `if (service->desc_next)` guard before
 `rotate_service_descriptors()` since it seems that it can go there with
 `desc_next` being NULL and it will overwrite `desc_current` with NULL.

 c) Also should we change all places we get the current time period num to
 use the consensus valid after? To reduce desynch possibilities?

 c) This final comment is not related to this branch, but I think there is
 a case of HSDir desynch that ''we don't handle in the current prop224
 spec'': Consider an HS with 13:00 consensus, and a client with 11:00
 consensus. This means that the client is in time period #N and the HS is
 in time period #N+1. The HS thinks it's in non-overlap mode so it only
 uploads the current descriptor for time period #N+1. Meanwhile, the client
 always downloads the current descriptor so it will attempt to download the
 descriptor for time period #N which could have expired in theory.

 This happens because we have an overlap period covering TP #N+1 from TP
 #N, but we don't have one that covers TP #N from TP #N+1.

 I'm dumping these thoughts here. Depending on my schedule today I might or
 might not be able to fix these on time.

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

Re: [tor-bugs] #19617 [Metrics]: Metrics Java projects should all use java8

2017-09-04 Thread Tor Bug Tracker & Wiki

#19617: Metrics Java projects should all use java8
-+
 Reporter:  iwakeh   |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by karsten):

 Merged!

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

1 2 >

1 - 100 of 118 matches

Mail list logo