Re: [tor-bugs] #26042 [Core Tor/Tor]: Add a new option "RouteDNSTraffic" to prevent noobs from insecure way to use Tor.

[Tor Bug Tracker & Wiki]

#26042: Add a new option "RouteDNSTraffic" to prevent noobs from insecure way to
use Tor.
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|
--+

Comment (by cypherpunks):

 http://mayakron.altervista.org/wikibase/show.php?id=AcrylicConfiguration

 PrimaryServerProtocol=SOCKS5
 PrimaryServerProxyAddress=127.0.0.1
 PrimaryServerProxyPort=9150
 PrimaryServerAddress=8.8.8.8
 PrimaryServerPort=53

 (copied from some website titled 'how to use Tor with DNS')

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26042 [Core Tor/Tor]: Add a new option "RouteDNSTraffic" to prevent noobs from insecure way to use Tor.

[Tor Bug Tracker & Wiki]

#26042: Add a new option "RouteDNSTraffic" to prevent noobs from insecure way to
use Tor.
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
--+
 RouteDNSTraffic 1
 (default: 1, enabled.)


 Analyzed my exit node's traffic, I noticed many users is sending DNS
 traffic over Tor, expecially targeting 8.8.8.8.

 Tor itself should reroute the tcp port 53 request to TorDNS system
 to prevent linking.

 https://nakedsecurity.sophos.com/2016/10/05/unmasking-tor-users-with-dns/
 https://lists.torproject.org/pipermail/tor-relays/2016-May/009255.html


 Before:
 User === Tor - Tor node ---> 8.8.8.8

 After:
 User === Tor[ --reroute-to-TorDNS-system ]<--->Tor node

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26041 [Core Tor/Tor]: Set Default version to 3 for new onion; V2 onion can be cracked easily

[Tor Bug Tracker & Wiki]

#26041: Set Default version to 3 for new onion; V2 onion can be cracked easily
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
--+
 Currently, the user should add 'Version 3' to torrc to generate V3 onion.
 I want you to use V3 by default.

 e.g.: HidServ /keys/onion/

 Scan /keys/onion/,
 a1. Is V3 hostname file exist? ===> use V3 only and ignore V2 onion
 a2. Is V2 hostname file exist? ===> use V2 only (and ignore V3)
 a3. Both file is not exist ===> Then, generate V3 onion.

 I've successfully generated "already-exist onion's private key".

 -BEGIN RSA PRIVATE KEY-
 MIICXgIBAAKBgQDPquVHKOacJ/fgY6G3vzbO4KgUYxRN5qlaysnKsApWBuGKWyoE
 irps1kmiPG1ewAxDYzrQtFzC14f94z8urN64SY8IaRgu76FHS5XeRDQ5AzIi54FH
 gHMEhbEReM5gRdxftgMto9Jhi+AoKO/VPhVlaIZyB7C223CiVyc299Qe7QIDAQAB
 AoGAalUSAybBNhINDRtW0fQZx0InLhExc1X5P2D4hE0xba0mTSay1BKItHPgzi5s
 vghN/y9PDVBc8vNTUb/LOUYQ35SBaEZKw0/TM+rnv/cHvnelPsrkyZmkr5HiQiUM
 p4cIwYO3VlF6NsGjhwZ3d0VJXSrsy6lUIYFjZFMB1OJ0H80CQQD/n76S6MHFKv6N
 9Imx2NCtQxYU/pbHMdUZOuG2MvpwmbkIYxO85AWxbp+9OMgr1s04kKtT9fhSM1iK
 R5/ZSqPDAkEAz/kX1viCd/l2qGD9bfJsd6+TNdsoaply7y7B/pgJZan4tQyi0Vha
 CexMW/M+j64hwWdTmP34ewcYbG+45cF3jwJBAPcs9W9C6BOKdmi3m+m/2FChfRnB
 7/QfSIrD9/thIe99hYEJpM1Sw/qFGKs028IgS4K1ySU/w+VgRu43QecwGFcCQQCd
 ziSIuYhGAMRIf0/NXWVwa4kIFINWX5kWZCRPSo3W1mIg/rWMo72uSd6m5qtR2o9C
 cWS9cfhZYcjmft+Ndn+BAkEArSW4oN9RibSh3JG0zstWTF6al6zPuhNxfB57MLaE
 HCS2yJf2vvWVTs9ZYBUEZUNX0OJ5doW5kl20gkXrsY4RKw==
 -END RSA PRIVATE KEY-

 I used 4 nvidia GPU and this took about 1 week.
 All V2 hosting admins should use V3.

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

Re: [tor-bugs] #12208 [Obfuscation/meek]: Make it possible to use an IP address as a front (no DNS request and no SNI)

[Tor Bug Tracker & Wiki]

#12208: Make it possible to use an IP address as a front (no DNS request and no
SNI)
--+--
 Reporter:  dcf   |  Owner:  dcf
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by dcf):

 Here are the four use cases I want to support. Cases !#1 and !#2 are
 already supported; this ticket is about adding !#3 and !#4. In the table,
 I separated `urlName` into "DNS name" and "connect to".
  * cdn.ex is at IP address 1.2.3.4
* serves a default certificate for CN=cdn.ex in absence of SNI
  * meek.ex is at IP address 5.5.5.5

 ||   ||||= DNS query =||= connect to =||= `hostName` =||=
 `sniName` =||= `verifyName` =||
 ||!#1||  direct|| meek.ex || 5.5.5.5  || meek.ex  ||
 meek.ex || meek.ex||
 ||!#2|| domain fronting|| cdn.ex  || 1.2.3.4  || meek.ex  ||
 cdn.ex  || cdn.ex ||
 ||!#3|| DNS, no SNI|| cdn.ex  || 1.2.3.4  || meek.ex  ||
 ^''none''^  || cdn.ex ||
 ||!#4||  no DNS, no SNI|| ^''none''^  || 1.2.3.4  || meek.ex  ||
 ^''none''^  || cdn.ex ||

 meek-client takes its configuration in two ways: on a per-connection basis
 via [https://gitweb.torproject.org/torspec.git/tree/pt-
 spec.txt?id=86480728d816474a0771a3b3aba5d223a32f0705#n628 PT SOCKS
 arguments], or globally via [https://gitweb.torproject.org/pluggable-
 transports/meek.git/tree/doc/meek-
 client.1.txt?id=7243a0df885dda442750836b397c2c5d1c7f3e8a#n61 command-line
 options]. SOCKS arguments take precedence over command-line options. Here
 is how cases !#1 and !#2 are represented:

 === !#1 direct
  SOCKS args::
   `url=https://meek.ex/`
  command line::
   `-url https://meek.ex/`
 === !#2 domain fronting
  SOCKS args::
   `url=https://meek.ex/ front=cdn.ex`
  command line::
   `-url https://meek.ex/ -front cdn.ex`

 We have to decide how to represent use cases !#3 and !#4.

 Observations:
  * `hostName` is the name of the final destination, always.
* It comes from the `url` argument and I like that design.
  * The only time `sniName`≠`verifyName` is when `sniName`=''none''.
* That is, there's no need to control `sniName` and `verifyName`
 completely independently, only for an option to blank the `sniName`.

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

Re: [tor-bugs] #26008 [Core Tor/Tor]: Make workqueue cancel code always get covered by tests.

[Tor Bug Tracker & Wiki]

#26008: Make workqueue cancel code always get covered by tests.
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, tor-tests-coverage, tor- |  Actual Points:
  tests-unit |
