Re: [tor-bugs] #24256 [Metrics/Onionoo]: Add a new "outdated" field to distinguish between outdated and too new tor versions

[Tor Bug Tracker & Wiki]

#24256: Add a new "outdated" field to distinguish between outdated and too new 
tor
versions
-+--
 Reporter:  arma |  Owner:  karsten
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #25199   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

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


Comment:

 I started working on 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] #25316 [Core Tor/Tor]: Assertion failure in scale_active_circuits

[Tor Bug Tracker & Wiki]

#25316: Assertion failure in scale_active_circuits
--+
 Reporter:  Logforme  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

 * component:  - Select a component => Core Tor/Tor


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

Re: [tor-bugs] #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:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201802R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Looks good. I merged it to `master` (commit
 79538fbfc42b467f7badce8eb5d024d74392f8a1). boklm, please have a look at
 the child ticket so that we can close this one.

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

Re: [tor-bugs] #24879 [Applications/Tor Browser]: Set 'fetch: 1' by default for nightly builds

[Tor Bug Tracker & Wiki]

#24879: Set 'fetch: 1' by default for nightly builds
---+---
 Reporter:  boklm  |  Owner:  tbb-team
 Type:  task   | Status:
   |  needs_revision
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201802  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by gk):

 * keywords:  tbb-rbm, TorBrowserTeam201802R => tbb-rbm,
   TorBrowserTeam201802
 * status:  needs_review => needs_revision


Comment:

 Thanks. It seems we want to have "if the selected commit" instead of "if
 the select 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] #25000 [Applications/Tor Browser]: TorBrowser's modifications to NoScript's mandatory whitelist break some webextensions when permissions are cascaded

[Tor Bug Tracker & Wiki]

#25000: TorBrowser's modifications to NoScript's mandatory whitelist break some
webextensions when permissions are cascaded
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam201802R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 Replying to [comment:30 mcs]:
 > Kathy and I confirmed that the proposed fix solves #23322.
 >
 > Unfortunately, it does not fix #24943. In fact, that issue occurs in Tor
 Browser 8.x even if NoScript is completely disabled and even when all of
 our bundled add-ons are disabled. The problem does not occur in Firefox
 ESR 52.6.0. All of these things seem to point to a browser patch as the
 cause.

 Thanks. I've reopened #24943 and merged the fix to `tor-browser-build`'s
 `master` (commit 448a263c986e4b824c5b4b205268e97fed88eb0c).

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

Re: [tor-bugs] #24943 [Applications/Tor Browser]: Tor Browser is preventing add-on from saving its setting (was: TorButton is preventing from add-on saving its setting)

[Tor Bug Tracker & Wiki]

#24943: Tor Browser is preventing add-on from saving its setting
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  mikeperry |Sponsor:
--+--
Changes (by gk):

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


