Re: [tor-bugs] #26764 [Applications/Orbot]: HTTP proxy bug in Orbot 16.0.2-RC-1

[Tor Bug Tracker & Wiki]

#26764: HTTP proxy bug in Orbot 16.0.2-RC-1
+--
 Reporter:  soren@… |  Owner:  n8fr8
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by soren@…):

 I created an issue on the GitHub tracker for this at
 https://github.com/n8fr8/orbot/issues/185.

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

Re: [tor-bugs] #26764 [Applications/Orbot]: HTTP proxy bug in Orbot 16.0.2-RC-1

[Tor Bug Tracker & Wiki]

#26764: HTTP proxy bug in Orbot 16.0.2-RC-1
+--
 Reporter:  soren@… |  Owner:  n8fr8
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by soren@…):

 Looking through the source code for Orbot, I can see that my previous
 comment regarding Android's network security config changes introduced in
 API 28 is not the core of the problem because you are still targeting API
 27.  However, you might want to file it away, because depending on all the
 specifics of your code you might need to use it when you do switch to
 targeting API 28.

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

Re: [tor-bugs] #26764 [Applications/Orbot]: HTTP proxy bug in Orbot 16.0.2-RC-1

[Tor Bug Tracker & Wiki]

#26764: HTTP proxy bug in Orbot 16.0.2-RC-1
+--
 Reporter:  soren@… |  Owner:  n8fr8
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by soren@…):

 Replying to [comment:7 n8fr8]:

 > As for this problem specifically, we moved from using Privoxy inside of
 Orbot as our HTTP proxy, to using the new, built-in HTTP proxy feature now
 available in Tor. Unfortunately, it only supports HTTP Connect proxy
 features, which in the case of Android, seem to only work with HTTPS
 traffic. For most apps, this is fine and a good requirement, to ensure
 traffic moving through Tor is always HTTPS. However, for a browser, which
 may still have HTTP traffic, I see how it can cause problems.

 Thanks for the information.

 > The answer is to just guide your users to use the VPN feature, which
 does work.

 I have been recommending that to users for a while, but that doesn't work
 well in all scenarios.

 https://www.stoutner.com/problems-with-orbot/

 For example, Privacy Browser allows users to quickly toggle proxying
 through Orbot while leaving Orbot connected so that they can access
 resources that are blocked via Tor.  This doesn't work with VPN mode
 enabled, and starting and stopping Orbot takes a lot longer than the quick
 toggle Privacy Browser provides.

 https://redmine.stoutner.com/issues/326

 > You could also consider building your browser from Mozilla's GeckoView
 component, which Firefox Focus uses.

 GeckoView is an interesting project, but it isn't a good fit for Privacy
 Browser.  I have written quite an extensive explanation that is hosted on
 my website.

 https://www.stoutner.com/geckoview/

 The short version is that part of the future of Privacy Browser will be to
 create a rolling fork of Android's WebView called Privacy WebView that
 exposes many more privacy controls that either GeckoView or WebView.
 Privacy WebView will be backwards API compatible with WebView, allowing
 custom ROMs to use it as a drop-in replacement for Android's WebView.
 This is something that is not possible with !GeckoView.

 > This supports SOCKS proxying, which works very well with Tor, and is
 much more secure than relying on Android's WebView.

 SOCKS proxying support is a nice feature, but Privacy WebView will provide
 a more secure web experience that I can see anywhere on the horizon for
 !GeckoView.

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

Re: [tor-bugs] #28921 [Core Tor/Stem]: tor-prompt command 'GETINFO desc/all-recent > /dev/null' fails

[Tor Bug Tracker & Wiki]

#28921: tor-prompt command 'GETINFO desc/all-recent > /dev/null' fails
---+---
 Reporter:  wagon  |  Owner:  atagar
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  descriptor |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by atagar):

 Hi wagon. What python interpreter version are you using.

 > because IP addresses in annotations @source are guard nodes your Tor
 uses

 Gotcha. From what I understand those aren't particularly sensitive (guard
 status is public, and that a particular person had one in their pool isn't
 terribly interesting). That said, no harm in scrubbing it too. Stem
 doesn't care about those file annotations.

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