Parent ID:  #25908   | Points:
 Reviewer:  catalyst |Sponsor:
 |  Sponsor3-can
-+-
Changes (by catalyst):

 * status:  needs_review => merge_ready


Comment:

 Looks good to me!

 There's some trailing whitespace in the changes file.

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

Re: [tor-bugs] #24659 [Core Tor/Tor]: Wrap our sha2 interface in Rust which implements the appropriate traits

[Tor Bug Tracker & Wiki]

#24659: Wrap our sha2 interface in Rust which implements the appropriate traits
-+-
 Reporter:  isis |  Owner:  isis
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, tor-crypto, review-group-34,   |  Actual Points:
  034-triage-20180328|
Parent ID:   | Points:  1
 Reviewer:  nickm|Sponsor:
 |  Sponsor3-can
-+-
Changes (by isis):

 * status:  needs_revision => merge_ready


Comment:

 Replying to [comment:19 nickm]:
 > How about
 >
 > 5. Merge, but don't write any code that requires our hash functions
 until we have the linking issues solved?

 Your call! I'm not sure the linking issues (cf. #25386) are going to be
 resolved anytime soon though.

 Marking as merge_ready.

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

Re: [tor-bugs] #24658 [Core Tor/Tor]: Split/refactor crypto.h into smaller separate modules

[Tor Bug Tracker & Wiki]

#24658: Split/refactor crypto.h into smaller separate modules
-+-
 Reporter:  isis |  Owner:
 |  ffmancera
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-crypto, refactor, review-|  Actual Points:
  group-32, review-group-34, |
  033-triage-20180320, 033-included-20180320 |
Parent ID:   | Points:
 Reviewer:  nickm|Sponsor:
 |  Sponsor8-can
-+-
Changes (by isis):

 * status:  needs_revision => new


Comment:

 Setting as new; there's still the stream and dh stuff to do, iirc.

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

Re: [tor-bugs] #23823 [Obfuscation/BridgeDB]: Prepopulate ipv6 checkbox if ipv6 bridges are available for the transport.

[Tor Bug Tracker & Wiki]

#23823: Prepopulate ipv6 checkbox if ipv6 bridges are available for the 
transport.
--+-
 Reporter:  cypherpunks   |  Owner:  isis
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:  bridgedb-reportbug|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by isis):

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


Comment:

 Without JS, this would require an additional HTTP request to tell the
 server which kinds of bridges you're looking for.  Additionally, I'm not
 comfortable with any queries whatsoever to the database until the user has
 past the security check (currently a CAPTCHA).

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

Re: [tor-bugs] #23883 [Core Tor/Tor]: document how to get Travis or GitLab CI running on your fork of tor

[Tor Bug Tracker & Wiki]

#23883: document how to get Travis or GitLab CI running on your fork of tor
-+-
 Reporter:  catalyst |  Owner:  Hello71
 Type:  task | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  new-developers, tor-ci, tor-doc, |  Actual Points:
  034-roadmap-subtask, 034-triage-20180328,  |
  034-included-20180328  |
Parent ID:  #25550   | Points:
 Reviewer:  catalyst |Sponsor:
 |  Sponsor3
-+-
Changes (by catalyst):

 * status:  assigned => needs_revision


Comment:

 Thanks for the patch!

 Do we want to recommend travis-ci.com instead of travis-ci.org for people
 who are new to Travis?  It seems like Travis is [https://docs.travis-
 ci.com/user/open-source-on-travis-ci-com/ recommending travis-ci.com] for
 new users.

 It should probably specify that `#tor-ci` is on the OFTC IRC network.

 Maybe this needs a changes file?

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

Re: [tor-bugs] #23883 [Core Tor/Tor]: document how to get Travis or GitLab CI running on your fork of tor

[Tor Bug Tracker & Wiki]

#23883: document how to get Travis or GitLab CI running on your fork of tor
-+-
 Reporter:  catalyst |  Owner:  Hello71
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  new-developers, tor-ci, tor-doc, |  Actual Points:
  034-roadmap-subtask, 034-triage-20180328,  |
  034-included-20180328  |
Parent ID:  #25550   | Points:
 Reviewer:  catalyst |Sponsor:
 |  Sponsor3
-+-
Changes (by catalyst):

 * status:  needs_review => assigned
 * owner:  catalyst => Hello71


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

Re: [tor-bugs] #26040 [Core Tor/Tor]: Improve getrandom handling

[Tor Bug Tracker & Wiki]

#26040: Improve getrandom handling
--+
 Reporter:  Hello71   |  Owner:  Hello71
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:   => Tor: 0.3.4.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] #23883 [Core Tor/Tor]: document how to get Travis or GitLab CI running on your fork of tor

[Tor Bug Tracker & Wiki]

#23883: document how to get Travis or GitLab CI running on your fork of tor
-+-
 Reporter:  catalyst |  Owner:
 |  catalyst
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  new-developers, tor-ci, tor-doc, |  Actual Points:
  034-roadmap-subtask, 034-triage-20180328,  |
  034-included-20180328  |
Parent ID:  #25550   | Points:
 Reviewer:  catalyst |Sponsor:
 |  Sponsor3
-+-

Comment (by Hello71):

 https://cgit.alxu.ca/tor.git/diff/?id=bug23883=master

 added fixup commit

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

Re: [tor-bugs] #26040 [Core Tor/Tor]: Improve getrandom handling

[Tor Bug Tracker & Wiki]

#26040: Improve getrandom handling
--+--
 Reporter:  Hello71   |  Owner:  Hello71
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by Hello71):

 * status:  assigned => needs_review


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

[tor-bugs] #26040 [Core Tor/Tor]: Improve getrandom handling

[Tor Bug Tracker & Wiki]

#26040: Improve getrandom handling
--+--
 Reporter:  Hello71   |  Owner:  Hello71
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 https://cgit.alxu.ca/tor.git/commit/?h=better-getrandom

 Improve getrandom handling.

 Do not check for EINTR and EAGAIN because getrandom is documented to
 never return those if size < 256 and flags = 0.

 Also revise obsolete and inaccurate comment.

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

Re: [tor-bugs] #26038 [Core Tor/Tor]: Misc Rust/Cargo improvements (incl. use global cargo cache)

[Tor Bug Tracker & Wiki]

#26038: Misc Rust/Cargo improvements (incl. use global cargo cache)
--+
 Reporter:  Hello71   |  Owner:  Hello71
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by Hello71):

 * status:  needs_review => needs_revision


Comment:

 hm, warning for relative CARGO_HOME doesn't work right now, must fix...

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

Re: [tor-bugs] #25750 [Applications/Tor Launcher]: update Tor Launcher for ESR 60

[Tor Bug Tracker & Wiki]

