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

[Tor Bug Tracker & Wiki]

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

Comment (by gk):

 Replying to [comment:59 mcs]:
 > Replying to [comment:58 antonela]:
 > > For first time users, is the double verification also needed? Could
 they have any network leak?
 >
 > I think we should require a click on the button on all cases (for
 consistency, and to be safe). In other words, I am convinced by gk's
 argument in comment:49 point 4).

 Well, I was not sure about first time users having no bridges yet but
 selecting that option ("So, at least after the user got some bridges (and
 even used them?) we could change that behavior?"). I could see arguments
 for both options (the consistency one and the first-time-just-one-click
 one).

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

Re: [tor-bugs] #25333 [Applications/Tor Browser]: NOT SECURE CONECTION please help

[Tor Bug Tracker & Wiki]

#25333: NOT SECURE CONECTION please help
--+---
 Reporter:  kiokawasaki1998   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * cc: phshirk (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] #25361 [Applications/Tor Browser]: Secure Connection Failed

[Tor Bug Tracker & Wiki]

#25361: Secure Connection Failed
--+---
 Reporter:  phshirk   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 I guess that's a duplicate of #25333.

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

Re: [tor-bugs] #25381 [Core Tor/Tor]: Add crypto_rand_double_sign() in C and Rust

[Tor Bug Tracker & Wiki]

#25381: Add crypto_rand_double_sign() in C and Rust
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-relay, privcount  |  Actual Points:
Parent ID:  #23061| Points:  2
 Reviewer:|Sponsor:  SponsorQ
--+

Comment (by teor):

 See my branch rust-rand-f64-v2 on https://github.com/teor2345/tor.git

 I need help getting the module doc tests to run.
 It seems like trivial changes can activate or deactivate doc tests.

 I wanted to put crypto_rand_f64/crypto_rand_distribution.rs in
 test/distribution/mod.rs, but I couldn't get its doc tests to run.

 Once I've sorted out these issues, I'll be ready to put the branch on
 oniongit for a real review.

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

[tor-bugs] #25381 [Core Tor/Tor]: Add crypto_rand_double_sign() in C and Rust

[Tor Bug Tracker & Wiki]

#25381: Add crypto_rand_double_sign() in C and Rust
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-relay, privcount
Actual Points:|  Parent ID:  #23061
   Points:  2 |   Reviewer:
  Sponsor:  SponsorQ  |
--+--
 We need a function that returns 1.0 or -1.0 with equal probability, so we
 can avoid weird tricks that waste floating point precision.

 Since we want to use this in the laplace and guassian distributions, it
 needs to be implemented in both C and Rust.

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

Re: [tor-bugs] #25380 [Core Tor/Tor]: Transparent proxy not working with linux kernel 4.15.6

[Tor Bug Tracker & Wiki]

#25380: Transparent proxy not working with linux kernel 4.15.6
+
 Reporter:  vafan   |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.3.2-alpha
 Severity:  Normal  | Resolution:
 Keywords:  033-must, hang  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  |Sponsor:
+
Changes (by teor):

 * keywords:   => 033-must, hang
 * points:   => 0.5
 * milestone:   => Tor: 0.3.3.x-final


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

Re: [tor-bugs] #25380 [Core Tor/Tor]: Transparent proxy not working with linux kernel 4.15.6

[Tor Bug Tracker & Wiki]

#25380: Transparent proxy not working with linux kernel 4.15.6
--+
 Reporter:  vafan |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.2-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by vafan):

 Make that change ff225999c603f0efed8fdbb791bab039d133eda2 - same author
 tho

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25380 [Core Tor/Tor]: Transparent proxy not working with linux kernel 4.15.6

[Tor Bug Tracker & Wiki]

#25380: Transparent proxy not working with linux kernel 4.15.6
--+
 Reporter:  vafan |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.2-alpha
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 I dunno if yous test with da latest kernel but transparent proxy is not
 working at all with verion 4.15.6

 If I were shooting from the hip or throwing darts blindfolded I would
 probably blame change 8f2f8993e0f69f4f8d5afe3873158f723daacb31 but I am
 not that kind of person.

 The symptoms are tor process gets stuck in the getopt for the original
 destination address (in connection_edge.c) ipv4 transprarent proxy code
 and cannot be killed because the system call just sits there
 UNINTERRUPTIBLE

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by Hello71):

 as I said on IRC:

 1. -L takes a directory, not a file. see `rustc --help`
 2. `src/rust/external/.cargo/config` is not read. you can verify with
 strace or inotify (or your platform equivalent). must use
 `src/rust/.cargo/config` (which already exists)
 3. rust does not depend on the libraries in the makefile. if you want it
 to work this way, you'd need to add that, otherwise building tor fails. I
 think it would be better to use it only for tests, i.e. use
 `RUSTFLAGS="-L... -l..."` in `src/test/test_rust.sh`.

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

Re: [tor-bugs] #25222 [Core Tor/DocTor]: replace static subject with summary of content

[Tor Bug Tracker & Wiki]

#25222: replace static subject with summary of content
-+-
 Reporter:  cypherpunks  |  Owner:  atagar
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Core Tor/DocTor  |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

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


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

Re: [tor-bugs] #25379 [Core Tor/Tor]: Determine the lowest rustc version we will compile with

[Tor Bug Tracker & Wiki]

#25379: Determine the lowest rustc version we will compile with
-+
 Reporter:  isis |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Low  |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, tor-build  |  Actual Points:
Parent ID:  #24765   | Points:  2
 Reviewer:   |Sponsor:  SponsorM-can
-+
Changes (by teor):

 * parent:   => #24765


Comment:

 This might be a duplicate of #24765

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

Re: [tor-bugs] #25341 [Core Tor/Tor]: Remove now-unnecessary Rust linking workaround

[Tor Bug Tracker & Wiki]

#25341: Remove now-unnecessary Rust linking workaround
---+---
 Reporter:  isis   |  Owner:  (none)
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.4.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.2.2-alpha
 Severity:  Normal | Resolution:
 Keywords:  rust, tor-build, autoconf  |  Actual Points:
Parent ID: | Points:  .1
 Reviewer: |Sponsor:
---+---

Comment (by isis):

 Replying to [comment:4 teor]:
 > We can't remove this workaround until we stop supporting old rustc
 versions without the fix.

 Okay! I made #25379 for figuring out more clearly which rustc(s) we
 support.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25379 [Core Tor/Tor]: Determine the lowest rustc version we will compile with

[Tor Bug Tracker & Wiki]

#25379: Determine the lowest rustc version we will compile with
--+
 Reporter:  isis  |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Low   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  rust, tor-build
