Re: [tor-bugs] #28997 [Applications/Tor Browser]: TB 8.0.4 - Tor is not shutting down properly

[Tor Bug Tracker & Wiki]

#28997: TB 8.0.4 - Tor is not shutting down properly
--+---
 Reporter:  jb.1234abcd   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  needs_information => closed
 * resolution:   => not a bug


Comment:

 Thanks for helping to track this down, everyone. This is not a Tor Browser
 bug it seems.

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

Re: [tor-bugs] #10760 [Applications/Tor Browser]: Integrate TorButton to TorBrowser core to prevent users from disabling them

[Tor Bug Tracker & Wiki]

#10760: Integrate TorButton to TorBrowser core to prevent users from disabling 
them
+--
 Reporter:  Rezonansowy |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201901, AffectsTails  |  Actual Points:
Parent ID:  #24855  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by gk):

 Replying to [comment:15 intrigeri]:
 > FTR, Tails' "Unsafe Browser" is basically Tor Browser, with Torbutton
 disabled and a scary homepage. It would be nice if there were still a
 hidden way for us to disable Torbutton for that browser profile.

 I see. I'll keep that in mind and I guess we could make a hidden pref
 available or something.

 > Otherwise, we'll have to ship binaries for another browser, which will
 make our ISO and upgrade delta significantly bigger. In order to plan
 Tails work on this topic, I need to know whether it'll still be possible
 to disable Torbutton somehow, and if not, I would be very grateful to
 learn what's the timeline is here, e.g. whether the plan is to ship this
 change in Tor Browser 8.5. Thanks in advance! Please let me know if you
 need additional info from me to answer my questions :)

 We didn't plan to have the option of disabling Torbutton. But we can try
 to make that happen. I doubt we'll have this ready for 8.5. I mean we
 probably could but I think we should have some more time to test this, in
 particular as there are downstream projects that might be affected by
 this. But this should land in alphas definitely way before we start the
 esr68 transition. So, my current plan is to have this in Tor Browser
 9.0a1, which should get out end of March/begin of April.

 FWIW: you might be interested in #28044, too.

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

Re: [tor-bugs] #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:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth, metrics, tor-bwauth,|  Actual Points:
  035-removed-20180711, 040-roadmap-proposed |
Parent ID:  #25925   | Points:
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by juga):

 * status:  needs_revision => needs_review


Comment:

 I added the comment and change the log message.

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

Re: [tor-bugs] #29074 [Applications/Tor Browser]: Consider using the Windows 10 UA instead of the Windows 7 UA in the TB UA

[Tor Bug Tracker & Wiki]

#29074: Consider using the Windows 10 UA instead of the Windows 7 UA in the TB 
UA
--+
 Reporter:  cypherpunks3  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

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


Comment:

 Yes, we won't switch now but will get this when switching to esr68. Thus,
 nothing to do on our side.

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

Re: [tor-bugs] #29041 [Applications/Tor Browser]: Compile clang closer to how Mozilla does it

[Tor Bug Tracker & Wiki]

#29041: Compile clang closer to how Mozilla does it
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| 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):

 We could think about doing
 https://bugs.chromium.org/p/chromium/issues/detail?id=533657 here, to get
 a more deterministicly built compiler (see: comment:8:ticket:28238).

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

Re: [tor-bugs] #28823 [Applications/Tor Browser]: Every web page crashes on Windows 7 with Tor Browser 8

[Tor Bug Tracker & Wiki]

#28823: Every web page crashes on Windows 7 with Tor Browser 8
--+---
 Reporter:  testcy|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by gk):

 Replying to [comment:36 testcy]:
 > I tried every version again and 8.0.4 and 8.5a6 both are crashing and
 also the latest test build. Previously when I briefly tested the test
 build it was not crashing, but now it is crashing. Also, note that the
 problem does not happen with every web-page, as in the description, but
 with certain web-pages and randomly, so it's difficult to reproduce. And
 am I the only one that uses Comodo and Tor? Shouldn't others report a
 problem if there is one?

 They might just give up and say "Tor Browser is broken, I use something
 else instead". That said we have and had different reports with
 Antivirus/Firewall software breaking Tor Browser. There is not much we can
 do in those cases, though. :(

 That said you seem to get crashes _without_ having Comodo active, so there
 might be something else that is wrong. The only difference between build
 _3 and _4 is that the former enables debug output and the latter not. I
 wonder if you could try a bit harder to get _3 crashed (and get back with
 some crash debug output). If not that's okay, but then I need to think
 harder about how to get some hint about what is going on on your system...

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

Re: [tor-bugs] #28238 [Applications/Tor Browser]: Use mingw-w64/clang toolchain to build Firefox

[Tor Bug Tracker & Wiki]

#28238: Use mingw-w64/clang toolchain to build Firefox
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, GeorgKoppen201901,  |  Actual Points:
  TorBrowserTeam201901   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:7 ld]:
 > https://bugs.chromium.org/p/chromium/issues/detail?id=533657
 > https://bugs.llvm.org/show_bug.cgi?id=24740#c3

 That's about building _clang_ deterministic, yes. Thus, this is more
 suited for #29041.

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