#25750: update Tor Launcher for ESR 60
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:
|  needs_revision
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201805  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by mcs):

 * keywords:  ff60-esr, TorBrowserTeam201805R => ff60-esr,
 TorBrowserTeam201805
 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:9 sysrqb]:
 > I'll set this to needs-review for the tor-launcher patches I have:
 > Branch bug25750 on git.tp.o/user/sysrqb/tor-launcher.git

 Kathy and I reviewed and ran the revised Tor Launcher in a ESR 60-ish
 browser. It is working pretty well – good work! We have a few comments:

 1) I am surprised that XPCOM extensions still work as well as they do. We
 should set `extensions.legacy.enabled = true` and add `tor-
 launc...@torproject.org` to `extensions.legacy.exceptions` so the
 about:addons UI does not label Tor Launcher as LEGACY (and also add
 Torbutton's extension ID if we keep them both as regular add-ons).

 2) For 5e5fba0951b0837948bd9c074a3710afe137d0eb, please omit the first
 change.

 3) For 6105ea64e74cf65e09755d917234fe63b49b84ba, you could use a shorter
 commit message, e.g.,
  Mozilla dropped support for Ci.nsIProgrammingLanguage.JAVASCRIPT
  See https://bugzilla.mozilla.org/show_bug.cgi?id=1149830#c18

 4) For 068b9b5e8bb0408879b984c7c7ebd3726f25dd6c you could shorten the
 commit message and reference the entire bugzilla.mozilla.org URL. Maybe
 just use:
 Gecko now requries "0o"-prefixed octal literals
 See https://bugzilla.mozilla.org/show_bug.cgi?id=1263074

 5) For 374b64f3057ab4b703e3e79473cd4cfc8abc295e:
 * How can we guarantee that the call to `_loadPreferences()` occurs before
 any code which might rely on the preference values? Kathy and I don't have
 an answer, but maybe we should add an explicit initialization call inside
 `components/tl-process.js` (either in the `"profile-after-change"` case
 within the `observe()` implementation or at the end of `tl-process.js`.
 * Please use `let` instead of `var` in new code when possible (we are
 migrating in that direction).
 * Please use the Cc and Ci constants.
 * Please log a message when ignoring invalid pref names (near the top of
 the `pref()` function).
 * You can use `this.mPrefsSvc` inside `_getPrefDefaultBranch()`; if you do
 that, it might not be worthwhile to have a `_getPrefDefaultBranch()`
 function.

 6) For d1efcd33ca6389479337f70a603c73c8264888b8:
 * Mozilla now uses Services.intl.DateTimeFormat(). We should too. See:
 https://hg.mozilla.org/releases/mozilla-beta/rev/650bd331efd0
 * I don't think we should add a blank line after this one:
   let fracSecsStr = ...
 (that declaration is tied to the `for` loop that follows immediately
 after).

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

Re: [tor-bugs] #21346 [Core Tor/Tor]: Clients with NoIPv4Traffic should only choose IPv6-supporting Exits

[Tor Bug Tracker & Wiki]

#21346: Clients with NoIPv4Traffic should only choose IPv6-supporting Exits
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, 031-deferred-20170425, |  Actual Points:
  032-unreached  |
Parent ID:  #21311   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by neel):

 Thank you so much for your help.

 My patch is almost ready, but I have two more questions before I finish.

 Should I:
  * Modify the code to only choose IPv4 exits before the circuit if
 `!ap_conn->entry_cfg.ipv6_traffic` is set?
  * Modify the code to only choose IPv4 exits in the stream attachment if
 `!ap_conn->entry_cfg.ipv4_traffic` is set?

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

Re: [tor-bugs] #25750 [Applications/Tor Launcher]: update Tor Launcher for ESR 60

[Tor Bug Tracker & Wiki]

#25750: update Tor Launcher for ESR 60
-+-
 Reporter:  mcs  |  Owner:  brade
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Launcher|Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201805R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:8 sysrqb]:
 > Replying to [comment:6 sysrqb]:
 > > I'll try reverting the changeset - hopefully it applies cleanly.
 >
 > It doesn't. Instead, I added another commit on branch bug25750 that
 loads the prefs.js file at initialization and sets the prefs on the
 default prefs branch. We'll need the same in torbutton, too.

 I filed #26039 to track a related problem.

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

[tor-bugs] #26039 [Applications/Tor Browser]: /preferences/extension-overrides.js will not be loaded in ESR 60

[Tor Bug Tracker & Wiki]

#26039: /preferences/extension-overrides.js will not be loaded in 
ESR
60
--+--
 Reporter:  mcs   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  ff60-esr
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 The code that read preferences from /preferences/extension-
 overrides.js was removed as part of
 https://bugzilla.mozilla.org/show_bug.cgi?id=1413413

 We will have to do one of the following:
 1. Restore the code that was removed (but see ticket:25750#comment:8).
 2. Devise another way to handle the preferences that we include in
 extension-overrides.js

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

Re: [tor-bugs] #26038 [Core Tor/Tor]: Misc Rust/Cargo improvements (incl. use global cargo cache)

[Tor Bug Tracker & Wiki]

#26038: Misc Rust/Cargo improvements (incl. use global cargo cache)
--+
 Reporter:  Hello71   |  Owner:  Hello71
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:   => Tor: 0.3.4.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] #26038 [Core Tor/Tor]: Misc Rust/Cargo improvements (incl. use global cargo cache)

[Tor Bug Tracker & Wiki]

#26038: Misc Rust/Cargo improvements (incl. use global cargo cache)
--+--
 Reporter:  Hello71   |  Owner:  Hello71
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by Hello71):

 * status:  assigned => needs_review


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

[tor-bugs] #26038 [Core Tor/Tor]: Misc Rust/Cargo improvements (incl. use global cargo cache)

[Tor Bug Tracker & Wiki]