Actual Points:|  Parent ID:
   Points:  2 |   Reviewer:
  Sponsor:  SponsorM-can  |
--+
 In our docs, we say that we currently develop with nightly, and that we
 might stop doing that soon. In our Makefiles, we refuse to compile if
 rustc is <1.14. About a week ago, some of us were pretty excited that the
 current stable compiler (1.24) [https://blog.rust-
 lang.org/2018/02/15/Rust-1.24.html#other-good-stuff will now abort if a
 panic occurs at an FFI boundary]. Also, our Makefiles currently contain a
 linker workaround for OSX systems for rustc <1.24 (#25341).

 We should maybe narrow down which version(s) of Rust we're using?

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

Re: [tor-bugs] #25378 [Core Tor/Tor]: Log domain list is out of sync in tor.1.txt

[Tor Bug Tracker & Wiki]

#25378: Log domain list is out of sync in tor.1.txt
---+
 Reporter:  ahf|  Owner:  ahf
 Type:  defect | Status:  merge_ready
 Priority:  Low|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  doc, 033-backport  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * status:  needs_review => merge_ready
 * keywords:   => doc, 033-backport
 * version:  Tor: unspecified =>
 * milestone:  Tor: 0.3.4.x-final => Tor: 0.3.3.x-final


Comment:

 Looks good to me.

 Since this is a doc / comment patch, I suggest we take it in 0.3.3.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by isis):

 I took a stab at this some more in
 
[https://github.com/isislovecruft/tor/commit/fad354aa8c10c20e1ec2f98effd5edf8e43c3a51
 this commit] but I'm still failing to get linking to happen for tests.

 I took a break from this for a bit to work on other stuff, but I'm
 beginning to agree with
 [https://trac.torproject.org/projects/tor/ticket/23881#comment:8 the thing
 that Chelsea said] in #23881 with the Rust logging stuff, about "The
 approach of 'write C integration tests and test Rust in isolation' is an
 approach taken by Servo." If I remove my tests for the correctness of the
 SHA-2 implementation here, and test only in C (which I'm not actually sure
 if we're doing yet?) then it'll link fine. The caveat though, which is
 quite steep, would be that ''anything'' that wished to test its Rust code
 and simultaneously use hashes in a non-generic way would be unable to do
 so. :/

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

Re: [tor-bugs] #25378 [Core Tor/Tor]: Log domain list is out of sync in tor.1.txt

[Tor Bug Tracker & Wiki]

#25378: Log domain list is out of sync in tor.1.txt
--+
 Reporter:  ahf   |  Owner:  ahf
 Type:  defect| Status:  needs_review
 Priority:  Low   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by ahf):

 * status:  assigned => needs_review


Comment:

 Patch in https://gitlab.com/ahf/tor/merge_requests/25

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

Re: [tor-bugs] #25378 [Core Tor/Tor]: Log domain list is out of sync in tor.1.txt

[Tor Bug Tracker & Wiki]

#25378: Log domain list is out of sync in tor.1.txt
--+
 Reporter:  ahf   |  Owner:  ahf
 Type:  defect| Status:  assigned
 Priority:  Low   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by ahf):

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


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25378 [Core Tor/Tor]: Log domain list is out of sync in tor.1.txt

[Tor Bug Tracker & Wiki]

#25378: Log domain list is out of sync in tor.1.txt
--+
 Reporter:  ahf   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Our list of log domains in the man page is out of sync.

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

Re: [tor-bugs] #25372 [Core Tor/Tor]: relay: Allocation for compression goes very high

[Tor Bug Tracker & Wiki]

#25372: relay: Allocation for compression goes very high
-+-
 Reporter:  dgoulet  |  Owner:  ahf
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, compression, tor-dos  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by ahf):

 * status:  assigned => needs_review


Comment:

 A patch that might help us in the future:
 https://gitlab.com/ahf/tor/merge_requests/24

 Please don't close the ticket if this is applied since it doesn't solve
 the issue, but it might help us debug issues in the future.

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

Re: [tor-bugs] #24029 [Core Tor/Tor]: Test all rust functions' behavior when called from C with bad UTF8

[Tor Bug Tracker & Wiki]

#24029: Test all rust functions' behavior when called from C with bad UTF8
--+
 Reporter:  nickm |  Owner:  chelseakomlo
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:  #24265| Points:
 Reviewer:|Sponsor:
--+
Changes (by isis):

 * cc: isis (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] #24265 [Core Tor/Tor]: Fuzz all rust functions that are used by authorities to make sure they match C

[Tor Bug Tracker & Wiki]

#24265: Fuzz all rust functions that are used by authorities to make sure they
match C
+
 Reporter:  teor|  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  Rust protover fuzz  |  Actual Points:
Parent ID:  | Points:  3
 Reviewer:  |Sponsor:
+
Changes (by isis):

 * cc: isis (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] #25377 [Core Tor/Tor]: Provide a control-port mechanisms to manage idle mode better.

[Tor Bug Tracker & Wiki]

#25377: Provide a control-port mechanisms to manage idle mode better.
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code

[Tor Bug Tracker & Wiki]

#23881: Implement a way to utilise tor's logging system from Rust code
---+---
 Reporter:  isis   |  Owner:  isis
 Type:  enhancement| Status:  accepted
 Priority:  High   |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  rust, rust-pilot, review-group-29  |  Actual Points:
Parent ID: | Points:  3
 Reviewer:  nickm  |Sponsor:
---+---

