Re: [tor-bugs] #29454 [HTTPS Everywhere/EFF-HTTPS Everywhere]: Updates of HTTPS-Everywhere we ship do not seem to update the rulesets

[Tor Bug Tracker & Wiki]

#29454: Updates of HTTPS-Everywhere we ship do not seem to update the rulesets
-+-
 Reporter:  gk   |  Owner:  legind
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:8 legind]:
 > > Yes, but lying in the sense that the date is wrong as in the bug
 report. The user opened an old Tor Browser, updated and was confused that
 the *old date* was still shown in the display suggesting that the rules
 from that date were used while the update brought a new HTTPS-Everywhere
 version with the new rules. I think the expected behavior would be: show
 the date of applied rulesets either those that got downloaded (as is the
 case now) OR those that we got by a new HTTPS Everywhere version (which is
 not happening right now). The request on start-up might not get through
 for whatever reason...
 >
 > To avoid the problem of old rulesets still applying even when a new
 extension version is released, the simplest thing to do is probably to
 just clear the out-of-band rulesets from storage upon first load of any
 new version.  This will ensure that the extension-bundled rulesets are
 used upon each extension upgrade.  How does this sound?

 Sounds good to me. What happens to the shown date after "Rulesets version
 for EFF (full)" in that case? I guess, ideally, it would reflect the
 extension release date as that's the date of the active rulesets (until a
 new out-of-band ruleset update happens).

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

Re: [tor-bugs] #28897 [Core Tor/sbws]: Stop running twice destination usability tests

[Tor Bug Tracker & Wiki]

#28897: Stop running twice destination usability tests
---+---
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID:  #28663 | Points:
 Reviewer:  teor   |Sponsor:
---+---
Changes (by juga):

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


Comment:

 Thanks, merged.

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

Re: [tor-bugs] #29299 [Core Tor/sbws]: Include scanner country and Web server country in the bandwidth file header

[Tor Bug Tracker & Wiki]

#29299: Include scanner country and Web server country in the bandwidth file 
header
---+---
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:  1
 Reviewer:  catalyst   |Sponsor:
---+---
Changes (by juga):

 * status:  needs_revision => needs_review


Comment:

 Thanks, addressed your comments.

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

Re: [tor-bugs] #29585 [Core Tor/Tor]: Intermittent test failures in dir/dirserv_read_measured_bandwidths

[Tor Bug Tracker & Wiki]

#29585: Intermittent test failures in dir/dirserv_read_measured_bandwidths
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:  Tor:
  |  unspecified
 Severity:  Normal| Resolution:
 Keywords:  tor-ci, tor-test, tor-bwauth  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by juga):

 Replying to [comment:5 teor]:
 > Unstable tests can fail, even if there are no changes to any code run by
 that test.

 what is an unstable test?

 > Is there an obvious error in dirserv_read_measured_bandwidths that
 caused the failure?

 No, but let me try to explain what i see in case helps you to come out
 with an explanation.

 The test [0] that is failing is testing a bandwidth file with only the
 timestamp and a new line.
 `dirserv_read_measured_bandwidths` should parse the timestamp correctly
 and assign `bw_file_headers` returning 0.

 It could return -1 instead of 0 in case:
 - Can't open the bandwidth file
 - The bandwidth file is empty
 - The timestamp line doesn't end with new line
 - The timestamp can't be parsed as integer
 - The timestamp is old
 All of this is initialized in the test, and in theory, correctly. And if
 it's not, should then fail all the times.
 I can only think on `write_str_to_file` not writing the file because of
 some temporal problem in the filesystem. Could be that in your case?.
 Or i didn't realize else.
 [0]
 https://github.com/nmathewson/tor/blob/bug29541/src/test/test_dir.c#L1802

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

Re: [tor-bugs] #29510 [Applications/Tor Browser]: Check reproducibility of the build of 8.5a8

[Tor Bug Tracker & Wiki]

#29510: Check reproducibility of the build of 8.5a8
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  closed
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by boklm):

 pospeselr mentioned his build was matching, except the `mar-tools-
 mac64.zip` file.

 I uploaded there the `mar-tools-mac64.zip` he sent me:
 https://people.torproject.org/~boklm/bug_29510/mar-tools-mac64.zip

 And the diff from diffoscope:
 https://people.torproject.org/~boklm/bug_29510/mar-tools.diff

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

Re: [tor-bugs] #26323 [Applications/Tor Browser]: Build 32bit Linux bundles on 64bit systems

[Tor Bug Tracker & Wiki]

#26323: Build 32bit Linux bundles on 64bit systems
---+--
 Reporter:  gk |  Owner:  tbb-team
 Type:  task   | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201902  |  Actual Points:
Parent ID:  #26468 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by boklm):

 Replying to [comment:12 dcf]:
 > Replying to [comment:10 boklm]:
 > > This is fixed by adding an `export CGO_ENABLED=1`. It seems that cgo
 is enabled by default, except when cross-compiling, which is the case when
 we build for linux-i686 on linux-x86_64, so the build of `go-webrtc` was
 missing the cgo parts.
 > >
 > > I am not sure if we should add this `export CGO_ENABLED=1` to
 `var/setup` in `projects/go/config`, so that it applies to all go
 projects, or add it only in `projects/go-webrtc/config` and
 `projects/snowflake/config`.
 >
 > I think either way should work. It is probably sufficient to set
 `CGO_ENABLED=1` only in the projects that use Cgo, but I don't know any
 disadvantages to keeping to always set.

 Thanks! If there is no known disadvantages to keeping it always set, then
 I think it's easier to just set it in one place.

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

Re: [tor-bugs] #28329 [Applications/Tor Browser]: Design TBA+Orbot configuration UI/UX

[Tor Bug Tracker & Wiki]

#28329: Design TBA+Orbot configuration UI/UX
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, ux-team, TBA-a3, |  Actual Points:
  TorBrowserTeam201902   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by gk):

 * keywords:  tbb-mobile, ux-team, TBA-a3, TorBrowserTeam201902R => tbb-
 mobile, ux-team, TBA-a3, TorBrowserTeam201902
 * status:  needs_review => needs_revision


Comment:

 Okay, thanks for this. The UI looks nice. I have some issues, though,
 getting this to run properly in the first place. Here is the build I used
 for testing:

 https://people.torproject.org/~gk/testbuilds/tor-browser-tbb-nightly-
 android-armv7-multi-qa-28329.apk
 https://people.torproject.org/~gk/testbuilds/tor-browser-tbb-nightly-
 android-armv7-multi-qa-28329.apk.asc

 It's based on `tor-browser-build`'s `master` branch pointing the Firefox
 project to my `bug_28329_test`.

 If I press the Connect button the app is crashing with OOM errors (I
 restarted my Samsung Galaxy S5 mini, no dice):
 {{{
 02-27 10:40:50.210  5350  5350 E GeckoCrashHandler:
 java.lang.OutOfMemoryError: Failed to allocate a 795676 byte allocation
 with 266048 free bytes and 259KB until OOM
 02-27 10:40:50.210  5350  5350 E GeckoCrashHandler: at
 dalvik.system.VMRuntime.newNonMovableArray(Native Method)
 02-27 10:40:50.210  5350  5350 E GeckoCrashHandler: at
 android.graphics.BitmapFactory.nativeDecodeAsset(Native Method)
 02-27 10:40:50.210  5350  5350 E GeckoCrashHandler: at
 android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:856)
 02-27 10:40:50.210  5350  5350 E GeckoCrashHandler: at
 android.graphics.BitmapFactory.decodeResourceStream(BitmapFactory.java:675)
 02-27 10:40:50.210  5350  5350 E GeckoCrashHandler: at
 android.graphics.drawable.Drawable.createFromResourceStream(Drawable.java:2230)
 02-27 10:40:50.210  5350  5350 E GeckoCrashHandler: at
 android.content.res.Resources.loadDrawableForCookie(Resources.java:4282)
 02-27 10:40:50.210  5350  5350 E GeckoCrashHandler: at
 android.content.res.Resources.loadDrawable(Resources.java:4156)
 02-27 10:40:50.210  5350  5350 E GeckoCrashHandler: at
 android.content.res.Resources.loadDrawable(Resources.java:4006)
 02-27 10:40:50.210  5350  5350 E GeckoCrashHandler: at
 android.content.res.TypedArray.getDrawable(TypedArray.java:886)
 02-27 10:40:50.210  5350  5350 E GeckoCrashHandler: at
 
android.graphics.drawable.AnimationDrawable.inflateChildElements(AnimationDrawable.java:324)
 02-27 10:40:50.210  5350  5350 E GeckoCrashHandler: at
 android.graphics.drawable.AnimationDrawable.inflate(AnimationDrawable.java:294)
 02-27 10:40:50.210  5350  5350 E GeckoCrashHandler: at
 android.graphics.drawable.Drawable.createFromXmlInner(Drawable.java:2551)
 02-27 10:40:50.210  5350  5350 E GeckoCrashHandler: at
 android.graphics.drawable.Drawable.createFromXml(Drawable.java:2322)
 02-27 10:40:50.210  5350  5350 E GeckoCrashHandler: at
 android.content.res.Resources.loadDrawableForCookie(Resources.java:4277)
 02-27 10:40:50.210  5350  5350 E GeckoCrashHandler: at
 android.content.res.Resources.loadDrawable(Resources.java:4156)
 02-27 10:40:50.210  5350  5350 E GeckoCrashHandler: at
 android.content.res.Resources.getDrawable(Resources.java:2045)
 02-27 10:40:50.210  5350  5350 E GeckoCrashHandler: at
 android.content.res.Resources.getDrawable(Resources.java:2027)
 02-27 10:40:50.210  5350  5350 E GeckoCrashHandler: at
 
android.support.v7.widget.ResourcesWrapper.getDrawable(ResourcesWrapper.java:133)
 02-27 10:40:50.210  5350  5350 E GeckoCrashHandler: at
 android.content.Context.getDrawable(Context.java:464)
 02-27 10:40:50.210  5350  5350 E GeckoCrashHandler: at
 android.view.View.setBackgroundResource(View.java:18598)
 02-27 10:40:50.210  5350  5350 E GeckoCrashHandler: at
 
android.support.v7.widget.AppCompatImageView.setBackgroundResource(AppCompatImageView.java:76)
 02-27 10:40:50.210  5350  5350 E GeckoCrashHandler: at
 
org.mozilla.gecko.torbootstrap.TorBootstrapPanel.startBootstrapping(TorBootstrapPanel.java:175)
 02-27 10:40:50.210  5350  5350 E GeckoCrashHandler: at
 
org.mozilla.gecko.torbootstrap.TorBootstrapPanel.access$000(TorBoots

Re: [tor-bugs] #29510 [Applications/Tor Browser]: Check reproducibility of the build of 8.5a8

[Tor Bug Tracker & Wiki]

#29510: Check reproducibility of the build of 8.5a8
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  closed
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by boklm):

 Replying to [comment:2 boklm]:
 > pospeselr mentioned his build was matching, except the `mar-tools-
 mac64.zip` file.
 >
 > I uploaded there the `mar-tools-mac64.zip` he sent me:
 > https://people.torproject.org/~boklm/bug_29510/mar-tools-mac64.zip
 >
 > And the diff from diffoscope:
 > https://people.torproject.org/~boklm/bug_29510/mar-tools.diff

 GeKo mentioned on IRC that this diff is caused by #28102.

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

Re: [tor-bugs] #28481 [Core Tor/Tor]: Tor's startup time is getting slower on Android

[Tor Bug Tracker & Wiki]

#28481: Tor's startup time is getting slower on Android
-+-
 Reporter:  akwizgran|  Owner:  nickm
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.4.9
 Severity:  Normal   | Resolution:
 Keywords:  android startup performance  |  Actual Points:
  controller |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by akwizgran):

 Things aren't looking quite as good on Android. 0.4.0 performs much better
 than 0.3.4, but not as well as 0.2.9:

 ||= Tor version =||= Min =||= Max =||
 ||0.2.9.16||3.2||5.1||
 ||0.3.4.8||16.7||20.3||
 ||0.3.5.8||13.8||14.1||
 ||0.4.0.2-alpha||11.3||12.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] #29120 [Applications/Tor Browser]: Default value of media.cache_size (0) causes some media to load extremely slowly or become unplayable

