Re: [tor-bugs] #21059 [Core Tor/Tor]: shared-rand-current-value violates spec

[Tor Bug Tracker & Wiki]

#21059: shared-rand-current-value violates spec
--+
 Reporter:  atagar|  Owner:  asn
 Type:  defect| Status:  reopened
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+

Comment (by asn):

 Replying to [comment:29 atagar]:
 > Hi George, gonna reopen. I argued against your patch a while ago and I
 still disagree with it. If you have the spec say MUST then this order is
 something we should validate. See my earlier comments regarding why you
 probably don't want this headache.
 >
 > Mind reverting your patch?

 Hey atagar, sorry about that. I think I had not understood your concerns.

 FWIW I'm also fine with your patch in comment:20. How would you feel if I
 rebased your comment:20 patch to current torspec master, and pushed that
 instead?

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

Re: [tor-bugs] #21061 [Core Tor/Tor]: Tor configure error - OpenSSL 1.1.0c with MinGW

[Tor Bug Tracker & Wiki]

#21061: Tor configure error - OpenSSL 1.1.0c with MinGW
+
 Reporter:  Diapolo |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.0.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  OpenSSL, MinGW  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by Diapolo):

 Sorry for answering late. Is a config.log automatically generated in my
 build dir? I'm asking, because I didn't keep the non working files and
 would try to build again, to get a config.log.

 Dia

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

Re: [tor-bugs] #18914 [Applications/Tor Browser]: Consider removing

[Tor Bug Tracker & Wiki]

#18914: Consider removing 
-+-
 Reporter:  mcs  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff45-esr, TorBrowserTeam201605R, |  Actual Points:
  tbb-fingerprinting |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * keywords:  ff45-esr, TorBrowserTeam201605R => ff45-esr,
 TorBrowserTeam201605R, tbb-fingerprinting


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

Re: [tor-bugs] #19459 [Applications/Tor Browser]: Write (C++) patch for window resizing parts

[Tor Bug Tracker & Wiki]

#19459: Write (C++) patch for window resizing parts
-+-
 Reporter:  gk   |  Owner:
 |  arthuredelstein
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-torbutton-conversion,|  Actual Points:
  TorBrowserTeam201611R, tbb-fingerprinting  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-
Changes (by arthuredelstein):

 * keywords:  tbb-torbutton-conversion, TorBrowserTeam201611R => tbb-
 torbutton-conversion, TorBrowserTeam201611R, tbb-fingerprinting


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

Re: [tor-bugs] #16622 [Applications/Tor Browser]: Spoof Timezone from Firefox patch

[Tor Bug Tracker & Wiki]

#16622: Spoof Timezone from Firefox patch
-+-
 Reporter:  mikeperry|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-torbutton-conversion,|  Actual Points:
  TorBrowserTeam201611R, tbb-fingerprinting  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-
Changes (by arthuredelstein):

 * keywords:  tbb-torbutton-conversion, TorBrowserTeam201611R => tbb-
 torbutton-conversion, TorBrowserTeam201611R, tbb-fingerprinting


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21217 [User Experience/Website]: Organizing and adding to media.torproject.org

[Tor Bug Tracker & Wiki]

#21217: Organizing and adding to media.torproject.org
-+---
 Reporter:  lnl  |  Owner:
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   |   Keywords:  media
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+---
 I would like access to media.torproject.org so that I can:

 - organize what's already hosted at media.torproject.org
 - decide what we should keep, host somewhere else, and not keep at
 media.torproject.org
 - work to update and add images to media.torproject.org

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

Re: [tor-bugs] #21216 [Internal Services/Tor Sysadmin Team]: Need a virtual host to run OnionPerf

[Tor Bug Tracker & Wiki]

#21216: Need a virtual host to run OnionPerf
-+-
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by weasel):

 That's a lot of disk space, but not impossible as long as it's ok if it's
 slow.

 How much network traffic do we think this will use?

 Network listening things will this host need to run?

 Who will maintain the service?

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

Re: [tor-bugs] #20929 [Applications/Tor Browser]: Bump GCC version in our alpha builds

[Tor Bug Tracker & Wiki]

#20929: Bump GCC version in our alpha builds
---+---
 Reporter:  gk |  Owner:  tbb-team
 Type:  enhancement| Status:
   |  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-gitian, TorBrowserTeam201701R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by mcs):

 r=brade
 r=mcs

 This looks okay.

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

Re: [tor-bugs] #21194 [Applications/Tor Browser]: Show snowflake in the circuit display

[Tor Bug Tracker & Wiki]

#21194: Show snowflake in the circuit display
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-torbutton,|  Actual Points:
  TorBrowserTeam201701R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 r=brade
 r=mcs

 This patch looks fine. It would be nice to avoid using a hard-coded list
 of bridge types, but that is difficult since we probably cannot assume
 anything about the config for bridge types that have not yet been
 invented.

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

Re: [tor-bugs] #21134 [Core Tor/Tor]: Fail if file is too large to mmap.

[Tor Bug Tracker & Wiki]