Comment (by manish.earth):

 Yeah, I'd missed the "not" in the second half.


 You're right that `CString::_new` does no copies or allocations; the
 sneaky bit is the `t.into()` -- the `From<>` impl for `Vec`. That
 itself calls the `From<&[u8]> for Vec` impl (https://github.com/rust-
 
lang/rust/blob/29f5c699b11a6a148f097f82eaa05202f8799bbc/src/liballoc/vec.rs#L2161-L2171)
 :

 {{{#!rust
 impl<'a, T: Clone> From<&'a [T]> for Vec {
 #[cfg(not(test))]
 fn from(s: &'a [T]) -> Vec {
 s.to_vec()
 }
 #[cfg(test)]
 fn from(s: &'a [T]) -> Vec {
 ::slice::to_vec(s)
 }
 }
 }}}

 which calls `alloc::slice::to_vec` (https://github.com/rust-
 
lang/rust/blob/29f5c699b11a6a148f097f82eaa05202f8799bbc/src/liballoc/slice.rs#L164-L170),
 which creates a new vector and copies stuff into it via
 `extend_from_slice`

 {{{#!rust
 pub fn to_vec(s: &[T]) -> Vec
 where T: Clone
 {
 let mut vector = Vec::with_capacity(s.len());
 vector.extend_from_slice(s);
 vector
 }
 }}}

 If `T` is a `String` or `Vec`, it won't be copied, because the
 `From for Vec` impl is basically a no-op move. But if it's a
 borrow (e.g. `` or `&[u8]` or something), it will be copied into a new
 allocation. It has to be -- you can't guarantee that borrow will live
 forever.

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

Re: [tor-bugs] #25222 [Core Tor/DocTor]: replace static subject with summary of content

[Tor Bug Tracker & Wiki]

#25222: replace static subject with summary of content
-+
 Reporter:  cypherpunks  |  Owner:  atagar
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/DocTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by atagar):

 Hi, this seems like it would make for an unpleasantly long subject. I'm
 open to ideas, but I'd like to keep it short.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by mcs):

 Replying to [comment:58 antonela]:
 > !GeKo, I can see your concerns described at 4) on comment:49.
 >
 > What does happen when the user has more than one old successful bridge
 connection? Will the bridges alreadyobtainedbe shown on a list?

 There is only one service that can be used to obtain bridges: BridgeDB.
 Therefore, there will only ever be one button. The idea of referring to it
 as "torproject.org" is to communicate to users that a network conversation
 will happen and that the bridge info is coming from the Tor Project. After
 someone successfully obtains some bridges from BridgeDB, the bridge info
 is inserted and the button gets a new label (we can decide what the new
 label should be). The UI would look something like this:
 {{{
  [ ] Select a built-in bridge [i]
  [X] Request a bridge
obfs4 1.2.3.4 fingerprint...
obfs4 1.2.3.5 fingerprint...
obfs4 1.2.3.6 fingerprint...
[Request a New Bridge…]

  [ ] Provide a bridge I know
 }}}
 > For first time users, is the double verification also needed? Could they
 have any network leak?

 I think we should require a click on the button on all cases (for
 consistency, and to be safe). In other words, I am convinced by gk's
 argument in comment:49 point 4).

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

[tor-bugs] #25377 [- Select a component]: Provide a control-port mechanisms to manage idle mode better.

[Tor Bug Tracker & Wiki]

#25377: Provide a control-port mechanisms to manage idle mode better.
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor8  |
--+
 When Tor is idle, we should fetch directory information less aggressively,
 not build predictive or probe circuits, and so on.  We should provide a
 way for controllers to manage idle mode: to tell Tor to enter it early,
 and to leave it in part of in full.

 This is related to proposal 286.

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

Re: [tor-bugs] #25376 [Core Tor/Tor]: Disable as many timers as possible when DisableNetwork or when idle/hibernating

[Tor Bug Tracker & Wiki]

#25376: Disable as many timers as possible when DisableNetwork or when
idle/hibernating
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8
--+

Comment (by nickm):

 (There should be one subticket to build this system, and several
 subtickets to apply it as needed)

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

Re: [tor-bugs] #25222 [Core Tor/DocTor]: replace static subject with summary of content

[Tor Bug Tracker & Wiki]

#25222: replace static subject with summary of content
-+
 Reporter:  cypherpunks  |  Owner:  atagar
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/DocTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by cypherpunks):

 Lets skip the numbers in brackets for easier filtering, example above:
 warning: certexpiry, hsdir disagreement, badexit disagreement

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25376 [Core Tor/Tor]: Disable as many timers as possible when DisableNetwork or when idle/hibernating

[Tor Bug Tracker & Wiki]

#25376: Disable as many timers as possible when DisableNetwork or when
idle/hibernating
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor8  |
--+
 With #25373 and #25375, we should be using first-class timer objects for
 more and more of our timed events.   We should have a way to mark timers
 that should be disabled when Tor is idle, or when DisableNetwork has been
 set.  Then we should actually disable them, to lower the amount of wakeups
 that Tor performs under those circumstances.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25375 [Core Tor/Tor]: Remove as many items as possible from second_elapsed_callback() and run_scheduled_events()

[Tor Bug Tracker & Wiki]

#25375: Remove as many items as possible from second_elapsed_callback() and
run_scheduled_events()
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor8  |
--+
 We have a real system for periodic events and deferred events and so on --
 several of them, in fact.  We shouldn't be using second_elapsed_callback()
 and run_scheduled_events() to do things any more:
   * Some things should be done as soon as possible, on demand (see
 #25374).
   * Some things should be done on the timers from periodic.c.
   * Some things should be done with one-off timers schedueld "for later".

 And some things might still need to be done once a second -- but they
 should be things that only need to happen when Tor is running.  When Tor
 is idle or hibernating, or when DisableNetwork is set, we should be able
 to disable those once-per-second events so that we don't use so much CPU.

 '''Please make subtickets for removing things from these functions.'''

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25374 [Core Tor/Tor]: Create a better-designed system for handling computation outside the event loop

[Tor Bug Tracker & Wiki]

#25374: Create a better-designed system for handling computation outside the 
event
loop
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor8  |
--+
 Right now, we do a couple of things in `run_main_loop_once` that happen
 outside the event loop (because we want to re-scan for events event loop
 before they happen):
   * Making events on active_linked_connection_lst active.
   * Running connection_ap_attach_pending.

 But we can do this much better.  With Libevent 2.1, instead of making the
 loop exit for this, we can should do all of these things in a separate
 event callback, and call `event_base_loopcontinue()` at the end of that
 event's callback so that the event_base will get rescanned before we
 return. With earlier versions of Libevent, we can do something similar
 with event_base_loopbreak().

 Doing this won't lower the number of wakeups we do, but it should simplify
 our overall event loop logic, and make other event loop simplifications
 easier.

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

Re: [tor-bugs] #25373 [Core Tor/Tor]: Avoid needless wakeups for token bucket refills.

[Tor Bug Tracker & Wiki]

#25373: Avoid needless wakeups for token bucket refills.
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8
--+
Changes (by nickm):

 * sponsor:   => Sponsor8


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25373 [Core Tor/Tor]: Avoid needless wakeups for token bucket refills.

[Tor Bug Tracker & Wiki]

#25373: Avoid needless wakeups for token bucket refills.
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 In 0.2.3.5-alpha, we increased our default token bucket refill interval
 from 1 time per second to 10 times per second.  (See #3630 and proposal
 183.)

 AFAICT, this is now the most frequently running timer causing wakeups on
 an idle Tor instance.  It even causes wakeups on Tor instances when
 DisableNetwork is set. We can do better!

 Two key insights:
   *  First, it is not necessary to actually refill these buckets
 periodically.  Instead, we can store the last time at which we refilled
 each one, and calculate its current size at immediately before we read or
 write.  The only thing we'll need to use a timer for is to wake up
 connections on which we've stopped reading or writing.

   * Second, we only need to have this timer active when at least one
 connection is blocked on bandwidth.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by antonela):

 !GeKo, I can see your concerns described at 4) on comment:49.

 What does happen when the user has more than one old successful bridge
 connection? Will the bridges already obtained be showing on a list?

 So, will it look like this?

 [ ] Select a built-in bridge [i]
 [X] Request a bridge

   [Request from torproject.org]
   [Request from source_2]
   [Request from source_3]

 [ ] Provide a bridge I know

 If it is the version, what happens if as a user I need a new bridge
 outside the list?

 [ ] Select a built-in bridge [i]
 [X] Request a bridge

   [Request from torproject.org]
   [Request from source_2]
   [Request from source_3]
   [Request a new bridge]

 [ ] Provide a bridge I know

 For first time users, is the double verification also needed? Could they
 have any network leak?

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