#26038: Misc Rust/Cargo improvements (incl. use global cargo cache)
--+--
 Reporter:  Hello71   |  Owner:  Hello71
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  rust
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 https://cgit.alxu.ca/tor.git/log/?h=misc-rust

 for discussion (since nobody cared on #tor-dev): should we use the global
 cargo cache? I think most C+Rust projects still use the global cache. I
 tried searching GitHub
 (https://github.com/search?q=%22CARGO_HOME%22+extension%3Aam=Code). I
 found that tor is the only project that does not. for users who do not
 care, using the global cache will save download time and bandwidth on
 repeat builds, and for those who do care, my patch prints a warning so
 they will know. (maybe it should be downgraded to NOTICE?)

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

Re: [tor-bugs] #26036 [Core Tor/Tor]: macOS regression in crypto_rand.c refactor

[Tor Bug Tracker & Wiki]

#26036: macOS regression in crypto_rand.c refactor
-+-
 Reporter:  catalyst |  Owner:
 |  catalyst
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-crypto, refactor, regression,|  Actual Points:
  macos, fast-fix|
Parent ID:  #24658   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 CI likes it; merging!

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

Re: [tor-bugs] #25981 [Core Tor/Tor]: Conflicting ports cause tor to crash

[Tor Bug Tracker & Wiki]

#25981: Conflicting ports cause tor to crash
-+
 Reporter:  atagar   |  Owner:  nickm
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Major| Resolution:
 Keywords:  034-must regression  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

 * priority:  Very High => High
 * status:  accepted => needs_review


Comment:

 Branch is `bug25981`; github PR at
 https://github.com/torproject/tor/pull/94

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

Re: [tor-bugs] #24631 [Applications/Tor Browser]: Update Tor Browser toolchains for ESR 60

[Tor Bug Tracker & Wiki]

#24631: Update Tor Browser toolchains for ESR 60
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm, ff60-esr |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arthuredelstein):

 * cc: arthuredelstein (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] #26037 [Core Tor/Tor]: DirAuths should check vote signatures before parsing

[Tor Bug Tracker & Wiki]

#26037: DirAuths should check vote signatures before parsing
--+
 Reporter:  isis  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-security, tor-crypto  |  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+
Description changed by isis:

Old description:

> teor pointed out that vote parsing occurs before checking the votes
> signature (both verifying the signature and ensuring that it comes from a
> known valid directory authority). dgoulet confirmed this is the case:
>
> > See dirvote.c, function dirvote_add_vote(). You will notice that the
> very first thing is parsing the whole thing with
> networkstatus_parse_vote_from_string(). Now, as far as I can tell, the
> voter signature check happens in that function. However, by the time we
> check it out, we've tokenized the votes and parsed _many_ parts of the
> vote already. (If you look for check_signature_token() in that function).
> >
> > And then once we are done parsing, we do have a valid signature for the
> vote which then make us check if we know the authority with
> trusteddirserver_get_by_v3_auth_digest().
>
> The issue of anyone being able to trigger a hypothetical vulnerability in
> one of the parsing functions aside, it's also just simply not efficient
> to do all the parsing work and then chuck the results at the end of
> `networkstatus_parse_vote_from_string()` if the signature wasn't from a
> valid sig from a known authority.
>
> This issue has been apparently been present since f4ce7f9c9b4 in
> tor-0.2.0.3-alpha.

New description:

 teor pointed out that vote parsing occurs before checking the votes
 signature (both verifying the signature and ensuring that it comes from a
 known valid directory authority). dgoulet confirmed this is the case:

 > See dirvote.c, function dirvote_add_vote(). You will notice that the
 very first thing is parsing the whole thing with
 networkstatus_parse_vote_from_string(). Now, as far as I can tell, the
 voter signature check happens in that function. However, by the time we
 check it out, we've tokenized the votes and parsed _many_ parts of the
 vote already. (If you look for check_signature_token() in that function).
 >
 > And then once we are done parsing, we do have a valid signature for the
 vote which then make us check if we know the authority with
 trusteddirserver_get_by_v3_auth_digest().

 The issue of anyone being able to trigger a hypothetical vulnerability in
 one of the parsing functions aside, it's also just simply not efficient to
 do all the parsing work and then chuck the results at the end of
 `networkstatus_parse_vote_from_string()` if the signature wasn't from a
 valid sig from a known authority.

 This issue has been apparently been present since f4ce7f9c9b4 in
 tor-0.2.0.3-alpha.

--

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

Re: [tor-bugs] #26037 [Core Tor/Tor]: DirAuths should check vote signatures before parsing

[Tor Bug Tracker & Wiki]

#26037: DirAuths should check vote signatures before parsing
--+
 Reporter:  isis  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-security, tor-crypto  |  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+
Changes (by isis):

 * cc: dgouler (removed)
 * cc: dgoulet (added)


Comment:

 Not sure who "dgouler" is but they just got notified about this bug.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26037 [Core Tor/Tor]: DirAuths should check vote signatures before parsing

[Tor Bug Tracker & Wiki]

#26037: DirAuths should check vote signatures before parsing
--+--
 Reporter:  isis  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-security, tor-crypto
Actual Points:|  Parent ID:
   Points:  2 |   Reviewer:
  Sponsor:|
--+--
 teor pointed out that vote parsing occurs before checking the votes
 signature (both verifying the signature and ensuring that it comes from a
 known valid directory authority). dgoulet confirmed this is the case:

 > See dirvote.c, function dirvote_add_vote(). You will notice that the
 very first thing is parsing the whole thing with
 networkstatus_parse_vote_from_string(). Now, as far as I can tell, the
 voter signature check happens in that function. However, by the time we
 check it out, we've tokenized the votes and parsed _many_ parts of the
 vote already. (If you look for check_signature_token() in that function).
 >
 > And then once we are done parsing, we do have a valid signature for the
 vote which then make us check if we know the authority with
 trusteddirserver_get_by_v3_auth_digest().

 The issue of anyone being able to trigger a hypothetical vulnerability in
 one of the parsing functions aside, it's also just simply not efficient to
 do all the parsing work and then chuck the results at the end of
 `networkstatus_parse_vote_from_string()` if the signature wasn't from a
 valid sig from a known authority.

 This issue has been apparently been present since f4ce7f9c9b4 in
 tor-0.2.0.3-alpha.

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

Re: [tor-bugs] #26036 [Core Tor/Tor]: macOS regression in crypto_rand.c refactor

[Tor Bug Tracker & Wiki]

#26036: macOS regression in crypto_rand.c refactor
-+-
 Reporter:  catalyst |  Owner:
 |  catalyst
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-crypto, refactor, regression,|  Actual Points:
  macos, fast-fix|
Parent ID:  #24658   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => merge_ready


Comment:

 LGTM; will merge once CI agrees with 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] #26036 [Core Tor/Tor]: macOS regression in crypto_rand.c refactor

[Tor Bug Tracker & Wiki]

#26036: macOS regression in crypto_rand.c refactor
-+-
 Reporter:  catalyst |  Owner:
 |  catalyst
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-crypto, refactor, regression,|  Actual Points:
  macos, fast-fix|
Parent ID:  #24658   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by catalyst):

 * status:  assigned => needs_review


Comment:

 Patch in https://github.com/torproject/tor/pull/93

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

Re: [tor-bugs] #25869 [Core Tor/Tor]: Proposal: Bandwidth Measurements Document Format

[Tor Bug Tracker & Wiki]

#25869: Proposal: Bandwidth Measurements Document Format
-+-
 Reporter:  juga |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bandwidth, bwauth, scanner, torflow  |  Actual Points:
Parent ID:  #3723| Points:
 Reviewer:  nickm|Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Done via personal email this morning -- please let me know if there's more
 to do!

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

Re: [tor-bugs] #26004 [Core Tor/Tor]: Allow Tor to accept node_id at the end of a bandwidth file line

[Tor Bug Tracker & Wiki]

#26004: Allow Tor to accept node_id at the end of a bandwidth file line
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  fast-fix, 034-backport-maybe, 033|  Actual Points:
  -backport-maybe, 032-backport-maybe, 031   |
  -backport-maybe, 029-backport-maybe, tor-  |
  dirauth|
Parent ID:  #25925   | Points:
 Reviewer:  nickm|Sponsor:
-+-

Comment (by nickm):

 Two changes needed here:

   * If the input to this function is the empty string, `strlen(line) - 1`
 will underflow.
   * This branch needs a changes file.

 I've made both of these changes in my own branch (with the same name as
 yours) -- please let me know if you agree with them, and I'll merge.

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

[tor-bugs] #26036 [Core Tor/Tor]: macOS regression in crypto_rand.c refactor

[Tor Bug Tracker & Wiki]

#26036: macOS regression in crypto_rand.c refactor
-+-
 Reporter:   |  Owner:  catalyst
  catalyst   |
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  tor-crypto, refactor, regression,
 Severity:  Normal   |  macos, fast-fix
Actual Points:   |  Parent ID:  #24658
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 The refactoring that created crypto_rand.c is missing includes of
 sys/syscall.h and sys/random.h.  sys/random.h is needed for `getentropy()`
 on macOS 10.12 Sierra.  Omitting sys/syscall.h might also cause us to fail
 to detect a `getrandom()` syscall on Linux when that's supported.

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

Re: [tor-bugs] #25318 [Applications/Quality Assurance and Testing]: Add Tor Browser nightly builds email notification

[Tor Bug Tracker & Wiki]

#25318: Add Tor Browser nightly builds email notification
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing|
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201805R, boklm201805   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * status:  needs_information => needs_review


Comment:

 Replying to [comment:7 gk]:
 > There are already commits with the bug number of this ticket that landed
 in `tor-browser-bundle-testsuite` it seems. What's their relationship to
 the review request here?

 Commits `12f9759ee532527c8fb6e5db640ee631cfb6db2c` and
 `59d2ed3f22f618b70b2814b5cf6bb47063826390` in the `tor-browser-bundle-
 testsuite` repo have been adding support to the testsuite for sending
 build reports emails.

 I rebased the `tor-browser-build.git` commit on the new version of #25817
 in branch `bug_25318_v2`:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_25318_v2=4580c03c937e8ccab86446d60a0d4ee29b7c07c8

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