Comment:

 This does not seem to be a duplicate of #25000. Here is what mcs and brade
 found out:
 {{{
 Unfortunately, it does not fix #24943. In fact, that issue occurs in Tor
 Browser 8.x even if NoScript is completely disabled and even when all of
 our bundled add-ons are disabled. The problem does not occur in Firefox
 ESR 52.6.0. All of these things seem to point to a browser patch as the
 cause.
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25316 [- Select a component]: Assertion failure in scale_active_circuits

[Tor Bug Tracker & Wiki]

#25316: Assertion failure in scale_active_circuits
--+
 Reporter:  Logforme  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Relay 855BC2DABE24C861CD887DB9B2E950424B49FC34 crashed with the following
 log entries:
 {{{
 Feb 20 14:33:40.000 [err] tor_assertion_failed_(): Bug:
 ../src/or/circuitmux_ewma.c:711: scale_active_circuits: Assertion
 e->last_adjusted_tick == pol->active_circuit_pqueue_last_recalibrated
 failed; aborting. (on Tor 0.3.2.9 )
 Feb 20 14:33:40.000 [err] Bug: Assertion e->last_adjusted_tick ==
 pol->active_circuit_pqueue_last_recalibrated failed in
 scale_active_circuits at ../src/or/circuitmux_ewma.c:711. Stack trace: (on
 Tor 0.3.2.9 )
 Feb 20 14:33:40.000 [err] Bug: /usr/bin/tor(log_backtrace+0x42)
 [0x7f4b7ab65fb2] (on Tor 0.3.2.9 )
 Feb 20 14:33:40.000 [err] Bug:
 /usr/bin/tor(tor_assertion_failed_+0x9f) [0x7f4b7ab80b3f] (on Tor 0.3.2.9
 )
 Feb 20 14:33:40.000 [err] Bug: /usr/bin/tor(+0xe74b2) [0x7f4b7aac74b2]
 (on Tor 0.3.2.9 )
 Feb 20 14:33:40.000 [err] Bug:
 /usr/bin/tor(circuitmux_notify_xmit_cells+0xdb) [0x7f4b7aac5a7b] (on Tor
 0.3.2.9 )
 Feb 20 14:33:40.000 [err] Bug:
 /usr/bin/tor(channel_flush_from_first_active_circuit+0x269)
 [0x7f4b7aa5b7d9] (on Tor 0.3.2.9 )
 Feb 20 14:33:40.000 [err] Bug:
 /usr/bin/tor(channel_flush_some_cells+0xe4) [0x7f4b7aaaf8d4] (on Tor
 0.3.2.9 )
 Feb 20 14:33:40.000 [err] Bug: /usr/bin/tor(+0xbd369) [0x7f4b7aa9d369]
 (on Tor 0.3.2.9 )
 Feb 20 14:33:40.000 [err] Bug: /usr/bin/tor(+0xbb2a2) [0x7f4b7aa9b2a2]
 (on Tor 0.3.2.9 )
 Feb 20 14:33:40.000 [err] Bug: /usr/lib/x86_64-linux-
 gnu/libevent-2.0.so.5(event_base_loop+0x414) [0x7f4b7a0ee254] (on Tor
 0.3.2.9 )
 Feb 20 14:33:40.000 [err] Bug: /usr/bin/tor(do_main_loop+0x255)
 [0x7f4b7aa35d75] (on Tor 0.3.2.9 )
 Feb 20 14:33:40.000 [err] Bug: /usr/bin/tor(tor_main+0x1e75)
 [0x7f4b7aa397d5] (on Tor 0.3.2.9 )
 Feb 20 14:33:40.000 [err] Bug: /usr/bin/tor(main+0x19)
 [0x7f4b7aa31539] (on Tor 0.3.2.9 )
 Feb 20 14:33:40.000 [err] Bug: /lib/x86_64-linux-
 gnu/libc.so.6(__libc_start_main+0xfd) [0x7f4b79103ead] (on Tor 0.3.2.9 )
 Feb 20 14:33:40.000 [err] Bug: /usr/bin/tor(+0x51589) [0x7f4b7aa31589]
 (on Tor 0.3.2.9 )
 }}}

 Relay runs on Debian wheezy. uname -a:
 Linux 3.2.0-5-amd64 #1 SMP Debian 3.2.96-3 x86_64 GNU/Linux

 Uptime before the crash was 23 days. Memory and CPU usage was normal:
 {{{
 Feb 20 12:55:12.000 [notice] Heartbeat: Tor's uptime is 23 days 17:59
 hours, with 30352 circuits open. I've sent 20574.36 GB and received
 20125.28 GB.
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25315 [Applications/Tor Browser]: Web sites embedding https://www.facebook.com/tr/ freeze Tor Browser due to NoScript's XSS filter

[Tor Bug Tracker & Wiki]

#25315: Web sites embedding https://www.facebook.com/tr/ freeze Tor Browser due 
to
NoScript's XSS filter
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Again NoScript's XSS filter seems to cause a freezing Tor Browser in case
 https://www.facebook.com/tr/ is embedded. Loading zeit.de is an example
 where one can see that happen right now.

 That's similar to #22362.

 NoScript version is 5.1.8.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] #25314 [Applications/Tor Mail]: Build error during Windows (32- and 64-bit builds) of Thunderbird

[Tor Bug Tracker & Wiki]

#25314: Build error during Windows (32- and 64-bit builds) of Thunderbird
---+
 Reporter:  sukhbir|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Mail  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by sukhbir):

 https://bugzilla.mozilla.org/show_bug.cgi?id=944905

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25314 [Applications/Tor Mail]: Build error during Windows (32- and 64-bit builds) of Thunderbird

[Tor Bug Tracker & Wiki]

#25314: Build error during Windows (32- and 64-bit builds) of Thunderbird
---+
 Reporter:  sukhbir|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Mail  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 When building Thunderbird for Windows (32- and 64-bit builds), we get the
 following error:

 {{{
 20:38.34 /var/tmp/build/thunderbird-
 48f960ae7db5/mailnews/base/search/src/nsMsgImapSearch.cpp: In static
 member function 'static nsresult nsMsgSearchOnlineMail::Encode(nsCString&,
 nsISupportsArray*, const char16_t*)':
 20:38.34 /var/tmp/build/thunderbird-
 48f960ae7db5/mailnews/base/search/src/nsMsgImapSearch.cpp:122:43: error:
 call of overloaded 'NS_IsAscii(char16ptr_t)' is ambiguous
 20:38.34  asciiOnly = NS_IsAscii(pchar.get());
 20:38.34^
 20:38.34 In file included from /var/tmp/build/thunderbird-48f960ae7db5
 /obj-mingw/dist/include/msgCore.h:15:0,
 20:38.35  from /var/tmp/build/thunderbird-
 48f960ae7db5/mailnews/base/search/src/nsMsgImapSearch.cpp:5:
 20:38.35 /var/tmp/build/thunderbird-48f960ae7db5/obj-
 mingw/dist/include/nsCRTGlue.h:101:6: note: candidate: bool
 NS_IsAscii(char16_t)
 20:38.35  bool NS_IsAscii(char16_t aChar);
 20:38.35   ^
 20:38.35 /var/tmp/build/thunderbird-48f960ae7db5/obj-
 mingw/dist/include/nsCRTGlue.h:102:6: note: candidate: bool
 NS_IsAscii(const char16_t*)
 20:38.35  bool NS_IsAscii(const char16_t* aString);
 20:38.35   ^
 20:38.35 /var/tmp/build/thunderbird-
 48f960ae7db5/mailnews/base/search/src/nsMsgImapSearch.cpp:131:48: error:
 operands to ?: have different types 'char16ptr_t' and 'const char16_t*'
 20:38.35char *csname = GetImapCharsetParam(asciiOnly ?
 usAsciiCharSet.get() : destCharset);
 20:38.35 ^
 20:38.35 /var/tmp/build/thunderbird-
 48f960ae7db5/mailnews/base/search/src/nsMsgImapSearch.cpp:131:48: note:
 and each type can be converted to the other
 20:38.35 /var/tmp/build/thunderbird-
 48f960ae7db5/mailnews/base/search/src/nsMsgImapSearch.cpp:136:15: error:
 operands to ?: have different types 'char16ptr_t' and 'const char16_t*'
 20:38.35  asciiOnly ?  usAsciiCharSet.get(): destCharset,
 20:38.35^
 20:38.35 /var/tmp/build/thunderbird-
 48f960ae7db5/mailnews/base/search/src/nsMsgImapSearch.cpp:136:15: note:
 and each type can be converted to the other
 20:38.35 /var/tmp/build/thunderbird-
 48f960ae7db5/mailnews/base/search/src/nsMsgImapSearch.cpp:137:15: error:
 operands to ?: have different types 'char16ptr_t' and 'const char16_t*'
 20:38.35  asciiOnly ?  usAsciiCharSet.get(): destCharset, false);
 20:38.35^
 20:38.35 /var/tmp/build/thunderbird-
 48f960ae7db5/mailnews/base/search/src/nsMsgImapSearch.cpp:137:15: note:
 and each type can be converted to the other
 20:38.40
 20:38.40 In the directory  /var/tmp/build/thunderbird-48f960ae7db5/obj-
 mingw/mailnews/base/search/src
 20:38.40 The following command failed to execute properly:
 20:38.40 /var/tmp/dist/mingw-w64/helpers/x86_64-w64-mingw32-g++
 -std=gnu++11 -mwindows -o nsMsgImapSearch.o -c -DNDEBUG=1 -DTRIMMED=1
 -DSTATIC_EXPORTABLE_JS_API -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API
 -DIMPL_LIBXUL -I/var/tmp/build/thunderbird-
 48f960ae7db5/mailnews/base/search/src -I/var/tmp/build/thunderbird-
 48f960ae7db5/obj-mingw/mailnews/base/search/src -I/var/tmp/build
 /thunderbird-48f960ae7db5/obj-mingw/dist/include -I/var/tmp/build
 /thunderbird-48f960ae7db5/obj-mingw/dist/include/nspr -I/var/tmp/build
 /thunderbird-48f960ae7db5/obj-mingw/dist/include/nss -DMOZILLA_CLIENT
 -include /var/tmp/build/thunderbird-48f960ae7db5/obj-mingw/mozilla-
 config.h -MD -MP -MF .deps/nsMsgImapSearch.o.pp -Wall -Wc++11-compat
 -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith
 -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-
 invalid-offsetof -Wc++14-compat -Wno-error=maybe-uninitialized -Wno-error
 =deprecated-declarations -Wno-error=array-bounds -Wno-format -fno-
 lifetime-dse -fno-exceptions -fno-strict-aliasing -mms-bitfields -fno-rtti
 -fno-exceptions -fno-math-errno -pipe -g -O -fomit-frame-pointer
 /var/tmp/build/thunderbird-
 48f960ae7db5/mailnews/base/search/src/nsMsgImapSearch.cpp
 20:38.40 /var/tmp/build/thunderbird-
 48f960ae7db5/mozilla/config/rules.mk:951: recipe for target
 'nsMsgImapSearch.o' failed
 20:38.40 make[4]: *** [nsMsgImapSearch.o] Error 1
 20:38.40 /var/tmp/build/thunderbird-
 48f960ae7db5/mozilla/config/recurse.mk:71: recipe for target
 'mailnews/base/search/src/target' failed
 

Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_review
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201802R  |  Actual Points:
Parent ID:  #24689 | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--

Comment (by isis):

 Replying to [comment:38 mcs]:
 > While using rbm to create some test builds, we found and fixed another
 problem: #25266.
 >
 > Speaking of test builds, selected platforms are available at the
 following location for non-developers who want to experiment with Moat:
 > https://people.torproject.org/~brade/testbuilds/moat-2018-02-15/
 >
 > As a team, we should discuss various follow up issues including:
 > * The .appspot.com one issue that was raised in comment:37

 FWIW, nothing is stopping us from setting up (an)other reflector. I'm not
 much of a sysadmin, so I just set up the easiest one (and also the one
 which would let me use it without giving it a personal credit card).

 > * Which type of bridges to return (see ticket:24432#comment:34)

 As I stated there, I think obfs4 is the most useful/least likely to get
 blocked in most contexts.

 > * The fact that BridgeDB's policy of giving out the same set of bridges
 to the same client makes it difficult to get a new set of bridges if the
 first set obtained does not work (of course it makes sense for BridgeDB to
 do that to prevent mass "scraping" of bridges).

 The set of bridges that a client will get will change every three hours
 (with the current configuration). Also, this obviously won't work if we
 completely can't bootstrap, but if there is some way to bootstrap,
 requesting new bridges over tor in the same time period will give a
 different set of bridges.

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

Re: [tor-bugs] #22614 [Applications/Tor Browser]: Make e10s/non-e10s Tor Browsers indistinguishable

[Tor Bug Tracker & Wiki]

#22614: Make e10s/non-e10s Tor Browsers indistinguishable
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff52-esr, tbb-fingerprinting,|  Actual Points:
  TorBrowserTeam201802R, tbb-no-uplift, ff60 |
  -esr-obsolete  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * keywords:  ff52-esr, tbb-fingerprinting, TorBrowserTeam201802R, tbb-no-
 uplift =>
 ff52-esr, tbb-fingerprinting, TorBrowserTeam201802R, tbb-no-uplift,
 ff60-esr-obsolete


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

Re: [tor-bugs] #22614 [Applications/Tor Browser]: Make e10s/non-e10s Tor Browsers indistinguishable

[Tor Bug Tracker & Wiki]

#22614: Make e10s/non-e10s Tor Browsers indistinguishable
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff52-esr, tbb-fingerprinting,|  Actual Points:
  TorBrowserTeam201802R, tbb-no-uplift   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * keywords:  ff52-esr, tbb-fingerprinting, TorBrowserTeam201802R =>
 ff52-esr, tbb-fingerprinting, TorBrowserTeam201802R, tbb-no-uplift


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25313 [Core Tor/Tor]: Sandbox: Caught a bad syscall attempt (syscall poll)

[Tor Bug Tracker & Wiki]

#25313: Sandbox: Caught a bad syscall attempt (syscall poll)
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 {{{
  (Sandbox) Caught a bad syscall attempt (syscall poll)
  /usr/bin/tor(+0x1a5baa)[0x560fee34ebaa]
  /lib/x86_64-linux-gnu/libc.so.6(__poll+0x10)[0x7fd66246c690]
  /lib/x86_64-linux-gnu/libc.so.6(__poll+0x10)[0x7fd66246c690]
  /lib/x86_64-linux-gnu/libc.so.6(+0x11b573)[0x7fd6624a8573]
  /lib/x86_64-linux-gnu/libc.so.6(+0x11c189)[0x7fd6624a9189]
  /lib/x86_64-linux-gnu/libc.so.6(+0x1187f2)[0x7fd6624a57f2]
  /lib/x86_64-linux-gnu/libc.so.6(+0x118a3e)[0x7fd6624a5a3e]
  /lib/x86_64-linux-gnu/libc.so.6(getpwnam_r+0x1cd)[0x7fd6624443ed]
  /lib/x86_64-linux-gnu/libc.so.6(getpwnam+0x90)[0x7fd662443d20]
  /usr/bin/tor(tor_getpwnam+0x29)[0x560fee3369e9]
  /usr/bin/tor(check_private_dir+0x9f)[0x560fee3480bf]
  /usr/bin/tor(create_keys_directory+0x34)[0x560fee29b924]
  /usr/bin/tor(init_keys+0x89)[0x560fee2439d9]
  /usr/bin/tor(do_main_loop+0x54)[0x560fee1fd5b4]
  /usr/bin/tor(tor_run_main+0x275)[0x560fee1fef25]
  /usr/bin/tor(tor_main+0x3a)[0x560fee1f836a]
  /usr/bin/tor(main+0x19)[0x560fee1f80d9]
  /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fd6623ad2b1]
  /usr/bin/tor(_start+0x2a)[0x560fee1f812a]

 }}}

 config
 {{{
 OfflineMasterKey 1
 RunAsDaemon 0
 Log notice syslog
 OutboundBindAddress xx
 SocksPort 0
 User 
 DataDirectory x
 ORPort xxx
 ORPort x
 OutboundBindAddress xxx
 DirPort x
 ControlSocket 0
 CookieAuthentication 0
 Sandbox 1
 ExitRelay 0
 ExitPolicy reject *:*
 }}}

 os: debian 9 on KVM

 reproducible with:

 0.3.2.9-1~d90.stretch+1
 0.3.3.2-alpha-1~d90.stretch+1
 0.3.4.0-alpha-dev-20180220T150525Z-1~d90.stretch+1

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

Re: [tor-bugs] #21777 [Applications/Tor Browser]: Investigate cross-compiling Tor Browser for Windows with clang-cl

[Tor Bug Tracker & Wiki]

#21777: Investigate cross-compiling Tor Browser for Windows with clang-cl
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  project  | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff60-esr,   |  Actual Points:
  GeorgKoppen201802, TorBrowserTeam201802|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:11 cypherpunks]:
 > ROFL :D Who are those?
 Everyone who hopes that Stylo will make it into the next TB release so
 that we don't have to wait yet another year just to get some decent speed
 boost.

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

Re: [tor-bugs] #22614 [Applications/Tor Browser]: Make e10s/non-e10s Tor Browsers indistinguishable

[Tor Bug Tracker & Wiki]

#22614: Make e10s/non-e10s Tor Browsers indistinguishable
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff52-esr, tbb-fingerprinting,|  Actual Points:
  TorBrowserTeam201802R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 mcs mentioned this fix will no longer be needed in TBB/ESR60 because of
 the patches landed in https://bugzilla.mozilla.org/show_bug.cgi?id=981796

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

Re: [tor-bugs] #22926 [Core Tor/Tor]: The Tor compression code can call functions that are NULL

[Tor Bug Tracker & Wiki]

#22926: The Tor compression code can call functions that are NULL
-+
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  review-group-32  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:  mikeperry|Sponsor:
-+

Comment (by teor):

 There's a lot of detail here, and I don't have time to check it all on my
 Mac.

 The original bug report was from the shadow author, who now wants to
 integrate building the tor shadow plugin into configure.ac.

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

Re: [tor-bugs] #25000 [Applications/Tor Browser]: TorBrowser's modifications to NoScript's mandatory whitelist break some webextensions when permissions are cascaded

[Tor Bug Tracker & Wiki]

#25000: TorBrowser's modifications to NoScript's mandatory whitelist break some
webextensions when permissions are cascaded
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201802R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mcs):

 Kathy and I confirmed that the proposed fix solves #23322.

 Unfortunately, it does not fix #24943. In fact, that issue occurs in Tor
 Browser 8.x even if NoScript is completely disabled and even when all of
 our bundled add-ons are disabled. The problem does not occur in Firefox
 ESR 52.6.0. All of these things seem to point to a browser patch as the
 cause.

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

Re: [tor-bugs] #17945 [Core Tor/Tor]: Stop Tor2Web connecting to (Rendezvous) Single Onion Services

[Tor Bug Tracker & Wiki]

#17945: Stop Tor2Web connecting to (Rendezvous) Single Onion Services
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor2web, tor-hs, 029-proposed, 029   |  Actual Points:
  -teor-no, needs-design, needs-proposal-maybe,  |
  single-onion, review-group-33  |
Parent ID:  #24962   | Points:  5
 Reviewer:  asn, teor|Sponsor:
-+-
Changes (by teor):

 * reviewer:  asn => asn, teor


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25312 [Core Tor/Tor]: circ: We can pick an active circuit that is marked for close

[Tor Bug Tracker & Wiki]

#25312: circ: We can pick an active circuit that is marked for close
--+---
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-cmux, tor-circuit
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 The issue lies in when we detach cicuits from the cmux.

 The function `circuitmux_get_first_active_circuit()` returns the first
 active circuit from the given cmux (attached to the channel).

 But, when we mark for close a circuit, we don't detach it from the cmux,
 it is only done "before free" so the result is that
 `cmux->policy->pick_active_circuit()` can return a marked for close
 circuit then a cell is dequeued from it and sent on the wire.

 In my experimentation, I only saw END, DROP and TRUNCATED relay commands
 being sent on the wire from a marked for close circuit. Thus, I don't
 think that is currently such a big problem but still, not that good I
 would say.

 We should assume that from the time the circuit is marked for close,
 nothing should go outbound on it from that point on.

 Possible solution would be to detach the circuit from the cmux when marked
 for close or make the active circuit function ignore closed circuit.

 Not sure at this point about 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] #18935 [Applications/Tor Browser]: MS bugs - Danger! Windows updates break everything on their way!

[Tor Bug Tracker & Wiki]

#18935: MS bugs - Danger! Windows updates break everything on their way!
--+---
 Reporter:  bugzilla  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:  duplicate
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 Tor Browser crashed on Windows 7 with 0xc0fd = STACK_OVERFLOW,
 mentioned in this ticket only:
  
   firefox.exe
   52.6.0.6607
   
   kernel32.dll
   6.1.7601.24000
   5a4996cc
   c0fd
   0004719b
 It happened when I had just switched a tab.

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

Re: [tor-bugs] #25215 [Applications/Tor Browser]: Revert #18619

[Tor Bug Tracker & Wiki]

#25215: Revert #18619
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam201802R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 Thanks. Merged to `tor-browser-52.6.0esr-8.0-2` (commit
 8ee6fdadea2a79524f1b9b9427d4daf0362a074f).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25311 [Applications/Tor Browser]: Check that #18900 is still fixed

[Tor Bug Tracker & Wiki]

#25311: Check that #18900 is still fixed
--+--
 Reporter:  arthuredelstein   |  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 https://bugzilla.mozilla.org/show_bug.cgi?id=1434666 we checked in a
 patch that is supposed to fix the problem seen in #18900. But we should
 run at least a manual regression test to see that this indeed fixed the
 bug, and we don't need our #18900 patch any more for TBB/ESR60.

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

Re: [tor-bugs] #25284 [Core Tor/Tor]: hidden-service-dir description in dir-spec should reference HSDir protovers

[Tor Bug Tracker & Wiki]

#25284: hidden-service-dir description in dir-spec should reference HSDir 
protovers
+--
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-spec, dir-spec, tor-hs  |  Actual Points:
Parent ID:  | Points:  0.1
 Reviewer:  |Sponsor:
+--
Changes (by karsten):

 * cc: metrics-team (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] #24713 [Metrics/Statistics]: Make pgTAP test work again

[Tor Bug Tracker & Wiki]

#24713: Make pgTAP test work again
+--
 Reporter:  iwakeh  |  Owner:  karsten
 Type:  defect  | Status:  accepted
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by karsten):

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


Comment:

 I worked on this and am going to post a branch here in a second.

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

Re: [tor-bugs] #24713 [Metrics/Statistics]: Make pgTAP test work again

[Tor Bug Tracker & Wiki]

#24713: Make pgTAP test work again
+--
 Reporter:  iwakeh  |  Owner:  karsten
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by karsten):

 * status:  accepted => needs_review


