Re: [tor-bugs] #25619 [Applications/Tor Browser]: The webrtc build downloads and runs a cipd program

[Tor Bug Tracker & Wiki]

#25619: The webrtc build downloads and runs a cipd program
--+--
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [ticket:25619 dcf]:
 > I haven't looked very deeply into this. I'm also experimenting with some
 changes to the webrtc build, but none that should affect this. As a first
 check, does anyone else have the `Bootstrapping cipd client` message in
 logs/webrtc-linux-x86_64.log?

 I don't have this message in my log file dating from last Friday.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25619 [Applications/Tor Browser]: The webrtc build downloads and runs a cipd program

[Tor Bug Tracker & Wiki]

#25619: The webrtc build downloads and runs a cipd program
--+--
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 While doing a build of Tor Browser, I noticed this in logs/webrtc-linux-
 x86_64.log:
 {{{
 Starting build: Sat Mar 24 00:04:29 2018
 Bootstrapping cipd client for linux-amd64 from https://chrome-infra-
 packages.appspot.com/client?platform=linux-
 amd64=git_revision:ae28364c740acff97ae118adcb2808b6cb5129c5...
 [0:02:35] Still working on:
 [0:02:35]   src/third_party/icu
 }}}

 `Bootstrapping cipd client` comes from
 
[https://chromium.googlesource.com/chromium/tools/depot_tools.git/+/e346e411d56a33575a9818310e73a66f17de3da0/cipd#67
 the cipd program] in depot_tools. I suppose it is being run somehow
 through `gclient sync`. It downloads a program and then runs it with a
 `selfupdate` argument. "cipd" seems to refer to "Chrome infra packages
 (?)".

 I'm not sure what cipd is doing, but if it's downloading software at build
 time, it could potentially break reproducibility. We are already setting
 `DEPOT_TOOLS_UPDATE=0`.

 I saw the message in logs/webrtc-linux-i686.log and logs/webrtc-linux-
 x86_64.log. I did not see it in logs/webrtc-osx-x86_64.log.

 I haven't looked very deeply into this. I'm also experimenting with some
 changes to the webrtc build, but none that should affect this. As a first
 check, does anyone else have the `Bootstrapping cipd client` message in
 logs/webrtc-linux-x86_64.log?

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by saper):

 I have a question - how do we want to keep scripts/instructions in sync
 with tor's own CI infrastructure?

 For example right now I am using libevent and openssl provided by msys64
 project, but the CI is building their own.

 Also there are some compiler flags being set in the tor project CI that I
 might want to add.

 How to keep all of this synchronized? Do we need to?

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

Re: [tor-bugs] #25549 [Core Tor/Tor]: Add tor CI config for AppVeyor

[Tor Bug Tracker & Wiki]

#25549: Add tor CI config for AppVeyor
-+
 Reporter:  isis |  Owner:  saper
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, tor-testing  |  Actual Points:
Parent ID:  #25550   | Points:
 Reviewer:   |Sponsor:  Sponsor3
-+
Changes (by saper):

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


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

Re: [tor-bugs] #25549 [Core Tor/Tor]: Add tor CI config for AppVeyor

[Tor Bug Tracker & Wiki]

#25549: Add tor CI config for AppVeyor
-+
 Reporter:  isis |  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-ci, tor-testing  |  Actual Points:
Parent ID:  #25550   | Points:
 Reviewer:   |Sponsor:  Sponsor3
-+

Comment (by saper):

 Working on it, got basic compilation using msys64 provided libraries
 working.

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

Re: [tor-bugs] #25617 [Core Tor/Tor]: unable to resolve DNS requests from control port, regression

[Tor Bug Tracker & Wiki]

#25617: unable to resolve DNS requests from control port, regression
--+
 Reporter:  starlight |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by starlight):

 er, not sure. . .2.6.something?

 Seems to me client DNS was extensively renovated along the way with an eye
 toward IPv6.  SocksPort flag NoDNSRequest is new and related I think.
 Perhaps +DNSRequest or -NoDNSRequest applied invisibly to control ports
 would fix?

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

Re: [tor-bugs] #25618 [Core Tor/Tor]: Document ISO_STREAM in the tor man page

[Tor Bug Tracker & Wiki]