Re: [tor-bugs] #28873 [Applications/Tor Browser]: Cascading of permissions does not seem to work properly in Tor Browser 8

[Tor Bug Tracker & Wiki]

#28873: Cascading of permissions does not seem to work properly in Tor Browser 8
-+-
 Reporter:  gk   |  Owner:  ma1
 Type:  defect   | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  noscript, tbb-security, tbb- |  Actual Points:
  torbutton, tbb-8.0-issues, tbb-regression, |
  TorBrowserTeam201812R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by ma1):

 * status:  needs_review => needs_information


Comment:

 An afterthough: some users are complaining that having TRUSTED subframes
 constrained by DEFAULT/UNTRUSTED parent document is annoying, if not
 disfunctional: for instance if you've set Youtube to TRUSTED, embedded
 movies used to work without the need of raising privileges of the parent
 page. One may object that you could always use "show only this frame", but
 do we really have a strong case here for cascading inline restrictions to
 trusted subdocuments? What's the threat model we're guarding against
 (beside clickjacking, which is orthogonal to scripting though)?

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

Re: [tor-bugs] #28142 [Core Tor/Tor]: Merge original WTF-PAD branch

[Tor Bug Tracker & Wiki]

#28142: Merge original WTF-PAD branch
-+-
 Reporter:  asn  |  Owner:
 |  mikeperry
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding|
Parent ID:  #28631   | Points:
 Reviewer:  asn  |Sponsor:
 |  Sponsor2
-+-

Comment (by mikeperry):

 Ok I did a couple tweaks:

  * ensure that when negotiation fails, we dont try again
  * change the size of circpad_hist_token_t

 I then pushed https://github.com/torproject/tor/pull/623.

 I think this is ready for review, though could use a squash.

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

Re: [tor-bugs] #10416 [Core Tor/Tor]: Tor won't start on Windows when path contains non-ascii characters

[Tor Bug Tracker & Wiki]