Comment:

 Please review [https://gitweb.torproject.org/karsten/metrics-
 web.git/commit/?h=task-24713=f6257c1644b0144c47eb4f7b22dfc1c5553876e1
 commit f6257c1 in my task-24713 branch]. The commit message contains all
 the details why this commit fixes the 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] #25013 [Applications/Tor Browser]: Move TorButton code to the tor browser repository

[Tor Bug Tracker & Wiki]

#25013: Move TorButton code to the tor browser repository
--+
 Reporter:  igt0  |  Owner:  tbb-team
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201802  |  Actual Points:
Parent ID:  #24855| Points:
 Reviewer:  gk, sysrqb, mcs,  |Sponsor:
--+
Changes (by gk):

 * keywords:  TorBrowserTeam201802R => TorBrowserTeam201802
 * status:  needs_information => needs_revision


Comment:

 Replying to [comment:17 arthuredelstein]:
 > Replying to [comment:16 igt0]:
 > > The idea is deprecate the tor button repository(we should keep it just
 for historical reasons) and move the whole tor button development to tor-
 browser.
 >
 > This was my original thinking as well, but sysrqb's investigations in
 #25260 make me wonder if we wouldn't be better off finding a way to keep
 separate repositories for torbutton and tor-launcher. Perhaps we can find
 a way to either make them system addons ("feature" XPIs), or internal JS
 modules that are copied into the tor-browser.git tree at build time.
 >
 > The advantage of maintaining separate torbutton and tor-launcher
 repositories is that we retain commit history (including the history we
 will accumulate for future commits). The tor-browser.git repository
 specifically is not so good for retaining history because we are
 constantly rebasing the patches to new versions of Firefox.

 +1 to 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] #16472 [Applications/Tor Browser]: Upgrade Binutils to 2.25+ for Tor Browser builds

[Tor Bug Tracker & Wiki]

#16472: Upgrade Binutils to 2.25+ for Tor Browser builds
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm, boklm201802  |  Actual Points:
Parent ID:  #12968| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [comment:18 boklm]:
 > Replying to [comment:17 gk]:
 > > Hm. Is that caused by Selfrando? I can't otherwise imagine we are the
 only ones hitting that while compiling Firefox given that binutils 2.27+
 and GCC 6.4.0 is not an esoteric compiler/linker combo.
 >
 > Yes, it seems to be caused by Selfrando. I started a build after
 disabling Selfrando, and the build did not fail in this case.

 Okay, let me get back to the selfrando folks with 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] #25304 [Applications/Tor Browser]: Update gcc to 6.4.0

[Tor Bug Tracker & Wiki]

#25304: Update gcc to 6.4.0
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201802,   |  Actual Points:
  boklm201802|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:1 boklm]:
 > After updating gcc to 6.4.0, gcc fails to build with this error:
 > ...
 > The gcc build is fixed when setting `DEB_BUILD_HARDENING_PIE=0` in
 `projects/gcc/build`.
 This is #20301.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-crypto, refactor, review-|  Actual Points:
  group-32   |
Parent ID:   | Points:
 Reviewer:  isis |Sponsor:
 |  Sponsor8-can
-+-

Comment (by isis):

 I have a tiny fixup patch in my `bug24658-rm-curve25519-header` branch
 (based upon ffmancera's `bug24658-xof_digest` branch above) which removes
 an unnecessary `#include "crypto_curve25519.h"` from `crypto_digest.h`
 (which was causing `rust-bindgen` to generate bindings for ''so much
 stuff''). It also adds the appropriate `#include ` to fix the
 missing resolutions.

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

Re: [tor-bugs] #25215 [Applications/Tor Browser]: Revert #18619

[Tor Bug Tracker & Wiki]

#25215: Revert #18619
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201802R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arthuredelstein):

 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] #25307 [Metrics/CollecTor]: Use `persist` package for writing bridge descriptors in sanitization module

[Tor Bug Tracker & Wiki]

#25307: Use `persist` package for writing  bridge descriptors in sanitization
module
---+---
 Reporter:  iwakeh |  Owner:  metrics-team
 Type:  enhancement| Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by karsten):

 I'm afraid I don't understand the question.

 The current behavior, IIRC, is that if a descriptor cannot be sanitized
 for any reason, it is skipped.

 What would be the new behavior?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25310 [Core Tor/Tor]: Document our policy for Rust dependencies