Re: [tor-bugs] #25353 [Core Tor/Tor]: Configure fails with some OpenSSL 1.1.0

[Tor Bug Tracker & Wiki]

#25353: Configure fails with some OpenSSL 1.1.0
-+-
 Reporter:  laomaiweng   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  openssl, tor-ssl, 033-backport,  |  Actual Points:
  032-backport, 031-backport, 029-backport   |
  033-must   |
Parent ID:  #19429   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:
 openssl, tor-ssl, 033-backport, 032-backport, 031-backport,
 029-backport
 =>
 openssl, tor-ssl, 033-backport, 032-backport, 031-backport,
 029-backport 033-must


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

Re: [tor-bugs] #25372 [Core Tor/Tor]: relay: Allocation for compression goes very high

[Tor Bug Tracker & Wiki]

#25372: relay: Allocation for compression goes very high
-+-
 Reporter:  dgoulet  |  Owner:  ahf
 Type:  defect   | Status:  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, compression, tor-dos  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by ahf):

 Looks like this isn't related to #24368 if Zstandard is disabled.

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

Re: [tor-bugs] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code

[Tor Bug Tracker & Wiki]

#23881: Implement a way to utilise tor's logging system from Rust code
---+---
 Reporter:  isis   |  Owner:  isis
 Type:  enhancement| Status:  accepted
 Priority:  High   |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  rust, rust-pilot, review-group-29  |  Actual Points:
Parent ID: | Points:  3
 Reviewer:  nickm  |Sponsor:
---+---

Comment (by isis):

 Okay, to answer the question of "Does `CString::new` perform a copy?"

 Manish answered above, but I ''think'' there was a typo in the answer? (It
 seems to be missing the word "not" in the latter clause?) I had assumed it
 always copied, so I went and dug through the stdlib to figure it out.

 So [https://doc.rust-lang.org/src/std/ffi/c_str.rs.html#330-332 looking at
 the source of `CString::new`]:

 {{{#!rust
 pub fn new>>(t: T) -> Result {
 Self::_new(t.into())
 }

 fn _new(bytes: Vec) -> Result {
 match memchr::memchr(0, ) {
 Some(i) => Err(NulError(i, bytes)),
 None => Ok(unsafe { CString::from_vec_unchecked(bytes) }),
 }
 }
 }}}

 [wow!!! check out that ↑↑ frickin syntax highlighting! zomg, my
 life is changed!!]

 it takes a any `T` which has implemented a way (`Into`) to transmute it
 into a `Vec` and calls [https://doc.rust-
 lang.org/src/std/ffi/c_str.rs.html#334-339 `Cstring::_new()`] on it. There
 [https://doc.rust-lang.org/src/alloc/vec.rs.html#2226-2230 exists]
 `impl<'a> From<&'a str> for Vec`:

 {{{#!rust
 impl<'a> From<&'a str> for Vec {
 fn from(s: &'a str) -> Vec {
 From::from(s.as_bytes())
 }
 }
 }}}

 The `_new()` function checks that is has no NUL bytes, and errors if it
 does, then calls [https://doc.rust-
 lang.org/src/std/ffi/c_str.rs.html#361-365
 `CString::from_vec_unchecked()`]:

 {{{#!rust
 pub unsafe fn from_vec_unchecked(mut v: Vec) -> CString {
 v.reserve_exact(1);
 v.push(0);
 CString { inner: v.into_boxed_slice() }
 }
 }}}

 And then [https://doc.rust-
 lang.org/alloc/vec/struct.Vec.html#method.into_boxed_slice
 `Vec::into_boxed_slice()`]:

 {{{#!rust
 pub fn into_boxed_slice(mut self) -> Box<[T]> {
 unsafe {
 self.shrink_to_fit();
 let buf = ptr::read();
 mem::forget(self);
 buf.into_box()
 }
 }
 }}}

 which is doing some olympic level gymnastics where [https://doc.rust-
 lang.org/std/ptr/fn.read.html `std::ptr::read`] is returning a `Rawvec`,
 then it `mem::forget()`s itself so that the deallocator never runs, and
 finally it `Box`es the memory it forgot about by calling
 `RawVec::into_box()`:

 {{{#!rust
 impl RawVec {
 /// Converts the entire buffer into `Box<[T]>`.
 ///
 /// While it is not *strictly* Undefined Behavior to call
 /// this procedure while some of the RawVec is uninitialized,
 /// it certainly makes it trivial to trigger it.
 ///
 /// Note that this will correctly reconstitute any `cap` changes
 /// that may have been performed. (see description of type for
 details)
 pub unsafe fn into_box(self) -> Box<[T]> {
 // NOTE: not calling `cap()` here, actually using the real `cap`
 field!
 let slice = slice::from_raw_parts_mut(self.ptr(), self.cap);
 let output: Box<[T]> = Box::from_raw(slice);
 mem::forget(self);
 output
 }
 }
 }}}

 which is doing even more olympic level gymnastics with [https://doc.rust-
 lang.org/std/slice/fn.from_raw_parts.html `slice::from_raw_parts`], which
 is like the King of Capital-U Unsafety, because it just says "N bytes from
 this pointer forward are now a slice, with an lifetime that I decided by
 royal proclamation, and which is not necessarily the correct lifetime
 given that I was handed a raw pointer that I know nothing about". But it
 doesn't copy. Then it does a similar pirouette as the trick we saw before
 with `std::ptr::read` and then `Box`ing the `RawVec`, but even more
 complicated and dangerous, like if the last one was a pirouette, this is
 like a pirouette while juggling machetes. `Box::from_raw` is only
 ''really'' supposed to be called on pointers produced via `Box::into_raw`,
 but whatever, so many crazy things have already been done with these
 pointers to this memory. So `Box::from_raw` creates a [https://doc.rust-
 lang.org/std/ptr/struct.Unique.html `Unique`], which just says, "I own
 this raw pointer to a `T` (`*mut T`), and I'm just going to pretend it
 

Re: [tor-bugs] #25372 [Core Tor/Tor]: relay: Allocation for compression goes very high

[Tor Bug Tracker & Wiki]

#25372: relay: Allocation for compression goes very high
-+-
 Reporter:  dgoulet  |  Owner:  ahf
 Type:  defect   | Status:  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, compression, tor-dos  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by ahf):

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


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

