Re: [tor-bugs] #23357 [Core Tor/Tor]: Build with non-Cross-DSO CFI

[Tor Bug Tracker & Wiki]

#23357: Build with non-Cross-DSO CFI
+--
 Reporter:  shawn.webb  |  Owner:  (none)
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  security, defence-in-depth  |  Actual Points:
Parent ID:  | Points:  1.0
 Reviewer:  |Sponsor:
+--

Comment (by shawn.webb):

 > When we configure with a recent clang/llvm and --enable-cfi, then
 compile .o files and link them together into the tor binary, does non-
 Cross-DSO CFI work for that binary?

 Yup. One problem with trying to use CFI with both static and dynamic
 libraries is that you need to use llvm-ar, llvm-nm, and llvm-objdump as
 your ar, nm, and objdump applications. This is because compiling with CFI
 will cause clang to output intermediate object files as LLVM bitcode files
 instead of ELF object files. The ar, nm, and objdump applications that
 come on most (all?) operating systems only support ELF. Essentially, the
 whole compiler toolchain must be switched over to the entire llvm tool
 suite.

 So, what I can do, is expand the patch to apply the CFLAGS and LDFLAGS to
 more of the applications (rather than just tor). This way, we skip
 applying CFI to the library code (even though the libraries in the
 codebase get statically linked).

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

Re: [tor-bugs] #23357 [Core Tor/Tor]: Build with non-Cross-DSO CFI

[Tor Bug Tracker & Wiki]

#23357: Build with non-Cross-DSO CFI
+--
 Reporter:  shawn.webb  |  Owner:  (none)
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  security, defence-in-depth  |  Actual Points:
Parent ID:  | Points:  1.0
 Reviewer:  |Sponsor:
+--

Comment (by teor):

 I'm going to drop the discussion about DSOs, because it doesn't answer my
 question, or move us towards getting this patch revised and merged.

 Here is my original question:

 Replying to [comment:1 teor]:
 > Why do we only enable this feature for tor itself?
 > I think it would also be useful to have it enabled for:
 > * fuzzing
 > * unit tests

 Let me try to clarify what I meant:

 When we configure with a recent clang/llvm and `--enable-cfi`, then
 compile `.o` files and link them together into the `tor` binary, does non-
 Cross-DSO CFI work for that binary?

 If so, how do we get non-Cross-DSO CFI working for the other binaries that
 the tor makefiles generate? In particular, how can we get them working for
 the `test` and `fuzz_*` binaries?

 Is it simpler just to enable non-Cross-DSO CFI for all the binaries that
 the tor makefiles generate, so we don't miss any?

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

Re: [tor-bugs] #23357 [Core Tor/Tor]: Build with non-Cross-DSO CFI

[Tor Bug Tracker & Wiki]

#23357: Build with non-Cross-DSO CFI
+--
 Reporter:  shawn.webb  |  Owner:  (none)
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  security, defence-in-depth  |  Actual Points:
Parent ID:  | Points:  1.0
 Reviewer:  |Sponsor:
+--

Comment (by shawn.webb):

 $ ldd src/or/tor
 src/or/tor:
 libz.so.6 => /lib/libz.so.6 (0x50c47ffd000)
 libm.so.5 => /lib/libm.so.5 (0x50c06cb9000)
 libevent-2.1.so.6 => /usr/local/lib/libevent-2.1.so.6
 (0x50c48018000)
 libssl.so.43 => /usr/lib/libssl.so.43 (0x50c48267000)
 libcrypto.so.41 => /lib/libcrypto.so.41 (0x50c482c7000)
 liblzma.so.5 => /usr/lib/liblzma.so.5 (0x50c484b1000)
 libthr.so.3 => /lib/libthr.so.3 (0x50c06c87000)
 libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x50c484dc000)
 libc.so.7 => /lib/libc.so.7 (0x50c06ce9000)
 libelf.so.2 => /lib/libelf.so.2 (0x50c484e1000)
 libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x50c484fb000)

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

Re: [tor-bugs] #23357 [Core Tor/Tor]: Build with non-Cross-DSO CFI

[Tor Bug Tracker & Wiki]

#23357: Build with non-Cross-DSO CFI
+--
 Reporter:  shawn.webb  |  Owner:  (none)
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  security, defence-in-depth  |  Actual Points:
Parent ID:  | Points:  1.0
 Reviewer:  |Sponsor:
+--

Comment (by shawn.webb):

 "DSO" is a generic term. For Windows, DSO means ".dll". For *nix, it means
 ".so". For OSX, it means ".dylib".

 DSO stands for "Dynamic Shared Object." Just a fancy way to genericize the
 term for a .dll, .so, .dylib, etc.

 Tor does use DSOs. :)

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

Re: [tor-bugs] #23357 [Core Tor/Tor]: Build with non-Cross-DSO CFI

[Tor Bug Tracker & Wiki]