#21134: Fail if file is too large to mmap.
---+
 Reporter:  junglefowl |  Owner:
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.2.9.8
 Severity:  Normal | Resolution:
 Keywords:  tor_mmap_file  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by junglefowl):

 ---
 #include 
 #include 

 int
 main(void)
 {
 printf("size_t: %d\n", sizeof(size_t));
 printf("off_t: %d\n", sizeof(off_t));

 return 0;
 }
 ---

 If you compile this code with -D_FILE_OFFSET_BITS=64 (large file support),
 32 bit systems will use 4 bytes for size_t and 8 bytes for off_t:

 $ uname -m
 i686
 $ gcc -o sizes sizes.c
 $ ./sizes
 size_t: 4
 off_t: 4
 $ gcc -D_FILE_OFFSET_BITS=64 -o sizes sizes.c
 $ ./sizes
 size_t: 4
 off_t: 8

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

Re: [tor-bugs] #16659 [Metrics/Analysis]: Linux TCP Initial Sequence Numbers may aid correlation

[Tor Bug Tracker & Wiki]

#16659: Linux TCP Initial Sequence Numbers may aid correlation
--+--
 Reporter:  source|  Owner:
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Metrics/Analysis  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 No:

 https://lists.torproject.org/pipermail/tor-dev/2017-January/011789.html

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

Re: [tor-bugs] #21042 [Applications/Tor Browser]: DDG isn't work form address bar anymore

[Tor Bug Tracker & Wiki]

#21042: DDG isn't work form address bar anymore
-+-
 Reporter:  i139 |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201701R, tbb-  |  Actual Points:
  usability  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 r=brade
 r=mcs

 This seems to fix the problem.

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

Re: [tor-bugs] #19898 [Applications/Tor Browser]: Use default search in about:tor in our alpha builds

[Tor Bug Tracker & Wiki]

#19898: Use default search in about:tor in our alpha builds
--+--
 Reporter:  f451022   |  Owner:  tbb-team
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201701R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mcs):

 r=brade
 r=mcs

 The proposed fix looks fine. The original reporter may have been asking
 for something more sophisticated though: when the user changes their
 default search engine, the about:tor page should use it (which is how
 things work for about:home).

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

Re: [tor-bugs] #21199 [Internal Services/Service - jabber]: Jabber service: only contacts should be allowed to send messages

[Tor Bug Tracker & Wiki]

#21199: Jabber service: only contacts should be allowed to send messages
+
 Reporter:  mrphs   |  Owner:
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Internal Services/Service - jabber  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by cypherpunks):

 * component:  - Select a component => Internal Services/Service - jabber


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

Re: [tor-bugs] #21118 [Core Tor/Tor]: circuit_get_global_origin_circuit_list() returns the wrong list

[Tor Bug Tracker & Wiki]

#21118: circuit_get_global_origin_circuit_list() returns the wrong list
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:  #20921| Points:  .1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 Whoops!  I don't know what happened to that commit.  Added one again.
 Sorry!

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

Re: [tor-bugs] #17847 [Core Tor/Tor]: Unify router_pick_directory_server_impl and router_pick_trusteddirserver_impl

[Tor Bug Tracker & Wiki]

#17847: Unify router_pick_directory_server_impl and
router_pick_trusteddirserver_impl
+
 Reporter:  teor|  Owner:
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  easy, refactor  |  Actual Points:
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:
+
Changes (by nickm):

 * status:  needs_revision => needs_review


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

Re: [tor-bugs] #20502 [Core Tor/Tor]: Setting UseBridges=1 UseEntryGuards=0 means you bypass your bridges

[Tor Bug Tracker & Wiki]

#20502: Setting UseBridges=1 UseEntryGuards=0 means you bypass your bridges
-+
 Reporter:  arma |  Owner:
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  config, review-group-14  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:  chelseakomlo |Sponsor:
-+
Changes (by nickm):

 * status:  needs_revision => needs_review


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

Re: [tor-bugs] #21059 [Core Tor/Tor]: shared-rand-current-value violates spec

[Tor Bug Tracker & Wiki]

#21059: shared-rand-current-value violates spec
--+
 Reporter:  atagar|  Owner:  asn
 Type:  defect| Status:  reopened
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by atagar):

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


Comment:

 Hi George, gonna reopen. I argued against your patch a while ago and I
 still disagree with it. If you have the spec say MUST then this order is
 something we should validate. See my earlier comments regarding why you
 probably don't want this headache.

 Mind reverting your patch?

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

Re: [tor-bugs] #21131 [Applications/Tor Browser]: Remove 2016 about:tor donation banner

[Tor Bug Tracker & Wiki]

#21131: Remove 2016 about:tor donation banner
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fundraising, |  Actual Points:
  TorBrowserTeam201701R  |
Parent ID:  #20413   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 r=mcs
 r=brade

 This looks good to us.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21216 [Internal Services/Tor Sysadmin Team]: Need a virtual host to run OnionPerf

[Tor Bug Tracker & Wiki]

#21216: Need a virtual host to run OnionPerf
-+-
 Reporter:  hiro |  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:   |
