Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201810  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by arthuredelstein):

 Replying to [comment:34 gk]:
 > The security risks don't map the the underlying transport ot its
 security being used. The security risks we try to tackle are to a large
 part due to the *content* that gets transferred. Someone injecting this
 content on the path from server to user is an important risk but just one
 of those we need to defend against. This binding the security state to
 HTTP/HTTPS is not sufficient. Moreover, the strongest security we want to
 provide is something like the current "safest" option we have. We won't be
 able to enable this by default probably forever as the breakage is too
 high, irrespective of the transport being used.

 We have discussed this issue previously, but I wanted to try laying it out
 in more detail and see if that helps to clarify the different approaches.
 :)

 We already have a "Safest" setting that maximizes security guarantees. I
 agree we shouldn't lower those guarantees. We also have a "Safe" (Low)
 setting which maximizes usability and already has the lowest possible
 security guarantees. That probably shouldn't change for now.

 So the question is: what should the "Safer" (Medium) level be? Given that
 the three levels are implementing a tradeoff between security and website
 usability, I think we should be willing to consider any Pareto-optimal
 choice, even if it reduces security somewhat. What is important is that
 the "Safer" level is sufficiently distinct from both "Safest" and "Safe"
 so that it is worthwhile to make it available.

 Let's compare two possible "Safer" (Medium) Security designs:

 Design (1), the status quo (Tor Browser 8.0.x):

 || || Unblocked || Blocked ||
 || HTTP || WebFont, blob, SVG || scripts, WebGL, Video, Audio, WebAudio,
 MathML, JIT ||
 || HTTPS || WebFont, blob, SVG, scripts, WebGL || Video, Audio, WebAudio,
 MathML, JIT ||

 Design (2), proposed in comment:33:
 || || Unblocked || Blocked ||
 || HTTP || || WebFont, blob, SVG, scripts, WebGL, Video, Audio, WebAudio,
 MathML, JIT ||
 || HTTPS || WebFont, blob, SVG, scripts, WebGL, Video, Audio, WebAudio,
 MathML, JIT || ||

 So, which of these two options is more secure? (1) has better security for
 HTTPS and (2) has better security for HTTP. Overall security depends on
 one's threat model.

 Consider the two main potential threats:
 (A) '''Hostile content injected at exit nodes, or between server and exit
 node.''' To combat this threat, it seems that Design (2) is somewhat
 better because it blocks the most content in HTTP.
 (B) '''Hostile content from the website itself, or subresources.''' Which
 design is safer depends on whether the hostile site is HTTP or HTTPS. If
 an HTTP site is hostile, Design (2) is preferred. If an HTTPS site is
 hostile, Design (1) is preferred.

 The next question: which of the two threats are dominant in a real user's
 threat model? I think there are different categories of users:

 (I) '''Users who are unconcerned about threats or unable to handle broken
 websites.''' For these users, "Safe" (Low) security is the (default)
 choice.
 (II) '''Users who only visit "trustworthy" sites.''' (I define
 "trustworthy" as websites the user expects will not send malicious code.)
 For these users, Threat (A) is the dominant threat and in this case,
 "Safer" security seems appropriate, and Design (2) is better.
 (III) '''Users who visit "untrustworthy" sites.''' For these users, Threat
 (B) can be the dominant threat. (But Threat (A) still exists for these
 users to the same extent as for Category (II) users. The total risk of
 being exploited is higher.) Assuming they are using the "Safer" level,
 these users may prefer Design (1), at least for HTTPS.

 Perhaps, up to this point, my description is fairly uncontroversial. ;) I
 hope this kind of analysis is useful regardless of our final decision for
 the "Safer" level.

 

 But now I want to think further about Category (III) users. These users
 are visiting untrustworthy websites; they are high-risk users. Why would
 the user want to leave SVG, WebFonts, or scripts unblocked if they think a
 site is untrustworthy? While it's true that some websites will work
 better, it seems dangerous to assume we 

Re: [tor-bugs] #28205 [Obfuscation/Snowflake]: linking against other libwebrtc binaries errors out on missing symbols

[Tor Bug Tracker & Wiki]

#28205: linking against other libwebrtc binaries errors out on missing symbols
---+
 Reporter:  eighthave  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by arlolra):

 HEAD of go-webrtc is at `88f5d9180eae78a6162cccd78850ff416eb82483` in
 webrtc, which is around `branch-heads/64`
 https://github.com/keroserene/go-webrtc/blob/master/build.sh#L12
 which is what the HEAD of snowflake matches

 But in tor-browser-build it's still on
 `c279861207c5b15fc51069e96595782350e0ac12`, circa `branch-heads/58`
 https://gitweb.torproject.org/builders/tor-browser-
 build.git/tree/projects/webrtc/config
 https://github.com/keroserene/go-
 webrtc/blob/52280a1ecdfbfc0557a962ff832dbf5632122a35/build.sh#L12
 which wants an older snowflake commit

 You need to line up your webrtc, go-webrtc, snowflake

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

Re: [tor-bugs] #28209 [Core Tor/Tor]: Add single-onion-v2-ipv6-md to chutney, and use it in Tor's make test-network-all

[Tor Bug Tracker & Wiki]

#28209: Add single-onion-v2-ipv6-md to chutney, and use it in Tor's make test-
network-all
+
 Reporter:  teor|  Owner:  teor
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  test, fast-fix  |  Actual Points:
Parent ID:  #27912  | Points:
 Reviewer:  |Sponsor:
+
Changes (by teor):

 * parent:   => #27912


Comment:

 I want to do this as part of #27912, for consistency.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28209 [Core Tor/Tor]: Add single-onion-v2-ipv6-md to chutney, and use it in Tor's make test-network-all

[Tor Bug Tracker & Wiki]

#28209: Add single-onion-v2-ipv6-md to chutney, and use it in Tor's make test-
network-all
--+
 Reporter:  teor  |  Owner:  teor
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  test, fast-fix
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 single-onion-v2-ipv6-md will be a copy of the existing single-onion-
 ipv6-md, but the onion service version will be more obvious from the name.

 Also add single-onion-v2-ipv6 for completeness.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28208 [Core Tor/Tor]: Run bridges+hs-v23 for make test-network in 0.3.5 and later

[Tor Bug Tracker & Wiki]

#28208: Run bridges+hs-v23 for make test-network in 0.3.5 and later
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  test, fast-fix
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Tor 0.3.2 and later support v3 onion services, so we should run a v3 onion
 service during our quick integration test.

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

[tor-bugs] #28207 [Core Tor/Chutney]: Cleanup duplicate and near-duplicate chutney networks

[Tor Bug Tracker & Wiki]

#28207: Cleanup duplicate and near-duplicate chutney networks
--+---
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal|   Keywords:  easy refactor
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 There are a bunch of chutney networks that are duplicates or near-
 duplicates of each other.

 Instead of duplicating code, we could turn the network code into a
 function, and then call it from all similar networks.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28206 [Core Tor/Chutney]: Add a chutney network where the HS connects via a bridge

[Tor Bug Tracker & Wiki]

#28206: Add a chutney network where the HS connects via a bridge
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 We have a network where a bridge client connects to a HS, but no network
 where a HS *is* a bridge client.

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

Re: [tor-bugs] #27417 [Core Tor/Tor]: refactor conn_close_if_marked() in main.c

[Tor Bug Tracker & Wiki]

#27417: refactor conn_close_if_marked() in main.c
--+--
 Reporter:  cyberpunks|  Owner:  (none)
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  refactor  |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+--

Comment (by cyberpunks):

 Replying to [comment:12 dgoulet]:
 > `if (conn->linked_conn && retval >= 0) {`
 > `connection_start_reading_from_linked_conn(conn->linked_conn);`
 > So here is a potential problem. With this refactor, this function can be
 called ''after'' the code below here that is moved into
 `connection_flush_before_close()`.

 The point about splitting it into a pure code movement commit and then a
 separate commit is well taken. Should do that.

 That said, it's certain there's no behavior change, because if
 `conn->linked_conn` is non-NULL, it's impossible for
 `connection_wants_to_flush(conn)` to be `true` when you reach the code
 below's `if` statement, so the code below that's moved into the new
 function was never called when this is a linked connection.
 `buf_move_to_buf()` always reduces `conn->outbuf_flushlen` to zero,
 emptying the buffer entirely.

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

Re: [tor-bugs] #24419 [Metrics/Onionoo]: Improve getter names for boolean fields

[Tor Bug Tracker & Wiki]

#24419: Improve getter names for boolean fields
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  irl  |Sponsor:
-+--

Comment (by efgyirfe784):

 My pleasure, glad I could help!

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

Re: [tor-bugs] #28068 [Applications/Tor Browser]: Tor not reopening on USB

[Tor Bug Tracker & Wiki]

#28068: Tor not reopening on USB
+--
 Reporter:  mackey  |  Owner:  tbb-team
 Type:  defect  | Status:
|  needs_information
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-regression, tbb-8.0-issues  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by mackey):

 Issue still persists with version 8.0.3

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

Re: [tor-bugs] #28195 [Applications/Tor Browser]: TB fails to restart updating 8.5a3

[Tor Bug Tracker & Wiki]