Re: [tor-bugs] #29080 [Applications/Tor Browser]: Merge OrbotService and TOPL

[Tor Bug Tracker & Wiki]

#29080: Merge OrbotService and TOPL
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a3,  |  Actual Points:
  TorBrowserTeam201901   |
Parent ID:  #27609   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 I've done an initial (ugly) merging of TOPL and orbotservice so have
 enough to identify the specifics.

 Changes to TOPL

  * The !OnionProxyManager should be able to set the !EventHandler, rather
 than use the default one. Need to add a field to the !OnionProxyManager
 allowing us to pass in the custom !EventHandler that we will use.

  * Currently only supports configuring one hidden service. Add support for
 multiple hidden services through !OnionProxyManager.publishHiddenService

  * Add fields to the !TorConfig builder: ServerDNSResolvConfFile,
 !ExitNodes, Bridge, NEWNYM, Socks5ProxyUsername, Socks5ProxyPassword,
 !ProxyAuthenticator, !ClientTransportPlugin, !ReachableAddresses,
 !ExcludeNodes, !EntryNodes, !AutomapHostsOnResolve, DNSPort,
 HTTPTunnelPort

  * Add support for writing DNS File (resolv.conf)

  * Add support for loading bridges from resource file

 Changes to OrbotService
 * TorEventHandler - Orbot delegates sending of Android broadcasts to the
 TorService. We can decouple this by sending the broadcasts directly. This
 interface integrates with the same one that TOPL uses and can be
 configured through the OnionProxyManager with the fix defined above. [Easy
 fix]

 * TorService - this is a 2K line uber class.
   - Dozen or so broadcast messages that the main app will display to user.
 Need to replicate these where is makes sense
   - HiddenService Content DB - writes out to torrc. Break into its own
 class (possibly auto-generate)
   - Client Cookie DB - writes out to torrc. Break into its own class
 (possibly auto-generate)
   - VPN - we can port this directly
   - Clean circuits - a pending intent through a notification on service
 startup (NEWNYM)
   - Create Notifications for Network connectivity - this exists in TOPL
 but does not create notif
   - Start/Stop tor - we can use TOPL OnionProxyManager.start and
 OnionProxyManager.stop method to replace this feature
   - Tor Installer - we can use the one from TOPL
   - Handle events sent to service: ACTION_START, ACTION_STATUS,
 CMD_SIGNAL_HUP, CMD_NEWNYM, CMD_VPN, CMD_VPN_CLEAR, CMD_SET_EXIT
   - Various torrc config params that mirror TOPL
   - Loads Bridges from resource file

 Most of the work is simply taking everything from the Content DB and prefs
 and adding fields to torrc. The DB need to be rewritten. This should all
 be done in a separate package/set of classes, not in the TorService class.

 The new TorService will:
 * delegate to TorConfig package when generating torrc from prefs/DB
 * delegate to the OnionProxyManager for the start/stop of tor.
 * delegate to the AndroidResourceInstaller (TOPL) for installing tor
 * delegate to TOPL Config for loading bridges
 * handle incoming events AND outgoing notifications.
 * handle VPN configuration

 Integration:
 TOPL will be an android library. OrbotService will use TOPL. We can create
 patches for both projects and then integrate into tor-browser-build. The
 main Orbot app shouldn't require any changes as we can support the
 existing interfaces and broadcasts.

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

Re: [tor-bugs] #29027 [Core Tor/Tor]: PrivCount proof of concept: put the PrivCount statistics in a stats/ file

[Tor Bug Tracker & Wiki]

#29027: PrivCount proof of concept: put the PrivCount statistics in a stats/ 
file
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  privcount, 040-unreached-20190109,   |  Actual Points:
  041-proposed-on-roadmap|
Parent ID:  #29004   | Points:  0.5
 Reviewer:   |Sponsor:
 |  SponsorV
-+-
Changes (by teor):

 * points:   => 0.5


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

Re: [tor-bugs] #26970 [Core Tor/Tor]: Privcount: plan the modules and components

[Tor Bug Tracker & Wiki]

#26970: Privcount: plan the modules and components
-+-
 Reporter:  teor |  Owner:  teor
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  privcount, 035-roadmap-master, 035   |  Actual Points:
  -triaged-in-20180711, rust,|
  040-unreached-20190109, 041-proposed-on-   |
  roadmap|