#10416: Tor won't start on Windows when path contains non-ascii characters
-+-
 Reporter:  iktsuarpok   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.3.25
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, windows, unicode, win32  |  Actual Points:
Parent ID:  #25729   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks2):

 Simple detector for tor-launcher
 {{{
 diff --git a/src/components/tl-process.js b/src/components/tl-process.js
 index 3aa45e4..e12e523 100644
 --- a/src/components/tl-process.js
 +++ b/src/components/tl-process.js
 @@ -355,6 +355,7 @@ TorProcessService.prototype =
mLastTorWarningPhase: null,
mLastTorWarningReason: null,
mDefaultPreferencesAreLoaded: false,
 +  mWindowsCodePageWrong: false,

// Private Methods
 /
_startTor: function(aForceDisableNetwork)
 @@ -510,6 +511,12 @@ TorProcessService.prototype =
  if (env.exists("PATH"))
path += ";" + env.get("PATH");
  env.set("PATH", path);
 +var check = env.get("PATH");
 +if (path != check) {
 +   this.mWindowsCodePageWrong = true;
 +   var s =
 TorLauncherUtil.getLocalizedString("wrong_windows_codepage")
 +   this._notifyUserOfError(s, null,
 this.kTorProcessDidNotStartTopic);
 +}
}

this.mTorProcessStatus = this.kStatusStarting;
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28956 [Internal Services/Service - github tpo]: Github nyx repository

[Tor Bug Tracker & Wiki]

#28956: Github nyx repository
+--
 Reporter:  atagar  |  Owner:  hiro
 Type:  defect  | Status:  new
 Priority:  Low |  Milestone:
Component:  Internal Services/Service - github tpo  |Version:
 Severity:  Minor   |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+--
 Hi lovely github admin folks. Could we please set
 [https://gitweb.torproject.org/nyx.git/ Nyx] up to have a tpo github
 mirror, similar to [https://github.com/torproject/stem Stem]?

 Thanks!

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

Re: [tor-bugs] #28955 [Applications/Orbot]: should Orbot include DNS forwarder backed by DNS-over-TLS

[Tor Bug Tracker & Wiki]

#28955: should Orbot include DNS forwarder backed by DNS-over-TLS
+---
 Reporter:  eighthave   |  Owner:  n8fr8
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---

Comment (by eighthave):

 I should add that in the past, I thought this wasn't worth the complexity.
 But now with DNS-over-TLS, I think its worth considering.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28955 [Applications/Orbot]: should Orbot include DNS forwarder backed by DNS-over-TLS

[Tor Bug Tracker & Wiki]

#28955: should Orbot include DNS forwarder backed by DNS-over-TLS
---+
 Reporter:  eighthave  |  Owner:  n8fr8
 Type:  defect | Status:  new
 Priority:  Medium |  Component:  Applications/Orbot
  Version: |   Severity:  Normal
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
 DNS-over-TLS (DoT) is now available on many nameservers, and at least
 three, large public ones 9.9.9.9, 8.8.8.8, and 1.1.1.1.  DoT plugs a
 significant metadata leak: the domain in plain text.  Starting in Android
 9, Android itself supports DoT.  Should Orbot itself include a DNS server
 that uses only DoT?

 If yes, then here is some related example code:
 https://github.com/gryphius/androdns

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

Re: [tor-bugs] #24215 [Applications/Orbot]: Use Tor's built-in HTTP proxy instead of polipo. Remove Polipo from Orbot. Comment from other cypherpunks: current Orbot version does, but in about orbot po

[Tor Bug Tracker & Wiki]

#24215: Use Tor's built-in HTTP proxy instead of polipo. Remove Polipo from 
Orbot.
Comment from other cypherpunks: current Orbot version does, but in about
orbot popup it still reads polipo! but httptunnelport is bound
+---
 Reporter:  cypherpunks |  Owner:  n8fr8
 Type:  task| Status:  new
 Priority:  Very High   |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
Changes (by eighthave):

 * cc: eighthave (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] #28954 [Core Tor/Tor]: fuzz-descriptor aborts with a crash

[Tor Bug Tracker & Wiki]

#28954: fuzz-descriptor aborts with a crash
-+--
 Reporter:  toralf   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  Core Tor/Tor
  Version:  Tor: 0.3.5.6-rc  |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 With recent Tor (tor-0.3.5.3-alpha-727-g99713b176) the command
 {{{
 /usr/bin/afl-fuzz -i /home/torproject/tor-fuzz-corpora/descriptor -o tmp/
 -m 45 -- /home/torproject/tor/src/test/fuzz/fuzz-descriptor
 }}}
 gives an
 {{{
 [-] Oops, the program crashed with one of the test cases provided. There
 are
 several possible explanations:

 - The test case causes known crashes under normal working conditions.
 If
   so, please remove it. The fuzzer should be seeded with interesting
   inputs - but not ones that cause an outright crash.

 - The current memory limit (45.0 MB) is too low for this program,
 causing
   it to die due to OOM when parsing valid files. To fix this, try
   bumping it up with the -m setting in the command line. If in doubt,
   try something along the lines of:

   ( ulimit -Sv $[44 << 10]; /path/to/binary [...] http://jwilk.net/software/recidivm to quickly
   estimate the required amount of virtual memory for the binary. Also,
   if you are using ASAN, see
 /usr/share/doc/afl-2.52b/notes_for_asan.txt.

 - Least likely, there is a horrible bug in the fuzzer. If other
 options
   fail, poke  for troubleshooting tips.

 [-] PROGRAM ABORT : Test case
 
'id:000153,orig:2136185e394ee1b2b4b9336ec365ac0c0dd5f2ac53065272591d3bb31375d568'
 results in a crash
  Location : perform_dry_run(), afl-fuzz.c:2852

 }}}
 despite that recidivm marks a value of "45" as ok:
 {{{
 $ ../recidivm/recidivm -v -u M ./src/test/fuzz/fuzz-descriptor
 recidivm: 35184372088832 -> ok
 recidivm: 17592186044416 -> ok
 recidivm: 8796093022208 -> ok
 recidivm: 4398046511104 -> ok
 recidivm: 219902322 -> ok
 recidivm: 1099511627776 -> ok
 recidivm: 549755813888 -> ok
 recidivm: 274877906944 -> ok
 recidivm: 137438953472 -> ok
 recidivm: 68719476736 -> ok
 recidivm: 34359738368 -> ok
 recidivm: 17179869184 -> ok
 recidivm: 8589934592 -> ok
 recidivm: 4294967296 -> ok
 recidivm: 2147483648 -> ok
 recidivm: 1073741824 -> ok
 recidivm: 536870912 -> ok
 recidivm: 268435456 -> ok
 recidivm: 134217728 -> ok
 recidivm: 67108864 -> ok
 recidivm: 33554432 -> exit status 127
 recidivm: 50331648 -> ok
 recidivm: 41943040 -> exit status 127
 recidivm: 46137344 -> exit status 127
 recidivm: 48234496 -> ok
 recidivm: 47185920 -> ok
 45
 }}}
 With "55" the fuzzer proceeds.
 FWIW:
 {{{
 ~/recidivm $ git describe
 0.1.4-30-g844edc0
 torproject@mr-fox ~/recidivm $
 }}}
 and
 {{{
 $ gcc -v
 Using built-in specs.
 COLLECT_GCC=gcc
 COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/lto-wrapper
 Target: x86_64-pc-linux-gnu
 Configured with: /var/tmp/portage/sys-
 devel/gcc-7.3.0-r3/work/gcc-7.3.0/configure --host=x86_64-pc-linux-gnu
 --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-
 gnu/gcc-bin/7.3.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-
 gnu/7.3.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.3.0
 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.3.0/man
 --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.3.0/info --with-gxx-
 include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/g++-v7 --with-
 python-dir=/share/gcc-data/x86_64-pc-linux-gnu/7.3.0/python --enable-
 languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
 --with-system-zlib --enable-nls --without-included-gettext --enable-
 checking=release --with-bugurl=https://bugs.gentoo.org/ --with-
 pkgversion='Gentoo Hardened 7.3.0-r3 p1.4' --enable-esp --enable-
 libstdcxx-time --disable-libstdcxx-pch --enable-shared --enable-
 threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-
 multilib --with-multilib-list=m64 --disable-altivec --disable-fixed-point
 --enable-targets=all --enable-libgomp --disable-libmudflap --disable-
 libssp --disable-libcilkrts --disable-libmpx --enable-vtable-verify
 --enable-libvtv --disable-libquadmath --enable-lto --without-isl
 --disable-libsanitizer --enable-default-pie --enable-default-ssp
 Thread model: posix
 gcc version 7.3.0 (Gentoo Hardened 7.3.0-r3 p1.4)

 }}}

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

Re: [tor-bugs] #16982 [Applications/Tor Browser]: Resizing Tor Browser only issues warning if maximized fully

[Tor Bug Tracker & Wiki]

#16982: Resizing Tor Browser only issues warning if maximized fully
---+--
 Reporter:  cypherpunks|  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-fingerprinting-resolution  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by ArenaL5):

 Tor Browsers only issues a warning you if the window is maximized while
 it's running. If the window manager overrides the window size before
 running, there is no warning either.

 This has happened. Awesome is a tiling window manager. In some settings,
 windows fill the whole screen without being tehcnically "maximized", and
 [https://github.com/awesomeWM/awesome/pull/2505 they're programming an
 exception for Tor Browser] so it will retain its default window size.

 The same happens if you use a window manager add-on to resize windows to
 preset sizes, like gTile for Ubuntu. Even if you resize the window to fill
 the whole screen, it counts as "manually resized" and, thus, "not
 maximized".

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

Re: [tor-bugs] #28937 [Applications/Tor Browser]: Tor Browser 8.0.4 only warns the user if it's MAXIMIZED, WHILE it's running.

[Tor Bug Tracker & Wiki]

#28937: Tor Browser 8.0.4 only warns the user if it's MAXIMIZED, WHILE it's
running.
--+--
 Reporter:  ArenaL5   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  Tor Browser, screen size  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by ArenaL5):

 My apologies. This is a duplicate of #16982, will close ticket 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] #28937 [Applications/Tor Browser]: Tor Browser 8.0.4 only warns the user if it's MAXIMIZED, WHILE it's running.

[Tor Bug Tracker & Wiki]

#28937: Tor Browser 8.0.4 only warns the user if it's MAXIMIZED, WHILE it's
running.
--+---
 Reporter:  ArenaL5   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  Tor Browser, screen size  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by ArenaL5):

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


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

Re: [tor-bugs] #28921 [Core Tor/Stem]: tor-prompt command 'GETINFO desc/all-recent > /dev/null' fails

[Tor Bug Tracker & Wiki]

#28921: tor-prompt command 'GETINFO desc/all-recent > /dev/null' fails
---+---
 Reporter:  wagon  |  Owner:  atagar
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  descriptor |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by wagon):

 Replying to [comment:3 atagar]:
 > Hi wagon. This is odd, I'm having difficulty reproducing that
 stacktrace. Non-ascii content appears on the contact lines but this is
 normal and stem accounts for this...
 >
 > {{{
 > grep -P "[\x80-\xFF]" cached-descriptors
 > }}}
 Your grep doesn't catch all non-ascii characters. For example, I tried
 [[https://stackoverflow.com/questions/14567745/detect-russian-characters-
 with-grep|this suggestion]] and found the following:
 {{{
 $ grep -E "[А-Яа-яЁё]" cached-descriptors
 contact ++Питер++ c.m.i(at)mail.ru++ hkp://keyserver.ubuntu.com:11371
 ++ Bitcoin?  153gfzos233LcSnJpDF5u3q76iVAACwTAd
 }}}
 I have no idea what are the characters which results to error.

 > I tried parsing this through stem and printing the output with both
 python 2.7 and 3.5 but couldn't repro that stacktrace. Are you using the
 copy of stem from git? If not then please give that a whirl.
 I used
 [[http://trac.torproject.org/projects/tor/ticket/28332#comment:7|this git
 version]]. Now I've found another interesting observation. `tor-prompt`
 from 1.6.0 (release) doesn't have this problem.

 > There are no privacy issues with this file. It's just cached descriptor
 content. Everyone receives the same and each hours descriptors are
 publicly available on CollecTor.
 There are privacy issues with this file, because IP addresses in
 annotations `@source` are guard nodes your Tor uses. I don't think it is
 safe to tell everybody which guard nodes you are using 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] #26764 [Applications/Orbot]: HTTP proxy bug in Orbot 16.0.2-RC-1