#28195: TB fails to restart updating 8.5a3
--+---
 Reporter:  traumschule   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by traumschule):

 All updates are ok, restarting fails. When TB crashes the update is not
 invoked and no last-update.log or app.update.log are created. Every
 {{{last-update.log}}} file i found ends with
 > succeeded
 > calling QuitProgressUI

 The different errors on exit do not only happen on updates, for example
 below with 8.0.3.
 My computer is slow, maybe it can be fixed by raising some timeout?
 Also folder name seems to have an effect (#28199).

 Updating 8.5a3
 {{{
 AUS:SVC Downloader:onStopRequest - setting state to: pending
 AUS:SVC getCanStageUpdates - staging updates is disabled by preference
 app.update.staging.enabled
 AUS:SVC showUpdateDownloaded - Notifying observers that an update was
 downloaded. topic: update-downloaded, status: pending
 Discarding onCreatedNavigationTarget for 27: received source tab data
 without any created tab data available
 [10-25 21:26:31] Torbutton DBUG: Got timer update, but no cookie change.
 Discarding onCreatedNavigationTarget for 27: received source tab data
 without any created tab data available
 [10-25 21:27:31] Torbutton DBUG: Got timer update, but no cookie change.
 [10-25 21:27:46] Torbutton INFO: controlPort >> 650 STREAM 51 CLOSED 6
 :443 REASON=DONE
 [10-25 21:27:53] Torbutton INFO: controlPort >> 650 STREAM 8 CLOSED 6
 :443 REASON=DONE
 [10-25 21:28:31] Torbutton DBUG: Got timer update, but no cookie change.
 AUS:SVC getCanApplyUpdates - testing write access
 /media/user/tbb/tor/manual/tor-browser_en-
 US/Browser/TorBrowser/UpdateInfo/update.test
 AUS:SVC getCanApplyUpdates - able to apply updates
 AUS:SVC getCanStageUpdates - staging updates is disabled by preference
 app.update.staging.enabled
 AUS:SVC readStatusFile - status: pending, path: /media/user/tbb/tor/manual
 /tor-browser_en-US/Browser/TorBrowser/UpdateInfo/updates/0/update.status
 [10-25 21:29:31] Torbutton DBUG: Got timer update, but no cookie change.

 
 Oct 25 21:32:14.000 [notice] Owning controller connection has closed --
 exiting now.
 Oct 25 21:32:14.000 [notice] Catching signal TERM, exiting cleanly.
 Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close
 with reason=AbnormalShutdown (t=473.767) [GFX1-]: Receive IPC close with
 reason=AbnormalShutdown
 [Child 15153, Chrome_ChildThread] WARNING: pipe error (3): Connection
 reset by peer: file /var/tmp/build/firefox-
 0c004047822a/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 353
 }}}

 Exitin 8.0.3 without (visible) update

 > FATAL ERROR: AsyncShutdown timeout in profile-before-change Conditions:
 [{"name":"Crash Reporter: blocking on
 minidumpgeneration.","state":"(none)","filename":"/var/tmp/build/firefox-
 858720263bed/ipc/glue/CrashReporterHost.cpp","lineNumber":189,"stack":"Minidump
 generation"}] At least one completion condition failed to complete within
 a reasonable amount of time. Causing a crash to ensure that we do not
 leave the user with an unresponsive process draining resources.
 > WARNING: No crash reporter available
 > [Parent 6862, Main Thread] ###!!! ABORT: file /var/tmp/build/firefox-
 858720263bed/ipc/glue/CrashReporterHost.cpp, line 189

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

Re: [tor-bugs] #28199 [Applications/Tor Browser]: Torlauncher fails when TB folder has been renamed (was: Interrupted exit damages TB)

[Tor Bug Tracker & Wiki]

#28199: Torlauncher fails when TB folder has been renamed
--+---
 Reporter:  traumschule   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Old description:

> When TB quits it takes 30 seconds to give back the prompt because tor
> wants to exit gracefully after the lines
> > [notice] Owning controller connection has closed -- exiting now.
> > [notice] Catching signal TERM, exiting cleanly.
>
> I just damaged my freshly updated 8.5a4 with ctrl+c on exit because i was
> impatient to wait. On the next start tor did not start anymore and gave
> no errors (i closed and opened TB several times without changes).
>
> The about dialog says "Firefox Quantum" and no page is loaded ({{{refused
> connection}}}).
>
> The log is missing any info on tor:
> {{{
> $ tbb-debug tor-browser_en-US8.5a4/
> Logging Tor Browser debug information to tor-browser.log
> Fontconfig warning: "/home/tbb/tor-browser_en-
> US8.5a4/Browser/TorBrowser/Data/fontconfig/fonts.conf", line 85: unknown
> element "blank"
> alloc factor 0.90 0.90
> alloc factor 0.90 0.90
> Fontconfig warning: "/home/tbb/tor-browser_en-
> US8.5a4/Browser/TorBrowser/Data/fontconfig/fonts.conf", line 85: unknown
> element "blank"
> alloc factor 0.90 0.90
> alloc factor 0.90 0.90
> Fontconfig warning: "/home/tbb/tor-browser_en-
> US8.5a4/Browser/TorBrowser/Data/fontconfig/fonts.conf", line 85: unknown
> element "blank"
> ^C
> tbb@t43:~$ tbb-debug tor-browser_en-US8.5a4/
> Logging Tor Browser debug information to tor-browser.log
> Fontconfig warning: "/home/tbb/tor-browser_en-
> US8.5a4/Browser/TorBrowser/Data/fontconfig/fonts.conf", line 85: unknown
> element "blank"
> alloc factor 0.90 0.90
> alloc factor 0.90 0.90
> Fontconfig warning: "/home/tbb/tor-browser_en-
> US8.5a4/Browser/TorBrowser/Data/fontconfig/fonts.conf", line 85: unknown
> element "blank"
> alloc factor 0.90 0.90
> alloc factor 0.90 0.90
> Fontconfig warning: "/home/tbb/tor-browser_en-
> US8.5a4/Browser/TorBrowser/Data/fontconfig/fonts.conf", line 85: unknown
> element "blank"
> ^C
> }}}
>
> Log before it was damaged:
> {{{
> $ tbb-debug tor-browser_en-US8.5a1/
> Logging Tor Browser debug information to tor-browser.log
> Fontconfig warning: "/home/tbb/tor-browser_en-
> US8.5a1/Browser/TorBrowser/Data/fontconfig/fonts.conf", line 85: unknown
> element "blank"
> alloc factor 0.90 0.90
> alloc factor 0.90 0.90
> Oct 25 11:49:34.507 [notice] Tor 0.3.5.3-alpha (git-444e9b37c53b0246)
> running on Linux with Libevent 2.1.8-stable, OpenSSL 1.0.2p, Zlib 1.2.11,
> Liblzma N/A, and Libzstd N/A.
> Oct 25 11:49:34.528 [notice] Tor can't help you if you use it wrong!
> Learn how to be safe at
> https://www.torproject.org/download/download#warning
> Oct 25 11:49:34.528 [notice] This version is not a stable Tor release.
> Expect more bugs than usual.
> Oct 25 11:49:34.546 [notice] Read configuration file "/media/user/tbb
> /tor-browser_en-US8.5a1/Browser/TorBrowser/Data/Tor/torrc-defaults".
> Oct 25 11:49:34.585 [notice] Read configuration file "/media/user/tbb
> /tor-browser_en-US8.5a1/Browser/TorBrowser/Data/Tor/torrc".
> Oct 25 11:49:34.674 [notice] Opening Socks listener on 127.0.0.1:9150
> Oct 25 11:49:34.676 [notice] Opened Socks listener on 127.0.0.1:9150
> Oct 25 11:49:34.676 [notice] Opening Control listener on 127.0.0.1:9151
> Oct 25 11:49:34.676 [notice] Opened Control listener on 127.0.0.1:9151
> Fontconfig warning: "/home/tbb/tor-browser_en-
> US8.5a1/Browser/TorBrowser/Data/fontconfig/fonts.conf", line 85: unknown
> element "blank"
> alloc factor 0.90 0.90
> alloc factor 0.90 0.90
> Fontconfig warning: "/home/tbb/tor-browser_en-
> US8.5a1/Browser/TorBrowser/Data/fontconfig/fonts.conf", line 85: unknown
> element "blank"
> ^C
> }}}
> TB should recognize that something is broken, tell the user that the
> bundle has been damaged and should be deleted and extracted again (even
> if this is obvious and users will figure it out, some may not and show up
> on #tor looking for support ..). Do we have any self-tests right now?
>
> The last message on exit should say that it needs time to clean up at the
> end or similar.

New description:

 When i rename the tor-browser folder Torlauncher does not start.
 To fix this the TorLauncher extension has to be disabled and re-enabled
 directly after. On the next start TorLauncher works as expected.

 

 When TB quits it takes 30 seconds 

Re: [tor-bugs] #28200 [Applications/Tor Browser]: Update downloader does not automatically retry when connection is interrupted (was: Update fails when connection is interrupted)

[Tor Bug Tracker & Wiki]

#28200: Update downloader does not automatically retry when connection is
interrupted
--+---
 Reporter:  traumschule   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_revision => needs_review


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

Re: [tor-bugs] #28125 [Applications/Tor Browser]: Don't let Android leak DNS queries

[Tor Bug Tracker & Wiki]

#28125: Don't let Android leak DNS queries
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, tbb-proxy-bypass  |  Actual Points:
Parent ID:  #5709 | Points:
 Reviewer:|Sponsor:
--+--

Comment (by sysrqb):

 Replying to [comment:1 new_user]:
 > -I made comment in #27822 and indeed i was using android o sdk 27
 > -so again i tested tor on android 7.1
 > -dns leaks on 7.1
 > -latest alpha leaks dns
 > -but orfox is running fine does not leaks dns at all

 Are you using a physical device or an emulator?

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

Re: [tor-bugs] #28125 [Applications/Tor Browser]: Don't let Android leak DNS queries

[Tor Bug Tracker & Wiki]

#28125: Don't let Android leak DNS queries
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, tbb-proxy-bypass  |  Actual Points:
Parent ID:  #5709 | Points:
 Reviewer:|Sponsor:
--+--
Changes (by sysrqb):

 * status:  new => needs_review


Comment:

 I have branch `28125` on my public repo. I haven't confirmed it prevents
 all leaks, yet (but it should). It simply prevents all non-Necko
 connections. A better patch will take some more 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] #28174 [Applications/Tor Browser]: Block non-.onion subresources on .onion websites?

[Tor Bug Tracker & Wiki]

#28174: Block non-.onion subresources on .onion websites?
--+--
 Reporter:  arthuredelstein   |  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 tom):

 I think there are two constituents here: The onion server, and the Browser
 user.

 Our primary goal should be to serve the browser user.

 Where it's easy and simple, we can serve the onion server. But these
 suggestions are not comprehensive, and Tor Browser will never be a
 comprehensive onion audit tool. I would instead advocate for improving the
 tool onionscan https://onionscan.org/ where it is possible (although that
 also, cannot be comprehensive...)


 Focusing on the browser user, I think it's fair to treat any non-onion
 resource as Mixed Content on an onion, regardless of HTTP/HTTPS status.
 There are three levels of Mixed Content Blocking:
  - None
  - Active (blocks scripts, allows images)
  - Full (blocks scripts and images)

 There's also the security slider. I would suggest that when the security
 slider is at High, we perform Full blocking. It provides a smaller attack
 surface for the browser user.

 When the slider is not at High; I would advocate for either Active or Full
 Blocking. Probably Active.


 * I personally would ignore the situation of a HTTPS onion including from
 a HTTP onion and give this no special treatment (that is to say it's fine,
 and it loads 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] #27443 [Applications/Tor Browser]: Update Firefox RBM config and build for Android

[Tor Bug Tracker & Wiki]

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

Comment (by sisbell):

 Changes (android-1024)

  * Directly copy the apks to dest_dir (no archive)
  * Remove martools references
  * Return directly after packaging stage for android

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

Re: [tor-bugs] #22718 [Obfuscation/Snowflake]: OpenWebRTC?

[Tor Bug Tracker & Wiki]

#22718: OpenWebRTC?
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by eighthave):

 building Chromium's libwebrtc is so vast and scary, I think this would be
 worth considering.

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