Parent ID:  #22898   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorV
-+-
Changes (by teor):

 * points:   => 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] #27908 [Core Tor/Tor]: PrivCount proof of concept with existing statistics

[Tor Bug Tracker & Wiki]

#27908: PrivCount proof of concept with existing statistics
-+-
 Reporter:  teor |  Owner:  teor
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  privcount, 040-unreached-20190109,   |  Actual Points:
  041-proposed-on-roadmap|
Parent ID:  #22898   | Points:  3
 Reviewer:   |Sponsor:
 |  SponsorV
-+-
Changes (by teor):

 * points:   => 3


Comment:

 The points for this ticket are for the remaining sub tasks that we haven't
 created yet,

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

Re: [tor-bugs] #29024 [Core Tor/Chutney]: Add pluggable-transport support to Chutney

[Tor Bug Tracker & Wiki]

#29024: Add pluggable-transport support to Chutney
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Chutney |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-pt, 041-proposed-on-roadmap  |  Actual Points:
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:  Sponsor19
-+-
Changes (by teor):

 * points:   => 2


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

Re: [tor-bugs] #29056 [Core Tor/Stem]: Implement bandwidth file parser and formater

[Tor Bug Tracker & Wiki]

#29056: Implement bandwidth file parser and formater
---+--
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-bwauth |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by juga):

 * status:  assigned => new


Comment:

 Un-assign myself, since maybe is implemented by atagar

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

Re: [tor-bugs] #27162 [Core Tor/Tor]: Travis: consider running CI on beta, nightly, and tor's lowest supported rust

[Tor Bug Tracker & Wiki]

#27162: Travis: consider running CI on beta, nightly, and tor's lowest supported
rust
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, tor-ci, privcount, |  Actual Points:
  040-unreached-20190109, 041-proposed-on-   |
  roadmap|
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * points:   => 0.5


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

Re: [tor-bugs] #26992 [Core Tor/Tor]: Add intro point IPv6 address to service descriptors

[Tor Bug Tracker & Wiki]

#26992: Add intro point IPv6 address to service descriptors
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:
  ipv6, 034-triage-20180328, |
  034-removed-20180328, 040-unreached-20190109,  |
  041-proposed   |
Parent ID:  #23576   | Points:  0.5
 Reviewer:  asn  |Sponsor:
-+-
Changes (by teor):

 * points:   => 0.5


Comment:

 This could take half a day to test.

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

Re: [tor-bugs] #27906 [Core Tor/Tor]: PrivCount noise specification

[Tor Bug Tracker & Wiki]

#27906: PrivCount noise specification
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  needs-proposal, privcount,   |  Actual Points:
  040-unreached-20190109, 041-proposed-on-   |
  roadmap|
Parent ID:  #25153   | Points:  3
 Reviewer:   |Sponsor:
 |  SponsorV
-+-
Changes (by teor):

 * points:   => 3


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

Re: [tor-bugs] #29056 [Core Tor/Stem]: Implement bandwidth file parser and formater

[Tor Bug Tracker & Wiki]

#29056: Implement bandwidth file parser and formater
---+--
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-bwauth |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by juga):

 Replying to [comment:7 teor]:
 > In fact, you should have 4 files in your unit tests, because there are
 two different kinds of 1.2.0 files.
 >
 > There are sample files in the appendix of the spec here:
 > https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-
 spec.txt#n543
 >
 > If you want to parse a real file that contains thousands of relays, they
 are publicly archived by some directory authorities. You should get a
 sample from longclaw, which runs sbws, and another authority, which all
 run torflow.

 Torflow: https://bwauth.ritter.vg/bwauth/bwscan.V3BandwidthsFile
 sbws v1.0.2 (bandwidth file version 1.2):
 https://people.torproject.org/~juga/volatile/latest.v3bw

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

Re: [tor-bugs] #29029 [Core Tor/Tor]: Make "tried to establish rendezvous on non-OR circuit" into a protocol warning

[Tor Bug Tracker & Wiki]

#29029: Make "tried to establish rendezvous on non-OR circuit" into a protocol
warning
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.5.7-rc
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, fast-fix, 040-proposed-  |  Actual Points:  0.2
  fast-fix, 040-backport, 035-backport,  |
  034-backport, 033-backport, 029-backport   |
Parent ID:  #15618   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:
 tor-hs, fast-fix, 041-proposed-fast-fix, 040-proposed-fast-fix,
 040-backport, 035-backport, 034-backport, 033-backport, 029-backport
 =>
 tor-hs, fast-fix, 040-proposed-fast-fix, 040-backport, 035-backport,
 034-backport, 033-backport, 029-backport


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

Re: [tor-bugs] #29056 [Core Tor/Stem]: Implement bandwidth file parser and formater

[Tor Bug Tracker & Wiki]

