Re: [tor-bugs] #17019 [Core Tor/Tor]: Include Tor2web and Encrypted Services in default Tor build

[Tor Bug Tracker & Wiki]

#17019: Include Tor2web and Encrypted Services in default Tor build
--+--
 Reporter:  naif  |  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by grisloh33):

 Replying to [ticket:17019 naif]:
 > This ticket is to propose inclusion of Tor2web and Encrypted Services in
 default Tor build.
 >
 > Both Tor2web mode and Encrypted Services are non-anonymous way of using
 Tor, either as a client, either as a server.
 >
 > Given that this implementation at #2555 enable exposure of NON-ANONYMOUS
 Tor Hidden Service with the standard Tor software, i think that it make
 sense to enable also NON-ANONYMOUS Tor Hidden Service Client (ie: Actually
 compile-time Tor2web Mode) with the standard Tor software.
 >
 > For both NON-ANONYMOUS Tor Hidden Service use-cases (Server and Client),
 we can build them in the standard version of Tor by adding a command line
 like:
 >
 > --yes-i-know-that-i-m-going-to-use-non-anonymous-tor-hidden-services-
 client (tor2web mode)
 > --yes-i-know-that-i-m-going-to-use-non-anonymous-tor-hidden-services-
 server (encrypted services)
 >
 > That way the Tor Hidden Services world will have it's NON-ANONYMOUS way
 to use Tor Darknet with the Server (encrypted services) and Client
 (tor2web mode).
 >
 > Any application using Encrypted Services and Tor2web mode would greatly
 benefit from being enabled by default in the default Tor build.

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

Re: [tor-bugs] #29635 [Core Tor/Tor]: tor man page screws up quotes when telling you to use quotes for command line

[Tor Bug Tracker & Wiki]