[tor-bugs] #28205 [Obfuscation/Snowflake]: linking against other libwebrtc binaries errors out on missing symbols

[Tor Bug Tracker & Wiki]

#28205: linking against other libwebrtc binaries errors out on missing symbols
---+---
 Reporter:  eighthave  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Component:  Obfuscation/Snowflake
  Version: |   Severity:  Major
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
 I have a build where it builds libwebrtc from the chromium tree from
 scratch, but it seems to be missing symbols that snowflake needs.  My
 guess is that the symbols change often in libwebrtc given there is no
 release ever, so the go-webrtc build needs to be pinned against a very
 specific version of libwebrtc.

 Here's the build where I run go-webrtc's ./build.sh script:
 https://gitlab.com/eighthave/snowflake/-/jobs/112538917

 {{{
 $ go get ./...
 # github.com/keroserene/go-webrtc
 /tmp/go-build263677836/b053/_x008.o: In function `CGO_DeserializeSDP':
 /go/src/github.com/keroserene/go-webrtc/peerconnection.cc:379: undefined
 reference to
 `webrtc::JsepSessionDescription::JsepSessionDescription(std::string
 const&)'
 /go/src/github.com/keroserene/go-webrtc/peerconnection.cc:382: undefined
 reference to `webrtc::SdpDeserialize(std::string const&,
 webrtc::JsepSessionDescription*, webrtc::SdpParseError*)'
 /tmp/go-build263677836/b053/_x008.o: In function `CGO_AddIceCandidate':
 /go/src/github.com/keroserene/go-webrtc/peerconnection.cc:421: undefined
 reference to `webrtc::CreateIceCandidate(std::string const&, int,
 std::string const&, webrtc::SdpParseError*)'
 /tmp/go-build263677836/b053/_x008.o: In function `Peer::Initialize()':
 /go/src/github.com/keroserene/go-webrtc/peerconnection.cc:57: undefined
 reference to `rtc::Thread::SetName(std::string const&, void const*)'
 /go/src/github.com/keroserene/go-webrtc/peerconnection.cc:58: undefined
 reference to `rtc::Thread::SetName(std::string const&, void const*)'
 /tmp/go-build263677836/b053/_x008.o: In function `rtc::ArrayView::ArrayView(bool*, unsigned long)':
 /go/src/github.com/keroserene/go-webrtc/./include/api/array_view.h:157:
 undefined reference to `rtc::FatalMessage::FatalMessage(char const*, int,
 std::string*)'
 /tmp/go-build263677836/b053/_x008.o: In function `rtc::ArrayView::ArrayView(int*, unsigned long)':
 /go/src/github.com/keroserene/go-webrtc/./include/api/array_view.h:157:
 undefined reference to `rtc::FatalMessage::FatalMessage(char const*, int,
 std::string*)'
 }}}

 Then I ran a build against the official google libwebrtc binaries for
 Android, and that is missing many more symbols:
 https://gitlab.com/eighthave/snowflake/-/jobs/112339118

 {{{
 # github.com/keroserene/go-webrtc
 peerconnection.cc:379: error: undefined reference to
 
'webrtc::JsepSessionDescription::JsepSessionDescription(std::__ndk1::basic_string, std::__ndk1::allocator > const&)'
 peerconnection.cc:382: error: undefined reference to
 'webrtc::SdpDeserialize(std::__ndk1::basic_string, std::__ndk1::allocator > const&,
 webrtc::JsepSessionDescription*, webrtc::SdpParseError*)'
 peerconnection.cc:420: error: undefined reference to
 'webrtc::CreateIceCandidate(std::__ndk1::basic_string, std::__ndk1::allocator > const&,
 int, std::__ndk1::basic_string,
 std::__ndk1::allocator > const&, webrtc::SdpParseError*)'
 peerconnection.cc:55: error: undefined reference to
 'rtc::Thread::Thread()'
 peerconnection.cc:56: error: undefined reference to
 'rtc::Thread::Thread()'
 peerconnection.cc:57: error: undefined reference to
 'rtc::Thread::SetName(std::__ndk1::basic_string, std::__ndk1::allocator > const&,
 void const*)'
 peerconnection.cc:58: error: undefined reference to
 'rtc::Thread::SetName(std::__ndk1::basic_string, std::__ndk1::allocator > const&,
 void const*)'
 peerconnection.cc:59: error: undefined reference to
 'rtc::Thread::Start(rtc::Runnable*)'
 peerconnection.cc:60: error: undefined reference to
 'rtc::Thread::Start(rtc::Runnable*)'
 peerconnection.cc:62: error: undefined reference to
 'FakeAudioCaptureModule::Create()'
 peerconnection.cc:67: error: undefined reference to
 'webrtc::CreateBuiltinAudioEncoderFactory()'
 peerconnection.cc:68: error: undefined reference to
 'webrtc::CreateBuiltinAudioDecoderFactory()'
 /go/pkg/gomobile/ndk-toolchains/arm/bin/../lib/gcc/arm-linux-
 androideabi/4.9.x/../../../../include/c++/4.9.x/string:0: error: undefined
 reference to 'webrtc::MediaConstraintsInterface::kEnableDtlsSrtp'
 /go/pkg/gomobile/ndk-toolchains/arm/bin/../lib/gcc/arm-linux-
 androideabi/4.9.x/../../../../include/c++/4.9.x/string:0: error: undefined
 reference to 'webrtc::MediaConstraintsInterface::kEnableDtlsSrtp'
 ./include/api/peerconnectioninterface.h:1289: error: undefined reference
 to 'webrtc::CreatePeerConnectionFactory(rtc::Thread*, rtc::Thread*,
 rtc::Thread*, webrtc::AudioDeviceModule*,
 rtc::scoped_refptr,
 

Re: [tor-bugs] #19409 [Obfuscation/Snowflake]: Make a deb of snowflake and get into Debian

[Tor Bug Tracker & Wiki]

#19409: Make a deb of snowflake and get into Debian
---+
 Reporter:  adrelanos  |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by eighthave):

 its kind of like building Tor Browser to get one of the libraries.

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

Re: [tor-bugs] #19409 [Obfuscation/Snowflake]: Make a deb of snowflake and get into Debian

[Tor Bug Tracker & Wiki]

#19409: Make a deb of snowflake and get into Debian
---+
 Reporter:  adrelanos  |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by eighthave):

 Now that I'm digging into building libwebrtc, I have to say that building
 a Debian package of Snowflake based on the Chromium libwebrtc will be a
 ton of work.  The libwebrtc build system is vast and insane.  It literally
 downloads Debian stretch images for both i386 and amd64 as part of the
 process:

 {{{
  running '/usr/bin/python src/build/linux/sysroot_scripts/install-
 sysroot.py --running-as-hook' in '/go/src/github.com/keroserene/go-
 webrtc/third_party/webrtc'
 Installing Debian Stretch amd64 root image: /go/src/github.com/keroserene
 /go-webrtc/third_party/webrtc/src/build/linux/debian_stretch_amd64-sysroot
 Downloading https://commondatastorage.googleapis.com/chrome-linux-
 
sysroot/toolchain/2202c161310ffde63729f29d27fe7bb24a0bc540/debian_stretch_amd64_sysroot.tar.xz
 }}}

 see the full build log here:
 https://gitlab.com/eighthave/snowflake/-/jobs/112538917

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

Re: [tor-bugs] #27439 [Applications/Tor Browser]: Configure Rust compiler to target Android Platform

[Tor Bug Tracker & Wiki]

#27439: Configure Rust compiler to target Android Platform
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201810   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 Replying to [comment:14 boklm]:

 > In commit `992b9324097f41c9503eb4ada393cec3da03195c`, the patch is
 removing the empty line before `targets:`, but I think we should keep it
 as it separates the different parts of the file. Other than this it looks
 good to me.
 >
 > > I removed extra line

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

Re: [tor-bugs] #28007 [Core Tor/Tor]: shellcheck: scan-build.sh issues

[Tor Bug Tracker & Wiki]

#28007: shellcheck: scan-build.sh issues
--+
 Reporter:  rl1987|  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  catalyst  |Sponsor:
--+
Changes (by catalyst):

 * status:  needs_review => needs_information


Comment:

 Thanks for working on this! At first glance the changes themselves seem
 reasonable.

 Do we really want to restrict ourselves to platforms with bash, or ones
 where it might not be in /bin? I'm not sure we have guidelines for this.

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

Re: [tor-bugs] #28193 [Core Tor/Tor]: Compile-time assertion

[Tor Bug Tracker & Wiki]

#28193: Compile-time assertion
--+
 Reporter:  riastradh |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  new => needs_review
 * milestone:   => Tor: 0.3.6.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] #27845 [Applications/Tor Browser]: Tor Browser 8.0.1 - on MacOS desktop platforms, the default Tor Browser window size is 1000 Wide x 0998 High, not 1000 Wide x 1000 High. Is this a def

[Tor Bug Tracker & Wiki]

#27845: Tor Browser 8.0.1 - on MacOS desktop platforms, the default Tor Browser
window size is 1000 Wide x 0998 High, not 1000 Wide x 1000 High. Is this a
defect?
-+-
 Reporter:  monmire  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting-resolution,   |  Actual Points:
  tbb-8.0-issues, tbb-regression |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by monmire):

 In Tor Browser 8.0.3, the same identical regression present in Tor Browser
 8.0.2, as described in comment:5, still persists in Tor Browser 8.0.3.

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

Re: [tor-bugs] #28197 [Core Tor/sbws]: Rename some bandwidth file keys in the code

[Tor Bug Tracker & Wiki]