[Tor Bug Tracker & Wiki]

#29120: Default value of media.cache_size (0) causes some media to load 
extremely
slowly or become unplayable
-+-
 Reporter:  QZw2aBQoPyuEVXYVlBps |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-disk-leak, tbb-usability-|  Actual Points:
  website, TorBrowserTeam201902R |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 mcs/brade can you have a (second) look on the latest patch? 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] #28102 [Applications/Tor Browser]: Make sure we pick the exact same compile environment for Tor Browser builds

[Tor Bug Tracker & Wiki]

#28102: Make sure we pick the exact same compile environment for Tor Browser 
builds
---+--
 Reporter:  gk |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201811  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by boklm):

 Replying to [comment:1 boklm]:
 > I can think about the following ways to fix that:
 > - specify exactly the versions of the packages we need, when we know
 that this package can cause reproducibility issues. For example we could
 make the firefox build on macOS require `gcc-49=4.9.2-10+deb8u1`. The
 problem is that any package update could cause such issue, and it can take
 time until we notice it. With complex package such as gcc, with many
 dependencies, the list of packages for which we need to specify the
 version might be long.
 > - add a container image version number. We can then increase this number
 when we need to invalidate old containers after we found that an update is
 causing a reproducibility issue. Like the first option, this means that we
 only fix the issues after finding them, and the previous releases can
 become unreproducible.
 > - use snapshots.debian.org to only install package updates that were
 available on a specific date. I think the main problem would be that
 changing the selected date would cause everything to be rebuilt, but that
 might be ok if we don't do it too often.

 An other way to fix this could be to not use the system's gcc to build
 firefox, but our own build of gcc. We are already doing that for the
 Windows build, and could maybe share the gcc build as both are based on
 jessie.

 However this would not help if other package updates cause the same kind
 of issues.

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

Re: [tor-bugs] #28685 [Applications/Tor Browser]: Tor Browser for Android needs a more dynamic Build ID

[Tor Bug Tracker & Wiki]

#28685: Tor Browser for Android needs a more dynamic Build ID
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, TBA-a3, |  Actual Points:
  TorBrowserTeam201902   |
Parent ID:  #28708   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by gk):

 * keywords:  tbb-mobile, tbb-rbm, TBA-a3, TorBrowserTeam201902R => tbb-
 mobile, tbb-rbm, TBA-a3, TorBrowserTeam201902
 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:10 boklm]:
 > I pushed a patch in branch `bug_28685_v3` using the Tor Browser version
 to compute a `MOZ_BUILD_DATE`, instead of the firefox version:
 > https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_28685_v3&id=9d6d3f15319cfaf2efdf5677e1e2e9cce022e509
 >
 > With Tor Browser 8.0.6 and Firefox 60.4.0, the build id was
 20190204050101.
 >
 > With this change the build id would be:
 > {{{
 > $ ./projects/firefox/get-moz-build-date 2019 8.0.7
 > export MOZ_BUILD_DATE=20190302080101
 > $ ./projects/firefox/get-moz-build-date 2019 8.5a9
 > export MOZ_BUILD_DATE=20190306100101
 > $ ./projects/firefox/get-moz-build-date 2019 8.5a10
 > export MOZ_BUILD_DATE=20190306110101
 > $ ./projects/firefox/get-moz-build-date 2019 8.5
 > export MOZ_BUILD_DATE=20190307010101
 > $ ./projects/firefox/get-moz-build-date 2019 8.5.1
 > export MOZ_BUILD_DATE=20190307020101
 > }}}

 We shipped 8.0.6 with 60.5.1esr, no? It seems we should adapt the comment
 in the script accordingly.

 The new scheme makes the calculation save until Tor Browser 18, if I see
 this correctly. That's okay for 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] #29221 [Core Tor/Tor]: Tooling to track code-style/best-practices violations

[Tor Bug Tracker & Wiki]

#29221: Tooling to track code-style/best-practices violations
+--
 Reporter:  nickm   |  Owner:  (none)
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  network-team-roadmap-2019-Q1Q2  |  Actual Points:
Parent ID:  | Points:  3
 Reviewer:  |Sponsor:
|  Sponsor31-can
+--
Changes (by asn):

 * status:  new => needs_review


Comment:

 Initial PoC posted in https://github.com/asn-d6/tor/tree/bug29221_draft

 Needs further work based on the TODO in practracker.py.

 Would like some feedback from Nick on how this looks.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29607 [- Select a component]: Need urgent help!

[Tor Bug Tracker & Wiki]

#29607: Need urgent help!
---+--
 Reporter:  pidgin |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Immediate  |  Component:  - Select a component
  Version: |   Severity:  Normal
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 Dear tor team,
 We have setup a discussion board, on the tor network.
 And there is someone that is exploiting within our servers, by taking it
 down it every time and the forums will respond with "Server not found".
 We are pretty sure this problem is on the side of the TOR browser, is
 there anything we could do to sort this?
 With many thanks for taking time into reading this.

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

[tor-bugs] #29608 [Webpages/Website]: Sponsors Page Update

[Tor Bug Tracker & Wiki]

#29608: Sponsors Page Update
--+--
 Reporter:  bekeela   |  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 On this page https://lektor-
 staging.torproject.org/tpo/staging/about/sponsors/

 in the Past Sponsors section, please change

  * [https://lektor-staging.torproject.org/tpo/staging/about/sponsors/ An
 anonymous North American NGO] - 2008-2013

 to Internews - 2008-2013

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

Re: [tor-bugs] #29607 [- Select a component]: Need urgent help!

[Tor Bug Tracker & Wiki]

#29607: Need urgent help!
--+
 Reporter:  pidgin|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by pidgin):

 Some server sided info below :

 onionbalance is active
 vanguard is active
 vanguard tor process is at 5%
 serving tor process is at 5%

 attacker has found a way to DDOS not based on tor cpu usage attack or tor
 traffic exhaust attack.

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

Re: [tor-bugs] #29607 [Core Tor/Tor]: Need urgent help!

[Tor Bug Tracker & Wiki]

#29607: Need urgent help!
--+
 Reporter:  pidgin|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by mcs):

 * component:  - Select a component => Core Tor/Tor


Comment:

 Setting Trac component (someone please reset it if it is incorrect).

 I don't understand the comment "We are pretty sure this problem is on the
 side of the TOR browser" since this sounds to me like a tor server-side
 issue. It is also unclear if this is a bug report or a support request.

 Also, if you need immediate help please ask on IRC:
 https://www.torproject.org/about/contact.html.en#irc

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

Re: [tor-bugs] #29599 [Core Tor/Tor]: Test failure due to missing sr_state_free[_all]() in shared-random unit tests

[Tor Bug Tracker & Wiki]

#29599: Test failure due to missing sr_state_free[_all]() in shared-random unit
tests
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Major| Resolution:
 Keywords:  tor-ci, tor-test, memory-leak,   |  Actual Points:
  external-change, 029-backport, 033-backport,   |
  034-backport, 035-backport, 040-backport,  |
  nickm-merge|
Parent ID:   | Points:  0.5
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * keywords:
 tor-ci, tor-test, memory-leak, external-change, 029-backport,
 033-backport, 034-backport, 035-backport, 040-backport
 =>
 tor-ci, tor-test, memory-leak, external-change, 029-backport,
 033-backport, 034-backport, 035-backport, 040-backport, nickm-merge
 * reviewer:   => dgoulet
 * status:  needs_review => merge_ready


Comment:

 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] #29607 [Core Tor/Tor]: Need urgent help!

[Tor Bug Tracker & Wiki]

#29607: Need urgent help!
--+
 Reporter:  pidgin|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by pidgin):

 Replying to [comment:2 mcs]:
 > Setting Trac component (someone please reset it if it is incorrect).
 >
 > I don't understand the comment "We are pretty sure this problem is on
 the side of the TOR browser" since this sounds to me like a tor server-
 side issue. It is also unclear if this is a bug report or a support
 request.
 >
 > Also, if you need immediate help please ask on IRC:
 https://www.torproject.org/about/contact.html.en#irc

 My apologizes if it's not on TOR side, i am not here to discuss whether it
 is or not.
 Just trying to sort this problem out, so people won't have to deal with
 the problem in the future.
 And thank you for linking me the irc.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a3,  |  Actual Points:
  TorBrowserTeam201902R  |
Parent ID:  #27609   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 Replying to [comment:15 sisbell]:
 > Replying to [comment:14 sysrqb]:
 > > Shane, can you expand on why this is better?
 https://github.com/sisbell/tor-android-service/issues/12
 >
 > In tor-browser-build, we will replace these jars/libs with the ones that
 are generated as part of the build. The developer who wants to use tor-
 android-service in their own project will have these libraries already
 provided in the libs folder. This keeps a consistent approach. I'm still
 exploring whether these dependent libraries should be treated as provided,
 meaning they won't be packaged in the resulting aar.
 >
 > Ideally, in the future, I'd like to get the TOPL artifacts officially
 deployed to a maven repo and pull these down as dependencies during a
 regular developer build. The tor-browser-build would pull down the
 dependencies as part of the build process as well.


 Ah, so this is simply a stop-gap until they're available from a maven
 repo? That's fine. And if tor-browser-build will build these independently
 and (presumably) overwrite the vendored files, then I'm okay with that
 too, thanks for explaining.

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