#25618: Document ISO_STREAM in the tor man page
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy doc  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 Replying to [comment:1 nickm]:
 > Wait -- if that were the default, then streams would never share
 circuits, right?

 Right. I think this would be a pretty big bug if so, and we'd want to fix
 it by fixing the bug, not by documenting it.

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

Re: [tor-bugs] #25617 [Core Tor/Tor]: unable to resolve DNS requests from control port, regression

[Tor Bug Tracker & Wiki]

#25617: unable to resolve DNS requests from control port, regression
--+
 Reporter:  starlight |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 I can confirm that the above sequence happens as described.

 You say regression -- can you remind us when this used to work? :)

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

Re: [tor-bugs] #25618 [Core Tor/Tor]: Document ISO_STREAM in the tor man page

[Tor Bug Tracker & Wiki]

#25618: Document ISO_STREAM in the tor man page
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy doc  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nickm):

 Wait -- if that were the default, then streams would never share circuits,
 right?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25618 [Core Tor/Tor]: Document ISO_STREAM in the tor man page

[Tor Bug Tracker & Wiki]

#25618: Document ISO_STREAM in the tor man page
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  easy doc
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Tor applies stream isolation by default: each new origin stream gets a new
 circuit.

 This means that the default behaviour of Tor is stricter than
 IsolateDestAddr and IsolateDestPort, because each different destination
 address or port needs a new stream.

 We should document this in the tor man page under the SOCKSPort option.

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

Re: [tor-bugs] #25612 [Core Tor/Tor]: Segfault when starting Tor Raspian Stretch Light 2018-03-13 Kernel 4.9

[Tor Bug Tracker & Wiki]

#25612: Segfault when starting Tor Raspian Stretch Light 2018-03-13 Kernel 4.9
-+-
 Reporter:  ConjugateThis|  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.10
 Severity:  Normal   | Resolution:  invalid
 Keywords:  segmentation fault debian stretch|  Actual Points:
  raspian raspberry pi   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by ConjugateThis):

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


Comment:

 I had mistakenly added the full debian repo to my pi, and that was
 installed instead of the raspbian build. All is well now.

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

Re: [tor-bugs] #25603 [Applications/Tor Browser]: Update Orfox HTTPS-E Add-on

[Tor Bug Tracker & Wiki]

#25603: Update Orfox HTTPS-E Add-on
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201803  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:  tbb-mobile => tbb-mobile, TorBrowserTeam201803


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

Re: [tor-bugs] #19919 [Core Tor/Tor]: If ORPort address is publicly routable, use it to guess Address

[Tor Bug Tracker & Wiki]

#19919: If ORPort address is publicly routable, use it to guess Address
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.5.10
 Severity:  Normal   | Resolution:
 Keywords:  address-guessing config torrc|  Actual Points:
  bootsrap relay needs-analysis tarpit   |
Parent ID:  #24403   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:   => #24403


Comment:

 This bug will be easier to resolve after we do IPv6 address autodetection
 on relays.

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

Re: [tor-bugs] #25245 [Core Tor/Tor]: Crash in assert_connection_ok when changing Exit options

[Tor Bug Tracker & Wiki]

#25245: Crash in assert_connection_ok when changing Exit options
-+-
 Reporter:  toralf   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  crash, regression?, tor-exit, tor-   |  Actual Points:
  relay, ipv6, 033-must, 033-triage-20180320,|
  033-included-20180320  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by rl1987):

 I believe the following is logically equivalent (and logs more debug
 info):
 *
 https://github.com/rl1987/tor/commit/7fcca6bd61a00fd9eaae246914155a4af5bd7a9d
 *
 https://github.com/rl1987/tor/commit/69bcd164ee9ae181973efbaba8a68e7066defd81

 This one checks if we have edge connection first and if so, checks if it
 is exit connection.

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

Re: [tor-bugs] #24832 [Core Tor/Nyx]: Drop 'measured' bandwidth from nyx

[Tor Bug Tracker & Wiki]

#24832: Drop 'measured' bandwidth from nyx
--+
 Reporter:  atagar|  Owner:  atagar
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by atagar):

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


Comment:

 Thanks Guinness! Pushed.

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

Re: [tor-bugs] #23234 [Core Tor/Tor]: Possible problem with bootstrapping logic (Problem bootstrapping. Stuck at 53%: Loading relay descriptors. (No route to host; NOROUTE; count 7; recommendation war