Re: [tor-bugs] #25733 [Core Tor/Tor]: Bug: Assertion bin_counts > 0 failed in circuit_build_times_get_xm at ../src/or/circuitstats.c:772.

[Tor Bug Tracker & Wiki]

#25733: Bug: Assertion bin_counts > 0 failed in circuit_build_times_get_xm at
../src/or/circuitstats.c:772.
-+-
 Reporter:  cstest   |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.10
 Severity:  Normal   | Resolution:
 Keywords:  crash 029-backport 031-backport  |  Actual Points:
  032-backport   |
Parent ID:   | Points:
 Reviewer:  nickm|Sponsor:
-+-
Changes (by nickm):

 * milestone:  Tor: 0.3.3.x-final => Tor: 0.3.2.x-final


Comment:

 Merged to 0.3.3 and forward; marking for backport.

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

Re: [tor-bugs] #25817 [Applications/Tor Browser]: Add ansible scripts for setup of nigthly build server

[Tor Bug Tracker & Wiki]

#25817: Add ansible scripts for setup of nigthly build server
+--
 Reporter:  boklm   |  Owner:  tbb-team
 Type:  task| Status:
|  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  boklm201805, TorBrowserTeam201805R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by boklm):

 * keywords:  boklm201805, TorBrowserTeam201805 => boklm201805,
 TorBrowserTeam201805R
 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:4 gk]:
 > Okay, looks mostly good. Some typos and one question.
 >
 > s/setup/set up/ (when used as a verb)
 > "for an example of how they it be used" <- not sure which version you
 wanted to have :)

 I fixed those typos in branch `bug_25817_v8`:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_25817_v8=a2f565643d4c34a49712c37e3931dd6f80da7ba1

 >
 > Now, I am a bit confused about the dependency to the test suite repo.
 Could you explain a bit more about how that is working. For instance, one
 thing I saw was that we already have a `tor-browser-
 nightly.rbm.local.conf` there but that one now gets overwritten with a
 newly added one we keep in the `tbb-nightly-build` dir in `tor-browser-
 build` but used afterwards which is a bit confusing.

 We use the testsuite repo to generate build report pages on
 http://f4amtbsowhix7rrf.onion/reports/index-tor-browser_build.html.

 Before the setup was done using ansible, we were storing some
 configuration files for the nightly builds in the test suite repo, but we
 are not using them anymore. To avoid confusion, I removed them from the
 test suite repo in commit `348ad855711382089c4fbf1badfec58e31a6c148`. I
 also updated the README in tor-browser-build to remove references to those
 files, and instead recommend using the ansible roles for the setup.

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

Re: [tor-bugs] #25965 [Core Tor/Tor]: Document default value of Nickname parameter [patch]

[Tor Bug Tracker & Wiki]

#25965: Document default value of Nickname parameter [patch]
--+
 Reporter:  saper |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Very Low  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:  doc   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  merge_ready => closed
 * resolution:   => implemented
 * milestone:  Tor: 0.3.3.x-final => Tor: 0.3.4.x-final


Comment:

 Merged into master!  (Not backporting.)

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

Re: [tor-bugs] #17949 [Core Tor/Tor]: Make loopback address search more accurate

[Tor Bug Tracker & Wiki]

#17949: Make loopback address search more accurate
-+-
 Reporter:  teor |  Owner:  rl1987
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy tor-client tor-relay loopback   |  Actual Points:
  weird-configuration|
Parent ID:  #17991   | Points:
 Reviewer:  ahf, teor, isis  |Sponsor:
-+-
Changes (by isis):

 * reviewer:  ahf, teor => ahf, teor, isis


Comment:

 I'm taking over secondary round of review for teor since he's away this
 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] #26007 [Core Tor/Tor]: Stop logging stack contents when reading a zero-length bandwidth file

[Tor Bug Tracker & Wiki]

#26007: Stop logging stack contents when reading a zero-length bandwidth file
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  033-must-maybe security-low  |  Actual Points:
  032-backport 031-backport 029-backport fast-   |
  fix|
Parent ID:  #25925   | Points:
 Reviewer:  asn  |Sponsor:
-+-

Comment (by nickm):

 WRT the question of how to avoid adding an extra file: you can use the
 "get_fname()" function to get a temporary filename from within a unit
 test, and then use write_str_to_file() to write a string into that file.
 The file will be automatically cleaned up when the unit tests exit.

 For a very simple example, see test_util_listdir() in test_util.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] #26014 [Core Tor/Tor]: Fix two cases of nondeterminism in voting_schedule.c coverage

[Tor Bug Tracker & Wiki]

#26014: Fix two cases of nondeterminism in voting_schedule.c coverage
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-ci, tor-tests-coverage, tor- |  Actual Points:
  tests-unit |
Parent ID:  #25908   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor3-can
-+-
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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #26004

[Tor Bug Tracker & Wiki]

Batch modification to #26004 by dgoulet:
reviewer to nickm

--
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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #25994, #26016

[Tor Bug Tracker & Wiki]

Batch modification to #25994, #26016 by dgoulet:
reviewer to mikeperry

--
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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #25756

[Tor Bug Tracker & Wiki]

Batch modification to #25756 by dgoulet:
reviewer to isis

--
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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #25647, #26009

[Tor Bug Tracker & Wiki]

Batch modification to #25647, #26009 by dgoulet:
reviewer to dgoulet

--
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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #23883, #25993, #26008

[Tor Bug Tracker & Wiki]

Batch modification to #23883, #25993, #26008 by dgoulet:
reviewer to catalyst

--
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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #26005, #26006, #26007

[Tor Bug Tracker & Wiki]

Batch modification to #26005, #26006, #26007 by dgoulet:
reviewer to asn

--
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] #25870 [Core Tor/Tor]: Fix vanguard restrictions

[Tor Bug Tracker & Wiki]

#25870: Fix vanguard restrictions
--+
 Reporter:  mikeperry |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #25546| Points:
 Reviewer:  asn   |Sponsor:
--+

Comment (by nickm):

 (Travis likes it fine; I'll merge it once there's a relevant spec branch
 to go with 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] #25552 [Core Tor/Tor]: prop224: Onion service rev counters are useless and actually harmful for scalability

[Tor Bug Tracker & Wiki]

#25552: prop224: Onion service rev counters are useless and actually harmful for
scalability
---+---
 Reporter:  asn|  Owner:  dgoulet
 Type:  defect | Status:
   |  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.4.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.1.9
 Severity:  Normal | Resolution:
 Keywords:  tor-hs prop224 034-roadmap-master  |  Actual Points:
Parent ID: | Points:  4
 Reviewer:  asn|Sponsor:
---+---

Comment (by nickm):

 I've reviewed the PR.  The biggest issue is related to the use of "\n"
 signature_str, which I believe should be "\n" signature_str " " instead.

 Other issues not on the PR:

 1. How hard is it to DoS this into an OOM condition?  Do we need to tie it
 into the OOM system?  And by doing so, do we subject ourselves to replay
 attacks once again?

 2. On point 1: perhaps the replay cache should be thought of, not as a
 complete replacement for revision counters, but as an  alternative to them
 when they cannot be used?  That is, we could enforce the rule that
 revision counters are ''non-decreasing'', but allow revision counters to
 remain equal, and use the replay cache to handle only the "equal counter"
 case.

 That way if we need to rip out the cache because of OOM issues in the
 future, or if we solve the problem of coordinating revision counters
 between distributed HS providers, we aren't stuck with the cache forever.

 3. As above, the unit tests need fixing.

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