Re: [tor-bugs] #26288 [Core Tor/Tor]: prop289: Implement authenticated SENDME

[Tor Bug Tracker & Wiki]

#26288: prop289: Implement authenticated SENDME
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop289, 035-roadmap-master, 035 |  Actual Points:
  -triaged-in-20180711, prop289-assigned-|
  sponsor-v, 041-proposed-on-roadmap, network-   |
  team-roadmap-2019-Q1Q2 |
Parent ID:   | Points:  21
 Reviewer:  nickm|Sponsor:
 |  SponsorV
-+-
Changes (by ahf):

 * reviewer:  ahf => nickm


Comment:

 The code and spec changes looks good to me. Moving this over to Nick for
 some additional 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] #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:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a3,  |  Actual Points:
  TorBrowserTeam201902R  |
Parent ID:  #27609   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 Have you seen these build errors. They're obviously coming form proguard,
 but i haven't started comparing Orbot's proguard file(s) with tor-android-
 service's yet.

 {{{
  1:10.37 Note: the configuration refers to the unknown class
 'com.google.android.gms.common.annotation.KeepName'
  1:10.37 Note: the configuration refers to the unknown class
 'com.google.android.gms.common.annotation.KeepName'
  1:10.38 Note: the configuration refers to the unknown class
 'okhttp3.internal.publicsuffix.PublicSuffixDatabase'
 [...]
  1:10.64 Warning:
 com.msopentech.thali.toronionproxy.OnionProxyManagerEventHandler: can't
 find superclass or interface net.freehaven.tor.control.EventHandler
  1:10.64 Warning: org.torproject.android.service.TorEventHandler: can't
 find superclass or interface net.freehaven.tor.control.EventHandler
  1:10.94 Warning: com.msopentech.thali.toronionproxy.BaseEventBroadcaster:
 can't find referenced class org.slf4j.Logger
  1:10.94 Warning: com.msopentech.thali.toronionproxy.BaseEventBroadcaster:
 can't find referenced class org.slf4j.Logger
 [...]
  1:10.95 Warning: com.msopentech.thali.toronionproxy.OnionProxyContext:
 can't find referenced class org.slf4j.Logger
  1:10.95 Warning: com.msopentech.thali.toronionproxy.OnionProxyContext:
 can't find referenced class org.slf4j.LoggerFactory
 [...]
  1:11.22 Warning: org.torproject.android.service.TorService: can't find
 referenced class
 com.msopentech.thali.android.toronionproxy.AndroidOnionProxyManager
  1:11.22 Warning: org.torproject.android.service.TorService: can't find
 referenced class
 com.msopentech.thali.android.toronionproxy.AndroidOnionProxyManager
  1:11.22 Warning: org.torproject.android.service.TorService: can't find
 referenced class
 com.msopentech.thali.android.toronionproxy.AndroidOnionProxyManager
 [...]
  1:11.40 Note: com.google.android.exoplayer2.DefaultRenderersFactory:
 can't find dynamically referenced class
 com.google.android.exoplayer2.ext.vp9.LibvpxVideoRenderer
 [...]
  1:12.84 Note: there were 16 references to unknown classes.
  1:12.84   You should check your configuration for typos.
  1:12.84
 (http://proguard.sourceforge.net/manual/troubleshooting.html#unknownclass)
  1:12.84 Note: there were 11 unkept descriptor classes in kept class
 members.
  1:12.84   You should consider explicitly keeping the mentioned
 classes
  1:12.84   (using '-keep').
  1:12.84
 (http://proguard.sourceforge.net/manual/troubleshooting.html#descriptorclass)
  1:12.84 Note: there were 1 library classes explicitly being kept.
  1:12.84   You don't need to keep library classes; they are already
 left unchanged.
  1:12.85
 (http://proguard.sourceforge.net/manual/troubleshooting.html#libraryclass)
  1:12.85 Note: there were 12 unresolved dynamic references to classes or
 interfaces.
  1:12.85   You should check if you need to specify additional program
 jars.
  1:12.85
 (http://proguard.sourceforge.net/manual/troubleshooting.html#dynamicalclass)
  1:12.85 Warning: there were 83 unresolved references to classes or
 interfaces.
  1:12.87  You may need to add missing library jars or update their
 versions.
  1:12.87  If your code works fine without the missing classes, you
 can suppress
  1:12.87  the warnings with '-dontwarn' options.
 }}}

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

Re: [tor-bugs] #23681 [Core Tor/Tor]: prop224: Clients mark intro circs as timed-out within seconds

[Tor Bug Tracker & Wiki]

#23681: prop224: Clients mark intro circs as timed-out within seconds
-+-
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, 029-backport-   |  Actual Points:
  maybe, 031-unreached-backport  |
Parent ID:   | Points:
 Reviewer:  mikeperry|Sponsor:
-+-

Comment (by dgoulet):

 Yeah I think backporting to 029 is fine.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29609 [Internal Services/Service - git]: Create new repository for privacy docs

[Tor Bug Tracker & Wiki]

#29609: Create new repository for privacy docs
-+--
 Reporter:  hiro |  Owner:  hiro
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--


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

Re: [tor-bugs] #29599 [Core Tor/Tor]: Test failure due to missing sr_state_free[_all]() in shared-random unit tests

[Tor Bug Tracker & Wiki]

#29599: Test failure due to missing sr_state_free[_all]() in shared-random unit
tests
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Major| Resolution:
 Keywords:  tor-ci, tor-test, memory-leak,   |  Actual Points:
  external-change, 029-backport, 033-backport,   |
  034-backport, 035-backport, 040-backport,  |
  nickm-merge|
Parent ID:   | Points:  0.5
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by nickm):

 * milestone:  Tor: 0.4.1.x-final => Tor: 0.3.5.x-final


Comment:

 Merged to 0.4.0 and forward; marking for 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] #28525 [Core Tor/Tor]: Make tor_addr_is_internal_() aware of RFC 6598 (Carrier Grade NAT/Large Scale NAT) IPv4 Ranges

[Tor Bug Tracker & Wiki]

#28525: Make tor_addr_is_internal_() aware of RFC 6598 (Carrier Grade NAT/Large
Scale NAT) IPv4 Ranges
-+-
 Reporter:  neel |  Owner:  neel
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, 040-deferred-20190220  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  nickm|Sponsor:
-+-
Changes (by nickm):

 * cc: teor (added)


Comment:

 looks okay to me.  I'd like Teor to take one last look too, if they're
 free.  Then let's merge!

 (you free, teor?)

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

Re: [tor-bugs] #29598 [Internal Services/Service - git]: Please give Teor permissions to push to torspec.git

[Tor Bug Tracker & Wiki]

#29598: Please give Teor permissions to push to torspec.git
-+
 Reporter:  nickm|  Owner:  tor-gitadm
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by hiro):

 * 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] #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:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a3,  |  Actual Points:
  TorBrowserTeam201902R  |
Parent ID:  #27609   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 Replying to [comment:17 sysrqb]:
 > {{{
 >  1:10.64 Warning:
 com.msopentech.thali.toronionproxy.OnionProxyManagerEventHandler: can't
 find superclass or interface net.freehaven.tor.control.EventHandler
 >  1:10.64 Warning: org.torproject.android.service.TorEventHandler: can't
 find superclass or interface net.freehaven.tor.control.EventHandler
 >  1:10.94 Warning:
 com.msopentech.thali.toronionproxy.BaseEventBroadcaster: can't find
 referenced class org.slf4j.Logger
 >  1:10.94 Warning:
 com.msopentech.thali.toronionproxy.BaseEventBroadcaster: can't find
 referenced class org.slf4j.Logger
 > [...]
 >  1:10.95 Warning: com.msopentech.thali.toronionproxy.OnionProxyContext:
 can't find referenced class org.slf4j.Logger
 >  1:10.95 Warning: com.msopentech.thali.toronionproxy.OnionProxyContext:
 can't find referenced class org.slf4j.LoggerFactory
 > [...]
 >  1:11.22 Warning: org.torproject.android.service.TorService: can't find
 referenced class
 com.msopentech.thali.android.toronionproxy.AndroidOnionProxyManager
 >  1:11.22 Warning: org.torproject.android.service.TorService: can't find
 referenced class
 com.msopentech.thali.android.toronionproxy.AndroidOnionProxyManager
 >  1:11.22 Warning: org.torproject.android.service.TorService: can't find
 referenced class
 com.msopentech.thali.android.toronionproxy.AndroidOnionProxyManager
 > [...]
 >  1:12.85 Warning: there were 83 unresolved references to classes or
 interfaces.
 >  1:12.87  You may need to add missing library jars or update
 their versions.
 >  1:12.87  If your code works fine without the missing classes,
 you can suppress
 >  1:12.87  the warnings with '-dontwarn' options.
 > }}}

 To be clear, it is the latter Warnings causing the build failure (83
 unresolved references to classes).

 {{{
 Warning: Exception while processing task java.io.IOException: Please
 correct the above warnings first.
 
:app:transformClassesAndResourcesWithProguardForOfficialWithGeckoBinariesNoMinApiPhotonDebug
 FAILED

 FAILURE: Build failed with an exception.

 * What went wrong:
 Execution failed for task
 
':app:transformClassesAndResourcesWithProguardForOfficialWithGeckoBinariesNoMinApiPhotonDebug'.
 > Job failed, see logs for details

 }}}

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

Re: [tor-bugs] #29489 [Obfuscation/Snowflake]: Set up automated local testing environment for Snowflake

[Tor Bug Tracker & Wiki]

#29489: Set up automated local testing environment for Snowflake
---+---
 Reporter:  cohosh |  Owner:  cohosh
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #29259 | Points:
 Reviewer: |Sponsor:  Sponsor19
---+---

