Re: [tor-bugs] #25483 [Obfuscation/Snowflake]: Windows reproducible build of snowflake

[Tor Bug Tracker & Wiki]

#25483: Windows reproducible build of snowflake
---+--
 Reporter:  arlolra|  Owner:  sukhbir
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201805   |  Actual Points:
Parent ID:  #19001 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cmm323):

 The problem in step 3 is that the name mangling schemes used by the two
 compilers are different and thus the linker cannot find the appropriate
 function in the object file generated by the other compiler. However, this
 is a common problem and a popular solution is to export method calls as C
 functions. Since C doesn't have namespaces there is no name mangling
 issue. These functions can be exported as a DLL wrapper (see [1] and [2]
 for more information). Go-Webrtc wrapper by asicerik[3] wraps WebRTC
 functions called by Snowflake, in C functions and export them as a runtime
 DLL. I have tested the functionality of this wrapper on Windows. Cross-
 compiling the wrapper on a Linux machine, however, seems to be harder. The
 wrapper uses Windows header and some other WebRTC headers. I believe that
 we can use the Ninja[4] and GYP build systems that are used to build the
 WebRTC library to cross-compile the wrapper as well. I think the solution
 is to add a target to Ninja build system to build the wrapper with WebRTC
 library as a dependency. Unfortunately, I don't know enough about Ninja
 build system to do that and won't have the time to research it anytime
 soon.

 [1]- http://www.mingw.org/wiki/Visual_Basic_DLL
 [2]- https://www.transmissionzero.co.uk/computing/building-dlls-with-
 mingw/
 [3]- https://github.com/asicerik/go-webrtc
 [4]- https://ninja-build.org/manual.html

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

Re: [tor-bugs] #25483 [Obfuscation/Snowflake]: Windows reproducible build of snowflake

[Tor Bug Tracker & Wiki]

#25483: Windows reproducible build of snowflake
---+--
 Reporter:  arlolra|  Owner:  sukhbir
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201805   |  Actual Points:
Parent ID:  #19001 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cmm323):

 Cross compiling WebRTC library for Windows on a Linux machine and linking
 Snowflake involves multiple steps:

 1-Cross compiling WebRTC lib: This step is currently done using Clang,
 which is Microsoft Visual C++ (MSVC) compatible[1].
 2-Cross compiling Snowflake code: This step is currently done using MingW
 because Cgo (which integrates Golang with C) does not support Clang for
 Windows[2].
 3-Linking Snowflake binary against WebRTC lib: This part is problematic.
 First, Cgo currently doesn't support MSVC object files [3] and MingW and
 Clang/MSVC object files are not compatible[4]. An attempt to link these
 two using MingW leads to compiler errors `undefined reference to`
 mentioned in[comment:29].



 [1]- https://clang.llvm.org/docs/MSVCCompatibility.html
 [2]- https://github.com/golang/go/issues/17014
 [3]- https://github.com/golang/go/issues/20982
 [4]- http://www.mingw.org/wiki/MixingCompilers

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

Re: [tor-bugs] #24991 [Core Tor/Tor]: relay frequently claiming "missing descriptors for 1/2 of our primary entry guards"

[Tor Bug Tracker & Wiki]

#24991: relay frequently claiming "missing descriptors for 1/2 of our primary 
entry
guards"
-+-
 Reporter:  alecmuffett  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Minor| Resolution:
 Keywords:  single-onion, guards, logging,   |  Actual Points:
  easy, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:  #23863   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 That log config looks fine.

 Please don't strip the log levels from your logs. Some of those messages
 have different log levels depending on internal state, and I need the log
 levels to debug this issue.

 I think that directory_info_has_arrived() is being called twice, probably
 for the consensus and for descriptors. Unless something else is going
 wrong, that's not a bug.

 But we can improve the log message by saying what kind of directory
 documents we just downloaded.

 I'll know when I see the debug logs.

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

[tor-bugs] #26246 [Core Tor/Chutney]: Add a chutney network without relay DirPorts

[Tor Bug Tracker & Wiki]

#26246: Add a chutney network without relay DirPorts
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 All supported Tor client versions don't use DirPorts. We should add a
 chutney network that doesn't have any relay DirPorts, and then make it one
 of Tor's make test-network-all networks.

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

[tor-bugs] #26245 [Core Tor/Tor]: Unused Rust code warnings

[Tor Bug Tracker & Wiki]