#29635: tor man page screws up quotes when telling you to use quotes for command
line
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Replying to [ticket:29635 arma]:
 > Changing both the ' to " seems like it resolves it.

 Actually, the ' does something -- it makes the arguments underlined.

 If we want to keep that (I don't know man page conventions) then here is
 the fix:
 {{{
 -messages to debug.log, you will probably need to say --Log 'debug file
 -debug.log'.
 +messages to debug.log, you will probably need to say --Log "'debug file
 +debug.log'".
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29636 [Metrics/Website]: Document how we estimate users by transport by country

[Tor Bug Tracker & Wiki]

#29636: Document how we estimate users by transport by country
-+--
 Reporter:  arma |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 On
 https://metrics.torproject.org/userstats-bridge-combined.html?country=ar
 at the bottom it says
 "Even though bridges don't report a combination of clients by country and
 transport, it's possible to derive and graph lower and upper bounds from
 existing usage statistics. For further details see these questions and
 answers about user statistics."

 But the further details link doesn't tell me how this graph derives lower
 and upper bounds from existing usage statistics.

 Maybe it is already written up somewhere, and we can link to 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] #23333 [Obfuscation/BridgeDB]: Leekspin bug hunting

[Tor Bug Tracker & Wiki]

#2: Leekspin bug hunting
--+
 Reporter:  Samdney   |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by arma):

 * status:  assigned => new
 * sponsor:  Sponsor19 =>


Comment:

 disconnecting the ticket from sponsor19

 we might want to abandon leekspin (or rather, acknowledge that we've
 already abandoned it) and close all of its tickets. but that can be a
 separate decision.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23043 [Obfuscation/BridgeDB]: leekspin's except/error code handling in generator.py is strange

[Tor Bug Tracker & Wiki]

#23043: leekspin's except/error code handling in generator.py is strange
--+
 Reporter:  Samdney   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Minor | Resolution:
 Keywords:  leekspin  |  Actual Points:
Parent ID:  #2| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by arma):

 * status:  assigned => new
 * sponsor:  Sponsor19 =>


Comment:

 disconnecting the ticket from sponsor19

 we might want to abandon leekspin (or rather, acknowledge that we've
 already abandoned it) and close all of its tickets. but that can be a
 separate decision.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29635 [Core Tor/Tor]: tor man page screws up quotes when telling you to use quotes for command line

[Tor Bug Tracker & Wiki]

#29635: tor man page screws up quotes when telling you to use quotes for command
line
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 tor.1.txt says
 {{{
 You will need to
 quote options with spaces in them: if you want Tor to log all debugging
 messages to debug.log, you will probably need to say --Log 'debug file
 debug.log'.
 }}}
 which results in a man page that says
 {{{
You will need to quote options with spaces in them:
if you want Tor to log all debugging messages to debug.log, you
 will
probably need to say --Log debug file debug.log.
 }}}
 which sure isn't going to help anybody.

 Changing both the ' to " seems like it resolves it.

 The bad quotes went in during commit f5e86bc.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20643 [Internal Services/Service - deb.tpo]: make and maintain a registry of what debs are on deb.tp.o and why

[Tor Bug Tracker & Wiki]

#20643: make and maintain a registry of what debs are on deb.tp.o and why
-+-
 Reporter:  arma |  Owner:  irl
 Type:  task | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - deb.tpo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  arma |Sponsor:
-+-
Changes (by arma):

 * status:  needs_review => needs_revision


Comment:

 Great! I looked at the wiki page.

 The wiki page lists these packages as being available on deb.tp.o:
 deb.torproject.org-keyring, tor, obfsproxy, pyptlib, obfs4proxy.

 But I see other debs, like python-klein:
 http://deb.torproject.org/torproject.org/pool/main/k/klein/
 and ooniprobe:
 http://deb.torproject.org/torproject.org/pool/main/o/ooniprobe/
 python-certifi:
 http://deb.torproject.org/torproject.org/pool/main/p/python-certifi/
 and txtorcon:
 http://deb.torproject.org/torproject.org/pool/main/t/txtorcon/

 So it seems like this list on the wiki is incomplete?

 Also, I didn't find the obfsproxy package in the pool/ directory. (Maybe
 it was removed in the past 7 months, when wheezy went away?)

 Are these extra debs somehow not "really" on deb.tpo, since they're not in
 the Releases files that you mentioned? If that is so, should we delete
 them?

 But I have a memory of Arturo thinking that the ooniprobe deb was still in
 use? (It appears to still be referenced directly from
 https://ooni.torproject.org/docs/ so I would guess yes it is.)

 In the example command line on the wiki there is this typo,
 "$PACKCAGETOREMOVE"

 To satisfy the "and maintain" part of this ticket, we should figure out
 some way to make sure that a pointer to the wiki page is in the critical
 path to adding or removing a package from deb.tpo, so people know to go
 update the wiki page. An alternative option would be that we run some sort
 of nagios cron that automatically enumerates the available packages, and
 notifies somebody when they differ from the entries on the wiki?

 And lastly, for the "and why" part of the ticket, it would be nice to have
 a short explanation of why we have each package on deb.tpo. Such an
 explanation would primarily help it stay easy to notice when that reason
 no longer applies and it's time to reconsider having a separate copy here.

 Thanks!

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

Re: [tor-bugs] #29205 [Obfuscation/Snowflake]: Look into using Firefox for the WebRTC implementation

[Tor Bug Tracker & Wiki]

#29205: Look into using Firefox for the WebRTC implementation
---+---
 Reporter:  cohosh |  Owner:  (none)
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor19
---+---

Comment (by arma):

 I had thought the idea here was to drive an actual firefox to talk webrtc
 to the snowflakes. That way Tor users would be talking webrtc just like
 firefox, because it *would* be firefox. Rather than linking in a library
 and trying to call it in the same ways that Firefox calls it (and react to
 errors and network conditions etc in the same way that Firefox reacts).

 And we picked Firefox because "we already have one" in tor browser (though
 tor browser currently disables webrtc at compile time, but hey, nobody
 said this would be easy).

 So, kind of like how meek launches a browser and drives it to do the
 domain fronting connection.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25642 [Webpages/Website]: translation of torproject.org

[Tor Bug Tracker & Wiki]

#25642: translation of torproject.org
--+--
 Reporter:  isabela   |  Owner:  emmapeel
 Type:  project   | Status:  assigned
 Priority:  Medium|  Milestone:  website redesign
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team,  |  Actual Points:
Parent ID:  #24131| Points:
 Reviewer:|Sponsor:
--+--

Comment (by emmapeel):

 I am waiting for the string freeze to send this to translators

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

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

[Tor Bug Tracker & Wiki]

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

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


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

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

[Tor Bug Tracker & Wiki]

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

Comment (by pidgin):

 the service behind onion HiddenService is fine, it is serving requests.
 before the DDOS there have not been "Server Not Found".
 Actually it was the hackers third iteration.
 First step from hacker was brute force DDOS which made tor cpu load 100%.
 countermeasure: vanguards and using ExcludeNodes (torrc)
 Second iteration from hacker was to use random nodes, about 1000+, to do
 tor cpu load 100%. countermeasure: vanguards / onionbalance.
 now tor browser gives "server not found", countermeasure not found yet

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

Re: [tor-bugs] #28300 [Core Tor/Stem]: Scrolling support for tor-prompt is needed

[Tor Bug Tracker & Wiki]

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

Comment (by atagar):

 Thanks wagon! Fixed the typo and adjusted the wording a tad...

 https://gitweb.torproject.org/stem.git/commit/?id=85e96a0

 I realized from your example that you backgrounded the telnet session, but
 wasn't sure how best to communicate that. I assumed by presenting
 additional terminal commands that the reader would realize they needed
 another prompt, but no harm in calling it out.

 On a side note, were you the person that pointed out that tor-prompt is a
 bit slow? If so then I just improved that a bit...

 https://gitweb.torproject.org/stem.git/commit/?id=0fc61dd

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29628 [Applications/Tor Browser]: Distrust DarkMatter Intermediate CAs

[Tor Bug Tracker & Wiki]

#29628: Distrust DarkMatter Intermediate CAs
--+--
 Reporter:  nsuchy|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nsuchy):

 Replying to [comment:2 sysrqb]:
 > You may find the entire thread discussing this topic enlightening. I am
 personally in support of Mozilla denying the root inclusion request and
 revoking their intermediate CA certificate. However, as it was said
 numerous times in the discussion thread, the only reason we know
 DarkMatter have these CA certificates is because they applied for root
 inclusion - in a public forum. It is very easy for a malicious
 organization to obtain an intermediate CA certificate without that
 certificate being attributable to them. As far as anyone knows (publicly),
 DarkMatter haven't used their current Intermediate CA with malicious
 intent, yet(!). If DarkMatter use their CA for malicious purpose in the
 future and that malicious activity is detected, then their intermediate CA
 certificate should be revoked by DigiCert (and therefore they lose their
 trusted position globally). The current question is whether Mozilla should
 pre-emptively revoke DarkMatter's Intermediate certificate and reject
 their current root.
 >
 > The Tor Project isn't in a position where we can successfully audit all
 anchor and intermediate CAs included in Mozilla's root store. And, even if
 we could, we likely wouldn't be able to maintain that long-term. We can
 distrust DarkMatter's current intermediate, but given the previous
 statement about how Intermediate CAs certificates can be obtained
 relatively easily under alternative-names, I don't know if this is a
 winning solution. In reality, distrusting one intermediate CA is likely
 pointless, other than making a political statement.
 >
 > I'll leave this open, in case anyone else on the team has more input
 here.
 >
 >
 
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/YiybcXciBQAJ

 I agree that it's impossible for a small organization to monitor all
 intermediate cas, instead wait for someone to make a report in trac,
 review it's legitimacy, and distrust where appropriate. Even root cas like
 LetsEncrypt could in theory issue abusive certificates. In this case,
 evidence points towards the CA being likely to misbehave and it'd be a
 reasonable precaution given the evidence for the Tor Project to take
 action.

 Also the Google Groups thread was interesting, thank you for sharing.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29330 [Metrics/Website]: Do something with advertised bandwidth distribution graphs

[Tor Bug Tracker & Wiki]

#29330: Do something with advertised bandwidth distribution graphs
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  irl  |Sponsor:
-+--

Comment (by arma):

 I am ok with the 'replace' plan, where we switch from descriptor
 bandwidths to consensus weights.

 These graphs are all about (or at least, were started for) visualizing how
 centralized the Tor network is. For example, they aimed to help answer the
 questions "how much of the Tor network are the top x relays, or the top x%
 of the relays?" There are many other ways we might visualize the
 centralization of the network over time, and which for me might be at
 least as good as these current graphs. For examples,

 * "how many relays are in the top 50% of the network by bandwidth or by
 consensus weight?"

 * "if we think of the current Tor network in terms of equally weighted
 relays, rather than the current wildly unbalanced weights, how many
 uniformly-weighted relays would it be the equivalent of?"

 * "if a client builds 100 circuits, what's the expected number of relays
 (maybe broken out into first / second / third hop) that it will interact
 with?"

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29634 [Applications/Tor Browser]: Riot.im local storage lost when closing tab

[Tor Bug Tracker & Wiki]

#29634: Riot.im local storage lost when closing tab
-+-
 Reporter:  0tzVNmkQxgql |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  Applications/Tor
 |  Browser
  Version:   |   Severity:  Normal
 Keywords:  riot, matrix, local  |  Actual Points:
  storage|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
 I am trying to use the official release instance of the Riot client for
 Matrix at https://riot.im/app . I have configured Tor Browser to keep site
 data for riot.im. Security level is Standard.

 When I log into Riot, I can see in TB's Storage Inspector that data is
 written to IndexedDB and Local Storage. When I close the Riot tab and
 reopen Riot in a new tab, I am no longer logged in. In Storage Inspector,
 the IndexedDB data seems to persist (even over browser restarts, as
 intended), but Local Storage was not kept when closing the tab and a new
 guest session is written.

 I have reproduced this problem on Riot v0.17.8 and later, as well as Tor
 Browser 8.0.4 and later. It does not occur on Firefox ESR. Without
 persistent Local Storage, it is not possible to use the device-based E2E
 encryption that Matrix offers, because old messages will not decrypt
 properly and all communication partners have to re-verify my "devices"
 every time I close the tab and log back in.

 IMO, Tor Browser should keep all data stored by sites that are explicitly
 whitelisted by the user, not just cookies and IndexedDB.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28802 [Applications/Tor Browser]: Integrate PTs and bridge support into Tor Browser

[Tor Bug Tracker & Wiki]

#28802: Integrate PTs and bridge support into Tor Browser
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a3,  |  Actual Points:
  TorBrowserTeam201903R, GeorgKoppen201903   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by gk):

 * keywords:  tbb-mobile, TBA-a3, TorBrowserTeam201903, GeorgKoppen201903 =>
 tbb-mobile, TBA-a3, TorBrowserTeam201903R, GeorgKoppen201903
 * status:  new => needs_review