Comment (by cohosh):

 > Reproduce the proxy-go deadlocking bug #25688

 It might be useful to spawn several clients in the docker container for
 testing and bug-reproduction purposes. At the moment, I am using the
 torrc-localhost file for the torrc configuration on the client side, but
 we can have only one client bound to each local socks port at a time, and
 tor processes cannot share a datadir.

 What I have done manually so far is copy the client executable and torrc
 file to different directories and added the SocksPort line to each new
 torrc file with a different port number per client instance. I'm thinking
 of expanding the script.sh script to specify a --num-clients option that
 will do this copying SockPort configuration automatically (we don't even
 really need different directories for each client, just different socks
 ports and datadir's).

 While I'm at it, I will probably include a --build option to the script
 that will only compile the code if needed. Since we are mounting the git
 repository from the host directly, this does not need to be done each time
 the container is started.

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

Re: [tor-bugs] #29553 [Core Tor/Tor]: pre-commit hook gives a warning when there are no changes files, when source files aren't where expected, and doesn't exit.

[Tor Bug Tracker & Wiki]

#29553: pre-commit hook gives a warning when there are no changes files, when
source files aren't where expected, and doesn't exit.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  asn-merge |  Actual Points:
Parent ID:| Points:  .1
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_review => merge_ready
 * keywords:   => asn-merge


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

Re: [tor-bugs] #17357 [Core Tor/Tor]: rend_service_relaunch_rendezvous() ignores rend_service_requires_uptime()

[Tor Bug Tracker & Wiki]

#17357: rend_service_relaunch_rendezvous() ignores 
rend_service_requires_uptime()
--+--
 Reporter:  teor  |  Owner:  neel
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+--
Changes (by neel):

 * owner:  (none) => neel
 * cc: neel (added)
 * 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] #17357 [Core Tor/Tor]: rend_service_relaunch_rendezvous() ignores hs_service_requires_uptime_circ() (was: rend_service_relaunch_rendezvous() ignores rend_service_requires_uptime())

[Tor Bug Tracker & Wiki]

#17357: rend_service_relaunch_rendezvous() ignores
hs_service_requires_uptime_circ()
--+--
 Reporter:  teor  |  Owner:  neel
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+--

Comment (by neel):

 I believe `rend_service_requires_uptime()` was renamed to
 `hs_service_requires_uptime_circ()` and the former function no longer
 exists in 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] #29120 [Applications/Tor Browser]: Default value of media.cache_size (0) causes some media to load extremely slowly or become unplayable

[Tor Bug Tracker & Wiki]

#29120: Default value of media.cache_size (0) causes some media to load 
extremely
slowly or become unplayable
-+-
 Reporter:  QZw2aBQoPyuEVXYVlBps |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-disk-leak, tbb-usability-|  Actual Points:
  website, TorBrowserTeam201902R |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:27 gk]:
 > mcs/brade can you have a (second) look on the latest patch? Thanks!

 The patch looks good to us. We are a little concerned about portions of
 comment:25, especially the part about `return nullptr;` (because we are do
 not understand cyperpunks' point).

 It might be worthwhile to add parens around the second part of the `if`
 expression; with the patched code, clang emits a `-Wlogical-op-
 parentheses` warning due to potential confusion when reading the code. The
 following would be better:
 {{{
   if (aIsPrivateBrowsing ||
   (aContentLength > 0 &&
aContentLength <= int64_t(MediaPrefs::MediaMemoryCacheMaxSize()) *
 1024)) {
 }}}

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

Re: [tor-bugs] #29603 [Core Tor/Tor]: Make a script that sets up worktrees for the git-* merge scripts

[Tor Bug Tracker & Wiki]

#29603: Make a script that sets up worktrees for the git-* merge scripts
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  git-scripts   |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+--

Comment (by dgoulet):

 Just attached a file I hacked up last night for my personal usage. It
 ain't the best "bash" but it is a good start :). I use it and it is doing
 what we need so far.

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

Re: [tor-bugs] #29603 [Core Tor/Tor]: Make a script that sets up worktrees for the git-* merge scripts

[Tor Bug Tracker & Wiki]

#29603: Make a script that sets up worktrees for the git-* merge scripts
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  git-scripts   |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

 * Attachment "tor-git-new-worktree.sh" 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] #29280 [Core Tor/Tor]: Use Chutney for CI

[Tor Bug Tracker & Wiki]

#29280: Use Chutney for CI
-+-
 Reporter:  cohosh   |  Owner:  (none)
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  CI, PTs 029-backport 034-backport|  Actual Points:  1
  035-backport 040-backport  |
Parent ID:  #29267   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor19
-+-
Changes (by nickm):

 * status:  new => needs_review
 * keywords:  CI, PTs => CI, PTs 029-backport 034-backport 035-backport
 040-backport
 * actualpoints:   => 1


Comment:

 Please see the branches below.  They add a new make target, "make test-
 network-forgiving" that tries to run test-network.sh a few times, and
 succeeds if it succeeds once.  They add a builder to do this on travis.


  * chutney_ci_029, PR at https://github.com/torproject/tor/pull/734
  * chutney_ci_034, PR at https://github.com/torproject/tor/pull/735 (fixes
 conflicts)
  * chutney_ci_035, PR at https://github.com/torproject/tor/pull/736 (fixes
 conflicts)
  * chutney_ci_040, PR at https://github.com/torproject/tor/pull/737 (no
 conflicts to fix; CI only)
  * chutney_ci_041, PR at https://github.com/torproject/tor/pull/738 (no
 conflicts to fix; CI only)

 All of them passed on my first attempt when I pushed them to github
 myself, so let's see whether CI likes them a second time.

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

Re: [tor-bugs] #29280 [Core Tor/Tor]: Use Chutney for CI

[Tor Bug Tracker & Wiki]

#29280: Use Chutney for CI
-+-
 Reporter:  cohosh   |  Owner:  (none)
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  CI, PTs 029-backport 034-backport|  Actual Points:  1
  035-backport 040-backport  |
Parent ID:  #29267   | Points:
 Reviewer:  teor |Sponsor:
 |  Sponsor19
-+-
Changes (by nickm):

 * reviewer:   => teor


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

Re: [tor-bugs] #28794 [Core Tor/Fallback Scripts]: Run an opt-in process for relay operators to become fallbacks in 2019

[Tor Bug Tracker & Wiki]

#28794: Run an opt-in process for relay operators to become fallbacks in 2019
---+--
 Reporter:  teor   |  Owner:  phoul
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback   |  Actual Points:
Parent ID:  #28793 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by phoul):

 Replying to [comment:13 teor]:
 > fallback directory mirror armbrust:
 E781F4EC69671B3F1864AE2753E0890351506329 is going down soon. It should be
 removed from the whitelist.
 >
 > https://lists.torproject.org/pipermail/tor-
 relays/2019-January/016878.html
 The list has now been migrated to the fallback-scripts repo, and this
 change has been made at https://github.com/Phoul/fallback-
 scripts/commit/30dc6bd347860a3df42f6c205550f2f0766e2151

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

Re: [tor-bugs] #27484 [Applications/Tor Browser]: Onboarding: unintuitive not-navigation buttons, starting with "Circuit Display" / "See My Path"

[Tor Bug Tracker & Wiki]

#27484: Onboarding: unintuitive not-navigation buttons, starting with "Circuit
Display" / "See My Path"
-+-
 Reporter:  dmr  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-8.0-issues, tbb-onboarding, ux-  |  Actual Points:
  team   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by antonela):

 * Attachment "TB8.5-onboarding-review.png" added.


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

Re: [tor-bugs] #28044 [Applications/Tor Launcher]: Integrate Tor Launcher into tor-browser

[Tor Bug Tracker & Wiki]

#28044: Integrate Tor Launcher into tor-browser
-+-
 Reporter:  gk   |  Owner:  brade
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Launcher|Version:
 Severity:  Normal   | Resolution:
 Keywords:  AffectsTails, ux-team,   |  Actual Points:
  TorBrowserTeam201902R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:14 gk]:
 > Nice! Have you by chance tried testing the mechanism you are using for
 integrating Tor Launcher into the browser in, say, some recent-ish
 mozilla-central build? It might be worth it in order to figure out whether
 we could do more work already now in case there are unanticipated problems
 with our migration plan for esr68.

 We did not try the build integration, but in early January we performed an
 experiment in which we manually embedded Tor Launcher inside a nightly
 build of Firefox 66 (that is, we hacked `browser/omni.ja`).  I do not
 remember everything about that experiment, but the general integration
 approach was successful (although #29197 needs to be fixed for Tor
 Launcher functionality to work fully in newer Firefox builds).

 Please let us know if you want Kathy and me to do a new, more thorough
 experiment.

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

Re: [tor-bugs] #27484 [Applications/Tor Browser]: Onboarding: unintuitive not-navigation buttons, starting with "Circuit Display" / "See My Path"

[Tor Bug Tracker & Wiki]

#27484: Onboarding: unintuitive not-navigation buttons, starting with "Circuit
Display" / "See My Path"
-+-
 Reporter:  dmr  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-8.0-issues, tbb-onboarding, ux-  |  Actual Points:
  team   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by antonela):

 * Attachment "TB8.5-onboarding-review.png" added.


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

Re: [tor-bugs] #27484 [Applications/Tor Browser]: Onboarding: unintuitive not-navigation buttons, starting with "Circuit Display" / "See My Path"

[Tor Bug Tracker & Wiki]

#27484: Onboarding: unintuitive not-navigation buttons, starting with "Circuit
Display" / "See My Path"
-+-
 Reporter:  dmr  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-8.0-issues, tbb-onboarding, ux-  |  Actual Points:
  team   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by antonela):

 * Attachment "TB8.5-onboarding-review.png" 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] #27484 [Applications/Tor Browser]: Onboarding: unintuitive not-navigation buttons, starting with "Circuit Display" / "See My Path"

[Tor Bug Tracker & Wiki]