-+-
 Hi,

 The metric team needs a VM to have a test run of OnionPerf
 (https://github.com/robgjansen/onionperf).

 Ideally we would like to keep generated logs for several months (>6) so
 approximately 500Gigas of minimum disk space are required (based on a
 rough estimation that 50Mb of logs are generated every few hours).

 Please let me know if I can help you with anything regarding 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

[tor-bugs] #21215 [Core Tor/Tor]: Lower the directory overhead for low-bandwidth clients

[Tor Bug Tracker & Wiki]

#21215: Lower the directory overhead for low-bandwidth clients
--+
 Reporter:  nickm |  Owner:
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  sponsor4
Actual Points:|  Parent ID:
   Points:  parent|   Reviewer:
  Sponsor:|
--+
 This is a parent ticket for the actual implementation work of sponsor4.
 As we complete measurement (#21205) and design (#21209), we'll add child
 tickets here for the particular work we are going to accomplish.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21214 [Core Tor/Tor]: Based on measurement of #21205, write/analyze additional proposals and tickets for lowering bw usage for directory stuff

[Tor Bug Tracker & Wiki]

#21214: Based on measurement of #21205, write/analyze additional proposals and
tickets for lowering bw usage for directory stuff
--+
 Reporter:  nickm |  Owner:
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  sponsor4
Actual Points:|  Parent ID:  #21209
   Points:|   Reviewer:
  Sponsor:|
--+
 Based on the measurements we get from #21205, we'll probably learn more
 about some actual bandwidth needs, and the circumstances when dir BW is
 overused.  We should add tickets to fix the bugs, possibly with proposals,
 based on what we find otu.

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

Re: [tor-bugs] #2149 [Core Tor/Tor]: new 'extra dormant' mode for people who never use their tor

[Tor Bug Tracker & Wiki]

#2149: new 'extra dormant' mode for people who never use their tor
-+-
 Reporter:  arma |  Owner:
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:
 Keywords:  performance, scaling, tor-client,|  Actual Points:
  027-triaged-1-deferrable, 028-triaged, |
  pre028-patch, SponsorU-deferred,   |
  tor-03-unspecified-201612, sponsor4|
Parent ID:   | Points:  large
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:
 performance, scaling, tor-client, 027-triaged-1-deferrable,
 028-triaged, pre028-patch, SponsorU-deferred,
 tor-03-unspecified-201612
 =>
 performance, scaling, tor-client, 027-triaged-1-deferrable,
 028-triaged, pre028-patch, SponsorU-deferred,
 tor-03-unspecified-201612, 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] #21212 [Core Tor/Tor]: Write and analyze proposals for transmitting microdescriptors with less bandwidth

[Tor Bug Tracker & Wiki]

#21212: Write and analyze proposals for transmitting microdescriptors with less
bandwidth
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sponsor4  |  Actual Points:
Parent ID:  #21209| Points:  3
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 #10871 has some earlier discussion of the third idea here.

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #13339, #16844, #2681, #7986, ...

[Tor Bug Tracker & Wiki]

Batch modification to #13339, #16844, #2681, #7986, #10871, #13258 by nickm:
keywords to sponsor4

Comment:
Bulk-adding "sponsor4" keyword to items that would appear to reduce low-bw 
clients' directory bandwidth usage.  But we shouldn't build these without 
measurement/proposals: see #21205 and #21209.

--
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] #21213 [Core Tor/Tor]: Write and analyze proposals for fetching consensuses/microdescriptors less frequently?

[Tor Bug Tracker & Wiki]

#21213: Write and analyze proposals for fetching consensuses/microdescriptors 
less
frequently?
--+
 Reporter:  nickm |  Owner:
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sponsor4  |  Actual Points:
Parent ID:  #21209| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 See also proposal 212

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21213 [Core Tor/Tor]: Write and analyze proposals for fetching consensuses/microdescriptors less frequently?

[Tor Bug Tracker & Wiki]

#21213: Write and analyze proposals for fetching consensuses/microdescriptors 
less
frequently?
--+
 Reporter:  nickm |  Owner:
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  sponsor4
Actual Points:|  Parent ID:  #21209
   Points:|   Reviewer:
  Sponsor:|
--+
 '''The idea''': Our current algorithm for deciding whether you need a new
 consensus is ad hoc; we just picked an interval more or less at random.

 Depending on the results from #21205, we may learn that it's not as
 necessary as we had thought for a client to fetch consensuses and
 microdescriptors so often.  If that's the case, we should have proposals
 and analyses for (optionally?) decreasing the frequency of our downloads.

 There may be different results here for "busy" and "not so busy" clients.

 Of course, the analysis needs to include the security impact.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21212 [Core Tor/Tor]: Write and analyze proposals for transmitting microdescriptors with less bandwidth

[Tor Bug Tracker & Wiki]

#21212: Write and analyze proposals for transmitting microdescriptors with less
bandwidth
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  sponsor4
Actual Points:|  Parent ID:  #21209
   Points:  3 |   Reviewer:
  Sponsor:|
