Re: [tor-bugs] #22637 [Webpages/Website]: Find a more maintainable approach for the signing-keys page

[Tor Bug Tracker & Wiki]

#22637: Find a more maintainable approach for the signing-keys page
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  website
  |  redesign
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  website-content, website-bug  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by traumschule):

 * owner:  traumschule => (none)
 * status:  reopened => assigned
 * parent:  #3893 =>


Comment:

 This is currently not in my hands, happy to work on revisions. Unparenting
 to fix {{{'max_depth' exceeded (5) : #27698 - #27699 - #22637 - #3893 -
 #23266 - #21222 }}} for children.

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

Re: [tor-bugs] #22178 [Community/Mirrors]: Website redesign: Mirror list site

[Tor Bug Tracker & Wiki]

#22178: Website redesign: Mirror list site
---+---
 Reporter:  Samdney|  Owner:  (none)
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:  WebsiteV3
Component:  Community/Mirrors  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22150 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by traumschule):

 * owner:  traumschule => (none)


Comment:

 Hard to decide if this should live in the Website component instead, not
 working 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] #28144 [Applications/Tor Browser]: Update projects/tor-browser for Android

[Tor Bug Tracker & Wiki]

#28144: Update projects/tor-browser for Android
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 So, from a high-level point we'd like to get a properly built and named
 Tor Browser for Android by executing commands like `make alpha` or `make
 nightly`. That means after e.g. entering `make alpha` and after the build
 job is done the result should be a `tor-browser-android-arm-8.5a4.apk` in
 alpha/unsigned/8.5a4-buildN (yes, I think once we have the mobile build
 integrated it could be a good time to switch to our "regular versioning"
 scheme).

 From a less high-level viewpoint this requires (at least) a) adapting the
 `Makefile` to add the new targets and b) getting the extensions we need
 funneled into the .apk.

 For b) we usually have the bundling step (i.e. the tor-browser project).
 If that's not going to work (Is that the case? If so, why?) for Android
 (which would mean reopening the .apk we got in the firefox step and
 putting the extensions into place after building them if needed) we need
 to find a way doing that in the firefox build step and could do just the
 renaming in the tor-browser step.

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

Re: [tor-bugs] #28144 [Applications/Tor Browser]: Update projects/tor-browser for Android

[Tor Bug Tracker & Wiki]

#28144: Update projects/tor-browser for Android
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * cc: boklm (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] #27621 [Community/Tor Browser Manual]: port tb-manual to lektor

[Tor Bug Tracker & Wiki]

#27621: port tb-manual to lektor
--+--
 Reporter:  arthuredelstein   |  Owner:  (none)
 Type:  project   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Community/Tor Browser Manual  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by traumschule):

 * owner:  traumschule => (none)
 * status:  new => assigned


Comment:

 unassigning

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

Re: [tor-bugs] #27836 [Internal Services/Service - trac]: RSS feed https authentication

[Tor Bug Tracker & Wiki]

#27836: RSS feed https authentication
--+-
 Reporter:  atagar|  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 traumschule):

 * cc: hiro, ahf (added)


Comment:

 Hi atagar! The feed only works when logged in so a solution would be to
 make the script login first and send a cookie with the RSS request.
 Unfortunately this is necessary to prevent spam. AFAIK ahf is working on a
 similar script to scrape trac.

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

Re: [tor-bugs] #27443 [Applications/Tor Browser]: Update Firefox RBM config and build for Android

[Tor Bug Tracker & Wiki]

#27443: Update Firefox RBM config and build for Android
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 Changes (android-1105a)

  * Remove MOZILLA_OFFICIAL ac_add_options
  * Regenerated the gradle-dependencies-list to include test artifacts
 (around 150 additional entries)
  * Renamed file to how-to-create-gradle-dependencies-list.txt, wrapped
 lines
  * Updated how-to-create-gradle-dependencies-list.txt with new info
  * Remove ccache references

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

Re: [tor-bugs] #22179 [Community/Mirrors]: Website redesign/Support portal: Instructions - Setting up a mirror

[Tor Bug Tracker & Wiki]

#22179: Website redesign/Support portal: Instructions - Setting up a mirror
---+--
 Reporter:  Samdney|  Owner:  (none)
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Community/Mirrors  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22150 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by traumschule):

 * owner:  traumschule => (none)


Comment:

 Not working on this right now. html files can easily be converted with
 html2text:
 {{{pip install html2text}}}

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

Re: [tor-bugs] #28326 [Applications/Tor Browser]: Tor Browser for PPC64LE

[Tor Bug Tracker & Wiki]

#28326: Tor Browser for PPC64LE
--+--
 Reporter:  power9|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 https://bearssl.org/ctmul.html has some more 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] #28343 [Applications/Tor Browser]: tbb-mobile/Tor Browser for Android: Unable to highlight, select, copy plain text in tor browser

[Tor Bug Tracker & Wiki]

#28343: tbb-mobile/Tor Browser for Android: Unable to highlight, select, copy 
plain
text in tor browser
--+--
 Reporter:  mtristan  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * priority:  High => Medium
 * keywords:  long-press, cut, copy, paste => tbb-mobile
 * 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

Re: [tor-bugs] #28345 [Applications/Tor Browser]: Tor Browser hang on macOS when opening a new tab

[Tor Bug Tracker & Wiki]

#28345: Tor Browser hang on macOS when opening a new tab
--+--
 Reporter:  teor  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:   => tbb-crash


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

Re: [tor-bugs] #19683 [Webpages/Website]: Add flag to allow building website without tor docs

[Tor Bug Tracker & Wiki]

#19683: Add flag to allow building website without tor docs
--+---
 Reporter:  arthuredelstein   |  Owner:  arthuredelstein
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  website redesign
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  website-bug   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by traumschule):

 * status:  assigned => needs_information


Comment:

 Finally realized this makes no sense, reverting latest change.

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

Re: [tor-bugs] #28346 [Internal Services/Tor Sysadmin Team]: Please refresh 726824BE9D8D5CF009C5F039FF9D1C57779FB883

[Tor Bug Tracker & Wiki]

#28346: Please refresh 726824BE9D8D5CF009C5F039FF9D1C57779FB883
-+
 Reporter:  phoul|  Owner:  tpa
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


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

Re: [tor-bugs] #28346 [Internal Services/Tor Sysadmin Team]: Please refresh 726824BE9D8D5CF009C5F039FF9D1C57779FB883

[Tor Bug Tracker & Wiki]

#28346: Please refresh 726824BE9D8D5CF009C5F039FF9D1C57779FB883
-+-
 Reporter:  phoul|  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by phoul):

 * owner:  (none) => tpa
 * component:  - Select a component => Internal Services/Tor Sysadmin Team


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28346 [- Select a component]: Please refresh 726824BE9D8D5CF009C5F039FF9D1C57779FB883

[Tor Bug Tracker & Wiki]

#28346: Please refresh 726824BE9D8D5CF009C5F039FF9D1C57779FB883
--+
 Reporter:  phoul |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Mater key is unchanged, new subkeys were added a while ago.

 {{{
 pub   rsa4096/0xFF9D1C57779FB883 2014-03-01 [SC]
   Key fingerprint = 7268 24BE 9D8D 5CF0 09C5  F039 FF9D 1C57 779F B883
 uid   [ unknown] Colin Childs (offline long term identity
 key) 
 uid   [ unknown] Colin Childs (offline long term identity
 key) 
 uid   [ unknown] Colin Childs (offline long term identity
 key) 
 sub   rsa4096/0x4AE02367738E79FC 2017-02-24 [S] [expires: 2020-02-24]
   Key fingerprint = D70B D58F 2524 6AC3 F648  B273 4AE0 2367 738E 79FC
 sub   rsa4096/0x1BCB5B2A92E48366 2017-02-24 [E] [expires: 2020-02-24]
   Key fingerprint = 3F04 539A BC55 8628 AB71  E599 1BCB 5B2A 92E4 8366
 }}}

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

Re: [tor-bugs] #28341 [Webpages/Website]: Add press clips to website

[Tor Bug Tracker & Wiki]

#28341: Add press clips to website
--+--
 Reporter:  steph |  Owner:  hiro
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by traumschule):

 * status:  new => needs_review


Comment:

 Thanks! Added to existing pull request:
 https://github.com/torproject/webwml/pull/64

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

Re: [tor-bugs] #27443 [Applications/Tor Browser]: Update Firefox RBM config and build for Android

[Tor Bug Tracker & Wiki]

#27443: Update Firefox RBM config and build for Android
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 Replying to [comment:32 sysrqb]:

 > I'm excited for this!
 >
 > {{{
 > +ac_add_options --with-android-version=22
 > }}}
 > Do we need this? We've used the default value without a problem (the
 default is 9 for 32-bit CPU archs, and 21 for 64-bit).
 >> Under the current build configuration, it defaults to 9 in all cases.
 Is there someway to tell the build that its for 32 or 64 bit?
 >> From my testing, 22 is the highest version that works. This is the only
 way I'm aware of to configure the android 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] #28345 [Applications/Tor Browser]: Tor Browser hang on macOS when opening a new tab

[Tor Bug Tracker & Wiki]