#23357: Build with non-Cross-DSO CFI
+--
 Reporter:  shawn.webb  |  Owner:  (none)
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  security, defence-in-depth  |  Actual Points:
Parent ID:  | Points:  1.0
 Reviewer:  |Sponsor:
+--

Comment (by teor):

 Tor doesn't use DSOs for its fuzzing and unit testing code, only for
 dependent libraries.
 I've just checked, and there are no DSOs (dylib, so) in my build tree, nor
 any in my local tor install.

 So can we please enable this across all the code compiled by tor's
 configure?

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

Re: [tor-bugs] #23357 [Core Tor/Tor]: Build with non-Cross-DSO CFI

[Tor Bug Tracker & Wiki]

#23357: Build with non-Cross-DSO CFI
+--
 Reporter:  shawn.webb  |  Owner:  (none)
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  security, defence-in-depth  |  Actual Points:
Parent ID:  | Points:  1.0
 Reviewer:  |Sponsor:
+--

Comment (by shawn.webb):

 I wouldn't enable CFI across the entire codebase right now. This patch is
 specifically for non-Cross-DSO CFI.

 Cross-DSO CFI requires a whole heck of a lot more work, including explicit
 support from the RTLD. Once I get Cross-DSO CFI support working in
 HardenedBSD (an ongoing effort), I'll likely submit a follow-up patch
 here.

 I don't know of any operating system today that supports Cross-DSO CFI.

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

Re: [tor-bugs] #23347 [Core Tor/Tor]: Using bridges is not working anymore with tor on master

[Tor Bug Tracker & Wiki]

#23347: Using bridges is not working anymore with tor on master
--+
 Reporter:  gk|  Owner:  teor
 Type:  defect| Status:
  |  needs_review
 Priority:  Very High |  Milestone:  Tor:
  |  0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bootstrap, tor-bridge-client  |  Actual Points:  0.5
Parent ID:| Points:  0.5
 Reviewer:  isis  |Sponsor:
--+