--+
 '''The idea:''' I can think of a few ways to lower the amount of bandwidth
 we use for downloading microdescriptors, without actually fetching any
 fewer.  Would any of them be worthwhile?  We should analyze them and write
 proposals for them.

  * Do we frequently download small batches of microdescriptors?  If so,
 fetching them in larger batches would get us better compression.

  * Do we frequently download small batches of microdescriptors?  If so,
 zlib dictionaries would get us better compression.

  * When a client moves from one consensus to another, the set of
 microdescriptors that the client wants is almost determined by the
 difference between those two consensuses.  (I say "almost" because the
 client may have other mds that occurred in even earlier consensuses.)  Can
 we have clients download microdescriptors in batches that depend on the
 consensus, rather than batches that are named by the microdescriptor
 digests?  This would have these benefits:
 * HTTP requests would get much shorter.
 * Batching many microdescriptors together would improve compression.
 * Batching a ''predictable group'' of microdescriptors together would
 enable us to spend more CPU on compressing those groups, since we wouldn't
 need to compress so many different groups. (See #21211)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21211 [Core Tor/Tor]: Write and analyze proposals for compressing consensus (diff)s with better algorithms

[Tor Bug Tracker & Wiki]

#21211: Write and analyze proposals for compressing consensus (diff)s with 
better
algorithms
--+
 Reporter:  nickm |  Owner:
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  sponsor4
Actual Points:|  Parent ID:  #21209
   Points:  1 |   Reviewer:
  Sponsor:|
--+
 '''The idea:''' Consensus documents are compressed with zlib, but nobody
 has to compress any given consensus more than once.  Therefore, we can
 safely use more CPU compressing them, and save bandwidth on consensus
 downloads by switching to something else instead of zlib for consensuses.

 This same analysis also applies to consensus diffs.

 For this ticket, we should look at the code complexity and potential
 bandwidth savings here, and decide whether they are worth 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

[tor-bugs] #21210 [Core Tor/Tor]: Analyze, and maybe improve, consensus diff proposal

[Tor Bug Tracker & Wiki]

#21210: Analyze, and maybe improve, consensus diff proposal
--+
 Reporter:  nickm |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #21209
   Points:  2 |   Reviewer:
  Sponsor:|
--+
 We should use stats to re-run our numbers on the consensus diff proposal
 (140), and see how much bandwidth we expect to save.  We should consider
 the impact of this proposal alongside alternative or related proposals,
 such as ones that would cause clients to download the consensus less
 frequently.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21209 [Core Tor/Tor]: Write, revise, analyze proposals for ways to use less directory bandwidth

[Tor Bug Tracker & Wiki]

#21209: Write, revise, analyze proposals for ways to use less directory 
bandwidth
--+
 Reporter:  nickm |  Owner:
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  sponsor4
Actual Points:|  Parent ID:
   Points:  parent|   Reviewer:
  Sponsor:|
--+
 We have a bunch of ideas about how to use less bandwidth for directory
 stuff. But most of them need to be expanded into proposals, and some of
 the the ones that *are* proposals need better analysis -- informed in part
 by the information we hope to get from #21205.

 This is a parent ticket.  Each child ticket will be for one particular
 proposal.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21208 [Core Tor/Tor]: Measure overall client bandwidth usage and circuit counts

[Tor Bug Tracker & Wiki]

#21208: Measure overall client bandwidth usage and circuit counts
--+
 Reporter:  nickm |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  sponsor4
Actual Points:|  Parent ID:  #21205
   Points:|   Reviewer:
  Sponsor:|
--+
 See parent ticket for context.

 To put directory requests into context, we should analyze non-directory
 usage in a similar way, for bandwidth and circuit usage.  This part
 doesn't need to be so fine-grained though.

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

[tor-bugs] #21207 [Core Tor/Tor]: Test scenarios for clients that are idle for large periods of time

[Tor Bug Tracker & Wiki]

#21207: Test scenarios for clients that are idle for large periods of time
--+
 Reporter:  nickm |  Owner:
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  sponsor4
Actual Points:|  Parent ID:  #21205
   Points:  3 |   Reviewer:
  Sponsor:|
--+
 See parent ticket for context.

 We could use some automated tests that exercise clients in a certain
 predictable way (as described in the parent ticket), and record the
 directory bandwidth usage and non-directory bandwidth usage.

 I think that we should do this on the real network, and not on a test
 network: otherwise, there are far too many ways that we can get it wrong.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21206 [Core Tor/Tor]: Measure client up/down bandwidth for directory requests, split by type

[Tor Bug Tracker & Wiki]

#21206: Measure client up/down bandwidth for directory requests, split by type
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  sponsor4
Actual Points:|  Parent ID:  #21205
   Points:  3 |   Reviewer:
  Sponsor:|
--+
 See parent ticket for context.

 We need a way to measure, over time, split up by type of directory
 request, how much bandwidth a client uses for requests and for responses.

 We should include both directory lookups that are successful and those
 that are not.

 We should, if possible, measure this with and without circuit overhead.
 But not if it's too hard.

 We should, if possible, count failed circuits that are opened only for
 directory requests. But not if it's too hard.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21205 [Core Tor/Tor]: Instrument clients to measure directory usage

[Tor Bug Tracker & Wiki]

#21205: Instrument clients to measure directory usage
--+
 Reporter:  nickm |  Owner:
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  sponsor4
Actual Points:|  Parent ID:
   Points:  parent|   Reviewer:
  Sponsor:|
--+
 We want to reduce the directory overhead needed for low-bandwidth clients.
 To do this well, we should make it so a client can measure how much stuff
 it downloads, and how much of what kind of traffic it uses to download it.

 In general, this should be local-only measurements for use while testing:
 there's no reason we need a complex infrastructure for this one, since the
 results should be pretty uniform given the same client software in the
 same circumstances.

 Here are some strawman scenarios for client usage which we might want to
 think about:
* Client is completely unused.
* Client is completely unused, but restarted or HUPed once every N
 hours.
* Client is used to fetch a .onion website once every N hours.
* Client is used to fetch a http website once every N hours.
* Client is turned on, and connected to (say) IRC all the time.

 The relevant values of "N" are probably something like: .5 hours, 1 hour,
 4 hours, 8 hours, ... up to a week?


 This is a parent-ticket.  Child tickets will focus on particular
 measurements we want.

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

Re: [tor-bugs] #21132 [User Experience/Website]: Remove donation banner for 2016 campaign

[Tor Bug Tracker & Wiki]

#21132: Remove donation banner for 2016 campaign
-+--
 Reporter:  arthuredelstein  |  Owner:  cypherpunks
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by hiro):

 This is finished and live.

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