Comment:

 After stopping to fiddle with unzipping and re-zipping .apk's to get the
 `obfs4proxy` binary at the correct place this was not overly hard anymore.
 Thanks to Nathan for this help! `bug_28802`
 (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/commit/?h=bug_28802=1a5d368802706c3050db61430cb8b13287812229)
 in my `tor-browser-build` repo has a patch for review.

 meek worked for me, however not the obfs4 bridges (they seemed to be
 down), so I wonder whether we should update the list to use the ones we
 ship for Tor Browser. For some reason I was not able to use bridges I got
 from BridgeDB. I entered them into Orbot's bridge settings but still the
 obfs4 ones were tried. That might be a thing we can solve with #28329,
 though.

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

Re: [tor-bugs] #7144 [Core Tor/Tor]: Implement Bridge Guards and other anti-enumeration defenses

[Tor Bug Tracker & Wiki]

#7144: Implement Bridge Guards and other anti-enumeration defenses
-+-
 Reporter:  karsten  |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridge tor-guard censorship  |  Actual Points:
Parent ID:   | Points:  10
 Reviewer:   |Sponsor:  Sponsor19
-+-
Changes (by gaba):

 * status:  needs_revision => new


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28803 [Applications/Tor Browser]: Integrate building pluggable transports for Android into tor-browser-build

[Tor Bug Tracker & Wiki]

#28803: Integrate building pluggable transports for Android into 
tor-browser-build
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, TBA-a3, tor-|  Actual Points:
  pt, TorBrowserTeam201902   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor19-can
-+-
Changes (by gaba):

 * sponsor:  Sponsor8 => Sponsor19-can


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28803 [Applications/Tor Browser]: Integrate building pluggable transports for Android into tor-browser-build

[Tor Bug Tracker & Wiki]

#28803: Integrate building pluggable transports for Android into 
tor-browser-build
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, TBA-a3, tor-|  Actual Points:
  pt, TorBrowserTeam201902   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by gk):

 * cc: n8fr8 (added)


Comment:

 I guess Orbot is not ready for that yet and I am not sure where we are
 with our PT story once we switch to TOPL. Thus we might want to file a
 more specific ticket to include the `obfs4proxy` build process (a la Pluto
 or the Briar way) in our reproducible build process meanwhile. Or maybe we
 just wait a bit longer... :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29541 [Core Tor/Tor]: Re-enable util/mmap_anon_no_fork

[Tor Bug Tracker & Wiki]

#29541: Re-enable util/mmap_anon_no_fork
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop289, prop289-assigned-   |  Actual Points:
  sponsor-v, 041-proposed-on-roadmap, network-   |
  team-roadmap-2019-Q1Q2 |
Parent ID:  #26288   | Points:
 Reviewer:  mikeperry|Sponsor:
-+-
Changes (by mikeperry):

 * status:  needs_review => merge_ready


Comment:

 This is a little mind-bendy with the magic behavior constants and bytes
 being sent back and forth, but it's well commented and looks ok.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28802 [Applications/Tor Browser]: Integrate PTs and bridge support into Tor Browser

[Tor Bug Tracker & Wiki]

#28802: Integrate PTs and bridge support into Tor Browser
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a3,  |  Actual Points:
  TorBrowserTeam201903, GeorgKoppen201903|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by gk):

 * keywords:  tbb-mobile, TBA-a3, TorBrowserTeam201902 => tbb-mobile,
 TBA-a3, TorBrowserTeam201903, GeorgKoppen201903


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29527 [Core Tor/Tor]: Division by zero: undefined behaviour in circuitpadding/circuitpadding_sample_distribution test

[Tor Bug Tracker & Wiki]

#29527: Division by zero: undefined behaviour in
circuitpadding/circuitpadding_sample_distribution test
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, tor-ci, tor-test,|  Actual Points:
  040-must   |
Parent ID:   | Points:
 Reviewer:  mikeperry|Sponsor:
-+-

Comment (by nickm):

 I'm fine with `-fno-sanitize=float-divide-by-zero` globally.  Should I
 wait until #29298 is merged to merge this branch?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] [Tor Bug Tracker & Wiki] Batch modify: #29632, #29633

[Tor Bug Tracker & Wiki]

Batch modification to #29632, #29633 by gk:


Comment:
mobile tickets

--
Tickets URL: 
Tor Bug Tracker & Wiki 
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] #29632 [Applications/Tor Browser]: Fretch Gradle over HTTPS when prepaing android toolchain build

[Tor Bug Tracker & Wiki]

#29632: Fretch Gradle over HTTPS when prepaing android toolchain build
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201903R,  |  Actual Points:
  GeorgKoppen201903  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-rbm, TorBrowserTeam201903, GeorgKoppen201903 => tbb-rbm,
 TorBrowserTeam201903R, GeorgKoppen201903
 * status:  new => needs_review


Comment:

 `bug_29632` (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/commit/?h=bug_29633=1e09514cd1bfdeba863a84929edfc21ede3f8b9d)
 in my public `tor-browser-build` repo has a patch for 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] #29633 [Applications/Tor Browser]: Don't bundle pdnsd in Tor Browser for Android

[Tor Bug Tracker & Wiki]

#29633: Don't bundle pdnsd in Tor Browser for Android
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201903R,  |  Actual Points:
  GeorgKoppen201903  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-rbm, TorBrowserTeam201903, GeorgKoppen201903 => tbb-rbm,
 TorBrowserTeam201903R, GeorgKoppen201903
 * status:  new => needs_review


Comment:

 `bug_29633` (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/commit/?h=bug_29633=e39c1dbe69a48274c5e806efc0ef2d407085b255)
 has the patch for 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] #29624 [Metrics/ExoneraTor]: New version of exit list format

[Tor Bug Tracker & Wiki]