#28345: Tor Browser hang on macOS when opening a new tab
--+--
 Reporter:  teor  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 My tor browser hung when I tried to open a new tab. So I force quit it.
 Then it crashed.

 A similar bug used to happen reasonably often with Tor Browser 7.5. But I
 don't know how to reproduce it.

 {{{
 Path:  /Applications/TorBrowser.app/Contents/MacOS/firefox
 ...
 Version:   8.0.2 (6018.2.4)
 ...
 Date/Time: 2018-11-06 15:01:57.535 +1000
 OS Version:Mac OS X 10.13.6 (17G65)
 Report Version:12
 Bridge OS Version: 3.0 (14Y664)
 ...
 System Integrity Protection: enabled

 Crashed Thread:0  Dispatch queue: com.apple.main-thread

 Exception Type:EXC_BAD_ACCESS (SIGSEGV)
 Exception Codes:   EXC_I386_GPFLT
 Exception Note:EXC_CORPSE_NOTIFY

 Termination Signal:Segmentation fault: 11
 Termination Reason:Namespace SIGNAL, Code 0xb
 Terminating Process:   exc handler [0]

 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
 0   libc++.1.dylib  0x7fff75c4592e
 std::__1::__shared_weak_count::__release_weak() + 4
 1   com.apple.FinderKit 0x7fff6578f0c6
 
TNodeObserverRegistry::UnregisterNodeObserver(std::__1::shared_ptr)
 + 266
 2   com.apple.FinderKit 0x7fff6578eef8
 TNodeObserver::StopObservingSourceNode(TFENode const&,
 NodeNotificationOptions) + 568
 3   com.apple.FinderKit 0x7fff657813f9
 TMDQueryAliasNode::~TMDQueryAliasNode() + 99
 4   com.apple.FinderKit 0x7fff657815f4
 TMDQueryAliasNode::~TMDQueryAliasNode() + 14
 5   com.apple.FinderKit 0x7fff657670c5 void
 CallOnMainThread(void () block_pointer&&) + 29
 6   com.apple.FinderKit 0x7fff657670a1
 TCustomNode::ReleaseCustomNodeCallback(OpaqueNodeRef*, void*) + 99
 7   com.apple.desktopservices   0x7fff642ebe0b TNode::~TNode()
 + 233
 8   com.apple.desktopservices   0x7fff642ebcca -[FITNode
 dealloc] + 25
 9   libobjc.A.dylib 0x7fff7709edb4
 objc_object::sidetable_release(bool) + 266
 10  com.apple.desktopservices   0x7fff642ebcaa -[FITNode
 releaseUnderMonitor] + 41
 11  com.apple.desktopservices   0x7fff642cf164
 NodeDisposeNodeRef + 234
 12  com.apple.FinderKit 0x7fff6576d74f
 TFENode::~TFENode() + 17
 13  com.apple.FinderKit 0x7fff65788967
 std::__1::__vector_base,
 std::__1::allocator > >::~__vector_base()
 + 47
 14  libsystem_c.dylib   0x7fff77d6aeed
 __cxa_finalize_ranges + 351
 15  libsystem_c.dylib   0x7fff77d6b1fe exit + 55
 16  firefox 0x00010790ed4b start + 59
 ...
 Thread 0 crashed with X86 Thread State (64-bit):
   rax: 0x000125b40310  rbx: 0x000125b40300  rcx:
 0x00012068  rdx: 0x0001
   rdi: 0xe5e5e5e5e5e5e5e5  rsi: 0x0008  rbp:
 0x7ffee82f1800  rsp: 0x7ffee82f1800
r8: 0x000adb39   r9: 0x00014bd1f058  r10:
 0x00012ef18d18  r11: 0x00012ef18d20
   r12: 0x7fffad370ee8  r13: 0x000165205700  r14:
 0x000125b402f0  r15: 0x
   rip: 0x7fff75c4592e  rfl: 0x00010282  cr2:
 0x7fff65924192

 Logical CPU: 0
 Error Code:  0x
 Trap Number: 13
 }}}

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

Re: [tor-bugs] #27443 [Applications/Tor Browser]: Update Firefox RBM config and build for Android

[Tor Bug Tracker & Wiki]

#27443: Update Firefox RBM config and build for Android
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 The MOZILLA_OFFICIAL export executes some tasks that handles dependencies
 in a different way. Basically the build just fails with missing artifacts,
 rather than trying to download them. Many of these artifacts are in
 different repositories than we were using on the first list of
 dependencies.

 Its tedious tracking each dependency through manually so I'm looking for
 an easier way to handle 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] #26698 [Core Tor/Tor]: Authorities should put a hash of the bandwidth file in their votes

[Tor Bug Tracker & Wiki]

#26698: Authorities should put a hash of the bandwidth file in their votes
+--
 Reporter:  teor|  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Low |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-crypto tor-dirauth  |  Actual Points:
Parent ID:  #27047  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by teor):

 Replying to [comment:3 juga]:
 > i wonder if we should add the hash to the bandwidth file name in `sbws`,
 similar to what is done with descriptors. Though then we would need to
 allow giving a directory or a file (to be compatible with older versions)
 in V3BandwidthsFile, and then adding (or resusing?) code to find the
 latest file parsing the date in it.

 We could add this feature if we want, but I think it would make the tor
 code much more complicated. If you want to add it, let's open a separate
 ticket.

 This ticket is about verifying the bandwidth file that was used in a vote.

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

Re: [tor-bugs] #22453 [Core Tor/Tor]: Relays should regularly do a larger bandwidth self-test

[Tor Bug Tracker & Wiki]

#22453: Relays should regularly do a larger bandwidth self-test
-+-
 Reporter:  arma |  Owner:  juga
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-triage-20180328, |  Actual Points:
  034-removed-20180328, tor-bwauth   |
Parent ID:  #25925   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:18 arma]:
 > I still think there's a strong argument for simplifying our design and
 code and ripping out the bandwidth self-tests. So long as there are
 bwauths of any sort running, they will produce load on the relays, which
 will have the same effect as the self-test. And if there aren't bwauths
 running, then either the existing client traffic is enough to make relays
 realize they are fast or it isn't, but the tiny amount of traffic from the
 self-test isn't going to help that much.

 I still think there's a strong argument for doing a larger bandwidth self-
 test.

 On the public network, torflow's partitions give some relays a
 ridiculously small amount of bandwidth. Until the relay picks up traffic
 from elsewhere, it is stuck in the small partition. I have literally had
 to use EntryNodes to run fake client traffic through relays to get them
 unstuck. Removing the small test is risky, because it makes the problem
 worse.

 On test networks, there may not be any bandwidth scanners. So the
 bandwidth self-test should be on in test networks (and it should be
 larger).

 I don't think sbws suffers from similar issues, so once all the torflow
 scanners are gone, we can disable the bandwidth self-test code. Until
 then, it should be on and larger.

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

Re: [tor-bugs] #27490 [Core Tor/Tor]: When ClientPreferIPv6ORPort is set to auto, and a relay is being chosen for a directory or orport connection, prefer IPv4 or IPv6 at random

[Tor Bug Tracker & Wiki]

#27490: When ClientPreferIPv6ORPort is set to auto, and a relay is being chosen 
for
a directory or orport connection, prefer IPv4 or IPv6 at random
--+
 Reporter:  neel  |  Owner:  neel
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6  |  Actual Points:
Parent ID:  #17835| Points:
 Reviewer:  teor  |Sponsor:
--+

Comment (by teor):

 I think we can merge this feature as an experimental option. Then we can
 improve it later.

 I will ask what other people think at the team meeting tomorrow.

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

Re: [tor-bugs] #28170 [Core Tor/Stem]: Test stem pull requests against all supported tor versions, and tor nightly builds

[Tor Bug Tracker & Wiki]

#28170: Test stem pull requests against all supported tor versions, and tor 
nightly
builds
---+
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ci travis  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by teor):

 Replying to [comment:3 atagar]:
 > > We want to make sure that changes to stem master don't break tor's CI.
 >
 > Gotcha. I should be made aware of regressions on my side by Stem's
 Jenkins runs. That tests against tor's tip (not against multiple tor
 versions) but I've found this tends to be sufficient for bugs on my end.
 >
 > https://jenkins.torproject.org/job/stem-tor-ci/
 >
 > > Then I'll copy the tor version matrix into stem's travis CI config,
 and update this ticket with the branch.
 >
 > Sorry, not sure I quite follow. Tor uses travis, but I don't for Stem.

 The stem repository contains a travis config, and it runs under the
 torproject's travis:
 https://travis-ci.org/torproject/stem

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

Re: [tor-bugs] #28140 [Core Tor/Tor]: Our circuit died due to an invalid selected path if switching to plugabble transports

[Tor Bug Tracker & Wiki]

#28140: Our circuit died due to an invalid selected path if switching to 
plugabble
transports
--+
 Reporter:  gk|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.7-rc
 Severity:  Normal| Resolution:
 Keywords:  tor-path, regression  |  Actual Points:
Parent ID:  #25885| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * keywords:   => tor-path, regression
 * version:   => Tor: 0.3.2.7-rc
 * parent:   => #25885


Comment:

 I think that our path selection changes in #25885 will fix this issue. If
 they don't, they will provide better diagnostics.

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