Re: [tor-bugs] #25552 [Core Tor/Tor]: prop224: Onion service rev counters are useless and actually harmful for scalability

[Tor Bug Tracker & Wiki]

#25552: prop224: Onion service rev counters are useless and actually harmful for
scalability
---+---
 Reporter:  asn|  Owner:  dgoulet
 Type:  defect | Status:
   |  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.4.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.1.9
 Severity:  Normal | Resolution:
 Keywords:  tor-hs prop224 034-roadmap-master  |  Actual Points:
Parent ID: | Points:  4
 Reviewer:  asn|Sponsor:
---+---
Changes (by nickm):

 * status:  merge_ready => needs_revision


Comment:

 Travis says the unit tests are failing here.  I confirm:

 {{{
 hs_cache/directory:
   FAIL src/test/test_hs_cache.c:112: expected log to contain "Possible
 descriptor replay detected"  Captured logs:

   [directory FAILED]
 1/1086 TESTS FAILED. (31 skipped)
 }}}

 I'll also start reviewing the 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] #26030 [Metrics/Website]: Delete "Tor Messenger downloads and updates" section

[Tor Bug Tracker & Wiki]

#26030: Delete "Tor Messenger downloads and updates" section
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  defect   | Status:  reopened
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Replying to [comment:4 irl]:
 > Oooh. A thought: We put this static analysis alongside the reports from
 the Analysis tickets on the website that we discussed at the Aberdeen
 meeting.

 Sure, sounds good to me. And maybe it will take a sufficient number of
 months for us to set up that page that we can remove the (dynamic) graph
 at the same time as adding a static version of it to the new page.

 FWIW, this specific graph requires very little maintenance effort as
 compared to other graphs. It would also be perfectly fine to keep it for
 longer than 12 months.

 So, what are the next steps here?
  - Open a new ticket for that updated graph text mentioning the
 ​sunsetting of Tor Messenger.
  - Revisit this ticket when there's a page for Analysis tickets.

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

Re: [tor-bugs] #25705 [Core Tor/Tor]: Refactor circuit_build_failed to separate build vs path failures

[Tor Bug Tracker & Wiki]

#25705: Refactor circuit_build_failed to separate build vs path failures
--+
 Reporter:  mikeperry |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #25546| Points:
 Reviewer:  asn   |Sponsor:  SponsorV-can
--+
Changes (by nickm):

 * milestone:  Tor: 0.3.4.x-final => Tor: 0.3.3.x-final


Comment:

 Merged to 0.3.4; marking for backport to 0.3.3 assuming nothing breaks.

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

Re: [tor-bugs] #25870 [Core Tor/Tor]: Fix vanguard restrictions

[Tor Bug Tracker & Wiki]

#25870: Fix vanguard restrictions
--+
 Reporter:  mikeperry |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #25546| Points:
 Reviewer:  asn   |Sponsor:
--+

Comment (by nickm):

 Looks plausible to me; running it through travis now.

 Is there a spec branch 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] #26014 [Core Tor/Tor]: Fix two cases of nondeterminism in voting_schedule.c coverage

[Tor Bug Tracker & Wiki]

#26014: Fix two cases of nondeterminism in voting_schedule.c coverage
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, tor-tests-coverage, tor- |  Actual Points:
  tests-unit |
Parent ID:  #25908   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor3-can
-+-
Changes (by dgoulet):

 * status:  needs_review => merge_ready
 * reviewer:   => dgoulet


Comment:

 lgtm;

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

[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:  metrics-team
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  Sponsor13   |
+--
 While documenting how to reproduce our various statistics, I noticed that
 we're using different methods/formulas for computing sample quantiles,
 that is, the median, quartiles, percentiles, and so on. Ideally, we would
 settle on one method and use that everywhere. The benefit is easier
 documentation and reproducibility.

 Here is a (probably still incomplete) list of graphs for which we
 calculate quantiles (with the tool written in parentheses):
  - [https://metrics.torproject.org/userstats-relay-country.html Relay
 users]: Median and inter-quartile range of ratios in censorship detector
 (Python, possibly Java soon)
  - [https://metrics.torproject.org/advbwdist-perc.html Advertised
 bandwidth distribution]: Percentiles, including the unusual 0-th
 percentile (Java) and median (R)
  - [https://metrics.torproject.org/advbwdist-relay.html Advertised
 bandwidth of n-th fastest relays]: Median (R)
  - [https://metrics.torproject.org/connbidirect.html Fraction of
 connections used uni-/bidirectionally]: Quartiles (Java)
  - [https://metrics.torproject.org/torperf.html Time to download files
 over Tor]: Quartiles (PostgreSQL)
  - [https://metrics.torproject.org/hidserv-dir-onions-seen.html Unique
 .onion addresses (version 2 only)]: Quartiles for weighted inter-quartile
 mean (Java)
  - [https://metrics.torproject.org/hidserv-rend-relayed-cells.html Onion-
 service traffic (versions 2 and 3)]: Quartiles for weighted inter-quartile
 mean (Java)

 There exist surprisingly many ways for computing quantiles. I found the
 following links to be quite helpful:

  -
 https://en.wikipedia.org/wiki/Quantile#Estimating_quantiles_from_a_sample
  -
 https://www.rdocumentation.org/packages/stats/versions/3.5.0/topics/quantile

 Looking at the lists, we should probably pick two types: one discontinuous
 (`R-1` to `R-3`) and one continuous type (`R-4` to `R-9`). And ideally,
 we'd pick types that are either the defaults in the tools we're using or
 that we can easily select to use in those tools.

 Going through our tools:
  - PostgreSQL has two functions, `PERCENTILE_CONT` and `PERCENTILE_DISC`,
 of which we already use the first. I did some experiments with a quite
 large sample set and found that `PERCENTILE_CONT` produces the exact same
 output as `R-7` and `PERCENTILE_DISC` must be either `R-1` or `R-2`. A
 math person might be able to say whether it's `R-1` or `R-2` by looking at
 the PostgreSQL source code. And maybe that person would be able to confirm
 the `R-7` part, too. It seems like we don't have the choice of using other
 types than these in PosrtgreSQL, though, or at least not easily.
  - R has support for all nine types. After all, they're named after this
 language. It seems like `R-7` is the default type.
  - Java with Apache Commons Math has support for all nine types, `R-1` to
 `R-9`. And in theory, the two types we need shouldn't be terribly hard to
 re-implement, in case we want to avoid putting in this not-exactly-tiny
 library as dependency.
  - Python with SciPy/Numpy probably has support for some types, but I
 guess we're not planning to keep our Python code anyway, so this doesn't
 really matter.

 Whee, long ticket. Thoughts?

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

Re: [tor-bugs] #17949 [Core Tor/Tor]: Make loopback address search more accurate

[Tor Bug Tracker & Wiki]

#17949: Make loopback address search more accurate
-+-
 Reporter:  teor |  Owner:  rl1987
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy tor-client tor-relay loopback   |  Actual Points:
  weird-configuration|
Parent ID:  #17991   | Points:
 Reviewer:  ahf, teor|Sponsor:
-+-
Changes (by rl1987):

 * status:  needs_revision => needs_review


Comment:

 New pull request: https://github.com/torproject/tor/pull/92

 In 0b121a10d6c91cd5cc4bb0e15918fe19dff55815 I made a workaround to get
 entire test suite working on Travis.

 It passes successfully now: https://travis-
 ci.org/torproject/tor/builds/375907313

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26034 [Core Tor/Tor]: LibreSSL 2.7.x may support OpenSSL 1.1 APIs?

[Tor Bug Tracker & Wiki]

#26034: LibreSSL 2.7.x may support OpenSSL 1.1 APIs?
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Toralf points me towards this Python patch:

 https://github.com/gentoo/gentoo/blob/master/dev-
 lang/python/files/python-3.5.5-libressl-compatibility.patch

 It implies that for Python's purposes at least, LibreSSL 2.7.x supports
 the newer openssl APIs.  We should test that out, and if so, support 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] #25852 [Core Tor/Tor]: GETINFO exit-policy for tor client should return 551