#29624: New version of exit list format
-+-
 Reporter:  irl  |  Owner:  karsten
 Type:  task | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/ExoneraTor   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-exit-list-project metrics-   |  Actual Points:
  roadmap-2019-q2|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by karsten):

 Replying to [comment:2 irl]:
 > Replying to [comment:1 karsten]:
 > > > * Source ASN
 > > > * Source country
 > >
 > > I'm not sure about these. We would basically include these by having
 the source look up its IP address in a database. But then the result
 depends on which database (version) the source uses. Of course, whoever
 uses this information could as well look up the source IP address in the
 database (version) of their choice and discard these two fields. Maybe
 this means we shouldn't put too much effort in the source's ability to
 include these two fields. Or we could just omit them from the spec. Not
 sure!
 >
 > I would rather have them as optional if you think that they would not be
 required. I would expect this to be either declared by the user, who
 should know best, or looked up via RIPEstat.

 We can specify these. What format would we expect the country and ASN to
 be in?

 > > This one is tricky. I don't think that the current scanner includes
 scans that ended with unknown failures or timeouts. It includes, for each
 found exit IP address, the latest scan time of a successful run resulting
 in that IP address. It probably omits IP addresses after a given number of
 hours, but we'd have to look at the code in order to know.
 >
 > I would like to have one line per measurement, whether it succeeds, has
 a duplicate result, fails, or whatever. This helps us to understand how
 the tool is performing and doesn't hide information that would be really
 useful in debugging.

 I see your point. However, this would be a backward-incompatible change to
 the current document format where the IP address is unique for the
 `ExitAddress` lines of any given router. And it might not scale if we add
 lots and lots of scans all ending with the same result. Unclear.

 > > > I think we should probably have one line per measurement, so IPv4
 and IPv6 results would be listed separately, not on the same line. In the
 future we may have differing transports to consider (TCP/QUIC/something
 else) so maybe we should not just have IPv4 vs IPv6 but some numeric
 identifier that is later extensible.
 > >
 > > Agreed on the IPv4/IPv6 distinction. I was thinking to simply include
 a new `ExitAddress6` line for IPv6 addresses and continue using
 `ExitAddress` for IPv4 addresses. And I'd probably simply add another
 keyword for the next transport or address version. What else do you have
 in mind?
 >
 > This could also work, but we should do it in a way that we have defined
 a generalised format for the measurement result and then we have specifics
 for IPv4 and IPv6 which should just be that the expected address format is
 different.

 Sounds good.

 > > Relatedly, I'd want to include `OrAddress` and `OrAddress6` for the
 addresses found in the consensus. Background is that I'd like to use exit
 lists as single input document type for ExoneraTor in the future.
 >
 > Perhaps we are describing Internet Address Lists and not Exit Lists?

 Possibly. Maybe this won't scale, either. Unclear.

 > > > Exit lists are not currently included in torspec but probably should
 be. The specification should cover the existing format, and then also the
 new format. We should expect that we will later extend the new format with
 a signature. Maybe we should just figure that out now also.
 > >
 > > Turns out that specifying the existing format is not trivial. Right
 now I'm looking at metrics-lib only, but I think I'll have to look at
 other code that produces/consumes these lists. For example, it would be
 great to know whether `Published` and `LastStatus` in the current format
 are considered required or optional fields, because it would be very
 convenient to lose them in version 2. What other code I should be looking
 at?
 >
 > I've not thought about this yet, but why would it be convenient to lose
 these in version 2?

 Both are rather implementation-specific pieces of information that are not
 really relevant for exit lists. `Published` is used to avoid doing another
 scan until the next descriptor arrives, and `LastStatus` is used to decide
 when to discard a router. 

Re: [tor-bugs] #29527 [Core Tor/Tor]: Division by zero: undefined behaviour in circuitpadding/circuitpadding_sample_distribution test

[Tor Bug Tracker & Wiki]

#29527: Division by zero: undefined behaviour in
circuitpadding/circuitpadding_sample_distribution test
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, tor-ci, tor-test,|  Actual Points:
  040-must   |
Parent ID:   | Points:
 Reviewer:  mikeperry|Sponsor:
-+-
Changes (by mikeperry):

 * status:  needs_review => merge_ready


Comment:

 Little nervous about disabling divide by zero sanitation across all of Tor
 for this code, but it's not actually undefined behavior, so it's probably
 ok.

 Thought I should still just flag that for Nick in case he wants to hack
 autoconf to apply -fno-sanitize=float-divide-by-zero to just this c file
 somehow.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29624 [Metrics/ExoneraTor]: New version of exit list format

[Tor Bug Tracker & Wiki]

#29624: New version of exit list format
-+-
 Reporter:  irl  |  Owner:  karsten
 Type:  task | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/ExoneraTor   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-exit-list-project metrics-   |  Actual Points:
  roadmap-2019-q2|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by irl):

 Replying to [comment:1 karsten]:
 > > * Source ASN
 > > * Source country
 >
 > I'm not sure about these. We would basically include these by having the
 source look up its IP address in a database. But then the result depends
 on which database (version) the source uses. Of course, whoever uses this
 information could as well look up the source IP address in the database
 (version) of their choice and discard these two fields. Maybe this means
 we shouldn't put too much effort in the source's ability to include these
 two fields. Or we could just omit them from the spec. Not sure!

 I would rather have them as optional if you think that they would not be
 required. I would expect this to be either declared by the user, who
 should know best, or looked up via RIPEstat.

 > This one is tricky. I don't think that the current scanner includes
 scans that ended with unknown failures or timeouts. It includes, for each
 found exit IP address, the latest scan time of a successful run resulting
 in that IP address. It probably omits IP addresses after a given number of
 hours, but we'd have to look at the code in order to know.

 I would like to have one line per measurement, whether it succeeds, has a
 duplicate result, fails, or whatever. This helps us to understand how the
 tool is performing and doesn't hide information that would be really
 useful in debugging.

 > > I think we should probably have one line per measurement, so IPv4 and
 IPv6 results would be listed separately, not on the same line. In the
 future we may have differing transports to consider (TCP/QUIC/something
 else) so maybe we should not just have IPv4 vs IPv6 but some numeric
 identifier that is later extensible.
 >
 > Agreed on the IPv4/IPv6 distinction. I was thinking to simply include a
 new `ExitAddress6` line for IPv6 addresses and continue using
 `ExitAddress` for IPv4 addresses. And I'd probably simply add another
 keyword for the next transport or address version. What else do you have
 in mind?

 This could also work, but we should do it in a way that we have defined a
 generalised format for the measurement result and then we have specifics
 for IPv4 and IPv6 which should just be that the expected address format is
 different.

 > Relatedly, I'd want to include `OrAddress` and `OrAddress6` for the
 addresses found in the consensus. Background is that I'd like to use exit
 lists as single input document type for ExoneraTor in the future.

 Perhaps we are describing Internet Address Lists and not Exit Lists?

 > > Exit lists are not currently included in torspec but probably should
 be. The specification should cover the existing format, and then also the
 new format. We should expect that we will later extend the new format with
 a signature. Maybe we should just figure that out now also.
 >
 > Turns out that specifying the existing format is not trivial. Right now
 I'm looking at metrics-lib only, but I think I'll have to look at other
 code that produces/consumes these lists. For example, it would be great to
 know whether `Published` and `LastStatus` in the current format are
 considered required or optional fields, because it would be very
 convenient to lose them in version 2. What other code I should be looking
 at?

 I've not thought about this yet, but why would it be convenient to lose
 these in version 2?

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

Re: [tor-bugs] #28866 [Core Tor/sbws]: ResultDump.queue.put() can hang if the queue is full

[Tor Bug Tracker & Wiki]

#28866: ResultDump.queue.put() can hang if the queue is full
---+---
 Reporter:  teor   |  Owner:  juga
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28663 | Points:  1
 Reviewer:  mikeperry  |Sponsor:
---+---
Changes (by mikeperry):

 * status:  needs_review => merge_ready


Comment:

 Ok this looks good. Sorry for the delay.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29587 [Community/Tor Support]: How to Fix Quick-Books Payroll Error PS032 & PS077

[Tor Bug Tracker & Wiki]

#29587: How to Fix Quick-Books Payroll Error PS032 & PS077
---+---
 Reporter:  yaret11|  Owner:  irl
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by irl):

 * status:  new => needs_information


Comment:

 Is this about trying to update QuickBooks through Tor?

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

Re: [tor-bugs] #29587 [Community/Tor Support]: How to Fix Quick-Books Payroll Error PS032 & PS077

[Tor Bug Tracker & Wiki]