Re: [tor-bugs] #27197 [Core Tor/Tor]: rust protover accepts excess commas in version strings

[Tor Bug Tracker & Wiki]

#27197: rust protover accepts excess commas in version strings
-+-
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, security-low, 033-backport,|  Actual Points:
  034-backport   |
Parent ID:  #27194   | Points:
 Reviewer:  teor |Sponsor:
-+-

Comment (by teor):

 GitHub had major downtime on some systems, including CI jobs. When they
 started processing jobs again, they dropped some of them:

 > As we re-enabled processing of this data, we processed ~200,000 webhook
 payloads that had outlived an internal TTL and were dropped.

 https://blog.github.com/2018-10-30-oct21-post-incident-analysis/

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by teor):

 Replying to [comment:8 cyberpunks]:
 > Replying to [comment:7 teor]:
 > > This branch conflicts with some changes in master.
 >
 > It actually doesn't, the branch was already rebased a good while ago.

 I opened a pull request at:
 https://github.com/torproject/tor/pull/427

 GitHub says:
 {{{
 This branch has conflicts that must be resolved
 Use the web editor or the  to resolve conflicts.
 Conflicting files
 src/feature/dirparse/ns_parse.c
 }}}

 When I try to do the merge manually, there are conflicts:
 {{{
 $ git checkout -b parsevotesplit1-master tp/master
 Branch 'parsevotesplit1-master' set up to track remote branch 'master'
 from 'tp'.
 Switched to a new branch 'parsevotesplit1-master'
 $ git merge onionk/parsevotesplit1
 Auto-merging src/feature/dirparse/ns_parse.h
 Auto-merging src/feature/dirparse/ns_parse.c
 CONFLICT (content): Merge conflict in src/feature/dirparse/ns_parse.c
 Recorded preimage for 'src/feature/dirparse/ns_parse.c'
 Automatic merge failed; fix conflicts and then commit the result.
 Exit 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] #28137 [Metrics/Statistics]: Modify "Total consensus weights across bandwidth authorities" graph to only include relays that end up in the consensus

[Tor Bug Tracker & Wiki]

#28137: Modify "Total consensus weights across bandwidth authorities" graph to 
only
include relays that end up in the consensus
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by teor):

 I wanted the total for the relays in the consensus: I didn't realise we
 were getting something different.

 > Are there alternatives, like only including relays from votes that have
 the Running flag?

 If checking the Running flag in a vote is faster, we could do it as an
 initial fix.

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

[tor-bugs] #28344 [Core Tor/Tor]: Should we log \r\n on Windows?

[Tor Bug Tracker & Wiki]

#28344: Should we log \r\n on Windows?
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  036-roadmap-proposed, fast-fix
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Tor's logging code terminates strings with \n.

 When I run tor.exe via the command prompt on Windows, I don't see any of
 the log output, because there's no \r at the end of the line.

 Should we make tor log \r\n on Windows?

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

Re: [tor-bugs] #28097 [Core Tor/Tor]: Get the actual Windows version from Kernel32.dll

[Tor Bug Tracker & Wiki]

#28097: Get the actual Windows version from Kernel32.dll
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  windows   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:2 nickm]:
 > I think this is something we'll actually want: reporting the OS version
 is pretty important for successful debugging.

 When I was testing #28096, our Appveyor CI reported the correct Windows
 server versions. This behaviour is surprising, and does not match
 Microsoft's API documentation.

 However, when I tested Tor 0.3.4.8 on my Windows 10 desktop, it said it
 was running on Windows 8.

 So it looks like we'll need to implement this ticket for Windows Client
 8.1 and later.

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

[tor-bugs] #28343 [Applications/Tor Browser]: tbb-mobile/Tor Browser for Android: Unable to highlight, select, copy plain text in tor browser

[Tor Bug Tracker & Wiki]

#28343: tbb-mobile/Tor Browser for Android: Unable to highlight, select, copy 
plain
text in tor browser
-+-
 Reporter:  mtristan |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  High |  Component:  Applications/Tor
 |  Browser
  Version:   |   Severity:  Major
 Keywords:  long-press, cut, copy,   |  Actual Points:
  paste  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
 I am having this issue on both phones ive installed it on, and both Tor
 Browser releases.
 (60.3.0 from F-Droid).
 The browser does not allow me to select plain text, or long press to bring
 up the cut/copy/paste dialogue.
 -- It does allow me to long-press links in the page, and the URL bar.
 -- I am unable to long press text windows to paste. Additionally, I am
 unable to long-press search boxes to add them as a search engine.
 -- I am able to perform these functions in OrFox.


 Thank you for your time, consideration, and any suggestions.

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

Re: [tor-bugs] #27443 [Applications/Tor Browser]: Update Firefox RBM config and build for Android

[Tor Bug Tracker & Wiki]

#27443: Update Firefox RBM config and build for Android
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 I'm excited for this!

 In `projects/firefox/mozconfig-android-armv7`
 {{{
 +mk_add_options MOZILLA_OFFICIAL=1
 }}}
 We don't need this automake directive anymore (the export replaces it)

 {{{
 +ac_add_options --with-android-version=22
 }}}
 Do we need this? We've used the default value without a problem (the
 default is 9 for 32-bit CPU archs, and 21 for 64-bit).
 {{{
 +ac_add_options --with-ccache
 }}}
 I agree with gk in comment:28 - ccache won't help us here

 In `projects/firefox/config`
 {{{
 +  android-armv7:
 +var:
 +  arch_deps:
 +- openjdk-8-jdk
 +- ccache
 }}}
 nit: ccache here, too

 `projects/firefox/how-to-create-dependencies-list.txt`
 nit: can the lines be wrapped at some length? (72, 79, 80, 100?)

 In `projects/firefox/fetch-gradle-dependencies`
 {{{
 +echo "[% artifact.sha256sum %]  downloaded_file" | sha256sum -c
 }}}
 Does the script fail when this line returns non-zero?  There's no error
 handling, so I'm guessing this is caught another way?

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

Re: [tor-bugs] #28081 [Core Tor/Tor]: rust protover discards all votes if one is not UTF-8

[Tor Bug Tracker & Wiki]

#28081: rust protover discards all votes if one is not UTF-8
-+-
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, protover, 033-backport,|  Actual Points:
  034-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  new => needs_revision


Comment:

 #27741 has been merged.
 Which branch do you want us to review?
 Does it need to be rebased?

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

Re: [tor-bugs] #26973 [Core Tor/Tor]: Privcount blinding and encryption: add rustfmt CI check

[Tor Bug Tracker & Wiki]

#26973: Privcount blinding and encryption: add rustfmt CI check
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  privcount, 035-roadmap-master, 035   |  Actual Points:
  -triaged-in-20180711, rust |
Parent ID:  #25669   | Points:
 Reviewer:  nickm|Sponsor:
 |  SponsorV
-+-

Comment (by teor):

 Hi nickm, now would be a good time to re-run rustfmt, and merge this
 ticket.

 No-one is working on PrivCount right 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] #28328 [Metrics/Website]: inlcude "total consensus" in vote totals graph

[Tor Bug Tracker & Wiki]

#28328: inlcude "total consensus" in vote totals graph
-+--
 Reporter:  starlight|  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by starlight):

 The relevant consensus information is certainly present in OnionOO.
 Constructing the scripts and spread-sheet was my avenue to noticing the
 behavior and thinking of the enhancement.

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

Re: [tor-bugs] #23922 [Community/Tor Browser Manual]: The Uninstalling page does not mention the TorBrowser-Data directory on OSX

[Tor Bug Tracker & Wiki]

#23922: The Uninstalling page does not mention the TorBrowser-Data directory on 
OSX
--+-
 Reporter:  boklm |  Owner:  phoul
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:
Component:  Community/Tor Browser Manual  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #24231| Points:
 Reviewer:|Sponsor:
--+-
Changes (by teor):

 * status:  needs_review => merge_ready


Comment:

 Looks fine to me.

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

Re: [tor-bugs] #28326 [Applications/Tor Browser]: Tor Browser for PPC64LE

[Tor Bug Tracker & Wiki]

#28326: Tor Browser for PPC64LE
--+--
 Reporter:  power9|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 Replying to [comment:3 gk]:
 > Replying to [comment:2 teor]:
 > > Tor doesn't support PPC, because its MUL instruction is not constant-
 time.
 > > It's really hard to write secure crypto without a constant-time MUL.
 > >
 
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/SupportedPlatforms
 >
 > Good to know. FWIW: there are Debian packages for that platform, though.

 That's fine: Tor is open-source, so Debian can maintain a PPC build of Tor
 if they want.

 We just won't put any effort into Tor on PPC, because:

 >  If (nearly?) all users on a platform are insecure, it's also good
 candidate for Rejected.

 > PPC (The MUL instruction isn't constant-time, thus many common
 cryptographic operations on these systems are subject to even the most
 trivial side-channel attacks.)

 Replying to [comment:4 power9]:
 > That's mean we never see Tor Browser on PPC?

 The Tor Browser team can maintain a PPC build of Tor if they want. But PPC
 has trivial cryptographic side-channel attacks. So a PPC Tor Browser might
 not meet Tor Browser's security standards.

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

Re: [tor-bugs] #28328 [Metrics/Website]: inlcude "total consensus" in vote totals graph