#27484: Onboarding: unintuitive not-navigation buttons, starting with "Circuit
Display" / "See My Path"
-+-
 Reporter:  dmr  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-8.0-issues, tbb-onboarding, ux-  |  Actual Points:
  team   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by antonela):

 I reviewed this ticket and I approached solutions for the problem defined
 at 1. on the comment:8 and confirmed by mcs at comment:9

 [[Image(https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/27484/TB8.5-onboarding-review.png, 700px)]]

 **Option A**

 We continue having a [next/continue] button on all steps and move external
 links to the body content. In this case, we will need some indicator that
 we are going to open an external URL — something like
 [https://thenounproject.com/search/?q=external%20url&i=1721080 this].

 **Option B**

 We rely on the left menu navigation for users to navigate, in the same way
 as Firefox does, and we use the right button on the needed steps to open
 external links.

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

Re: [tor-bugs] #17357 [Core Tor/Tor]: rend_service_relaunch_rendezvous() ignores hs_service_requires_uptime_circ()

[Tor Bug Tracker & Wiki]

#17357: rend_service_relaunch_rendezvous() ignores
hs_service_requires_uptime_circ()
--+--
 Reporter:  teor  |  Owner:  neel
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+--
Changes (by neel):

 * status:  assigned => needs_review


Comment:

 I have a GitHub PR here: https://github.com/torproject/tor/pull/739

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

Re: [tor-bugs] #28044 [Applications/Tor Launcher]: Integrate Tor Launcher into tor-browser

[Tor Bug Tracker & Wiki]

#28044: Integrate Tor Launcher into tor-browser
-+-
 Reporter:  gk   |  Owner:  brade
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Launcher|Version:
 Severity:  Normal   | Resolution:
 Keywords:  AffectsTails, ux-team,   |  Actual Points:
  TorBrowserTeam201902R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:15 mcs]:
 > Replying to [comment:14 gk]:
 > > Nice! Have you by chance tried testing the mechanism you are using for
 integrating Tor Launcher into the browser in, say, some recent-ish
 mozilla-central build? It might be worth it in order to figure out whether
 we could do more work already now in case there are unanticipated problems
 with our migration plan for esr68.
 >
 > We did not try the build integration, but in early January we performed
 an experiment in which we manually embedded Tor Launcher inside a nightly
 build of Firefox 66 (that is, we hacked `browser/omni.ja`).  I do not
 remember everything about that experiment, but the general integration
 approach was successful (although #29197 needs to be fixed for Tor
 Launcher functionality to work fully in newer Firefox builds).
 >
 > Please let us know if you want Kathy and me to do a new, more thorough
 experiment.

 Thanks, works for 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] #29120 [Applications/Tor Browser]: Default value of media.cache_size (0) causes some media to load extremely slowly or become unplayable

[Tor Bug Tracker & Wiki]

#29120: Default value of media.cache_size (0) causes some media to load 
extremely
slowly or become unplayable
-+-
 Reporter:  QZw2aBQoPyuEVXYVlBps |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-disk-leak, tbb-usability-|  Actual Points:
  website, TorBrowserTeam201902R |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by QZw2aBQoPyuEVXYVlBps):

 Replying to [comment:28 mcs]:
 >
 > The patch looks good to us. We are a little concerned about portions of
 comment:25, especially the part about `return nullptr;` (because we are do
 not understand cyperpunks' point).
 I also have no idea what cypherpunks meant by that comment. The original
 Mozilla code also returns nullptr on failure, so we're not changing any
 logic in that regard. It's even documented in the function comment:
 https://hg.mozilla.org/releases/mozilla-
 
esr60/file/256453759958ed9c2eb17a0764d2fcfd7f8e3323/dom/media/MediaCache.cpp#l152

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

Re: [tor-bugs] #29607 [Core Tor/Tor]: Need urgent help!

[Tor Bug Tracker & Wiki]

#29607: Need urgent help!
--+
 Reporter:  pidgin|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 > We are pretty sure this problem is on the side of the TOR browser, is
 there anything we could do to sort this?

 Probably the best way to get started would be to explain why you conclude
 this is a problem with the Tor browser, or with 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] #17357 [Core Tor/Tor]: rend_service_relaunch_rendezvous() ignores hs_service_requires_uptime_circ()

[Tor Bug Tracker & Wiki]

#17357: rend_service_relaunch_rendezvous() ignores
hs_service_requires_uptime_circ()
--+
 Reporter:  teor  |  Owner:  neel
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:  Tor: unspecified => Tor: 0.4.1.x-final


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

Re: [tor-bugs] #29299 [Core Tor/sbws]: Include scanner country and Web server country in the bandwidth file header

[Tor Bug Tracker & Wiki]

#29299: Include scanner country and Web server country in the bandwidth file 
header
---+---
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:  1
 Reviewer:  catalyst   |Sponsor:
---+---
Changes (by catalyst):

 * status:  needs_review => merge_ready


Comment:

 Replying to [comment:14 juga]:
 > Thanks, addressed your comments.
 Thanks! It looks good now. I left one more comment on github about an
 extraneous minor format change, but please feel free to merge without
 further review after fixing 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] #28329 [Applications/Tor Browser]: Design TBA+Orbot configuration UI/UX

[Tor Bug Tracker & Wiki]

#28329: Design TBA+Orbot configuration UI/UX
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, ux-team, TBA-a3, |  Actual Points:
  TorBrowserTeam201902   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by gk):

 antonela: What about

 https://people.torproject.org/~gk/testbuilds/tor-browser-tbb-nightly-
 android-armv7-multi-qa-28329_v2.apk
 https://people.torproject.org/~gk/testbuilds/tor-browser-tbb-nightly-
 android-armv7-multi-qa-28329_v2.apk.asc

 ?

 I don't get it to crash on my phone. The patch I used on top of sysrqb's
 is:
 {{{
 diff --git
 
a/mobile/android/base/java/org/mozilla/gecko/torbootstrap/TorBootstrapPanel.java
 
b/mobile/android/base/java/org/mozilla/gecko/torbootstrap/TorBootstrapPanel.java
 index 743842dca88d..e097a31abb2c 100644
 ---
 
a/mobile/android/base/java/org/mozilla/gecko/torbootstrap/TorBootstrapPanel.java
 +++
 
b/mobile/android/base/java/org/mozilla/gecko/torbootstrap/TorBootstrapPanel.java
 @@ -170,16 +170,16 @@ public class TorBootstrapPanel extends FirstrunPanel
 implements TorBootstrapLogg
  }
  connectButton.setVisibility(View.GONE);

 -ImageView spinningOnionHolder = (ImageView)
 mRoot.findViewById(R.id.tor_bootstrap_onion);
 +//ImageView spinningOnionHolder = (ImageView)
 mRoot.findViewById(R.id.tor_bootstrap_onion);

 -
 spinningOnionHolder.setBackgroundResource(R.drawable.tor_spinning_onion);
 -AnimationDrawable spinningOnion = (AnimationDrawable)
 spinningOnionHolder.getBackground();
 +
 //spinningOnionHolder.setBackgroundResource(R.drawable.tor_spinning_onion);
 +//AnimationDrawable spinningOnion = (AnimationDrawable)
 spinningOnionHolder.getBackground();

  // Begin spinning
 -spinningOnion.start();
 +//spinningOnion.start();

  // Make the still image 100% transparent
 -spinningOnionHolder.setImageAlpha(0);
 +//spinningOnionHolder.setImageAlpha(0);

  TextView torStatus = (TextView)
 mRoot.findViewById(R.id.tor_bootstrap_last_status_message);

 @@ -201,13 +201,13 @@ public class TorBootstrapPanel extends FirstrunPanel
 implements TorBootstrapLogg
  }
  connectButton.setVisibility(View.VISIBLE);

 -ImageView spinningOnionHolder = (ImageView)
 mRoot.findViewById(R.id.tor_bootstrap_onion);
 -if (null == spinningOnionHolder) {
 +//ImageView spinningOnionHolder = (ImageView)
 mRoot.findViewById(R.id.tor_bootstrap_onion);
 +/*if (null == spinningOnionHolder) {
  Log.w(LOGTAG, "stopBootstrapping: spinningOnionHolder is
 null?");
  return;
 -}
 -AnimationDrawable spinningOnion = (AnimationDrawable)
 spinningOnionHolder.getBackground();
 -if (null != spinningOnion) {
 +}*/
 +//AnimationDrawable spinningOnion = (AnimationDrawable)
 spinningOnionHolder.getBackground();
 +/*if (null != spinningOnion) {
  // Stop spinning. This is null if we didn't
  // previously call startBootstrapping.
  spinningOnion.stop();
 @@ -215,7 +215,7 @@ public class TorBootstrapPanel extends FirstrunPanel
 implements TorBootstrapLogg
  // Make the still image 0% transparent, but only
  // if there is an animation in the background
  spinningOnionHolder.setImageAlpha(100);
 -}
 +}*/

  TextView torStatus = (TextView)
 mRoot.findViewById(R.id.tor_bootstrap_last_status_message);
  if (null == torStatus) {
 }}}
 which just disables the animation.

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

Re: [tor-bugs] #28168 [Obfuscation/meek]: Use ESNI via Firefox HTTPS helper

[Tor Bug Tracker & Wiki]

#28168: Use ESNI via Firefox HTTPS helper
--+-
 Reporter:  dcf   |  Owner:  dcf
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by dcf):

 I set up a Cloudflare account and got this all working: meek with ESNI in
 place of domain fronting, running in Tor Browser with an external Firefox
 helper. When Tor Browser starts using a Firefox newer than 60 ESR, it
 won't need an separate external Firefox.

 === Cloudflare setup ===

  * Register a new domain name. I got rinsed-tinsel.site. (I initially
 planned to use a subdomain of bamsoftware.com, but Cloudflare only allows
 that on their paid plans—on the free plan the only option is to have
 Cloudflare handle ''all'' the DNS for the domain.)
  * Click "+ Add site", enter the domain name, and choose the free plan.
  * At the DNS screen, add a new CNAME record for subdomain "meek" pointing
 to "meek.bamsoftware.com". (How this works is when users query meek
 .rinsed-tinsel.site, the Cloudflare DNS server will give them an A record
 pointing at a Cloudflare edge server, and then the Cloudflare edge server
 will fetch origin pages from meek.bamsoftware.com.)
  * Go back to the name registrar and set the nameserver to the two
 *.ns.cloudflare.com servers that it tells you to set.
  * I then went and made the following configuration changes:
* Crypto tab
  * SSL: Full (strict)
  * Always Use HTTPS: On
  * Minimum TLS Version: TLS 1.2
* Firewall tab
  * Security Level: Essentially Off
  * Web Application Firewall
* Browser Integrity Check: Off
* Caching tab
  * Always Online™: Off