#29587: How to Fix Quick-Books Payroll Error PS032 & PS077
---+-
 Reporter:  yaret11|  Owner:  irl
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by irl):

 * keywords:  error code PS032 & PS077 =>
 * status:  assigned => new
 * component:  Webpages/Research => Community/Tor Support


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29633 [Applications/Tor Browser]: Don't bundle pdnsd in Tor Browser for Android

[Tor Bug Tracker & Wiki]

#29633: Don't bundle pdnsd in Tor Browser for Android
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-rbm,
 Severity:  Normal   |  TorBrowserTeam201903,
 |  GeorgKoppen201903
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Since we don't use the VPN we don't need to bundle pdnsd. Thanks for
 noticing, Nathan.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29628 [Applications/Tor Browser]: Distrust DarkMatter Intermediate CAs

[Tor Bug Tracker & Wiki]

#29628: Distrust DarkMatter Intermediate CAs
--+--
 Reporter:  nsuchy|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by sysrqb):

 * priority:  Immediate => Medium
 * severity:  Critical => Major


Comment:

 You may find the entire thread discussing this topic enlightening. I am
 personally in support of Mozilla denying the root inclusion request and
 revoking their intermediate CA certificate. However, as it was said
 numerous times in the discussion thread, the only reason we know
 DarkMatter have these CA certificates is because they applied for root
 inclusion - in a public forum. It is very easy for a malicious
 organization to obtain an intermediate CA certificate without that
 certificate being attributable to them. As far as anyone knows (publicly),
 DarkMatter haven't used their current Intermediate CA with malicious
 intent, yet(!). If DarkMatter use their CA for malicious purpose in the
 future and that malicious activity is detected, then their intermediate CA
 certificate should be revoked by DigiCert (and therefore they lose their
 trusted position globally). The current question is whether Mozilla should
 pre-emptively revoke DarkMatter's Intermediate certificate and reject
 their current root.

 The Tor Project isn't in a position where we can successfully audit all
 anchor and intermediate CAs included in Mozilla's root store. And, even if
 we could, we likely wouldn't be able to maintain that long-term. We can
 distrust DarkMatter's current intermediate, but given the previous
 statement about how Intermediate CAs certificates can be obtained
 relatively easily under alternative-names, I don't know if this is a
 winning solution. In reality, distrusting one intermediate CA is likely
 pointless, other than making a political statement.

 I'll leave this open, in case anyone else on the team has more input here.

 
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/YiybcXciBQAJ

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29632 [Applications/Tor Browser]: Fretch Gradle over HTTPS when prepaing android toolchain build

[Tor Bug Tracker & Wiki]

#29632: Fretch Gradle over HTTPS when prepaing android toolchain build
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-rbm,
 Severity:  Normal   |  TorBrowserTeam201903,
 |  GeorgKoppen201903
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 For some reason we fetch Gradle over HTTP right now (although checking the
 SHA-256 sum). We should use HTTPS.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29631 [Core Tor/Tor]: protover: Rust missing Padding value in translate_to_rust()

[Tor Bug Tracker & Wiki]

#29631: protover: Rust missing Padding value in translate_to_rust()
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust, protover, fast-fix  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  assigned => needs_review
 * keywords:  rust, protover => rust, protover, fast-fix


Comment:

 PR: https://github.com/torproject/tor/pull/751
 Branch: `ticket29631_041_01`

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29631 [Core Tor/Tor]: protover: Rust missing Padding value in translate_to_rust()

[Tor Bug Tracker & Wiki]

#29631: protover: Rust missing Padding value in translate_to_rust()
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  rust, protover
Actual Points:|  Parent ID:
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+
 Noticed that when I was adding the protover support in #26288.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29111 [Obfuscation/Pluggable transport]: Optional heartbeat message from PT's

[Tor Bug Tracker & Wiki]

#29111: Optional heartbeat message from PT's
-+-
 Reporter:  ahf  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Obfuscation/Pluggable transport  |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor19
-+-

Comment (by ahf):

 This should be done using the other new message (`STATUS`) rather than
 `LOG`. In this ticket we should figure out what information would be
 useful to note here and standardize the parameters to the given `STATUS`
 message (which values we emit).

 If a PT process today want to just do a "plain text" heartbeat like log
 line (like Tor does) they can do it via the `LOG` statement. This is less
 useful for Tor though since we would have to parse the text message, which
 is what `STATUS` tries to solve.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29111 [Obfuscation/Pluggable transport]: Optional heartbeat message from PT's

[Tor Bug Tracker & Wiki]

#29111: Optional heartbeat message from PT's
-+-
 Reporter:  ahf  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Obfuscation/Pluggable transport  |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor19
-+-

Comment (by arma):

 Is this ticket accomplishable now that there is a LOG message equivalent
 from PTs to Tor? Or is this about tagging the log message in a special way
 so that Tor knows to treat it as a contribution to its own heartbeat
 messages?

 If it's this second one, I wonder if we want to generalize to adding a
 domain or something to the log messages coming from PTs, so the PT can
 label its messages however it likes. And then the first use case there
 would be for some of the log messages to be in the heartbeat domain, and
 then Tor would know how the PT thinks the user should be informed.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25688 [Obfuscation/Snowflake]: proxy-go is still deadlocking occasionally

[Tor Bug Tracker & Wiki]

#25688: proxy-go is still deadlocking occasionally
---+--
 Reporter:  dcf|  Owner:  cohosh
 Type:  defect | Status:  assigned
 Priority:  Low|  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:  3
 Reviewer: |Sponsor:
---+--
Changes (by cohosh):

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


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29630 [Applications/Tor Browser]: TorBrowser creates empty directory in "/tmp"

[Tor Bug Tracker & Wiki]

#29630: TorBrowser creates empty directory in "/tmp"
+--
 Reporter:  AxelF   |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Component:  Applications/Tor Browser
  Version:  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 I'm using the latest TBB on Linux.

 After I start TorBrowser, the directory is created in temporary direcrory
 (in my case /tmp)

 drwx-- 2 user user4096 Mar  1 12:34 Temp-
 41d8a42b-5545-4af5-89c2-be2502af95c7

 The directory is empty. After I close the TBB, this directory disappears.
 Not sure if it's OK behavior or not.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29629 [Core Tor]: Cannot establish a TOR Browser session

[Tor Bug Tracker & Wiki]

#29629: Cannot establish a TOR Browser session
--+--
 Reporter:  DavidTC44 |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  Core Tor
  Version:  Tor: unspecified  |   Severity:  Blocker
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 Whn I attempt to establish a TOR Browser session in the morning, I usually
 have success.  However, whenI try to reestablish contact in the afternoon,
 I failed with the message;

 Tor failed to establish a Tor network connection

 Establishing an encrypted connection failed (done 128.31.0.34.9101).

 I have tried re-booting several times and it makes no difference.  Why
 does Tor work in the a.m, but invariably fails in the p.m.

  I am working in the UK on GMT.  I running under wonderful Windows 10
 (NOT!).

 David T-C.

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_revision => needs_review


Comment:

 I've force pushed quite a big fix on the last commit. I recommend a
 complete re-read of section 4 (Deployment).

 I've expanded it considering teor's comment and a discussion I had with
 Nick this morning on IRC. Basically, keeping v0 support on *directory one-
 hop* circuit could be desirable as a buffer once v0 is not accepted
 anymore.

 I've also added a Timeline section to try to give us a better idea of how
 it looks.

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