Re: [tor-bugs] #25372 [Core Tor/Tor]: relay: Allocation for compression goes very high

[Tor Bug Tracker & Wiki]

#25372: relay: Allocation for compression goes very high
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, compression, tor-dos  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dgoulet):

 >  Which compression methods is your tor compiled with?

 {{{
 Feb 13 20:15:54.919 [notice] Tor 0.3.3.2-alpha-dev (git-86f461e362480bb5)
 running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g, Zlib 1.2.8,
 Liblzma 5.1.0alpha, and Libzstd N/A.
 }}}

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

Re: [tor-bugs] #25372 [Core Tor/Tor]: relay: Allocation for compression goes very high

[Tor Bug Tracker & Wiki]

#25372: relay: Allocation for compression goes very high
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, compression, tor-dos  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Which compression methods is your tor compiled with?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25372 [Core Tor/Tor]: relay: Allocation for compression goes very high

[Tor Bug Tracker & Wiki]

#25372: relay: Allocation for compression goes very high
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor: 0.3.4.x-final
Component:  Core |Version:
  Tor/Tor|
 Severity:  Normal   |   Keywords:  tor-relay, compression, tor-dos
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 My relay just OOMed some circuits with filled up queue (#25226) but then a
 useful log was printed showing that the compress total allocation is huge.

 {{{
 Feb 27 20:02:55.718 [notice] We're low on memory (cell queues total alloc:
 232279872 buffer total alloc: 1937408, tor compress total alloc: 878586075
 rendezvous cache total alloc: 4684497). Killing circuits withover-long
 queues. (This behavior is controlled by MaxMemInQueues.)
 }}}

 That `878586075 = ~838MB`. My relay is hovering around 1.4GB of RAM right
 now which means ~60% of the RAM used is in the compression subsystem.

 I'm not sure where it all comes, the relay is serving directory data but I
 have my doubt that *compressed*, it comes down to 800+ MB...

 Datapoint:

 {{{
 $ du -sh diff-cache/
 131Mdiff-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] #24767 [Core Tor/Tor]: All relays are constantly connecting to down relays and failing over and over

[Tor Bug Tracker & Wiki]

#24767: All relays are constantly connecting to down relays and failing over and
over
-+-
 Reporter:  arma |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-dos, performance, |  Actual Points:
  review-group-32, 033-must  |
Parent ID:   | Points:
 Reviewer:  asn, teor|Sponsor:
-+-

Comment (by teor):

 Replying to [comment:23 dgoulet]:
 > Replying to [comment:22 teor]:
 > > There are two design issues here:
 > > * the HT implementation only uses 32 bit hashes on 64-bit LP64
 systems, like macOS and the BSDs, and 32-bit systems (split off into
 #25365)
 > > * the port is user-controlled, so it needs to be hashed before being
 combined with the other hashes
 >
 > What is the danger here? The length is fixed so what is the difference
 between "+= 42" or "+= h(42)" ?

 The hash needs to be unpredictable so that bad clients can't fill up one
 of your hash table buckets and cause your relay to slow down.
 Adding the raw port gives the client direct control over 16 bits of your
 hash result, which makes the hash table less secure.

 > > I fixed the port issue, and the compilation issues in my branch
 bug24767_033_02 on https://github.com/teor2345/tor.git
 >
 > For the hash fix, wouldn't it be more efficient to then combined addr +
 digest + port in a buffer and siphash that instead of doing 3 rounds of
 siphash?

 Hashing digest and port in a single buffer would be an easy win.
 Hashing an extra buffer as part of tor_addr_hash() would also be great,
 because it avoids combining hashes with +.
 But it would need a new argument to tor_addr_hash().
 And we could fix the other use of tor_addr_hash() at the same time.

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

Re: [tor-bugs] #22689 [Core Tor/Tor]: hs: Stop rend and intro points being used as single hop proxies

[Tor Bug Tracker & Wiki]

#22689: hs: Stop rend and intro points being used as single hop proxies
--+
 Reporter:  teor  |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  relay-safety  |  Actual Points:
Parent ID:  #17945| Points:  0.5
 Reviewer:  teor  |Sponsor:
--+
Changes (by teor):

 * reviewer:   => teor


Comment:

 I'll review this later today, after I get some Rust done.

 Do we want a consensus parameter to block Tor2web at Intros, like the one
 at Rendezvous?
 I think the answer is "yes, but not on by default, and not on right now,
 and maybe just in 0.3.4".
 I opened #25371 to do it in a separate task.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25371 [Core Tor/Tor]: Add a consensus parameter for blocking single hop client intro

[Tor Bug Tracker & Wiki]

#25371: Add a consensus parameter for blocking single hop client intro
-+-
 Reporter:  teor |  Owner:  teor
 Type:   | Status:  assigned
  enhancement|
 Priority:  Medium   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  tor2web, tor-hs, 029-backport-
 Severity:  Normal   |  maybe, 031-backport-maybe, 032-backport-maybe,
 |  033-backport-maybe
Actual Points:   |  Parent ID:  #17945
   Points:  0.5  |   Reviewer:
  Sponsor:   |
-+-
 In #22689, we allow single hop client intro when the service is multi-hop.
 But we might want to block it entirely some time in the future.

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

Re: [tor-bugs] #22688 [Core Tor/Tor]: hs: Make sure HSDir never know service, client, or bridge IP addresses

[Tor Bug Tracker & Wiki]

#22688: hs: Make sure HSDir never know service, client, or bridge IP addresses
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, relay-safety  |  Actual Points:  0.3
Parent ID:  #17945| Points:  0.3
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  assigned => needs_revision


Comment:

 Do we want a consensus parameter to block Tor2web at HSDirs?
 I think the answer is "yes, but not on by default, and not on right now".
 I'll add that parameter when I revise the ticket.

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

Re: [tor-bugs] #25226 [Core Tor/Tor]: Circuit cell queue can fill up memory

[Tor Bug Tracker & Wiki]

#25226: Circuit cell queue can fill up memory
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-cell, tor-relay, tor-dos,|  Actual Points:
  033-must   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:11 cypherpunks]:
 > Replying to [comment:9 dgoulet]:
 > > An upper limit on the circuit queue bound with the SENDME logic would
 look like this: `bug25226_033_01`
 > >
 > > The gist is that if the queue size goes above the circuit window start
 maximum limit (1000), the circuit is closed with TORPROTOCOL reason.
 Assuming we ever reach that limit, it means something is wrong in the path
 and the edge connection keeps sending stuff even though it shouldn't.
 >
 > tor-spec.txt:
 > > To control a circuit's bandwidth usage, each OR **keeps track of** two
 'windows', consisting of how many **RELAY_DATA cells** it is allowed to
 originate (package for transmission), and how many **RELAY_DATA cells** it
 is willing to consume (receive for local streams). **These limits do not
 apply to cells that the OR receives from one host and relays to another**.

 We can change this part of the spec.

 > tor-design.pdf:
 > > **Leaky-pipe circuit topology**: Through in-band signaling within the
 circuit, Tor initiators can direct traffic to nodes partway down the
 circuit. This novel approach allows traffic to exit the circuit from the
 middle — possibly frustrating traffic shape and volume attacks based on
 observing the end of the circuit. (It also allows for long-range padding
 if future research shows this to be worthwhile.)

 Standard Tor clients do not use this feature, but they get close:
 * connection netflow padding is at link level, not circuit level
 * client introduce circuits send a single INTRODUCE1 cell, then EXTEND if
 the introduction fails

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

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

[Tor Bug Tracker & Wiki]

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

 * keywords:  TorBrowserTeam201802R => TorBrowserTeam201802R, ux-team


Comment:

 Replying to [comment:56 mcs]:
 > Replying to [comment:55 mcs]:
 > > I think the only reason it works how it does right now is that we were
 trying to stay faithful to Linda's design, which tried hard to reduce the
 number of clicks needed (by removing the wizard and generally streamlining
 things). But let's require the second click. Kathy and I have two
 questions though:
 > > a) What do you mean by "then showing the available bridges?" Do you
 mean offering a choice of bridge types (e.g., obfs3, obsf4) or do you mean
 showing bridges that the user has already obtained?

 The latter, i.e. showing bridges they already have obtained.

 > > b) What text should we use for the radio button label? Introducing
 "BridgeDB" without explaining it does not seem ideal, although the current
 design is somewhat cryptic as well. And it would be nice to keep the word
 "Request" because it avoids making the user think they need some knowledge
 ahead of time to use the middle radio button. Anyway, Kathy and I will see
 what we come up with for the label.
 >
 > Assuming you didn't have anything fancy in mind for "then showing the
 available bridges", here are a couple of possibilities for the radio
 button and button labels:
 >
 > [[Image(BridgeDB-UI.png)]]
 >
 > Thoughts? We are open to other ideas as well.

 I like A but don't feel strongly here. Would be good to include the UX
 folks into the discussion I guess. That said I am more than fine if we
 keep this as one item to think about for a proper inclusion into the
 stable series as it might be longer to get right. Leaving that part as
 currently envisioned for the upcoming alpha(s) does not sound bad to me.
 And, hey, maybe I am the only one that is surprised here. :)

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