[Tor Bug Tracker & Wiki]

#28328: inlcude "total consensus" in vote totals graph
-+--
 Reporter:  starlight|  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by starlight):

 * Attachment "bw_stat_dbw_201807-11_graph.xlsx" 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] #28328 [Metrics/Website]: inlcude "total consensus" in vote totals graph

[Tor Bug Tracker & Wiki]

#28328: inlcude "total consensus" in vote totals graph
-+--
 Reporter:  starlight|  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by starlight):

 Wrote a few scripts that collect consensus data and data from my relay to
 comprehend Torflow.  Flows into attached spreadsheet.  Possibly works only
 with Excel. . .OO chokes and dies; have not attempted Google Docs.

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

Re: [tor-bugs] #28255 [Core Tor/Tor]: verify guard selection consensus expiry constraints

[Tor Bug Tracker & Wiki]

#28255: verify guard selection consensus expiry constraints
-+-
 Reporter:  catalyst |  Owner:  teor
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bootstrap, clock-skew, tor-guard,|  Actual Points:
  usability, ux, s8-errors, 035-roadmap- |
  subtask, 035-triaged-in-20180711,  |
  s8-bootstrap   |
Parent ID:  #23605   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by teor):

 * owner:  catalyst => teor


Comment:

 I guess this ticket is also mine.

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

Re: [tor-bugs] #26632 [Core Tor/Tor]: Updated version of the WTF-pad proposal

[Tor Bug Tracker & Wiki]

#26632: Updated version of the WTF-pad proposal
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  project  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  035-roadmap-master, 035-triaged- |  Actual Points:
  in-20180711|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor2
-+-
Changes (by asn):

 * status:  new => merge_ready


Comment:

 Latest proposal https://github.com/torproject/torspec/pull/41 LGTM!

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

Re: [tor-bugs] #28144 [Applications/Tor Browser]: Update projects/tor-browser for Android

[Tor Bug Tracker & Wiki]

#28144: Update projects/tor-browser for Android
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 That looks pretty good. I'm not familiar with abicheck.cc, and it looks
 like the patch is missing https-everywhere. I don't immediately see
 anything else that's different from what I'm doing. For reference, the
 script I use is here:
 https://github.com/sysrqb/build_tba_alpha/blob/master/build_tba_alpha

 One difference is that I was downloading https-everywhere from the EFF
 website (for simplicity), instead of building it locally. Of course, with
 tor-browser-build we should use the locally built xpi.

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

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

[Tor Bug Tracker & Wiki]

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

 * sponsor:  Sponsor8 => Sponsor8-can


Comment:

 Replying to [comment:19 arma]:
 > I believe it just produces scary-sounding warnings: the bootstrap
 complaint logs are entirely separate from Tor's decision to try to launch
 circuits and fetch things and etc.
 Thanks. I'll put it in sponsor8-can, then. I think it's also lower
 priority than bootstrap reporting issues that cause client-facing UX
 problems.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by arma):

 I believe it just produces scary-sounding warnings: the bootstrap
 complaint logs are entirely separate from Tor's decision to try to launch
 circuits and fetch things and etc.

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

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

[Tor Bug Tracker & Wiki]

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

 * sponsor:  Sponsor8 => Sponsor8-can


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

Re: [tor-bugs] #27308 [Core Tor/Tor]: add completion milestones to bootstrap

[Tor Bug Tracker & Wiki]

#27308: add completion milestones to bootstrap
-+-
 Reporter:  catalyst |  Owner:
 |  catalyst
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  usability, ux, ux-team, bootstrap,   |  Actual Points:
  035-roadmap-subtask, 035-triaged-in-20180711,  |
  s8-bootstrap   |
Parent ID:  #28018   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-
Changes (by catalyst):

 * sponsor:  Sponsor8 => Sponsor8-can


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

Re: [tor-bugs] #27443 [Applications/Tor Browser]: Update Firefox RBM config and build for Android

[Tor Bug Tracker & Wiki]

#27443: Update Firefox RBM config and build for Android
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 I looks like the export MOZILLA_OFFICIAL does change behavior of the
 build. It triggers the unit tests on the build. I'll add the test
 libraries to the gradle-dependencies and then get that checked in. I'll
 also add a comment in mozconfig explaining the reasons for the export.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by catalyst):

 We should double check whether this merely makes scary-sounding warnings,
 or if it actually prevents a relay from completing bootstrapping.

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

Re: [tor-bugs] #26035 [Metrics/Statistics]: Streamline sample quantile types used in the various modules

[Tor Bug Tracker & Wiki]

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

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


Comment:

 Replying to [comment:26 karsten]:
 > Replying to [comment:25 karsten]:
 > > Replying to [comment:24 irl]:
 > > > [...] but, we should create a new ticket for generalising the
 computePercentiles function with generics.
 > >
 > > I'll create a slightly different ticket before closing this one: we
 should share more code between modules, and a generic
 `computePercentiles()` would be one piece of code to consider here. I
 wouldn't want to merge a patch that starts with this part of the code. I'd
 want us to approach this from a top-down perspective where we generalize
 similar functionality and use it in all modules to reduce the overall
 amount of code and likelihood of bugs.
 >
 > Still not closing until I get around to doing this.

 Alright, #28342 now exists with many more ideas on this topic. Closing.
 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

[tor-bugs] #28342 [Metrics/Statistics]: Share more code between modules

[Tor Bug Tracker & Wiki]

#28342: Share more code between modules
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+--
 We currently have nine data-processing modules in metrics-web. Each of
 them reads descriptors from a local directory, aggregates them somehow,
 and writes one or more CSV files to a local directory. Some modules use a
 database for the aggregation part, others use state files.

 Some of these modules have a lot of code in common. Yet they do not share
 actual code other than what's in metrics-lib for reading and parsing
 descriptors. This is bad for obvious reasons.

 I'd like to approach this refactoring from a top-down perspective where we
 generalize similar functionality and use it in all modules. The following
 list is ordered by topic, not by priority:

  - Configuration: Most of the modules can be configured in some way,
 including database connection details or file system paths. It would be
 easier to configure things once for all modules by using a single config
 file, or to have reasonable defaults and modify single options via
 command-line arguments.

  - Scheduling: Right now, modules are running once per day, called by
 cron. We would like to run them more often, but we need to avoid
 overlapping runs. And we need to handle shutdowns gracefully. A common
 scheduler might help with this.

  - Descriptor reading and parsing: Each module has its own code for
 reading and parsing descriptors using metrics-lib. This includes setting
 paths where descriptors are located and paths for parse history files.

  - Statistics: We have similar code for computing percentiles and other
 statistics distributed over the code base. We might be able to generalize
 these computations and provide a common math/statistics interface for
 them. We should still use a math library, so this would be mostly a
 wrapper for that library.

  - Database access: Several of our modules have the same or very similar
 code to: connect to a database, import parsed descriptor parts into
 tables, executing stored procedures for importing data, executing stored
 procedures for aggregating data, querying one or more results view, and
 disconnecting from the database. What we need is a more powerful API to
 our databases than `java.sql`.

  - Output: Our modules write one or more CSV files as their output. Some
 modules treat missing values differently in the output, but this code is
 mostly the same in all modules. Maybe this is still part of the database
 access item above. If not, we should share some code across modules for
 writing output files.

 This is not high priority, and it requires discussion prior to making any
 code changes. This ticket is supposed to get us started here. (And I said
 I wouldn't close #26035 before this ticket exists.)

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

Re: [tor-bugs] #28341 [Webpages/Website]: Add press clips to website

[Tor Bug Tracker & Wiki]

#28341: Add press clips to website
--+--
 Reporter:  steph |  Owner:  hiro
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by steph):

 * Attachment "Press clips for website - 2018 .csv" 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] #27443 [Applications/Tor Browser]: Update Firefox RBM config and build for Android

[Tor Bug Tracker & Wiki]

#27443: Update Firefox RBM config and build for Android
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 I verified build was working this morning but within the last hour it stop
 building with errors:

  * Could not find junit:junit:4.12
  * Could not find !org.robolectric:robolectric:3.5.1
  * org.mockito:mockito-core:1.10.19

 These are easy to add but the question is why did these test dependencies
 show up? I'll look into the cause of the changes...

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

[tor-bugs] #28341 [Webpages/Website]: Add press clips to website

[Tor Bug Tracker & Wiki]

#28341: Add press clips to website
--+--
 Reporter:  steph |  Owner:  hiro
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 ​https://www.torproject.org/press/press.html.en

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

Re: [tor-bugs] #28320 [Metrics/CollecTor]: Rewrite CollecTor relaydescs module using Stem/txtorcon

[Tor Bug Tracker & Wiki]

#28320: Rewrite CollecTor relaydescs module using Stem/txtorcon
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor13
---+--

Comment (by atagar):

 Gotcha! When you guys know what you want just let me know. I'd be happy to
 whip up a prototype if you'd like since the asks here thus far sound
 pretty simple.

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

Re: [tor-bugs] #21378 [Metrics/CollecTor]: Archive bwauth bandwidth files

[Tor Bug Tracker & Wiki]