Re: [tor-bugs] #29626 [Applications/Tor Browser]: TBA: Application name is now "Always-On Notifications"

[Tor Bug Tracker & Wiki]

#29626: TBA: Application name is now "Always-On Notifications"
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a3,  |  Actual Points:
  TorBrowserTeam201903   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 Okay, I was worried this may be a result of manually tweaking the version
 code (due to #28685), and it seems this is the case. When I created the
 tweaked AndroidManifest.xml file, it was compiled from a different source
 (not a tor-browser-build build), so it seems some of the string indices
 changed. The result of this is the manifest file now points to the wrong
 strings for `android:label`. Thankfully, this is the only erroneous
 change, but still it isn't good (I'm sorry I wasn't more careful with this
 change). At the time when I made this, I noticed there were additional
 modifications within the file but they seemed insignificant. Now I know
 they weren't.

 (See the end of this comment for the overall effect)

 Diffing the outputs from:
 {{{
 aapt l -a tor-browser-8.5a8-android-armv7-multi-qa.apk
 aapt l -a tor-browser-8.5a8-android-armv7-multi.apk
 }}}

 {{{
 --- aapt_l_a_8.5a8_qa   2019-03-01 15:40:27.039709996 +
 +++ aapt_l_a_8.5a8  2019-03-01 15:37:53.990400730 +
 @@ -1,6 +1,3 @@
 -META-INF/MANIFEST.MF
 -META-INF/ANDROIDQ.SF
 -META-INF/ANDROIDQ.RSA
  AndroidManifest.xml
  assets/LICENSE
  assets/common/bridges.txt
 @@ -1571,9 +1568,11 @@
  platform.ini
  removed-files
  assets/omni.ja
 -assets/distribution/extensions/
  assets/distribution/extensions/https-everywhere-...@eff.org.xpi
  assets/distribution/extensions/{73a6fe31-595d-460b-a920-fcc0f8843232}.xpi
 +META-INF/TBA_ALPH.SF
 +META-INF/TBA_ALPH.RSA
 +META-INF/MANIFEST.MF

  Resource table:
  Package Groups (1)
 @@ -46657,7 +46656,7 @@
  N: android=http://schemas.android.com/apk/res/android
E: manifest (line=1)
  A:
 android:sharedUserId(0x0101000b)="org.torproject.torbrowser_alpha.sharedID"
 (Raw: "org.torproject.torbrowser_alpha.sharedID")
 -A: android:versionCode(0x0101021b)=(type 0x10)0x7823c271
 +A: android:versionCode(0x0101021b)=(type 0x10)0x7823c272
  A: android:versionName(0x0101021c)="60.5.1" (Raw: "60.5.1")
  A: android:installLocation(0x010102b7)=(type 0x10)0x1
  A: package="org.torproject.torbrowser_alpha" (Raw:
 "org.torproject.torbrowser_alpha")
 @@ -46695,12 +46694,12 @@
A:
 
android:name(0x01010003)="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS"
 (Raw: "android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS")
  E: application (line=16)
A: android:theme(0x0101)=@0x7f0d0143
 -  A: android:label(0x01010001)=@0x7f0801db
 +  A: android:label(0x01010001)=@0x7f0802cc
A: android:icon(0x01010002)=@0x7f0200ed
A: android:name(0x01010003)="org.mozilla.gecko.GeckoApplication"
 (Raw: "org.mozilla.gecko.GeckoApplication")
A: android:allowClearUserData(0x01010005)=(type 0x12)0x
A: android:configChanges(0x0101001f)=(type 0x11)0x484
 -  A: android:description(0x01010020)=@0x7f080028
 +  A: android:description(0x01010020)=@0x7f08001a
A: android:allowBackup(0x01010280)=(type 0x12)0x0
A: android:logo(0x010102be)=@0x7f0200fe
A: android:hardwareAccelerated(0x010102d3)=(type 0x12)0x
 @@ -46848,7 +46847,7 @@
  A: android:name(0x01010003)="android.intent.category.DEFAULT"
 (Raw: "android.intent.category.DEFAULT")
E: activity (line=100)
  A: android:theme(0x0101)=@0x7f0d014a
 -A: android:label(0x01010001)=@0x7f0801db
 +A: android:label(0x01010001)=@0x7f0802cc
  A: android:name(0x01010003)="org.mozilla.gecko.BrowserApp" (Raw:
 "org.mozilla.gecko.BrowserApp")
  A: android:exported(0x01010010)=(type 0x12)0x
  A:
 android:taskAffinity(0x01010012)="org.torproject.torbrowser_alpha.BROWSER"
 (Raw: "org.torproject.torbrowser_alpha.BROWSER")
 @@ -46945,7 +46944,7 @@
  A:
 
android:authorities(0x01010018)="org.torproject.torbrowser_alpha.partnerbookmarks"
 (Raw: "org.torproject.torbrowser_alpha.partnerbookmarks")
E: activity (line=144)
  A: android:theme(0x0101)=@0x7f0d00f7
 -A: android:label(0x01010001)=@0x7f0801f7
 +A: android:label(0x01010001)=@0x7f0802da
  A:
 

Re: [tor-bugs] #29628 [Applications/Tor Browser]: Distrust DarkMatter Intermediate CAs

[Tor Bug Tracker & Wiki]

#29628: Distrust DarkMatter Intermediate CAs
--+--
 Reporter:  nsuchy|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nsuchy):

 Also of note, Firefox does not enforce certificate transparency logs so
 DarkMatter could simply not log rouge issued certificates, or if they
 enforce only on new domains, they could backdate the certificates.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29628 [Applications/Tor Browser]: Distrust DarkMatter Intermediate CAs

[Tor Bug Tracker & Wiki]

#29628: Distrust DarkMatter Intermediate CAs
---+--
 Reporter:  nsuchy |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Immediate  |  Component:  Applications/Tor Browser
  Version: |   Severity:  Critical
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 Mozilla Firefox's root trust store trusts an intermediate ca for a spying
 firm called DarkMatter. They trust they intermediate ca as it was signed
 by Quovadis.

 This already puts Tor users at risk as they can spy today, however once
 they are a root ca there will be no oversight by Quovadis/Digicert and
 they can misbehave and issue secret certificates to spy on Tor users.

 They have a business interest in spying on HTTPS traffic. Google Chrome
 and Mozilla Firefox are still discussing this. It's in the best interest
 of Tor Users to immediately distrust the intermediate CA.

 Thoughts?

 References:
 https://www.bleepingcomputer.com/news/security/cybersecurity-firm-
 darkmatter-request-to-be-trusted-root-ca-raises-concerns/
 https://protonmail.com/blog/dark-matter-quo-vadis/

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29626 [Applications/Tor Browser]: TBA: Application name is now "Always-On Notifications"

[Tor Bug Tracker & Wiki]

#29626: TBA: Application name is now "Always-On Notifications"
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a3,  |  Actual Points:
  TorBrowserTeam201903   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:   => tbb-mobile, TBA-a3, TorBrowserTeam201903


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29588 [Core Tor/Tor]: Make a post-merge hook that logs a message when the git hooks are updated in master

[Tor Bug Tracker & Wiki]

#29588: Make a post-merge hook that logs a message when the git hooks are 
updated
in master
---+--
 Reporter:  teor   |  Owner:  rl1987
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  git-scripts, 041-proposed  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:
---+--
Changes (by rl1987):

 * status:  accepted => needs_review


Comment:

 https://github.com/torproject/tor/pull/750

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29627 [Applications/Tor Launcher]: Moat: add support for obfsproxy's meek_lite

[Tor Bug Tracker & Wiki]

#29627: Moat: add support for obfsproxy's meek_lite
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201903R  |  Actual Points:
Parent ID:  #29430 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by mcs):

 * keywords:  TorBrowserTeam201903 => TorBrowserTeam201903R
 * status:  new => needs_review


Comment:

 Here is a patch:
 https://gitweb.torproject.org/user/brade/tor-
 launcher.git/commit/?h=bug29627-01=9ddc818a394623bc21c900fa473a6d0802537733

 With these changes, Moat works with both `meek-client-torbrowser` and
 `obfs4proxy`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29542 [Core Tor/Tor]: Stop using weak_rng.

[Tor Bug Tracker & Wiki]

#29542: Stop using weak_rng.
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  dgoulet-merge  |  Actual Points:  .1
Parent ID: | Points:  .1
 Reviewer:  asn|Sponsor:
---+
Changes (by dgoulet):

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


Comment:

 Merged to master!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29430 [Applications/Tor Browser]: Use uTLS for meek TLS camouflage in Tor Browser

[Tor Bug Tracker & Wiki]

#29430: Use uTLS for meek TLS camouflage in Tor Browser
--+--
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  meek utls |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mcs):

 I filed #29627 for the Tor Launcher work necessary to use meek_lite.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29627 [Applications/Tor Launcher]: Moat: add support for obfsproxy's meek_lite

[Tor Bug Tracker & Wiki]

#29627: Moat: add support for obfsproxy's meek_lite
---+---
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal |   Keywords:
   |  TorBrowserTeam201903
Actual Points: |  Parent ID:  #29430
   Points: |   Reviewer:
  Sponsor: |
---+---
 We should improve the Moat client support in Tor Launcher so it will work
 with obfsproxy's meek_lite implementation (as well as with dcf's meek
 implementation). The main reason it does not currently work is because the
 code inside Tor Launcher that interacts with the PT program relies on
 command line parameters instead of SOCKS args to pass info to the PT.

 For more background, see ticket:29430#comment:5 and other related comments
 within #29430.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29588 [Core Tor/Tor]: Make a post-merge hook that logs a message when the git hooks are updated in master