Re: [tor-bugs] #17521 [Core Tor/Tor]: Support capsicum(4) on FreeBSD

[Tor Bug Tracker & Wiki]

#17521: Support capsicum(4) on FreeBSD
-+-
 Reporter:  yawning  |  Owner:
 |  shawn.webb
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, security, sandboxing, |  Actual Points:
  BSD, capsicum  |
Parent ID:   | Points:
 Reviewer:  ahf  |Sponsor:
-+-

Comment (by shawn.webb):

 It looks like libevent not being Capsicum-friendly also affects Capsicum
 support when Tor is used as a relay. We need to fix libevent first before
 the ORPort and DNSPort options work when Capsicum is enabled via the
 Sandbox option.

 Effectively, that means that this new Capsicum support is only applicable
 to running client nodes.

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

Re: [tor-bugs] #4698 [Core Tor/Tor]: MapAddress should be able to map from invalid .onion names

[Tor Bug Tracker & Wiki]

#4698: MapAddress should be able to map from invalid .onion names
--+
 Reporter:  katmagic  |  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:  tor-hs interface easy naming  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by fristonio):

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


Comment:

 This issue does not exist in tor as of now.
 Tested on Tor Browser and Firefox, MapAddress works perfectly fine.

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

Re: [tor-bugs] #25354 [Internal Services/Tor Sysadmin Team]: torproject.org using insecure ciphers/protocols (SSLv3, 3DES and RC4)

[Tor Bug Tracker & Wiki]

#25354: torproject.org using insecure ciphers/protocols (SSLv3, 3DES and RC4)
-+-
 Reporter:  pege |  Owner:  tpa
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Major| Resolution:  invalid
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 In the meantime you can use: https://thetorproject.github.io/gettor/ if
 it's urgent to share a link to some trustworthy URL to download TOR.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by mcs):

 Replying to [comment:55 mcs]:
 > I think the only reason it works how it does right now is that we were
 trying to stay faithful to Linda's design, which tried hard to reduce the
 number of clicks needed (by removing the wizard and generally streamlining
 things). But let's require the second click. Kathy and I have two
 questions though:
 > a) What do you mean by "then showing the available bridges?" Do you mean
 offering a choice of bridge types (e.g., obfs3, obsf4) or do you mean
 showing bridges that the user has already obtained?
 > b) What text should we use for the radio button label? Introducing
 "BridgeDB" without explaining it does not seem ideal, although the current
 design is somewhat cryptic as well. And it would be nice to keep the word
 "Request" because it avoids making the user think they need some knowledge
 ahead of time to use the middle radio button. Anyway, Kathy and I will see
 what we come up with for the label.

 Assuming you didn't have anything fancy in mind for "then showing the
 available bridges", here are a couple of possibilities for the radio
 button and button labels:

 [[Image(BridgeDB-UI.png)]]

 Thoughts? We are open to other ideas as well.

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

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

[Tor Bug Tracker & Wiki]

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

 * Attachment "BridgeDB-UI.png" removed.

 BridgeDB UI options

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

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