#29056: Implement bandwidth file parser and formater
---+--
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-bwauth |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by teor):

 Replying to [comment:8 juga]:
 > Replying to [comment:7 teor]:
 > > In fact, you should have 4 files in your unit tests, because there are
 two different kinds of 1.2.0 files.
 >
 > Since it'll change again with 1.0.3 (not released yet) and since, except
 for longclaw, there're no other authorities that has used sbws, do you
 really think it's needed to support the files produced by sbws 1.2.0?.

 People will expect stem to parse all available format versions.

 Here's why we might need to parse each format version:
 * stem will need to parse 1.0.0 format files, because they're produced by
 Torflow on most authorities.
 * if anyone is keeping an archive of bandwidth files from longclaw, then
 it may contain 1.1.0 format files, and it will contain 1.2.0 format files.
 * if stem's parser is ready before longclaw deploys sbws 1.0.3, then it
 should be able to parse 1.2.0 format files.

 And more generally:

 The bandwidth file format is forward-compatible: a well-written parser
 should be able to handle 1.0.0, 1.1.0, 1.2.0, and all future 1.x format
 versions. And it's worth testing the parser with all available format
 versions, to make sure it produces useful results.

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

Re: [tor-bugs] #29056 [Core Tor/Stem]: Implement bandwidth file parser and formater

[Tor Bug Tracker & Wiki]

#29056: Implement bandwidth file parser and formater
---+--
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-bwauth |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by juga):

 Replying to [comment:4 atagar]:
 > Thanks teor! I'd be happy to proceed with the parser part of this now.

 It's basically implemented in sbws [0], but there're some changes to make
 I guess it should inherit from stem.descriptor.Descriptor. It's not using
 regular expressions but after looking how you implemented other documents,
 might be easier to use them.
 Probably there's no need to separate classes for header and bandwidth
 lines.

 [0]
 
https://github.com/torproject/sbws/blob/12ad99d0024cdd65bd73d6ac969cc1e70680f286/sbws/lib/v3bwfile.py#L157,
 
https://github.com/torproject/sbws/blob/12ad99d0024cdd65bd73d6ac969cc1e70680f286/sbws/lib/v3bwfile.py#L187,
 
https://github.com/torproject/sbws/blob/12ad99d0024cdd65bd73d6ac969cc1e70680f286/sbws/lib/v3bwfile.py#L362,
 
https://github.com/torproject/sbws/blob/12ad99d0024cdd65bd73d6ac969cc1e70680f286/sbws/lib/v3bwfile.py#L590,
 
https://github.com/torproject/sbws/blob/12ad99d0024cdd65bd73d6ac969cc1e70680f286/sbws/lib/v3bwfile.py#L600

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

Re: [tor-bugs] #29056 [Core Tor/Stem]: Implement bandwidth file parser and formater

[Tor Bug Tracker & Wiki]

#29056: Implement bandwidth file parser and formater
---+--
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-bwauth |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by juga):

 Replying to [comment:7 teor]:
 > In fact, you should have 4 files in your unit tests, because there are
 two different kinds of 1.2.0 files.

 Since it'll change again with 1.0.3 (not released yet) and since, except
 for longclaw, there're no other authorities that has used sbws, do you
 really think it's needed to support the files produced by sbws 1.2.0?.

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

[tor-bugs] #29080 [Applications/Tor Browser]: Merge OrbotService and TOPL

[Tor Bug Tracker & Wiki]

#29080: Merge OrbotService and TOPL
-+-
 Reporter:  sisbell  |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-mobile, TBA-a3,
 Severity:  Normal   |  TorBrowserTeam201901
Actual Points:   |  Parent ID:  #27609
   Points:   |   Reviewer:
  Sponsor:   |
-+-


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

Re: [tor-bugs] #27531 [Applications/Tor Browser]: Tor Browser 8 crashes trying to print on Linux

[Tor Bug Tracker & Wiki]