* Scrape Shield tab
  * Email Address Obfuscation: Off
  * Server-side Excludes: Off
  * Hotlink Protection: Off

 === WebExtension build ===

 Start with commit [https://gitweb.torproject.org/pluggable-
 
transports/meek.git/log/?h=webextension&id=9a822c9e99e0bf23c542427de4eae3493ebccbc3
 9a822c9e99] in the [https://gitweb.torproject.org/pluggable-
 transports/meek.git/log/?h=webextension webextension] branch.

 1. Enter meek/webextension/native and run `go build`. This produces the
 native component of the extension.
 1. Enter meek/webextension and run `make`. This zips up the extension
 files into an installable bundle, !meek-http-hel...@bamsoftware.com.xpi.

 === Firefox setup ===

 3. Download [https://www.mozilla.org/en-US/firefox/developer/ Firefox
 Developer Edition]. You need the developer edition in order to install an
 unsigned extension.
 1. Run `firefox/firefox --ProfileManager` and create a new "esni" profile.
 Go to `about:config` and set these prefs:
{{{
 browser.dom.window.dump.enabled
 network.trr.mode=3
 network.trr.uri=https://1.1.1.1/dns-query
 network.security.esni.enabled=true
 toolkit.startup.max_resumed_crashes=-1
 xpinstall.signatures.required=false
}}}
 1. Go to `about:addons`. Click Extensions. Click ⚙️ and select "Install
 Add-on From File...". Open meek/webextension/!meek-http-
 hel...@bamsoftware.com.xpi. Say yes to the permissions dialog.
 1. Close Firefox.

 === meek-client-torbrowser build ===

 7. Edit meek/meek-client-torbrowser/{linux,mac,windows}.go (whatever's
 needed for your platform) and adjust the paths:
{{{
 firefoxPath= "/path/to/firefox/firefox"
 firefoxProfilePath =
 "/home/user/.mozilla/firefox/.esni"
 helperNativeManifestDir= "/path/to/tor-browser_en-US/Browser/.mozilla
 /native-messaging-hosts"
 helperNativeExecutablePath = "/path/to/meek/webextension/native/native"
}}}
 1. In meek/meek-client-torbrowser, run `go build`.
 1. Copy the resulting meek-client-torbrowser binary to tor-browser_en-
 US/Browser/TorBrowser/Tor/PluggableTransports/.

 === Tor Browser setup ===

 10. Click the "Configure" button in Tor Launcher, or "Tor Network
 Settings..." in the onion toolbar icon.
 1. Click "Tor ic censored in my country" and "Provide a bridge I know".
 Enter the bridge line:
{{{
 meek 0.0.2.0:3 1922840D0D66CB82EACE4327F5001430227C0127 url=https://meek
 .rinsed-tinsel.site/
}}}
 1. Because of #12774, it may not work right away and you'll have to
 restart.

 

 This is a packet capture of bootstrapping and browsing to example.com:
 attachment:meek-esni.pcap. Here's a summary of all the Client Hellos it
 contains:
 {{{
 No.  Time Source DestinationProtocol Info
   7  2019-02-27 12:24:38  192.168.111.2  1.1.1.1TLSv1.2  Client
 Hello
  14  2019-02-27 12:24:38  192.168.111.2  1.1.1.1TLSv1.2  Client
 Hello
  15  2019-02-27 12:24:38  192.168.111.2  1.1.1.1TLSv1.2  Client
 He

Re: [tor-bugs] #28168 [Obfuscation/meek]: Use ESNI via Firefox HTTPS helper

[Tor Bug Tracker & Wiki]

#28168: Use ESNI via Firefox HTTPS helper
--+-
 Reporter:  dcf   |  Owner:  dcf
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by dcf):

 * Attachment "meek-esni.pcap" 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] #29610 [Core Tor/Tor]: Server being attacked

[Tor Bug Tracker & Wiki]

#29610: Server being attacked
---+--
 Reporter:  pidgin |  Owner:  (none)
 Type:  project| Status:  new
 Priority:  Very High  |  Component:  Core Tor/Tor
  Version: |   Severity:  Critical
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 Dear tor team,
 We have setup a discussion board, on the tor network.
 And there is someone that is exploiting within our servers, by taking it
 down it every time and the forums will respond with "Server not found".

  Some server sided info below :

 onionbalance is active
 vanguard is active
 vanguard tor process is at 5%
 serving tor process is at 5%

 attacker has found a way to DDOS not based on tor cpu usage attack or tor
 traffic exhaust attack.

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

Re: [tor-bugs] #28168 [Obfuscation/meek]: Use ESNI via Firefox HTTPS helper

[Tor Bug Tracker & Wiki]

#28168: Use ESNI via Firefox HTTPS helper
--+-
 Reporter:  dcf   |  Owner:  dcf
 Type:  project   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by dcf):

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


Comment:

 Calling this done because it works, and the rest is a matter of
 integration.

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

Re: [tor-bugs] #17357 [Core Tor/Tor]: rend_service_relaunch_rendezvous() ignores hs_service_requires_uptime_circ()

[Tor Bug Tracker & Wiki]

#17357: rend_service_relaunch_rendezvous() ignores
hs_service_requires_uptime_circ()
--+
 Reporter:  teor  |  Owner:  neel
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_review => needs_revision


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

Re: [tor-bugs] #29601 [Core Tor/Tor]: Drop the oldest Windows 32-bit build on Appveyor to speed up builds

[Tor Bug Tracker & Wiki]

#29601: Drop the oldest Windows 32-bit build on Appveyor to speed up builds
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:  Tor:
   |  0.4.1.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.5.4-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-ci, tor-test, windows  |  Actual Points:
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 I worked out how to cut it down to 2 jobs, and force-pushed 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

Re: [tor-bugs] #29601 [Core Tor/Tor]: Drop redundant jobs on Appveyor to speed up builds (was: Drop the oldest Windows 32-bit build on Appveyor to speed up builds)

[Tor Bug Tracker & Wiki]

#29601: Drop redundant jobs on Appveyor to speed up builds
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:  Tor:
   |  0.4.1.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.5.4-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-ci, tor-test, windows  |  Actual Points:
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:
---+---

Old description:

> Our Appveyor builds are really slow. We can still get decent coverage if
> we drop the 32-bit Windows Server 2012 R2 build.
>
> The remaining builds will be:
> * 64-bit Windows Server 2016
> * 32-bit Windows Server 2016
> * 64-bit Windows Server 2012 R2

New description:

 Our Appveyor builds are really slow. We can still get decent coverage if
 we drop some redundant jobs.

 The remaining builds will be:
 * 64-bit Windows Server 2016
 * 32-bit Windows Server 2012 R2

 We can also set fast_finish, so the first failed job terminates the build
 immediately.

--

Comment (by teor):

 Fix description.

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

Re: [tor-bugs] #29294 [Core Tor/sbws]: Create an script to automate releases

[Tor Bug Tracker & Wiki]

#29294: Create an script to automate releases
---+---
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords:  easy   |  Actual Points:
Parent ID: | Points:  1
 Reviewer:  teor   |Sponsor:
---+---

Comment (by teor):

 Answering juga's question from IRC:
 {{{
 you prefer i rm the script and add doc, or just leave it like it is now?
 }}}

 It's up to you.

 It is weird to have a script that just prints instructions.

 It is good that the script shows the right versions in the instructions.
 Can you add a comment explaining that the script shows the right versions?

 Do you plan on modifying the script so it automates more tasks in future
 releases?
 Can you add a comment explaining that the script will get better?

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

Re: [tor-bugs] #29294 [Core Tor/sbws]: Create an script to automate releases

[Tor Bug Tracker & Wiki]

#29294: Create an script to automate releases
---+---
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords:  easy   |  Actual Points:
Parent ID: | Points:  1
 Reviewer:  teor   |Sponsor:
---+---
Changes (by teor):

 * status:  needs_review => needs_revision


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

Re: [tor-bugs] #29599 [Core Tor/Tor]: Test failure due to missing sr_state_free[_all]() in shared-random unit tests

[Tor Bug Tracker & Wiki]

#29599: Test failure due to missing sr_state_free[_all]() in shared-random unit
tests
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Major| Resolution:
 Keywords:  tor-ci, tor-test, memory-leak,   |  Actual Points:
  external-change, 029-backport, 033-backport,   |
  034-backport, 035-backport, 040-backport,  |
  nickm-merge|
Parent ID:   | Points:  0.5
 Reviewer:  dgoulet  |Sponsor:
-+-

Comment (by teor):

 The 64-bit Windows Server 2016 builds failed in appveyor due to #29500.

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

Re: [tor-bugs] #17357 [Core Tor/Tor]: rend_service_relaunch_rendezvous() ignores hs_service_requires_uptime_circ()

[Tor Bug Tracker & Wiki]

#17357: rend_service_relaunch_rendezvous() ignores
hs_service_requires_uptime_circ()
--+
 Reporter:  teor  |  Owner:  neel
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by neel):

 * status:  needs_revision => needs_review


Comment:

 I have moved the `base32_encode()` call into the `if (!service)`
 statement.

 I could not move the `rend_pk_digest()` call into the statement because
 it's needed by `rend_service_get_by_pk_digest()` to fill in `service`
 which is needed by `hs_service_requires_uptime_circ()`.

 These changes have been pushed and I am 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] #28300 [Core Tor/Stem]: Scrolling support for tor-prompt is needed

[Tor Bug Tracker & Wiki]

#28300: Scrolling support for tor-prompt is needed
---+--
 Reporter:  wagon  |  Owner:  atagar
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:  Tor: 0.3.4.8
 Severity:  Normal | Resolution:  wontfix
 Keywords:  tor-prompt |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by atagar):

 Hi wagon, sorry about the long multi-month lack of a reply. Your demo is
 perfect, works like a charm. Added it to our faq...

 https://gitweb.torproject.org/stem.git/commit/?id=2cd7bff

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

Re: [tor-bugs] #22132 [Core Tor/Chutney]: Chutney should avoid waiting for set times: wait for conditions instead

[Tor Bug Tracker & Wiki]

#22132: Chutney should avoid waiting for set times: wait for conditions instead
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  1
Parent ID:  #20647| Points:  2
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * status:  needs_revision => needs_review
 * actualpoints:   => 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] #22132 [Core Tor/Chutney]: Chutney should avoid waiting for set times: wait for conditions instead

[Tor Bug Tracker & Wiki]

#22132: Chutney should avoid waiting for set times: wait for conditions instead
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #20647| Points:  2
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 I have a chutney branch here called `wait_until_bootstrap`.  We'll need to
 update the test scripts accordingly.

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

Re: [tor-bugs] #29500 [Core Tor/Tor]: Broken circuitpadding unittests on appveyor

[Tor Bug Tracker & Wiki]

#29500: Broken circuitpadding unittests on appveyor
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  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, 041-proposed, 040-must|
Parent ID:  #28631   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:10 mikeperry]:
 > Replying to [comment:9 asn]:
 > > Mike, wrt the `test_circuitpadding_tokens()` test, could it be another
 case where the test actually schedules legit padding because of a state
 transition or something and it might trigger or might not depending on how
 the timing of the test goes?  Like the one from #29122?
 >
 > Yes, that does seem likely for the tokens test. In fact, I think this
 should fix it, if we could reproduce:
 > https://github.com/mikeperry-
 tor/tor/commit/b61cd3709be53dd0aee55111dc0c29b882c31cc6

 The 0.4.0 and master builds all failed due to this bug after #29599 was
 merged.

 But only the "Image: Visual Studio 2017; Environment:
 target=x86_64-w64-mingw32..." jobs failed, so it might be timing-
 sensitive. Or the OS bug might happen reliably on Windows Server 2016.

 You can remote desktop to the build machine if you want:
 https://www.appveyor.com/docs/how-to/rdp-to-build-worker/

 It will be easier to set up if you use your own appveyor account, not
 Tor's.

 > However, I have no idea why the rtt test is failing. It almost seems
 like a compiler bug.

 It's an OS bug:
 https://gitweb.torproject.org/tor.git/tree/src/lib/time/compat_time.c#n543
 https://www.python.org/dev/peps/pep-0418/#windows-queryperformancecounter

 Which tor works around by pretending that no time has elapsed:
 https://gitweb.torproject.org/tor.git/tree/src/lib/time/compat_time.c#n175

 More generally, there is no guarantee that the monotonic clock will have
 increased by at least 1000 nanoseconds between monotime_init() and
 circpad_estimate_circ_rtt_on_received()'s call to
 monotime_absolute_usec(). A non-increasing value is more likely when the
 monotonic clock's resolution is in milliseconds: two calls can easily
 return the same value.

 But the circuitpadding code assumes that monotime_absolute_usec() is
 always greater than zero.

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