#21378: Archive bwauth bandwidth files
+--
 Reporter:  tom |  Owner:  metrics-team
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Metrics/CollecTor   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-bwauth tor-dirauth  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by karsten):

 Replying just to the parts where I wouldn't reply "okay, cool!":

 Replying to [comment:15 teor]:
 > Replying to [comment:14 karsten]:
 > > In the future, we can switch to fetching only those files that are
 referenced from votes, unless for some reason we want to have non-
 referenced files, too.
 >
 > How are bandwidth files referenced from votes?
 >
 > I don't think we will implement "bandwidth-file-url" from
 https://trac.torproject.org/projects/tor/ticket/21378?replyto=14#comment:6
 >
 > Tor 0.3.5? and later add bandwidth file headers to each vote, and we may
 add a bandwidth file hash in future. Once all authorities upgrade, you can
 fetch the bandwidth file if the vote contains headers.

 I guess I was thinking of 0.3.5 then. I'm not aware of any other plans.

 > >   - The relaydescs module runs twice per hour, so it's going to
 download the file twice every hour. Again, if we only fetch referenced
 files, we wouldn't download the same file more than once.
 >
 > I am not sure if we plan on implementing "referenced files" in Tor. Can
 you explain what you mean?

 Same as above: bandwidth files referenced from votes.

 > >   - I assume there are no plans that authorities serve bandwidth files
 of other authorities? That's different for votes which are cached by other
 authorities. Should be fine, but something to consider for the future.
 >
 > Votes are posted, fetched, and cached by authorities so that each
 authority can create a consensus.
 > There's no equivalent for bandwidth files, so we probably won't
 implement bandwidth file caching.
 > But if you tell us you really need it, we could work something out.

 Sounds reasonable. I don't think we'll need it.

 > > > 2) Teach
 
[https://gitweb.torproject.org/collector.git/tree/src/main/java/org/torproject/collector/relaydescs/RelayDescriptorParser.java
 RelayDescriptorParser] to recognise the file
 > >
 > >  - While we're waiting for #21377, can we have a sample file to start
 writing some parsing code?
 >
 > moria1's votes have a bandwidth-file-headers line, but it's based on
 torflow's bandwidth file, so it only has a timestamp:
 > http://128.31.0.34:9131/tor/status-vote/current/authority
 >
 > The bandwidth file spec contains sample data:
 > https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-
 spec.txt#n450
 >
 > We're working on version 1.2.0 of the format for sbws 1.0 in #28085.
 When sbws 1.0 is ready, we will update the spec with sample data from the
 latest sbws.

 Thanks! I didn't look just yet, but this should be a good start to write
 some 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] #28320 [Metrics/CollecTor]: Rewrite CollecTor relaydescs module using Stem/txtorcon

[Tor Bug Tracker & Wiki]

#28320: Rewrite CollecTor relaydescs module using Stem/txtorcon
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor13
---+--

Comment (by karsten):

 It's true that Stem/txtorcon might not be of primary interest for this
 prototype. But if we later want to build upon this prototype to rewrite
 the rest of CollecTor's relaydescs module, Stem's descriptor parsing and
 validation capabilities will be quite useful. I'll leave it up to irl to
 decide whether he wants to use Stem or txtorcon. This discussion will also
 be more useful as soon as the requirements are written down. Stay tuned!

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

Re: [tor-bugs] #27609 [Applications/Tor Browser]: TBA: Evaluate Tor Onion Proxy Library

[Tor Bug Tracker & Wiki]

#27609: TBA: Evaluate Tor Onion Proxy Library
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a2,  |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 We should cleanup the OnionProxyManager  class. It loops/sleeps as it
 probes the port for bootstrap messages.  This can be error prone and also
 slows down the bootstrap process  significantly.

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

Re: [tor-bugs] #28328 [Metrics/Website]: inlcude "total consensus" in vote totals graph

[Tor Bug Tracker & Wiki]

#28328: inlcude "total consensus" in vote totals graph
-+--
 Reporter:  starlight|  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Where do you have those numbers from? The current graph does not consider
 any relay flags at all and simply plots the total consensus weight of all
 relays in a vote. Do you have graphs or raw data on those events in July?

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

Re: [tor-bugs] #27609 [Applications/Tor Browser]: TBA: Evaluate Tor Onion Proxy Library

[Tor Bug Tracker & Wiki]

#27609: TBA: Evaluate Tor Onion Proxy Library
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a2,  |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * cc: sysrqb (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] #28144 [Applications/Tor Browser]: Update projects/tor-browser for Android

[Tor Bug Tracker & Wiki]

#28144: Update projects/tor-browser for Android
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * Attachment "0001-hacked-up-extension-bundling.patch" added.


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

Re: [tor-bugs] #28144 [Applications/Tor Browser]: Update projects/tor-browser for Android

[Tor Bug Tracker & Wiki]

#28144: Update projects/tor-browser for Android
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * cc: sysrqb (added)
 * status:  new => needs_information


Comment:

 Turns out I did all the things needed in the firefox part before packaging
 things up. See my attached patch I used a while back.

 sysrqb: does that somewhat match what you do?

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

Re: [tor-bugs] #27609 [Applications/Tor Browser]: TBA: Evaluate Tor Onion Proxy Library

[Tor Bug Tracker & Wiki]

#27609: TBA: Evaluate Tor Onion Proxy Library
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a2,  |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 The Android part of this project is dependent on https://github.com/n8fr8
 /tor-android for the tor binaries. Will this be the official source of tor
 binaries or should we add android support to projects/tor?

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

Re: [tor-bugs] #27443 [Applications/Tor Browser]: Update Firefox RBM config and build for Android

[Tor Bug Tracker & Wiki]

#27443: Update Firefox RBM config and build for Android
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 I think a filename like `how-to-create-gradle-dependencies-list.txt` would
 be more clear (as this is only about the gradle dependencies). Wrapping
 lines to ~80 characters would make it easier to read.

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

Re: [tor-bugs] #27443 [Applications/Tor Browser]: Update Firefox RBM config and build for Android

[Tor Bug Tracker & Wiki]

#27443: Update Firefox RBM config and build for Android
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  needs_review => needs_revision


Comment:

 I think we can disable the `ccache` related things. We are building within
 containers from scratch and `ccache` should not help much in that
 scenario. However, it might do so in local builds which is why it is
 there. Sorry, for not being more explicit 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] #28340 [Applications/GetTor]: Package gettor for Debian

[Tor Bug Tracker & Wiki]

#28340: Package gettor for Debian
-+
 Reporter:  hiro |  Owner:  ilv
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #28152
   Points:   |   Reviewer:
  Sponsor:   |
-+
 Package gettor and dependencies for Debian so that it is easier to deploy
 and maintain.

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

Re: [tor-bugs] #28152 [Applications/GetTor]: Gettor code refactor with Python Twisted

[Tor Bug Tracker & Wiki]

#28152: Gettor code refactor with Python Twisted
-+-
 Reporter:  ilv  |  Owner:  ilv
 Type:  enhancement  | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #28232   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by hiro):

 Hi I have been looking at the code of gettor and bridge db. I am thinking
 many of the functionalities implemented in twistd in bridgedb could be
 easily ported.

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

Re: [tor-bugs] #25013 [Applications/Tor Browser]: Move TorButton code to the tor browser repository

[Tor Bug Tracker & Wiki]

#25013: Move TorButton code to the tor browser repository
--+
 Reporter:  igt0  |  Owner:  tbb-team
 Type:  defect| Status:
  |  needs_revision
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201811  |  Actual Points:
Parent ID:  #10760| Points:
 Reviewer:  gk, sysrqb, mcs,  |Sponsor:
--+
Changes (by gk):

 * keywords:  tbb-mobile, TorBrowserTeam201811R => tbb-mobile,
 TorBrowserTeam201811
 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:49 igt0]:
 > Updated code: https://github.com/igortoliveira/torbutton/tree/25013-v1
 >
 > I moved the jar.mn to the src/ folder and renamed the en/ locale to en-
 US.

 I don't think just renaming the folder is going to fly with our
 translations workflow. See e.g. the `import-translations.sh` script with
 the `en` pieces. Which is why I was thinking about some symlink until
 #28261 is figured out. Not sure whether that is working, though.

 What about the bug component I mentioned in comment:43?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28339 [Applications/GetTor]: Log handling in gettor

[Tor Bug Tracker & Wiki]

#28339: Log handling in gettor
-+
 Reporter:  hiro |  Owner:  ilv
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #28152
   Points:   |   Reviewer:
  Sponsor:   |
-+
 Log generation should be refactored in gettor in order to be able to debug
 errors and generate statistics.

 The following tasks should be implemented:
 - Use log levels: not everything should be logged all the times.
 - Use the log to generate simple statistics about service usage.
 - Use logrotation to store logs in a format that can be exported and
 parsed easily by another 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] #27321 [Core Tor/Nyx]: incorrect bw calculation during initial startup

[Tor Bug Tracker & Wiki]