#28197: Rename some bandwidth file keys in the code
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28085 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by juga):

 Replying to [comment:3 teor]:
 [...]

 > When I worked as a database designer, we named fields using this
 pattern:
 > * optional Adjective(s) (words that modify the thing)
 > * Noun (what the thing is)
 > * optional Adjectives (words that modify the format of the data)
 > * Kind (what format the data is in)

 It's a similar pattern i was trying to follow. The main differences being:
 - in all the other humans languages i know, adjetives come after noun, so
 even if the key names are in English, my way of thinking gives more
 importance to the noum.
 - i'd have thought that units (Kind) comes at the end, except that after
 naming the keys with only nouns and units, i wanted other keys with
 adjetives to start with that noun + unit + adjetive. This was probably a
 bad choice, since i'd still put _ls for list or other "Kind"s at the end.

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

Re: [tor-bugs] #27417 [Core Tor/Tor]: refactor conn_close_if_marked() in main.c

[Tor Bug Tracker & Wiki]

#27417: refactor conn_close_if_marked() in main.c
--+--
 Reporter:  cyberpunks|  Owner:  (none)
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  refactor  |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+--
Changes (by dgoulet):

 * status:  needs_review => needs_revision
 * milestone:  Tor: 0.3.6.x-final => Tor: unspecified


Comment:

 One comment on the PR.

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

Re: [tor-bugs] #28200 [Applications/Tor Browser]: Update fails when connection is interrupted

[Tor Bug Tracker & Wiki]

#28200: Update fails when connection is interrupted
--+---
 Reporter:  traumschule   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by traumschule):

 * cc: teor (added)


Comment:

 > Is this filed upstream already?
 https://bugzilla.mozilla.org/show_bug.cgi?id=701733
 https://bugzilla.mozilla.org/show_bug.cgi?id=606373
 https://bugzilla.mozilla.org/show_bug.cgi?id=1367084
 So it's known at least. And i wanted to CC teor before.

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

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201810  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by gk):

 Replying to [comment:35 antonela]:
 > Hi geko, thanks for the heads-up; already read the diff. Seems like you
 have a strong opinion for keeping the slider.

 Not at all. I do want, though, not lower the security guarantees AND the
 usability we currently offer. So, the redesign we currently have in mind
 should provide the same guarantees + better usability. If we get to that
 then that's a good result for this iteration with hopefully other
 iterations to come.

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

Re: [tor-bugs] #27771 [Community]: Update PreventingDnsLeaksInTor wiki page

[Tor Bug Tracker & Wiki]

#27771: Update PreventingDnsLeaksInTor wiki page
--+
 Reporter:  traumschule   |  Owner:  alison
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Community |Version:
 Severity:  Normal| Resolution:
 Keywords:  dns leak tor  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by traumschule):

 Some new things appeared in the pad.

 Today i got the hint to use dnsmasq to avoid issues when torifying
 applications. Trac has following on this:
 - [[doc/LinuxDNSresolverForOnions]]
 - #6228 #20930 #12756
 - comment:9:issue:2370
 - comment:3:issue:18079 comment:3:issue:9782
 - comment:41:issue:3374
 - comment:52:issue:24497

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

Re: [tor-bugs] #28200 [Applications/Tor Browser]: Update fails when connection is interrupted

[Tor Bug Tracker & Wiki]

#28200: Update fails when connection is interrupted
--+---
 Reporter:  traumschule   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by gk):

 Replying to [comment:2 traumschule]:
 > I went through tickets filed by teor in 2016 and 2017 to check if this
 is maybe a duplicate. These are related to the updater:
 > #16812 #18186 #20150 #22598 #22598 #23115 #23798
 >
 > > What is Firefox 60 ESR doing in such a case?
 > Unplugging the cable did not irritate it much, it just continued when
 replugging it after some time. However the update is so small that i had
 to {{{wondershaper [iface] 10 10}}}, still then it did not show a progress
 bar, just a spinner with "Checking for updates..." and then the restart
 button.
 > So i used iptables to drop packets for the created firefox user
 ({{{iptables -I OUTPUT -m owner --uid-owner 100X -j DROP}}}), started
 firefox and it claimed "Firefox is up to date". Is this filed upstream
 already?

 Good question, I don't know.

 > Maybe giving users the chance to interact with a Refresh button is
 easier than implementing a lot of logic here.

 Could be, yes.

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

Re: [tor-bugs] #28200 [Applications/Tor Browser]: Update fails when connection is interrupted

[Tor Bug Tracker & Wiki]

#28200: Update fails when connection is interrupted
--+---
 Reporter:  traumschule   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by traumschule):

 I went through tickets filed by teor in 2016 and 2017 to check if this is
 maybe a duplicate. These are related to the updater:
 #16812 #18186 #20150 #22598 #22598 #23115 #23798

 > What is Firefox 60 ESR doing in such a case?
 Unplugging the cable did not irritate it much, it just continued when
 replugging it after some time. However the update is so small that i had
 to {{{wondershaper [iface] 10 10}}}, still then it did not show a progress
 bar, just a spinner with "Checking for updates..." and then the restart
 button.
 So i used iptables to drop packets for the created firefox user
 ({{{iptables -I OUTPUT -m owner --uid-owner 100X -j DROP}}}), started
 firefox and it claimed "Firefox is up to date". Is this filed upstream
 already?

 Maybe giving users the chance to interact with a Refresh button is easier
 than implementing a lot of logic here.

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

Re: [tor-bugs] #27690 [Core Tor/Tor]: Update bandwidth-file-spec with scaling methods

[Tor Bug Tracker & Wiki]

#27690: Update bandwidth-file-spec with scaling methods
--+-
 Reporter:  juga  |  Owner:  juga
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec, tor-bwauth  |  Actual Points:
Parent ID:  #27107| Points:
 Reviewer:|Sponsor:
--+-
Changes (by juga):

 * status:  assigned => needs_review


Comment:

 https://github.com/torproject/torspec/pull/37

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

Re: [tor-bugs] #28194 [Internal Services/Tor Sysadmin Team]: Please add komlo to the job-anticensor email alias distribution list

[Tor Bug Tracker & Wiki]

#28194: Please add komlo to the job-anticensor email alias distribution list
-+
 Reporter:  ewyatt   |  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  High |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by ln5):

 * 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] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201810  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by antonela):

 Hi geko, thanks for the heads-up; already read the diff. Seems like you
 have a strong opinion for keeping the slider.

 Let's do it again:

 **2.1.1 Removing HTTPS Everywhere and NoScript from the Toolbar**

 OK

 **2.1.2 Showing Security Slider State**

 We tried this before and this is the latest prototype I have: ​

 https://marvelapp.com/383eaa9/screen/44007368

 Should we iterate over it again? Are we happy with the icon? Do we want a
 different icon?

 >
 >To mitigate that problem we could at least warn users about the possible
 danger and provide the option to acquire a New Identity right after
 changing the security slider level.

 Suggest a New Identity after the global setting change, seems smart. We
 can do that right after the user change about:preferences#security. A
 message that says "You may need a New Identity to apply changes safely.
 Your tabs will reload, and some information could be missed" will help.

 >
 >We'll add a security settings button to the toolbar which shows the
 current slider state but, once clicked on, opens an about:preferences
 panel in a new tab which contains the security slider.

 Something like this?
 [[Image(https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/25658/25658-preferences.png, 700px)]]

 **2.1.3 Reorganizing the Toolbar**

 OK

 ** 2.2 Dealing with Per-Site Security Settings**

 > One way to do that would be to use the Permissions section which opens
 after clicking on the "i" icon in the URL bar.

 Ok. It should look similar to

 [[Image(https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/25658/25658%20-%207.png, 700px)]]

 >
 > We should refrain from exposing icons for every single "active content"
 in the URL bar, though. Rather, besides the button for temporarily
 allowing JavaScript we would only add one additional, which is responsible
 for manipulating and showing the state of "active content" (like WebGL,
 SVG, fonts etc.).

 Where do you think it should have place? At the Control Center doorhanger?

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

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201810  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---
Changes (by antonela):

 * Attachment "25658 - 7.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] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201810  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---
Changes (by antonela):

 * Attachment "25658-preferences.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] #28201 [Applications/Tor Browser]: about:support shows "Firefox" (was: about:support shows Firefox)

[Tor Bug Tracker & Wiki]

#28201: about:support shows "Firefox"
--+--
 Reporter:  traumschule   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-branding  |  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] #28201 [Applications/Tor Browser]: about:support shows Firefox

[Tor Bug Tracker & Wiki]

#28201: about:support shows Firefox
--+--
 Reporter:  traumschule   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-branding  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:   => tbb-branding


Comment:

 Yes, the refresh option is #24993. The support link is #23129. The
 onboardin ID is okay, we use the code from Mozilla with slight
 modifications.

 I guess what we could say is "Tor Browser" instead of "Firefox" and then
 on the next line our version (like "8.5a4) and in parentheses "based on
 Mozilla Firefox 60.3.0esr" similar to the about Tor Browser dialog.

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

Re: [tor-bugs] #28195 [Applications/Tor Browser]: TB fails to restart updating 8.5a3

[Tor Bug Tracker & Wiki]

#28195: TB fails to restart updating 8.5a3
--+---
 Reporter:  traumschule   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * cc: mcs, brade (added)
 * status:  new => needs_information


Comment:

 Do you find a `last-update.log` file in your Tor Browser when the update
 fails? That might give us some clue about what is going on. It might be
 worth enabling `app.update.log` as well and check in the browser console
 that everything is fine before the browser is supposed to get restarted.

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

Re: [tor-bugs] #28200 [Applications/Tor Browser]: Update fails when connection is interrupted

[Tor Bug Tracker & Wiki]

#28200: Update fails when connection is interrupted
--+---
 Reporter:  traumschule   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * cc: mcs, brade (added)
 * status:  new => needs_information


Comment:

 What is Firefox 60 ESR doing in such a case? I.e. is that a more generic
 bug in Firefox's code or something we messed up when adding our patches?

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

Re: [tor-bugs] #22598 [Applications/Tor Browser]: When updater read fails, About Tor Browser and Quit stop working

[Tor Bug Tracker & Wiki]

#22598: When updater read fails, About Tor Browser and Quit stop working
--+---
 Reporter:  teor  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by teor):

 Replying to [comment:1 mcs]:
 > We don't do too much to change the way the updater works in terms of
 processes and file access, so this is likely a Firefox bug. How can I
 reproduce it? Do you have special software that prevents new binaries from
 accessing files? Or is this something I can reproduce use macOS settings?

 Here are three possible ways to reproduce issues like this:
 1. use FSecure XFence (used to be called Little Flocker) to deny access to
 files
 2. install Tor Browser as an admin user, but open it as a non-admin user
 3. do 2, but also turn on macOS parental controls, and allow Tor Browser
 4. do 2, but also turn on macOS parental controls, and don't allow Tor
 Browser

 You will get a range of interesting errors.

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