#27531: Tor Browser 8 crashes trying to print on Linux
-+-
 Reporter:  mikeperry|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-crash, tbb-8.0-issues, tbb-  |  Actual Points:
  regression |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 Replying to [comment:12 wert2]:
 > If I understand this right, gmpn_cnd_sub_n is defined locally but not in
 TBB.  Hope this helps.  (If this is an upstream or elsewhere thing, please
 let me know.)

 Okay, I'm hitting this now, too. Fedora 29.

 {{{
 (firefox:2105): Gtk-WARNING **: 02:17:31.932: /lib64/libhogweed.so.4:
 undefined symbol: __gmpn_cnd_sub_n

 (firefox:2105): Gtk-WARNING **: 02:17:31.939: /lib64/libhogweed.so.4:
 undefined symbol: __gmpn_cnd_sub_n
 Jan 14 02:17:36.000 [notice] Owning controller connection has closed --
 exiting now.
 Jan 14 02:17:36.000 [notice] Catching signal TERM, exiting cleanly.
 ./tor-browser_en-US/Browser/start-tor-browser: line 373:  2105
 Segmentation fault  (core dumped)
 TOR_CONTROL_PASSWD=${TOR_CONTROL_PASSWD} ./firefox --class "Tor Browser"
 -profile TorBrowser/Data/Browser/profile.default "${@}" < /dev/null
 [Child 2230, Chrome_ChildThread] WARNING: pipe error (3): Connection reset
 by peer: file /var/tmp/build/firefox-
 efdff96e8955/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 353
 }}}

 Interestingly, I'm seeing the same missing symbol as wert2
 (`__gmpn_cnd_sub_n`), but a different missing symbol than Jaym
 (`gmpz_limbs_read`), probably different Tor Browser releases. But, either
 way, it seems like this is another instance where the system provides a
 newer version of the library. I'm guessing Debian Wheezy is providing a
 particularly old version of gmp 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] #29056 [Core Tor/Stem]: Implement bandwidth file parser and formater

[Tor Bug Tracker & Wiki]

#29056: Implement bandwidth file parser and formater
---+--
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-bwauth |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by teor):

 In fact, you should have 4 files in your unit tests, because there are two
 different kinds of 1.2.0 files.

 There are sample files in the appendix of the spec here:
 https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-
 spec.txt#n543

 If you want to parse a real file that contains thousands of relays, they
 are publicly archived by some directory authorities. You should get a
 sample from longclaw, which runs sbws, and another authority, which all
 run torflow.

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

Re: [tor-bugs] #29079 [Core Tor/Tor]: Minor bandwidth file spec updates (was: The terminator was 4 characters long from sbws 0.1.0 to sbws 1.0.0)

[Tor Bug Tracker & Wiki]

#29079: Minor bandwidth file spec updates
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bwauth, torspec, doc  |  Actual Points:
Parent ID:  #29056| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  assigned => needs_review


Old description:

> https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-
> spec.txt#n96

New description:

 The terminator was 4 characters long from sbws 0.1.0 to sbws 1.0.0

 https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-spec.txt#n96

--

Comment:

 See my pull request:
 https://github.com/torproject/torspec/pull/51

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

Re: [tor-bugs] #29056 [Core Tor/Stem]: Implement bandwidth file parser and formater

[Tor Bug Tracker & Wiki]

#29056: Implement bandwidth file parser and formater
---+--
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-bwauth |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by atagar):

 > You should have three files in your unit tests

 Sounds good. Any notion of who can provide them?

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

Re: [tor-bugs] #29079 [Core Tor/Tor]: The terminator was 4 characters long from sbws 0.1.0 to sbws 1.0.0

[Tor Bug Tracker & Wiki]

#29079: The terminator was 4 characters long from sbws 0.1.0 to sbws 1.0.0
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bwauth, torspec, doc  |  Actual Points:
Parent ID:  #29056| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 I'll do a bunch of minor changes in this ticket, in separate commits,

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29079 [Core Tor/Tor]: The terminator was 4 characters long from sbws 0.1.0 to sbws 1.0.0

[Tor Bug Tracker & Wiki]

#29079: The terminator was 4 characters long from sbws 0.1.0 to sbws 1.0.0
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-bwauth, torspec, doc
Actual Points:|  Parent ID:  #29056
   Points:|   Reviewer:
  Sponsor:|
--+--
 https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-spec.txt#n96

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

Re: [tor-bugs] #29056 [Core Tor/Stem]: Implement bandwidth file parser and formater

[Tor Bug Tracker & Wiki]

#29056: Implement bandwidth file parser and formater
---+--
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-bwauth |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by teor):

 Replying to [comment:4 atagar]:
 > Thanks teor! I'd be happy to proceed with the parser part of this now.
 It's fine if there's spec tweaks up until our next Stem release, which is
 a very long ways out. That said, I'll hold off on the downloader component
 until #21377 has been merged since I need that for an end-to-end test.
 >
 > To proceed with making a parser I need a copy of a bandwidth authority
 file for our unit tests. Per chance does anyone have one handy?

 You should have three files in your unit tests:
 * a format version 1.0 file from Torflow,
 * a format version 1.1 file from sbws 0.1.0 to 1.0.0
 * a format version 1.2 file from sbws 1.0.3 and later
 https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-
 spec.txt#n543

 I've noticed some minor spec issues, I'll open child tickets for them.

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

Re: [tor-bugs] #29078 [Core Tor/Nyx]: nyx values do differ from stem native example

[Tor Bug Tracker & Wiki]