[Tor Bug Tracker & Wiki]

#25310: Document our policy for Rust dependencies
--+
 Reporter:  isis  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  rust, tor-doc
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:  SponsorM  |
--+
 We should document what our (experimental, subject to change) policies are
 w.r.t. new Rust dependencies in tor, somewhere in the `doc/HACKING/`
 directory.

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

Re: [tor-bugs] #5915 [Core Tor/Tor]: Write patch to make socks handshakes succeed instantly

[Tor Bug Tracker & Wiki]

#5915: Write patch to make socks handshakes succeed instantly
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client intro performance |  Actual Points:
  application experiment, tbb-wants  |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tor-client intro performance application experiment => tor-
 client intro performance application experiment, tbb-wants


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

Re: [tor-bugs] #25161 [Metrics/CollecTor]: Fix another memory problem with the webstats bulk import

[Tor Bug Tracker & Wiki]

#25161: Fix another memory problem with the webstats bulk import
---+--
 Reporter:  karsten|  Owner:  iwakeh
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 Looking at the stack trace and the input log files, I noticed that two log
 files are larger than 2G when decompressed:

 {{{
 3.2G in/webstats/archeotrichon.torproject.org/dist.torproject.org-
 access.log-20160531
 584K in/webstats/archeotrichon.torproject.org/dist.torproject.org-
 access.log-20160531.xz
 2.1G in/webstats/archeotrichon.torproject.org/dist.torproject.org-
 access.log-20160601
 404K in/webstats/archeotrichon.torproject.org/dist.torproject.org-
 access.log-20160601.xz
 }}}

 I just ran another bulk import with just those two files as import and ran
 into the same exception.

 It seems like we shouldn't attempt to decompress these files into a
 `byte[]` in `FileType.decompress`, because Java can only handle arrays
 with up to 2 billion elements:
 https://en.wikipedia.org/wiki/Criticism_of_Java#Large_arrays . Maybe we
 should work with streams there, not `byte[]`.

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

Re: [tor-bugs] #25204 [Applications/Tor Browser]: Switch security.insecure_connection_* prefs to warn users about insecure HTTP in FF60-esr

[Tor Bug Tracker & Wiki]

#25204: Switch security.insecure_connection_* prefs to warn users about insecure
HTTP in FF60-esr
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff60-esr, ux-team |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 If enabled in the next TB stable 8.0 release this would also coincide with
 the time Google enables it as well, and probably Mozilla as well.

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

Re: [tor-bugs] #25308 [- Select a component]: Onion service node pinning by default

[Tor Bug Tracker & Wiki]

#25308: Onion service node pinning by default
--+---
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by cypherpunks):

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


Comment:

 > If you plan on waiting for more testing, is there a fingerprinting
 disadvantage if some users have it enabled?

 IFIRC, and AFAIK, that's why it's not enabled by default until that
 problem is fixed, i.e. when the rest of the padding negotiation proposal
 is implemented:
 http://jqs44zhtxl2uo6gk.onion/torspec.git/tree/proposals/254-padding-
 negotiation.txt

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

Re: [tor-bugs] #23247 [Applications/Tor Browser]: Communicating security expectations for .onion: what to say about different padlock states for .onion services

[Tor Bug Tracker & Wiki]

#23247: Communicating security expectations for .onion: what to say about 
different
padlock states for .onion services
--+--
 Reporter:  isabela   |  Owner:  tbb-team
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Actually isa already answered that on the meeting pad on Feb 12:
 {{{
  [isa: is pending a task from me asked by Geko which is to create a new
 doc with the final states we are implementing and copy (cleaner version
 from what is currently linked on the ticket) then after that it should be
 planned/added for implementation at TB roadmap in Rome]
 }}}

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

Re: [tor-bugs] #25161 [Metrics/CollecTor]: Fix another memory problem with the webstats bulk import

[Tor Bug Tracker & Wiki]

#25161: Fix another memory problem with the webstats bulk import
---+--
 Reporter:  karsten|  Owner:  iwakeh
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by karsten):

 * owner:  karsten => iwakeh


Comment:

 So, even with 64G RAM I'm running into the very same issue:

 {{{
 2018-02-20 16:40:46,425 INFO o.t.c.w.SanitizeWeblogs:108 Processing logs
 for dist.torproject.org on archeotrichon.torproject.org.
 2018-02-20 16:54:39,815 ERROR o.t.c.c.CollecTorMain:71 The webstats module
 failed: null
 java.lang.OutOfMemoryError: null
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
 Method)
 at
 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
 at
 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
 at
 java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:598)
 at
 java.util.concurrent.ForkJoinTask.reportException(ForkJoinTask.java:677)
 at java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:735)
 at
 java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:160)
 at
 
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:174)
 at
 java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233)
 at
 java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
 at
 java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:496)
 at
 
org.torproject.collector.webstats.SanitizeWeblogs.findCleanWrite(SanitizeWeblogs.java:113)
 at
 
org.torproject.collector.webstats.SanitizeWeblogs.startProcessing(SanitizeWeblogs.java:90)
 at
 org.torproject.collector.cron.CollecTorMain.run(CollecTorMain.java:67)
 at
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
 at
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
 at
 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
 at
 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
 at
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
 at
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
 at java.lang.Thread.run(Thread.java:748)
 Caused by: java.lang.OutOfMemoryError: Requested array size exceeds VM
 limit
 at java.util.Arrays.copyOf(Arrays.java:3236)
 at
 java.io.ByteArrayOutputStream.grow(ByteArrayOutputStream.java:118)
 at
 java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:93)
 at
 java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:135)
 at
 org.torproject.descriptor.internal.FileType.decompress(FileType.java:109)
 at
 
org.torproject.collector.webstats.SanitizeWeblogs.lineStream(SanitizeWeblogs.java:190)
 at
 
org.torproject.collector.webstats.SanitizeWeblogs.lambda$findCleanWrite$1(SanitizeWeblogs.java:111)
 at
 
org.torproject.collector.webstats.SanitizeWeblogs$$Lambda$15/894365800.apply(Unknown
 Source)
 at
 java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:267)
 at
 java.util.TreeMap$ValueSpliterator.forEachRemaining(TreeMap.java:2897)
 at
 java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
 at
 java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:291)
 at
 java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:731)
 at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
 at
 java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
 at
 java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
 at
 java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
 2018-02-20 16:54:39,917 INFO o.t.c.c.ShutdownHook:23 Shutdown in progress
 ...
 2018-02-20 16:54:39,917 INFO o.t.c.cron.Scheduler:127 Waiting at most 10
 minutes for termination of running tasks ...
 2018-02-20 16:54:39,917 INFO o.t.c.cron.Scheduler:132 Shutdown of all
 scheduled tasks completed 

Re: [tor-bugs] #25055 [Core Tor/Tor]: string_is_valid_hostname() returns true for IPv4 addresses

[Tor Bug Tracker & Wiki]

#25055: string_is_valid_hostname() returns true for IPv4 addresses
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  IPv6 IPv4 tor-dns 032-backport   |  Actual Points:
  must-033   |
Parent ID:  #25036   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by rl1987):

 * status:  needs_revision => merge_ready


Comment:

 https://github.com/rl1987/tor/commits/bugs_25036_25055_clean

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

Re: [tor-bugs] #25013 [Applications/Tor Browser]: Move TorButton code to the tor browser repository

[Tor Bug Tracker & Wiki]

#25013: Move TorButton code to the tor browser repository
--+---
 Reporter:  igt0  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201802R |  Actual Points:
Parent ID:  #24855| Points:
 Reviewer:  gk, sysrqb, mcs,  |Sponsor:
--+---

Comment (by arthuredelstein):

 Replying to [comment:16 igt0]:
 > The idea is deprecate the tor button repository(we should keep it just
 for historical reasons) and move the whole tor button development to tor-
 browser.

 This was my original thinking as well, but sysrqb's investigations in
 #25260 make me wonder if we wouldn't be better off finding a way to keep
 separate repositories for torbutton and tor-launcher. Perhaps we can find
 a way to either make them system addons ("feature" XPIs), or internal JS
 modules that are copied into the tor-browser.git tree at build time.

 The advantage of maintaining separate torbutton and tor-launcher
 repositories is that we retain commit history (including the history we
 will accumulate for future commits). The tor-browser.git repository
 specifically is not so good for retaining history because we are
 constantly rebasing the patches to new versions of Firefox.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25309 [Metrics/CollecTor]: Use java8 datetime classes in bridgedesc module

[Tor Bug Tracker & Wiki]

#25309: Use java8 datetime classes in bridgedesc module
---+--
 Reporter:  iwakeh |  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:  metrics-2018
Actual Points: |  Parent ID:  #23752
   Points: |   Reviewer:
  Sponsor: |
---+--
 See parent.

 (This will also be a good preparation for #20983.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25308 [- Select a component]: Onion service node pinning by default

[Tor Bug Tracker & Wiki]

#25308: Onion service node pinning by default
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Hi, can you please consider enabling node pinning by default for onion
 services? https://trac.torproject.org/projects/tor/ticket/13837

 If you plan on waiting for more testing, is there a fingerprinting
 disadvantage if some users have it enabled?

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

Re: [tor-bugs] #16472 [Applications/Tor Browser]: Upgrade Binutils to 2.25+ for Tor Browser builds

[Tor Bug Tracker & Wiki]

#16472: Upgrade Binutils to 2.25+ for Tor Browser builds
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm, boklm201802  |  Actual Points:
Parent ID:  #12968| Points:
 Reviewer:|Sponsor:
--+--

Comment (by boklm):

 Replying to [comment:17 gk]:
 > Hm. Is that caused by Selfrando? I can't otherwise imagine we are the
 only ones hitting that while compiling Firefox given that binutils 2.27+
 and GCC 6.4.0 is not an esoteric compiler/linker combo.

 Yes, it seems to be caused by Selfrando. I started a build after disabling
 Selfrando, and the build did not fail in this case.

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

Re: [tor-bugs] #25074 [Core Tor/Tor]: TROVE-2018-001

[Tor Bug Tracker & Wiki]

#25074: TROVE-2018-001
---+---
 Reporter:  teor   |  Owner:  nickm
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  033-must, review-group-33  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by asn):

 * keywords:  033-must => 033-must, review-group-33
 * reviewer:  review-group-33 =>


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