#26245: Unused Rust code warnings
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.1-alpha
 Severity:  Normal|   Keywords:  034-must-maybe, rust
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Recent Rust versions (1.26.1) report the following warnings on master:
 {{{
 warning: constant item is never used: `N_DIGEST_ALGORITHMS`
   --> external/crypto_digest.rs:74:1
|
 74 | const N_DIGEST_ALGORITHMS: usize = DIGEST_SHA3_512 as usize + 1;
| 
|
= note: #[warn(dead_code)] on by default

 warning: type alias is never used: `smartlist_t`
--> external/crypto_digest.rs:120:1
 |
 120 | type smartlist_t = Stringlist;
 | ^^
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26244 [Core Tor/Nyx]: The ability to jump to the bottom or top of the connection list in Nyx

[Tor Bug Tracker & Wiki]

#26244: The ability to jump to the bottom or top of the connection list in Nyx
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Nyx   |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 The ability to jump to the bottom or top of the connection list in Nyx is
 needed because it can take minutes when I have thousands of connections
 and I have to use the arrow keys to go from the bottom to the top. Tested
 using Nyx 2.0.4

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

Re: [tor-bugs] #26242 [Applications/Tor Browser]: Implement update strategy for TBA

[Tor Bug Tracker & Wiki]

#26242: Implement update strategy for TBA
--+--
 Reporter:  igt0  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by igt0):

 * cc: sysrqb, gk (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] #26242 [Applications/Tor Browser]: Implement update strategy for TBA

[Tor Bug Tracker & Wiki]

#26242: Implement update strategy for TBA
--+--
 Reporter:  igt0  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by igt0):

 I see two solutions:

 1. Follow what Tor Browser Desktop does: When the user opens a tab, we
 show a warning message saying that there is a new version and the browser
 is out to date.

  Pros: It is not intrusive and the user decides if they want to upgrade it
 or not.

  Cons: The user never upgrades the app because it is not just one click,
 they need to go to settings to   upgrade  it.

 2. Open a dialog covering the whole screen saying that the app is out to
 date and allowing or not the user to close the modal.

  Pros: Force the user to update the browser, if there is a security issue,
 the user will not use an out dated browser.

  Cons: It affects the app usability, because it blocks the user
 interaction with the main application.

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

Re: [tor-bugs] #24991 [Core Tor/Tor]: relay frequently claiming "missing descriptors for 1/2 of our primary entry guards"

[Tor Bug Tracker & Wiki]

#24991: relay frequently claiming "missing descriptors for 1/2 of our primary 
entry
guards"
-+-
 Reporter:  alecmuffett  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Minor| Resolution:
 Keywords:  single-onion, guards, logging,   |  Actual Points:
  easy, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:  #23863   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by starlight):

 Will log this for tomorrow around the expected time (24hrs + 10min) with

 {{{
 SETCONF LogMessageDomains=1 LogTimeGranularity=1 Log="notice syslog"
 Log="[*]notice [*]info [general,dir,dirserv,guard,heartbeat,consdiff]debug
 file logfile$(date '+%M%S')"
 }}}

 If a category is missing or `SafeLogging=0` should be set please advise.

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

Re: [tor-bugs] #25501 [Core Tor/Tor]: Control-flow issues solved for WTF-pad

[Tor Bug Tracker & Wiki]

#25501: Control-flow issues solved for WTF-pad
---+---
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.5.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  control-flow, tor-circuit  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor2
---+---
Changes (by arma):

 * cc: armadev (removed)
 * cc: arma (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] #24991 [Core Tor/Tor]: relay frequently claiming "missing descriptors for 1/2 of our primary entry guards"

[Tor Bug Tracker & Wiki]

#24991: relay frequently claiming "missing descriptors for 1/2 of our primary 
entry
guards"
-+-
 Reporter:  alecmuffett  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Minor| Resolution:
 Keywords:  single-onion, guards, logging,   |  Actual Points:
  easy, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:  #23863   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by starlight):

 Appears to me recovery is near instantaneous, which provoked the idea it
 might be a race condition in processing logic:

 {{{
 May 26 19:23:34 Tor[]: Heartbeat: Tor's uptime is 5 days 6:00 hours
 May 26 19:25:42 Tor[]: Our directory information is no longer up-to-date
 enough to build circuits: We're missing descriptors for 1/2 of our primary
 entry guards (total microdescriptors: 6346/6383).
 May 26 19:25:42 Tor[]: I learned some more directory information, but not
 enough to build a circuit: We're missing descriptors for 1/2 of our
 primary entry guards (total microdescriptors: 6346/6383).
 May 26 19:25:42 Tor[]: We now have enough directory information to build
 circuits.
 }}}

 {{{
 May 29 07:23:34 Tor[]: Heartbeat: Tor's uptime is 7 days 18:00 hours
 May 29 09:18:44 Tor[]: Our directory information is no longer up-to-date
 enough to build circuits: We're missing descriptors for 1/2 of our primary
 entry guards (total microdescriptors: 6307/6352).
 May 29 09:18:44 Tor[]: I learned some more directory information, but not
 enough to build a circuit: We're missing descriptors for 1/2 of our
 primary entry guards (total microdescriptors: 6307/6352).
 May 29 09:18:45 Tor[]: We now have enough directory information to build
 circuits.
 }}}

 {{{
 May 30 07:23:34 Tor[]: Heartbeat: Tor's uptime is 8 days 18:00 hours
 May 30 09:28:45 Tor[]: Our directory information is no longer up-to-date
 enough to build circuits: We're missing descriptors for 1/2 of our primary
 entry guards (total microdescriptors: 6317/6353).
 May 30 09:28:45 Tor[]: I learned some more directory information, but not
 enough to build a circuit: We're missing descriptors for 1/2 of our
 primary entry guards (total microdescriptors: 6317/6353).
 May 30 09:28:46 Tor[]: We now have enough directory information to build
 circuits.
 }}}

 Could log debug to disk with millisecond resolution if that helps.  Is
 full debug required or would a subsystem or two work?  If the latter
 please indicate which subsystem(s) to 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

Re: [tor-bugs] #3723 [Core Tor/Tor]: Report version of bwscanners in votes

[Tor Bug Tracker & Wiki]

#3723: Report version of bwscanners in votes
--+
 Reporter:  mikeperry |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-dirauth   |  Actual Points:
Parent ID:  #25925| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  new => 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] #3723 [Core Tor/Tor]: Report version of bwscanners in votes

[Tor Bug Tracker & Wiki]

#3723: Report version of bwscanners in votes
--+
 Reporter:  mikeperry |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-dirauth   |  Actual Points:
Parent ID:  #25925| Points:
 Reviewer:|Sponsor:
--+
Changes (by juga):

 * keywords:   => tor-dirauth


Comment:

 Since it is not being backported i based it on master, now in my branch
 `ticket3723`

 After looking more to `dirvote.c` i thought it was better to use
 `smartlist_t` instead of string, and get it converted to string in
 `format_networkstatus_vote`.

 Since `dirserv_read_measured_bandwidths` is call from
 `dirserv_generate_networkstatus_vote_obj`, i don't need a different
 function to obtain the headers.

 Since i didn't found specific tests for
 `dirserv_generate_networkstatus_vote_obj` and `format_networkstatus_vote`,
 i'm not sure how to add tests for the vote document.

 This code break other tests, hints?.

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

Re: [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:  pospeselr
 Type:  defect  | Status:  assigned
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201805  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
Changes (by pospeselr):

 * status:  new => assigned
 * owner:  tbb-team => pospeselr


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

Re: [tor-bugs] #24991 [Core Tor/Tor]: relay frequently claiming "missing descriptors for 1/2 of our primary entry guards"

[Tor Bug Tracker & Wiki]

#24991: relay frequently claiming "missing descriptors for 1/2 of our primary 
entry
guards"
-+-
 Reporter:  alecmuffett  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Minor| Resolution:
 Keywords:  single-onion, guards, logging,   |  Actual Points:
  easy, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:  #23863   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  new => needs_information
 * version:  Tor: 0.3.4.1-alpha => Tor: 0.3.0.1-alpha


Comment:

 (This is a bug on 0.3.0.1-alpha, the earliest version with this issue.)

 You've stripped the times and the log levels from your log, so it's hard
 to analyse this bug.

 {{{
 Our directory information is no longer up-to-date enough to build
 circuits: We're missing descriptors for 1/2 of our primary entry guards
 (total microdescriptors: 6346/6383).
 I learned some more directory information, but not enough to build a
 circuit: We're missing descriptors for 1/2 of our primary entry guards
 (total microdescriptors: 6346/6383).
 We now have enough directory information to build circuits.
 }}}

 These logs show that Tor expires the microdescs for one of its guards,
 then fetches some more microdescs, then finally gets enough to use that
 guard again. How long did it take to recover?

 If it only took a minute or so, then that's ok. Maybe we should downgrade
 the log levels. But they are useful if the descriptor download fails.

 If it took a long time, then maybe we need to make the downloads more
 aggressive.

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

Re: [tor-bugs] #19506 [Core Tor/Tor]: Tool to inspect id signing certs

[Tor Bug Tracker & Wiki]

#19506: Tool to inspect id signing certs
-+-
 Reporter:  weasel   |  Owner:  rl1987
 Type:  enhancement  | Status:
 |  reopened
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.4-rc
 Severity:  Normal   | Resolution:
 Keywords:  ed25519 tor-relay monitor tooling|  Actual Points:
  admin-tools|
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by weasel):

 The problem with running the tor binary is that it's not obvious what the
 heck it will do.  It's scary very, very scary.

 This failure actually is a prime example -- it tries to do thing it has no
 business doing.  All I want is the expiration date of the id key, yet it
 tries to load secret key material that it doesn't need and shouldn't have.
 {{{
 tor --key-expiration sign
 May 30 18:43:44.619 [notice] Tor 0.3.3.6 (git-c9903102c98cd028) running on
 Linux with Libevent 2.0.21-stable, OpenSSL 1.1.0f, Zlib 1.2.8, Liblzma
 5.2.2, and Libzstd 1.1.2.
 May 30 18:43:44.619 [notice] Tor can't help you if you use it wrong! Learn
 how to be safe at https://www.torproject.org/download/download#warning
 May 30 18:43:44.619 [notice] Read configuration file "/etc/tor/torrc".
 May 30 18:43:44.623 [warn] Skipping obsolete configuration option
 'SocksListenAddress'
 May 30 18:43:44.624 [notice] Based on detected system memory,
 MaxMemInQueues is set to 5974 MB. You can override this by setting
 MaxMemInQueues by hand.
 May 30 18:43:44.624 [warn] You have used DirAuthority or
 AlternateDirAuthority to specify alternate directory authorities in your
 configuration. This is potentially dangerous: it can make you look
 different from all other Tor users, and hurt your anonymity. Even if
 you've specified the same authorities as Tor uses by default, the defaults
 could change in the future. Be sure you know what you're doing.
 May 30 18:43:44.625 [err] No key found in
 "/var/lib/tor/.tor/keys/authority_signing_key"
 May 30 18:43:44.625 [warn] No version 3 directory key found in
 /var/lib/tor/.tor/keys/authority_signing_key
 May 30 18:43:44.625 [err] We're configured as a V3 authority, but we were
 unable to load our v3 authority keys and certificate! Use tor-gencert to
 generate them. Dying.
 May 30 18:43:44.625 [err] tor_assertion_failed_(): Bug:
 ../src/or/routerkeys.c:1187: log_master_signing_key_cert_expiration:
 Assertion server_identity_key_is_set() failed; aborting. (on Tor 0.3.3.6 )
 May 30 18:43:44.625 [err] Bug: Assertion server_identity_key_is_set()
 failed in log_master_signing_key_cert_expiration at
 ../src/or/routerkeys.c:1187. Stack trace: (on Tor 0.3.3.6 )
 May 30 18:43:44.625 [err] Bug: tor(log_backtrace+0x44)
 [0x55af745bb864] (on Tor 0.3.3.6 )
 May 30 18:43:44.625 [err] Bug: tor(tor_assertion_failed_+0x8d)
 [0x55af745d6fad] (on Tor 0.3.3.6 )
 May 30 18:43:44.625 [err] Bug: tor(log_cert_expiration+0x13f)
 [0x55af744d0baf] (on Tor 0.3.3.6 )
 May 30 18:43:44.625 [err] Bug: tor(tor_run_main+0xf2) [0x55af74487e32]
 (on Tor 0.3.3.6 )
 May 30 18:43:44.625 [err] Bug: tor(tor_main+0x3a) [0x55af744813ea] (on
 Tor 0.3.3.6 )
 May 30 18:43:44.625 [err] Bug: tor(main+0x19) [0x55af74481159] (on Tor
 0.3.3.6 )
 May 30 18:43:44.625 [err] Bug: /lib/x86_64-linux-
 gnu/libc.so.6(__libc_start_main+0xf1) [0x7f3ff8e242e1] (on Tor 0.3.3.6 )
 May 30 18:43:44.625 [err] Bug: tor(_start+0x2a) [0x55af744811aa] (on
 Tor 0.3.3.6 )
 }}}

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

Re: [tor-bugs] #25477 [Core Tor/Tor]: Stop warning users about bug #21018

[Tor Bug Tracker & Wiki]

#25477: Stop warning users about bug #21018
-+-
 Reporter:  asn  |  Owner:  rl1987
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-client,  |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
  034-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  tor-hs, tor-client, 034-triage-20180328, 034-removed-20180328
 =>
 tor-hs, tor-client, 034-triage-20180328, 034-removed-20180328
 034-backport
 * milestone:  Tor: unspecified => Tor: 0.3.5.x-final


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

Re: [tor-bugs] #26197 [Internal Services/Service - git]: Sync git.torproject.org/stem.git to github.com/torproject/stem.git

[Tor Bug Tracker & Wiki]

#26197: Sync git.torproject.org/stem.git to github.com/torproject/stem.git
-+
 Reporter:  teor |  Owner:  tor-gitadm
 Type:  task | Status:  reopened
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by isis):

 Replying to [comment:2 atagar]:
 > Thanks Isis! Here's my GitHub user...
 >
 > https://github.com/atagar

 No prob!  You should have an invite to the organisation and for admin
 permissions on the stem-maintainers team.  I think that means you can add
 more contributors/members, but if not just ping me or another github admin
 with their usernames and I'll add them.

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