[Tor Bug Tracker & Wiki]

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

 * Attachment "BridgeDB-UI.png" added.

 BridgeDB UI options

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

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

[Tor Bug Tracker & Wiki]

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

 * Attachment "BridgeDB-UI.png" added.

 BridgeDB UI options

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

Re: [tor-bugs] #22689 [Core Tor/Tor]: hs: Stop rend and intro points being used as single hop proxies

[Tor Bug Tracker & Wiki]

#22689: hs: Stop rend and intro points being used as single hop proxies
--+
 Reporter:  teor  |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  relay-safety  |  Actual Points:
Parent ID:  #17945| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  assigned => needs_review


Comment:

 Branch: `ticket22689_033_01`

 It is not that small because I did an HS specific interface but it is as
 simple as the original patch.

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

Re: [tor-bugs] #25354 [Internal Services/Tor Sysadmin Team]: torproject.org using insecure ciphers/protocols (SSLv3, 3DES and RC4)

[Tor Bug Tracker & Wiki]

#25354: torproject.org using insecure ciphers/protocols (SSLv3, 3DES and RC4)
-+-
 Reporter:  pege |  Owner:  tpa
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Major| Resolution:  invalid
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 For context, yes, this week's webserver for www.torproject.org does indeed
 use old risky ciphers.

 We've asked the nice people who set it up to update it to smarter ciphers,
 and they say it will be at least a few days until they succeed.

 Hang in there everybody. :)

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

Re: [tor-bugs] #25333 [Applications/Tor Browser]: NOT SECURE CONECTION please help

[Tor Bug Tracker & Wiki]

#25333: NOT SECURE CONECTION please help
--+---
 Reporter:  kiokawasaki1998   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by Toruser85):

 Replying to [comment:30 mario]:
 > Replying to [comment:29 Nemo]:
 > > Internet Security - Current version - defs up to date.
 > > Replying to [comment:27 Nemo]:
 > > > I'm afraid not.Replying to [comment:26 cypherpunks]:
 > > > > Replying to [comment:25 Nemo]:
 > > > > > Similar situation here.
 > > > > > Dell E6330; Windows 7 Pro; Relatively new Samsung EVO HD; fresh
 load of V7.5; Current Firefox; DuckDuck Go for Tor
 > > > > > Shut down Kaspersky and the result is the same - "Secure
 Connection Failed" with and without HTTPS Everywhere enabled.
 > > > > > I can copy and paste the debug info if that would be helpful but
 there is quite a bit and I don't want to fill up space here unless you
 want me to. If there is a specific section of the debug you'd like to see,
 let me know.
 > > > > > Thank you for your attention to this and your help trying to
 resolve it.
 > > > > Try to use the `meek-amazon` pluggable transport (Click on the
 `Torbutton` (that green onion on your toolbar) > `Tor Network Settings...`
 > `Select a built-in bridge` > `meek-amazon`). Does it work then?
 > > > >
 > > > > Kaspersky has a reputation for doing full TLS decryption since Mr.
 Eugene is a smart puppet.
 >
 > Dear all,
 > I'm using Kaspersky (free edition) too, and I solved the problem as
 following:
 > 1-TOR settings (default )
 > 2- open kaspersky settings -> additional -> Network-> Encrypt connection
 settings -> CHECK the do not scan encrypted connection
 >
 > done
 > thanks for your precious contribute

 done.. it was kaspersky

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by dgoulet):

 Changing the title just to be a tiny bit more accurate about single hop
 client instead of just Tor2web.

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

Re: [tor-bugs] #22688 [Core Tor/Tor]: hs: Make sure HSDir never know service, client, or bridge IP addresses (was: Make sure HSDir3s never know service, client, or bridge IP addresses)

[Tor Bug Tracker & Wiki]

#22688: hs: Make sure HSDir never know service, client, or bridge IP addresses
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, relay-safety  |  Actual Points:  0.3
Parent ID:  #17945| Points:  0.3
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_review => assigned
 * keywords:  prop224, relay-safety, 031-backport, maybe-030-backport-
 with-21406 => tor-hs, relay-safety


Comment:

 Changing ticket title to be for all HS version, not only v3. Assigning to
 teor because the code exists in his #17945 branch.

 Also, removing backport for now, even single service should use a 3-hop
 circuit so I don't think this is mission critical. Feel free to add
 backport keyword if you think it 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] #17945 [Core Tor/Tor]: Stop Tor2Web connecting to (Rendezvous) Single Onion Services

[Tor Bug Tracker & Wiki]

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

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


Comment:

 I'm OK with rend and intro in 033. It is an easy fix because we can easily
 check the two circuits on both sides.

 Agree on the HSDir part to be in 034 and we'll have to try to inject a bit
 more semantic in that function.

 I'm putting back this in "Accepted", sending it to 034 and moving the
 patch for 033 in #22689

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

Re: [tor-bugs] #22689 [Core Tor/Tor]: hs: Stop rend and intro points being used as single hop proxies (was: prop224: Stop rend and intro points being used as single hop proxies)

[Tor Bug Tracker & Wiki]

#22689: hs: Stop rend and intro points being used as single hop proxies
--+
 Reporter:  teor  |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  relay-safety  |  Actual Points:
Parent ID:  #17945| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * owner:  teor => dgoulet
 * keywords:  prop224, relay-safety => relay-safety
 * status:  needs_review => assigned
 * milestone:  Tor: 0.3.4.x-final => Tor: 0.3.3.x-final


Comment:

 Changing ticket title to reflect that it now applies to all HS version.
 Then moving it to 033 and I'm taking it, I'll submit a branch soon. We are
 splitting things out of #17945 so we don't get too confused.

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

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

[Tor Bug Tracker & Wiki]

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

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


Comment:

 Replying to [comment:16 asn]:
 > Two last things:
 > - Does the code that we added in this ticket allow the service to
 recover from this issue where it has no descriptors? That is, will it ever
 rebuild the needed descriptors and rotate them gracefully, or will it get
 permanently stuck in a broken state? My understanding from reading the
 code a bit is that the latter case will happen. Do we care about the
 latter if it happens?

 I think it will get stuck if `current` is NULL and `next` is not. We won't
 be able to rotate nor build a current one if no rotation.

 If both are NULL, it won't get stuck, new desc will be created. If only
 next is NULL, it won't get stuck as it will be built just after.

 Tbh, having a `current == NULL`, which I don't think is possible without
 also having a `next == NULL`, we have a very bad code flow issue. I think
 at that point, we might want the service to stop working properly so the
 operator can notice the BUG() and tell us. I've personally never ever seen
 this so if it happens (like this ticket maybe), it should be rare or if
 not, we'll catch it soon enough.

 > - In `rotate_all_descriptors()` let's add the `BUG` check inside
 `should_rotate_descriptors()`. I think that's conceptually the right place
 to do any check wrt rotating descriptors.

 See fixup commit: `4cad1376c6`

 Notice that I changed a bit the log message to print the desc pointer as
 in we do want to know which desc are NULL.

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