[Tor Bug Tracker & Wiki]

#26764: HTTP proxy bug in Orbot 16.0.2-RC-1
+---
 Reporter:  soren@… |  Owner:  n8fr8
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---

Comment (by n8fr8):

 For now, the best place for submitted issues is:
 https://github.com/n8fr8/orbot/issues

 We are working on consolidating and cleaning up our various trackers. We
 are happy to work here on trac, but the volume of notifications and the
 fact we don't use this as our core tracker can cause us to miss issues now
 and then.

 As for this problem specifically, we moved from using Privoxy inside of
 Orbot as our HTTP proxy, to using the new, built-in HTTP proxy feature now
 available in Tor. Unfortunately, it only supports HTTP Connect proxy
 features, which in the case of Android, seem to only work with HTTPS
 traffic. For most apps, this is fine and a good requirement, to ensure
 traffic moving through Tor is always HTTPS. However, for a browser, which
 may still have HTTP traffic, I see how it can cause problems.

 The answer is to just guide your users to use the VPN feature, which does
 work. You could also consider building your browser from Mozilla's
 GeckoView component, which Firefox Focus uses. This supports SOCKS
 proxying, which works very well with Tor, and is much more secure than
 relying on Android's WebView.

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

Re: [tor-bugs] #26764 [Applications/Orbot]: HTTP proxy bug in Orbot 16.0.2-RC-1