#29078: nyx values do differ from stem native example
--+---
 Reporter:  toralf|  Owner:  atagar
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.3.5.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by atagar):

 > If however the connections are shown then pressing "r" doesn't have any
 visible effect for no choosen resolver.

 That makes sense to some extent. If you wait long enough the numbers will
 correct themselves. Nyx slows down the rate at which it polls connection
 data when it takes a long time to get results so we don't put an overdue
 burden on your system...

 https://gitweb.torproject.org/nyx.git/tree/nyx/tracker.py#n569

 If it takes 20 seconds to query connection data then Nyx will back off so
 it only polls connection data every 2,000 seconds (every half hour). That
 said, Nyx should only do so after making three highly burdensome requests.

 Logging at a debug runlevel will tell you how long queries take to
 complete and when Nyx reduces its poll rate.

 > The error in that case still looks like that the inbound number aren't
 subtracted from the outbound number

 Sorry, without a local reproduction of an issue I can't really dig in. I
 just took a peek at the panel title stats and it looks right to me (not
 spotting any double counting).

 If you pause Nyx (so the panel does not populate with new connections)
 then count the number of connections labeled 'inbound' and 'outbound'
 shown in the panel are you saying that number does not match the panel
 title?

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

Re: [tor-bugs] #28070 [Applications/Tor Browser]: 'Save Image' crashes browser

[Tor Bug Tracker & Wiki]

#28070: 'Save Image' crashes browser
--+--
 Reporter:  babs4 |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tbb-mobile, tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by babs4):

 Have just tested with 8.5a5. Retried the process of comment #3. The
 browser has not crashed but neither has it downloaded the image (although
 I was prompted to allow File Access permission for Tor Browser for
 Android). Tried same process with another image on that page and nothing
 happens either.

 Since browser hasn't crashed will leave ticket status as closed.

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

Re: [tor-bugs] #29056 [Core Tor/Stem]: Implement bandwidth file parser and formater

[Tor Bug Tracker & Wiki]

#29056: Implement bandwidth file parser and formater
---+--
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-bwauth |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by atagar):

 Thanks teor! I'd be happy to proceed with the parser part of this now.
 It's fine if there's spec tweaks up until our next Stem release, which is
 a very long ways out. That said, I'll hold off on the downloader component
 until #21377 has been merged since I need that for an end-to-end test.

 To proceed with making a parser I need a copy of a bandwidth authority
 file for our unit tests. Per chance does anyone have one handy?

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

Re: [tor-bugs] #29078 [Core Tor/Nyx]: nyx values do differ from stem native example

[Tor Bug Tracker & Wiki]

#29078: nyx values do differ from stem native example
--+---
 Reporter:  toralf|  Owner:  atagar
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.3.5.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by toralf):

 The numebrs of the stem example are correct and comparable for "--
 netstat", "--lsof" and "--proc".

 For nyx the correct numbers are shown (for "netstat", "ss" and "proc") if
 I press "r" before the first time the connection page was filled (which
 usually needs 20 sec). If however the connections are shown then pressing
 "r" doesn't have any visible effect for no choosen resolver.

 The error in that case still looks like that the inbound number aren't
 subtracted from the outbound number (which seems to be the sum of both
 isntead of the outbound only).

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

Re: [tor-bugs] #28997 [Applications/Tor Browser]: TB 8.0.4 - Tor is not shutting down properly

[Tor Bug Tracker & Wiki]

#28997: TB 8.0.4 - Tor is not shutting down properly
--+---
 Reporter:  jb.1234abcd   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by jb.1234abcd):

 Replying to [comment:29 cypherpunks3]:
 > > or in iptables
 >
 > or kernel update (more likely).
 > some race condition, browser closed socket and vanished, conntrack
 purged state before connection terminated. then anything (non RST) for
 this connection is invalid.
 Yes indeed, the problem is linked to kernel 4.20 (a fallback to prior
 version makes it good again).
 I contacted kernel netfilter mailing list.

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

Re: [tor-bugs] #29078 [Core Tor/Nyx]: nyx values do differ from stem native example

[Tor Bug Tracker & Wiki]

#29078: nyx values do differ from stem native example
--+---
 Reporter:  toralf|  Owner:  atagar
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.3.5.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by atagar):

 * owner:  (none) => atagar
 * status:  new => needs_information
 * component:  - Select a component => Core Tor/Nyx


Comment:

 Hi toralf. To start with please change Nyx's resolution method. By default
 it uses a method I call 'inference' which sidesteps
 DisableDebuggerAttachment but might be getting confused by having two tor
 relays present.

 To change the method go to the connection page, press 'r', and select
 'netstat'. Please also re-run the stem connection count with a '--resolver
 netstat' argument.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29078 [- Select a component]: nyx values do differ from stem native example

[Tor Bug Tracker & Wiki]