Re: [tor-bugs] #3259 [Core Tor/Tor]: don't give up on your bridges so easily

[Tor Bug Tracker & Wiki]

#3259: don't give up on your bridges so easily
-+-
 Reporter:  arma |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridge, 027-triaged-1-in, tor-   |  Actual Points:
  guards-revamp?, isaremoved,|
  tor-03-unspecified-201612  |
Parent ID:   | Points:  1.5
 Reviewer:   |Sponsor:
 |  SponsorU-can
-+-
Changes (by nickm):

 * keywords:
 tor-bridge, 027-triaged-1-in, tor-guards-revamp?, low-bandwidth,
 isaremoved, tor-03-unspecified-201612
 =>
 tor-bridge, 027-triaged-1-in, tor-guards-revamp?, isaremoved,
 tor-03-unspecified-201612


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

Re: [tor-bugs] #21196 [Metrics/Metrics website]: use colorRampPalette instead of limited colorBrewer

[Tor Bug Tracker & Wiki]

#21196: use colorRampPalette instead of limited colorBrewer
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Minor| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Hmm, I'm still a fan of
 [http://colorbrewer2.org/#type=qualitative=Paired=12
 ColorBrewer's Paired] palette.  Those colors are carefully designed to be
 distinguishable, which is not the case with those six manually selected
 colors.

 A repetition after 12 versions seems not ideal, but is probably not the
 end of the world.  That would mean that 0.1.0 and 0.2.9 would have the
 same color, and those two should never have non-zero values on the same
 date.

 However, it seems to be an issue that 0.2.4 and 0.2.9 almost look like the
 same color, when the palette has 12 different colors.  I think that's 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] #20951 [Applications/Tor Browser]: Back out Unix domain socket related patches for Tor Browser 6.5

[Tor Bug Tracker & Wiki]

#20951: Back out Unix domain socket related patches for Tor Browser 6.5
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201701R,   |  Actual Points:
  GeorgKoppen201701  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:3 gk]:
 > So, we are removing the patch for bug 1211567 but keep the fix for
 #19733? Does that scenario gain anybody anything? Or, if we want to keep
 #19733, the scenario to keep 1211567 as well?

 Thanks for the review.

 Our rationale for keeping the #19733 fix is that we thought there was a
 sandbox scenario (reported by Yawning) where Torbutton saw a Unix domain
 sockets SocksPort (via the control port) even when the browser itself was
 not directly using a Unix domain socket.  Including the #19733 fix seems
 safe to Kathy and me and avoids an ugly "unexpected tor response" log
 message.  But we don't think it makes sense to keep the 1211567 fix unless
 we keep all of the browser patches.

 > FWIW: I probably won't apply the tor-browser patches but rather omit the
 patches we don't want to have when rebasing.

 That makes sense.

 > The tor-launcher changes look fine to me. Note: `master` is used for the
 hardened series where we just keep the unix domain socket support. So, the
 patches should have been against `maint-0.2.10`. There is no need to
 create new ones, though, the resulting small conflict in the prefs file is
 easy to solve when preparing the stable branch.

 OK. Kathy and I forgot that alpha is not built from Tor Launcher master.
 Sorry!

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

Re: [tor-bugs] #20502 [Core Tor/Tor]: Setting UseBridges=1 UseEntryGuards=0 means you bypass your bridges

[Tor Bug Tracker & Wiki]

#20502: Setting UseBridges=1 UseEntryGuards=0 means you bypass your bridges
-+
 Reporter:  arma |  Owner:
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  config, review-group-14  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:  chelseakomlo |Sponsor:
-+