Re: [tor-bugs] #25074 [Core Tor/Tor]: TROVE-2018-001

[Tor Bug Tracker & Wiki]

#25074: TROVE-2018-001
-+
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  033-must |  Actual Points:
Parent ID:   | Points:
 Reviewer:  review-group-33  |Sponsor:
-+
Changes (by asn):

 * 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

Re: [tor-bugs] #25074 [Core Tor/Tor]: TROVE-2018-001

[Tor Bug Tracker & Wiki]

#25074: TROVE-2018-001
-+
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  033-must |  Actual Points:
Parent ID:   | Points:
 Reviewer:  review-group-33  |Sponsor:
-+
Changes (by asn):

 * reviewer:   => review-group-33


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

Re: [tor-bugs] #17945 [Core Tor/Tor]: Stop Tor2Web connecting to (Rendezvous) Single Onion Services

[Tor Bug Tracker & Wiki]

#17945: Stop Tor2Web connecting to (Rendezvous) Single Onion Services
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor2web, tor-hs, 029-proposed, 029   |  Actual Points:
  -teor-no, needs-design, needs-proposal-maybe,  |
  single-onion, review-group-33  |
Parent ID:  #24962   | Points:  5
 Reviewer:  asn  |Sponsor:
-+-
Changes (by asn):

 * reviewer:   => asn


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

Re: [tor-bugs] #25304 [Applications/Tor Browser]: Update gcc to 6.4.0

[Tor Bug Tracker & Wiki]