Re: [tor-bugs] #28082 [Applications/Tor Browser]: Add 4 more Tor Browser locales

[Tor Bug Tracker & Wiki]

#28082: Add 4 more Tor Browser locales
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam201810R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 Commit e0701803216baa74b4166c34a7b85e00f8e327af (on `master` in `tor-
 browser-build`), 30fee1c708e5e6cae9c41105847e4d95deec2f20 (on `master` in
 `tor-launcher`), and b9d1a5a7f2808f533d32ffab11ad7ddb566888ec (on `master`
 in `torbutton`) should finally have  the changes. I updated the
 translations in Torbutton as well (commit
 a62f5e98572d2dd6bcc5d7310dfbb431bcd6fec7 and
 bff597351775e60648e37e3328e424176d41b712) to make sure we don't miss
 strings for those locales.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28204 [Core Tor/Chutney]: Make chutney log the verify progress for each circuit

[Tor Bug Tracker & Wiki]

#28204: Make chutney log the verify progress for each circuit
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core |Version:
  Tor/Chutney|   Keywords:  test, chutney, consistency,
 Severity:  Normal   |  jenkins, integration-testing, continuous-
 |  integration
Actual Points:   |  Parent ID:  #20647
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Chutney lists the circuits that it's building, but it doesn't say which
 ones have succeeded, and which ones have failed.

 Let's log (some of) the following events for each circuit:
 * circuit open / connect or fail to connect
 * first data sent or fail to send
 * first data received or fail to verify
 * each 10%? of data, or each second, or something?
 * last data sent
 * last data received

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => needs_revision


Comment:

 Looking at commit `370168b7b2b00dcd72e51e6a229d7720cfe69c5d`, currently
 the output of the build is a `tor-browser.tar.gz` file containing two apk
 files in a `Browser/` directory. Instead I think we could just copy the
 two apk files to the destination directory (`[% dest_dir _ '/' _
 c('filename') %]`), after creating it. And after the apk files are copied,
 I think we can add a `[% RETURN %]` if none of the following lines apply
 to the android build (and in that case also remove all the `var/martools`
 changes).

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

[tor-bugs] #28203 [Core Tor/Chutney]: Make chutney log the bootstrap progress for each node

[Tor Bug Tracker & Wiki]

#28203: Make chutney log the bootstrap progress for each node
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core |Version:
  Tor/Chutney|   Keywords:  test, chutney, consistency,
 Severity:  Normal   |  jenkins, integration-testing, continuous-
 |  integration
Actual Points:   |  Parent ID:  #20647
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 To solve #20473 and implement #22132, we need to know when nodes have
 bootstrapped.

 Bootstrap progress is also useful when debugging failures.

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

Re: [tor-bugs] #28202 [Core Tor/Tor]: Bad end-of-string check in get_next_token (CID various)

[Tor Bug Tracker & Wiki]

#28202: Bad end-of-string check in get_next_token (CID various)
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-backport 033-backport|  Actual Points:
  034-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  accepted => 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] #28202 [Core Tor/Tor]: Bad end-of-string check in get_next_token (CID various)

[Tor Bug Tracker & Wiki]

#28202: Bad end-of-string check in get_next_token (CID various)
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-backport 033-backport|  Actual Points:
  034-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * owner:  (none) => nickm
 * status:  new => accepted


Comment:

 see branches:
* bug28202_029 -- PR https://github.com/torproject/tor/pull/442
* bug28202_033 -- PR https://github.com/torproject/tor/pull/443
* bug28202_035 -- PR https://github.com/torproject/tor/pull/444

 Note that there is C pointer math here, along with ugly code and code
 movement that affected the merges.

 I'd support refactoring this code entirely in the future but for now I
 think we can't, at least not in these releases.

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

Re: [tor-bugs] #20473 [Core Tor/Chutney]: Fix Chutney Nodes that don't bootstrap

[Tor Bug Tracker & Wiki]

#20473: Fix Chutney Nodes that don't bootstrap
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #20647| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * parent:  #27912 => #20647


Comment:

 Not required for #27912.

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

Re: [tor-bugs] #28013 [Core Tor/Tor]: run test-network-all in Travis CI

[Tor Bug Tracker & Wiki]

#28013: run test-network-all in Travis CI
-+-
 Reporter:  catalyst |  Owner:
 |  catalyst
 Type:  enhancement  | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  test, chutney, consistency,  |  Actual Points:
  integration-testing, continuous-integration,   |
  tor-ci |
Parent ID:  #20647   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 I added some chutney diagnostics as part of #27912.

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

Re: [tor-bugs] #27913 [Core Tor/Tor]: Add test-stem to travis-ci if possible

[Tor Bug Tracker & Wiki]

#27913: Add test-stem to travis-ci if possible
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  enhancement   | Status:  merge_ready
 Priority:  High  |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ci travis |  Actual Points:
Parent ID:| Points:
 Reviewer:  catalyst  |Sponsor:
--+

Comment (by teor):

 On the stem side, I'll try to do #28170 this week, but it might not be
 ready until late next week.

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

Re: [tor-bugs] #27912 [Core Tor/Chutney]: Add travis CI for the Chutney repository

[Tor Bug Tracker & Wiki]

#27912: Add travis CI for the Chutney repository
--+
 Reporter:  nickm |  Owner:  teor
 Type:  enhancement   | Status:  needs_revision
 Priority:  High  |  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #20647| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:13 teor]:
 > ...
 > I want to copy the `make test-network-all` networks from each tor
 version into the travis config. Then I'll be done with this branch.

 Since this is chutney, I'll just run the networks from tor stable on
 stable, and any extra networks in master on nightly. That's enough.

 Then I need to decide on a default network: either basic-min, or chutney's
 default bridges-etc-etc-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] #27912 [Core Tor/Chutney]: Add travis CI for the Chutney repository

[Tor Bug Tracker & Wiki]

#27912: Add travis CI for the Chutney repository
--+
 Reporter:  nickm |  Owner:  teor
 Type:  enhancement   | Status:  needs_revision
 Priority:  High  |  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #20647| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by teor):

 We can't fix 0.3.4 and earlier, so I want to run them twice (or however
 long it takes to get an acceptable error rate), and make the test pass if
 either succeeds.

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

Re: [tor-bugs] #28120 [Core Tor/Tor]: hs_descriptor: CID 1440368: Incorrect expression (SIZEOF_MISMATCH)

[Tor Bug Tracker & Wiki]

#28120: hs_descriptor: CID 1440368:  Incorrect expression  (SIZEOF_MISMATCH)
-+
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  coverity tor-hs  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

 * milestone:   => Tor: 0.3.5.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] #28142 [Core Tor/Tor]: Merge original WTF-PAD branch

[Tor Bug Tracker & Wiki]

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

Comment (by asn):

 I started doing the review, and I put some general comments in github. I'm
 far from done.

 I also started testing it with chutney and it seems to work pretty nicely.
 I have some local changes that add some extra logs, but I'm gonna push
 them after I do more testing.

 Mike, you have any tips for more effective testing of this feature?

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

Re: [tor-bugs] #28201 [Applications/Tor Browser]: about:support shows Firefox

[Tor Bug Tracker & Wiki]

#28201: about:support shows Firefox
--+--
 Reporter:  traumschule   |  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 traumschule):

 - The page also shows a link to
 https://support.mozilla.org/1/firefox/60.3.0/Linux/en-US/
 - Under Features the onboarding ID is {{{onboard...@mozilla.org}}}.

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

Re: [tor-bugs] #27690 [Core Tor/Tor]: Update bandwidth-file-spec with scaling methods

[Tor Bug Tracker & Wiki]

#27690: Update bandwidth-file-spec with scaling methods
--+-
 Reporter:  juga  |  Owner:  juga
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec, tor-bwauth  |  Actual Points:
Parent ID:  #27107| Points:
 Reviewer:|Sponsor:
--+-

Comment (by teor):

 Replying to [comment:7 juga]:
 > Should we also describe the PID control feedback method or only the
 method without?.
 > I think that if we are not describing other parts on how Torflow works
 now, then we should not include it either, since it is not being used.

 Let's focus on documenting sbws, not torflow.

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

[tor-bugs] #28202 [Core Tor/Tor]: Bad end-of-string check in get_next_token (CID various)

[Tor Bug Tracker & Wiki]

#28202: Bad end-of-string check in get_next_token (CID various)
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  029-backport 033-backport
 Severity:  Normal   |  034-backport
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 There's a coverity warning about an overflow in test_parsecommmon.  I
 think it is happening because of this code:
 {{{
  *s + 16 >= eol
 }}}

 That's the wrong way to test for end-of-string, since C says that *s+16 is
 undefined behavior if the resulting pointer would be more than 1 off the
 end of the allocated byte array.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28201 [Applications/Tor Browser]: about:support shows Firefox

[Tor Bug Tracker & Wiki]

#28201: about:support shows Firefox
--+--
 Reporter:  traumschule   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Similar to #27905. Also this page has a Refresh button that offers to mess
 up the profile.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.5.3-alpha
 Severity:  Normal| Resolution:
 Keywords:  035-must, regression  |  Actual Points:
Parent ID:  #20647| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 0.3.4 seems to fail about 5% of the time, but it also seems to depend on
 travis load.

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

Re: [tor-bugs] #27439 [Applications/Tor Browser]: Configure Rust compiler to target Android Platform

[Tor Bug Tracker & Wiki]

#27439: Configure Rust compiler to target Android Platform
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201810   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * status:  needs_review => needs_revision


Comment:

 In commit `992b9324097f41c9503eb4ada393cec3da03195c`, the patch is
 removing the empty line before `targets:`, but I think we should keep it
 as it separates the different parts of the file. Other than this it looks
 good to me.

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