Comment (by neel):

 Under the "Updated patch (1/8/17) to disallow UseBridges 1 and
 UseEntryGuards 0" label, I have an updated patch which logs the change as
 a file changes/bug20502.

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

Re: [tor-bugs] #20951 [Applications/Tor Browser]: Back out Unix domain socket related patches for Tor Browser 6.5

[Tor Bug Tracker & Wiki]

#20951: Back out Unix domain socket related patches for Tor Browser 6.5
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201701R,   |  Actual Points:
  GeorgKoppen201701  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 So, we are removing the patch for bug 1211567 but keep the fix for #19733?
 Does that scenario gain anybody anything? Or, if we want to keep #19733,
 the scenario to keep 1211567 as well?

 FWIW: I probably won't apply the tor-browser patches but rather omit the
 patches we don't want to have when rebasing. The tor-launcher changes look
 fine to me. Note: `master` is used for the hardened series where we just
 keep the unix domain socket support. So, the patches should have been
 against `maint-0.2.10`. There is no need to create new ones, though, the
 resulting small conflict in the prefs file is easy to solve when preparing
 the stable branch.

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

Re: [tor-bugs] #21140 [Internal Services/Tor Sysadmin Team]: Document the distinction between sys admin and service admin

[Tor Bug Tracker & Wiki]

#21140: Document the distinction between sys admin and service admin
-+--
 Reporter:  arma |  Owner:  hiro
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by hiro):

 Freshly baked: https://help.torproject.org/tsa/doc/admins/

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

Re: [tor-bugs] #21201 [Applications/Tor Browser]: Adapt torbutton to TBB/FF52ESR

[Tor Bug Tracker & Wiki]

#21201: Adapt torbutton to TBB/FF52ESR
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #20680| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mcs):

 * cc: brade, mcs (added)


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

Re: [tor-bugs] #21198 [Internal Services/Service - trac]: Jabber Component

[Tor Bug Tracker & Wiki]

#21198: Jabber Component
--+
 Reporter:  mrphs |  Owner:  qbi
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

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


Comment:

 There I just added "Internal Services/Service - jabber" and put myself as
 the owner.

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

Re: [tor-bugs] #21199 [- Select a component]: Jabber service: only contacts should be allowed to send messages

[Tor Bug Tracker & Wiki]

#21199: Jabber service: only contacts should be allowed to send messages
--+
 Reporter:  mrphs |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

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


Comment:

 I just installed the `mod_block_strangers` module so we'll see how it goes
 ;).

 https://modules.prosody.im/mod_block_strangers.html

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

Re: [tor-bugs] #21054 [Core Tor/Tor]: hs: BUG() is triggered with ephemeral service on config reload

[Tor Bug Tracker & Wiki]

#21054: hs: BUG() is triggered with ephemeral service on config reload
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, refactoring,|  Actual Points:
  review-group-14|
Parent ID:   | Points:  0.5
 Reviewer:  asn  |Sponsor:
 |  SponsorR-can
-+-
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 OK I managed to reproduce it by using a direct connection to control port
 instead of camrl. David's branch indeed fixes the issue!

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

Re: [tor-bugs] #21204 [Applications/Tor Browser]: Mac Sierra Password Protected Directory

[Tor Bug Tracker & Wiki]

#21204: Mac Sierra Password Protected Directory
--+--
 Reporter:  Slaraty@… |  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * owner:   => tbb-team
 * keywords:  Mac Sierra Password Protected Directory => tbb-usability
 * status:  needs_information => assigned


Comment:

 You mean your Tor Browser? Which version are you using?

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

Re: [tor-bugs] #21178 [User Experience/Website]: torproject.org submenus and page structures behave inconsistently

[Tor Bug Tracker & Wiki]

#21178: torproject.org submenus and page structures behave inconsistently
-+---
 Reporter:  lnl  |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  WebsiteV3
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by gk):

 * component:  - Select a component => User Experience/Website


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

Re: [tor-bugs] #21178 [- Select a component]: torproject.org submenus and page structures behave inconsistently

[Tor Bug Tracker & Wiki]

#21178: torproject.org submenus and page structures behave inconsistently
--+---
 Reporter:  lnl   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  WebsiteV3
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by hiro):

 Hi lnl, I have started working on your list and have fixed the first item.
 https://gitweb.torproject.org/user/hiro/webwml.git/commit/?h=submenus
 And pushed it to staging: https://www-staging.torproject.org/


 I have noticed though that to finish the list we might need to restructure
 links and pages quite a bit. Some links might even change.


 For example. There are rules regarding how to build and include the menus
 that are based on the current structure of how pages are divided into
 directories and subdirectories. I think this can be improved, but some
 links might change in the process.

 I think it would help if we knew already that we want to keep the current
 framework or we want to consider alternatives. If we want to keep it I'd
 clean the current installation as much as I can, otherwise I'd maintain it
 till we are ready to try something different.

 -s

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

Re: [tor-bugs] #21140 [Internal Services/Tor Sysadmin Team]: Document the distinction between sys admin and service admin

[Tor Bug Tracker & Wiki]