Re: [tor-bugs] #25477 [Core Tor/Tor]: Stop warning users about bug #21018

[Tor Bug Tracker & Wiki]

#25477: Stop warning users about bug #21018
-+-
 Reporter:  asn  |  Owner:  rl1987
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-client,  |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by rl1987):

 * status:  accepted => needs_review


Comment:

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

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

Re: [tor-bugs] #26197 [Internal Services/Service - git]: Sync git.torproject.org/stem.git to github.com/torproject/stem.git

[Tor Bug Tracker & Wiki]

#26197: Sync git.torproject.org/stem.git to github.com/torproject/stem.git
-+
 Reporter:  teor |  Owner:  tor-gitadm
 Type:  task | Status:  reopened
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by isis):

 Replying to [comment:4 teor]:
 > This is not fixed: the GitHub stem master is behind the torproject stem
 master

 Yep, it's not fixed. I didn't set up mirroring at all, and I can't since
 I'm not an admin of git.tpo.

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

Re: [tor-bugs] #19506 [Core Tor/Tor]: Tool to inspect id signing certs

[Tor Bug Tracker & Wiki]

#19506: Tool to inspect id signing certs
-+-
 Reporter:  weasel   |  Owner:  rl1987
 Type:  enhancement  | Status:
 |  reopened
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.4-rc
 Severity:  Normal   | Resolution:
 Keywords:  ed25519 tor-relay monitor tooling|  Actual Points:
  admin-tools|
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by rl1987):

 You're supposed to run `tor --key-expiration sign` to see expiration date
 of you Ed25519 key/cert while your Tor instance is running. I can see why
 this isn't ideal, but do we really need it as a separate binary? Seems
 like (mostly) duplication of functionality.

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