Re: [tor-bugs] #28192 [Core Tor/Tor]: Work out why 0.3.5 and later fail chutney (but 0.3.4 and earlier do not)

[Tor Bug Tracker & Wiki]

#28192: Work out why 0.3.5 and later fail chutney (but 0.3.4 and earlier do not)
-+
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.5.3-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  regression, 035-can  |  Actual Points:
Parent ID:  #20647   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by teor):

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


Comment:

 We've made a lot of fixes to 0.3.4 and later. Let's reopen new issues for
 any version-specific bugs.

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

Re: [tor-bugs] #26288 [Core Tor/Tor]: prop289: Implement authenticated SENDME

[Tor Bug Tracker & Wiki]

#26288: prop289: Implement authenticated SENDME
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop289, 035-roadmap-master, 035 |  Actual Points:
  -triaged-in-20180711, prop289-assigned-|
  sponsor-v, 041-proposed-on-roadmap, network-   |
  team-roadmap-2019-Q1Q2 |
Parent ID:   | Points:  21
 Reviewer:  nickm|Sponsor:
 |  SponsorV
-+-

Comment (by teor):

 Replying to [comment:14 dgoulet]:
 > Replying to [comment:13 teor]:
 >
 >
 > > Replying to [comment:12 dgoulet]:
 > >
 > > >
 > > > ...
 > > >
 > > > So a piece missing is the integration with protover. I'm not
 entirely sure how to proceed code wise because what I've tried with
 `SendMe=1` and it was not working. Basically, what I need is a
 confirmation that what is proposed makes sense and is doable that way. If
 so, I'll push the commit that implements this and will ask nickm to hunt
 down why it is failing.
 > > >
 > >
 > > SENDMEs are part of circuits and streams, so we could increment the
 Relay protocol version:
 >
 > H the only reason I created a `SendMe` here is because it would have
 made `Relay` a bit messier... but I guess overall that is what we've
 designed Protover to support anyway.
 >
 > Edit: After some discussions with Nick on IRC, problem with Relay is
 that we would need two new versions, that is "Auth. SENDME + tap" and
 "Auth. SENDME + ntor"... and that means using `Relay` implies a large
 matrix of versions every time we change a different cell type.
 >
 > So the suggestion would be something like `FlowCtrl=`, have an implicit
 "1" that is current situation and add the value for `2` that would be for
 prop289.

 You can do it this way: just like HSIntro etc.

 > ~~We already have a SENDME version (0) that all tor supports. And now we
 want to support v1. In order for protover to "stop" the use of v0, we then
 need to introduce two new versions to `Relay` which right now would be 3
 and 4.~~
 >
 > ~~Then to remove the usage of v0, we would advertise `Relay=1-2,4` which
 should effectively exit() every client that does NOT support v1 that is
 `Relay=4`.~~

 I think there's some confusion here.

 The current Relay protocols are:
 1. TAP and all the features in Tor 0.2.3 (including whatever flow control
 was in 0.2.3)
 2. ntor and all the features in Tor 0.2.4.19, including TAP and all the
 features in 0.2.3 (including whatever flow control was in 0.2.4.19)
 https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n2012

 But I think you're right overall: we don't know if we want to turn off TAP
 first, or the old flow control first. So a new protocol is a good idea.

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

Re: [tor-bugs] #26288 [Core Tor/Tor]: prop289: Implement authenticated SENDME

[Tor Bug Tracker & Wiki]

#26288: prop289: Implement authenticated SENDME
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop289, 035-roadmap-master, 035 |  Actual Points:
  -triaged-in-20180711, prop289-assigned-|
  sponsor-v, 041-proposed-on-roadmap, network-   |
  team-roadmap-2019-Q1Q2 |
Parent ID:   | Points:  21
 Reviewer:  nickm|Sponsor:
 |  SponsorV
-+-
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 I reviewed the protocol parts of this patch:

 Phase 3 of the transition plan requires old clients and relays to download
 a consensus so they learn that they should stop trying to connect to the
 network. But since 0.2.8, clients (and censored relays that can't access
 any DirPorts) will try to use the ORPort to download a consensus. But
 ORPort circuits from legacy clients will fail during phase 3.

 Here's what I think we need to do:
 1. always allow legacy sendmes for BEGINDIR for the consensus, and
 everything that is required to validate a consensus:
   * authority certificates,
   * relay descriptors (for bridge clients),
   * anything else?
 2. Revise the transition plan, so it includes the protover changes and the
 consensus parameter changes
 3. Don't remove the section about extensive testing using chutney:
 {{{
 -   We'll want to do a bunch of testing in chutney before flipping the
 -   switches in the real network: I've long suspected we still have bugs
 -   in our sendme timing, and this proposal might expose some of them.
 }}}
 4. Do the chutney tests now, and do them again when we want to implement
 each phase on the public network

 The spec and the code are also out of sync: the spec talks about FlowCtrl,
 but the code doesn't have FlowCtrl.

 Here are the changes I think we need to make:

 1. Add FlowCtrl=1 to the protocols advertised by relays in C
 2. Add FlowCtrl=1 to the protocols advertised by relays in Rust
 3. Clarify "FlowCtrl" in the spec:
 {{{
Tor clients and relays that don't support this protover version from
 the
consensus "required-client-protocols" or "required-relay-protocols"
 lines
will exit and thus not try to join the network. Here is the proposed
 value:

   "FlowCtrl"

   Describes the flow control protocol at the circuit and stream level.
   If there is no FlowCtrl protocol version, tor supports the
 unauthenticated
   flow control features from its supported Relay protocols.
 }}}

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

Re: [tor-bugs] #22029 [Core Tor/Tor]: Allow ed25519 keys to be banned in the approved-routers file

[Tor Bug Tracker & Wiki]

#22029: Allow ed25519 keys to be banned in the approved-routers file
-+-
 Reporter:  teor |  Owner:  neel
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-triage-20180328, |  Actual Points:
  034-removed-20180328   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * reviewer:  teor =>


Comment:

 I don't have time to do this review next week: I need to focus on #23588
 (large, IPv6, needs tests) and #29280 (chutney).

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

Re: [tor-bugs] #28348 [Core Tor/Tor]: Setting DisableNetwork won't disable NEED_NET events

[Tor Bug Tracker & Wiki]

#28348: Setting DisableNetwork won't disable NEED_NET events
+
 Reporter:  nickm   |  Owner:  (none)
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  034-backport-unreached  |  Actual Points:
Parent ID:  | Points:  0
 Reviewer:  dgoulet |Sponsor:
+
Changes (by teor):

 * status:  merge_ready => closed
 * keywords:  034-backport => 034-backport-unreached
 * resolution:   => fixed


Comment:

 Closing as no-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] #29599 [Core Tor/Tor]: Test failure due to missing sr_state_free[_all]() in shared-random unit tests

[Tor Bug Tracker & Wiki]

#29599: Test failure due to missing sr_state_free[_all]() in shared-random unit
tests
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Major| Resolution:  fixed
 Keywords:  tor-ci, tor-test, memory-leak,   |  Actual Points:
  external-change, 029-backport, 033-backport,   |
  034-backport, 035-backport, 040-backport,  |
  nickm-merge|
Parent ID:   | Points:  0.5
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by teor):

 * status:  merge_ready => closed
 * resolution:   => fixed
 * milestone:  Tor: 0.3.5.x-final => Tor: 0.2.9.x-final