[Tor Bug Tracker & Wiki]

#25852: GETINFO exit-policy for tor client should return 551
+--
 Reporter:  dmr |  Owner:  (none)
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-spec, tor-client, fast-fix  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  dgoulet |Sponsor:
+--

Comment (by rl1987):

 https://github.com/torproject/tor/pull/91
 https://github.com/torproject/torspec/pull/8

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

Re: [tor-bugs] #26032 [Metrics/ExoneraTor]: suggestion URL is broken (duplicate [[]])

[Tor Bug Tracker & Wiki]

#26032: suggestion URL is broken (duplicate [[]])
+--
 Reporter:  cypherpunks |  Owner:  iwakeh
 Type:  defect  | Status:  accepted
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by iwakeh):

 * owner:  metrics-team => iwakeh
 * status:  new => accepted


Comment:

 Taking a look at 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] #17873 [Core Tor/Tor]: replacing 0.0.0.0 listeners at runtime fails

[Tor Bug Tracker & Wiki]

#17873: replacing 0.0.0.0 listeners at runtime fails
+--
 Reporter:  cypherpunks |  Owner:  (none)
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-client port bind switching  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  ahf |Sponsor:
+--
Changes (by rl1987):

 * status:  needs_revision => needs_review


Comment:

 I made code cleanups according to your feedback. Please check if
 everything is good now.

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

 I did test it on macOS - we don't need the replacement dance here.
 According to analysis above, we don't need it on BSD systems either.

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

Re: [tor-bugs] #25804 [Obfuscation/Snowflake]: Domain fronting to App Engine stopped working

[Tor Bug Tracker & Wiki]

#25804: Domain fronting to App Engine stopped working
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords:  moat   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by cypherpunks):

 > Don't know how much data Moat and Snowflake need, but if it's only a
 tiny amount an alternative for the AMP proxy could be Google's favicon
 retrieval service, which allows to retrieve one 16×16 PNG at the time.
 Could perhaps be combined with wildcard DNS so you get .some-endpoint.torproject.org/favicon.ico, .some-
 endpoint.torproject.org/favicon.ifo

 That's neat for sure.
 But Google support DNS-over-HTTPS (Beta version).

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

Re: [tor-bugs] #25869 [Core Tor/Tor]: Proposal: Bandwidth Measurements Document Format

[Tor Bug Tracker & Wiki]

#25869: Proposal: Bandwidth Measurements Document Format
-+-
 Reporter:  juga |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bandwidth, bwauth, scanner, torflow  |  Actual Points:
Parent ID:  #3723| Points:
 Reviewer:  nickm|Sponsor:
-+-
Changes (by juga):

 * 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] #25869 [Core Tor/Tor]: Proposal: Bandwidth Measurements Document Format

[Tor Bug Tracker & Wiki]

#25869: Proposal: Bandwidth Measurements Document Format
-+-
 Reporter:  juga |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bandwidth, bwauth, scanner, torflow  |  Actual Points:
Parent ID:  #3723| Points:
 Reviewer:  nickm|Sponsor:
-+-

Comment (by juga):

 nickm, teor, would you mind to review/answer all the questions i left in
 `[NOTE]` (same branch) before i send again to tor-dev@?.

 As suggested by teor in tor-dev@ and
 https://trac.torproject.org/projects/tor/ticket/25960#comment:9, i would
 create other file with for version 2.0.0 (replacing key_value format with
 SP). Same of the questions would still apply.

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

Re: [tor-bugs] #26030 [Metrics/Website]: Delete "Tor Messenger downloads and updates" section

[Tor Bug Tracker & Wiki]

#26030: Delete "Tor Messenger downloads and updates" section
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  defect   | Status:  reopened
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by irl):

 Oooh. A thought: We put this static analysis alongside the reports from
 the Analysis tickets on the website that we discussed at the Aberdeen
 meeting.

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

Re: [tor-bugs] #26030 [Metrics/Website]: Delete "Tor Messenger downloads and updates" section

[Tor Bug Tracker & Wiki]

#26030: Delete "Tor Messenger downloads and updates" section
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  defect   | Status:  reopened
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by irl):

 I feel that even 12 months would be too soon, unless we had a plan to
 replace it with some sort of static view of the history of Tor Messenger
 during its life.

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

Re: [tor-bugs] #20892 [Applications/Tor Browser]: tools/update-responses/download_missing_versions fails to download OSX mar files

[Tor Bug Tracker & Wiki]

#20892: tools/update-responses/download_missing_versions fails to download OSX 
mar
files
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201802R, tbb-  |  Actual Points:
  backported |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  TorBrowserTeam201802R, tbb-backport => TorBrowserTeam201802R,
 tbb-backported


Comment:

 Backported with commit da514cdf49e89fb5efbb969cfd74dd561d50f54e.

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

Re: [tor-bugs] #26030 [Metrics/Website]: Delete "Tor Messenger downloads and updates" section

[Tor Bug Tracker & Wiki]

#26030: Delete "Tor Messenger downloads and updates" section
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  defect   | Status:  reopened
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  closed => reopened
 * resolution:  not a bug =>


Comment:

 I agree with irl that we shouldn't remove the graph right away.

 But we're not going to keep the graph forever. Maybe we can brainstorm
 here what would be a good time to remove it. 3 months from now? 6 months?
 12?

 And does anybody want to open a new ticket for that updated graph text
 mentioning the [https://blog.torproject.org/sunsetting-tor-messenger
 sunsetting of Tor Messenger]?

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

Re: [tor-bugs] #26030 [Metrics/Website]: Delete "Tor Messenger downloads and updates" section

[Tor Bug Tracker & Wiki]

#26030: Delete "Tor Messenger downloads and updates" section
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:  not a bug
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by irl):

 * status:  assigned => closed
 * resolution:   => not a bug


Comment:

 Historical information may still be of interest, and you'll notice also
 that we are still receiving update pings.

 We may want to update the text under the graph to explain that it's no
 longer actively developed, but that would be a different ticket.

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

Re: [tor-bugs] #9711 [Applications/Tor Browser]: Test out crosstools-ng for rbm/tor-browser-build OSX builds (instead of toolchain4 binaries)

[Tor Bug Tracker & Wiki]

#9711: Test out crosstools-ng for rbm/tor-browser-build OSX builds (instead of
toolchain4 binaries)
+--
 Reporter:  mikeperry   |  Owner:  tbb-team
 Type:  task| Status:
|  needs_information
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, GeorgKoppen201506  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by gk):

 Mozilla switched away from `crosstools-ng` to `cctools-port`
 (https://github.com/tpoechtrager/cctools-port) after ESR52. Seems
 worthwhile to follow that step just to keep the toolchains in sync as good
 as possible. (See:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1331957#c11 for the
 reasoning).

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

Re: [tor-bugs] #25383 [Metrics/Website]: Deprecate stats.html and stats/*.csv files

[Tor Bug Tracker & Wiki]

#25383: Deprecate stats.html and stats/*.csv files
-+--
 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:   |Sponsor:
-+--

Comment (by irl):

 Are we strongly against the idea of providing two CSV files? I'd like to
 see the current CSV that only contains the data used to produce the plot,
 and then additionally the full CSV pre-filtering that would contain all
 the data.

 This would work for the use case where you want to do your own processing
 on the data and would also work for the use case where someone wanted to
 produce plots using the same data that we have already filtered and
 processed.

 For the full CSV file, a header would probably be useful. It may also be
 useful to have an HTML page that contains a list of all the available CSV
 files but the specifications for those files could be documented in the
 headers of the CSVs. We wouldn't need to list the individual pre-filtered
 CSV files on that page.

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

Re: [tor-bugs] #26019 [Applications/Tor Browser]: Allow javascript.options.ion, javascript.options.baselinejit, and javascript.options.native_regexp at the highest security level

[Tor Bug Tracker & Wiki]

#26019: Allow javascript.options.ion, javascript.options.baselinejit, and
javascript.options.native_regexp at the highest security level
--+---
 Reporter:  cypherpunks   |  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:

 Differentiating between content and privileged browser with respect to JIT
 preferences is not possible anymore (see:
 https://bugzilla.mozilla.org/show_bug.cgi?id=939562 where the content
 related prefs got removed).

 I think we won't allow JIT as you suggested it in this ticket either
 because the risk is that users by simply allowing scripts on certain
 domains are having the JIT related things enabled, too, which is not
 intended and surprising behavior. Additionally, this would leave the
 "Safer" setting in a weird situation as JIT is disabled there, too, while
 JavaScript is being allowed.

 That said: In which way is the web browser slowed down? (Note: note every
 JS-code can be JITed) Could you give some performance numbers from tests
 you make?

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

Re: [tor-bugs] #26002 [Metrics/Statistics]: Simplify graph with number of bytes spent on answering directory requests

[Tor Bug Tracker & Wiki]

#26002: Simplify graph with number of bytes spent on answering directory 
requests
+--
 Reporter:  karsten |  Owner:  karsten
 Type:  enhancement | Status:  accepted
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by irl):

 Replying to [comment:4 karsten]:
 > In theory, I agree. However, this extrapolation code is so legacy that
 we wouldn't look at it again even if we decide we want to extrapolate
 numbers again. To give you an idea, this code is based on a previous
 approach for estimating user numbers, and this graph is the only reason
 why we still have this code in the codebase. I'd rather want to start
 cleanly when writing the next extrapolation code than looking again at
 this very old code. So, good suggestion in theory, but in this case I
 think it simply doesn't make as much sense.

 Ok, your reasoning as to why this does not make sense makes sense.

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

Re: [tor-bugs] #26002 [Metrics/Statistics]: Simplify graph with number of bytes spent on answering directory requests

[Tor Bug Tracker & Wiki]

#26002: Simplify graph with number of bytes spent on answering directory 
requests
+--
 Reporter:  karsten |  Owner:  karsten
 Type:  enhancement | Status:  accepted
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by karsten):

 * owner:  metrics-team => karsten
 * status:  needs_review => accepted


Comment:

 Replying to [comment:3 iwakeh]:
 > Looking at the graph in comment:1 the old and new calculations only
 differ by a constant factor during April 2018.  Would be interesting to
 see a longer history for this comparison.

 Agreed. I'll fire up the engine now to produce a longer history. That will
 take a while, though.

 > And true, the extrapolation of the total is really not that useful and
 complicates reproducibility unnecessarily.

 Agreed!

 > As an improvement (that ought to be easy to implement on first thought)
 maybe add the counts reporting vs. not-reporting (in some useful way)?

 I'll add some counts for consideration here, though I'm unsure if we want
 to display those to the user. It would be a graph similar to the
 [https://metrics.torproject.org/hidserv-frac-reporting.html Fraction of
 relays reporting onion-service statistics] graph, and I'm yet unclear
 whether that's useful or just confusing for 90% of our users.

 Grabbing the ticket and setting status to accepted.

 Thanks for the feedback so far!

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

Re: [tor-bugs] #26002 [Metrics/Statistics]: Simplify graph with number of bytes spent on answering directory requests

[Tor Bug Tracker & Wiki]

#26002: Simplify graph with number of bytes spent on answering directory 
requests
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by karsten):

 Replying to [comment:2 irl]:
 > LGTM.

 GTFL. (Great, thanks for looking.)

 > Let's keep a comment in the code to point out that the git history will
 have a version that can extrapolate in case we need it in the future but
 forgot that it exists (but no need to document the extrapolation steps for
 reproducible metrics).

 In theory, I agree. However, this extrapolation code is so legacy that we
 wouldn't look at it again even if we decide we want to extrapolate numbers
 again. To give you an idea, this code is based on a previous approach for
 estimating user numbers, and this graph is the only reason why we still
 have this code in the codebase. I'd rather want to start cleanly when
 writing the next extrapolation code than looking again at this very old
 code. So, good suggestion in theory, but in this case I think it simply
 doesn't make as much sense.

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

Re: [tor-bugs] #26033 [Applications/Tor Browser]: Unable to launch Tor

[Tor Bug Tracker & Wiki]

#26033: Unable to launch Tor
--+---
 Reporter:  dutiel|  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:

 Which antivirus software are you using? Could you uninstall it for testing
 purposes, figuring out whether that's related? (Note: disabling is often
 not enough). Which Windows version is that?

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

Re: [tor-bugs] #26027 [Applications]: Installation issues

[Tor Bug Tracker & Wiki]

#26027: Installation issues
--+-
 Reporter:  lili  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications  |Version:
 Severity:  Major | Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by gk):

 * keywords:  nyx installation =>
 * status:  new => closed
 * version:  Tor: unspecified =>
 * resolution:   => invalid
 * milestone:  Tor: unspecified =>


Comment:

 Replying to [comment:1 atagar]:
 > Hi lili. Alex maintains Nyx for ArchLinux (I don't know much about it),
 but I took a quick peek around. The AUR signature [1] is the same as the
 one I uploaded to PyPI. So it should be verifiable with my key [3].
 Trouble is that 888404C187F30690 looks to be the wrong key. On first
 glance not sure who's it is.

 Seems it is your signing subkey bound to 0x0445B7AB9ABBEEC6, no?

 I guess this issue could easily be fixed by importing that key first. At
 any rate, this is not an applications bug.

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

Re: [tor-bugs] #25750 [Applications/Tor Launcher]: update Tor Launcher for ESR 60

[Tor Bug Tracker & Wiki]

#25750: update Tor Launcher for ESR 60
-+-
 Reporter:  mcs  |  Owner:  brade
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Launcher|Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201805R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * cc: brade (removed)
 * cc: mcs (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] #25750 [Applications/Tor Launcher]: update Tor Launcher for ESR 60

[Tor Bug Tracker & Wiki]

#25750: update Tor Launcher for ESR 60
-+-
 Reporter:  mcs  |  Owner:  brade
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Launcher|Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201805R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  ff60-esr, TorBrowserTeam201804 => ff60-esr,
 TorBrowserTeam201805R


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