Re: [tor-bugs] #28199 [Applications/Tor Browser]: Interrupted exit damages TB

[Tor Bug Tracker & Wiki]

#28199: Interrupted exit damages TB
--+---
 Reporter:  traumschule   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information


Comment:

 I often quit my Tor Browser with Ctrl+c and have never managed to damage
 it so far. Can you reproduce that with a clean Tor Browser 8.5a4? If so,
 I'd be interested in seeing a diff between an 8.5a4 cleanly shutting down
 and an 8.5a4 that is damaged.

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

Re: [tor-bugs] #28195 [Applications/Tor Browser]: TB fails to restart updating 8.5a3

[Tor Bug Tracker & Wiki]

#28195: TB fails to restart updating 8.5a3
--+--
 Reporter:  traumschule   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by traumschule):

 * status:  needs_information => new


Comment:

 To recap our talk on IRC:

 > What do you mean with "looks like fixing this introduced an error"?
 It was my impression that the alpha shuts down faster, but i might be
 wrong. Was thinking of #28113 but it looks unrelated.

 > The previous alpha updates worked for you?
 Yes, it worked until now.

 > The issue is that 8.5a3 which is what is important here just fixes two
 moz sec bugs in the js engine on linux. so, i don't see how that can lead
 to your problems.
 > It seems the browser is killing itself because the shutdown takes too
 long which messes with the updates.
 Because tor takes 30 seconds to exit? Maybe this should go or the timeout
 needs to be raised.

 > Does it make a difference if you apply partial updates or full updates?
 The updates above were all incremental. Fished this from the log: Testing
 the upgrade from 8.5a1 it downloads 82mb, so incremental updates are only
 supported for the direct successor it seems. It worked well and also
 restarted as it should.
 So the answer to your question is yes, it does seem to make a difference.

 However when i retested the update from 8.5a1 -> 8.5a4 just now it just
 exited without restarting and without error. It just exits when it should
 restart instead. On the next start the update goes well, so this is minor.
 The last line in the terminal was
 > Oct 25 11:24:52.000 [notice] Catching signal TERM, exiting cleanly.

 On the way more issues showed up. I filed #28199 and #28200 for additional
 pleasure.

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

Re: [tor-bugs] #28085 [Core Tor/sbws]: Update key/values in the bandwidth file spec

[Tor Bug Tracker & Wiki]

#28085: Update key/values in the bandwidth file spec
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #27107 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by teor):

 I answered your name question in
 https://trac.torproject.org/projects/tor/ticket/28197#comment:3

 Replying to [comment:4 juga]:
 > Should those keys be optional or mandatory?.

 None of these keys are required for the network to operate. So they should
 be optional.

 > If they are mandatory, should we increment the verion of the spec to
 1.2.0?

 New fields are a new feature, so we should increment the spec version to
 1.2.0. It doesn't matter if they are optional or mandatory.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28200 [Applications/Tor Browser]: Update fails when connection is interrupted

[Tor Bug Tracker & Wiki]

#28200: Update fails when connection is interrupted
--+--
 Reporter:  traumschule   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 The about dialog showed a download in progress and suddenly stopped. I had
 to close the about dialog and reopen it to continue the download. teor
 confirmed that on irc:
 > I have seen Tor Browser time out on updates on my macOS VM. Possibly
 because the VM is overloaded.

 TB should recognize an interrupted connection and restart the download
 automatically.

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

Re: [tor-bugs] #26094 [Core Tor/Tor]: manpage: increase minimal bandwidth requirements to be consistent with the relay guide and FAQ

[Tor Bug Tracker & Wiki]

#26094: manpage: increase minimal bandwidth requirements to be consistent with 
the
relay guide and FAQ
-+-
 Reporter:  nusenu   |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-doc, fast-fix, 035-triaged-  |  Actual Points:
  in-20180711|
Parent ID:   | Points:
 Reviewer:  arma |Sponsor:
-+-
Changes (by gman999):

 * cc: gman999@… (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] #28197 [Core Tor/sbws]: Rename some bandwidth file keys in the code

[Tor Bug Tracker & Wiki]

#28197: Rename some bandwidth file keys in the code
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28085 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by teor):

 The full list of keys in sbws master is at:
 https://github.com/torproject/sbws/blob/master/sbws/lib/v3bwfile.py#L29

 When I worked as a database designer, we named fields using this pattern:
 * optional Adjective(s) (words that modify the thing)
 * Noun (what the thing is)
 * optional Adjectives (words that modify the format of the data)
 * Kind (what format the data is in)

 We avoided most abbreviations, because they can mean different things. If
 we needed an abbreviation, we documented it, and used it consistently.

 If we were designing this format again, here are the names I would
 suggest:

 EXTRA_ARG_KEYVALUES:
 * software => software_name
 * software_version
 * file_created => file_creation_datetime
 * earliest_bandwidth => earliest_bandwidth_datetime
 * generator_started => generator_start_datetime

 UNORDERED_KEYVALUES:
 * latest_bandwidth => latest_bandwidth_datetime

 ALL_KEYVALUES:
 * version => format_version

 STATS_KEYVALUES:
 * num_measured_relays => eligible_relay_count
 * num_target_relays => min_relay_count (documented abbreviation) or
 minimum_eligible_relay_count
 * num_net_relays => consensus_relay_count
 * perc_measured_relays => eligible_relay_percentage
 * perc_measured_targed => min_relay_percentage (documented abbreviation)
 or minimum_eligible_relay_percentage

 BW_KEYVALUES_BASIC:
 * node_id
 * bw => bw_kps (documented abbreviations) or
 bandwidth_kilobytes_per_second

 BW_KEYVALUES_FILE:
 * master_key_ed25519 => ed25519_key or ed25519_master_key
 * nick => nick_text (documented abbreviation) or nickname_text
 * rtt => rtt_milliseconds (documented abbreviation) or
 round_trip_time_milliseconds
 * time => latest_relay_bandwidth_datetime
 * success => bandwidth_success_count
 * error_stream => bandwidth_stream_error_count
 * error_circ => bandwidth_circuit_error_count
 * error_misc => bandwidth_other_error_count

 BW_KEYVALUES_EXTRA_BWS:
 * bw_bs_median => median_bw_bps (documented abbreviations) or
 median_bandwidth_bytes_per_second
 * bw_bs_mean => mean_bw_bps (documented abbreviations) or
 mean_bandwidth_bytes_per_second
 * desc_avg_bw_bs => desc_avg_bw_limit_bps (documented abbreviations) or
 descriptor_average_bandwidth_limit_bytes_per_second
 * desc_obs_bw_bs_last => latest_desc_obs_bw_bps (documented abbreviations)
 or latest_descriptor_observed_bandwidth_bytes_per_second
 * desc_obs_bw_bs_mean => mean_desc_obs_bw_bps (documented abbreviations)
 or mean_descriptor_observed_bandwidth_bytes_per_second

 You can decide if you want to follow this pattern. You can change the
 names I suggested. You can leave some names as they are.

 If you rename a field in the 1.1.0 spec, it is a breaking change, and you
 should update the spec version to 2.0.0. (I don't think breaking changes
 are a good use of your time.)

 If you add fields to the 1.1.0 spec, they are new features, and you should
 update the spec version to 1.2.0.

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

[tor-bugs] #28199 [Applications/Tor Browser]: Interrupted exit damages TB

[Tor Bug Tracker & Wiki]

