Re: [tor-bugs] #31567 [Applications/Tor Browser]: NS_tsnprintf() does not handle %s correctly on Windows

2019-08-31 Thread Tor Bug Tracker & Wiki
#31567: NS_tsnprintf() does not handle %s correctly on Windows
-+-
 Reporter:  mcs  |  Owner:  gk
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:22 mcs]:
 > gk -- hopefully the `UPDATE_SETTINGS_FILE_CHANNEL` error is caused by
 your test setup. However, in case Kathy and I need to do some debugging
 tomorrow, can you tell me how to apply your patch from comment:17 during
 the build? Do I just need to place your patch in
 `projects/mingw-w64-clang/31567.patch`? And will rbm then automatically
 rebuild the mingw-w64-clang project?

 I backported the potential patches Martin provided and am currently
 testing the build in my `bug_31567`. You could use that one if needed.

 I try to look closer into the error I got later today but still hope that
 this is due to us not having proper support for updating nightly builds
 yet.

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

Re: [tor-bugs] #31564 [Applications/Tor Browser]: Android bundles based on ESR 68 are not built reproducibly anymore

2019-08-31 Thread Tor Bug Tracker & Wiki
#31564: Android bundles based on ESR 68 are not built reproducibly anymore
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908, GeorgKoppen201908|
Parent ID:  #30324   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:13 sisbell]:
 > Looks like Signal created an apkdiff script that ignores resources.arsc
 >
 > https://github.com/signalapp/Signal-
 Android/blob/master/apkdiff/apkdiff.py
 >
 > Briar went the route of a deterministic file system
 >
 > https://code.briarproject.org/briar/briar-
 reproducer/commit/22d04ff8bba956ec9647fd583ec655df691e15e5
 >
 > Are either of these approaches workable for us?

 Sounds to me like wallpapering over the underlying problem by taking extra
 steps during the verification process to work around the still existing
 differences, no? If so, I am not a big fan of those approaches.

 > A third route is to build and patch the gradle plugin ourselves but I
 have been unable to find the elusive change-id that google mentions.

 Yes, that's the preferred way I think.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31380 [Applications/Tor Browser]: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.11' not found (required by ./TorBrowser/Tor/PluggableTransports/snowflake-client)

2019-08-31 Thread Tor Bug Tracker & Wiki
#31380: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.11' not 
found
(required by ./TorBrowser/Tor/PluggableTransports/snowflake-client)
--+--
 Reporter:  xhdix |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  snowflake, tbb-rbm|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 Replying to [comment:9 arma]:
 > gk, what is different with 9.02a vs 9.01a?

 We bumped the GCC version for Linux bundles to 8.3.0 (from 6.4.0).
 However, it is weird that this is affecting only snowflake. I'd suspect
 either the whole bundle would not work if Tor Browser gets started the
 recommended way or everything...

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31568 [Applications/Tor Browser]: Update How to Create Gradle Dependencies