[Tor Bug Tracker & Wiki]

#26764: HTTP proxy bug in Orbot 16.0.2-RC-1
+--
 Reporter:  soren@… |  Owner:  n8fr8
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by n8fr8):

 * status:  new => assigned


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

Re: [tor-bugs] #19966 [Core Tor/Tor]: torproxy goes south with more than 1 connection attempt per second to a hidden service

[Tor Bug Tracker & Wiki]

#19966: torproxy goes south with more than 1 connection attempt per second to a
hidden service
-+-
 Reporter:  Alan |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.6
 Severity:  Major| Resolution:  user
 Keywords:  tor-hs, regression, triage-  |  disappeared
  out-030-201612 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by damiengray):

 If I initiate onion service connections too rapidly, I see the same error
 progression:

 {{{
 Dec {redacted} [notice] We'd like to launch a circuit to handle a
 connection, but we already have {redacted} general-purpose client circuits
 pending. Waiting until some finish.
 Dec {redacted} [warn] Fetching v2 rendezvous descriptor failed. Retrying
 at another directory.
 Dec {redacted} [warn] Fetching v2 rendezvous descriptor failed. Retrying
 at another directory.
 Dec {redacted} [warn] Fetching v2 rendezvous descriptor failed. Retrying
 at another directory.
 Dec {redacted} [notice] Closing stream for '[scrubbed].onion': hidden
 service is unavailable (try again later).
 Dec {redacted} [notice] Closing stream for '[scrubbed].onion': hidden
 service is unavailable (try again later).
 Dec {redacted} [notice] Tried for 120 seconds to get a connection to
 [scrubbed]:{redacted}. Giving up. (waiting for rendezvous desc)
 Dec {redacted} [notice] Tried for 120 seconds to get a connection to
 [scrubbed]:{redacted}. Giving up. (waiting for rendezvous desc)
 }}}

 I am using Tor version 0.3.4.9 (git-074ca2e0054fded1).

 Is there any fix for this, other than limiting the connection rate?

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