#21140: Document the distinction between sys admin and service admin
-+--
 Reporter:  arma |  Owner:  hiro
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by hiro):

 Yes I will.

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

Re: [tor-bugs] #21204 [Applications/Tor Browser]: Mac Sierra Password Protected Directory

[Tor Bug Tracker & Wiki]

#21204: Mac Sierra Password Protected Directory
-+-
 Reporter:  Slaraty@…|  Owner:
 Type:  defect   | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  Mac Sierra Password Protected|  Actual Points:
  Directory  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by asn):

 * status:  new => needs_information
 * component:  Core Tor/Tor => Applications/Tor Browser


Comment:

 Triaging bugs: This is definitely not a Core Tor issue. I moved it to Tor
 Browser just to be sure even though it seems like a support request.

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

Re: [tor-bugs] #21059 [Core Tor/Tor]: shared-rand-current-value violates spec

[Tor Bug Tracker & Wiki]

#21059: shared-rand-current-value violates spec
--+
 Reporter:  atagar|  Owner:  asn
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Major | Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by asn):

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


Comment:

 Hello, to finally resolve this ticket I merged the branch from comment:6
 which specifies that the preamble MUST be accepted in whatever order by
 clients, but authorities MUST be consistent about it (so that consensus
 can be reached).

 I will close this ticket. Feel free to reopen if you think something is
 wrong.

 Thanks :)

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

Re: [tor-bugs] #21054 [Core Tor/Tor]: hs: BUG() is triggered with ephemeral service on config reload

[Tor Bug Tracker & Wiki]

#21054: hs: BUG() is triggered with ephemeral service on config reload
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, refactoring,|  Actual Points:
  review-group-14|
Parent ID:   | Points:  0.5
 Reviewer:  asn  |Sponsor:
 |  SponsorR-can
-+-

Comment (by asn):

 Replying to [comment:5 dgoulet]:
 > Replying to [comment:4 asn]:
 > > Initial review:
 > >
 > > Changes look reasonable to me. One question, why does
 `circuit_get_next_service_intro_circ()` need the `start` argument?
 > >
 > > In the old code, we just iterated from the beginning of the
 circuitlist everytime. Why do we now begin from `start`? Is it an
 optimization?
 >
 > Yes. It is also to basically follow the `circuit_get_next_by_*` API that
 uses that technique. Without it, we can't return a circuit from the middle
 of the list matching our requirements and then continuing the loop at that
 circuit. Else, the other options is for the function to return a list of
 matching circuits. No strong preferences here, I would be fine with
 either.
 >

 I think the way you have it is fine!

 > >
 > > Also, BTW I didn't manage to reproduce the original bug. How do we do
 it? I started up a Tor with a normal HS, then I added an ADD_ONION, and
 then I HUPed. Am I missing a step?
 >
 > Yes, normal service then you do `ADD_ONION NEW:BEST Port=8161` and then
 HUP or `SIGNAL RELOAD`, you should hit the BUG. Btw, it won't be on
 console if you setup logging and should look like this (I just reproduced
 it on master):
 >
 > {{{
 > Jan 09 09:23:44.000 [warn] tor_bug_occurred_(): Bug:
 src/or/rendservice.c:839: rend_config_services: Non-fatal assertion
 !(rend_service_is_ephemeral(new)) failed. (on Tor 0.3.0.1-alpha-dev
 655ffeadd53833d9)
 > Jan 09 09:23:44.000 [warn] Bug: Non-fatal assertion
 !(rend_service_is_ephemeral(new)) failed in rend_config_services at
 src/or/rendservice.c:839. Stack trace: (on Tor 0.3.0.1-alpha-dev
 655ffeadd53833d9)
 > [...]
 > }}}

 Hmm, I'm still unable to repro this with carml. I tried with unpatched
 `df87812` and Tor will just successfuly HUP with no issues. Here is my
 torrc:
 {{{
 SocksPort auto
 ControlPort auto

 HiddenServiceDir /tmp/hidden_service
 HiddenServicePort 6667 127.0.0.1:6667

 CookieAuthentication 1
 CookieAuthFileGroupReadable 1
 ControlPort 9051
 }}}

 And then I just do:
 {{{
 $ ./bin/carml --connect tcp:127.0.0.1:9051 -q cmd ADD_ONION NEW:BEST
 Port=8161
 $ ./bin/carml --connect tcp:127.0.0.1:9051 -q cmd SIGNAL RELOAD
 }}}
 but Tor seems to handle it just fine:
 {{{
 Jan 12 13:16:53.000 [notice] Tor 0.3.0.1-alpha-dev (git-df87812b41abccd6)
 opening log file.
 Jan 12 13:16:57.000 [notice] New control connection opened from 127.0.0.1.
 Jan 12 13:16:58.000 [notice] New control connection opened from 127.0.0.1.
 Jan 12 13:16:58.000 [notice] Received reload signal (hup). Reloading
 config and resetting internal state.
 Jan 12 13:16:58.000 [notice] Read configuration file
 "/home/f/Computers/tor/mytor/../confs/bug21054".
 Jan 12 13:16:58.000 [warn] CookieAuthFileGroupReadable is set, but will
 have no effect: you must specify an explicit CookieAuthFile to have it
 group-readable.
 }}}

 What am I doing wrong?

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