[Tor Bug Tracker & Wiki]

#23234: Possible problem with bootstrapping logic (Problem bootstrapping. Stuck 
at
53%: Loading relay descriptors. (No route to host; NOROUTE; count 7;
recommendation warn)
-+-
 Reporter:  s7r  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  bootstrap, dirguard, bridge, needs-  |  Actual Points:
  insight, 031-backport, 033-triage-20180320,|
  033-removed-20180320   |
Parent ID:  #21969   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Replying to [comment:4 teor]:
 > This will probably be resolved when we fix #21969.

 Agreed. In fact, it might even be called a duplicate of it.

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

Re: [tor-bugs] #24832 [Core Tor/Nyx]: Drop 'measured' bandwidth from nyx

[Tor Bug Tracker & Wiki]

#24832: Drop 'measured' bandwidth from nyx
--+
 Reporter:  atagar|  Owner:  atagar
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by Guinness):

 Hi !

 Here is my patched version:
  1) Remove the measured bandwidth
  2) Display if possible the observed bandwidth.

 The commit can be found here :
 
https://git.oudin.ml/Guinness/nyx/commit/4de3324f12b0b8e28be77d69712fd7eb33b46d3d

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201803R,  |  Actual Points:
  boklm201803|
Parent ID:  #12968   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:59 boklm]:
 > We reverted this patch in tbb-8.0a5-build2, as it might be the cause for
 non-reproducible Windows build.
 Details?
 > I was previously able to reproduce a Windows build using binutils 2.30.
 I will check if I can reproduce the build with 2.29.1 on my machine, and
 if not we can look at switching to binutils 2.30 with a patch to fix the
 crash.
 They can do 2.30.1 if you ask.

 BTW, it's now possible to download `xz` instead of `bz2`.
 Also
 {{{
   # XXX: This is needed due to bug 10102.
   sed 's/= extern_rt_rel_d;/= extern_rt_rel_d;\n  memset (extern_rt_rel_d,
 0, PE_IDATA5_SIZE);/' -i ld/pe-dll.c
 }}}
 is not needed since https://sourceware.org/git/?p=binutils-
 gdb.git;a=commit;h=8d5c4b7bfdfa5f2b40fa056132823c8e9497dc72

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

Re: [tor-bugs] #25458 [Applications/Tor Browser]: UI customization half-broken in Tor Browser 8.0a3

[Tor Bug Tracker & Wiki]

#25458: UI customization half-broken in Tor Browser 8.0a3
-+-
 Reporter:  viktorj  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-regression,  |  Actual Points:
  TorBrowserTeam201803   |
Parent ID:  #25147   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Not sure how related but BTW the entire UI becomes sometimes completely
 unresponsive, and one has to wait quiet a bit before it gets back to
 normal.

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

Re: [tor-bugs] #25245 [Core Tor/Tor]: Crash in assert_connection_ok when changing Exit options

[Tor Bug Tracker & Wiki]

#25245: Crash in assert_connection_ok when changing Exit options
-+-
 Reporter:  toralf   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  crash, regression?, tor-exit, tor-   |  Actual Points:
  relay, ipv6, 033-must, 033-triage-20180320,|
  033-included-20180320  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Replying to [comment:4 rl1987]:
 > I tried untangling the assert statement for better debuggability:
 > *
 https://github.com/rl1987/tor/commit/ebd1fda4b16bb169718554e112ede315b9601c61

 I think this patch is not right. That is, the new more debuggable version
 is a different set of asserts than the original.

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

Re: [tor-bugs] #25386 [Core Tor/Tor]: fix rust tests

[Tor Bug Tracker & Wiki]

#25386: fix rust tests
-+-
 Reporter:  Hello71  |  Owner:  Hello71
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, tor-test, 033-backport,|  Actual Points:
  review-group-34|
Parent ID:   | Points:  3
 Reviewer:  isis |Sponsor:
 |  Sponsor8-can
-+-

Comment (by Hello71):

 rebased on master, added changes file

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

Re: [tor-bugs] #24857 [Core Tor/Tor]: tor 0.3.1.9 100% cpu load

[Tor Bug Tracker & Wiki]