Re: [tor-bugs] #28616 [Core Tor/Tor]: TLS internal error running Tor 0.3.4.9 on Debian Buster (OpenSSL 1.1.1a)

[Tor Bug Tracker & Wiki]

#28616: TLS internal error running Tor 0.3.4.9 on Debian Buster (OpenSSL 1.1.1a)
--+
 Reporter:  filippo   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by Big):

 It would be indeed important that there will be a fixed release, or Debian
 Buster will go stable with this bug and this will shift from only some
 relays are affected to realy many.

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

Re: [tor-bugs] #28142 [Core Tor/Tor]: Merge original WTF-PAD branch

[Tor Bug Tracker & Wiki]

#28142: Merge original WTF-PAD branch
-+-
 Reporter:  asn  |  Owner:
 |  mikeperry
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding|
Parent ID:  #28631   | Points:
 Reviewer:  asn  |Sponsor:
 |  Sponsor2
-+-

Comment (by asn):

 Hey Mike,

 I reviewed your latest `adaptive_padding-20181218-rebased` and it looks
 great! On this note I took your branch and did the following changes:
 - Tested the unittests for memleaks with ASAN (all good).
 - Disabled the current machines
 and also rebased it to latest master (so that CI runs) and made a PR out
 of it: https://github.com/torproject/tor/pull/622

 Let me know what else there is to do. Otherwise, we should make a squashed
 version of this branch for the final review and merge by Nick. I can do
 the squash no problem.

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