Comment (by isis):

 * `435952538` LGTM
 * `61227b7b0` LGTM
 * `ea662f00d` LGTM
 * `836cc60d4` LGTM

 FWIW, [https://travis-ci.org/isislovecruft/tor/builds/269821789 clang
 builds are broken], but that's not your fault, it appears to be from
 commit `6eb9de1b8c` where there's now two `typedef struct
 response_handler_args_t`s in `src/or/directory.h`. I made #23358 for this.

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

Re: [tor-bugs] #23358 [Core Tor/Tor]: Multiple definitions of `response_handler_args_t` in src/or/directory.h are breaking clang builds

[Tor Bug Tracker & Wiki]

#23358: Multiple definitions of `response_handler_args_t` in src/or/directory.h 
are
breaking clang builds
--+
 Reporter:  isis  |  Owner:  isis
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:  .2
 Reviewer:|Sponsor:
--+
Changes (by isis):

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


Comment:

 This was fixed in `b1cb1686`.

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

Re: [tor-bugs] #23358 [Core Tor/Tor]: Multiple definitions of `response_handler_args_t` in src/or/directory.h are breaking clang builds

[Tor Bug Tracker & Wiki]

#23358: Multiple definitions of `response_handler_args_t` in src/or/directory.h 
are
breaking clang builds
--+
 Reporter:  isis  |  Owner:  isis
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  .2
 Reviewer:|Sponsor:
--+

Comment (by teor):

 I think this was fixed in #23335?

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

Re: [tor-bugs] #23357 [Core Tor/Tor]: Build with non-Cross-DSO CFI

[Tor Bug Tracker & Wiki]

#23357: Build with non-Cross-DSO CFI
+--
 Reporter:  shawn.webb  |  Owner:  (none)
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  security, defence-in-depth  |  Actual Points:
Parent ID:  | Points:  1.0
 Reviewer:  |Sponsor:
+--

Comment (by teor):

 We could make `--enable-cfi` enable CFI across the entire Tor codebase and
 tests and everything else we compile at the same time.

 I can't see why we'd want to selectively disable it, unless there's code
 that does some really weird things to the stack.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23358 [Core Tor/Tor]: Multiple definitions of `response_handler_args_t` in src/or/directory.h are breaking clang builds

[Tor Bug Tracker & Wiki]

#23358: Multiple definitions of `response_handler_args_t` in src/or/directory.h 
are
breaking clang builds
--+
 Reporter:  isis  |  Owner:  isis
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:  .2|   Reviewer:
  Sponsor:|
--+
 [https://travis-ci.org/isislovecruft/tor/jobs/269821792#L1704 Travis
 caught a warning from clang] that we defined multiple
 `response_handler_args_t` in `src/or/directory.h`. This appears to stem
 from commit `6eb9de1b8c` from #17242, where we made the type public, but
 never removed the old typedef.

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

Re: [tor-bugs] #23357 [Core Tor/Tor]: Build with non-Cross-DSO CFI

[Tor Bug Tracker & Wiki]

#23357: Build with non-Cross-DSO CFI
+--
 Reporter:  shawn.webb  |  Owner:  (none)
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  security, defence-in-depth  |  Actual Points:
Parent ID:  | Points:  1.0
 Reviewer:  |Sponsor:
+--

Comment (by shawn.webb):

 Agreed. Should we keep `--enable-cfi`, though? What do you think would be
 the best approach?

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

Re: [tor-bugs] #23357 [Core Tor/Tor]: Build with non-Cross-DSO CFI

[Tor Bug Tracker & Wiki]

#23357: Build with non-Cross-DSO CFI
+--
 Reporter:  shawn.webb  |  Owner:  (none)
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  security, defence-in-depth  |  Actual Points:
Parent ID:  | Points:  1.0
 Reviewer:  |Sponsor:
+--

Comment (by teor):

 I still think we should enable this while fuzzing and while unit testing.
 It would be embarrassing to release a remote code execution that we could
 have detected using these options while fuzzing, and even more so for unit
 tests.

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

Re: [tor-bugs] #23357 [Core Tor/Tor]: Build with non-Cross-DSO CFI

[Tor Bug Tracker & Wiki]

#23357: Build with non-Cross-DSO CFI
+--
 Reporter:  shawn.webb  |  Owner:  (none)
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  security, defence-in-depth  |  Actual Points:
Parent ID:  | Points:  1.0
 Reviewer:  |Sponsor:
+--

Comment (by shawn.webb):

 CFLAGS isn't set by that point, so autoconf will complain with an error
 that `+=` was used instead of `=`.

 I would probably leave this as a separate flag, given this needs both
 explicit compiler and linker support. CFI is still under development by
 the clang/llvm folks, too.

 As an FYI, I've committed this patch to the HardenedBSD ports tree in case
 anyone wants to play with it on HardenedBSD 12-CURRENT/amd64. I'm about to
 deploy it on my public relay, which also serves as a transparent proxy for
 my entire home LAN.

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

Re: [tor-bugs] #23357 [Core Tor/Tor]: Build with non-Cross-DSO CFI

[Tor Bug Tracker & Wiki]

#23357: Build with non-Cross-DSO CFI
+--
 Reporter:  shawn.webb  |  Owner:  (none)
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  security, defence-in-depth  |  Actual Points:
Parent ID:  | Points:  1.0
 Reviewer:  |Sponsor:
+--
Changes (by teor):

 * keywords:   => security, defence-in-depth
 * status:  new => needs_revision
 * points:   => 1.0
 * milestone:   => Tor: 0.3.2.x-final


Comment:

 Thanks for this patch!

 I think we might want this enabled for our debug and development builds.
 So we might want to add it to `--enable-fragile-hardening`.

 Here is a quick review:

 Is there a way of enabling this feature if it's supported by the compiler,
 but disabling it otherwise?

 Why do we only enable this feature for tor itself?
 I think it would also be useful to have it enabled for:
 * fuzzing
 * unit tests

 Should this line say `+=`?
 {{{
 src_or_tor_CFLAGS = -flto -fvisibility=hidden -fsanitize=cfi
 }}}

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

Re: [tor-bugs] #23357 [Core Tor/Tor]: Build with non-Cross-DSO CFI

[Tor Bug Tracker & Wiki]

#23357: Build with non-Cross-DSO CFI
--+
 Reporter:  shawn.webb|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by shawn.webb):

 * Attachment "tor-cfi-r01.patch" 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

[tor-bugs] #23357 [Core Tor/Tor]: Build with non-Cross-DSO CFI

[Tor Bug Tracker & Wiki]

#23357: Build with non-Cross-DSO CFI
--+
 Reporter:  shawn.webb|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Control Flow Integrity is an exploit mitigation. clang/llvm has a CFI
 implementation that can be used on hardened operating systems like
 HardenedBSD.

 When lld is the compiler, non-Cross-DSO CFI from clang/llvm can be used.
 I've tested this on HardenedBSD with a very basic configuration.

 Attached is a candidate patch for enabling non-Cross-DSO CFI for the core
 Tor application.

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

Re: [tor-bugs] #23277 [Core Tor/Tor]: ApplicationControlSocket: the way for apps to control Tor

[Tor Bug Tracker & Wiki]

#23277: ApplicationControlSocket: the way for apps to control Tor
--+--
 Reporter:  yurivict271   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by yurivict271):

 This **is** a new feature suggestion.

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

Re: [tor-bugs] #22692 [Applications/Tor Browser]: Backport Linux content sandboxing from Firefox 54

[Tor Bug Tracker & Wiki]

#22692: Backport Linux content sandboxing from Firefox 54
-+-
 Reporter:  jld  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  TorBrowserTeam201708,|  Actual Points:
  GeorgKoppen201708  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by ah@…):

 I added a mremap() workaround to selfrando, release tb-v0.3.3 should fix
 these crashes.

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

Re: [tor-bugs] #22818 [Core Tor/Tor]: Improve documentation for building Tor with Rust

[Tor Bug Tracker & Wiki]

#22818: Improve documentation for building Tor with Rust
+--
 Reporter:  chelseakomlo|  Owner:  (none)
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.3.1.2-alpha
 Severity:  Normal  | Resolution:
 Keywords:  rust tor-build docs rust-pilot  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:  SponsorZ
+--
Changes (by isis):

 * status:  new => needs_review
 * version:  Tor: unspecified => Tor: 0.3.1.2-alpha
 * points:   => 1
 * sponsor:   => SponsorZ
 * milestone:  Tor: unspecified => Tor: 0.3.1.x-final
 * keywords:  rust tor-build docs => rust tor-build docs rust-pilot


Comment:

 I added a `doc/HACKING/CodingStandardsRust.md` and a
 `doc/HACKING/GettingStartedRust.md` in my `bug22818`
 [https://gitweb.torproject.org/user/isis/tor.git/log/?h=bug22818 branch].

 I probably missed or didn't think of plenty of things, so if you think of
 something please let me know.  (I don't think we need to think of
 ''everything'' now… we can add more stuff as we realise 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] #23347 [Core Tor/Tor]: Using bridges is not working anymore with tor on master

[Tor Bug Tracker & Wiki]

#23347: Using bridges is not working anymore with tor on master
--+
 Reporter:  gk|  Owner:  teor
 Type:  defect| Status:
  |  needs_review
 Priority:  Very High |  Milestone:  Tor:
  |  0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bootstrap, tor-bridge-client  |  Actual Points:  0.5
Parent ID:| Points:  0.5
 Reviewer:  isis  |Sponsor:
--+
Changes (by isis):

 * reviewer:   => isis


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

Re: [tor-bugs] #14744 [Applications/GetTor]: Automate upload of latest Tor Browser to cloud services

[Tor Bug Tracker & Wiki]

#14744: Automate upload of latest Tor Browser to cloud services
-+--
 Reporter:  ilv  |  Owner:  ilv
 Type:  defect   | Status:  reopened
 Priority:  High |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by arma):

 Replying to [comment:10 teor]:
 > The current links are for 7.0.2 (Windows, macOS), and 7.0.3 (Linux).
 Could skipping 7.0.3 for Windows and macOS have confused the bot?

 A fine question.

 > What version should we show in the first paragraph when different
 platforms have different versions?

 Option A would be to list one, two, or three versions, depending on how
 many there are.

 Option B would be to stop listing "a" version, since it's clear sometimes
 there is no single version.

 Option C would be to lobby the tor browser team to stop doing
 unsynchronized version bumps between platforms.

 Option A would be the least invasive out of these.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23356 [Obfuscation/Snowflake]: proxy-go starts using 100% CPU when network is disconnected

[Tor Bug Tracker & Wiki]

#23356: proxy-go starts using 100% CPU when network is disconnected
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 A power outage disconnected the network of a laptop on which I was running
 proxy-go. The laptop battery kept the computer running until the power
 came back on, but the network was still down. When I checked on it, the
 log was filled with 2.4 GB of
 {{{
 2017/08/29 10:02:33 error polling broker: Post https://snowflake-
 reg.appspot.com/proxy: dial tcp: lookup snowflake-reg.appspot.com on :53: dial udp :53: connect: network is unreachable
 2017/08/29 10:02:33 error polling broker: Post https://snowflake-
 reg.appspot.com/proxy: dial tcp: lookup snowflake-reg.appspot.com on :53: dial udp :53: connect: network is unreachable
 2017/08/29 10:02:33 error polling broker: Post https://snowflake-
 reg.appspot.com/proxy: dial tcp: lookup snowflake-reg.appspot.com on :53: dial udp :53: connect: network is unreachable
 }}}

 There were 11,879,088 of these messages over the course of about an hour
 (according to the log timestamps), so about 3,330 messages per second. I'm
 guessing the code was in a tight failure loop.

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

Re: [tor-bugs] #22605 [Core Tor/Tor]: sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/tor/torrc.d/

[Tor Bug Tracker & Wiki]

#22605: sandbox_intern_string(): Bug: No interned sandbox parameter found for
/etc/tor/torrc.d/
-+
 Reporter:  toralf   |  Owner:  dgoulet
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.1.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  sandbox, regression  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

 * status:  needs_revision => needs_review


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

Re: [tor-bugs] #23311 [Core Tor/Tor]: prop224: Spammy intro point logs in v2

[Tor Bug Tracker & Wiki]

#23311: prop224: Spammy intro point logs in v2
-+
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #20657   | Points:  0.3
 Reviewer:   |Sponsor:
-+
Changes (by dgoulet):

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


Comment:

 Fixed by #22159. It has been rate limited and the actual limit has been
 changed to what was originally intended.

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

Re: [tor-bugs] #23240 [Applications/Tor Launcher]: do not show progress bar at zero when bootstrap progress is greater than zero

[Tor Bug Tracker & Wiki]

#23240: do not show progress bar at zero when bootstrap progress is greater than
zero
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  TorBrowserTeam201708R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--
Changes (by gk):

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


Comment:

 Replying to [comment:8 mcs]:
 > Replying to [comment:7 gk]:
 > > The code works for me and seems to fix the things mentioned in
 comment:6. mcs/brade: I'd be happy merging it into `master`, closing this
 ticket, and giving it some testing in the next alpha. What do you think?
 >
 > Sure, let's try it in the next alpha.

 Done. Cherry-picked to `master` with commit
 26d284e3835ddd5b283b732278b7b5b740bace6e.

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

Re: [tor-bugs] #22232 [Applications/Tor Launcher]: gather info on how Tor Launcher uses bootstrap status messages

[Tor Bug Tracker & Wiki]

#22232: gather info on how Tor Launcher uses bootstrap status messages
---+--
 Reporter:  catalyst   |  Owner:  brade
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  usability, ux  |  Actual Points:
Parent ID:  #21951 | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--

Comment (by cypherpunks):

 > The PROGRESS field of the STATUS_CLIENT messages are used directly
 *is used

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

Re: [tor-bugs] #23327 [Core Tor/Tor]: prop224: client-side memleaks on the last hidserv request subsystem

[Tor Bug Tracker & Wiki]

#23327: prop224: client-side memleaks on the last hidserv request subsystem
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, prop224, memleak  |  Actual Points:
Parent ID:  #23300| Points:  0.3
 Reviewer:  asn   |Sponsor:
--+
Changes (by dgoulet):

 * status:  new => needs_review
 * reviewer:   => asn


Comment:

 Turns out it was the cache itself that was never freed ;).

 See branch: `bug23327_032_01`.

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

Re: [tor-bugs] #22232 [Applications/Tor Launcher]: gather info on how Tor Launcher uses bootstrap status messages

[Tor Bug Tracker & Wiki]

#22232: gather info on how Tor Launcher uses bootstrap status messages
---+--
 Reporter:  catalyst   |  Owner:  brade
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  usability, ux  |  Actual Points:
Parent ID:  #21951 | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--
Changes (by mcs):

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


Comment:

 Kathy and I added README-BOOTSTRAP via commit
 ab8e081f3007f45e98171e163f080fea8caad964 on Tor Launcher master. You can
 view the file here:
 https://gitweb.torproject.org/tor-launcher.git/plain/README-BOOTSTRAP

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

Re: [tor-bugs] #22407 [Core Tor/Tor]: Support HTTP CONNECT tunnels as an alternative to SOCKS

[Tor Bug Tracker & Wiki]

#22407: Support HTTP CONNECT tunnels as an alternative to SOCKS
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, pt-v2, application-  |  Actual Points:
  support, http-connect, needs-design, prop229,  |
  review-group-22|
Parent ID:   | Points:  5
 Reviewer:  isis |Sponsor:
-+-
Changes (by isis):

 * status:  needs_review => needs_revision


Comment:

 Reviewed on oniongit. There's a couple suggestions/comments but nothing
 major, so please feel free to address whatever comments you feel like and
 then merge.

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

[tor-bugs] #23355 [Core Tor/Tor]: prop224: Implement a client purge state for NEWNYM

[Tor Bug Tracker & Wiki]

#23355: prop224: Implement a client purge state for NEWNYM
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  prop224, tor-hs
Actual Points:|  Parent ID:  #23300
   Points:|   Reviewer:
  Sponsor:|
--+
 Similar to `rend_client_purge_state()`

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

Re: [tor-bugs] #23310 [Core Tor/Tor]: test: prop224 client unit tests

[Tor Bug Tracker & Wiki]

#23310: test: prop224 client unit tests
+--
 Reporter:  dgoulet |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Very High   |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, prop224, test-unit  |  Actual Points:
Parent ID:  #23300  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by dgoulet):

 More tests, including those in asn's branch above, can be found here:
 `ticket23310_032_01`

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

Re: [tor-bugs] #23351 [Core Tor/Tor]: Create a rustfmt.toml defining our whitespace/formatting standards

[Tor Bug Tracker & Wiki]

#23351: Create a rustfmt.toml defining our whitespace/formatting standards
---+--
 Reporter:  isis   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  rust rust-pilot style  |  Actual Points:
Parent ID:  #22156 | Points:  1
 Reviewer: |Sponsor:
---+--
Changes (by isis):

 * priority:  Medium => Low


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

Re: [tor-bugs] #22752 [Core Tor/Tor]: Assertion failure in consensus_cache_entry_handle_get on Windows

[Tor Bug Tracker & Wiki]

#22752: Assertion failure in consensus_cache_entry_handle_get on Windows
--+
 Reporter:  ahf   |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor4
--+
Changes (by nickm):

 * status:  accepted => needs_review


Comment:

 I tried the simpler approach in `bug22752_031_simple` -- I think that's
 the one we should be reviewing.

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

Re: [tor-bugs] #22752 [Core Tor/Tor]: Assertion failure in consensus_cache_entry_handle_get on Windows

[Tor Bug Tracker & Wiki]

#22752: Assertion failure in consensus_cache_entry_handle_get on Windows
--+
 Reporter:  ahf   |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor4
--+

Comment (by nickm):

 >Another option is to kill off the maps when deleting on windows, since we
 can't keep them around.

 I tried this option first, since I thought it would be simple, but I ran
 into multithreading issues, and it turned out to be fairly tricky.  I've
 left my code in branch `bug22752_031_complex` in my public repository, but
 I hope we don't need to use it -- it could be destabilizing if I got
 _anything_ wrong, which I probably did.

 I'm going to try a simpler option now, with fewer multithreading issues.

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

Re: [tor-bugs] #22605 [Core Tor/Tor]: sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/tor/torrc.d/

[Tor Bug Tracker & Wiki]

#22605: sandbox_intern_string(): Bug: No interned sandbox parameter found for
/etc/tor/torrc.d/
-+
 Reporter:  toralf   |  Owner:  dgoulet
 Type:  defect   | Status:  needs_revision
 Priority:  High |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.1.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  sandbox, regression  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by Jigsaw52):

 Sorry for disappearing for a while but life got in the way.

 I've been working on a new patch that:
 1. Allows %include to work with sandbox and reload as long as no new files
 are added.
 1. Fails to reload the configuration (without crashing :) when a new file
 has been added.

 You can see my branch on https://github.com/Jigsaw52/tor/commits/fix-
 torrcd-sandbox-22605v2

 Currently, 1. seems to be working for this example but it still needs
 further testing.
 I haven't started working on 2. yet.

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

Re: [tor-bugs] #23258 [Applications/Tor Browser]: HTTPS Everywhere is not working when noscript is enabled globally

[Tor Bug Tracker & Wiki]

#23258: HTTPS Everywhere is not working when noscript is enabled globally
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:  fixed
 Keywords:  TorBrowserTeam201708R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:16 gk]:
 > So, the startup delay is not related to the whitelisting but to the new
 HTTPS-E itself. :/
 Confirmed. It creates
 {{{
 │   ├──27.41 MB (19.21%) -- https-everywhere-...@eff.org
 │   │  ├──27.38 MB (19.19%) ++ window-objects/top(moz-
 
extension://06272878-3037-4aa2-bbd3-e0effb78113c/_generated_background_page.html,
 id=14)
 }}}
 at startup.

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

Re: [tor-bugs] #23316 [Webpages/Website]: Replace templates at https://media.torproject.org/templates/

[Tor Bug Tracker & Wiki]

#23316: Replace templates at https://media.torproject.org/templates/
--+
 Reporter:  steph |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by steph):

 The other three can stay as is.

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

Re: [tor-bugs] #13410 [Applications/Tor Browser]: Disable self-signed certificate warnings when visiting .onion sites

[Tor Bug Tracker & Wiki]

#13410: Disable self-signed certificate warnings when visiting .onion sites
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by linda):

 yawning: that sounds reasonable!

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

Re: [tor-bugs] #22266 [Core Tor/Tor]: fix the jump-to-80% issue

[Tor Bug Tracker & Wiki]

#22266: fix the jump-to-80% issue
+
 Reporter:  catalyst|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  usability, ux, ux-team  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by linda):

 Isabela and I are thinking about this problem! We'll update you when we
 have a conclusion.

 My initial thoughts:
 * I am also not a fan of rescaling the bar.
 * I think the progress bar should accurately represent the progress made,
 so not starting at zero seems less confusing of the two.
 * Glad to know that if we want to do the above, we can cache the
 percentage and it never goes backwards.
 * The ideal thing for me would be that it starts at 0% every time, because
 the progress actually starts from 0% every 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] #23310 [Core Tor/Tor]: test: prop224 client unit tests

[Tor Bug Tracker & Wiki]

#23310: test: prop224 client unit tests
+--
 Reporter:  dgoulet |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Very High   |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, prop224, test-unit  |  Actual Points:
Parent ID:  #23300  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by asn):

 Pushed branch `bug23310_client_intro_test` in my repo which tests the
 client-side picking intro points, the intro state cache, etc.

 It also found a subtle memleak which is fixed as part of the branch.

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #16513, #21138, #21370, #23348

[Tor Bug Tracker & Wiki]

Batch modification to #16513, #21138, #21370, #23348 by iwakeh:
milestone to Onionoo-1.5.0

--
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] #22605 [Core Tor/Tor]: sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/tor/torrc.d/

[Tor Bug Tracker & Wiki]

#22605: sandbox_intern_string(): Bug: No interned sandbox parameter found for
/etc/tor/torrc.d/
-+
 Reporter:  toralf   |  Owner:  dgoulet
 Type:  defect   | Status:  needs_revision
 Priority:  High |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.1.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  sandbox, regression  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 I think this isn't quite right, for a couple of reasons:

* The code here gets run after the new options are parsed.  But the
 included files will make the load fail before we reach this point.
* This patch makes it impossible to disable includes, not only to
 enable them.

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

Re: [tor-bugs] #22159 [Core Tor/Tor]: Hidden service f3oap63t7u7hfnki exceeded launch limit with 11 intro points in the last 77 seconds

[Tor Bug Tracker & Wiki]

#22159: Hidden service f3oap63t7u7hfnki exceeded launch limit with 11 intro 
points
in the last 77 seconds
--+
 Reporter:  arma  |  Owner:  dgoulet
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Merged to 0.3.1 and forward.

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

Re: [tor-bugs] #23338 [Internal Services/Service - trac]: Trac registration requires that username is an email address

[Tor Bug Tracker & Wiki]

#23338: Trac registration requires that username is an email address
--+---
 Reporter:  downloadfiles@…   |  Owner:  qbi
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by qbi):

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


Comment:

 duplicate of #23207

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

Re: [tor-bugs] #23339 [Metrics/Metrics website]: adapt onionoo documentation to contain new search filter

[Tor Bug Tracker & Wiki]

#23339: adapt onionoo documentation to contain new search filter
-+---
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:  Onionoo-1.4.0
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

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


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

Re: [tor-bugs] #23240 [Applications/Tor Launcher]: do not show progress bar at zero when bootstrap progress is greater than zero

[Tor Bug Tracker & Wiki]

#23240: do not show progress bar at zero when bootstrap progress is greater than
zero
---+---
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201708R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+---

Comment (by mcs):

 Replying to [comment:7 gk]:
 > The code works for me and seems to fix the things mentioned in
 comment:6. mcs/brade: I'd be happy merging it into `master`, closing this
 ticket, and giving it some testing in the next alpha. What do you think?

 Sure, let's try it in the next 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] #23207 [Internal Services/Service - trac]: Registration on trac seems to be counterintuitive

[Tor Bug Tracker & Wiki]

#23207: Registration on trac seems to be counterintuitive
--+
 Reporter:  mail@…|  Owner:  qbi
 Type:  enhancement   | Status:  closed
 Priority:  Very Low  |  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Trivial   | Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by qbi):

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


Comment:

 `trac.ini` has a config option `register_check`. It had
 [[https://trac.edgewall.org/wiki/SpamFilter|RegistrationFilterAdapter]]
 enabled. According to the documentation this is responsible for the
 behaviour. I disabled the setting. According to my tests normal
 registering should be working again.

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

Re: [tor-bugs] #20971 [Applications/Tor Browser]: Try building Tor Browser with SafeStack

[Tor Bug Tracker & Wiki]

#20971: Try building Tor Browser with SafeStack
+--
 Reporter:  arthuredelstein |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-hardened, tbb-security  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by cypherpunks):

 > The SafeStack enforcement mechanism is now part of the Clang compiler
 https://clang.llvm.org/docs/SafeStack.html

 > SafeStack is a component of Code-Pointer Separation (CPS).
 > CPS is a simplified version of Code-Pointer Integrity (CPI).
 But
 > compiling dynamic libraries with SafeStack is not supported.
 > SafeStack was tested on Linux, FreeBSD and MacOSX.
 Instead of CPS/CPI Clang prefers #20361.

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

Re: [tor-bugs] #22324 [Applications/Tor Browser]: Allow JS on `about:tabcrashed` on higher security levels

[Tor Bug Tracker & Wiki]

#22324: Allow JS on `about:tabcrashed` on higher security levels
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff52-esr, tbb-7.0-must,  |  Actual Points:
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by cypherpunks):

 Could be upstreamed.

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

Re: [tor-bugs] #23350 [Applications/Tor Browser]: Website loads endlessly if connection went back then came, while other websites work just fine if they're loaded afterwards

[Tor Bug Tracker & Wiki]

#23350: Website loads endlessly if connection went back then came, while other
websites work just fine if they're loaded afterwards
--+--
 Reporter:  cypherpunks   |  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 cypherpunks):

 ticket:22432#comment:6 looks related.

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

Re: [tor-bugs] #23350 [Applications/Tor Browser]: Website loads endlessly if connection went back then came, while other websites work just fine if they're loaded afterwards

[Tor Bug Tracker & Wiki]

#23350: Website loads endlessly if connection went back then came, while other
websites work just fine if they're loaded afterwards
--+--
 Reporter:  cypherpunks   |  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 cypherpunks):

 Could somebody answer why that spinner
 https://bug1284395.bmoattachments.org/attachment.cgi?id=8767853 eats half
 the power of my two cores?

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

Re: [tor-bugs] #7501 [Applications/Tor Browser]: Audit PDF.js

[Tor Bug Tracker & Wiki]

#7501: Audit PDF.js
--+--
 Reporter:  mikeperry |  Owner:  gk
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * keywords:  tbb-usability, tbb-linkability, ff52-esr => tbb-security


Comment:

 Indeed, Mozilla realized that it needed a full-featured PDF processor,
 especially for [https://www.iso.org/standard/63534.html ISO 32000-2:2017],
 and no PDF.js could cope with it. So now we have ~~Adobe ~~ PDF Plugin
 integrated into the chrome process for
 https://bugzilla.mozilla.org/show_bug.cgi?id=1347444.

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

Re: [tor-bugs] #23350 [Applications/Tor Browser]: Website loads endlessly if connection went back then came, while other websites work just fine if they're loaded afterwards

[Tor Bug Tracker & Wiki]

#23350: Website loads endlessly if connection went back then came, while other
websites work just fine if they're loaded afterwards
--+--
 Reporter:  cypherpunks   |  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 cypherpunks):

 * status:  needs_information => new


Comment:

 Replying to [comment:1 gk]:
 > Just a quick thought: Does this happen as well if you disable
 multiprocess mode (by setting `browser.tabs.remote.autostart.2` to
 `false`) and restart Tor Browser? (I wonder whether that is essentially
 the same as #21924).

 Just tested it and this issue didn't happen in that 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] #21696 [Applications/Tor Browser]: 2 minute load time using duckduckgo onion in search bar

[Tor Bug Tracker & Wiki]

#21696: 2 minute load time using duckduckgo onion in search bar
--+--
 Reporter:  xz|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

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


Comment:

 This seems to have been a temporary issue for them, in any case, you
 should contact them if you find issue with their service and not fill
 tickets on the Tor Project's bug tracker since they have no control over
 their infrastructure.

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

Re: [tor-bugs] #21427 [Metrics/Onionoo]: allow to filter for tor_version

[Tor Bug Tracker & Wiki]

#21427: allow to filter for tor_version
-+---
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Onionoo-1.4.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

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


Comment:

 Merged together with a change log entry and protocol version bump.
 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] #23211 [Metrics/Onionoo]: limit Onionoo default listening to localhost

[Tor Bug Tracker & Wiki]

#23211: limit Onionoo default listening to localhost
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Onionoo-1.4.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

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


Comment:

 Merged! 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] #22983 [Metrics/metrics-lib]: add a descriptor interface and implementation for web-logs

[Tor Bug Tracker & Wiki]

#22983: add a descriptor interface and implementation for web-logs
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:  metrics-lib 2.1.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Cherry-picked and pushed that 1-line 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] #23350 [Applications/Tor Browser]: Website loads endlessly if connection went back then came, while other websites work just fine if they're loaded afterwards

[Tor Bug Tracker & Wiki]

#23350: Website loads endlessly if connection went back then came, while other
websites work just fine if they're loaded afterwards
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information


Comment:

 Just a quick thought: Does this happen as well if you disable multiprocess
 mode (by setting `browser.tabs.remote.autostart.2` to `false`) and restart
 Tor Browser? (I wonder whether that is essentially the same as #21924).

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

Re: [tor-bugs] #23349 [Applications/Tor Browser]: Disable navigator.send_beacon().

[Tor Bug Tracker & Wiki]

#23349: Disable navigator.send_beacon().
--+---
 Reporter:  yawning   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by yawning):

 Replying to [comment:1 gk]:
 > What is so special about `sendBeacon` that we should treat it
 differently than the more cumbersome it means to replace (see the MDN page
 you linked to and https://w3c.github.io/beacon/, especially the Privacy
 and Security section? Or, asked differently, why should we allow all the
 other awful techniques but not `sendBeacon`.

 In an ideal world, we shouldn't allow any of those other awful things
 either.

 > Could you elaborate on the "runs counter to 'Transpaency in Navigation
 Tracking'" claim? What does `sendBeacon` add that is not entailed in the
 usual third party (data aggregation) requests?

 "Report session data when the page transitions to background state or is
 being unloaded, without blocking the user agent." is anything but
 transparent.  Philosophically, an API call that was introduced primarily
 to facilitate anti-privacy practices is horrific and evil.

 I guess a better time to push for it being disabled was, when it was first
 introduced, because it was blatantly broken (CVE-2014-8638), and not just
 when I disagree with it from a philosophical point of view.

 *shrug*

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

Re: [tor-bugs] #23349 [Applications/Tor Browser]: Disable navigator.send_beacon().

[Tor Bug Tracker & Wiki]

#23349: Disable navigator.send_beacon().
--+---
 Reporter:  yawning   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information


Comment:

 What is so special about `sendBeacon` that we should treat it differently
 than the more cumbersome it means to replace (see the MDN page you linked
 to and https://w3c.github.io/beacon/, especially the Privacy and Security
 section? Or, asked differently, why should we allow all the other awful
 techniques but not `sendBeacon`.

 Could you elaborate on the "runs counter to 'Transpaency in Navigation
 Tracking'" claim? What does `sendBeacon` add that is not entailed in the
 usual third party (data aggregation) requests?

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