#29078: nyx values do differ from stem native example
--+--
 Reporter:  toralf|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  - Select a component
  Version:  Tor: 0.3.5.7  |   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 I do run 2 Tor relaays at the same hardware at 2 different ports. Netstat
 reports about 12,000 connections.
 Stem 1.7.1 gives:
 {{{
 mr-fox ~ # for p in 9051 29051 ; do python
 /usr/share/doc/stem-1.7.1/_static/example/relay_connections.py --ctrlport
 $p; done
  0.3.5.7   uptime: 08:25:03   flags: Fast, Guard, Running, Stable, V2Dir,
 Valid

 +--+--+--+
 | Type | IPv4 | IPv6 |
 +--+--+--+
 | Inbound to our ORPort| 2777 |6 |
 | Inbound to our DirPort   |3 |0 |
 | Inbound to our ControlPort   |1 |0 |
 | Outbound to a relay  | 3235 |0 |
 | Outbound uncategorized   |8 |0 |
 +--+--+--+
 | Total| 6024 |6 |
 +--+--+--+

  0.3.5.7   uptime: 08:25:05   flags: Fast, Guard, Running, Stable, V2Dir,
 Valid

 +--+--+--+
 | Type | IPv4 | IPv6 |
 +--+--+--+
 | Inbound to our ORPort| 2866 |2 |
 | Inbound to our ControlPort   |2 |0 |
 | Outbound to a relay  | 3447 |0 |
 | Outbound uncategorized   |   16 |0 |
 +--+--+--+
 | Total| 6331 |2 |
 +--+--+--+
 }}}
 whilst nyx 2.0.4 gives:
 {{{
 sudo -u tor /bin/bash -c "/usr/bin/nyx -i 29051"
 ...
 Connections (2853 inbound, 6690 outbound, 1 control):
 }}}
 and
 {{{
 sudo -u tor /bin/bash -c "/usr/bin/nyx -i 9051"
 ...
 Connections (2787 inbound, 6694 outbound, 1 control):
 }}}
 respectively.

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

Re: [tor-bugs] #26889 [Core Tor/Torsocks]: torsocks: option to disable all network traffic

[Tor Bug Tracker & Wiki]

#26889: torsocks: option to disable all network traffic
---+---
 Reporter:  ilf|  Owner:  dgoulet
 Type:  enhancement| Status:
   |  needs_information
 Priority:  Low|  Milestone:
Component:  Core Tor/Torsocks  |Version:
 Severity:  Normal | Resolution:
 Keywords:  torsocks, option, disable network  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by ilf):

 You are absolutely right, quoting
 [https://en.wikipedia.org/wiki/Unix_philosophy the UNIX philosophy]: "Make
 each program do one thing well. To do a new job, build afresh rather than
 complicate old programs by adding new 'features'."

 As I said, "this is a classic job for (application) firewalls, but
 torsocks has all the functionality already".

 Your approach sounds reasonable, although I'm not sure how complicated
 checking that the ephemeral port is actually unused is.

 I'll leave the decision on this to the authors and maintainers.

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

Re: [tor-bugs] #29050 [Core Tor/Torsocks]: Connecting to tor over a socks 5 connection no longer works in 3.5.7

[Tor Bug Tracker & Wiki]

#29050: Connecting to tor over a socks 5 connection no longer works in 3.5.7
---+---
 Reporter:  arj|  Owner:  dgoulet
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Core Tor/Torsocks  |Version:  Tor: 0.3.5.7
 Severity:  Normal | Resolution:
 Keywords:  regression?|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by rl1987):

 * cc: rl1987 (added)


Comment:

 Will look into this in few days.

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

Re: [tor-bugs] #28716 [Applications/Tor Browser]: Create a mingw-w64-clang project

[Tor Bug Tracker & Wiki]

#28716: Create a mingw-w64-clang project
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201901,   |  Actual Points:
  GeorgKoppen201901  |