#24857: tor 0.3.1.9 100% cpu load
-+-
 Reporter:  Eugene646|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.9
 Severity:  Normal   | Resolution:
 Keywords:  cpu, windows, linux, performance,|  Actual Points:
  regression |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 > it looks like a dumb mingw implementation of some function

 {{{
 #ifdef _WIN32
 /* On Windows, unlink won't work on a file if the file is actively
 mmap()ed.
  * That forces us to be less aggressive about unlinking files, and causes
 other
  * changes throughout our logic.
  */
 #define MUST_UNMAP_TO_UNLINK
 #endif /* defined(_WIN32) */
 }}}
 {{{
 #ifdef MUST_UNMAP_TO_UNLINK
   /* If we can't unlink the files that we're still using, then we need to
* tell the storagedir backend to allow far more files than this
 consensus
* cache actually wants, so that it can hold files which, from this
 cache's
* perspective, have become useless.
*/
 #define VERY_LARGE_STORAGEDIR_LIMIT (1000*1000)
   storagedir_max_entries = VERY_LARGE_STORAGEDIR_LIMIT;
 #else /* !(defined(MUST_UNMAP_TO_UNLINK)) */
   /* Otherwise, we can just tell the storagedir to use the same limits
* as this cache. */
   storagedir_max_entries = max_entries;
 #endif /* defined(MUST_UNMAP_TO_UNLINK) */
 }}}
 {{{
 get_max_age_to_cache(void)
 {
   const int32_t DEFAULT_MAX_AGE_TO_CACHE = 8192;
   const int32_t MIN_MAX_AGE_TO_CACHE = 0;
   const int32_t MAX_MAX_AGE_TO_CACHE = 8192;
   const char MAX_AGE_TO_CACHE_NAME[] = "max-consensus-age-to-cache-for-
 diff";

   const or_options_t *options = get_options();

   if (options->MaxConsensusAgeForDiffs) {
 const int v = options->MaxConsensusAgeForDiffs;
 if (v >= MAX_MAX_AGE_TO_CACHE * 3600)
   return MAX_MAX_AGE_TO_CACHE;
 else
   return v;
   }

   /* The parameter is in hours, so we multiply */
   return 3600 * networkstatus_get_param(NULL,
 MAX_AGE_TO_CACHE_NAME,
 DEFAULT_MAX_AGE_TO_CACHE,
 MIN_MAX_AGE_TO_CACHE,
 MAX_MAX_AGE_TO_CACHE);
 }
 }}}

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

Re: [tor-bugs] #24857 [Core Tor/Tor]: tor 0.3.1.9 100% cpu load

[Tor Bug Tracker & Wiki]

#24857: tor 0.3.1.9 100% cpu load
-+-
 Reporter:  Eugene646|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.9
 Severity:  Normal   | Resolution:
 Keywords:  cpu, windows, linux, performance,|  Actual Points:
  regression |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

 * keywords:  cpu, windows, linux => cpu, windows, linux, performance,
 regression
 * version:  Tor: 0.3.2.9 => Tor: 0.3.1.9
 * milestone:  Tor: 0.3.4.x-final => Tor: 0.3.3.x-final


Comment:

 It's a regression, started from 0.3.1.x, and it looks like a dumb mingw
 implementation of some function, used in consdiff. #24826 didn't fix it.

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

Re: [tor-bugs] #24527 [Applications/Tor Launcher]: Inform users in Tor Launcher of which settings are best for them based on their country

[Tor Bug Tracker & Wiki]