[Tor Bug Tracker & Wiki]

#29588: Make a post-merge hook that logs a message when the git hooks are 
updated
in master
---+--
 Reporter:  teor   |  Owner:  rl1987
 Type:  enhancement| Status:  accepted
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  git-scripts, 041-proposed  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:
---+--
Changes (by rl1987):

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


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29625 [Core Tor/Tor]: git-pull-all.sh should say which branches it updated, and which files changed

[Tor Bug Tracker & Wiki]

#29625: git-pull-all.sh should say which branches it updated, and which files
changed
--+--
 Reporter:  nickm |  Owner:  dgoulet
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  git-scripts   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

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


Comment:

 I can certainly do that once #29616 is merged since it changes how the
 pull is done :S.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29617 [Core Tor/Tor]: OOM manger wipes entire DNS cache

[Tor Bug Tracker & Wiki]

#29617: OOM manger wipes entire DNS cache
-+-
 Reporter:  pulls|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.0.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  035-backport 040-backport fast-fix   |  Actual Points:
  easy   |
Parent ID:   | Points:  0
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:   => 035-backport 040-backport fast-fix easy
 * points:   => 0
 * milestone:   => Tor: 0.4.1.x-final


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

Re: [tor-bugs] #29616 [Core Tor/Tor]: Git scripts should fetch once only.

[Tor Bug Tracker & Wiki]

#29616: Git scripts should fetch once only.
--+--
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  git-scripts   |  Actual Points:
Parent ID:| Points:
 Reviewer:  teor  |Sponsor:
--+--
Changes (by dgoulet):

 * 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

[tor-bugs] #29626 [Applications/Tor Browser]: TBA: Application name is now "Always-On Notifications"

[Tor Bug Tracker & Wiki]

#29626: TBA: Application name is now "Always-On Notifications"
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Why? eighthave noticed this, too. It seems like this is coming from
 Orbot's `pref_use_persistent_notifications_title` string? Something
 changed between 8.5a7 and 8.5a8.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29625 [Core Tor/Tor]: git-pull-all.sh should say which branches it updated, and which files changed

[Tor Bug Tracker & Wiki]

#29625: git-pull-all.sh should say which branches it updated, and which files
changed
--+-
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  git-scripts
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 One of our defenses against weird merges is that when each developer pulls
 the latest version of the branches, git will tell them which files
 changed.  But if I'm reading the output of the git scripts correctly, they
 don't actually do this.

 IMO we should _not_ suppress the output of the pull/merge operations here,
 or at least not the part that says what changed.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29624 [Metrics/ExoneraTor]: New version of exit list format

[Tor Bug Tracker & Wiki]

#29624: New version of exit list format
-+-
 Reporter:  irl  |  Owner:  karsten
 Type:  task | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/ExoneraTor   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-exit-list-project metrics-   |  Actual Points:
  roadmap-2019-q2|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by karsten):

 * status:  new => accepted
 * cc: metrics-team (added)
 * owner:  metrics-team => karsten


Comment:

 I already started working on this as discussed yesterday. Some comments:

 Replying to [ticket:29624 irl]:
 > We need to extend the exit list format to include:
 >
 > Metadata:
 >
 > * Source identifier
 > * Source software name
 > * Source software version
 > * Source IP address

 I already have these.

 > * Source ASN
 > * Source country

 I'm not sure about these. We would basically include these by having the
 source look up its IP address in a database. But then the result depends
 on which database (version) the source uses. Of course, whoever uses this
 information could as well look up the source IP address in the database
 (version) of their choice and discard these two fields. Maybe this means
 we shouldn't put too much effort in the source's ability to include these
 two fields. Or we could just omit them from the spec. Not sure!

 > * Source operator contact details
 >
 > Measurement results:
 >
 > * IPv6 addresses

 Yep, these make sense.

 > * Error code
 >
 > Error codes:
 >
 > * Success
 > * Unknown Failure
 > * Timeout
 > * (others we can think of now, but we can extend this later when we
 actually implement it)

 This one is tricky. I don't think that the current scanner includes scans
 that ended with unknown failures or timeouts. It includes, for each found
 exit IP address, the latest scan time of a successful run resulting in
 that IP address. It probably omits IP addresses after a given number of
 hours, but we'd have to look at the code in order to know.

 > I think we should probably have one line per measurement, so IPv4 and
 IPv6 results would be listed separately, not on the same line. In the
 future we may have differing transports to consider (TCP/QUIC/something
 else) so maybe we should not just have IPv4 vs IPv6 but some numeric
 identifier that is later extensible.

 Agreed on the IPv4/IPv6 distinction. I was thinking to simply include a
 new `ExitAddress6` line for IPv6 addresses and continue using
 `ExitAddress` for IPv4 addresses. And I'd probably simply add another
 keyword for the next transport or address version. What else do you have
 in mind?

 Relatedly, I'd want to include `OrAddress` and `OrAddress6` for the
 addresses found in the consensus. Background is that I'd like to use exit
 lists as single input document type for ExoneraTor in the future.

 > Exit lists are not currently included in torspec but probably should be.
 The specification should cover the existing format, and then also the new
 format. We should expect that we will later extend the new format with a
 signature. Maybe we should just figure that out now also.

 Turns out that specifying the existing format is not trivial. Right now
 I'm looking at metrics-lib only, but I think I'll have to look at other
 code that produces/consumes these lists. For example, it would be great to
 know whether `Published` and `LastStatus` in the current format are
 considered required or optional fields, because it would be very
 convenient to lose them in version 2. What other code I should be looking
 at?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29064 [Core Tor/Tor]: shellcheck: test_rust.sh issues