Comment:

 These builds worked in 0.4.0 and master, so I merged pr/730 to 0.2.9 and
 later, and pr/731 to 0.3.3 and later.

 (I accidentally pushed in-between, so there may be some temporary build
 failures on 0.3.3, 0.3.4, and 0.3.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

[tor-bugs] #29611 [Applications/Tor Browser]: Work around lack of app.update.enabled pref in Firefox 63+

[Tor Bug Tracker & Wiki]

#29611: Work around lack of app.update.enabled pref in Firefox 63+
--+---
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  meek moat
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 Firefox 63 removes the app.update.enabled pref that we used to prevent the
 meek and Moat profiles from downloading their own updates (#14203).
 https://bugzilla.mozilla.org/show_bug.cgi?id=1420514

 As far as I can tell, there isn't a replacement for the pref. The attached
 patch works around it by setting other prefs:
 {{{
 user_pref("app.update.interval", 9); // don't check for updates
 user_pref("app.update.auto", false); // if downloaded, don't automatically
 install
 user_pref("app.update.doorhanger", false); // don't show an update notice
 in the UI
 }}}

 I noticed this while testing with a newer Firefox in #28168. I tested
 setting these prefs in a Tor Browser 8.0.6, and they didn't have any
 harmful effect.

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

Re: [tor-bugs] #29611 [Applications/Tor Browser]: Work around lack of app.update.enabled pref in Firefox 63+

[Tor Bug Tracker & Wiki]

#29611: Work around lack of app.update.enabled pref in Firefox 63+
--+--
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  meek moat |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

 * Attachment "0001-Bug-29611-New-way-to-disable-updates-in-meek-Moat-
 pr.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] #29611 [Applications/Tor Browser]: Work around lack of app.update.enabled pref in Firefox 63+

[Tor Bug Tracker & Wiki]

#29611: Work around lack of app.update.enabled pref in Firefox 63+
--+--
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  meek moat |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

 * status:  assigned => 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

[tor-bugs] #29612 [Core Tor/Tor]: Update the documentation for ExitRelay

[Tor Bug Tracker & Wiki]

#29612: Update the documentation for ExitRelay
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.4.1.x-final
Component:  Core |Version:  Tor: 0.3.5.1-alpha
  Tor/Tor|   Keywords:  fast-fix, doc, 035-backport,
 Severity:  Normal   |  040-backport
Actual Points:   |  Parent ID:
   Points:  0.1  |   Reviewer:
  Sponsor:   |
-+-
 In #21530 in 0.3.5, we changed the default of ExitRelay: relays used to be
 exits by default, but now they are not.

 But we forgot to update the documentation.

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

Re: [tor-bugs] #29612 [Core Tor/Tor]: Update the documentation for ExitRelay

[Tor Bug Tracker & Wiki]

#29612: Update the documentation for ExitRelay
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  fast-fix, doc, 035-backport, |  Actual Points:
  040-backport   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  assigned => needs_review


Comment:

 See my pull request:
 https://github.com/torproject/tor/pull/741

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

Re: [tor-bugs] #21530 [Core Tor/Tor]: Make ExitRelay 0 the default when there is no exit policy

[Tor Bug Tracker & Wiki]

#21530: Make ExitRelay 0 the default when there is no exit policy
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-exit tor-relay configuration |  implemented
  usability expectations |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:  mikeperry|Sponsor:
-+-

Comment (by teor):

 We forgot to update the documentation when we made this change, see
 #29612.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29613 [Core Tor/Tor]: Make relays into exits when ExitRelay is auto and IPv6Exit is 1

[Tor Bug Tracker & Wiki]

#29613: Make relays into exits when ExitRelay is auto and IPv6Exit is 1
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.5.1-alpha
 Severity:  Normal|   Keywords:  ipv6, 041-proposed
Actual Points:|  Parent ID:
   Points:  0.5   |   Reviewer:
  Sponsor:|
--+
 In #21530, we made relays exit if ExitRelay is auto, and either:
 * ReducedExitPolicy is 1, or
 * ExitPolicy is set

 But a relay operator who sets IPv6Exit to 1 also wants to be an exit.

 So we should add `IPv6Exit 1` to the options that activate exits when
 ExitRelay is auto. We should also update the documentation (see #29612).

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

Re: [tor-bugs] #21530 [Core Tor/Tor]: Make ExitRelay 0 the default when there is no exit policy

[Tor Bug Tracker & Wiki]

#21530: Make ExitRelay 0 the default when there is no exit policy
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-exit tor-relay configuration |  implemented
  usability expectations |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:  mikeperry|Sponsor:
-+-

Comment (by teor):

 We didn't make `IPv6Exit 1` activate exit mode, but maybe it should, see
 #29613.

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

Re: [tor-bugs] #29613 [Core Tor/Tor]: Make relays into exits when ExitRelay is auto and IPv6Exit is 1

[Tor Bug Tracker & Wiki]

#29613: Make relays into exits when ExitRelay is auto and IPv6Exit is 1
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, 041-proposed, tor-relay, tor-  |  Actual Points:
  exit   |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  ipv6, 041-proposed => ipv6, 041-proposed, tor-relay, tor-exit


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

Re: [tor-bugs] #29500 [Core Tor/Tor]: Broken circuitpadding unittests on appveyor

[Tor Bug Tracker & Wiki]

#29500: Broken circuitpadding unittests on appveyor
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  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, 041-proposed, 040-must|
Parent ID:  #28631   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:11 teor]:
 > Replying to [comment:10 mikeperry]:
 > > Replying to [comment:9 asn]:
 > > > Mike, wrt the `test_circuitpadding_tokens()` test, could it be
 another case where the test actually schedules legit padding because of a
 state transition or something and it might trigger or might not depending
 on how the timing of the test goes?  Like the one from #29122?
 > >
 > > Yes, that does seem likely for the tokens test. In fact, I think this
 should fix it, if we could reproduce:
 > > https://github.com/mikeperry-
 tor/tor/commit/b61cd3709be53dd0aee55111dc0c29b882c31cc6
 >
 > The 0.4.0 and master builds all failed due to this bug after #29599 was
 merged.
 >
 > But only the "Image: Visual Studio 2017; Environment:
 target=x86_64-w64-mingw32..." jobs failed, so it might be timing-
 sensitive. Or the OS bug might happen reliably on Windows Server 2016.
 >
 > You can remote desktop to the build machine if you want:
 > https://www.appveyor.com/docs/how-to/rdp-to-build-worker/
 >
 > It will be easier to set up if you use your own appveyor account, not
 Tor's.

 Or you could create your best fix for these issues, get it merged, and
 then see if it fails again?

 It might be easier that messing around with RDP: there's no guarantee
 you'd be able to reproduce the timing issues on Appveyor within the 1 hour
 job limit.

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

Re: [tor-bugs] #29585 [Core Tor/Tor]: Intermittent test failures in dir/dirserv_read_measured_bandwidths

[Tor Bug Tracker & Wiki]

#29585: Intermittent test failures in dir/dirserv_read_measured_bandwidths
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:  Tor:
  |  unspecified
 Severity:  Normal| Resolution:
 Keywords:  tor-ci, tor-test, tor-bwauth  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:6 juga]:
 > Replying to [comment:5 teor]:
 > > Unstable tests can fail, even if there are no changes to any code run
 by that test.
 >
 > what is an unstable test?

 A test that sometimes passes, and sometimes fails.

 > > Is there an obvious error in dirserv_read_measured_bandwidths that
 caused the failure?
 >
 > No, but let me try to explain what i see in case helps you to come out
 with an explanation.
 >
 > The test [0] that is failing is testing a bandwidth file with only the
 timestamp and a new line.
 > `dirserv_read_measured_bandwidths` should parse the timestamp correctly,
 assign `bw_file_headers` and return 0.
 >
 > It could return -1 instead of 0 in case:
 > - Can't open the bandwidth file
 > - The bandwidth file is empty

 There could have been a temporary file descriptor shortage, but that is
 unlikely.
 Permissions issues usually cause tests to fail all the time.

 > - The timestamp line doesn't end with new line
 > - The timestamp can't be parsed as integer

 File corruption is unlikely.

 > - The timestamp is old

 How old?

 > All of this is initialized in the test, and in theory, correctly. And if
 it's not, it should then fail all the times.

 What if the the time changed on the local system between tests?

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

Re: [tor-bugs] #28525 [Core Tor/Tor]: Make tor_addr_is_internal_() aware of RFC 6598 (Carrier Grade NAT/Large Scale NAT) IPv4 Ranges

[Tor Bug Tracker & Wiki]

#28525: Make tor_addr_is_internal_() aware of RFC 6598 (Carrier Grade NAT/Large
Scale NAT) IPv4 Ranges
-+-
 Reporter:  neel |  Owner:  neel
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, 040-deferred-20190220  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  nickm|Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:17 nickm]:
 > looks okay to me.  I'd like Teor to take one last look too, if they're
 free.  Then let's merge!

 I don't think this patch changes Tor's behaviour at all:
 * Tor previously returned 0 for RFC6598 addresses.
 * This patch adds a new check for RFC6598 addresses, and then changes the
 calling code to pass IP_LISTEN_EXTERNAL, so that RFC6598 addresses always
 return 0 anyway.

 Here's what I think the patch should do:
 * When connecting, RFC6598 addresses are like internal addresses, because
 they are not publicly routable, so tor can not connect to relay ports on
 these addresses
 * When listening, RFC6598 addresses are like external addresses, because
 other people might be able to access them, so tor should not listen to
 client ports on these addresses
 In short, RFC6598 addresses should be treated just like 0.0.0.0.

 After we make that code change, here's how we can make
 tor_addr_is_internal_() easier to understand:
 * document the return value of the function for localhost or local
 networks in RFC1918 or RFC4193 or RFC4291
 * document the return value of the function for 0.0.0.0 and RFC6598
 addresses:
   * when for_listening is set
   * when for_listening is not set
 * explain *why* 0.0.0.0 and RFC6598 addresses are treated differently when
 for_listening is set (see my explanation above)

 After we make these changes, I don't think IP_LISTEN_INTERNAL will ever be
 used in Tor. So we should remove IP_LISTEN_INTERNAL and
 IP_LISTEN_EXTERNAL, and just go back to passing 0 or 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] #28525 [Core Tor/Tor]: Make tor_addr_is_internal_() aware of RFC 6598 (Carrier Grade NAT/Large Scale NAT) IPv4 Ranges

[Tor Bug Tracker & Wiki]

#28525: Make tor_addr_is_internal_() aware of RFC 6598 (Carrier Grade NAT/Large
Scale NAT) IPv4 Ranges
-+-
 Reporter:  neel |  Owner:  neel
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, 040-deferred-20190220  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  nickm|Sponsor:
-+-

Comment (by teor):

 Here is what would happen in each of these cases, if we do what I describe
 in my last comment:

 Replying to [comment:11 nickm]:
 > The main purpose of the rest of my review here is to see what else we
 would need to change to make sure this change is safe.  I'm going to do
 this by looking at all the users of tor_addr_is_internal in the codebase.
 >
 >* In warn_nonlocal_client_ports(), we will stop warning about binding
 a socksport to one of these addresses.  Is this a problem?  I need more
 guidance from others.

 We would continue to warn when client ports are on RFC6598 addresses.

 >* In warn_nonlocal_ext_orports(), we will stop warning about binding
 an extorport to one of these addresses.  (same note as above)

 We would continue to warn when extorports are on RFC6598 addresses.

 >* In connection_is_rate_limited(), we no longer count connections to
 or from one of these addresses as having any rate limits.

 We would not rate-limit connections to RFC6598 addresses (addr is the
 remote address). That's a rare case, and probably ok for clients with
 private bridges on the same local network. It might be slightly worse for
 (multiple) clients, with rate limiting, on the same mobile network as a
 private bridge, but that's a rare case.

 If intra-RFC6598 network connections become a more common case, we could
 add a FOR_RATE_LIMITING flag, and mark RFC6598 addresses as external when
 FOR_RATE_LIMITING is passed. Let's do that if needed, in a separate
 ticket.

 >* In channeltls.c [which calls tor_addr_is_internal via
 is_local_addr()], we count any OR connections to these addresses as
 "local", which seems unwise.

 channel_is_local() is only called by onionskin_answer(), before calling
 router_orport_found_reachable(). (There are other calls, but they're only
 used for logging.)

 We would stop calling router_orport_found_reachable() for remote
 connections from RFC6598 addresses, which is good.

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

Re: [tor-bugs] #28329 [Applications/Tor Browser]: Design TBA+Orbot configuration UI/UX

[Tor Bug Tracker & Wiki]

#28329: Design TBA+Orbot configuration UI/UX
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, ux-team, TBA-a3, |  Actual Points:
  TorBrowserTeam201902   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by gk):

 https://stackoverflow.com/questions/8692328/causing-outofmemoryerror-in-
 frame-by-frame-animation-in-android seems relevant here providing a bunch
 of ideas to try.

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