Re: [tor-bugs] #25339 [Applications/Tor Browser]: Install python 3.6 for building HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#25339: Install python 3.6 for building HTTPS-Everywhere
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201802R,  |  Actual Points:
  boklm201802|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

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


Comment:

 There is a patch for review in branch `bug_25339_v2`, using `buster` to
 build https-everywhere:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_25339_v2=734a41c0f986989163ff7536ff84a2a03e00d5cc

 However `buster` is not a stable release yet, so I am wondering how likely
 it is that an update, for instance on the `zip` package, would break the
 reproducibility of the build. Ubuntu Artful is a stable release, so it
 might be less likely to have big updates.

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

Re: [tor-bugs] #24767 [Core Tor/Tor]: All relays are constantly connecting to down relays and failing over and over

[Tor Bug Tracker & Wiki]

#24767: All relays are constantly connecting to down relays and failing over and
over
-+-
 Reporter:  arma |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-dos, performance, |  Actual Points:
  review-group-32, 033-must  |
Parent ID:   | Points:
 Reviewer:  asn, teor|Sponsor:
-+-

Comment (by dgoulet):

 Replying to [comment:22 teor]:
 > There are two design issues here:
 > * the HT implementation only uses 32 bit hashes on 64-bit LP64 systems,
 like macOS and the BSDs, and 32-bit systems (split off into #25365)
 > * the port is user-controlled, so it needs to be hashed before being
 combined with the other hashes

 What is the danger here? The length is fixed so what is the difference
 between "+= 42" or "+= h(42)" ?

 > I fixed the port issue, and the compilation issues in my branch
 bug24767_033_02 on https://github.com/teor2345/tor.git

 For the hash fix, wouldn't it be more efficient to then combined addr +
 digest + port in a buffer and siphash that instead of doing 3 rounds of
 siphash?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25370 [Applications/Tor Browser]: Unexplainably high CPU usage on a specific site

[Tor Bug Tracker & Wiki]

#25370: Unexplainably high CPU usage on a specific site
--+--
 Reporter:  cypherpunks   |  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:|
--+--
 Open TOR. Open Task Manager as well. Go to:

 `https://via.hypothes.is/https://www.google.com/?gws_rd=ssl`

 Wait 50sec, and watch as the CPU usage gets really high when it shouldn't.

 Tested on a Debian based distro with TOR Browser 8.0a2

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

Re: [tor-bugs] #25182 [Core Tor/Tor]: systemd unit file starts Tor before IPv6 address is available

[Tor Bug Tracker & Wiki]

#25182: systemd unit file starts Tor before IPv6 address is available
---+
 Reporter:  sjmurdoch  |  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.3.3.1-alpha
 Severity:  Normal | Resolution:  invalid
 Keywords:  ipv6, systemd  |  Actual Points:
Parent ID:  #24403 | Points:
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * keywords:   => ipv6, systemd
 * parent:   => #24403
 * milestone:   => Tor: 0.3.4.x-final


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

Re: [tor-bugs] #25182 [Core Tor/Tor]: systemd unit file starts Tor before IPv6 address is available

[Tor Bug Tracker & Wiki]

#25182: systemd unit file starts Tor before IPv6 address is available
--+
 Reporter:  sjmurdoch |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.1-alpha
 Severity:  Normal| Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 The relevant cross-platform advice is:
 {{{
 If you write a server: listen on [::], [::1], 0.0.0.0 and 127.0.0.1 only.
 These pseudo-addresses are unconditionally available. If you always bind
 to these addresses you will have code that doesn't have to react to
 network changes, as all you listen on is catch-all and private addresses.
 }}}

 Tor already implements binding to 0.0.0.0 and dynamically determining the
 IPv4 address at runtime. This is the default behaviour when Tor is
 configured using ORPort or DirPort without an explicit address.

 Tor will be able to dynamically determine its IPv6 address when IPv6
 reachability checks (#6939) are implemented. This depends on IPv6 extends
 (#24403).

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

Re: [tor-bugs] #20314 [Applications/Tor Browser]: Make SVG click-to-play and support fallback

[Tor Bug Tracker & Wiki]

#20314: Make SVG click-to-play and support fallback
--+--
 Reporter:  bugzilla  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability, ux-team|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by aprilrussell):

 Sounds good to me. We can omit it in 6.0 and backport it later to 6.0.x as
 soon as the translations (or a sufficiently large part of them) are
 available. Not sure about including the torrc path. I am inclined to omit
 that by arguing that folks who are able to play with their torrc file
 should know where it is (and, sure, I am assuming that our default torrc
 files are not causing this problem or, more precisely, that they are not
 causing that problem in a way a dev knowing what to do would not have hit
 it). kissmanga [https://www.kiss-manga.com] read manga online for free in
 english

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

Re: [tor-bugs] #25369 [Internal Services/Service - lists]: Create tor-...@lists.torproject.org

[Tor Bug Tracker & Wiki]

#25369: Create tor-...@lists.torproject.org
---+
 Reporter:  phoul  |  Owner:  qbi
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by weasel):

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


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

Re: [tor-bugs] #18947 [Applications/Tor Browser]: 6.0a5 is not starting on OS X if put into /Applications

[Tor Bug Tracker & Wiki]

#18947: 6.0a5 is not starting on OS X if put into /Applications
--+
 Reporter:  gk|  Owner:  mcs
 Type:  defect| Status:  closed
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:  fixed
 Keywords:  TorBrowserTeam201605R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by aprilrussell):

 Discovered your post fascinating to peruse. I cannot hold up to see your
 post soon. Good Luck for the up and coming update.This article is truly
 extremely fascinating and successful.Please get in tough with for updating
 new writing ideas. run 3 [https://run2.online/run-3] free online

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25369 [Internal Services/Service - lists]: Create tor-...@lists.torproject.org

[Tor Bug Tracker & Wiki]

#25369: Create tor-...@lists.torproject.org
---+-
 Reporter:  phoul  |  Owner:  qbi
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 Please create the mailing list "tor-sop" with co...@torproject.org as the
 admin. This list will be for accepting applications for the 2018 summer of
 privacy.

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