#25304: Update gcc to 6.4.0
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201802,   |  Actual Points:
  boklm201802|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 After updating gcc to 6.4.0, gcc fails to build with this error:
 {{{
 g++ -std=gnu++98 -fno-PIE -c   -g -DIN_GCC -fno-exceptions -fno-rtti
 -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
 -Wcast-qual -Wno-format -Wm
 issing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long
 -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H
 -I. -I. -I../.././gcc -I.
 ./.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include
 -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/bid
 -I../libdecnumber -I../.././gcc/..
 /libbacktrace   -o insn-attrtab.o -MT insn-attrtab.o -MMD -MP -MF ./.deps
 /insn-attrtab.TPo insn-attrtab.c
 g++ -std=gnu++98 -fno-PIE -c   -g -DIN_GCC -fno-exceptions -fno-rtti
 -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
 -Wcast-qual -Wno-format -Wm
 issing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long
 -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H
 -I. -I. -I../.././gcc -I.
 ./.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include
 -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/bid
 -I../libdecnumber -I../.././gcc/..
 /libbacktrace   -o insn-automata.o -MT insn-automata.o -MMD -MP -MF
 ./.deps/insn-automata.TPo insn-automata.c
 g++ -std=gnu++98 -fno-PIE -c   -g -DIN_GCC -fno-exceptions -fno-rtti
 -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
 -Wcast-qual -Wno-format -Wm
 issing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long
 -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H
 -I. -I. -I../.././gcc -I.
 ./.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include
 -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/bid
 -I../libdecnumber -I../.././gcc/..
 /libbacktrace   -o insn-dfatab.o -MT insn-dfatab.o -MMD -MP -MF ./.deps
 /insn-dfatab.TPo insn-dfatab.c
 g++ -std=gnu++98 -fno-PIE -c   -g -DIN_GCC -fno-exceptions -fno-rtti
 -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
 -Wcast-qual -Wno-format -Wm
 issing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long
 -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H
 -I. -I. -I../.././gcc -I.
 ./.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include
 -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/bid
 -I../libdecnumber -I../.././gcc/..
 /libbacktrace   -o insn-latencytab.o -MT insn-latencytab.o -MMD -MP -MF
 ./.deps/insn-latencytab.TPo insn-latencytab.c
 g++ -std=gnu++98-g -DIN_GCC -fno-exceptions -fno-rtti
 -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
 -Wcast-qual -Wno-format -Wmissing-form
 at-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-
 macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -static-
 libstdc++ -static-libgcc  gc
 ov.o \
 hash-table.o ggc-none.o libcommon.a ../libcpp/libcpp.a
 ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
 ../libdecnumber/libdecnumber.a  -o
  gcov
 /usr/bin/ld.bfd.real: gcov.o: relocation R_X86_64_32 against `.rodata' can
 not be used when making a shared object; recompile with -fPIC
 gcov.o: could not read symbols: Bad value
 collect2: error: ld returned 1 exit status
 make[3]: *** [gcov] Error 1
 }}}

 The gcc build is fixed when setting `DEB_BUILD_HARDENING_PIE=0` in
 `projects/gcc/build`.

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

Re: [tor-bugs] #24879 [Applications/Tor Browser]: Set 'fetch: 1' by default for nightly builds

[Tor Bug Tracker & Wiki]

#24879: Set 'fetch: 1' by default for nightly builds
+--
 Reporter:  boklm   |  Owner:  tbb-team
 Type:  task| Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201802R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by boklm):

 * status:  needs_revision => needs_review
 * keywords:  tbb-rbm, TorBrowserTeam201802 => tbb-rbm,
   TorBrowserTeam201802R


Comment:

 Replying to [comment:2 gk]:
 > It seems to me we want to have the comment block in `rbm.local.conf`
 indented by another 2 chars?

 Actually the error was in `rbm.conf`, as the option we should set is
 `fetch` and not `var/fetch`.

 I fixed that in branch `bug_24879_v3`:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_24879_v3=0eefe1adbcd19990a94842723872dd129de1535a

 I also changed the comment in `rbm.local.conf.example` to use `if_needed`
 instead of `0`.

 This should also apply to `testbuild` when it is based on nightly.

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

Re: [tor-bugs] #20337 [Core Tor/Tor]: Support abstract namespace AF_UNIX sockets.

[Tor Bug Tracker & Wiki]

#20337: Support abstract namespace AF_UNIX sockets.
-+-
 Reporter:  yawning  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  linux, af-unix, tor-client unix- |  Actual Points:
  socket, intro  |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-
Changes (by pospeselr):

 * cc: richard@… (added)


Comment:

 This change will need to take the patch for #22794 into account when we
 get to 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] #16472 [Applications/Tor Browser]: Upgrade Binutils to 2.25+ for Tor Browser builds

[Tor Bug Tracker & Wiki]

#16472: Upgrade Binutils to 2.25+ for Tor Browser builds
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm, boklm201802  |  Actual Points:
Parent ID:  #12968| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Hm. Is that caused by Selfrando? I can't otherwise imagine we are the only
 ones hitting that while compiling Firefox given that binutils 2.27+ and
 GCC 6.4.0 is not an esoteric compiler/linker combo.

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

Re: [tor-bugs] #24879 [Applications/Tor Browser]: Set 'fetch: 1' by default for nightly builds

[Tor Bug Tracker & Wiki]

#24879: Set 'fetch: 1' by default for nightly builds
---+---
 Reporter:  boklm  |  Owner:  tbb-team
 Type:  task   | Status:
   |  needs_revision
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201802  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by gk):

 I guess this would fix test builds as well in case they are based on
 nightlies, right? boklm: could you fix up the small thing mentioned in
 comment:2? It seems I ran into it today again missing to update the tor
 browser branch for testing the fix for #23136. :(

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

Re: [tor-bugs] #25306 [Core Tor/Tor]: tor_assertion_failed_(): Bug: ../src/or/hs_service.c:1985: rotate_all_descriptors: Assertion service->desc_current failed; aborting.

[Tor Bug Tracker & Wiki]

#25306: tor_assertion_failed_(): Bug: ../src/or/hs_service.c:1985:
rotate_all_descriptors: Assertion service->desc_current failed; aborting.
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.2-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by cypherpunks):

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


Comment:

 {{{
 tor_assertion_failed_(): Bug: ../src/or/hs_service.c:1985:
 rotate_all_descriptors: Assertion service->desc_current failed; aborting.
 (on Tor 0.3.3.2-alpha )
 Bug: Assertion service->desc_current failed in rotate_all_descriptors at
 ../src/or/hs_service.c:1985. Stack trace: (on Tor 0.3.3.2-alpha )
 Bug: /usr/bin/tor(log_backtrace+0x44) [0x556042f9ade4] (on Tor
 0.3.3.2-alpha )
 Bug: /usr/bin/tor(tor_assertion_failed_+0x8d) [0x556042fb638d] (on Tor
 0.3.3.2-alpha )
 Bug: /usr/bin/tor(hs_service_run_scheduled_events+0x848)
 [0x556042f894f8] (on Tor 0.3.3.2-alpha )
 Bug: /usr/bin/tor(+0x50611) [0x556042e62611] (on Tor 0.3.3.2-alpha )
 Bug: /usr/bin/tor(+0x70ee0) [0x556042e82ee0] (on Tor 0.3.3.2-alpha )
 Bug: /usr/lib/x86_64-linux-
 gnu/libevent-2.0.so.5(event_base_loop+0x6a0) [0x7f66827aa5a0] (on Tor
 0.3.3.2-alpha )
 Bug: /usr/bin/tor(do_main_loop+0x2bc) [0x556042e6681c] (on Tor
 0.3.3.2-alpha )
 Bug: /usr/bin/tor(tor_run_main+0x275) [0x556042e67f25] (on Tor
 0.3.3.2-alpha )
 Bug: /usr/bin/tor(tor_main+0x3a) [0x556042e6136a] (on Tor
 0.3.3.2-alpha )
 Bug: /usr/bin/tor(main+0x19) [0x556042e610d9] (on Tor 0.3.3.2-alpha )
 Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)
 [0x7f66810062b1] (on Tor 0.3.3.2-alpha )
 Bug: /usr/bin/tor(_start+0x2a) [0x556042e6112a] (on Tor 0.3.3.2-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] #20549 [Metrics/CollecTor]: Make bridge descriptor sanitization more maintainable and more modular

[Tor Bug Tracker & Wiki]

#20549: Make bridge descriptor sanitization more maintainable and more modular
---+--
 Reporter:  iwakeh |  Owner:  metrics-team
 Type:  enhancement| Status:  closed
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords:  metrics-2018   |  Actual Points:
Parent ID:  #20542 | Points:
 Reviewer:  iwakeh |Sponsor:
---+--
Changes (by iwakeh):

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


Comment:

 Changes look ok, thanks!

 Well, there'll always be more steps, but let's call this ticket finished.

 I created #25307 as I'm now aware that this should be quite easy (just a
 question to clarify on that ticket).

 Closing.
 Thanks!

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

Re: [tor-bugs] #25307 [Metrics/CollecTor]: Use `persist` package for writing bridge descriptors in sanitization module

[Tor Bug Tracker & Wiki]

#25307: Use `persist` package for writing  bridge descriptors in sanitization
module
---+---
 Reporter:  iwakeh |  Owner:  metrics-team
 Type:  enhancement| Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by iwakeh):

 * status:  new => needs_information


Comment:

 The question should be answered before the coding starts.  An option is
 also to keep the current behavior and change it later.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25307 [Metrics/CollecTor]: Use `persist` package for writing bridge descriptors in sanitization module

[Tor Bug Tracker & Wiki]

#25307: Use `persist` package for writing  bridge descriptors in sanitization
module
---+--
 Reporter:  iwakeh |  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 As the summary says.

 Should the old behavior be kept:
 Quote from comment 1 in #23421:
after sanitation the descriptor is written; if one descriptor cannot be
 sanitized, it is skipped

 Shouldn't we rather store all proper sanitized descriptors?

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

Re: [tor-bugs] #16472 [Applications/Tor Browser]: Upgrade Binutils to 2.25+ for Tor Browser builds

[Tor Bug Tracker & Wiki]

#16472: Upgrade Binutils to 2.25+ for Tor Browser builds
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm, boklm201802  |  Actual Points:
Parent ID:  #12968| Points:
 Reviewer:|Sponsor:
--+--

Comment (by boklm):

 Replying to [comment:14 boklm]:
 >
 > However, after updating gcc to 6.4.0, it seems those two patches are not
 needed anymore (and make the build fail). So I think we should update both
 binutils and gcc at the same time.

 It seems I was wrong on that, I had been trying an x86_64 build instead of
 an i686 one, and on i686 the build still fails with gcc 6.4.0 with the
 same error as in comment:9.

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

Re: [tor-bugs] #25035 [Metrics/Ideas]: Create a mailing list for metrics-specific Nagios alerts

[Tor Bug Tracker & Wiki]

#25035: Create a mailing list for metrics-specific Nagios alerts
---+-
 Reporter:  karsten|  Owner:  karsten
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Ideas  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

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


Comment:

 Okay, #25216 is resolved, so that the next Onionoo warning should go to
 [https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-alerts
 metrics-alerts@]. I think that's it. And if it was not it, we can re-open
 this ticket or create a new one. Closing.

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

Re: [tor-bugs] #25216 [Internal Services/Tor Sysadmin Team]: Please direct Nagios warnings for Onionoo to metrics-alerts@

[Tor Bug Tracker & Wiki]

#25216: Please direct Nagios warnings for Onionoo to metrics-alerts@
-+
 Reporter:  karsten  |  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by karsten):

 Thank you, weasel!

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

Re: [tor-bugs] #20549 [Metrics/CollecTor]: Make bridge descriptor sanitization more maintainable and more modular (was: Implement SanitizedBridgeServerDescriptor class that encapsulates the sanitizing

[Tor Bug Tracker & Wiki]

#20549: Make bridge descriptor sanitization more maintainable and more modular
---+--
 Reporter:  iwakeh |  Owner:  metrics-team
 Type:  enhancement| Status:  merge_ready
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-2018   |  Actual Points:
Parent ID:  #20542 | Points:
 Reviewer:  iwakeh |Sponsor:
---+--
Changes (by karsten):

 * status:  needs_information => merge_ready


Comment:

 Great! Your additional changes look good to me. I made two tiny changes in
 [https://gitweb.torproject.org/karsten/metrics-db.git/log/?h=task-20549 my
 task-20549 branch] (`this.` and a whitespace change), squashed, rebased,
 and pushed to master. Setting status to merge_ready.

 Do we want to make further changes as part of this ticket? If so, can you
 start a list of next steps here? If not, can you close this ticket?
 Thanks!

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

Re: [tor-bugs] #25306 [Core Tor/Tor]: tor_assertion_failed_(): Bug: ../src/or/hs_service.c:1985: rotate_all_descriptors: Assertion service->desc_current failed; aborting.

[Tor Bug Tracker & Wiki]

#25306: tor_assertion_failed_(): Bug: ../src/or/hs_service.c:1985:
rotate_all_descriptors: Assertion service->desc_current failed; aborting.
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.2-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by cypherpunks):

 * Attachment "tor.log" added.

 tor syslog entries

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25306 [Core Tor/Tor]: tor_assertion_failed_(): Bug: ../src/or/hs_service.c:1985: rotate_all_descriptors: Assertion service->desc_current failed; aborting.

[Tor Bug Tracker & Wiki]

#25306: tor_assertion_failed_(): Bug: ../src/or/hs_service.c:1985:
rotate_all_descriptors: Assertion service->desc_current failed; aborting.
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.2-alpha
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 I got this error shortly after my computer clock jumped forward a couple
 of hours. Sadly the log is all I have.

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

Re: [tor-bugs] #25279 [Core Tor/Tor]: Stem test-full fails on master branch (was: Chutney test-full fails on master branch)

[Tor Bug Tracker & Wiki]

#25279: Stem test-full fails on master branch
--+
 Reporter:  ffmancera |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  stem, test|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

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

Re: [tor-bugs] #25279 [Core Tor/Tor]: Chutney test-full fails on master branch

[Tor Bug Tracker & Wiki]

#25279: Chutney test-full fails on master branch
--+
 Reporter:  ffmancera |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  stem, test|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * cc: atagar (added)
 * keywords:  chutney, test => stem, test


Comment:

 Those look like stem tests, not chutney.

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

Re: [tor-bugs] #24769 [Core Tor/Tor]: Increase client idle and connection timeouts to reduce network load

[Tor Bug Tracker & Wiki]

#24769: Increase client idle and connection timeouts to reduce network load
-+-
 Reporter:  teor |  Owner:
 |  mikeperry
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, dos-resistance,  |  implemented
  032-backport, 031-backport, 029-backport, 025  |  Actual Points:
  -backport-maybe, review-group-32, 033-must |
Parent ID:   | Points:  1
 Reviewer:  nickm|Sponsor:
-+-

Comment (by nickm):

 no problem; that's why we 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] #20549 [Metrics/CollecTor]: Implement SanitizedBridgeServerDescriptor class that encapsulates the sanitizing logic for bridge server descriptors

[Tor Bug Tracker & Wiki]

#20549: Implement SanitizedBridgeServerDescriptor class that encapsulates the
sanitizing logic for bridge server descriptors
---+---
 Reporter:  iwakeh |  Owner:  metrics-team
 Type:  enhancement| Status:  needs_information
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-2018   |  Actual Points:
Parent ID:  #20542 | Points:
 Reviewer:  iwakeh |Sponsor:
---+---
Changes (by iwakeh):

 * status:  needs_review => needs_information


Comment:

 Changing to needs_information also meaning 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] #3940 [Core Tor/Tor]: Allow MapAddress .exit even if AllowDotExit is 0

[Tor Bug Tracker & Wiki]

#3940: Allow MapAddress .exit even if AllowDotExit is 0
-+-
 Reporter:  sjmurdoch|  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.32
 Severity:  Normal   | Resolution:
 Keywords:  regression tor-client 032-backport   |  Actual Points:
  031-backport 029-backport 033-must review- |
  group-33   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  regression tor-client 032-backport 031-backport 029-backport
 033-must =>
 regression tor-client 032-backport 031-backport 029-backport 033-must
 review-group-33


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

Re: [tor-bugs] #25305 [Applications/Tor Browser]: Tor Browser refuses to start / XDG_CONFIG_DIRS environment variable segfaults Tor Browser

[Tor Bug Tracker & Wiki]

#25305: Tor Browser refuses to start / XDG_CONFIG_DIRS environment variable
segfaults Tor Browser
--+--
 Reporter:  adrelanos |  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 adrelanos):

 * cc: adrelanos@… (added)
 * 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] #3940 [Core Tor/Tor]: Allow MapAddress .exit even if AllowDotExit is 0

[Tor Bug Tracker & Wiki]

#3940: Allow MapAddress .exit even if AllowDotExit is 0
-+-
 Reporter:  sjmurdoch|  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.32
 Severity:  Normal   | Resolution:
 Keywords:  regression tor-client 032-backport   |  Actual Points:
  031-backport 029-backport 033-must |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  regression tor-client => regression tor-client 032-backport
 031-backport 029-backport 033-must
 * status:  reopened => needs_review
 * severity:  Blocker => Normal
 * milestone:  Tor: 0.2.3.x-final => Tor: 0.3.3.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] #20549 [Metrics/CollecTor]: Implement SanitizedBridgeServerDescriptor class that encapsulates the sanitizing logic for bridge server descriptors

[Tor Bug Tracker & Wiki]

#20549: Implement SanitizedBridgeServerDescriptor class that encapsulates the
sanitizing logic for bridge server descriptors
---+--
 Reporter:  iwakeh |  Owner:  metrics-team
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-2018   |  Actual Points:
Parent ID:  #20542 | Points:
 Reviewer:  iwakeh |Sponsor:
---+--

Comment (by iwakeh):

 This s a different approach from the tickets description.  But, I really
 like this idea and added seven more commits.  The commit comments should
 describe the details, if necessary.  The general changes are some name
 changes, like introducing `DescriptorBuilder` as builder, which we might
 reuse elsewhere.
 The new `DescriptorBuilder` also accepts appending `DescriptorBuilder`
 now.

 Please review
 [https://gitweb.torproject.org/user/iwakeh/collector.git/log/?h=task-20549
 seven commits] on the task-20549 branch.

 Maybe, we should change the title and summary to a more general "Make
 bridge descriptor sanitization more maintainable and more modular"?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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: #24854, #25268

[Tor Bug Tracker & Wiki]

Batch modification to #24854, #25268 by 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: #24854, #25268

[Tor Bug Tracker & Wiki]

Batch modification to #24854, #25268 by 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] #25305 [- Select a component]: Tor Browser refuses to start / XDG_CONFIG_DIRS environment variable segfaults Tor Browser

[Tor Bug Tracker & Wiki]

#25305: Tor Browser refuses to start / XDG_CONFIG_DIRS environment variable
segfaults Tor Browser
--+
 Reporter:  adrelanos |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 More than 6 entries (each entry is devices by a colon) will segfault Tor
 Browser. Here is a simplified minimal example that shows how to trigger
 this bug.

 Happening with both, Tor Browser {{{7.5}}} and {{{8.0a1}}} on Debian
 stretch.

 **segfaults:**

 {{{
 XDG_CONFIG_DIRS=x:x:x:x:x:x:x ./start-tor-browser.desktop --debug
 }}}

 {{{./Browser/start-tor-browser: line 370:  3249 Segmentation fault
 TOR_CONTROL_PASSWD=${TOR_CONTROL_PASSWD} ./firefox --class "Tor Browser"
 -profile TorBrowser/Data/Browser/profile.default "${@}" < /dev/null}}}

 **working:**

 {{{
 XDG_CONFIG_DIRS=x:x:x:x:x:x ./start-tor-browser.desktop --debug
 }}}

 This is to show that the existence or content of the folder is unrelated
 here.

 **Relevance:**

 Of course nobody uses {{{XDG_CONFIG_DIRS=x:x:x:x:x:x}}} as their
 {{{XDG_CONFIG_DIRS}}}.

 Real world example that is failing is in Whonix, where settings are pre-
 configured. Whonix is using:

 {{{
 XDG_CONFIG_DIRS=/usr/share/torbrowser-default-browser/:/usr/share
 /security-misc/:/usr/share/kde-apper-no-autoupdate/:/usr/share/anon-ws-
 kde-startmenu/:/usr/share/anon-apps-config/:/usr/share/open-link-
 confirmation/:/etc/xdg
 }}}

 That segfaults Tor Browser.

 firefox-esr (from Debian stretch) does not have this issue.

 #21804 was a similar issue where a long {{{XDG_CONFIG_DIRS}}} environment
 variable resulted in Tor Browser refusing to start.

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

Re: [tor-bugs] #25261 [Core Tor/Tor]: Tor connection.c file have multiple transports.h includes.

[Tor Bug Tracker & Wiki]

#25261: Tor connection.c file have multiple transports.h includes.
--+
 Reporter:  fristonio |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by nickm):

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


Comment:

 Merged in master!

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

Re: [tor-bugs] #25261 [Core Tor/Tor]: Tor connection.c file have multiple transports.h includes.

[Tor Bug Tracker & Wiki]

#25261: Tor connection.c file have multiple transports.h includes.
--+
 Reporter:  fristonio |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by nickm):

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


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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #17945, #23635, #24456

[Tor Bug Tracker & Wiki]

Batch modification to #17945, #23635, #24456 by 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

Re: [tor-bugs] #25260 [Applications/Tor Launcher]: Merge mozbuild files into tor-launcher.git

[Tor Bug Tracker & Wiki]

#25260: Merge mozbuild files into tor-launcher.git
---+---
 Reporter:  sysrqb |  Owner:  brade
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #24856 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by sysrqb):

 Replying to [comment:7 cypherpunks]:
 > Replying to [comment:6 sysrqb]:
 > > I dug a little deeper on this, and I build the patch from mozilla-
 central. It seems some changes were introduced since ESR52. 1) At build
 time all system addons are added into a file,
 > IDs of add-ons

 Yes

 > > and that file is checked at application startup[0], so we won't be
 able to simply copy the extension into browser/features/ post-build,
 > That's the goal [0] was created for.
 > > we'll need to modify this file too [1].
 > It's auto-generated, no?

 Yes
 https://dxr.mozilla.org/mozilla-central/source/browser/app/Makefile.in#110

 > > This is the situation on desktop. On mobile, I don't see where this
 file is created, so right now I think "features" are broken on mobile.
 I'll dig into this some more.
 > If you add Tb and Tl to "features", they'll become part of firefox
 build, no post-build modifications are required.
 > > [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1348981
 > > [1]
 obj-*/dist/bin/browser/chrome/browser/content/browser/built_in_addons.json
 > > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1277920
 > Generally, as Tb and Tl don't require updates, the better way to
 integrate them is mentioned in
 https://bugzilla.mozilla.org/show_bug.cgi?id=1212059#c5

 Adding the torlauncher extension into the omni.ja remains an option.
 However, considering I haven't found where the builtin-addon manifest is
 created during the mobile build process, I'm not sure system addons
 actually work on Android.

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

Re: [tor-bugs] #25095 [Core Tor/Tor]: Update dir-spec.txt with recent consensus param additions

[Tor Bug Tracker & Wiki]

#25095: Update dir-spec.txt with recent consensus param additions
---+
 Reporter:  arma   |  Owner:  dgoulet
 Type:  task   | Status:  needs_revision
 Priority:  Medium |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-spec, tor-dos  |  Actual Points:
Parent ID: | Points:
 Reviewer:  ahf|Sponsor:
---+
Changes (by ahf):

 * status:  needs_review => needs_revision
 * reviewer:   => ahf


Comment:

 I think the patch looks good, I have two questions:

 1. `DoSCircuitCreationBurst` and `DoSCircuitCreationRate` seems related.
 Is `DoSCircuitCreationRate` also per Client IP address or not? Maybe that
 is worth addressing explicitly if it is.

 2. `DoSCircuitCreationDefenseType` is a bit vaguely defined here -- what
 are the possible values this could have? From the other entries I think
 it's possible to deduct the data-type, but not for this one.

 Other than that it looks good.

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

Re: [tor-bugs] #21804 [Applications/Tor Browser]: Tor Browser refuses to start with : Corrupt redzone 0 bytes after 0x7f0503ede9d0 (size 80), byte=0x0

[Tor Bug Tracker & Wiki]

#21804: Tor Browser refuses to start with : Corrupt redzone 0 bytes 
after
0x7f0503ede9d0 (size 80), byte=0x0
--+--
 Reporter:  adrelanos |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by adrelanos):

 Replying to [comment:8 gk]:
 > (Might still be interesting to understand why this happens in the first
 place at all)

 Our environment variable {{{XDG_CONFIG_DIRS}}} had too many entries.
 Details:

 https://phabricator.whonix.org/T651#13878

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

Re: [tor-bugs] #25013 [Applications/Tor Browser]: Move TorButton code to the tor browser repository

[Tor Bug Tracker & Wiki]

#25013: Move TorButton code to the tor browser repository
--+---
 Reporter:  igt0  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201802R |  Actual Points:
Parent ID:  #24855| Points:
 Reviewer:  gk, sysrqb, mcs,  |Sponsor:
--+---

Comment (by igt0):

 The idea is deprecate the tor button repository(we should keep it just for
 historical reasons) and move the whole tor button development to tor-
 browser.


 Replying to [comment:15 gk]:
 > I am wondering what your plan is regarding the current Torbutton
 repository and where future development should happen (until we have all
 things we need in the browser and there in a non-extension-environment).
 Do you think we should get rid of the Torbutton repo as we currently have
 it and do Torbutton development directly in Tor Browser? Or what is the
 model you have in mind here?

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

Re: [tor-bugs] #21777 [Applications/Tor Browser]: Investigate cross-compiling Tor Browser for Windows with clang-cl

[Tor Bug Tracker & Wiki]

#21777: Investigate cross-compiling Tor Browser for Windows with clang-cl
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  project  | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff60-esr,   |  Actual Points:
  GeorgKoppen201802, TorBrowserTeam201802|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:10 gk]:
 > For those following along at home:
 ROFL :D Who are those? Reply here, folks!
 > https://bugzilla.mozilla.org/show_bug.cgi?id=1390583 has all the
 details.
 Those, who follow, already know you spamming that Bugzilla ticket :)
 > So far I've been able to cross-compile our ESR52-based Tor Browser code
 in a similar setup to the one we use for our shipped bundles
 It seems, x86_64-w64-mingw32/ucrt/lld/clang (not -cl ;) ) is not similar
 to stable win32 builds. ;)
 > and the result is running on a Windows 8 system.
 Why win 8? :)
 (BTW, Tom ni you about debugging on win)

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

Re: [tor-bugs] #16472 [Applications/Tor Browser]: Upgrade Binutils to 2.25+ for Tor Browser builds

[Tor Bug Tracker & Wiki]

#16472: Upgrade Binutils to 2.25+ for Tor Browser builds
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm, boklm201802  |  Actual Points:
Parent ID:  #12968| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [comment:14 boklm]:
 > In branch `bug_16472_v2` I added a commit updating binutils to 2.30:
 > https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_16472_v2=fd2706c19dad44730ef10f8d868ac965d84a65b7
 >
 > I also added a test commit adding two `tor-browser.git` patches fixing
 the build, but I am not sure that they are correct:
 > https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_16472_v2=868c0384fa306f51f5be5e16a32b6ef063ade2a9
 >
 > However, after updating gcc to 6.4.0, it seems those two patches are not
 needed anymore (and make the build fail). So I think we should update both
 binutils and gcc at the same time.

 Agreed, bumping both at the same time sounds like a good idea, especially
 if that means we don't need those additional patches.

 Have you checked about the deterministic output of the Windows bundles
 after the switch to the newer  binutils version? That's has been the main
 reason for why an update did not happen earlier (see: comment:1).

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

Re: [tor-bugs] #20301 [Applications/Tor Browser]: Bumping the compiler version to 6.2.0 breaks 64bit Tor Browser builds

[Tor Bug Tracker & Wiki]

#20301: Bumping the compiler version to 6.2.0 breaks 64bit Tor Browser builds
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Blocker  | Resolution:
 Keywords:  GeorgKoppen201610,   |  Actual Points:
  TorBrowserTeam201802, tbb-rbm, boklm201802 |
Parent ID:  #25304   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * parent:   => #25304


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

Re: [tor-bugs] #20302 [Obfuscation/FTE]: FTE compilation in our gitian setup is broken for Windows with GCC 6.2.0

[Tor Bug Tracker & Wiki]

#20302: FTE compilation in our gitian setup is broken for Windows with GCC 6.2.0
-+-
 Reporter:  gk   |  Owner:  kpdyer
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Obfuscation/FTE  |Version:
 Severity:  Blocker  | Resolution:
 Keywords:  TorBrowserTeam201802, tbb-rbm,   |  Actual Points:
  boklm201802|
Parent ID:  #25304   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * parent:   => #25304


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25304 [Applications/Tor Browser]: Update gcc to 6.4.0

[Tor Bug Tracker & Wiki]

#25304: Update gcc to 6.4.0
-+-
 Reporter:  boklm|  Owner:  tbb-team
 Type:  task | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-rbm,
 Severity:  Normal   |  TorBrowserTeam201802, boklm201802
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We should build Tor Browser using gcc 6.4.0.

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

Re: [tor-bugs] #16472 [Applications/Tor Browser]: Upgrade Binutils to 2.25+ for Tor Browser builds

[Tor Bug Tracker & Wiki]

#16472: Upgrade Binutils to 2.25+ for Tor Browser builds
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm, boklm201802  |  Actual Points:
Parent ID:  #12968| Points:
 Reviewer:|Sponsor:
--+--

Comment (by boklm):

 In branch `bug_16472_v2` I added a commit updating binutils to 2.30:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_16472_v2=fd2706c19dad44730ef10f8d868ac965d84a65b7

 I also added a test commit adding two `tor-browser.git` patches fixing the
 build, but I am not sure that they are correct:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_16472_v2=868c0384fa306f51f5be5e16a32b6ef063ade2a9

 However, after updating gcc to 6.4.0, it seems those two patches are not
 needed anymore (and make the build fail). So I think we should update both
 binutils and gcc at the same time.

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

Re: [tor-bugs] #21777 [Applications/Tor Browser]: Investigate cross-compiling Tor Browser for Windows with clang-cl

[Tor Bug Tracker & Wiki]

#21777: Investigate cross-compiling Tor Browser for Windows with clang-cl
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  project  | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff60-esr,   |  Actual Points:
  GeorgKoppen201802, TorBrowserTeam201802|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 For those following along at home:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1390583 has all the details.
 So far I've been able to cross-compile our ESR52-based Tor Browser code in
 a similar setup to the one we use for our shipped bundles and the result
 is running on a Windows 8 system.

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

Re: [tor-bugs] #18287 [Applications/Tor Browser]: Use SHA-2 signature for Tor Browser setup executables

[Tor Bug Tracker & Wiki]

#18287: Use SHA-2 signature for Tor Browser setup executables
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  enhancement | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-security, TorBrowserTeam201802  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by cypherpunks):

 Replying to [ticket:18287 gk]:
 > #17870
 > So, we are doing the same as Mozilla right now: SHA-1 signature with a
 SHA-2 code signing certificate.
 But not in Win64 builds! You should reopen that 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] #18287 [Applications/Tor Browser]: Use SHA-2 signature for Tor Browser setup executables

[Tor Bug Tracker & Wiki]

#18287: Use SHA-2 signature for Tor Browser setup executables
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  enhancement | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-security, TorBrowserTeam201802  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by cypherpunks):

 Replying to [comment:3 gk]:
 > Looking at https://bugzilla.mozilla.org/show_bug.cgi?id=1245842 it seems
 Mozilla is not dual-signing things either. Instead, if I understand it
 correctly (https://bugzilla.mozilla.org/show_bug.cgi?id=1245895), they are
 redirecting users with older systems to binaries signed with SHA1 while
 properly supported ones get SHA2 signed installers.
 This is for outdated pre-SP3 XP and pre-SP2 Vista. You shouldn't support
 Windows installations without the latest security 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

Re: [tor-bugs] #25013 [Applications/Tor Browser]: Move TorButton code to the tor browser repository

[Tor Bug Tracker & Wiki]

#25013: Move TorButton code to the tor browser repository
--+---
 Reporter:  igt0  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201802R |  Actual Points:
Parent ID:  #24855| Points:
 Reviewer:  gk, sysrqb, mcs,  |Sponsor:
--+---
Changes (by gk):

 * status:  needs_review => needs_information


Comment:

 I am wondering what your plan is regarding the current torbutton
 repository and where future development should happen (until we have all
 things we need in the browser and there in a non-extension-environment).
 Do you think we should get rid of the Torbutton repo as we currently have
 it and do Torbutton development directly in Tor Browser? Or what is the
 model you have in mind here?

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

Re: [tor-bugs] #18287 [Applications/Tor Browser]: Use SHA-2 signature for Tor Browser setup executables

[Tor Bug Tracker & Wiki]

#18287: Use SHA-2 signature for Tor Browser setup executables
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  enhancement | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-security, TorBrowserTeam201802  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by cypherpunks):

 Replying to [comment:2 gk]:
 > Today a Windows users showed up on IRC and said they needed a 64bit Tor
 Browser because the stable 32bit one is not working on Windows 10 USN due
 to missing WoW64 ("The subsystem needed to support the image type is not
 present").
 WTF is "USN"? And, yes, 32-bit apps aren't working on Linux or Windows
 64-bit without 32-bit subsystem.
 > Furthermore, it turns out that the SHA1 signature we have on our .exe
 files is not valid on that system either: it wants a SHA2 one as SHA1 ones
 have been deprecated in Windows 10 USN and giving a unknown publisher
 yellow UAC error now.
 SHA-2 where? All Firefox .exes in https://www.mozilla.org/en-
 US/firefox/new/ have the same kind of signatures as TBB.
 > I wonder what that USN version is about and whether we could skip the
 dual-signing dance with `osslsigncode` and just provide a SHA2 signature
 given that we switch soon away from supporting XP and Vista anyway.
 You've already switched to SHA-2 signatures as Firefox 44 and don't
 provide SHA-1 ones for outdated XP and Vista versions.

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

Re: [tor-bugs] #25215 [Applications/Tor Browser]: Revert #18619

[Tor Bug Tracker & Wiki]

#25215: Revert #18619
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201802R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:  TorBrowserTeam201802 => TorBrowserTeam201802R
 * status:  new => needs_review


Comment:

 `bug_25215` (https://gitweb.torproject.org/user/gk/tor-
 browser.git/commit/?h=bug_25215=8ee6fdadea2a79524f1b9b9427d4daf0362a074f)
 in my public `tor-browser` repo has the trivial revert up for review.

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

Re: [tor-bugs] #18287 [Applications/Tor Browser]: Use SHA-2 signature for Tor Browser setup executables

[Tor Bug Tracker & Wiki]

#18287: Use SHA-2 signature for Tor Browser setup executables
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  enhancement | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-security, TorBrowserTeam201802  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by gk):

 Looking at https://bugzilla.mozilla.org/show_bug.cgi?id=1245842 it seems
 Mozilla is not dual-signing things either. Instead, if I understand it
 correctly (https://bugzilla.mozilla.org/show_bug.cgi?id=1245895), they are
 redirecting users with older systems to binaries signed with SHA1 while
 properly supported ones get SHA2 signed installers.

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

Re: [tor-bugs] #18287 [Applications/Tor Browser]: Use SHA-2 signature for Tor Browser setup executables

[Tor Bug Tracker & Wiki]

#18287: Use SHA-2 signature for Tor Browser setup executables
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  enhancement | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-security, TorBrowserTeam201802  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * cc: tom (added)
 * keywords:  tbb-security => tbb-security, TorBrowserTeam201802


Comment:

 Today a Windows users showed up on IRC and said they needed a 64bit Tor
 Browser because the stable 32bit one is not working on Windows 10 USN due
 to missing WoW64 ("The subsystem needed to support the image type is not
 present"). Furthermore, it turns out that the SHA1 signature we have on
 our .exe files is not valid on that system either: it wants a SHA2 one as
 SHA1 ones have been deprecated in Windows 10 USN and giving a unknown
 publisher yellow UAC error now.

 I wonder what that USN version is about and whether we could skip the
 dual-signing dance with `osslsigncode` and just provide a SHA2 signature
 given that we switch soon away from supporting XP and Vista anyway.

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

Re: [tor-bugs] #25260 [Applications/Tor Launcher]: Merge mozbuild files into tor-launcher.git

[Tor Bug Tracker & Wiki]

#25260: Merge mozbuild files into tor-launcher.git
---+---
 Reporter:  sysrqb |  Owner:  brade
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #24856 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by cypherpunks):

 Replying to [comment:6 sysrqb]:
 > I dug a little deeper on this, and I build the patch from mozilla-
 central. It seems some changes were introduced since ESR52. 1) At build
 time all system addons are added into a file,
 IDs of add-ons
 > and that file is checked at application startup[0], so we won't be able
 to simply copy the extension into browser/features/ post-build,
 That's the goal [0] was created for.
 > we'll need to modify this file too [1].
 It's auto-generated, no?
 > This is the situation on desktop. On mobile, I don't see where this file
 is created, so right now I think "features" are broken on mobile. I'll dig
 into this some more.
 If you add Tb and Tl to "features", they'll become part of firefox build,
 no post-build modifications are required.
 > [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1348981
 > [1]
 obj-*/dist/bin/browser/chrome/browser/content/browser/built_in_addons.json
 > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1277920
 Generally, as Tb and Tl don't require updates, the better way to integrate
 them is mentioned in
 https://bugzilla.mozilla.org/show_bug.cgi?id=1212059#c5

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