Re: [tor-bugs] #25477 [Core Tor/Tor]: Stop warning users about bug #21018

[Tor Bug Tracker & Wiki]

#25477: Stop warning users about bug #21018
-+-
 Reporter:  asn  |  Owner:  rl1987
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-client,  |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:
 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] #26145 [Applications/Tor Browser]: The "Tor Browser" shortcut file should be renamed

[Tor Bug Tracker & Wiki]

#26145: The "Tor Browser" shortcut file should be renamed
--+--
 Reporter:  David_Hedlund |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by rl1987):

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


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

Re: [tor-bugs] #26210 [Core Tor/Stem]: Stem test for GETINFO md/all

[Tor Bug Tracker & Wiki]

#26210: Stem test for GETINFO md/all
--+
 Reporter:  rl1987|  Owner:  atagar
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.5.x-final
Component:  Core Tor/Stem |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-client tor-control microdesc  |  Actual Points:
Parent ID:  #8323 | Points:
 Reviewer:|Sponsor:
--+
Changes (by rl1987):

 * type:  defect => enhancement


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

Re: [tor-bugs] #20874 [Core Tor/Tor]: ReachableAddresses adds an extra reject *:* on every SAVECONF

[Tor Bug Tracker & Wiki]

#20874: ReachableAddresses adds an extra reject *:* on every SAVECONF
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, torrc, saveconf, |  Actual Points:
  configuration, annoyance   |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  assigned => needs_review
 * milestone:  Tor: unspecified => Tor: 0.3.5.x-final


Comment:

 This is a bugfix, but it's not essential for 0.3.4, and may have
 unexpected consequences. So I've assigned it to 0.3.5.

 I would like to make sure this patch is tested with stem - I think atagar
 (or a nyx user?) reported this bug originally.

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

Re: [tor-bugs] #26200 [Core Tor/Tor]: Bandwidth List format specification: add KeyValues counting errors in Bandwidth Lines

[Tor Bug Tracker & Wiki]

#26200: Bandwidth List format specification: add KeyValues counting errors in
Bandwidth Lines
-+-
 Reporter:  juga |  Owner:  (none)
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth, bwauth, specification,  |  Actual Points:
  tor-spec   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => merge_ready
 * type:  defect => enhancement


Comment:

 Looks good to me!

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

Re: [tor-bugs] #26243 [Core Tor/Tor]: Hidden Services broken with TransPort

[Tor Bug Tracker & Wiki]

#26243: Hidden Services broken with TransPort
--+--
 Reporter:  camping   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.6
 Severity:  Normal| Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by camping):

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


Comment:

 Not a Tor bug after all. I apologize.

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

Re: [tor-bugs] #26220 [Core Tor/Tor]: Experiment with building/running Tor inside Docker container

[Tor Bug Tracker & Wiki]

#26220: Experiment with building/running Tor inside Docker container
--+--
 Reporter:  rl1987|  Owner:  rl1987
 Type:  task  | Status:  accepted
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by rl1987):

 Getting Tor to build (and run) inside Docker:
 * https://github.com/torproject/tor/compare/master...rl1987:docker_hax

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

Re: [tor-bugs] #24991 [Core Tor/Tor]: relay frequently claiming "missing descriptors for 1/2 of our primary entry guards"

[Tor Bug Tracker & Wiki]

#24991: relay frequently claiming "missing descriptors for 1/2 of our primary 
entry
guards"
-+-
 Reporter:  alecmuffett  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.4.1-alpha
 Severity:  Minor| Resolution:
 Keywords:  single-onion, guards, logging,   |  Actual Points:
  easy, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:  #23863   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by starlight):

 Perhaps the messages result from a race bug between the microdescriptor
 refresh tail-end and network reachable evaluation logic.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26243 [Core Tor/Tor]: Hidden Services broken with TransPort

[Tor Bug Tracker & Wiki]