[Tor Bug Tracker & Wiki]

#29064: shellcheck: test_rust.sh issues
+
 Reporter:  rl1987  |  Owner:  rl1987
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  catalyst|Sponsor:
+
Changes (by nickm):

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


Comment:

 merged to master!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29542 [Core Tor/Tor]: Stop using weak_rng.

[Tor Bug Tracker & Wiki]

#29542: Stop using weak_rng.
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  enhancement| Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  dgoulet-merge  |  Actual Points:  .1
Parent ID: | Points:  .1
 Reviewer:  asn|Sponsor:
---+
Changes (by nickm):

 * keywords:   => dgoulet-merge


Comment:

 I've added documentation to asn's request.

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

Re: [tor-bugs] #29120 [Applications/Tor Browser]: Default value of media.cache_size (0) causes some media to load extremely slowly or become unplayable

[Tor Bug Tracker & Wiki]

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

Comment (by cypherpunks):

 Don't waste time. Open a ticket on Bugzilla.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29624 [Metrics/ExoneraTor]: New version of exit list format

[Tor Bug Tracker & Wiki]

#29624: New version of exit list format
-+-
 Reporter:  irl  |  Owner:  metrics-team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:   |Version:
  Metrics/ExoneraTor |   Keywords:  metrics-exit-list-project metrics-
 Severity:  Normal   |  roadmap-2019-q2
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We need to extend the exit list format to include:

 Metadata:

 * Source identifier
 * Source software name
 * Source software version
 * Source IP address
 * Source ASN
 * Source country
 * Source operator contact details

 Measurement results:

 * IPv6 addresses
 * Error code

 Error codes:

 * Success
 * Unknown Failure
 * Timeout
 * (others we can think of now, but we can extend this later when we
 actually implement it)

 I think we should probably have one line per measurement, so IPv4 and IPv6
 results would be listed separately, not on the same line. In the future we
 may have differing transports to consider (TCP/QUIC/something else) so
 maybe we should not just have IPv4 vs IPv6 but some numeric identifier
 that is later extensible.

 Exit lists are not currently included in torspec but probably should be.
 The specification should cover the existing format, and then also the new
 format. We should expect that we will later extend the new format with a
 signature. Maybe we should just figure that out now also.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29542 [Core Tor/Tor]: Stop using weak_rng.

[Tor Bug Tracker & Wiki]

#29542: Stop using weak_rng.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  .1
Parent ID:| Points:  .1
 Reviewer:  asn   |Sponsor:
--+
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 LGTM. Nitpick: Might be worth documenting what
 `crypto_fast_rng_one_in_n()` does.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29330 [Metrics/Website]: Do something with advertised bandwidth distribution graphs

[Tor Bug Tracker & Wiki]

#29330: Do something with advertised bandwidth distribution graphs
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  irl  |Sponsor:
-+--

Comment (by teor):

 I often use n-th fastest to work out the fastest relay(s) over time.

 I expect to use n-th fastest a bit while developing PrivCount to answer
 questions like:
 * what's the highest bandwidth?
 * what do we get if we aggregate the top N relays?
 * what's the minimum relay count and consensus weight we should require to
 create an aggregate total?
 (we can't have a bandwidth requirement, because we don't know the
 bandwidth until *after* we aggregate)

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

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

[Tor Bug Tracker & Wiki]

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

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


Comment:

 Child now in `needs_review` and un-parented.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29354 [Core Tor/Tor]: Update bandwidth-file-spec.txt with the country keyword

[Tor Bug Tracker & Wiki]

#29354: Update bandwidth-file-spec.txt with the country keyword
-+-
 Reporter:  juga |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bwauth, tor-spec, postfreeze-|  Actual Points:
  ok, 040-must, spec |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by juga):

 * parent:  #29299 =>


Comment:

 Un-parenting because 29299 has already been merged, to be able to close
 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] #29354 [Core Tor/Tor]: Update bandwidth-file-spec.txt with the country keyword

[Tor Bug Tracker & Wiki]

#29354: Update bandwidth-file-spec.txt with the country keyword
-+-
 Reporter:  juga |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bwauth, tor-spec, postfreeze-|  Actual Points:
  ok, 040-must, spec |
Parent ID:  #29299   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by juga):

 * status:  new => needs_review


Comment:

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

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27539 [Applications/Tor Browser]: Create plan for releasing on F-Droid

[Tor Bug Tracker & Wiki]

#27539: Create plan for releasing on F-Droid
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201902,|  Actual Points:
  TBA-8.5|
Parent ID:  #26318   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by boklm):

 Replying to [comment:14 sysrqb]:

 > I currently have a metadata file ready and it successfully builds tor
 browser using tor-browser-build within a fdroidserver instance I installed
 locally. My main worry here is how long the build process takes. On a
 bare-metal older laptop I'm using, the entire build process for armv7
 takes roughly 3.5 hours. I'm under the impression F-Droid use VMs for each
 app build, and there's an upper bound of 7 hours(?) per build. If this is
 true, then I won't be surprised if we hit that timeout limit. One of the
 main reasons for this is artifacts are not cached across builds - so all
 repos and files are cloned/downloaded for every build iteration. I
 understand why this is important for a general apk builder, but this is
 painful for a large project like tor browser.

 I'm wondering if there could be an option in the F-Droid build to save
 some files at the end of a build, and restore them when starting a new
 builds.

 I think the directories we would want to keep are `out/`, `git_clones/`,
 `gclient/`.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by gk):

 sysrqb: how are you building `tor-android-service`? I can successfully
 build it using sisbell's `android-0224` branch.

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

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

[Tor Bug Tracker & Wiki]

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

 * cc: hans@… (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] #27609 [Applications/Tor Browser]: TBA: Evaluate Tor Onion Proxy Library

[Tor Bug Tracker & Wiki]

#27609: TBA: Evaluate Tor Onion Proxy Library
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a3,  |  Actual Points:
  TorBrowserTeam201902   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by eighthave):

 * cc: hans@… (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] #28803 [Applications/Tor Browser]: Integrate building pluggable transports for Android into tor-browser-build

[Tor Bug Tracker & Wiki]

#28803: Integrate building pluggable transports for Android into 
tor-browser-build
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, TBA-a3, tor-|  Actual Points:
  pt, TorBrowserTeam201902   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by eighthave):

 * cc: hans@… (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] #29575 [Applications/Tor Browser]: Configure Firefox Project to Use New TOPL Dependencies

[Tor Bug Tracker & Wiki]

#29575: Configure Firefox Project to Use New TOPL Dependencies
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a3,  |  Actual Points:
  TorBrowserTeam201902   |
Parent ID:  #27609   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 sisbell: Where are we here? It seems that's the last big chunk to get the
 whole TOPL related changes tested in a build...

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