Parent ID:  #28238   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by watt):

 Replying to [comment:18 tom]:
 Shouldn't clang be built with mingw-w64 headers (and not before)?

 `default_win32_winnt=0x601` - for better threading support.

 (What's up with dxr?)

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

Re: [tor-bugs] #27531 [Applications/Tor Browser]: Tor Browser 8 crashes trying to print on Linux

[Tor Bug Tracker & Wiki]

#27531: Tor Browser 8 crashes trying to print on Linux
-+-
 Reporter:  mikeperry|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-crash, tbb-8.0-issues, tbb-  |  Actual Points:
  regression |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by wert2):

 Jaym was missing a definition for gmpz_limbs_read as evidenced by the
 following error:

 symbol lookup error: /usr/lib/x86_64-linux-gnu/libhogweed.so.4: undefined
 symbol: gmpz_limbs_read

 Today looking more closely above I realized I could get feedback in the
 terminal if I start TBB with Browser/firefox instead of Browser/start-tor-
 browser. So, here's what I get (using Fedora 29 with Gnome 3.30.2):


 {{{
 $ /home//.local/share/torbrowser/tbb/x86_64/tor-browser_en-
 US/Browser/firefox
 Jan 13 08:59:58.883 [notice] Tor 0.3.4.9 (git-4ac3ccf2863b86e7) running on
 Linux with Libevent 2.1.8-stable, OpenSSL 1.0.2q, Zlib 1.2.11, Liblzma
 N/A, and Libzstd N/A.
 Jan 13 08:59:58.883 [notice] Tor can't help you if you use it wrong! Learn
 how to be safe at https://www.torproject.org/download/download#warning
 Jan 13 08:59:58.883 [notice] Read configuration file
 "/home//.local/share/torbrowser/tbb/x86_64/tor-browser_en-
 US/Browser/TorBrowser/Data/Tor/torrc-defaults".
 Jan 13 08:59:58.883 [notice] Read configuration file
 "/home//.local/share/torbrowser/tbb/x86_64/tor-browser_en-
 US/Browser/TorBrowser/Data/Tor/torrc".
 Jan 13 08:59:58.887 [notice] Scheduler type KIST has been enabled.
 Jan 13 08:59:58.887 [notice] Opening Socks listener on 127.0.0.1:9150
 Jan 13 08:59:58.887 [notice] Opening Control listener on 127.0.0.1:9151
 Jan 13 08:59:58.000 [notice] Parsing GEOIP IPv4 file
 /home//.local/share/torbrowser/tbb/x86_64/tor-browser_en-
 US/Browser/TorBrowser/Data/Tor/geoip.
 Jan 13 08:59:58.000 [notice] Parsing GEOIP IPv6 file
 /home//.local/share/torbrowser/tbb/x86_64/tor-browser_en-
 US/Browser/TorBrowser/Data/Tor/geoip6.
 Jan 13 08:59:59.000 [notice] Bootstrapped 0%: Starting
 Jan 13 08:59:59.000 [notice] Starting with guard context "default"
 Jan 13 08:59:59.000 [notice] Bootstrapped 80%: Connecting to the Tor
 network
 Jan 13 08:59:59.000 [notice] New control connection opened from 127.0.0.1.
 Jan 13 08:59:59.000 [notice] New control connection opened from 127.0.0.1.
 154736870   addons.webextension.{73a6fe31-595d-460b-a920-fcc0f8843232}
 WARNLoading extension '{73a6fe31-595d-460b-a920-fcc0f8843232}':
 Reading manifest: Error processing background.persistent: Event pages are
 not currently supported. This will run as a persistent background page.
 154737039   addons.webextension.https-everywhere-...@eff.org
 WARNPlease specify whether you want browser_style or not in your
 browser_action options.
 154737039   addons.webextension.{73a6fe31-595d-460b-a920-fcc0f8843232}
 WARNPlease specify whether you want browser_style or not in your
 browser_action options.
 Jan 13 09:00:00.000 [notice] Bootstrapped 85%: Finishing handshake with
 first hop
 Jan 13 09:00:01.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
 Jan 13 09:00:03.000 [notice] Tor has successfully opened a circuit. Looks
 like client functionality is working.
 Jan 13 09:00:03.000 [notice] Bootstrapped 100%: Done
 Jan 13 09:00:06.000 [notice] New control connection opened from 127.0.0.1.
 Jan 13 09:00:06.000 [notice] New control connection opened from 127.0.0.1.
 JavaScript error: chrome://global/content/browser-child.js, line 359:
 NS_ERROR_NOT_AVAILABLE: Component returned failure code: 0x80040111
 (NS_ERROR_NOT_AVAILABLE) [nsIWebNavigation.loadURIWithOptions]
 JavaScript error: chrome://global/content/browser-child.js, line 359:
 NS_ERROR_NOT_AVAILABLE: Component returned failure code: 0x80040111
 (NS_ERROR_NOT_AVAILABLE) [nsIWebNavigation.loadURIWithOptions]

 (firefox:10865): Gtk-WARNING **: 09:02:27.150: /lib64/libhogweed.so.4:
 undefined symbol: __gmpn_cnd_sub_n

 (firefox:10865): Gtk-WARNING **: 09:02:27.157: /lib64/libhogweed.so.4:
 undefined symbol: __gmpn_cnd_sub_n
 Jan 13 09:02:27.000 [notice] Owning controller connection has closed --
 exiting now.
 Jan 13 09:02:27.000 [notice] Catching signal TERM, exiting cleanly.
 Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close
 with reason=AbnormalShutdown (t=131.831) Segmentation fault (core dumped)
 }}}


 Following traumschule's suggestion with objdump