#26243: Hidden Services broken with TransPort
--+--
 Reporter:  camping   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.6
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Upgrading from 0.3.2.10 to 0.3.3.6, we noticed that hidden services over
 TransPort are now broken. Configuration is the same as before, did not
 notice any changes about this in the Change Log.

 The .onion will return an IP through DNS lookup, but immediately the
 connection is closed once it tries to connect to the local IP. Non .onions
 are fine.

 Since 0.3.2.10 was pulled from the repositories, we cannot pin to the
 older working version.

 Here is the configuration:

 --SocksPort "0 IPv6Traffic" --VirtualAddrNetworkIPv4 172.16.0.0/12
 --VirtualAddrNetworkIPv6 [FC00::]/7 --AutomapHostsOnResolve 1
 --AutomapHostSuffixes .onion --TransPort "127.0.0.1:%I" --TransPort
 "[::1]:%I" --DNSPort "127.0.0.1:%I" --DNSPort "[::1]:%I"

 Both V2 and V3 Hidden Services are broken.

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

Re: [tor-bugs] #23863 [Core Tor/Tor]: When our directory guards don't have each others' microdescs, we should try an authority or fallback

[Tor Bug Tracker & Wiki]

#23863: When our directory guards don't have each others' microdescs, we should 
try
an authority or fallback
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-bridge, tor-client,   |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by starlight):

 * cc: starlight@… (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] #24991 [Core Tor/Tor]: relay frequently claiming "missing descriptors for 1/2 of our primary entry guards" (was: relay claims "missing descriptors for 1/2 of our primary entry guards",

[Tor Bug Tracker & Wiki]

#24991: relay frequently claiming "missing descriptors for 1/2 of our primary 
entry
guards"
-+-
 Reporter:  alecmuffett  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.4.1-alpha
 Severity:  Minor| Resolution:
 Keywords:  single-onion, guards, logging,   |  Actual Points:
  easy, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:  #23863   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

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

Re: [tor-bugs] #26237 [Applications/Tor Browser]: Back and Forward button should be on the left side of the toolbar

[Tor Bug Tracker & Wiki]

#26237: Back and Forward button should be on the left side of the toolbar
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff60-esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Reload button doesn't appear as well. NoScript ends up in the toolbar
 after an update.

 (Wish: Set Density to compact by default (see >Customize))

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

Re: [tor-bugs] #24991 [Core Tor/Tor]: relay claims "missing descriptors for 1/2 of our primary entry guards", has no guards, makes no sense (was: SingleOnion claims "missing descriptors for 1/2 of our

[Tor Bug Tracker & Wiki]

#24991: relay claims "missing descriptors for 1/2 of our primary entry guards", 
has
no guards, makes no sense
-+-
 Reporter:  alecmuffett  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.4.1-alpha
 Severity:  Minor| Resolution:
 Keywords:  single-onion, guards, logging,   |  Actual Points:
  easy, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:  #23863   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

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

Re: [tor-bugs] #24991 [Core Tor/Tor]: SingleOnion claims "missing descriptors for 1/2 of our primary entry guards", has no guards, makes no sense

[Tor Bug Tracker & Wiki]

#24991: SingleOnion claims "missing descriptors for 1/2 of our primary entry
guards", has no guards, makes no sense
-+-
 Reporter:  alecmuffett  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.4.1-alpha
 Severity:  Minor| Resolution:
 Keywords:  single-onion, guards, logging,   |  Actual Points:
  easy, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:  #23863   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by starlight):

 * cc: starlight@… (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] #24991 [Core Tor/Tor]: SingleOnion claims "missing descriptors for 1/2 of our primary entry guards", has no guards, makes no sense

[Tor Bug Tracker & Wiki]

#24991: SingleOnion claims "missing descriptors for 1/2 of our primary entry
guards", has no guards, makes no sense
-+-
 Reporter:  alecmuffett  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.4.1-alpha
 Severity:  Minor| Resolution:
 Keywords:  single-onion, guards, logging,   |  Actual Points:
  easy, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:  #23863   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by starlight):

 * version:  Tor: 0.3.2.9 => Tor: 0.3.4.1-alpha