Re: [tor-bugs] #21193 [Core Tor/Tor]: Prop271 spec: High level circuit creation and guard selection overview

[Tor Bug Tracker & Wiki]

#21193: Prop271 spec: High level circuit creation and guard selection overview
--+
 Reporter:  chelseakomlo  |  Owner:
 Type:  enhancement   | Status:  needs_review
 Priority:  Low   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Minor | Resolution:
 Keywords:  torspec   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by asn):

 LGTM. I think the section added is a fine overview section. Perhaps it can
 even be moved above section `2. State instances`, so that it's beneath the
 motivation section like a true overview section would be.

 WRT how much detail is necessary, I think it could be useful to include
 some further information on what it means to ''use'' a circuit or to let
 it ''wait''. This has to do with how streams are assigned to circuits, and
 perhaps it would be useful for readers. Anyhow, this does not need to
 happen in this ticket; it's just some information that would have been
 useful to me when I originally read the proposal.

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

Re: [tor-bugs] #20992 [Core Tor/Tor]: hs: Add more unit tests for failure cases of parsing and validation for ESTABLISH_INTRO v3 cells

[Tor Bug Tracker & Wiki]

#20992: hs: Add more unit tests for failure cases of parsing and validation for
ESTABLISH_INTRO v3 cells
---+
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  enhancement| Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, prop224, test  |  Actual Points:
Parent ID:  #17241 | Points:  0.4
 Reviewer:  asn|Sponsor:  SponsorR-must
---+
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 LGTM. Tests seem to pass as well. Thanks for the code!

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

Re: [tor-bugs] #20918 [Core Tor/Tor]: Switch onion.c to use TRUNNEL_OPAQUE

[Tor Bug Tracker & Wiki]

#20918: Switch onion.c to use TRUNNEL_OPAQUE
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  .2
Parent ID:  #15054| Points:  .1
 Reviewer:  dgoulet   |Sponsor:
--+

Comment (by asn):

 Took a quick look here after Nick's request on IRC. I actually don't have
 a strong opinion and I'm fine both ways. I don't feel the change is that
 grave.

 ''Negatives:'' I do feel like the `ticket20918` code is more messy than
 before. That's mainly because some getters forced us to split code into
 multiple steps, and also some function names are lengthy so code had to
 wrap to fit into 80 columns. It's not terribly messy, but I imagine that
 it might be less readable to someone not familiar with trunnel. Also, if
 opaqueness is on by default, it makes it slightly harder to write trunnel
 code correctly. Also also, if this is a new coding pattern, do we need to
 change all the other places that use trunnel to actually solely use
 getters instead of direct struct access?

 ''Positives'': All in all, I guess making structs opaque is a positive
 step wrt encapsulation, information-hiding yada yada, so I can see why it
 would a good idea in principle to do this change.

 Personally, I'm OK with merging this patch. I'm also fine with postponing
 this patch until we have a more complete plan on how to properly do info-
 hiding over our whole codebase (and not just trunnel).

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

Re: [tor-bugs] #20929 [Applications/Tor Browser]: Bump GCC version in our alpha builds

[Tor Bug Tracker & Wiki]

#20929: Bump GCC version in our alpha builds
---+---
 Reporter:  gk |  Owner:  tbb-team
 Type:  enhancement| Status:
   |  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-gitian, TorBrowserTeam201701R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by gk):

 * keywords:  tbb-gitian, TorBrowserTeam201701 => tbb-gitian,
 TorBrowserTeam201701R
 * status:  new => needs_review


Comment:

 `bug_20929` (https://gitweb.torproject.org/user/gk/tor-browser-
 bundle.git/commit/?h=bug_20929=edc35ff67352d66390c1cce94b4a2f114dd91a2e)
 in my tor-browser-bundle repo has a fix for 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] #21140 [Internal Services/Tor Sysadmin Team]: Document the distinction between sys admin and service admin

[Tor Bug Tracker & Wiki]

#21140: Document the distinction between sys admin and service admin
-+--
 Reporter:  arma |  Owner:  hiro
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by weasel):

 Also, sounds good.  Can you commit a first version?

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

[tor-bugs] #21204 [Core Tor/Tor]: Mac Sierra Password Protected Directory

[Tor Bug Tracker & Wiki]

#21204: Mac Sierra Password Protected Directory
-+-
 Reporter:   |  Owner:
  Slaraty@…  |
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Core |Version:
  Tor/Tor|   Keywords:  Mac Sierra Password Protected
 Severity:  Major|  Directory
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Since Mac Sierra the browser keeps asking for the Password Protected
 Directory User Name and Password on a private mediawiki website.

  * Step 1 Authetication Required box enter User Name and Password
  * After 3 cancels i can click the login button
  * After 3 cancels i enter the website userid and password.
  * 1 cancel
  * Reload page Authetication Required box enter User Name and Password
  * Enter the website userid and password.

 This is not typical for all Password Protected Directory. I have this
 problem with one mediawiki website

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