#24527: Inform users in Tor Launcher of which settings are best for them based 
on
their country
---+---
 Reporter:  hellais|  Owner:  brade
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by cypherpunks):

 Replying to [comment:5 cypherpunks]:
 > If there's a place to tell users in for example China that Tor is
 unlikely to work in their country, maybe on the download page? But it
 isn't a dynamic page.
 To the best of my knowledge meek-amazon does work in China and it's what
 is recommended on irc when someone from China wants their tor to work.
 Also I guess most Chinese people download their Tor Browser from Github (I
 tested at the time in 2017 with a proxy in mainland China and I found that
 Github didn't censor TB (the gettorbrowser repository), unlike something
 like this: `https://qz.com/718465/chinas-fierce-censors-try-a-new-tactic-
 with-github-asking-nicely/`
 
[[Image(https://web.archive.org/web/200139239209390239230294439439944398349849843984398439if_/https://i.imgtc.com/uEO7sYR.jpg)]]
 but it could well be the case that this has changed).

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

Re: [tor-bugs] #25614 [Core Tor/Tor]: tor sets `TOR_PT_EXIT_ON_STDIN_CLOSE=1` only for server transports, not client transports

[Tor Bug Tracker & Wiki]

#25614: tor sets `TOR_PT_EXIT_ON_STDIN_CLOSE=1` only for server transports, not
client transports
--+--
 Reporter:  dcf   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 http://www.drdobbs.com/a-safer-alternative-to-terminateprocess/184416547

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

Re: [tor-bugs] #18218 [Applications/Tor Browser]: The certificate is not trusted because the issuer certificate is unknown. (Error code: sec_error_unknown_issuer)

[Tor Bug Tracker & Wiki]

#18218: The certificate is not trusted because the issuer certificate is 
unknown.
(Error code: sec_error_unknown_issuer)
--+--
 Reporter:  bugzilla  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Because of the bug in Firefox, Tor Browser can fall into undesirable
 state, preventing browsing of certain sites, e.g.
 https://observatory.mozilla.org/analyze/msdn.microsoft.com states that
 > HTTP Strict Transport Security (HSTS) header cannot be set, as site
 contains an invalid certificate chain
 but when it is set anyway, Tor Browser shows
 > Your connection is not secure
 > The owner of msdn.microsoft.com has configured their website improperly.
 To protect your information from being stolen, Tor Browser has not
 connected to this website.
 > This site uses HTTP Strict Transport Security (HSTS) to specify that Tor
 Browser may only connect to it securely. As a result, it is not possible
 to add an exception for this certificate.

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

Re: [tor-bugs] #24527 [Applications/Tor Launcher]: Inform users in Tor Launcher of which settings are best for them based on their country

[Tor Bug Tracker & Wiki]

#24527: Inform users in Tor Launcher of which settings are best for them based 
on
their country
---+---
 Reporter:  hellais|  Owner:  brade
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by cypherpunks):

 The degree of censorship often varies more within a country between
 networks than between countries. Consider the typical user (many/most
 censored Tor users) on a restrictive surveilled network but in a country
 without filtering at the tier 1 Internet backbone level. If Tor Launcher
 tells them Tor works fine for them without bridges that is a false
 statement, and if it auto-selects vanilla Tor with no bridges that is
 unhelpful and useless at best.

 Or someone could be in a country with national DPI but using a network
 whose route to the Internet is already tunneled through the DPI.

 If there's a place to tell users in for example China that Tor is unlikely
 to work in their country, maybe on the download page? But it isn't a
 dynamic page.

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

Re: [tor-bugs] #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:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201803R,  |  Actual Points:
  boklm201803|
Parent ID:  #12968   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

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


Comment:

 We reverted this patch in tbb-8.0a5-build2, as it might be the cause for
 non-reproducible Windows build.

 I was previously able to reproduce a Windows build using binutils 2.30. I
 will check if I can reproduce the build with 2.29.1 on my machine, and if
 not we can look at switching to binutils 2.30 with a patch to fix the
 crash.

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

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

[Tor Bug Tracker & Wiki]

#25483: Windows reproducible build of snowflake
---+
 Reporter:  arlolra|  Owner:  (none)
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #19001 | Points:
 Reviewer: |Sponsor:
---+
Changes (by boklm):

 * cc: boklm (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] #25483 [Obfuscation/Snowflake]: Windows reproducible build of snowflake

[Tor Bug Tracker & Wiki]

#25483: Windows reproducible build of snowflake
---+
 Reporter:  arlolra|  Owner:  (none)
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #19001 | Points:
 Reviewer: |Sponsor:
---+

Comment (by gk):

 FWIW: I am in contact with thakis who managed to get this work done. If
 you have any questions I should pass to them let me know. See:
 https://groups.google.com/a/chromium.org/forum/#!msg/chromium-
 dev/cIA9fBb9vBE/73cOvZu9BQAJ for the official announcement and further
 useful information.

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

Re: [tor-bugs] #24857 [Core Tor/Tor]: tor 0.3.1.9 100% cpu load

[Tor Bug Tracker & Wiki]

#24857: tor 0.3.1.9 100% cpu load
-+
 Reporter:  Eugene646|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.2.9
 Severity:  Normal   | Resolution:
 Keywords:  cpu, windows, linux  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by Eugene646):

 Still happens with 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