Comment:

 Seeing this with 0.3.4.1-alpha on a guard relay that has no client
 activity.  Something seems wrong about it because the shortage of
 descriptors is minuscule yet the message indicates a guard appears in the
 missing set.  Performed a DROPGUARDS thinking one of the guards was bum
 somehow, and the message came back the next day with the fresh set.  I
 wonder if this is a bug in the new differential descriptor logic; why
 would 50 relays go missing every day as an exceptional event?

 {{{
 DownloadExtraInfo 1
 }}}

 Removed cached-* and diff-cache/* before start.



 {{{
 Tor 0.3.4.1-alpha (git-deb8970a29ef7427) running on Linux with Libevent
 x.x.x, OpenSSL x.x.x, Zlib x.x.x, Liblzma x.x.x, and Libzstd x.x.x.
 Bootstrapped 0%: Starting
 Starting with guard context "default"
 Bootstrapped 10%: Finishing handshake with directory server
 I learned some more directory information, but not enough to build a
 circuit: We have no usable consensus.
 I learned some more directory information, but not enough to build a
 circuit: We have no usable consensus.
 Bootstrapped 45%: Asking for relay descriptors
 I learned some more directory information, but not enough to build a
 circuit: We need more microdescriptors: we have 0/6493, and can only build
 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, and 0% of
 exit bw = 0% of path bw.)
 I learned some more directory information, but not enough to build a
 circuit: We need more microdescriptors: we have 0/6493, and can only build
 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, and 0% of
 exit bw = 0% of path bw.)
 Bootstrapped 50%: Loading relay descriptors
 Bootstrapped 55%: Loading relay descriptors
 Bootstrapped 60%: Loading relay descriptors
 Bootstrapped 65%: Loading relay descriptors
 Bootstrapped 70%: Loading relay descriptors
 Problem bootstrapping. Stuck at 73%: Loading relay descriptors. (No route
 to host; NOROUTE; count 1; recommendation warn; host X at x.x.x.x:x)
 Bootstrapped 75%: Loading relay descriptors
 Bootstrapped 80%: Connecting to the Tor network
 Bootstrapped 85%: Finishing handshake with first hop
 Bootstrapped 90%: Establishing a Tor circuit
 Tor has successfully opened a circuit. Looks like client functionality is
 working.
 Bootstrapped 100%: Done
 Self-testing indicates your DirPort is reachable from the outside.
 Excellent. Publishing server descriptor.
 Performing bandwidth self-test...done.
 Heartbeat: Tor's uptime is 6:00 hours,
 Heartbeat: Tor's uptime is 12:00 hours,
 Heartbeat: Tor's uptime is 18:00 hours,
 Heartbeat: Tor's uptime is 1 day 0:00 hours,
 Heartbeat: Tor's uptime is 1 day 6:00 hours,
 Heartbeat: Tor's uptime is 1 day 12:00 hours,
 Heartbeat: Tor's uptime is 1 day 18:00 hours,
 Heartbeat: Tor's uptime is 2 days 0:00 hours,
 Heartbeat: Tor's uptime is 2 days 6:00 hours,
 Heartbeat: Tor's uptime is 2 days 12:00 hours,
 Heartbeat: Tor's uptime is 2 days 18:00 hours,
 Heartbeat: Tor's uptime is 3 days 0:00 hours,
 Heartbeat: Tor's uptime is 3 days 6:00 hours,
 Heartbeat: Tor's uptime is 3 days 12:00 hours,
 Heartbeat: Tor's uptime is 3 days 18:00 hours,
 Heartbeat: Tor's uptime is 4 days 0:00 hours,
 Channel padding timeout scheduled 209531ms in the past.
 Heartbeat: Tor's uptime is 4 days 6:00 hours,
 Heartbeat: Tor's uptime is 4 days 12:00 hours,
 Heartbeat: Tor's uptime is 4 days 18:00 hours,
 Heartbeat: Tor's uptime is 5 days 0:00 hours,
 Heartbeat: Tor's uptime is 5 days 6:00 hours,
 Our directory information is no longer up-to-date enough to build
 circuits: We're missing descriptors for 1/2 of our primary entry guards
 (total microdescriptors: 6346/6383).
 I learned some more directory information, but not enough to build a
 circuit: We're missing descriptors for 1/2 of our primary entry guards
 (total microdescriptors: 6346/6383).
 We now have enough 

Re: [tor-bugs] #26240 [Core Tor]: Check Maxmind GeoIPLocation Database before distributing

[Tor Bug Tracker & Wiki]

#26240: Check Maxmind GeoIPLocation Database before distributing
+
 Reporter:  jvsg|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  GeoIP, Geoipdb  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by irl):

 #25542 may be relevant.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26242 [Applications/Tor Browser]: Implement update strategy for TBA

[Tor Bug Tracker & Wiki]

#26242: Implement update strategy for TBA
--+
 Reporter:  igt0  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-mobile
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 When a new Tor Browser for Desktop is released there are two main visual
 changes in the Browser:

 1. the about:tor page changes saying that the browser is out dated

 2. Tor Button icon changes. It adds an exclamation mark informing the user
 that there is a new browser version.

 We need to discuss how we notify the users about TBA updates.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26241 [Obfuscation/meek]: Check meek TLS fingerprint on ESR 60

[Tor Bug Tracker & Wiki]

#26241: Check meek TLS fingerprint on ESR 60
--+-
 Reporter:  dcf   |  Owner:  dcf
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 #22515 previous ticket for ESR 52.

 https://lists.torproject.org/pipermail/tbb-dev/2018-May/000849.html
 http://f4amtbsowhix7rrf.onion/tor-browser-builds/

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

[tor-bugs] #26240 [Core Tor]: Check Maxmind GeoIPLocation Database before distributing

[Tor Bug Tracker & Wiki]

#26240: Check Maxmind GeoIPLocation Database before distributing
--+
 Reporter:  jvsg  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor  |Version:
 Severity:  Normal|   Keywords:  GeoIP, Geoipdb
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Currently we're consuming Maxmind's (a company registered in the U.S)
 GeoIPLocation Database in Tor. Not just this goes against the principles
 of modern privacy that advocates non-reliance on any single
 organisation/product, but comes with some serious threats. A powerful
 adversary can impose it's control over Maxmind's database. This can be
 used to attack tor in a variety of ways:

 1. The Tor Network is constantly monitored for any suspicious spike in
 nodes, as it may be an indication of an oncoming/undergoing sybil attack.
 A powerful adversary can coerce Maxmind to map some specific IP address
 blocks to random countries. This may lead to people/scripts monitoring the
 network to not feel suspicious about this event, and would result in the
 adversary staying under the radar.

 2. A large percentage of people don't want the exit of their circuits to
 be located in certain countries where the communication is under
 surveillance. The powerful adversary knows this as well. Users generally
 add a line in their config that allows them to not form a circuit through
 nodes located in those locations. To overcome this, the adversary can
 coerce Maxmind to alter it's database to map some particular IP's to
 locations which the user thinks  are havens of free speech.


 **Solution**

 I propose a system where instead of directly distributed maxmind's db to
 the users, we first check it for any anomalies.

 This is how it works:

 1. The Dir Authorities fetch the GeoIPLocation DBs from all the companies
 (including Maxmind) located in distinct countries.

 2. Tor Nodes' location (from maxmind) are checked against other DBs as
 well. The location which appears in a majority of DB is considered
 authentic.

 3. All the Dir Authorities perform the above two steps periodically and
 independently of each other, and try to reach on a consensus.

 4. This DB is then distributed to the users along with any modifications
 from step 2.

 **What if locations differ in all/most of the DBs?**

 A case might arise where the locations for an IP differ in all/most of
 DBs, because these locations are just guesses and hence can be erroneous.
 However IMO,

 1. Most of the nodes are either run from large datacentres, which in all
 cases have the right GeoLocation mapped to their IP addr range.

 2. Even if the nodes are run from home on a static IP, usually the whois
 records are well kept, which help companies such as maxmind fetch data for
 their DBs.

 So, false positives would be very few. Even if there are some, we can ban
 the IP addr from participating in the network until the issue is resolved.
 Or we can be a little liberal and allow them to participate given that
 there isnt a spike in number of nodes recently.

 **What about DB licenses?**

 Only the Dir Auths have to pay to get DBs in addition to the freely
 available maxmind DB. The DB that we will distribute to the users would
 just be maxmind (with some possible modifications)

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

Re: [tor-bugs] #25543 [Applications/Tor Browser]: Rebase Tor Browser patches for ESR60

[Tor Bug Tracker & Wiki]

#25543: Rebase Tor Browser patches for ESR60
-+-
 Reporter:  gk   |  Owner:
 |  arthuredelstein
 Type:  task | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201805R, ff60-esr  |  Actual Points:
Parent ID:  #25741   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:42 gk]:
 > The external helper app patch looks good to me, too (I've not tested it,
 though).

 To close the loop on this one: Kathy and I reviewed and tested the patch
 (on macOS), and it looks good to us.

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

Re: [tor-bugs] #26232 [Metrics/Website]: Release Tor Metrics 1.1.0

[Tor Bug Tracker & Wiki]

#26232: Release Tor Metrics 1.1.0
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  task | Status:  merge_ready
 Priority:  High |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Regarding tarball size, I just looked at the previous version, and that
 has a tarball size of 48M, too. We added some stuff since December 2017,
 so the 103M is at least not totally crazy. Working on this in another
 ticket sounds reasonable.

 And yes, the change log doesn't contain many changes. I gave up adding
 entries, because we made so many changes. If it works for everyone else to
 release anyway, it works for me, too.

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

Re: [tor-bugs] #26232 [Metrics/Website]: Release Tor Metrics 1.1.0

[Tor Bug Tracker & Wiki]

#26232: Release Tor Metrics 1.1.0
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  task | Status:  merge_ready
 Priority:  High |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

 * status:  needs_review => 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] #26232 [Metrics/Website]: Release Tor Metrics 1.1.0

[Tor Bug Tracker & Wiki]

#26232: Release Tor Metrics 1.1.0
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  task | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 The pre-release-tar looks fine and passes everything.
 I think the changelog doesn't really contain all changes, i.e., not all
 changes since December 2017.
 This shouldn't be a hindrance to releasing 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] #26232 [Metrics/Website]: Release Tor Metrics 1.1.0

[Tor Bug Tracker & Wiki]

#26232: Release Tor Metrics 1.1.0
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  task | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 Removing duplicate includes (cf. #25392) will be part of reducing size.

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

Re: [tor-bugs] #24977 [Core Tor/Tor]: Non-fatal assertion !(tor_mem_is_zero((const char*)node->hsdir_index->fetch, DIGEST256_LEN))

[Tor Bug Tracker & Wiki]

#24977: Non-fatal assertion !(tor_mem_is_zero((const
char*)node->hsdir_index->fetch, DIGEST256_LEN))
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, |  Actual Points:
  034-triage-20180328, 034-removed-20180502  |
Parent ID:   | Points:  1
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by asn):

 * status:  needs_revision => merge_ready


Comment:

 Replying to [comment:20 asn]:
 > Replying to [comment:19 nickm]:
 > > I think this might actually be a bugfix on 0.3.4, not on 0.3.2: 0.3.4
 changed the way that we call the dirvote calculation code when we did
 #25937. Could that be the cause of this?
 > >
 >
 > Hmm, I don't think so. Because also the backtrace from comment:8 is
 based on `Tor 0.3.3.5-rc` and represents the bug fixed by the branch. I'll
 look into this anyway.
 >

 Hm. I checked the branch from #25937 and I don't think it's related to
 this bug. This bug has been around for ever, but it started being visible
 now because we require a live consensus for some HSv3 functions to work
 properly. Hence, when we fetch a consensus with a skewed clock and wrongly
 consider it non-live, the relevant HSv3 functions also work badly. Our
 patch now basically re-runs those functions after the clock gets fixed.

 > > As for the patch itself: Is it possible for us to have this
 recalculation get _scheduled_ in update_current_time, but actually
 executed inside a mainloop_event?  Or does it hurt us to have other stuff
 called in between those points?  The problem there is that
 update_current_time already does too much: I'd rather keep our callgraph
 simple, and make tiny-fast functions like this _never_ have a slow-complex
 case.
 >
 > Yes, I think this is possible.
 >
 > I will try to make it so that `update_current_time()` sets a flag if
 needed, and then we actually do the computations as part of the HS
 subsystem.

 I implemented the above approach in my branch `bug24977`. You can also see
 the relevant PR here: https://github.com/torproject/tor/pull/124

 Please compare the approach of `bug24977` with the one from
 `bug24977_dev`. I think the one using callbacks indeed looks better.

 Not sure if this bug fix warrants a backport, it seems to be quite rare
 because it requires a skewed clock to occur. I'd vote for no, but let me
 know if you have a different opinion and I can prepare branches.

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

Re: [tor-bugs] #25555 [Applications/Tor Browser]: Reimplement Optimistic SOCKS feature

[Tor Bug Tracker & Wiki]

#2: Reimplement Optimistic SOCKS feature
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-performance, ff60-esr,   |  Actual Points:
  TorBrowserTeam201805   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * priority:  High => Very High


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

Re: [tor-bugs] #25741 [Applications/Tor Browser]: Create tor-browser for mobile branch based on mozilla-central

[Tor Bug Tracker & Wiki]

#25741: Create tor-browser for mobile branch based on mozilla-central
--+--
 Reporter:  gk|  Owner:  sysrqb
 Type:  defect| Status:  assigned
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201805, tbb-mobile  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * cc: boklm (added)


Comment:

 I guess we can use that (parent) bug to work on our general idea of
 automatically rebasing our patches against mozilla-central and figuring
 out what to do in case everything is okay/not okay. Should we run this
 rebase attempt daily? Weekly? Bi-weekly? I think I am against daily as a
 rebase failure might just be due to a broken m-c patch which is get fixed
 in $timeframe on mozilla-central "automatically" by Moz people. So, maybe
 starting with rebasing once a week could be a thing we try?

 I guess having an automated system that sends notification email about the
 result of the rebase would be good, indicating on which git commit the
 rebase was on. In case everything is fine I can do the rebase locally and
 push the result to our nightly branch.

 If it is not okay, we should file a ticket I guess with a special keyword
 and then someone from the team (maybe we create a particular role for that
 that is assigned on a weekly basis, like "rebase-hero") is looking into
 that and fixing up the issues. The idea would be to have things ready for
 review and merged until the next rebase attempt is running.

 If things are more thoroughly broken we can decide on a case-by-case basis
 what to do but fixing those problems will always be a top prio because we
 need enough testing time with functional builds to get the next Tor
 Browser for Android into stable shape.

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

Re: [tor-bugs] #14952 [Applications/Tor Browser]: Audit HTTP/2 and SPDY if needed

[Tor Bug Tracker & Wiki]

#14952: Audit HTTP/2 and SPDY if needed
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  assigned
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-linkability, tbb-usability-  |  Actual Points:
  website, tbb-performance, ff60-esr,|
  TorBrowserTeam201805   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * priority:  High => Very High


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

Re: [tor-bugs] #12968 [Applications/Tor Browser]: Specify HEASLR (High Entropy Address Space Layout Randomization) in MinGW-w64

[Tor Bug Tracker & Wiki]

#12968: Specify HEASLR (High Entropy Address Space Layout Randomization) in
MinGW-w64
-+-
 Reporter:  mikeperry|  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, tbb-rbm, ff60-esr, |  Actual Points:
  boklm201805, TorBrowserTeam201805R |
Parent ID:  #24631   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:17 gk]:
 > Replying to [comment:16 boklm]:
 > > There is a patch for review in branch `bug_12968`, adding the `-Wl
 ,--high-entropy-va` flag in the Windows x86_64 build:
 >
 > That might not be enough, see the ffmpeg link in comment:6. I guess we
 need at least `-Wl,--image-base,0x14000` additionally?

 Oh, and if that breaks compilation we might need to backport
 https://github.com/gcc-
 mirror/gcc/commit/f47fc7ef7f52cd095e636d4f93cca052427f3f0a.patch

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

Re: [tor-bugs] #12968 [Applications/Tor Browser]: Specify HEASLR (High Entropy Address Space Layout Randomization) in MinGW-w64

[Tor Bug Tracker & Wiki]

#12968: Specify HEASLR (High Entropy Address Space Layout Randomization) in
MinGW-w64
-+-
 Reporter:  mikeperry|  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, tbb-rbm, ff60-esr, |  Actual Points:
  boklm201805, TorBrowserTeam201805R |
Parent ID:  #24631   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:16 boklm]:
 > There is a patch for review in branch `bug_12968`, adding the `-Wl
 ,--high-entropy-va` flag in the Windows x86_64 build:

 That might not be enough, see the ffmpeg link in comment:6. I guess we
 need at least `-Wl,--image-base,0x14000` additionally?

 Is there some way to check that we are good by inspecting the binary?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26239 [Applications/Tor Browser]: Backport patch for bug 1448748 to fix Windows 64bit builds

[Tor Bug Tracker & Wiki]

#26239: Backport patch for bug 1448748 to fix Windows 64bit builds
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  task | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  ff60-esr,
 Severity:  Normal   |  TorBrowserTeam201805
Actual Points:   |  Parent ID:  #26203
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 The patch for https://bugzilla.mozilla.org/show_bug.cgi?id=1448748 is not
 available on ESR60 yet and we likely need to backport this NSS change at
 least for now.

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

Re: [tor-bugs] #25859 [Applications/Tor Browser]: Clean up zlib's build script

[Tor Bug Tracker & Wiki]

#25859: Clean up zlib's build script
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, boklm201805,|  Actual Points:
  TorBrowserTeam201805R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 The branch `bug_25859_v4` has the patch rebased on master:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_25859_v4=0e483da11bd8de64b3b881ef3484ae77f69759ed

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

Re: [tor-bugs] #25860 [Applications/Tor Browser]: Clean up OpenSSL's configure options for Windows

[Tor Bug Tracker & Wiki]

#25860: Clean up OpenSSL's configure options for Windows
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, boklm201805,|  Actual Points:
  TorBrowserTeam201805R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 The branch `bug_25860_v4` has the patch rebased on master:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_25860_v4=f60070a29e8c3b7307fb30218b2fa454190f9b5e

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26238 [Applications/Tor Browser]: Move from Debian Wheezy to Debian Jessie for our Linux builds

[Tor Bug Tracker & Wiki]

#26238: Move from Debian Wheezy to Debian Jessie for our Linux builds
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  task | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-rbm,
 Severity:  Normal   |  TorBrowserTeam201805
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Debian Wheezy is about to get unsupported and we should move to Debian
 Jessie for our Linux builds. This has the additional advantage that we
 don't have different Debian versions anymore to build bundles for all of
 our supported platforms: We are then using Debian Jessie everywhere.

 The only worrying situation is the CentOS one. We should think about
 whether we still can and want support CentOS 6 (which we need to do anyway
 while switching to Firefox ESR 60 which requires GTK3) and what the CentOS
 7 situation is if we start building using Jessie.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26237 [Applications/Tor Browser]: Back and Forward button should be on the left side of the toolbar

[Tor Bug Tracker & Wiki]

#26237: Back and Forward button should be on the left side of the toolbar
--+--
 Reporter:  gk|  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:|
--+--
 In nightly build based on ESR60 the buttons are next to the search bar.
 But they should be on the left side of the toolbar instead.

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

Re: [tor-bugs] #26235 [Applications/Tor Browser]: Help menu does not open in Tor Browser nightlies based on ESR60

[Tor Bug Tracker & Wiki]

#26235: Help menu does not open in Tor Browser nightlies based on ESR60
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  ff60-esr,TorBrowserTeam201805R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

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


Comment:

 Looks good to me. I changed the commit message a bit as we don't do the
 rebase thing in the torbutton repo (thus using `fixup` is not so
 beneficial). Rather, just showing the current bug number for reference
 seems like a good thing to me. Commit
 66048f2ad3c2708aec11d7414ec189e868c0d487 on `master` has the 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

[tor-bugs] #26236 [Applications/Tor Browser]: "myController is null" error when closing the browser

[Tor Bug Tracker & Wiki]

#26236: "myController is null" error when closing the browser
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  ff60-esr, tbb-
  |  torbutton
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Closing Tor Browser throws a JavaScript error:
 {{{
 May 30 06:17:45.000 [notice] Owning controller connection has closed --
 exiting now.
 May 30 06:17:45.000 [notice] Catching signal TERM, exiting cleanly.
 JavaScript error: chrome://torbutton/content/tor-circuit-display.js, line
 466: TypeError: myController is null
 }}}

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