#28199: Interrupted exit damages TB
--+--
 Reporter:  traumschule   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 When TB quits it takes 30 seconds to give back the prompt because tor
 wants to exit gracefully after the lines
 > [notice] Owning controller connection has closed -- exiting now.
 > [notice] Catching signal TERM, exiting cleanly.

 I just damaged my freshly updated 8.5a4 with ctrl+c on exit because i was
 impatient to wait. On the next start tor did not start anymore and gave no
 errors (i closed and opened TB several times without changes).

 The about dialog says "Firefox Quantum" and no page is loaded ({{{refused
 connection}}}).

 The log is missing any info on tor:
 {{{
 $ tbb-debug tor-browser_en-US8.5a4/
 Logging Tor Browser debug information to tor-browser.log
 Fontconfig warning: "/home/tbb/tor-browser_en-
 US8.5a4/Browser/TorBrowser/Data/fontconfig/fonts.conf", line 85: unknown
 element "blank"
 alloc factor 0.90 0.90
 alloc factor 0.90 0.90
 Fontconfig warning: "/home/tbb/tor-browser_en-
 US8.5a4/Browser/TorBrowser/Data/fontconfig/fonts.conf", line 85: unknown
 element "blank"
 alloc factor 0.90 0.90
 alloc factor 0.90 0.90
 Fontconfig warning: "/home/tbb/tor-browser_en-
 US8.5a4/Browser/TorBrowser/Data/fontconfig/fonts.conf", line 85: unknown
 element "blank"
 ^C
 tbb@t43:~$ tbb-debug tor-browser_en-US8.5a4/
 Logging Tor Browser debug information to tor-browser.log
 Fontconfig warning: "/home/tbb/tor-browser_en-
 US8.5a4/Browser/TorBrowser/Data/fontconfig/fonts.conf", line 85: unknown
 element "blank"
 alloc factor 0.90 0.90
 alloc factor 0.90 0.90
 Fontconfig warning: "/home/tbb/tor-browser_en-
 US8.5a4/Browser/TorBrowser/Data/fontconfig/fonts.conf", line 85: unknown
 element "blank"
 alloc factor 0.90 0.90
 alloc factor 0.90 0.90
 Fontconfig warning: "/home/tbb/tor-browser_en-
 US8.5a4/Browser/TorBrowser/Data/fontconfig/fonts.conf", line 85: unknown
 element "blank"
 ^C
 }}}

 Log before it was damaged:
 {{{
 $ tbb-debug tor-browser_en-US8.5a1/
 Logging Tor Browser debug information to tor-browser.log
 Fontconfig warning: "/home/tbb/tor-browser_en-
 US8.5a1/Browser/TorBrowser/Data/fontconfig/fonts.conf", line 85: unknown
 element "blank"
 alloc factor 0.90 0.90
 alloc factor 0.90 0.90
 Oct 25 11:49:34.507 [notice] Tor 0.3.5.3-alpha (git-444e9b37c53b0246)
 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.0.2p, Zlib 1.2.11,
 Liblzma N/A, and Libzstd N/A.
 Oct 25 11:49:34.528 [notice] Tor can't help you if you use it wrong! Learn
 how to be safe at https://www.torproject.org/download/download#warning
 Oct 25 11:49:34.528 [notice] This version is not a stable Tor release.
 Expect more bugs than usual.
 Oct 25 11:49:34.546 [notice] Read configuration file "/media/user/tbb/tor-
 browser_en-US8.5a1/Browser/TorBrowser/Data/Tor/torrc-defaults".
 Oct 25 11:49:34.585 [notice] Read configuration file "/media/user/tbb/tor-
 browser_en-US8.5a1/Browser/TorBrowser/Data/Tor/torrc".
 Oct 25 11:49:34.674 [notice] Opening Socks listener on 127.0.0.1:9150
 Oct 25 11:49:34.676 [notice] Opened Socks listener on 127.0.0.1:9150
 Oct 25 11:49:34.676 [notice] Opening Control listener on 127.0.0.1:9151
 Oct 25 11:49:34.676 [notice] Opened Control listener on 127.0.0.1:9151
 Fontconfig warning: "/home/tbb/tor-browser_en-
 US8.5a1/Browser/TorBrowser/Data/fontconfig/fonts.conf", line 85: unknown
 element "blank"
 alloc factor 0.90 0.90
 alloc factor 0.90 0.90
 Fontconfig warning: "/home/tbb/tor-browser_en-
 US8.5a1/Browser/TorBrowser/Data/fontconfig/fonts.conf", line 85: unknown
 element "blank"
 ^C
 }}}
 TB should recognize that something is broken, tell the user that the
 bundle has been damaged and should be deleted and extracted again (even if
 this is obvious and users will figure it out, some may not and show up on
 #tor looking for support ..). Do we have any self-tests right now?

 The last message on exit should say that it needs time to clean up at the
 end or similar.

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

Re: [tor-bugs] #27273 [Core Tor/Tor]: ASan fails to link on Travis due to rustc and linker arguments

[Tor Bug Tracker & Wiki]

#27273: ASan fails to link on Travis due to rustc and linker arguments
--+
 Reporter:  alexcrichton  |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  High  |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:  #25386| Points:
 Reviewer:  teor  |Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Hm. One thing I found here in my own testing is that this code seems to
 fail on rust 1.29 even if the sanitizers are disabled:

 {{{
   process didn't exit successfully: `rustc - --crate-name ___ --print
 =file-names -C linker=gcc -C default-linker-libraries --target x86_64
 -unknown-linux-gnu --crate-type bin --crate-type rlib --crate-type dylib
 --crate-type cdylib --crate-type staticlib --crate-type proc-macro` (exit
 code: 1)
 --- stderr
 error: unknown codegen option: `default-linker-libraries`
 }}}

 I'd either like to fix this up so that it doesn't break non-hardened
 builds 1.29, or wait until 1.29 is obsolete before we merge it.

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

Re: [tor-bugs] #28120 [Core Tor/Tor]: hs_descriptor: CID 1440368: Incorrect expression (SIZEOF_MISMATCH)

[Tor Bug Tracker & Wiki]

#28120: hs_descriptor: CID 1440368:  Incorrect expression  (SIZEOF_MISMATCH)
-+
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  coverity tor-hs  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by dgoulet):

 Probably our here is to pass the keystream length to
 `build_descriptor_cookie_keys()`. At first glance, it does seems like that
 function has no business of computing by itself the length but rather it
 would be the caller's job.

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

Re: [tor-bugs] #24006 [Core Tor/Tor]: IPv6-only Tor2web has never actually connected to rend points over IPv6

[Tor Bug Tracker & Wiki]

#24006: IPv6-only Tor2web has never actually connected to rend points over IPv6
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:  Tor: 0.2.8.1-alpha
 Severity:  Normal | Resolution:  wontfix
 Keywords:  tor-hs, tor2web, ipv6  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:
---+
Changes (by dgoulet):

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


Comment:

 tor2web is gone.

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

Re: [tor-bugs] #24346 [Core Tor/Tor]: prop224: Service stops uploading one of its two descriptors

[Tor Bug Tracker & Wiki]

#24346: prop224: Service stops uploading one of its two descriptors
-+-
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.4-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  prop224, tor-hs, |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

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


Comment:

 With OPE code as the revision counter and the fixes in #23603, I think we
 are done here. We've seen other upload issues but there are specific
 tickets for it now.

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

Re: [tor-bugs] #25441 [Core Tor/Tor]: Occasional timing? failures in hs_descriptor/validate_cert unit test

[Tor Bug Tracker & Wiki]

#25441: Occasional timing? failures in hs_descriptor/validate_cert unit test
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs, rust?, 034-triage-20180328,  |  Actual Points:
  034-removed-20180328   |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

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


Comment:

 This has been fixed to always use `approx_time()` or the consensus
 valid_after time. We shouldn't have this timing failure anymore.

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

Re: [tor-bugs] #27446 [Core Tor/Tor]: hs: Report configuration error on the control port (was: Vague 'see log' response when HS creation fails)

[Tor Bug Tracker & Wiki]

#27446: hs: Report configuration error on the control port
--+--
 Reporter:  atagar|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by dgoulet):

 Renaming to reflect the new reality of this ticket. Reporting possible
 configuration error on the control port could be a useful feature for HS.

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

Re: [tor-bugs] #28190 [Core Tor/Tor]: Hidden service v2 exceeded launch limit with 11 intro points in the last 37 seconds

[Tor Bug Tracker & Wiki]

#28190: Hidden service v2 exceeded launch limit with 11 intro points in the 
last 37
seconds
+
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor|Version:  Tor: unspecified
 Severity:  Normal  | Resolution:
 Keywords:  regression, tor-hs  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by dgoulet):

 * cc: dgoulet (removed)
 * keywords:  regression => regression, tor-hs


Comment:

 This is actually possible. I've seen that with 4 or 5 intro where 1 or 2
 circuits aren't opened and because we launch 3 + 2 intro points and take
 the first 3 that finishes, you can hit that log warning while having extra
 intro points inflight for which tor hasn't closed them yet.

 In this case, the 4th one still wasn't closed just yet.

 It is still unclear why the service would do so many attempts in such a
 small period of time but in this case it seems the service does has 3
 working intro points so the warning comes from this:

 {{{
 } else if (service->n_intro_circuits_launched >=
rend_max_intro_circs_per_period(
   service->n_intro_points_wanted)) {
   /* We have failed too many times in this period; wait for the next
* one before we try to initiate any more connections. */
   rend_log_intro_limit(service, LOG_WARN);
   continue;
 }
 }}}

 ... where in this case `n_intro_circuits_launched = 11` and if
 `n_intro_points_wanted` was 0, then we would hit that condition everytime
 that `rend_consider_services_intro_points()` is called, which is every
 second...

 It appears to me that we shouldn't even continue in the loop of that
 function if the service wants *NO* intro point. Just below that warning,
 there is this snippet of code that should be before I feel like...

 {{{
 /* Quiescent state, we have more or the equal amount of wanted node
 for
  * this service. Proceed to the next service. We can have more nodes
  * because we launch extra preemptive circuits if our intro nodes list
 was
  * originally empty for performance reasons. */
 if (intro_nodes_len >= service->n_intro_points_wanted) {
   continue;
 }
 }}}

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

Re: [tor-bugs] #26498 [Applications/Tor Browser]: Fix bn-BD and es-AR locale for Tor Browser

[Tor Bug Tracker & Wiki]

#26498: Fix bn-BD and es-AR locale for Tor Browser
--+
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by gk):

 Replying to [comment:4 gk]:
 > The `es-AR` bundle is neither running on Linux nor on Windows I get
 > {{{
 > Error de análisis XML: entidad indefinida
 > Ubicación: chrome://browser/content/browser.xul
 > Línea 41, columna 1: }}}
 > just before the main browser window pops up.

 Okay, I fixed that. I did 4) not good enough ignoring the fact that `es-
 AR` strings needed to actually get added (not just updated) to the
 Torbutton repo. After that `es-AR` looks good to me.

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

Re: [tor-bugs] #27690 [Core Tor/Tor]: Update bandwidth-file-spec with scaling methods

[Tor Bug Tracker & Wiki]

#27690: Update bandwidth-file-spec with scaling methods
--+-
 Reporter:  juga  |  Owner:  juga
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec, tor-bwauth  |  Actual Points:
Parent ID:  #27107| Points:
 Reviewer:|Sponsor:
--+-

Comment (by juga):

 Should we also describe the PID control feedback method or only the method
 without?.
 I think that if we are not describing other parts on how Torflow works
 now, then we should not include it either, since it is not being used.

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

Re: [tor-bugs] #27690 [Core Tor/Tor]: Update bandwidth-file-spec with scaling methods

[Tor Bug Tracker & Wiki]

#27690: Update bandwidth-file-spec with scaling methods
--+-
 Reporter:  juga  |  Owner:  juga
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec, tor-bwauth  |  Actual Points:
Parent ID:  #27107| Points:
 Reviewer:|Sponsor:
--+-

Comment (by juga):

 I think we should remove or change the paragraph in
 https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-
 spec.txt#n488, because with graphs we made later, we could see that they
 have different shape and Torflow scaled bandwidth was closer to the
 descriptor observed-bandwidth.
 What we could verify, is that the raw measurements between Torflow and
 sbws are close.

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

Re: [tor-bugs] #27690 [Core Tor/Tor]: Update bandwidth-file-spec with scaling methods

[Tor Bug Tracker & Wiki]

#27690: Update bandwidth-file-spec with scaling methods
--+-
 Reporter:  juga  |  Owner:  juga
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec, tor-bwauth  |  Actual Points:
Parent ID:  #27107| Points:
 Reviewer:|Sponsor:
--+-
Changes (by juga):

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


Comment:

 Assign myself

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

Re: [tor-bugs] #28085 [Core Tor/sbws]: Update key/values in the bandwidth file spec

[Tor Bug Tracker & Wiki]

#28085: Update key/values in the bandwidth file spec
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #27107 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by juga):

 Should those keys be optional or mandatory?. If they are mandatory, should
 we increment the verion of the spec to 1.2.0?

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

Re: [tor-bugs] #28195 [Applications/Tor Browser]: TB fails to restart updating 8.5a3

[Tor Bug Tracker & Wiki]

#28195: TB fails to restart updating 8.5a3
--+---
 Reporter:  traumschule   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by gk):

 What happens with an update from 8.5a2->8.5a4?

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

Re: [tor-bugs] #28085 [Core Tor/sbws]: Update key/values in the bandwidth file spec

[Tor Bug Tracker & Wiki]

#28085: Update key/values in the bandwidth file spec
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #27107 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by juga):

 See #28197 regarding other names.

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

Re: [tor-bugs] #28197 [Core Tor/sbws]: Rename some bandwidth file keys in the code

[Tor Bug Tracker & Wiki]

#28197: Rename some bandwidth file keys in the code
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28085 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by juga):

 The keys added by #28062 are having `measured` in their name.
 I think that's confusing, because the scanner measured more than those
 relays, it's just they didn't pass some restrictions.
 I'm not sure `to_include` is better 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] #28197 [Core Tor/sbws]: Rename some bandwidth file keys in the code

[Tor Bug Tracker & Wiki]

#28197: Rename some bandwidth file keys in the code
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28085 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by juga):

 I'd eliminate the parts that have `_bs` in their name, it was added to
 know that the unit was Bytes, but it's not clear from the name and if they
 unit is not specified the default should be Bytes.
 The names of the keys after eliminating `_bs` are:
 `bw_median`, `bw_mean`, `desc_avg_bw`, `desc_obs_bw_last`,
 `desc_obs_bw_mean`

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

Re: [tor-bugs] #28085 [Core Tor/sbws]: Update key/values in the bandwidth file spec

[Tor Bug Tracker & Wiki]

#28085: Update key/values in the bandwidth file spec
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #27107 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by juga):

 These are the keys i introduced because they were useful to create graphs
 and/or scale using different methods. I think we still need to try
 different method and we should keep them:

 `bw_median`, `bw_mean`, `desc_avg_bw`, `desc_obs_bw_last`,
 `desc_obs_bw_mean`

 What maybe we want to change is the name.

 These are the keys introduced in #28062 :
 'num_relays_to_include`, `num_target_relays`, `num_net_relays`,
 `perc_relays_to_include`, `perc_relays_to_include_target`

 Are we ok with this names?

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

Re: [tor-bugs] #22787 [Applications/Tor Browser]: Fontconfig warning: remove 'blank' configuration

[Tor Bug Tracker & Wiki]

#22787: Fontconfig warning: remove 'blank' configuration
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-fingerprinting-fonts  |  Actual Points:
Parent ID:  #18097| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * cc: traumschule (added)


Comment:

 Nowadays we have systems where we get `line 85: unknown element "blank"`
 messages. Resolved #28198 as a duplicate.

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

Re: [tor-bugs] #28198 [Applications/Tor Browser]: Fontconfig warning: "/home/…/TorBrowser/Data/fontconfig/fonts.conf", line 85: unknown element "blank"

[Tor Bug Tracker & Wiki]

#28198: Fontconfig warning: "/home/…/TorBrowser/Data/fontconfig/fonts.conf", 
line
85: unknown element "blank"
--+---
 Reporter:  traumschule   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Minor | Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 Duplicate of #22787.

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

Re: [tor-bugs] #28195 [Applications/Tor Browser]: TB fails to restart updating 8.5a3

[Tor Bug Tracker & Wiki]

#28195: TB fails to restart updating 8.5a3
--+---
 Reporter:  traumschule   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by traumschule):

 8.0.2 -> 8.0.3 works but it takes 30s until the bar appears, looks like
 fixing this introduced an error.
 > Oct 25 10:03:33.000 [notice] Catching signal TERM, exiting cleanly.
 > JavaScript error: chrome://torbutton/content/tor-circuit-display.js,
 line 436: TypeError: myController is null
 > Fontconfig warning: "/home/tbb/tor-browser_en-
 US8.0.2/Browser/TorBrowser/Data/fontconfig/fonts.conf", line 85: unknown
 element "blank"
 > 1540461904853   addons.webextension.   WARNLoading
 extension 'null': Reading manifest: Error processing
 background.persistent: Event pages are not currently supported. This will
 run as a persistent background page.
 > 1540461905523   addons.xpi  WARNPlease specify whether you want
 browser_style or not in your options_ui options.
 > 1540461906559   addons.xpi  WARNPlease specify whether you want
 browser_style or not in your options_ui options.
 > Fontconfig warning: "/home/tbb/tor-browser_en-
 US8.0.2/Browser/TorBrowser/Data/fontconfig/fonts.conf", line 85: unknown
 element "blank"
 > Oct 25 10:05:09.477 [notice] Tor 0.3.4.8 (git-da95b91355248ad8) running
 on Linux with Libevent 2.1.8-stable, OpenSSL 1.0.2p, Zlib 1.2.11, Liblzma
 N/A, and Libzstd N/A.
 Do you need more info? (happy to test more:) Filed #28198 for the
 Fontconfig lines.

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

Re: [tor-bugs] #26697 [Applications/Tor Browser]: Add Android toolchain

[Tor Bug Tracker & Wiki]

#26697: Add Android toolchain
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  task | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201810   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Looks good now, thanks! I cherry-picked the patch to `master`
 (10c58d9a2f9fc37f7ba3e1b7028d2b5a730b1e6f).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28198 [Applications/Tor Browser]: Fontconfig warning: "/home/…/TorBrowser/Data/fontconfig/fonts.conf", line 85: unknown element "blank"

[Tor Bug Tracker & Wiki]

#28198: Fontconfig warning: "/home/…/TorBrowser/Data/fontconfig/fonts.conf", 
line
85: unknown element "blank"
--+--
 Reporter:  traumschule   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Minor |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 This appears regularly in the log, probably harmless. I found this line
 has one tab less than the following, intentional?
 It would be nice to get this fixed because it leaks information about the
 environment in logs.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28197 [Core Tor/sbws]: Rename some bandwidth file keys in the code

[Tor Bug Tracker & Wiki]

#28197: Rename some bandwidth file keys in the code
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #28085
   Points: |   Reviewer:
  Sponsor: |
---+-
 So that they have also that name in the bandwidth file spec when 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] #27623 [Applications/Tor Browser]: wrong default pref values in Tor Browser 8.0

[Tor Bug Tracker & Wiki]

#27623: wrong default pref values in Tor Browser 8.0
-+-
 Reporter:  mcs  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff60-esr, tbb-8.0-issues,|  Actual Points:
  tbb-8.0.1-can, TorBrowserTeam201809R, tbb- |
  backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Note: for backporting we need #28039 fixed, too.

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

Re: [tor-bugs] #26498 [Applications/Tor Browser]: Fix bn-BD and es-AR locale for Tor Browser

[Tor Bug Tracker & Wiki]

#26498: Fix bn-BD and es-AR locale for Tor Browser
--+
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

 * Attachment "bn-BD-linux.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] #26498 [Applications/Tor Browser]: Fix bn-BD and es-AR locale for Tor Browser (was: Fix bn-BD locale for Tor Browser)

[Tor Bug Tracker & Wiki]

#26498: Fix bn-BD and es-AR locale for Tor Browser
--+
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

 * Attachment "bm-BD-linux.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] #26498 [Applications/Tor Browser]: Fix bn-BD and es-AR locale for Tor Browser

[Tor Bug Tracker & Wiki]

#26498: Fix bn-BD and es-AR locale for Tor Browser
--+
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

 * Attachment "bm-BD-linux.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] #26498 [Applications/Tor Browser]: Fix bn-BD and es-AR locale for Tor Browser

[Tor Bug Tracker & Wiki]

#26498: Fix bn-BD and es-AR locale for Tor Browser
--+
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

 * keywords:  TorBrowserTeam201810R =>
 * status:  needs_review => needs_revision


Comment:

 Okay, I tested both locales on a Linux and a Windows system. Here is what
 I did to build the bundles:

 1) I created patches with `git format-patch` for Torbutton and Tor
 Launcher and applied them during the rbm build process
 2) I patched `rbm.conf` to just build `bn-BD` and `es-AR` bundles in
 addition to `en-US` ones
 3) I committed the Torbutton patch locally
 4) I updated my local Torbutton repo to pick up possibly missing `bn-BD`
 and `es-AR` language strings
 5) I created a patch (with `git format-patch`) and applied the updated
 translations on top of the Torbutton patch up for review during the rbm
 build.

 The `bn-BD` bundle seems to be missing a font or something as the title
 bar is just gibberish on Linux (see attachment). On Windows this does not
 seem to be an issue. I additionally found #28196 which is unrelated to
 this bug, though.

 The `es-AR` bundle is neither running on Linux nor on Windows I get
 {{{
 Error de análisis XML: entidad indefinida
 Ubicación: chrome://browser/content/browser.xul
 Línea 41, columna 1:https://trac.torproject.org/projects/tor/ticket/26498#comment:4>
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #27905 [Applications/Tor Browser]: many occurrences of "Firefox" in about:preferences

[Tor Bug Tracker & Wiki]

#27905: many occurrences of "Firefox" in about:preferences
-+-
 Reporter:  mcs  |  Owner:  mcs
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff60-esr, tbb-8.0-issues,|  Actual Points:
  TorBrowserTeam201810R, tbb-backport|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Note for backporting we likely need to have #28196 fixed as well.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28196 [Applications/Tor Browser]: about:preferences#general is not properly translated anymore starting with Tor Browser 8.5a4

[Tor Bug Tracker & Wiki]

#28196: about:preferences#general is not properly translated anymore starting 
with
Tor Browser 8.5a4
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
  |  TorBrowserTeam201810
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 `about:preferences#general` contains almost only en-US strings independent
 of the locale used in Tor Browser 8.5a4. This is likey fallout from
 #27905.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by karsten):

 Replying to [comment:24 irl]:
 > I think this is ready to go, [...]

 Thanks for the review! Pushed to master, deploying now, step by step.
 Leaving this ticket open until everything's deployed.

 > [...] but, we should create a new ticket for generalising the
 computePercentiles function with generics.

 I'll create a slightly different ticket before closing this one: we should
 share more code between modules, and a generic `computePercentiles()`
 would be one piece of code to consider here. I wouldn't want to merge a
 patch that starts with this part of the code. I'd want us to approach this
 from a top-down perspective where we generalize similar functionality and
 use it in all modules to reduce the overall amount of code and likelihood
 of bugs.

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