2019-08-31 Thread Tor Bug Tracker & Wiki
#31568: Update How to Create Gradle Dependencies
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  nightly, TorBrowserTeam201908  |
Parent ID:  #30324   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 Looking through the logs further, I think one way to solve this is to
 parse out missing resource entries into another file. Then remove those
 missing resource entries from the download-urls.txt file.


 {{{
 02:28:51.107 [INFO]
 [org.gradle.internal.resource.transport.http.HttpClientHelper] Resource
 missing. [HTTP HEAD: https://repo.maven.apache.org/maven2/org/torproject
 /tor-android-binary/0.3.5.8-rc-v2/tor-android-binary-0.3.5.8-rc-v2.jar]

 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30665 [Applications/Tor Browser]: Get Firefox 68 ESR Working with latest android toolchain

2019-08-31 Thread Tor Bug Tracker & Wiki
#30665: Get Firefox 68 ESR Working with latest android toolchain
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  nightly, TorBrowserTeam201908  |
Parent ID:  #30324   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by sisbell):

 * status:  needs_revision => needs_review


Comment:

 https://github.com/sisbell/tor-browser-
 build/commit/407b762b487a94803ed95bc24eddc55e9a65ff3b

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31568 [Applications/Tor Browser]: Update How to Create Gradle Dependencies

2019-08-31 Thread Tor Bug Tracker & Wiki
#31568: Update How to Create Gradle Dependencies
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  nightly, TorBrowserTeam201908  |
Parent ID:  #30324   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 I found out what was going on here. The logs will attempt to download a
 URL and then later in the logs the build will log the artifact as not
 found. Then it moves on to try the same artifact at another repo. this
 records two entries (the new grep I provided filters out potentially the
 good site, keeping the bad one so we shouln't use it).

 I have no idea how to coordinate the log flow to see if it is successful
 without writing a custom program to track state. All of this changes if we
 move to another version of Gradle, since the logs are not a consistent
 forma. I'm not sure that it is worth the time to create a custom log
 parser.

 In my case, I would have multiple entries in the download-urls.txt. When I
 process it, my program excludes any artifact it doesn't find so everything
 is correct in the gradle-dependency file.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28942 [Circumvention/Snowflake]: Evaluate pion WebRTC

2019-08-31 Thread Tor Bug Tracker & Wiki
#28942: Evaluate pion WebRTC
+--
 Reporter:  backkem |  Owner:  cohosh
 Type:  enhancement | Status:  accepted
 Priority:  Medium  |  Milestone:
Component:  Circumvention/Snowflake |Version:
 Severity:  Normal  | Resolution:
 Keywords:  anti-censorship-roadmap-august  |  Actual Points:
Parent ID:  | Points:  5
 Reviewer:  |Sponsor:
|  Sponsor28-must
+--

Comment (by dcf):

 Replying to [comment:46 cohosh]:
 > Update on this: I tried building with pion/webrtc v2.0.23 (using
 pion/sctp v1.6.4 and otherwise sticking to the versions specified in
 `go.mod` for webrtc v2.0.23) and it bootstraps fully.

 I tried this hint here:
  * [https://gitweb.torproject.org/user/dcf/tor-browser-build.git/log/?h
 =pion-webrtc&id=6bfc0beea25295c04cb9a1753ea0a433786500e4 pion-webrtc]
 branch
  * https://people.torproject.org/~dcf/pt-bundle/tor-browser-pion-
 webrtc-20190901-6bfc0beea2/

 However it still doesn't work for me :/ Maybe I misunderstood what you
 suggested. I re-ran the [attachment:gomodtorbm gomodtorbm] script with
 pion-webrtc at v2.0.23 and restored the manual fixups. Then I singularly
 upgraded pion-sctp to v1.6.4. You can see exactly the changes
 [https://gitweb.torproject.org/user/dcf/tor-browser-build.git/commit/?h
 =pion-webrtc&id=6bfc0beea25295c04cb9a1753ea0a433786500e4 here]. Does it
 look right?

 It's also possible there's something wrong with my local network setup.
 Can someone try one of the bundles in https://people.torproject.org/~dcf
 /pt-bundle/tor-browser-pion-webrtc-20190901-6bfc0beea2/ and see if it
 works? The log output I get is different from what I got in comment:43 and
 comment:45. No data flows after the initial `Buffered X bytes --> WebRTC`.
 {{{
 2019/08/31 18:35:51 Negotiating via BrokerChannel...
 Target URL:  snowflake-broker.azureedge.net
 Front URL:   ajax.aspnetcdn.com
 2019/08/31 18:35:52 SOCKS accepted:  {[scrubbed]  map[]}
 2019/08/31 18:35:52 BrokerChannel Response:
 200 OK

 2019/08/31 18:35:52 Received Answer.
 2019/08/31 18:35:52  Handler: snowflake assigned 
 2019/08/31 18:35:53 Buffered 322 bytes --> WebRTC
 2019/08/31 18:35:58 Traffic Bytes (in|out): 0 | 322 -- (0 OnMessages, 1
 Sends)
 2019/08/31 18:36:02 WebRTC: At capacity [1/1]  Retrying in 10 seconds...
 2019/08/31 18:36:12 WebRTC: At capacity [1/1]  Retrying in 10 seconds...
 2019/08/31 18:36:22 WebRTC: At capacity [1/1]  Retrying in 10 seconds...
 2019/08/31 18:36:23 WebRTC: No messages received for 30 seconds -- closing
 stale connection.
 2019/08/31 18:36:23 WebRTC: closing PeerConnection
 2019/08/31 18:36:23 WebRTC: Closing
 2019/08/31 18:36:23 copy loop ended
 2019/08/31 18:36:23  Handler: closed ---
 2019/08/31 18:36:23 SOCKS listening...
 2019/08/31 18:36:23 synthesizing SIGTERM because of stdin close
 2019/08/31 18:36:23 WebRTC: melted all 0 snowflakes.
 2019/08/31 18:36:23 snowflake is done.
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31564 [Applications/Tor Browser]: Android bundles based on ESR 68 are not built reproducibly anymore

2019-08-31 Thread Tor Bug Tracker & Wiki
#31564: Android bundles based on ESR 68 are not built reproducibly anymore
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908, GeorgKoppen201908|
Parent ID:  #30324   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 MUST READ: https://f-droid.org/en/docs/Reproducible_Builds/

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31564 [Applications/Tor Browser]: Android bundles based on ESR 68 are not built reproducibly anymore

2019-08-31 Thread Tor Bug Tracker & Wiki
#31564: Android bundles based on ESR 68 are not built reproducibly anymore
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908, GeorgKoppen201908|
Parent ID:  #30324   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 > The latest version that worked was using
 com.android.tools.build:gradle:3.0.1, buildToolsVersion '26.0.2' and
 aaptOptions { cruncherEnabled = false }
 So, did you test with just adding `aaptOptions { cruncherEnabled = false
 }`?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31564 [Applications/Tor Browser]: Android bundles based on ESR 68 are not built reproducibly anymore

2019-08-31 Thread Tor Bug Tracker & Wiki
#31564: Android bundles based on ESR 68 are not built reproducibly anymore
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908, GeorgKoppen201908|
Parent ID:  #30324   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 Looks like Signal created an apkdiff script that ignores resources.arsc

 https://github.com/signalapp/Signal-Android/blob/master/apkdiff/apkdiff.py

 Briar went the route of a deterministic file system

 https://code.briarproject.org/briar/briar-
 reproducer/commit/22d04ff8bba956ec9647fd583ec655df691e15e5

 Are either of these approaches workable for us?

 A third route is to build and patch the gradle plugin ourselves but I have
 been unable to find the elusive change-id that google mentions.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31567 [Applications/Tor Browser]: NS_tsnprintf() does not handle %s correctly on Windows

2019-08-31 Thread Tor Bug Tracker & Wiki
#31567: NS_tsnprintf() does not handle %s correctly on Windows
-+-
 Reporter:  mcs  |  Owner:  gk
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 gk -- hopefully the `UPDATE_SETTINGS_FILE_CHANNEL` error is caused by your
 test setup. However, in case Kathy and I need to do some debugging
 tomorrow, can you tell me how to apply your patch from comment:17 during
 the build? Do I just need to place your patch in
 `projects/mingw-w64-clang/31567.patch`? And will rbm then automatically
 rebuild the mingw-w64-clang project?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31568 [Applications/Tor Browser]: Update How to Create Gradle Dependencies

2019-08-31 Thread Tor Bug Tracker & Wiki
#31568: Update How to Create Gradle Dependencies
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  nightly, TorBrowserTeam201908  |
Parent ID:  #30324   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 Can you try following and see if it works for you


 {{{
 cat logs/tor-android-service-android-armv7.log | grep "Performing HTTP" |
 grep -o "https://.*"; | rev | sort -t/ -u -k1,1 | rev > download-urls.txt
 }}}

 Since the de-duping is occurring on artifact name (and not the entire
 URL), we reverse the characters and sort. This puts same artifact names in
 adjacent lines. Then take only unique values for first field (artifact
 name)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24351 [Applications/Tor Browser]: Block Global Active Adversary Cloudflare

2019-08-31 Thread Tor Bug Tracker & Wiki
#24351: Block Global Active Adversary Cloudflare
-+-
 Reporter:  nullius  |  Owner:
 |  cypherpunks
 Type:  enhancement  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  security, privacy, anonymity, mitm,  |  Actual Points:
  cloudflare |
Parent ID:  #18361   | Points:  1000
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Re: #133

 Can someone login to github and tell Eva Comaroski about this redesign
 request?

 https://codeberg.org/crimeflare/cloudflare-tor/issues/3#issuecomment-6030

 "a fence or barbed wire could be wrapped around the cloud, or it could be
 a just barbed wire in the shape of a cloud. Maybe put an eye in the middle
 of it to signify the surveillance"

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31564 [Applications/Tor Browser]: Android bundles based on ESR 68 are not built reproducibly anymore

2019-08-31 Thread Tor Bug Tracker & Wiki
#31564: Android bundles based on ESR 68 are not built reproducibly anymore
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908, GeorgKoppen201908|
Parent ID:  #30324   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 So the 3.0.1 fails due to needing to accept license agreements for SDK.
 Notice that it is requiring build tools 26.0.2. So the downgrading the
 plugin also requires downgrading the toolchain as well.


 {{{
  0:37.28 21:25:31.055 [DEBUG]
 [org.gradle.internal.operations.DefaultBuildOperationExecutor] Build
 operation 'Configure build' completed
  0:37.37 21:25:31.062 [ERROR]
 [org.gradle.internal.buildevents.BuildExceptionReporter]
  0:37.37 21:25:31.062 [ERROR]
 [org.gradle.internal.buildevents.BuildExceptionReporter] FAILURE: Build
 failed with an exception.
  0:37.37 21:25:31.062 [ERROR]
 [org.gradle.internal.buildevents.BuildExceptionReporter]
  0:37.37 21:25:31.062 [ERROR]
 [org.gradle.internal.buildevents.BuildExceptionReporter] * What went
 wrong:
  0:37.37 21:25:31.062 [ERROR]
 [org.gradle.internal.buildevents.BuildExceptionReporter] A problem
 occurred configuring project ':app'.
  0:37.37 21:25:31.062 [ERROR]
 [org.gradle.internal.buildevents.BuildExceptionReporter] > You have not
 accepted the license agreements of the following SDK components:
  0:37.37 21:25:31.062 [ERROR]
 [org.gradle.internal.buildevents.BuildExceptionReporter]   [Android SDK
 Build-Tools 26.0.2].
  0:37.37 21:25:31.062 [ERROR]
 [org.gradle.internal.buildevents.BuildExceptionReporter]   Before building
 your project, you need to accept the license agreements and complete the
 installation of the missing components using the Android Studio SDK
 Manager.
  0:37.37 21:25:31.062 [ERROR]
 [org.gradle.internal.buildevents.BuildExceptionReporter]   Alternatively,
 to learn how to transfer the license agreements from one workstation to
 another, go to http://d.android.com/r/studio-ui/export-licenses.html
  0:37.37 21:25:31.062 [ERROR]
 [org.gradle.internal.buildevents.BuildExceptionReporter]

 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31380 [Applications/Tor Browser]: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.11' not found (required by ./TorBrowser/Tor/PluggableTransports/snowflake-client)

2019-08-31 Thread Tor Bug Tracker & Wiki
#31380: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.11' not 
found
(required by ./TorBrowser/Tor/PluggableTransports/snowflake-client)
--+---
 Reporter:  xhdix |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  snowflake, tbb-rbm|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by arma):

 gk, what is different with 9.02a vs 9.01a?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31564 [Applications/Tor Browser]: Android bundles based on ESR 68 are not built reproducibly anymore

2019-08-31 Thread Tor Bug Tracker & Wiki
#31564: Android bundles based on ESR 68 are not built reproducibly anymore
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908, GeorgKoppen201908|
Parent ID:  #30324   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 I tried just adding the 3.0.1 plugin and it did not build


 {{{
  0:37.44 21:25:31.172 [DEBUG]
 [org.gradle.launcher.daemon.server.exec.ExecuteBuild] The daemon has
 finished executing the build.
  0:37.44 21:25:31.228 [DEBUG]
 [org.gradle.launcher.daemon.client.DaemonClient] Received result
 Failure[value=org.gradle.initialization.ReportedException:
 org.gradle.internal.exceptions.LocationAwareException: A problem occurred
 configuring project ':app'.] from daemon DaemonInfo{pid=4198,
 address=[5ae804d2-ef75-4ba7-9d8c-51a300cbcdd7 port:46335,
 addresses:[/0:0:0:0:0:0:0:1, /127.0.0.1]], state=Busy,
 lastBusy=1567286702135, context=DefaultDaemonContext[uid=62e70e30-6e9a-
 4c42-91a7-9887ca646824,javaHome=/usr/lib/jvm/java-8-openjdk-
 amd64,daemonRegistryDir=/var/tmp/dist/android-
 
toolchain/gradle/daemon,pid=4198,idleTimeout=12,daemonOpts=-Xmx4608M,-Dfile.encoding=utf-8,-Duser.country=US,-Duser.language=en,-Duser.variant]}
 (build should be done).
  0:37.44 21:25:31.228 [DEBUG]
 [org.gradle.launcher.daemon.client.DaemonClientConnection] thread 1:
 dispatching class org.gradle.launcher.daemon.protocol.Finished
  0:37.82 Traceback (most recent call last):
  0:37.82   File "/usr/lib/python2.7/runpy.py", line 174, in
 _run_module_as_main
  0:37.82 "__main__", fname, loader, pkg_name)
  0:37.82   File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
  0:37.82 exec code in run_globals
  0:37.82   File "/var/tmp/build/firefox-
 2dbb7aefeaeb/python/mozbuild/mozbuild/action/file_generate.py", line 120,
 in 
  0:37.82 sys.exit(main(sys.argv[1:]))
  0:37.82   File "/var/tmp/build/firefox-
 2dbb7aefeaeb/python/mozbuild/mozbuild/action/file_generate.py", line 71,
 in main
  0:37.82 ret = module.__dict__[method](output,
 *args.additional_arguments, **kwargs)
  0:37.82   File "/var/tmp/build/firefox-
 2dbb7aefeaeb/mobile/android/gradle.py", line 46, in assemble_app
  0:37.82 return android('assemble-app')
  0:37.82   File "/var/tmp/build/firefox-
 2dbb7aefeaeb/mobile/android/gradle.py", line 38, in android
  0:37.82 subprocess.check_call(cmd, env=env)
  0:37.82   File "/usr/lib/python2.7/subprocess.py", line 186, in
 check_call
  0:37.82 raise CalledProcessError(retcode, cmd)
  0:37.82 subprocess.CalledProcessError: Command '['/var/tmp/build/firefox-
 2dbb7aefeaeb/obj-arm-linux-androideabi/_virtualenvs/init/bin/python',
 u'/var/tmp/build/firefox-2dbb7aefeaeb/mach', 'android', 'assemble-app']'
 returned non-zero exit status 1
  0:37.84 backend.mk:64: recipe for target '.deps/android_apks.stub' failed
  0:37.84 make[4]: *** [.deps/android_apks.stub] Error 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] #31567 [Applications/Tor Browser]: NS_tsnprintf() does not handle %s correctly on Windows

2019-08-31 Thread Tor Bug Tracker & Wiki
#31567: NS_tsnprintf() does not handle %s correctly on Windows
-+-
 Reporter:  mcs  |  Owner:  gk
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:20 gk]:
 > Okay, I got past the cert error just to hit the
 `UPDATE_SETTINGS_FILE_CHANNEL` one. Might be due to my testing setup, hard
 to say from here. What I did was copying the release certs over so that
 they can be used for nightlies as well and then I just did a `make
 nightly-windows-x86_64`.

 I cannot think of a reason why what you did would lead to a failure. The
 `UPDATE_SETTINGS_FILE_CHANNEL` error is generated when the updater cannot
 read and/or parse the file `Browser\update-settings.ini`. The contents of
 that file should look similar on all platforms and for all "flavors" of
 our builds... something like:
 {{{
 [Settings]
 ACCEPTED_MAR_CHANNEL_IDS=torbrowser-torproject-release
 }}}

 Unfortunately, Kathy and I are traveling at the moment and cannot do any
 testing. I will try to do some late tonight or tomorrow.

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

Re: [tor-bugs] #30665 [Applications/Tor Browser]: Get Firefox 68 ESR Working with latest android toolchain

2019-08-31 Thread Tor Bug Tracker & Wiki
#30665: Get Firefox 68 ESR Working with latest android toolchain
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  nightly, TorBrowserTeam201908  |
Parent ID:  #30324   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by gk):

 * status:  new => needs_revision
 * priority:  Medium => Very High


Comment:

 Additionally, please revert pointing to sysrqb's repo. `tor-
 browser-68.1.0esr-9.0` should be fine. Then you need to change

 {{{
 -  patch -p1 < $rootdir/android-dependencies.patch
 +   patch -p1 < $rootdir/android-packages.patch
 +   patch -p1 < $rootdir/android-remove-emulator.patch
 +   patch -p1 < $rootdir/android-jsocks.patch
 }}}
 Indentation.

 Is
 {{{
 +  cp /var/tmp/dist/android-toolchain/android-ndk/arm/lib64/libclang.so.6
 /var/tmp/dis
 t/android-toolchain/android-ndk/arm/lib64/libclang.so
 }}}
 needed for all architectures? If not, please copy it over only where
 appropriate. Just doing
 {{{
 +# Android does not support --enable-bundled-fonts option
 + ./mach configure --with-tor-browser-version=[%
 c("var/torbrowser_version") %] --with-distribution-id=org.torproject
 --enable-update-channel=[% c("var/torbrowser_update_channel") %] [% IF !
 c("var/android") %]--enable-bundled-fonts[% END -%] --with-branding=[%
 c("var/branding_directory") %]
 }}}
 should be enough.

 Please remove the change at `+#ac_add_options --disable-tor-browser-
 update`

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31564 [Applications/Tor Browser]: Android bundles based on ESR 68 are not built reproducibly anymore

2019-08-31 Thread Tor Bug Tracker & Wiki
#31564: Android bundles based on ESR 68 are not built reproducibly anymore
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908, GeorgKoppen201908|
Parent ID:  #30324   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:9 sisbell]:
 > The enableAapt2=false option results in a proguard error. So the current
 firefox build doesn't work out of the box with aapt2 disabled.

 I am not convinced yet we should go that route. It seems the move to
 `aapt2` might have helped in "fixing" unexplainable crashes. We should not
 risk getting those back if possible. We should maybe have hit those by now
 (and maybe users have but did not report) but, still, I am wary of
 switching back to the older tool.

 Could we downgrade the gradle plugin "easily" to an earlier version that
 was still 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] #31564 [Applications/Tor Browser]: Android bundles based on ESR 68 are not built reproducibly anymore

2019-08-31 Thread Tor Bug Tracker & Wiki
#31564: Android bundles based on ESR 68 are not built reproducibly anymore
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908, GeorgKoppen201908|
Parent ID:  #30324   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 The enableAapt2=false option results in a proguard error. So the current
 firefox build doesn't work out of the box with aapt2 disabled.


 {{{
  0:45.03 Warning: there were 13 unresolved references to classes or
 interfaces.
  0:45.03  You may need to add missing library jars or update their
 versions.
  0:45.03  If your code works fine without the missing classes, you
 can suppress
  0:45.03  the warnings with '-dontwarn' options.
  0:45.03
 (http://proguard.sourceforge.net/manual/troubleshooting.html#unresolvedclass)
  0:45.04 Warning: Exception while processing task java.io.IOException:
 Please correct the above warnings first.
  0:45.04 Thread(Tasks limiter_1): destruction
  0:45.04 > Task
 :app:transformClassesAndResourcesWithProguardForWithoutGeckoBinariesDebug
 FAILED
  0:45.04 FAILURE: Build failed with an exception.
  0:45.04 * What went wrong:
  0:45.04 Execution failed for task
 ':app:transformClassesAndResourcesWithProguardForWithoutGeckoBinariesDebug'.
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20811 [Applications/Tor Browser]: Document our recommendations for making Tor Browser the default browser

2019-08-31 Thread Tor Bug Tracker & Wiki
#20811: Document our recommendations for making Tor Browser the default browser
--+--
 Reporter:  arma  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by ggus):

 >if so we should write it down explicitly, along with some intuitions for
 why it's dangerous so people will understand why.

 We have an item in Support portal explaining that people should not do
 that:
 https://support.torproject.org/tbb/tbb-32/

 But, in Tor Browser 8.5 we have an option in Preferences saying:

 {{{
 [ ] Always check if Tor Browser is your default browser
 :( Tor Browser is not your default browser.
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31563 [Applications/Tor Browser]: Urlbar search icons disappear after browser restart

2019-08-31 Thread Tor Bug Tracker & Wiki
#31563: Urlbar search icons disappear after browser restart
-+-
 Reporter:  acat |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, TorBrowserTeam201908R, |  Actual Points:
  tbb-9.0-must-alpha |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 While testing manually I still get on first re-start no icons. Does that
 work for you now? However, on the second restart everything is as it
 should with your patch. So, I cherry-picked it to `tor-
 browser-68.1.0esr-9.0-1` (commit
 dc1c60e81e6d23560d597c390eed48b2331f005c).

 I tested on a Linux bundle by manually patching the files in the
 respective `omni.ja` files: first making sure we start with `enabledSopes`
 set to `1` and then after quitting applying your patch and setting
 `enabledScopes` to `5`. Then I cleared the startupCache and restarted
 showing the missing search icons. After another restart everything worked
 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

Re: [tor-bugs] #31564 [Applications/Tor Browser]: Android bundles based on ESR 68 are not built reproducibly anymore

2019-08-31 Thread Tor Bug Tracker & Wiki
#31564: Android bundles based on ESR 68 are not built reproducibly anymore
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908, GeorgKoppen201908|
Parent ID:  #30324   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 Replying to [comment:7 cypherpunks]:
 > > Is our reproducible builds setup broken that we did not detect that
 problem during the esr60 cycle? Or is that really a thing that got
 introduced with the new toolchain we use.
 > https://hg.mozilla.org/mozilla-central/rev/787dce710dce

 Thanks, I'll try android.enableAapt2=false and see if we get a different
 result for the resource file.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31567 [Applications/Tor Browser]: NS_tsnprintf() does not handle %s correctly on Windows

2019-08-31 Thread Tor Bug Tracker & Wiki
#31567: NS_tsnprintf() does not handle %s correctly on Windows
-+-
 Reporter:  mcs  |  Owner:  gk
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Okay, I got past the cert error just to hit the
 `UPDATE_SETTINGS_FILE_CHANNEL` one. Might be due to my testing setup, hard
 to say from here. What I did was copying the release certs over so that
 they can be used for nightlies as well and then I just did a `make
 nightly-windows-x86_64`.

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

Re: [tor-bugs] #31316 [Applications/Tor Browser]: macOS 10.15 crash on startup

2019-08-31 Thread Tor Bug Tracker & Wiki
#31316: macOS 10.15 crash on startup
--+
 Reporter:  mprogers  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

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


Comment:

 I think this got fixed on Apple's side in the latest Catalina update.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28942 [Circumvention/Snowflake]: Evaluate pion WebRTC

2019-08-31 Thread Tor Bug Tracker & Wiki
#28942: Evaluate pion WebRTC
+--
 Reporter:  backkem |  Owner:  cohosh
 Type:  enhancement | Status:  accepted
 Priority:  Medium  |  Milestone:
Component:  Circumvention/Snowflake |Version:
 Severity:  Normal  | Resolution:
 Keywords:  anti-censorship-roadmap-august  |  Actual Points:
Parent ID:  | Points:  5
 Reviewer:  |Sponsor:
|  Sponsor28-must
+--

Comment (by dcf):

 Replying to [comment:46 cohosh]:
 > I think the easiest way to go forward here is to take boklm's suggestion
 in https://trac.torproject.org/projects/tor/ticket/28325#comment:5 and
 just package up the directory supplied by `go mod vendor`. I've attached a
 zip file of working dependencies in `vendor.zip` above.

 Downloading a premade vendor.zip is a workable idea, but it does reduce
 the reproducible build's resistance to targeted attacks somewhat. To plant
 a backdoor in vendor.zip, an attacker would only have to subvert the
 computer of the developer that produces it (or the small number of
 developers who produce it and compare their copies with each other's).
 Once the vendor.zip is "blessed" with a checksum in a build script, no
 further builds will have a chance to detect the subterfuge. Maybe we could
 run the `go mod vendor` step in a `steps: fetch_sources:` step in projects
 /pion-webrtc/config instead? Compare
 [https://gitweb.torproject.org/user/dcf/tor-browser-
 build.git/tree/projects/webrtc/config?h=pion-
 webrtc&id=e7de4df2662b682acbd6937850584e65905e7a5e#n71 how it was done for
 webrtc]: projects/webrtc/config has a custom `fetch_sources` script that
 outputs a webrtc-sources-XXX.tar.gz, which is then
 [https://gitweb.torproject.org/user/dcf/tor-browser-
 build.git/tree/projects/webrtc/config?h=pion-
 webrtc&id=e7de4df2662b682acbd6937850584e65905e7a5e#n71 used] by
 projects/webrtc/build.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18705 [Applications/Tor Browser]: What does Tor browser protect against this

2019-08-31 Thread Tor Bug Tracker & Wiki
#18705: What does Tor browser protect against this
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Read the design spec https://spec.torproject.org/torbrowser-design

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28942 [Circumvention/Snowflake]: Evaluate pion WebRTC

2019-08-31 Thread Tor Bug Tracker & Wiki
#28942: Evaluate pion WebRTC
+--
 Reporter:  backkem |  Owner:  cohosh
 Type:  enhancement | Status:  accepted
 Priority:  Medium  |  Milestone:
Component:  Circumvention/Snowflake |Version:
 Severity:  Normal  | Resolution:
 Keywords:  anti-censorship-roadmap-august  |  Actual Points:
Parent ID:  | Points:  5
 Reviewer:  |Sponsor:
|  Sponsor28-must
+--

Comment (by dcf):

 Replying to [comment:43 dcf]:
 > I did a `make testbuild` using the pion-webrtc branch at
 0f31d1bcfd71bba9ef27fab3b5a6d3231c60213d and put the outputs, including
 checksums, here:
 >   https://people.torproject.org/~dcf/pt-bundle/tor-browser-pion-
 webrtc-20190829-0f31d1bcfd/

 I did another build of 0f31d1bcfd71bba9ef27fab3b5a6d3231c60213d after
 wiping out my `out/` directory, and reproduced the same checksums.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31585 [- Select a component]: start-tor-browser.desktop KConfigIni Invalid entry

2019-08-31 Thread Tor Bug Tracker & Wiki
#31585: start-tor-browser.desktop KConfigIni Invalid entry
---+--
 Reporter:  Psnarf |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Very Low   |  Component:  - Select a component
  Version: |   Severity:  Trivial
 Keywords:  .desktop escape-chars  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 According to freedesktop.org specs, among the characters that must be
 escaped is the backslash '\'. Line 32 of tor .desktop is a continuation of
 line 31. The Exec=sh.. command contains a '\' to continue the command on
 the next line. That backslash at the end of line 31 must escaped with a
 second backslash. KConfigIni flags line 32 as Invalid, missing =.

 {{{
 Fix:  \ --> \\
 }}}

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

Re: [tor-bugs] #31563 [Applications/Tor Browser]: Urlbar search icons disappear after browser restart

2019-08-31 Thread Tor Bug Tracker & Wiki
#31563: Urlbar search icons disappear after browser restart
-+-
 Reporter:  acat |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, TorBrowserTeam201908R, |  Actual Points:
  tbb-9.0-must-alpha |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by acat):

 * keywords:  ff68-esr, TorBrowserTeam201908, tbb-9.0-must-alpha =>
 ff68-esr, TorBrowserTeam201908R, tbb-9.0-must-alpha
 * status:  new => needs_review


Comment:

 There seems to be two different paths for loading search engines: from
 cache and from scratch. Initially they are loaded from scratch, and this
 seems to ignore `extensions.enabledScopes`, so the search extensions are
 installed and that's why it works on first time. After restart, engines
 are loaded from cache and in that case I think `extensions.enabledScopes`
 is enforced and previously installed search extensions are disabled (the
 icons are a moz-extension:// resource and that's probably why they
 disappear, because the extension is not enabled).

 The patch in https://github.com/acatarineu/tor-browser/commit/31563 forces
 reloading the search extensions if `extensions.enabledScopes` in the cache
 has changed, and fixes the engines when switching from 1 to 5 and
 restarting the browser.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31581 [Applications/Tor Browser]: KDE Desktop file error

2019-08-31 Thread Tor Bug Tracker & Wiki
#31581: KDE Desktop file error
--+--
 Reporter:  Psnarf|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very Low  |  Milestone:
Component:  Applications/Tor Browser  |Version:  Tor: unspecified
 Severity:  Trivial   | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * owner:  (none) => tbb-team
 * component:  Core Tor/Tor => Applications/Tor Browser


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31568 [Applications/Tor Browser]: Update How to Create Gradle Dependencies

2019-08-31 Thread Tor Bug Tracker & Wiki
#31568: Update How to Create Gradle Dependencies
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  nightly, TorBrowserTeam201908  |
Parent ID:  #30324   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 The problem still persists. It seems I got some files downloaded several
 times from different locations (that's for `tor-android-service` as an
 example):

 
https://dl.google.com/dl/android/maven2/org/jetbrains/trove4j/trove4j/20160824/trove4j-20160824.jar
 
https://dl.google.com/dl/android/maven2/org/jetbrains/trove4j/trove4j/20160824/trove4j-20160824.pom
 
https://repo.maven.apache.org/maven2/org/jetbrains/trove4j/trove4j/20160824/trove4j-20160824.jar
 
https://repo.maven.apache.org/maven2/org/jetbrains/trove4j/trove4j/20160824/trove4j-20160824.pom
 https://repo.spring.io/plugins-
 release/org/jetbrains/trove4j/trove4j/20160824/trove4j-20160824.jar
 https://repo.spring.io/plugins-
 release/org/jetbrains/trove4j/trove4j/20160824/trove4j-20160824.pom

 which your instructions do not take care of.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31584 [Applications/Tor Browser]: Clean up mingw-w64 project

2019-08-31 Thread Tor Bug Tracker & Wiki
#31584: Clean up mingw-w64 project
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  nightly, TorBrowserTeam201908, |
  GeorgKoppen201908  |
Parent ID:  #30322   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Note, we might bump the GCC version to something supported while we are at
 it. Likely 8.3.0 as we do use elsewhere.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31584 [Applications/Tor Browser]: Clean up mingw-w64 project

2019-08-31 Thread Tor Bug Tracker & Wiki
#31584: Clean up mingw-w64 project
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-rbm, ff68-esr,
 Severity:  Normal   |  tbb-9.0-must-nightly,
 |  TorBrowserTeam201908,
 |  GeorgKoppen201908
Actual Points:   |  Parent ID:  #30322
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We switched to `mingw-w64-clang` for the Firefox project and should not
 clean up the mingw-w64 as it still contains cruft related to our spec hack
 etc.

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

Re: [tor-bugs] #31567 [Applications/Tor Browser]: NS_tsnprintf() does not handle %s correctly on Windows

2019-08-31 Thread Tor Bug Tracker & Wiki
#31567: NS_tsnprintf() does not handle %s correctly on Windows
-+-
 Reporter:  mcs  |  Owner:  gk
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:18 gk]:
 > Replying to [comment:16 mcs]:
 > > Replying to [comment:14 pospeselr]:
 > > > ...
 > > > Patching the binary at runtime in windbg and letting it run results
 in these files:
 > > >
 > > > update.log:
 > > >
 > > > {{{
 > > > PATCH DIRECTORY
 C:\Users\user\Desktop\GKTest\Browser\TorBrowser\UpdateInfo\updates\0
 > > > INSTALLATION DIRECTORY C:\Users\user\Desktop\GKTest
 > > > WORKING DIRECTORY C:\Users\user\Desktop\GKTest
 > > > failed: 6
 > > > calling QuitProgressUI
 > > > }}}
 > > >
 > > > update.status:
 > > > {{{
 > > > failed: 6
 > > > }}}
 > > >
 > > > Not sure what the correct behaviour is here with regards to the
 updater but at least we get this far.
 > >
 > > I don't know why Mozilla doesn't add an errorToString() function for
 the updater error codes so they could log something more intelligible, but
 so far they have not done so. Anyway, you can find the updater error codes
 here:
 > > https://gitweb.torproject.org/tor-
 browser.git/tree/toolkit/mozapps/update/common/updatererrors.h?h=tor-
 browser-68.1.0esr-9.0-1
 > >
 > > Error 6 is `READ_ERROR` and that is probably happening because I
 forgot to tell you to copy Georg's test mar file to
 `...\updates\0\update.mar`. Sorry!
 >
 > Good point, let me test that.

 Yeah, that's been the problem. Now I get the error from `#define
 CERT_VERIFY_ERROR 19`. So, let me sign the .mar file next and try again.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31567 [Applications/Tor Browser]: NS_tsnprintf() does not handle %s correctly on Windows

2019-08-31 Thread Tor Bug Tracker & Wiki
#31567: NS_tsnprintf() does not handle %s correctly on Windows
-+-
 Reporter:  mcs  |  Owner:  gk
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:16 mcs]:
 > Replying to [comment:14 pospeselr]:
 > > ...
 > > Patching the binary at runtime in windbg and letting it run results in
 these files:
 > >
 > > update.log:
 > >
 > > {{{
 > > PATCH DIRECTORY
 C:\Users\user\Desktop\GKTest\Browser\TorBrowser\UpdateInfo\updates\0
 > > INSTALLATION DIRECTORY C:\Users\user\Desktop\GKTest
 > > WORKING DIRECTORY C:\Users\user\Desktop\GKTest
 > > failed: 6
 > > calling QuitProgressUI
 > > }}}
 > >
 > > update.status:
 > > {{{
 > > failed: 6
 > > }}}
 > >
 > > Not sure what the correct behaviour is here with regards to the
 updater but at least we get this far.
 >
 > I don't know why Mozilla doesn't add an errorToString() function for the
 updater error codes so they could log something more intelligible, but so
 far they have not done so. Anyway, you can find the updater error codes
 here:
 > https://gitweb.torproject.org/tor-
 browser.git/tree/toolkit/mozapps/update/common/updatererrors.h?h=tor-
 browser-68.1.0esr-9.0-1
 >
 > Error 6 is `READ_ERROR` and that is probably happening because I forgot
 to tell you to copy Georg's test mar file to `...\updates\0\update.mar`.
 Sorry!

 Good point, let me test that.

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

Re: [tor-bugs] #31567 [Applications/Tor Browser]: NS_tsnprintf() does not handle %s correctly on Windows

2019-08-31 Thread Tor Bug Tracker & Wiki
#31567: NS_tsnprintf() does not handle %s correctly on Windows
-+-
 Reporter:  mcs  |  Owner:  gk
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Okay, I built a new .exe with the following patch:
 {{{
 diff --git a/mingw-w64-crt/stdio/ucrt__vsnwprintf.c
 b/mingw-w64-crt/stdio/ucrt__vsnwprintf.c
 index bf9f4de2..a13286e5 100644
 --- a/mingw-w64-crt/stdio/ucrt__vsnwprintf.c
 +++ b/mingw-w64-crt/stdio/ucrt__vsnwprintf.c
 @@ -10,6 +10,6 @@

  int __cdecl _vsnwprintf(wchar_t * __restrict__ _Dest,size_t _Count,const
 wchar_t * __restrict__ _Format,va_list _Args)
 __MINGW_ATTRIB_DEPRECATED_SEC_WARN
  {
 -  return
 __stdio_common_vswprintf(UCRTBASE_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION,
 _Dest, _Count, _Format, NULL, _Args);
 +  return
 __stdio_common_vswprintf(UCRTBASE_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION
 | UCRTBASE_PRINTF_LEGACY_WIDE_SPECIFIERS, _Dest, _Count, _Format, NULL,
 _Args);
  }
  int __cdecl (*__MINGW_IMP_SYMBOL(_vsnwprintf))(wchar_t *__restrict__,
 size_t, const wchar_t *__restrict__, va_list) = _vsnwprintf;
 --
 2.23.0.rc1
 }}}
 https://people.torproject.org/~gk/testbuilds/31567.exe
 https://people.torproject.org/~gk/testbuilds/31567.exe.asc

 and took a .mar file from our recent nightly builds. That seems to get me
 past the problem we have, resulting in output similar to pospeselr's in
 comment:14.

 `failed: 6` seems to mean `#define READ_ERROR 6`. Not sure why this .mar
 file should not be readable, though. I'd have more expected a certificate
 related error as it is not signed...

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31567 [Applications/Tor Browser]: NS_tsnprintf() does not handle %s correctly on Windows

2019-08-31 Thread Tor Bug Tracker & Wiki
#31567: NS_tsnprintf() does not handle %s correctly on Windows
-+-
 Reporter:  mcs  |  Owner:  gk
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:14 pospeselr]:
 > ...
 > Patching the binary at runtime in windbg and letting it run results in
 these files:
 >
 > update.log:
 >
 > {{{
 > PATCH DIRECTORY
 C:\Users\user\Desktop\GKTest\Browser\TorBrowser\UpdateInfo\updates\0
 > INSTALLATION DIRECTORY C:\Users\user\Desktop\GKTest
 > WORKING DIRECTORY C:\Users\user\Desktop\GKTest
 > failed: 6
 > calling QuitProgressUI
 > }}}
 >
 > update.status:
 > {{{
 > failed: 6
 > }}}
 >
 > Not sure what the correct behaviour is here with regards to the updater
 but at least we get this far.

 I don't know why Mozilla doesn't add an errorToString() function for the
 updater error codes so they could log something more intelligible, but so
 far they have not done so. Anyway, you can find the updater error codes
 here:
 https://gitweb.torproject.org/tor-
 browser.git/tree/toolkit/mozapps/update/common/updatererrors.h?h=tor-
 browser-68.1.0esr-9.0-1

 Error 6 is `READ_ERROR` and that is probably happening because I forgot to
 tell you to copy Georg's test mar file to `...\updates\0\update.mar`.
 Sorry!

 If the mar file is not signed (and I suspect it may not be), it will fail
 at some point anyway... but I think you got past the problem we are trying
 to solve in this ticket.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27476 [Applications/Tor Browser]: Remove gap between Tor Launcher window and main browser window

2019-08-31 Thread Tor Bug Tracker & Wiki
#27476: Remove gap between Tor Launcher window and main browser window
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-launcher tbb-performance ux- |  Actual Points:
  team   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by intrigeri):

 * cc: intrigeri (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] #31286 [Applications/Tor Browser]: Include bridge configuration into about:preferences

2019-08-31 Thread Tor Bug Tracker & Wiki
#31286: Include bridge configuration into about:preferences
+--
 Reporter:  gk  |  Owner:  pospeselr
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201908, ff68-esr  |  Actual Points:
Parent ID:  #10760  | Points:
 Reviewer:  |Sponsor:
|  Sponsor44-can
+--
Changes (by intrigeri):

 * cc: intrigeri (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] #31564 [Applications/Tor Browser]: Android bundles based on ESR 68 are not built reproducibly anymore

2019-08-31 Thread Tor Bug Tracker & Wiki
#31564: Android bundles based on ESR 68 are not built reproducibly anymore
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908, GeorgKoppen201908|
Parent ID:  #30324   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 > Is our reproducible builds setup broken that we did not detect that
 problem during the esr60 cycle? Or is that really a thing that got
 introduced with the new toolchain we use.
 https://hg.mozilla.org/mozilla-central/rev/787dce710dce

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30461 [Applications/Tor Browser]: Update tor-android-service Project to Use Android Toolchain (Firefox 68)

2019-08-31 Thread Tor Bug Tracker & Wiki
#30461: Update tor-android-service Project to Use Android Toolchain (Firefox 68)
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  nightly, TorBrowserTeam201908  |
Parent ID:  #30324   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by cypherpunks):

 `+minVersion=21`?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31583 [Internal Services/Service - git]: Policy repo push access

2019-08-31 Thread Tor Bug Tracker & Wiki
#31583: Policy repo push access
-+
 Reporter:  atagar   |  Owner:  tor-gitadm
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Please grant Emma Peel push access to the community policy git repo...

   https://gitweb.torproject.org/community/policies.git/

 She plans to create a branch with translations.

 Thanks! -Damian

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQEcBAEBAgAGBQJdakAtAAoJEIiEBMGH8waQnFcIAJFsqCkzmvR2Y7I5JS/ivbNq
 B443/PPtFK2JwLRjVFuFUj9KOrVsen35nCOAWgb9pxUPesp3cScYjsY4hq6mkrOB
 XxX++D3lqir44vtJxcwdvKLp+ZE6WTbamsRzZOdH69q+mkkEPyb6j1MV7PwrTur6
 7NG0t3uNmFNUYnU9woBF+XVOPI3OE8ALzDZtlSQn37WUle7YgRCCH6GR20ZUVdGq
 qHr7rK3xpYj9JMEE9pxFSW38nqz6GzuVD5KkOoYurW1co46upysRGM40oMf0hPEr
 0DzsSWf6P4DI15TRYF2Isb6gdrigIR11ZyuYg8jwVqLf0fl9D2wUO+Vt3pGxtlY=
 =n1I8
 -END PGP SIGNATURE-
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31293 [Applications/Tor Browser]: tor-android-service gradle failure when probing network interfaces

2019-08-31 Thread Tor Bug Tracker & Wiki
#31293: tor-android-service gradle failure when probing network interfaces
---+--
 Reporter:  sysrqb |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201908  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by gk):

 Replying to [comment:16 sisbell]:
 > So what I found is that if we add a JVM property in the
 gradle.properties file, it forks the JVM, automatically creating a daemon
 and ignoring --no-daemon property. This is why it was working on some
 project but not others.

 The problem seems not to be different projects (like `tor-android-service`
 or `firefox`) but different machines as boklm and I seem to be unaffected
 by this bug. Or said differently: I'd assume the JVM forks are happening
 every time we build our projects if they happen but still on some setups
 this is no issue while on others it is.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31449 [Applications/Tor Browser]: Signing tools for 32bit Linux are 64bit now

2019-08-31 Thread Tor Bug Tracker & Wiki
#31449: Signing tools for 32bit Linux are 64bit now
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201908,   |  Actual Points:
  tbb-9.0-must-alpha |
Parent ID:  #30321   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:7 boklm]:
 > Replying to [comment:4 gk]:
 > >
 > > Fair enough. I was under the impression that the current state risks
 our `mar` signing AND that we do something wrong with our 32bit builds
 given that the issue did not happen in the past and we already seem to
 need some hacks to get 32bit builds going. If neither is the case, great!
 We could closed this ticket then as WORKSFORME or something similar.
 >
 > I think that we did not have this issue in the past because our
 `.mozconfig-linux-i686` file included the line `ac_add_options --host=i686
 -linux-gnu` which caused host tools to be built in 32bit. Although that
 was not really correct as the host was in reality 64bit, but it still
 worked as we can run 32bit binaries on a 64bit host.

 Makes sense. What is Mozilla doing for their 32bit builds? Do they get the
 same result as we? If so, it might be worth filing an upstream bug. If
 not, we should fix our setup.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30461 [Applications/Tor Browser]: Update tor-android-service Project to Use Android Toolchain (Firefox 68)

2019-08-31 Thread Tor Bug Tracker & Wiki
#30461: Update tor-android-service Project to Use Android Toolchain (Firefox 68)
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  nightly, TorBrowserTeam201908  |
Parent ID:  #30324   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by sisbell):

 There will also need to be a small change in firefox project: removing the
 android-jsocks.patch . Once that is done everything will build for the
 release.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30461 [Applications/Tor Browser]: Update tor-android-service Project to Use Android Toolchain (Firefox 68)

2019-08-31 Thread Tor Bug Tracker & Wiki
#30461: Update tor-android-service Project to Use Android Toolchain (Firefox 68)
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  nightly, TorBrowserTeam201908  |
Parent ID:  #30324   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by sisbell):

 * status:  needs_revision => needs_review


Comment:

 I updated the build to use the tor repo version of tor-android-service


 https://github.com/sisbell/tor-browser-
 build/commit/7dbdddb716962ee0ee7de81460762c07d8d772f7
 https://github.com/sisbell/tor-browser-build/tree/esr68_0830

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31564 [Applications/Tor Browser]: Android bundles based on ESR 68 are not built reproducibly anymore

2019-08-31 Thread Tor Bug Tracker & Wiki
#31564: Android bundles based on ESR 68 are not built reproducibly anymore
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908, GeorgKoppen201908|
Parent ID:  #30324   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 I've tried doing the linking for resources and then merging the apks but
 haven't had much luck when starting the app. I get various crashes. I'll
 investigate more.



 {{{
 08-31 02:02:43.923 31309 31309 W PackageManager: Failure retrieving xml
 0x7f130014 in package org.torproject.torbrowser
 08-31 02:02:43.923 31309 31309 W PackageManager:
 android.content.res.Resources$NotFoundException: Resource ID #0x7f130014
 08-31 02:02:43.923 31309 31309 W PackageManager:at
 android.content.res.ResourcesImpl.getValue(ResourcesImpl.java:237)
 }}}

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