#27321: incorrect bw calculation during initial startup
--+---
 Reporter:  a_p   |  Owner:  atagar
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by atagar):

 > I disabled logging on my system, because I want my system to be more
 amnesiac about its past. I don't think that Nyx should rely on existence
 of old log files with BW events.

 It doesn't (though it used to use those prior to 2.x). If all those
 datapoints are from before Nyx started then they came from the output of a
 'GETINFO bw-event-cache' command to tor.

 You might not keep logs but the tor process itself still knows its last
 several datapoints.

 Again, Nyx is just displaying data it gets from Tor. If that data's being
 faithfully reflected then this isn't a Nyx bug. If you feel that tor data
 is incorrect for some reason we can move this ticket over to the network
 team for further questions.

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

Re: [tor-bugs] #26698 [Core Tor/Tor]: Authorities should put a hash of the bandwidth file in their votes

[Tor Bug Tracker & Wiki]

#26698: Authorities should put a hash of the bandwidth file in their votes
+--
 Reporter:  teor|  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Low |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-crypto tor-dirauth  |  Actual Points:
Parent ID:  #27047  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by juga):

 i wonder if we should add the hash to the bandwidth file name in `sbws`,
 similar to what is done with descriptors. Though then we would need to
 allow giving a directory or a file (to be compatible with older versions)
 in V3BandwidthsFile, and then adding (or resusing?) code to find the
 latest file parsing the date in 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] #27321 [Core Tor/Nyx]: incorrect bw calculation during initial startup

[Tor Bug Tracker & Wiki]

#27321: incorrect bw calculation during initial startup
--+---
 Reporter:  a_p   |  Owner:  atagar
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by wagon):

 > Please log BW events
 I disabled logging on my system, because I want my system to be more
 amnesiac about its past. I don't think that Nyx should rely on existence
 of old log files with BW events.
 > This looks tor simply isn't reporting any traffic
 Don't you think that Nyx should recognize its start up as a special case,
 and start counting only from the first non-zero value(s)? "3 MB/s" jump
 during inactivity period looks as absurd 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] #28332 [Core Tor/Nyx]: Nyx configurashion editor reproducibly crashes if custom ordering is set

[Tor Bug Tracker & Wiki]

#28332: Nyx configurashion editor reproducibly crashes if custom ordering is set
--+--
 Reporter:  wagon |  Owner:  atagar
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:  duplicate
 Keywords:  config|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by atagar):

 > So, I can install on my system any trojan, run it, and later verify that
 this trojan was OK? No, it doesn't work this way.

 Ummm... no. It doesn't.

 ```
 moirai:~% cd /tmp

 moirai:/tmp% git clone https://git.torproject.org/nyx.git
 Cloning into 'nyx'...
 remote: Counting objects: 13147, done.
 remote: Compressing objects: 100% (36/36), done.
 remote: Total 13147 (delta 17), reused 0 (delta 0)
 Receiving objects: 100% (13147/13147), 10.73 MiB | 2.10 MiB/s, done.
 Resolving deltas: 100% (10090/10090), done.
 Checking connectivity... done.

 moirai:/tmp% cd nyx

 moirai:/tmp/nyx% git rev-parse HEAD
 d3dd23cec8cab7eea4969d0c462a2e1abfa5b19d

 [ ok, the cryptographic signature is correct ]

 moirai:/tmp/nyx% ./run_nyx --help
 ```

 There's no need to install, and if you have the HEAD signature that can be
 used for verification just the same as a gpg signed tarball. It provides
 the same thing. The only thing you *can't* safely trust is this message
 from me that's providing you with the above signature. If a meanie snagged
 my trac password, exploited the Tor git repository (to circumvent the
 https), and MITM your connection you're completely right - someone could
 do something nasty.

 But this is both requires the exploitation of multiple core Tor systems
 (in which case honestly your system is the least of our worries) and it
 wouldn't exploit root since nyx **does not need to be installed** to /usr.

 Anywho, if you're still worried I can pgp sign this message later. I'm at
 work at the moment so I don't have my keys handy but if you're really that
 worried let me know.

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

Re: [tor-bugs] #28332 [Core Tor/Nyx]: Nyx configurashion editor reproducibly crashes if custom ordering is set

[Tor Bug Tracker & Wiki]

#28332: Nyx configurashion editor reproducibly crashes if custom ordering is set
--+--
 Reporter:  wagon |  Owner:  atagar
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:  duplicate
 Keywords:  config|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by wagon):

 > simply run `git clone ​https://git.torproject.org/nyx.git`
 So, I can install on my system any trojan, run it, and later verify that
 this trojan was OK? No, it doesn't work this way. Once you installed it in
 `/usr`, and once it touched some important files, your system cannot be
 trusted again.

 Well, I can clone it to in some virtual machine and (suppose) verify it by
 the last commit. Then, what's the next? I need to move this trusted tree
 to my main system, where old `nyx` was installed using `pip3`. As I
 understand, git nyx version is not a python package, so it is not that
 simple. Either I have to learn how to install it to some local directory
 in parallel to main installation, or figure out how to replace all files
 of existing installation manually.

 And all of that just because you cannot give a link to current version
 with singed tarball. I spent few days to commit my tickets, I'm not payed
 for it, and I am not eager to learn `git` and `pip3` internals now only to
 commit a couple of more tickets. I'm 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] #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:
 |  angelo620
 Type:  enhancement  | Status:  new
 Priority:  Very High|  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:
 Keywords:  performance, scaling, tor-client,|  Actual Points:
  SponsorU-deferred, sponsor4, sponsor8-maybe,   |
  034-triage-20180328, 035-removed-20180711  |
Parent ID:  #28335   | Points:  large
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-
Changes (by dgoulet):

 * parent:  #25500 => #28335


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

Re: [tor-bugs] #28337 [Core Tor/Tor]: Implement a way to enable/disable the network participant role (was: Enable or disable mechanism for the network participant role)

[Tor Bug Tracker & Wiki]

#28337: Implement a way to enable/disable the network participant role
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  mainloop  |  Actual Points:
Parent ID:  #28335| Points:
 Reviewer:|Sponsor:  Sponsor8
--+
Description changed by dgoulet:

Old description:

> (From #28335)
>
> Make it so "that active network participant" will turn off after either a
> long time without client usage, or when the controller tells it to.
>
> This new role will come from #28336.

New description:

 (From #28335)

 Make it so "that active network participant" will turn off after either a
 long time without client usage, or when the controller tells it to.

 We want this to be remembered also across restarts.

 This new role will come from #28336.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28338 [Core Tor/Tor]: Audit ROLE_ALL callbacks to either have a way to turn them off or relax them

[Tor Bug Tracker & Wiki]

#28338: Audit ROLE_ALL callbacks to either have a way to turn them off or relax
them
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  mainloop
Actual Points:|  Parent ID:  #28335
   Points:|   Reviewer:
  Sponsor:  Sponsor8  |
--+
 (from #28335)

 We should make sure that every periodic event that remains in ROLE_ALL has
 a way to turn it off, a very generous and forgiving timeout, or both.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28337 [Core Tor/Tor]: Enable or disable mechanism for the network participant role

[Tor Bug Tracker & Wiki]

#28337: Enable or disable mechanism for the network participant role
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  mainloop
Actual Points:|  Parent ID:  #28335
   Points:|   Reviewer:
  Sponsor:  Sponsor8  |
--+
 (From #28335)

 Make it so "that active network participant" will turn off after either a
 long time without client usage, or when the controller tells it to.

 This new role will come from #28336.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28336 [Core Tor/Tor]: Split ROLE_ALL into new roles and make it always on role

[Tor Bug Tracker & Wiki]

#28336: Split ROLE_ALL into new roles and make it always on role
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  mainloop
Actual Points:|  Parent ID:  #28335
   Points:|   Reviewer:
  Sponsor:  Sponsor8  |
--+
 (From #28335)

 We should change these events as follows: we should make "ROLE_ALL" a real
 always-on role, and make sure we're always in it. Then we should move
 (nearly?) all the events out of ROLE_ALL into new roles, including a role
 that means "active network participant" -- that is, actively building and
 using circuits on the Tor network.

 The end goal is to end up with a cleaner separation and a role that means
 "network participant".

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

Re: [tor-bugs] #28187 [Applications/Tor Browser]: Change Tor Circuit display icon to an onion

[Tor Bug Tracker & Wiki]

#28187: Change Tor Circuit display icon to an onion
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, ux-team,  |  Actual Points:
  TorBrowserTeam201811R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by antonela):

 Arthur! looks awesome!

 The main aim with this iteration is to make clear that the circuit is made
 inside the Tor network. For non-tech-savvy users, it will help on
 recognize the relationship with the network.

 Should we also update the icon at the hamburger menu?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28335 [Core Tor/Tor]: Make most periodic events turn themselves off when Tor is dormant, sleeping, etc.

[Tor Bug Tracker & Wiki]

#28335: Make most periodic events turn themselves off when Tor is dormant,
sleeping, etc.
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #25500
   Points:  10|   Reviewer:
  Sponsor:|
--+
 See #2149 and https://lists.torproject.org/pipermail/tor-
 dev/2018-November/013529.html for some background here.

 Right now we have a bunch of periodic events -- those in ROLE_ALL and
 those in second_elapsed_callback() -- that are scheduled all the time.
 Some of them are run even when DisableNetwork is set.

 We should change these events as follows: we should make "ROLE_ALL" a real
 always-on role, and make sure we're always in it.  Then we should move
 (nearly?) all the events out of ROLE_ALL into new roles, including a role
 that means "active network participant" -- that is, actively building and
 using circuits on the Tor network.

 We should make it so "that active network participant" will turn off after
 either a long time without client usage, or when the controller tells it
 to.

 We should make sure that every periodic event that remains in ROLE_ALL has
 a way to turn it off, a very generous and forgiving timeout, or both.

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

Re: [tor-bugs] #28335 [Core Tor/Tor]: Make most periodic events turn themselves off when Tor is dormant, sleeping, etc.

[Tor Bug Tracker & Wiki]

#28335: Make most periodic events turn themselves off when Tor is dormant,
sleeping, etc.
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #25500| Points:  10
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Tracking the work for splitting up the current timeouts at
 https://pad.riseup.net/p/role-splitting-2-keep

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

Re: [tor-bugs] #27265 [Applications/rbm]: In some cases, rbm will download files in the wrong project directory

[Tor Bug Tracker & Wiki]

#27265: In some cases, rbm will download files in the wrong project directory
---+---
 Reporter:  boklm  |  Owner:  boklm
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/rbm   |Version:
 Severity:  Normal | Resolution:
 Keywords:  boklm201809, TorBrowserTeam201809  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by boklm):

 I made a patch fixing this in branch `bug_27265_v2`:
 
https://gitweb.torproject.org/user/boklm/rbm.git/commit/?h=bug_27265_v2=081cc2ece715c2a91c35e1529d4ac4af4ffe3235

 This patch also adds a feature allowing to define options that only apply
 to the current project but not the child projects. I still need to make a
 new revision of the patch documenting this feature and do more testing
 before setting this as `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] #26540 [Applications/Tor Browser]: Enabling pdfjs disableRange option prevents pdfs from loading

[Tor Bug Tracker & Wiki]

#26540: Enabling pdfjs disableRange option prevents pdfs from loading
-+-
 Reporter:  pospeselr|  Owner:  pospeselr
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201811R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by pospeselr):

 Some concerns arthuredelestein brought up on irc:

 (11/01/2018 03:47:14 PM) arthuredelstein: hi! your new patch for #26540
 looks good! I'm wondering though, about cache and cookies and things like
 that.
 (11/01/2018 03:47:25 PM) arthuredelstein: Does setting the
 originAttributes on loadinfo take care of all of that?
 (11/01/2018 03:47:41 PM) arthuredelstein: (I guess the range request
 pieces might not be cached, not sure.)
 (11/01/2018 03:47:54 PM) arthuredelstein: But, for example, if there's a
 cookie header, does that get stored in the right place?
 (11/01/2018 03:48:02 PM) arthuredelstein: I don't know how to easily test
 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] #22453 [Core Tor/Tor]: Relays should regularly do a larger bandwidth self-test

[Tor Bug Tracker & Wiki]

#22453: Relays should regularly do a larger bandwidth self-test
-+-
 Reporter:  arma |  Owner:  juga
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-triage-20180328, |  Actual Points:
  034-removed-20180328, tor-bwauth   |
Parent ID:  #25925   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by juga):

 i thought that the descriptor observed bandwidth (used by bwauths) comes
 only from the self-test, but arma comments in irc:

 > the descriptor observed bandwidth comes from all of the use of the
 relay. a little bit of that use is the bandwidth self-test. more of it is
 bwauth load. and ideally, most of it is from actual clients

 so then maybe it can be removed

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

Re: [tor-bugs] #28299 [Core Tor/Nyx]: Custom colors for Nyx and tor-prompt are needed

[Tor Bug Tracker & Wiki]

#28299: Custom colors for Nyx and tor-prompt are needed
--+---
 Reporter:  wagon |  Owner:  atagar
 Type:  enhancement   | Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.3.4.8
 Severity:  Normal| Resolution:
 Keywords:  tor-prompt|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by wagon):

 Actually, color names are messy, each console application use its own
 names (BrightGreen vs Green, or Green vs DarkGreen, etc... some cases even
 more esoteric: coexisting of some of the values such as DarkWhite, White,
 BrightWhite, DarkBlack, Black, BrightBlack, DarkGrey, Grey and
 BrightGrey).

 I got your point. Minimal program should be very simple: manually choose
 color for each set of elements. I guess it is like 5-10 options, just
 moving those constants to `nyxrc`. I don't know other popular curses
 applications which force user to use particular color scheme. :)

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

Re: [tor-bugs] #22453 [Core Tor/Tor]: Relays should regularly do a larger bandwidth self-test

[Tor Bug Tracker & Wiki]

#22453: Relays should regularly do a larger bandwidth self-test
-+-
 Reporter:  arma |  Owner:  juga
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-triage-20180328, |  Actual Points:
  034-removed-20180328, tor-bwauth   |
Parent ID:  #25925   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 I still think there's a strong argument for simplifying our design and
 code and ripping out the bandwidth self-tests. So long as there are
 bwauths of any sort running, they will produce load on the relays, which
 will have the same effect as the self-test. And if there aren't bwauths
 running, then either the existing client traffic is enough to make relays
 realize they are fast or it isn't, but the tiny amount of traffic from the
 self-test isn't going to help that much.

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

Re: [tor-bugs] #28332 [Core Tor/Nyx]: Nyx configurashion editor reproducibly crashes if custom ordering is set

[Tor Bug Tracker & Wiki]

#28332: Nyx configurashion editor reproducibly crashes if custom ordering is set
--+--
 Reporter:  wagon |  Owner:  atagar
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:  duplicate
 Keywords:  config|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by atagar):

 Hi wagon. Git is pretty simple - simply run 'git clone
 https://git.torproject.org/nyx.git'. Gi

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

Re: [tor-bugs] #28332 [Core Tor/Nyx]: Nyx configurashion editor reproducibly crashes if custom ordering is set

[Tor Bug Tracker & Wiki]

#28332: Nyx configurashion editor reproducibly crashes if custom ordering is set
--+--
 Reporter:  wagon |  Owner:  atagar
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:  duplicate
 Keywords:  config|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by wagon):

 I don't know how to use git version safely. I guess it is not even signed.
 Could you post a tarball and its sig for current developers version? You
 could add the links [[https://nyx.torproject.org/#download|here]] in Sec.
 "Python Package Index" and regularly update them (each month or week, so
 it could be analog of "alpha" versions).

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

Re: [tor-bugs] #27443 [Applications/Tor Browser]: Update Firefox RBM config and build for Android

[Tor Bug Tracker & Wiki]

#27443: Update Firefox RBM config and build for Android
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by sisbell):

 * 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] #27443 [Applications/Tor Browser]: Update Firefox RBM config and build for Android

[Tor Bug Tracker & Wiki]

#27443: Update Firefox RBM config and build for Android
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 Changes (android-1105)

  * __config__: Cleaned up arch_deps. Added ccache to support --with-ccache
 option in mozconfig-android-armv7
  * Added projects/firefox/how-to-create-dependencies-list.txt
  * __mozconfig-android-armv7__: Enabled optimization and cache options. I
 added the MOZILLA_OFFICIAL export to align with what is in tor-browser git
 repo. Although I'm not convinced this is really needed, it won't do any
 harm.

 I verified that apk runs on device.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28334 [Core Tor/Nyx]: Nyx configurashion editor does not work with options' values properly

[Tor Bug Tracker & Wiki]

#28334: Nyx configurashion editor does not work with options' values properly
--+--
 Reporter:  wagon |  Owner:  atagar
 Type:  defect| Status:  assigned
 Priority:  Medium|  Component:  Core Tor/Nyx
  Version:  Tor: 0.3.4.9  |   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 Nyx 2.0.4 at Linux.

 The first problem exist with all options: if I select some option, then
 press `Enter` (so, start editing it), and then press `ESC`, all old values
 for the option are erased (value becomes `none`). This behavior confuses
 users, because normally `ESC` should keep old version of values. To my
 opinion, if I really need to make it `none` I should manually remove old
 values (or press `ctrl+u`) and then press `Enter`.

 The second problem exist with options which have very long list of values.
 For example, you can consider `torrc` with a long list of `SocksPort`
 options or a long list of values for `ExcludeNodes` option. If you select
 such option in configuration editor (press `Enter`), only the first part
 of values' list will be shown. Other lengthy part of values list will not
 be printed and will not be accessible for editing (it is considered as
 non-existing). I guess it is related to the problem of line splitting
 ([[https://trac.torproject.org/projects/tor/ticket/28297|#28297]]). Since
 the first part of accessible values may end at any character (when end of
 line is reached), if I don't do anything, but just print `Enter`, I may
 get an error

 `Unacceptable option value: Invalid SocksPort configuration (press any
 key)`

 As `nyx` gives to Tor wrong option values, there are many warnings in a
 log file of `tor` itself, e.g.:

 `Controller gave us config lines that didn't validate: Invalid SocksPort
 configuration`

 Thus, if you accidentally press `Enter` on any option with too long list
 of values, you get trapped in inescapable situation: `ESC` will erase all
 old values, `Enter` will change them too (possibly with some errors). It
 is impossible to preserve status quo.

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

Re: [tor-bugs] #28320 [Metrics/CollecTor]: Rewrite CollecTor relaydescs module using Stem/txtorcon

[Tor Bug Tracker & Wiki]

#28320: Rewrite CollecTor relaydescs module using Stem/txtorcon
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor13
---+--

Comment (by atagar):

 Hi Karsten. This sounds an awful lot like DocTor (download descriptors on
 an hourly basis and check a series of characteristics).

 That said, honestly I'm unsure you need either stem or txorcon for this.
 If all you want is to download descriptors won't cron and curl do the
 trick? Stem's benefit is that it **parses** descriptors and can download
 leveraging directory mirrors. As for txtorcon, I'm unaware of any
 descriptor capabilities it provides (meejah can correct me wrong but it's
 solely a twisted control port controller).

 Would you mind further describing what you're hoping for one of these to
 provide? If you'd like a simple example of downloading descriptors
 [https://stem.torproject.org/tutorials/mirror_mirror_on_the_wall.html
 #where-can-i-get-the-current-descriptors our tutorials],
 [https://stem.torproject.org/tutorials/examples/download_descriptor.html
 demos], and
 [https://gitweb.torproject.org/doctor.git/tree/descriptor_checker.py
 doctor] have examples.

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

Re: [tor-bugs] #27919 [Applications/Tor Browser]: Backport SSL status API to Tor Browser alpha

[Tor Bug Tracker & Wiki]

#27919: Backport SSL status API to Tor Browser alpha
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201811,|  Actual Points:
  GeorgKoppen201811  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by pastly):

 * cc: pastly (added)


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

[tor-bugs] #28333 [- Select a component]: Trouble Connecting to Tor browser

[Tor Bug Tracker & Wiki]

#28333: Trouble Connecting to Tor browser
--+--
 Reporter:  Executor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  - Select a component
  Version:|   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 Hello, I'm having trouble Connecting to Tor browser. I thought it was a
 bit size promblem but was not. I downloaded 32 bit size nothing happened.
 Also 64 bit size and nothing happened. My computer is by the way 64 bit. I
 haven't downloaded Tor bundle but it might not be the promblem. I tried
 all this at night so times of clock might be wrong idk. The error is:
 failed to establish a connection. (Failed to connect host) and some
 numbers but I forgot what they were.
 Please Help

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

Re: [tor-bugs] #21377 [Core Tor/Tor]: DirAuths should expose bwauth bandwidth files

[Tor Bug Tracker & Wiki]

#21377: DirAuths should expose bwauth bandwidth files
-+-
 Reporter:  tom  |  Owner:  juga
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth, metrics, tor-bwauth,|  Actual Points:
  035-removed-20180711, 036-roadmap-proposed |
Parent ID:  #25925   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by juga):

 * status:  needs_revision => needs_review


Comment:

 Fixed CI

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

Re: [tor-bugs] #28295 [Core Tor/Nyx]: Non-interactive way to supply ControlPort password for nyx and tor-prompt is needed

[Tor Bug Tracker & Wiki]

#28295: Non-interactive way to supply ControlPort password for nyx and 
tor-prompt
is needed
--+--
 Reporter:  wagon |  Owner:  atagar
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.3.4.8
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by atagar):

 > I would say the opposite: cookie authentication is a poor man's password
 authentication.

 Your two points are true for ControlSockets, but a ControlPort with cookie
 authentication shouldn't differ from password authentication in this
 respect. In either case nyx is 'providing the contents of a file to tor's
 control port'. The only difference is that with
 [https://stem.torproject.org/faq.html#i-m-using-password-authentication
 password authetnication] its your raw password, with
 [https://stem.torproject.org/faq.html#i-m-using-cookie-authentication
 cookie auth] it's an autogenerated hash in a file with especially
 restricted permissions, and with SafeCookie it's a more complicated
 handshake that prevents replay attacks and such.

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

Re: [tor-bugs] #25013 [Applications/Tor Browser]: Move TorButton code to the tor browser repository

[Tor Bug Tracker & Wiki]

#25013: Move TorButton code to the tor browser repository
---+---
 Reporter:  igt0   |  Owner:  tbb-team
 Type:  defect | Status:
   |  needs_review
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201811R  |  Actual Points:
Parent ID:  #10760 | Points:
 Reviewer:  gk, sysrqb, mcs,   |Sponsor:
---+---

Comment (by sysrqb):

 Related to the above locales, this allows including only one locale.
 Current we ship torbutton with localization for all locales (and tor
 browser only uses one of them). I'm not sure if we want to continue
 shipping all of them or this proposed patch is better for tor browser and
 we only select the locale of the browser.

 I can see us wanting to ship torbutton with all locales within the multi-
 lingual builds, but I don't know if we should optimize for that right now.

 Another question is whether we want this as a feature extension or as a
 system extension. Arthur made a good argument for a feature extension
 allowing easily copying a new torbutton*.xpi into the tor-browser dir,
 compared with a system extension that's bundled directly into to omni jar.
 The feature extension is a little more complicated, but maybe the
 additional flexibility is worth the added complexity.

 This may already be known, but just so its documented...when testing this
 within tor-browser, we'll need something like this (assuming torbutton is
 places under toolkit/components/:
 {{{
 diff --git a/mobile/android/installer/package-manifest.in
 b/mobile/android/installer/package-manifest.in
 index 8a2a356c151c..5415d436acdd 100644
 --- a/mobile/android/installer/package-manifest.in
 +++ b/mobile/android/installer/package-manifest.in
 @@ -426,6 +426,10 @@
  @BINPATH@/chrome/devtools@JAREXT@
  @BINPATH@/chrome/devtools.manifest

 +; Torbutton
 +@BINPATH@/chrome/torbutton@JAREXT@
 +@BINPATH@/chrome/torbutton.manifest
 +
  ; [Default Preferences]
  ; All the pref files must be part of base to prevent migration bugs
  #ifdef MOZ_GECKOVIEW_JAR
 diff --git a/toolkit/components/moz.build b/toolkit/components/moz.build
 index 2bc8b12121f2..61a145335097 100644
 --- a/toolkit/components/moz.build
 +++ b/toolkit/components/moz.build
 @@ -114,3 +114,6 @@ if CONFIG['NIGHTLY_BUILD'] and CONFIG['MOZ_BUILD_APP']
 == 'browser':

  if CONFIG['MOZ_BUILD_APP'] == 'browser':
  DIRS += ['normandy']
 +
 +if CONFIG['MOZ_BUILD_APP'] == 'browser' or CONFIG['MOZ_BUILD_APP'] ==
 'mobile/android':
 +DIRS += ['torbutton']
 }}}

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

Re: [tor-bugs] #27321 [Core Tor/Nyx]: incorrect bw calculation during initial startup

[Tor Bug Tracker & Wiki]

#27321: incorrect bw calculation during initial startup
--+---
 Reporter:  a_p   |  Owner:  atagar
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by atagar):

 Hi wagon. This looks tor simply isn't reporting any traffic (the current
 value is zero bytes). Please log BW events. Nyx simply reflects whatever
 those events say. If the event is faithfully providing low values
 (commonly zero) then nyx is working as intended.

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

Re: [tor-bugs] #28326 [Applications/Tor Browser]: Tor Browser for PPC64LE

[Tor Bug Tracker & Wiki]

#28326: Tor Browser for PPC64LE
--+--
 Reporter:  power9|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by power9):

 That's mean we never see Tor on PPC?

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

Re: [tor-bugs] #28332 [Core Tor/Nyx]: Nyx configurashion editor reproducibly crashes if custom ordering is set

[Tor Bug Tracker & Wiki]

#28332: Nyx configurashion editor reproducibly crashes if custom ordering is set
--+--
 Reporter:  wagon |  Owner:  atagar
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:  duplicate
 Keywords:  config|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by atagar):

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


Comment:

 Hi wagon, I just tried those repro steps with the current nyx and stem git
 codebases. No crash. Please give those a try.

 This looks to be a case of:
 https://trac.torproject.org/projects/tor/ticket/24401

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

Re: [tor-bugs] #28299 [Core Tor/Nyx]: Custom colors for Nyx and tor-prompt are needed

[Tor Bug Tracker & Wiki]

#28299: Custom colors for Nyx and tor-prompt are needed
--+---
 Reporter:  wagon |  Owner:  atagar
 Type:  enhancement   | Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.3.4.8
 Severity:  Normal| Resolution:
 Keywords:  tor-prompt|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by atagar):

 Gotcha. I was worried that might be the ask. ;P

 Nyx 1.x (ie, when still called 'arm') we had more extensive
 configurability because I added options to reflect every user request.
 However, this complicated the codebase with options effectively nobody
 ever used. As such I've taken a 'less is more' approach with Nyx 2.x,
 providing a general color override but not per-field configurability.

 Lets keep this feature request open for a while to see if others chime in
 as wanting this. Maybe as part of a 'theming' feature?

 In the meantime colors are defined in simple codebase constants so with
 simple file tweaks (for instance, to 'panels/torrc.py') you should be able
 to adjust the constants as desired to fit your tastes.

 > Red, BrightRed, Green, BrightGreen, etc.

 It's minor semantics but for what it's worth in curses we have a RRB +
 CMYK pallet (red, green, blue, cyan, magenta, yellow, black). The
 'BrightRed' color you mention is a **bold** attribute applied to red. That
 said, on most (but not all) consoles it certainly does look like a
 brighter red.

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