Re: [tor-bugs] #21312 [Obfuscation/Snowflake]: snowflake-client is pegged at 100% cpu

[Tor Bug Tracker & Wiki]

#21312: snowflake-client is pegged at 100% cpu
---+--
 Reporter:  arlolra|  Owner:  arlolra
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by arlolra):

 > I put some guards around that and now my proxy seems to be happily
 serving connections w/o crash.

 I mean, in go-webrtc,

 {{{
 --- a/peerconnection.go
 +++ b/peerconnection.go
 @@ -44,6 +44,7 @@ import "C"
  import (
 "errors"
 "fmt"
 +   "sync"
 "unsafe"
  )

 @@ -124,6 +125,8 @@ type PeerConnection struct {
 localDescription*SessionDescription
 remoteDescription   *SessionDescription
 canTrickleIceCandidates bool
 +   destroyed   bool
 +   destroyLock *sync.Mutex

 // Event handlers
 OnNegotiationNeededfunc()
 @@ -152,6 +155,7 @@ func NewPeerConnection(config *Configuration)
 (*PeerConnection, error) {
 return nil, errors.New("PeerConnection requires a
 Configuration.")
 }
 pc := new(PeerConnection)
 +   pc.destroyLock = {}
 pc.index = PCMap.Set(pc)
 // Internal CGO Peer wraps the native
 webrtc::PeerConnectionInterface.
 pc.cgoPeer = C.CGO_InitializePeer(C.int(pc.index))
 @@ -169,6 +173,12 @@ func NewPeerConnection(config *Configuration)
 (*PeerConnection, error) {
  }

  func (pc *PeerConnection) Destroy() error {
 +   pc.destroyLock.Lock()
 +   if pc.destroyed {
 +   return nil
 +   }
 +   pc.destroyed = true
 +   pc.destroyLock.Unlock()
 err := pc.Close()
 PCMap.Delete(pc.index)
 C.CGO_DestroyPeer(pc.cgoPeer)
 }}}

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

Re: [tor-bugs] #21312 [Obfuscation/Snowflake]: snowflake-client is pegged at 100% cpu

[Tor Bug Tracker & Wiki]

#21312: snowflake-client is pegged at 100% cpu
---+--
 Reporter:  arlolra|  Owner:  arlolra
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by arlolra):

 > With this patch I got another quick crash on my desktop. Also just after
 the first OnClose, this time a segmentation fault in CGO_Close.

 So now what's happening is that `pc.Destroy()` is being called multiple
 times (3) in the proxy, when the datachannel closes, two of which I
 understand.  I put some guards around that and now my proxy seems to be
 happily serving connections w/o crash.

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

Re: [tor-bugs] #25472 [Obfuscation/Snowflake]: snowflake-client's `-url` option is intolerant of a missing path

[Tor Bug Tracker & Wiki]

#25472: snowflake-client's `-url` option is intolerant of a missing path
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Minor  | Resolution:  fixed
 Keywords:  easy   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dcf):

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


Comment:

 Replying to [comment:4 arlolra]:
 > > Your attached patch looks good.
 >
 > Pushed as https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/commit/?id=42ec097a58cd7a0bf9a6d2e24fe9beeec689c0f4
 >
 > > What do you think? I attached a patch. The URL API is marked
 "experimental"; maybe we don't want to deal with that?
 >
 > Could we add a little defensive code in the shims to exit early if the
 api isn't available?  Seems to require node.js v7 and not implemented in
 IE (but in Edge).

 Eh, let's not worry about it then. It's not really hurting anything as is,
 and we may deal with it all in a later refactoring anyway.

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

Re: [tor-bugs] #21312 [Obfuscation/Snowflake]: snowflake-client is pegged at 100% cpu

[Tor Bug Tracker & Wiki]

#21312: snowflake-client is pegged at 100% cpu
---+--
 Reporter:  arlolra|  Owner:  arlolra
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 Replying to [comment:33 dcf]:
 > Replying to [comment:32 arlolra]:
 > > > Here's a server-webrtc segfault from gdb.
 > >
 > > From the timeline in comment:29, maybe it's a race between the
 datachannel close on the server and reading from the OR (I'm assuming the
 logs never make it because they're async and the segfaults prevents them
 from being written).
 > >
 > > You can try something like,
 >
 > Good call. I tried your idea and added some debugging code to show the
 addresses of the data channel objects; it was definitely crashing while
 trying to dereference a NULL pointer before (notice `0x0` in the output).

 Touching base on server-webrtc, I didn't experience any crashes with it
 after [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/commit/?id=c834c76fc50677cfb98e516e5d9d630ecfe691c2
 c834c76fc5] (explicit frees). I downloaded a few hundred MB through it,
 then let it idle overnight. I was eyeballing the memory usage in top from
 time to time, checking for a slow leak. Here are the samples I happened to
 write down:
 ||=   time=||= mem=||
 || 2018-03-14 03:15|| 1.2%||
 ||03:38|| 2.0%||
 ||03:48|| 2.3%||
 ||04:01|| 2.6%||
 ||04:17|| 2.5%||
 ||04:34|| 2.5%||
 ||16:05|| 3.1%||
 ||16:56|| 3.1%||
 After the server had been allowed to idle for a while, I saw repeated
 write attempts (roughly one per 2 seconds) to a `nil` data connection.
 These would have crashed the server before [https://gitweb.torproject.org
 /pluggable-
 transports/snowflake.git/commit/?id=c834c76fc50677cfb98e516e5d9d630ecfe691c2
 c834c76fc5]. But their repeated nature shows it's not jsut a transient
 race condition, but something persistent.
 {{{
 2018/03/14 17:20:43 Write 543 bytes 0x0 --> WebRTC
 2018/03/14 17:20:45 Write 543 bytes 0x0 --> WebRTC
 2018/03/14 17:20:47 Write 543 bytes 0x0 --> WebRTC
 2018/03/14 17:20:50 Write 543 bytes 0x0 --> WebRTC
 2018/03/14 17:20:52 Write 543 bytes 0x0 --> WebRTC
 2018/03/14 17:20:54 Write 543 bytes 0x0 --> WebRTC
 2018/03/14 17:20:58 Write 543 bytes 0x0 --> WebRTC
 2018/03/14 17:21:00 Write 543 bytes 0x0 --> WebRTC
 2018/03/14 17:21:00 Write 543 bytes 0x0 --> WebRTC
 2018/03/14 17:21:03 Write 543 bytes 0x0 --> WebRTC
 2018/03/14 17:21:05 Write 543 bytes 0x0 --> WebRTC
 2018/03/14 17:21:06 Write 543 bytes 0x0 --> WebRTC
 2018/03/14 17:21:11 Write 543 bytes 0x0 --> WebRTC
 2018/03/14 17:21:12 Write 543 bytes 0x0 --> WebRTC
 2018/03/14 17:21:12 first signal interrupt
 2018/03/14 17:21:13 second signal interrupt
 }}}
 To get this output I just changed the log line:
 {{{
 log.Printf("Write %d bytes %p --> WebRTC", len(b), c.dc)
 }}}

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

Re: [tor-bugs] #21312 [Obfuscation/Snowflake]: snowflake-client is pegged at 100% cpu

[Tor Bug Tracker & Wiki]

#21312: snowflake-client is pegged at 100% cpu
---+--
 Reporter:  arlolra|  Owner:  arlolra
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 Replying to [comment:44 dcf]:
 > Replying to [comment:42 arlolra]:
 > > > Well, CGO_DestroyPeer doesn't appear to be thread-safe; so let's fix
 that.
 > >
 > > Attached a go-webrtc patch.  Can you try running that and seeing if
 you still get these aborts?
 >
 > Yeah I'll try it.

 With this patch I got another quick crash on my desktop. Also just after
 the first `OnClose`, this time a segmentation fault in `CGO_Close`. Here
 is the end of the log:
 {{{
 2018/03/15 04:18:21 OnClose channel
 INFO: peerconnection.go:503: fired OnIceConnectionStateChange:  1
 INFO: peerconnection.go:435: fired OnSignalingStateChange:  1 Closed
 [Thread 0x7fffd7fff700 (LWP 11244) exited]
 [Thread 0x7fffecff9700 (LWP 11243) exited]
 [Thread 0x74587700 (LWP 11239) exited]
 [Thread 0x74688700 (LWP 11238) exited]
 [Thread 0x7fffed7fa700 (LWP 11237) exited]
 [Thread 0x7fffedffb700 (LWP 11236) exited]
 2018/03/15 04:18:21 datachannelHandler ends

 Thread 7 "proxy-go" received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 0x7fffeeffd700 (LWP 11229)]
 CGO_Close (peer=) at
 /home/david/go/src/github.com/keroserene/go-webrtc/peerconnection.cc:481
 481   cPeer->pc_->Close();
 (gdb) bt
 #0  CGO_Close (peer=) at
 /home/david/go/src/github.com/keroserene/go-webrtc/peerconnection.cc:481
 #1  0x55726390 in runtime.asmcgocall () at
 /usr/lib/go-1.7/src/runtime/asm_amd64.s:590
 #2  0x00c42016dd70 in ?? ()
 #3  0x556d0e0d in runtime.cgocall (fn=0x0, arg=0xc420001860,
 ~r2=-285225288)
 at /usr/lib/go-1.7/src/runtime/cgocall.go:115
 #4  0x00c4200018a0 in ?? ()
 #5  0x in ?? ()
 }}}
 I verified with `go build -x` that peerconnection.cc was being recompiled
 when I built proxy-go.

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

Re: [tor-bugs] #21312 [Obfuscation/Snowflake]: snowflake-client is pegged at 100% cpu

[Tor Bug Tracker & Wiki]

#21312: snowflake-client is pegged at 100% cpu
---+--
 Reporter:  arlolra|  Owner:  arlolra
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by arlolra):

 > Yeah I'll try it.

 Nevermind, don't bother.  Was able to reproduce with your steps as well.
 I'll let you know when I have something concrete.  Thanks.

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

Re: [tor-bugs] #21312 [Obfuscation/Snowflake]: snowflake-client is pegged at 100% cpu

[Tor Bug Tracker & Wiki]

#21312: snowflake-client is pegged at 100% cpu
---+--
 Reporter:  arlolra|  Owner:  arlolra
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 Replying to [comment:42 arlolra]:
 > > Well, CGO_DestroyPeer doesn't appear to be thread-safe; so let's fix
 that.
 >
 > Attached a go-webrtc patch.  Can you try running that and seeing if you
 still get these aborts?

 Yeah I'll try 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] #21312 [Obfuscation/Snowflake]: snowflake-client is pegged at 100% cpu

[Tor Bug Tracker & Wiki]

#21312: snowflake-client is pegged at 100% cpu
---+--
 Reporter:  arlolra|  Owner:  arlolra
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 Replying to [comment:41 arlolra]:
 > > Perhaps "Pure virtual method called"? I'm not sure.
 >
 > Well, `CGO_DestroyPeer` doesn't appear to be thread-safe; so let's fix
 that.  The client is currently defaulting to 1 concurrent peer, which
 would explain why it doesn't hit this issue, if that's the cause.  The
 proxies, which are handling multiple peers, each of which are voluntarily
 exiting every 30s of inactivity, seem like they could be hitting some
 contention there, but possibly not at the rate things are failing?

 I just reproduced the crash on my desktop. I ran `gdb --args ./proxy-go
 -log snowflake.log`, then `r`, and just waited for someone to use it (it
 took 20 minutes). It is indeed "pure virtual method called". It looks to
 me like there was only one client connected at the time; so it seems that
 contention among multiple clients isn't necessary.

 The full log is in attachment:proxy-go-abort.20180314.log​. It has not
 only gdb output, but also stdout/stderr and the contents of the log file,
 interleaved. Potentially of note: the abort happens immediately after the
 first `OnClose channel`. The client had been connected for 78 seconds.

 Here is the last part of attachment:proxy-go-abort.20180314.log:
 {{{
 2018/03/15 03:53:11 Write 3113 bytes --> WebRTC
 2018/03/15 03:53:11 Write 1571 bytes --> WebRTC
 2018/03/15 03:53:11 Write 3627 bytes --> WebRTC
 2018/03/15 03:53:11 OnMessage <--- 543 bytes
 2018/03/15 03:53:14 broker returns: 504
 2018/03/15 03:53:24 broker returns: 504
 2018/03/15 03:53:39 broker returns: 504
 2018/03/15 03:53:42 OnClose channel
 INFO: peerconnection.go:503: fired OnIceConnectionStateChange:  1
 INFO: peerconnection.go:435: fired OnSignalingStateChange:  1 Closed
 [Thread 0x7fffd77fe700 (LWP 10782) exited]
 [Thread 0x7fffd7fff700 (LWP 10781) exited]
 [Thread 0x74587700 (LWP 10777) exited]
 pure virtual method called
 terminate called without an active exception
 [Thread 0x74688700 (LWP 10776) exited]
 [Thread 0x7fffedffb700 (LWP 10774) exited]
 [Thread 0x7fffed7fa700 (LWP 10775) exited]

 Thread 6 "proxy-go" received signal SIGABRT, Aborted.
 [Switching to Thread 0x7fffef7fe700 (LWP 10491)]
 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
 51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
 (gdb) bt
 #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
 #1  0x7686842a in __GI_abort () at abort.c:89
 #2  0x7717f0ad in __gnu_cxx::__verbose_terminate_handler() () from
 /usr/lib/x86_64-linux-gnu/libstdc++.so.6
 #3  0x7717d066 in ?? () from /usr/lib/x86_64-linux-
 gnu/libstdc++.so.6
 #4  0x7717d0b1 in std::terminate() () from /usr/lib/x86_64-linux-
 gnu/libstdc++.so.6
 #5  0x7717db8f in __cxa_pure_virtual () from /usr/lib/x86_64
 -linux-gnu/libstdc++.so.6
 #6  0x558dd957 in rtc::scoped_refptr::scoped_refptr (r=...,
 this=)
 at ./include/webrtc/base/scoped_ref_ptr.h:82
 #7
 
__gnu_cxx::__ops::_Iter_pred<CGO_DestroyPeer(CGO_Peer)::<lambda(rtc::scoped_refptr)>
 >::operator()<__gnu_cxx::__normal_iterator<rtc::scoped_refptr*,
 std::vector<rtc::scoped_refptr > > > (__it=...,
 this=) at
 /usr/include/c++/6/bits/predefined_ops.h:241
 #8  std::__find_if<__gnu_cxx::__normal_iterator<rtc::scoped_refptr*,
 std::vector<rtc::scoped_refptr > >,
 
__gnu_cxx::__ops::_Iter_pred<CGO_DestroyPeer(CGO_Peer)::<lambda(rtc::scoped_refptr)>
 > > (__pred=..., __last=
   {ptr_ = 0x7fffe298}, __first={ptr_ = 0x7fffea20}) at
 /usr/include/c++/6/bits/stl_algo.h:148
 #9  std::__find_if<__gnu_cxx::__normal_iterator<rtc::scoped_refptr*,
 std::vector<rtc::scoped_refptr > >,
 
__gnu_cxx::__ops::_Iter_pred<CGO_DestroyPeer(CGO_Peer)::<lambda(rtc::scoped_refptr)>
 > > (__pred=..., __last=...,
 __first=...) at /usr/include/c++/6/bits/stl_algo.h:162
 #10
 std::__remove_if<__gnu_cxx::__normal_iterator<rtc::scoped_refptr*,
 std::vector<rtc::scoped_refptr > >,
 
__gnu_cxx::__ops::_Iter_pred<CGO_DestroyPeer(CGO_Peer)::<lambda(rtc::scoped_refptr)>
 > > (__pred=..., __last=
   {ptr_ = 0x7fffe298}, __first=...) at
 /usr/include/c++/6/bits/stl_algo.h:860
 #11 std::re

Re: [tor-bugs] #21312 [Obfuscation/Snowflake]: snowflake-client is pegged at 100% cpu

[Tor Bug Tracker & Wiki]

#21312: snowflake-client is pegged at 100% cpu
---+--
 Reporter:  arlolra|  Owner:  arlolra
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by arlolra):

 > Well, CGO_DestroyPeer doesn't appear to be thread-safe; so let's fix
 that.

 Attached a go-webrtc patch.  Can you try running that and seeing if you
 still get these aborts?

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

Re: [tor-bugs] #21312 [Obfuscation/Snowflake]: snowflake-client is pegged at 100% cpu

[Tor Bug Tracker & Wiki]

#21312: snowflake-client is pegged at 100% cpu
---+--
 Reporter:  arlolra|  Owner:  arlolra
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by arlolra):

 * Attachment "0001-Add-locks-around-erases.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

Re: [tor-bugs] #21312 [Obfuscation/Snowflake]: snowflake-client is pegged at 100% cpu

[Tor Bug Tracker & Wiki]

#21312: snowflake-client is pegged at 100% cpu
---+--
 Reporter:  arlolra|  Owner:  arlolra
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by dcf):

 * Attachment "proxy-go-abort.20180314.log" added.

 gdb and stdout/stderr of a "pure virtual method called" in proxy-go

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

Re: [tor-bugs] #21312 [Obfuscation/Snowflake]: snowflake-client is pegged at 100% cpu

[Tor Bug Tracker & Wiki]

#21312: snowflake-client is pegged at 100% cpu
---+--
 Reporter:  arlolra|  Owner:  arlolra
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by arlolra):

 > Perhaps "Pure virtual method called"? I'm not sure.

 Well, `CGO_DestroyPeer` doesn't appear to be thread-safe; so let's fix
 that.  The client is currently defaulting to 1 concurrent peer, which
 would explain why it doesn't hit this issue, if that's the cause.  The
 proxies, which are handling multiple peers, each of which are voluntarily
 exiting every 30s of inactivity, seem like they could be hitting some
 contention there, but possibly not at the rate things are failing?

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

Re: [tor-bugs] #25505 [Core Tor]: Netflow padding should inspect circuitmux queues

[Tor Bug Tracker & Wiki]

#25505: Netflow padding should inspect circuitmux queues
---+--
 Reporter:  mikeperry  |  Owner:  (none)
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by mikeperry):

 * status:  assigned => needs_review


Comment:

 mikeperry/bug25505.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25505 [Core Tor]: Netflow padding should inspect circuitmux queues

[Tor Bug Tracker & Wiki]

#25505: Netflow padding should inspect circuitmux queues
---+--
 Reporter:  mikeperry  |  Owner:  (none)
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Core Tor   |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 The netflow padding code only tries to transmit padding if the link is
 otherwise idle. Dgoulet pointed out that checking the channel outbuf is
 not enough -- since kist that is now mostly empty. We need to inspect the
 circuitmux queue also.

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

Re: [tor-bugs] #21312 [Obfuscation/Snowflake]: snowflake-client is pegged at 100% cpu

[Tor Bug Tracker & Wiki]

#21312: snowflake-client is pegged at 100% cpu
---+--
 Reporter:  arlolra|  Owner:  arlolra
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 Replying to [comment:39 dcf]:
 > I'll try connecting a debugger to one of the frequently restarting
 instances and see if there's anything obvious.

 It didn't take long to get a crash in the debugger. It's not a segfault;
 it's a runtime abort inside `CGO_DestroyPeer`. (Perhaps "Pure virtual
 method called"? I'm not sure.)

 {{{
 (gdb) c
 Continuing.
 [New Thread 0x7f4d6cfc9700 (LWP 16471)]
 [Thread 0x7f4d6d0ca700 (LWP 16457) exited]

 Thread 3 "proxy-go" received signal SIGABRT, Aborted.
 [Switching to Thread 0x7f4d76337700 (LWP 16396)]
 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
 51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
 (gdb) bt
 #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
 #1  0x7f4d773b53fa in __GI_abort () at abort.c:89
 #2  0x7f4d77ccc0ad in __gnu_cxx::__verbose_terminate_handler() () from
 /usr/lib/x86_64-linux-gnu/libstdc++.so.6
 #3  0x7f4d77cca066 in ?? () from /usr/lib/x86_64-linux-
 gnu/libstdc++.so.6
 #4  0x7f4d77cca0b1 in std::terminate() () from /usr/lib/x86_64-linux-
 gnu/libstdc++.so.6
 #5  0x7f4d77ccab8f in __cxa_pure_virtual () from /usr/lib/x86_64
 -linux-gnu/libstdc++.so.6
 #6  0x561ddf051957 in rtc::scoped_refptr::scoped_refptr (r=...,
 this=)
 at ./include/webrtc/base/scoped_ref_ptr.h:82
 #7
 
__gnu_cxx::__ops::_Iter_pred
 >::operator()<__gnu_cxx::__normal_iterator > > (__it=...,
 this=) at
 /usr/include/c++/6/bits/predefined_ops.h:241
 #8  std::__find_if<__gnu_cxx::__normal_iterator >,
 
__gnu_cxx::__ops::_Iter_pred
 > > (__pred=..., __last=
   {ptr_ = 0x}, __first={ptr_ = 0x7f4d580008c0}) at
 /usr/include/c++/6/bits/stl_algo.h:148
 #9  std::__find_if<__gnu_cxx::__normal_iterator >,
 
__gnu_cxx::__ops::_Iter_pred
 > > (__pred=..., __last=...,
 __first=...) at /usr/include/c++/6/bits/stl_algo.h:162
 #10
 std::__remove_if<__gnu_cxx::__normal_iterator >,
 
__gnu_cxx::__ops::_Iter_pred
 > > (__pred=..., __last=
   {ptr_ = 0x}, __first=...) at
 /usr/include/c++/6/bits/stl_algo.h:860
 #11 std::remove_if<__gnu_cxx::__normal_iterator >,
 CGO_DestroyPeer(CGO_Peer):: >
 (__pred=..., __last=..., __first=...)
 at /usr/include/c++/6/bits/stl_algo.h:937
 #12 CGO_DestroyPeer (cgoPeer=0x7f4d580008c0)
 at /home/david/go/src/github.com/keroserene/go-
 webrtc/peerconnection.cc:249
 #13 0x561ddee9a350 in runtime.asmcgocall () at
 /usr/lib/go-1.7/src/runtime/asm_amd64.s:590
 #14 0x00c420117de0 in ?? ()
 #15 0x561ddee44dcd in runtime.cgocall (fn=0x0, arg=0xc42ea0,
 ~r2=1983082168)
 at /usr/lib/go-1.7/src/runtime/cgocall.go:115
 #16 0x00c420013500 in ?? ()
 #17 0x in ?? ()
 }}}

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

Re: [tor-bugs] #21312 [Obfuscation/Snowflake]: snowflake-client is pegged at 100% cpu

[Tor Bug Tracker & Wiki]

#21312: snowflake-client is pegged at 100% cpu
---+--
 Reporter:  arlolra|  Owner:  arlolra
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 Replying to [comment:34 dcf]:
 > It does appear to be the case that proxy-go is crashing and being
 restarted. One of the instances was automatically restarted 6 times since
 I started it manually 30 minutes ago.
 > I'll let it run overnight, and tomorrow I plan to try an analogous patch
 to the one in comment:32. I've also re-started the memory and file
 descriptor monitors, in case the memory leak was only being masked by
 frequent restarts.

 Well, I tried the `nil` check patch for proxy-go, and it seems that it is
 still restarting frequently :( So either there's a crash that remains
 unfixed even after the `nil` check, or there's something else going on
 that we don't understand.

  * The first blue line is [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/commit/?id=44ab82bc612dac3f9605afd44f057ef199b2cc12
 44ab82bc61], which just adds a "starting" marker to the log.
  * The second blue line is [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/commit/?id=f2abf5b60c289103d8661b8e54b3d3aee43a4aaf
 f2abf5b60c], which tries to protect against the crash with a `nil` check.

  * The "appengine" section represents the proxies connected to
 snowflake.appspot.com broker; i.e. the one that users are actually using.
  * The "standalone" section represents the proxies connected to the
 [ticket:22874 standalone broker] snowflake-broker.bamsoftware.com; i.e.
 the one nobody is using unless they went out of their way to configure it.
 You'll notice that these ones are mostly being restarted externally every
 1h, 2h, 10h, which is how I configured them and is expected. I don't know
 what accounts for the restarts between about 2018-03-14 07:30:00 and
 2018-03-14 10:00:00.

 [[Image(proxy-go-starting.20180314.png)]]

 I'll try connecting a debugger to one of the frequently restarting
 instances and see if there's anything obvious.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21312#comment:39>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21312 [Obfuscation/Snowflake]: snowflake-client is pegged at 100% cpu

[Tor Bug Tracker & Wiki]

#21312: snowflake-client is pegged at 100% cpu
---+--
 Reporter:  arlolra|  Owner:  arlolra
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by dcf):

 * Attachment "proxy-go-starting.20180314.png" added.


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

Re: [tor-bugs] #21312 [Obfuscation/Snowflake]: snowflake-client is pegged at 100% cpu

[Tor Bug Tracker & Wiki]

#21312: snowflake-client is pegged at 100% cpu
---+--
 Reporter:  arlolra|  Owner:  arlolra
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by dcf):

 * Attachment "proxy-go-log.20180314.R" added.


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

Re: [tor-bugs] #21312 [Obfuscation/Snowflake]: snowflake-client is pegged at 100% cpu

[Tor Bug Tracker & Wiki]

#21312: snowflake-client is pegged at 100% cpu
---+--
 Reporter:  arlolra|  Owner:  arlolra
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by dcf):

 * Attachment "proxy-go-starting.20180314.log" added.

 `grep starting *.log | sed -e 's/\(.*\)-\([0-9]\+h\)\.log:\(..
 ..:..:..\) .*/\1,\2,\3/' > starting.log`

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by chelseakomlo):

 Cool, thanks for clarifying and for working on this.

 Another necessary criteria to think about for this effort is being able to
 run individual tests, or tests at a module level to ensure a quick
 feedback 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] #25386 [Core Tor/Tor]: fix rust tests

[Tor Bug Tracker & Wiki]

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

Comment (by Hello71):

 Replying to [comment:15 chelseakomlo]:
 > Hi, apologies for the late review, but is there a reason why the #3
 option in the description is for doctests only? Ideally, we would want
 linking for at minimum integration tests, ideally all levels of tests.

 er, I meant all tests. everything that gets run by `cargo test`.

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

Re: [tor-bugs] #21312 [Obfuscation/Snowflake]: snowflake-client is pegged at 100% cpu

[Tor Bug Tracker & Wiki]

#21312: snowflake-client is pegged at 100% cpu
---+--
 Reporter:  arlolra|  Owner:  arlolra
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by arlolra):

 > Will do.

 Attached is a patch to try.  I've been running the client with some
 success.

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

Re: [tor-bugs] #21312 [Obfuscation/Snowflake]: snowflake-client is pegged at 100% cpu

[Tor Bug Tracker & Wiki]

#21312: snowflake-client is pegged at 100% cpu
---+--
 Reporter:  arlolra|  Owner:  arlolra
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by arlolra):

 * Attachment "0001-Add-synchronization-around-destroying-
 dataChannels.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

Re: [tor-bugs] #25291 [Core Tor/Tor]: get rid of redundant should_record_bridge_info() call in options_act()

[Tor Bug Tracker & Wiki]

#25291: get rid of redundant should_record_bridge_info() call in options_act()
--+
 Reporter:  arma  |  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:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by arma):

 * status:  new => needs_review


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

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

[Tor Bug Tracker & Wiki]

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

Comment (by chelseakomlo):

 Hi, apologies for the late review, but is there a reason why the #3 option
 in the description is for doctests only? Ideally, we would want linking
 for at minimum integration tests, ideally all levels of 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] #25386 [Core Tor/Tor]: fix rust tests

[Tor Bug Tracker & Wiki]

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

 * cc: chelseakomlo (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] #25291 [Core Tor/Tor]: get rid of redundant should_record_bridge_info() call in options_act()

[Tor Bug Tracker & Wiki]

#25291: get rid of redundant should_record_bridge_info() call in options_act()
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by neel):

 I have a patch which (hopefully) solves this. The filename is
 b25291-p1.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] #25291 [Core Tor/Tor]: get rid of redundant should_record_bridge_info() call in options_act()

[Tor Bug Tracker & Wiki]

#25291: get rid of redundant should_record_bridge_info() call in options_act()
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by neel):

 * Attachment "b25291-p1.patch" added.

 [PATCH] Remove redundant should_record_bridge_info() call in options_act()
 (Revision 1)

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

Re: [tor-bugs] #24031 [Core Tor/Tor]: Protover.rs could use a better algorithm

[Tor Bug Tracker & Wiki]

#24031: Protover.rs could use a better algorithm
+
 Reporter:  nickm   |  Owner:  isis
 Type:  defect  | Status:  accepted
 Priority:  High|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  rust 033-must protover  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+

Comment (by isis):

 Replying to [comment:5 nickm]:
 > (FWIW, I think it would be okay to defer this to 0.3.4 if it isn't fast.
 We can just say "don't use Rust on dirauths yet", right?)

 Although, also yes, we should advise authorities not to use Rust until
 #24265 is finished, otherwise we risk splitting the vote.

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

Re: [tor-bugs] #24031 [Core Tor/Tor]: Protover.rs could use a better algorithm

[Tor Bug Tracker & Wiki]

#24031: Protover.rs could use a better algorithm
+
 Reporter:  nickm   |  Owner:  isis
 Type:  defect  | Status:  accepted
 Priority:  High|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  rust 033-must protover  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+
Changes (by isis):

 * Attachment "main.rs" 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] #24031 [Core Tor/Tor]: Protover.rs could use a better algorithm

[Tor Bug Tracker & Wiki]

#24031: Protover.rs could use a better algorithm
+
 Reporter:  nickm   |  Owner:  isis
 Type:  defect  | Status:  accepted
 Priority:  High|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  rust 033-must protover  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+

Comment (by isis):

 Replying to [comment:5 nickm]:
 > (FWIW, I think it would be okay to defer this to 0.3.4 if it isn't fast.
 We can just say "don't use Rust on dirauths yet", right?)

 I think it really does matter to get it in, even if we advise dirauths
 against using Rust, due to the potential for DoS that teor mentioned.
 Wouldn't the attack vector look something like this?:

 1. A bad relay with alternate/modified tor implementation says `Link
 1-65536,LinkAuth 1-65536,Relay 1-65536,HSIntro 1-65536,HSRend
 1-65536,HSDir 1-65536,DirCache 1-65536,Desc 1-65536,Microdesc 1-65536,Cons
 1-65536`.

 2. The dirauths parse that in C and allow it.

 3. A Rust relay/client gets this consensus and suddenly it's got a HashSet
 with 10 keys, each one with 65536 32-bit integers in it, so that's
 2560.8594 kilobytes allocated per relay that does this. (according to this
 [XXX this tiny rust program])

 4. Bad relay operator spins up ~400 relays and suddenly every Rust-enabled
 relay/client in the network is using over 1 GB of memory.

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

Re: [tor-bugs] #25504 [Core Tor/Tor]: Find more generic ways to handle smartlist_t/Vec between C and Rust

[Tor Bug Tracker & Wiki]

#25504: Find more generic ways to handle smartlist_t/Vec between C and Rust
--+
 Reporter:  isis  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust, datatypes, ffi  |  Actual Points:
Parent ID:| Points:  3
 Reviewer:|Sponsor:  Sponsor8-can
--+
Changes (by catalyst):

 * cc: catalyst (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] #25453 [Core Tor/Nyx]: When I start nyx in small terminal then I expand the terminal window and the "cpu %" disappears

[Tor Bug Tracker & Wiki]

#25453: When I start nyx in small terminal then I expand the terminal window and
the "cpu %" disappears
---+---
 Reporter:  Dbryrtfbcbhgf  |  Owner:  atagar
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Core Tor/Nyx   |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by cypherpunks):

 * status:  new => needs_information


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

Re: [tor-bugs] #24902 [Core Tor/Tor]: Denial of Service mitigation subsystem

[Tor Bug Tracker & Wiki]

#24902: Denial of Service mitigation subsystem
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  closed
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-dos, tor-relay, review-  |  Actual Points:
  group-30, 029-backport, 031-backport,  |
  032-backport, review-group-31, SponsorV|
Parent ID:   | Points:
 Reviewer:  arma |Sponsor:
-+-
Changes (by cypherpunks):

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


Comment:

 @hurus my understanding is that the parameters will be weakened as times
 goes on, since this is just an emergency thing to do since the recent DDoS
 was very hard on the network. As a result now the DDoSers stopped and
 moved on.

 In the meantime you can set a guard node that doesn't have a Tor version
 with the recent DDoS mitigation. You can easily find them on the relay
 search in metrics.torproject.org

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

Re: [tor-bugs] #25310 [Core Tor/Tor]: Document our policy for Rust dependencies

[Tor Bug Tracker & Wiki]

#25310: Document our policy for Rust dependencies
+--
 Reporter:  isis|  Owner:  (none)
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  rust, tor-doc, review-group-35  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:  SponsorM
+--
Changes (by isis):

 * status:  new => needs_review
 * keywords:  rust, tor-doc => rust, tor-doc, review-group-35


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

Re: [tor-bugs] #24902 [Core Tor/Tor]: Denial of Service mitigation subsystem

[Tor Bug Tracker & Wiki]

#24902: Denial of Service mitigation subsystem
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  reopened
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dos, tor-relay, review-  |  Actual Points:
  group-30, 029-backport, 031-backport,  |
  032-backport, review-group-31, SponsorV|
Parent ID:   | Points:
 Reviewer:  arma |Sponsor:
-+-
Changes (by hurus):

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


Comment:

 It is a crazy decision to merge those changes.

 Some thoughts:

 1. Since release of 0.2.9.15, 0.3.1.10, 0.3.2.10 i myself as an extensive
 user of tor, my internal scripts which scan Tor network and monitored
 onion sites started to see frequent unexpected broken requests.

 It looks like this:
 You browse your wished onion and then suddently when you change or refresh
 the page, connection immediately drops. Tor Browser shows 'Unable to
 connect' message in this case.

 It happens at around 1% of requests at the moment in my tests. And i
 suspect that number to be much higher when more relays will update or
 consensus will change.

 I suspect such behaviour will lead to inability for Tor network to keep
 it's usage patterns. Users will not use system which randomly drops
 connections. Before Tor was very reliable. For years of usage i never
 noticed any dropped connection issues without proper automatic
 reconnection in place. Regardless of how relays were loaded, everything
 was smooth.

 2. Such feature as dropping connections is very close to 'shadow ban'. We
 can end up to censor Tor network by Tor network. Tor network was made to
 fight censorship, but 'shadow ban' and 'connection drop' is a way to the
 other direction - to the censorship / selectivity of whom allowed to query
 Tor network and whom is not. This is not a way which Tor Project should
 follow to.

 3. We may potentially face a situation where relays will drop all or most
 connections and Tor client will not be ever able to establish connection
 with a rate more than a crazy minimal (e.g. 5 requests per second). Such
 rate is not suitable for a regular browsing. Even if we hope that all web
 properties are ideally optimized, there are still conditions which will
 lead to problems. Most web properties usually use 5 - 200 elements per
 page which are loaded simultaneously. It usually means 20 constant
 concurrent connections and 20 - 500 requests per second on each client.
 Means that with usual limits no one will correctly load all elements of a
 web property.

 4. Under tests there was indicator of incorrectly used 'malicious' word.
 You were counting requests to be 'malicious' but you have no clue are they
 'malicious' at all. You are likely block regular browsing of high volume /
 less optimized web properties but you pretending that you blocking
 something 'malicious'. I highly recommend to remove that word as it is
 incorrect and do not show reality.

 5. Is it really a way to go to make limits per IPv4 address in modern
 world? We live in IPv4-shortage world. We live in the world of NAT and
 potentially tens of clients per IPv4 address. By limiting IPv4 we only
 limit real users which for some reason send too much requests from their
 IPv4 address.
 At start of the century it was a way to go. Nowadays, that's no-op. Such
 behaviour is suicidal for any online instance.

 6. Is it really a way to go to make limits per IPv6 address in modern
 world? We can blindly imagine that attacker can potentially use billions
 of IPv6 addresses. Limiting activity per IPv6 addresses will not impact
 DOS behaviour in any way but oppositely will cause refuse of regular
 clients which do not trying to bypass specific mitigations.

 7. Why do we limit usage patterns like crawling or high-loaded projects
 which are trying to lower costs by using a single IP address? Are those
 not allowed usage patterns on Tor? I doubt so. Current set of patches
 forces any service which are using Tor network extensively to build hard
 expensive systems to simply use Tor network for anything high-volumetric.


 All in all i think those changes are horrible and should be either
 reverted and reconsidered. It is one of the most harmful commitment in
 years of Tor developement by my opinion. It looks like this set of patches
 was made for a different world, not the one where we live. As it is
 disconnected from reality. 

Re: [tor-bugs] #25310 [Core Tor/Tor]: Document our policy for Rust dependencies

[Tor Bug Tracker & Wiki]

#25310: Document our policy for Rust dependencies
---+
 Reporter:  isis   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  rust, tor-doc  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:  SponsorM
---+

Comment (by isis):

 The documentation on our policy is in my `bug25310`
 [https://gitweb.torproject.org/user/isis/tor.git/log/?h=bug25310 branch].
 Additionally, I've added another commit for a script for
 updating/adding/removing Rust dependencies, at
 `scripts/maint/updateRustDependencies.sh`. There's documentation in the
 script, as well as in the dependencies section of
 `doc/HACKING/CodingStandardsRust.md`. Finally, I ran the script to test it
 how easy it was to use, and how intuitive its error messages were, by
 updating our current dependency on libc from 0.2.22 to 0.2.39 (there's a
 [https://github.com/rust-
 lang/libc/commits/master?after=9c561768f9435428d847f18fd777dbd4e369317d+1
 bunch of fixes], mostly for *BSD and Solaris systems).  The changes for
 that are also included, and require merging my `update/libc-0.2.39`
 [https://github.com/isislovecruft/tor-rust-
 dependencies/tree/update/libc-0.2.39 branch] (from
 https://github.com/isislovecruft/tor-rust-dependencies) into the tor-rust-
 dependencies repo.

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

Re: [tor-bugs] #24608 [Core Tor/Tor]: Update our Cargo.lock file to remove the deprecated and removed [root] section

[Tor Bug Tracker & Wiki]

#24608: Update our Cargo.lock file to remove the deprecated and removed [root]
section
-+-
 Reporter:  isis |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.6-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  rust, cargo, rust-pilot, tor-ci  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-
Changes (by isis):

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


Comment:

 This was fixed upstream and appears to no longer be necessary. Patches for
 updating dependencies (and maintaining them) are in #25310.

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

Re: [tor-bugs] #25137 [Obfuscation/Censorship analysis]: Tor blocked in UAE

[Tor Bug Tracker & Wiki]

#25137: Tor blocked in UAE
-+
 Reporter:  mwolfe   |  Owner:  dcf
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  censorship block ae  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by cypherpunks):

 > If it's not that, I'm not sure what it could be.

 Fresh Guard.

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

Re: [tor-bugs] #25368 [Core Tor/Tor]: Update the Tor Rust coding standards for new types

[Tor Bug Tracker & Wiki]

#25368: Update the Tor Rust coding standards for new types
+--
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  doc, rust, review-group-34  |  Actual Points:
Parent ID:  #23061  | Points:  0.5
 Reviewer:  isis|Sponsor:
+--
Changes (by isis):

 * status:  assigned => 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] #25368 [Core Tor/Tor]: Update the Tor Rust coding standards for new types

[Tor Bug Tracker & Wiki]

#25368: Update the Tor Rust coding standards for new types
+--
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  doc, rust, review-group-34  |  Actual Points:
Parent ID:  #23061  | Points:  0.5
 Reviewer:  isis|Sponsor:
+--

Comment (by isis):

 I made #25504 for genericising the `smartlist_t`/`Vec` stuff.

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

Re: [tor-bugs] #25137 [Obfuscation/Censorship analysis]: Tor blocked in UAE

[Tor Bug Tracker & Wiki]

#25137: Tor blocked in UAE
-+
 Reporter:  mwolfe   |  Owner:  dcf
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  censorship block ae  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by dcf):

 Replying to [comment:32 mwolfe]:
 > Today, I got Tor 8.a3 and it worked without any bridges. I wasn't sure
 if the UAE stopped blocking Tor, or if 8.a3 fixed the problem, so I tried
 one of my old Tor 7.a and it could not load the network without meek,
 while 8.a3 can load without any bridges.

 Hmm, maybe it has to do with the new directory authority bastet, which got
 added in Tor Browser 7.0.10 (2017-11-14) and 7.5a8 (2017-11-15), and had
 an IPv6 address added in Tor Browser 7.0.11 and 7.5a9 (2017-12-09). The
 existing directory authority Longclaw also changed its IP address in Tor
 Browser 7.0.10/7.5a8.

 If the censors are only blocking directory authorities, such a change may
 have caught them off guard. If it's not that, I'm not sure what it could
 be.

 I just added entries related to the above to the metrics timeline:
   [[doc/MetricsTimeline?action=diff=239_version=237]]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25504 [Core Tor/Tor]: Find more generic ways to handle smartlist_t/Vec between C and Rust

[Tor Bug Tracker & Wiki]

#25504: Find more generic ways to handle smartlist_t/Vec between C and Rust
--+--
 Reporter:  isis  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  rust, datatypes, ffi
Actual Points:|  Parent ID:
   Points:  3 |   Reviewer:
  Sponsor:  Sponsor8-can  |
--+--
 From #25368, we discussed having a possibly more generic and/or more rusty
 way to handle our `smartlist_t`s in C (and whatever underlying types the
 smartlist contains). Right now we have a `Stringlist` type in
 `src/rust/smartlist/smartlist.rs`, which is a Rust representation of
 `smartlist_t` using C types, and then we have a conversion between that
 and a `Vec`:

 {{{#!rust
 pub trait Smartlist {
 fn get_list() -> Vec;
 }

 #[repr(C)]
 pub struct Stringlist {
 pub list: *const *const c_char,
 pub num_used: c_int,
 pub capacity: c_int,
 }

 impl Smartlist for Stringlist {
 fn get_list() -> Vec {
 // [...]
 }
 }
 }}}

 I have not thought about this nearly as much as komlo has, but maybe one
 way to do it is to have direct conversion between a `smartlist_t` and a
 `Vec`, where `T` is probably an opaque pointer to whatever type in C,
 ''or'' `T` is only allowed to be a `String` which we've copied from a non-
 NULL `char*` (e.g. `impl From for Vec`, or something,
 and then keep `Stringlist` private since internally it's a bunch of C
 types that we don't want propagating into our more Rusty code).

 Another idea might be to only handle `Vec`-like things in Rust (if/when
 we move to the Rust-is-required phase), since we already have a nice
 datatype there, and then provide safe interfaces for C code to do all the
 things with/to the vectors that it currently does. (This sounds easier and
 more maintainable to me.)

 We should probably brainstorm other ideas of how we're going to do this
 generically moving forward, because our C code uses smartlists everywhere.

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

Re: [tor-bugs] #25492 [Core Tor/Nyx]: Fix nyx crashing when failing to write torrc.

[Tor Bug Tracker & Wiki]

#25492: Fix nyx crashing when failing to write torrc.
--+
 Reporter:  Guinness  |  Owner:  atagar
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by atagar):

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


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

Re: [tor-bugs] #25492 [Core Tor/Nyx]: Fix nyx crashing when failing to write torrc.

[Tor Bug Tracker & Wiki]

#25492: Fix nyx crashing when failing to write torrc.
--+
 Reporter:  Guinness  |  Owner:  atagar
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by atagar):

 Great, thanks Guinness! Fix pushed.

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

Re: [tor-bugs] #25453 [Core Tor/Nyx]: When I start nyx in small terminal then I expand the terminal window and the "cpu %" disappears

[Tor Bug Tracker & Wiki]

#25453: When I start nyx in small terminal then I expand the terminal window and
the "cpu %" disappears
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Nyx   |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 Hi Dbryrtfbcbhgf, sorry about the delay and thanks for the video! This is
 kinda mystifying. I tried to repro this with both the 2.0.4 release and
 current master but they both work for me. When your
 [https://gitweb.torproject.org/nyx.git/tree/nyx/panel/header.py#n30
 terminal's width is 141 characters] the header shows data in two columns,
 whereas less than that it's shown in one. Here's what it **should** look
 like...

 https://www.atagar.com/transfer/tmp/header_single.png

 Then if I widen my terminal by one character (passing the 140 threshold)
 it's shown side-by-side...

 https://www.atagar.com/transfer/tmp/header_double.png

 So question isn't why it disappears from the left, but rather why nothing
 is appearing on the right. And for that I gotta admit I haven't the
 foggiest.

 If you widen your terminal more slowly does it work? Or if you make it
 even wider? Would you mind sending me the nyx debug log when you do this?
 I doubt the logs will show anything, but worth a peek.

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

Re: [tor-bugs] #25321 [Applications/Tor Browser]: Unable to comment on independent.co.uk

[Tor Bug Tracker & Wiki]

#25321: Unable to comment on independent.co.uk
--+--
 Reporter:  mwolfe|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

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


Comment:

 Thanks for the followup!

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

Re: [tor-bugs] #24687 [Core Tor/Tor]: Tor eats all mbufs on FreeBSD

[Tor Bug Tracker & Wiki]

#24687: Tor eats all mbufs on FreeBSD
--+
 Reporter:  AMDmi3|  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.9
 Severity:  Major | Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 It might also be the case that 0.3.3.3-alpha was just at the same time
 when the bad guys decided to leave the network
 https://metrics.torproject.org/userstats-relay-
 country.html?start=2017-12-14=2018-03-14=de=off

 Nice munin graphs, I was not able to find that munin plugin, did you write
 it yourself or where did you get it from?

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by cmm323):

 I'm not sure what the issue is, but you definitely don't need to build the
 entire Chromium, you just fetch WebRTC with: `fetch --nohooks webrtc`

 See https://webrtc.org/native-code/development/


 Also: https://github.com/vsimon/webrtcbuilds

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

Re: [tor-bugs] #25321 [Applications/Tor Browser]: Unable to comment on independent.co.uk

[Tor Bug Tracker & Wiki]

#25321: Unable to comment on independent.co.uk
--+---
 Reporter:  mwolfe|  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 mwolfe):

 Today, I can comment on the Independent without any problem. Not sure if
 the Independent fixed their website, or if it was Tor 8.a3 (or both).

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

Re: [tor-bugs] #25137 [Obfuscation/Censorship analysis]: Tor blocked in UAE

[Tor Bug Tracker & Wiki]

#25137: Tor blocked in UAE
-+
 Reporter:  mwolfe   |  Owner:  dcf
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  censorship block ae  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by mwolfe):

 Update.

 Today, I got Tor 8.a3 and it worked without any bridges. I wasn't sure if
 the UAE stopped blocking Tor, or if 8.a3 fixed the problem, so I tried one
 of my old Tor 7.a and it could not load the network without meek, while
 8.a3 can load without any bridges.

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

Re: [tor-bugs] #25368 [Core Tor/Tor]: Update the Tor Rust coding standards for new types

[Tor Bug Tracker & Wiki]

#25368: Update the Tor Rust coding standards for new types
+--
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  doc, rust, review-group-34  |  Actual Points:
Parent ID:  #23061  | Points:  0.5
 Reviewer:  isis|Sponsor:
+--

Comment (by isis):

 Replying to [comment:9 teor]:
 > Replying to [comment:5 isis]:
 > The caveat doesn't apply, because we aren't transmitting binary floats
 over the network. We don't even want to transmit decimal floats over the
 network. Nor would we ever transmit NaNs over the network.
 >
 > > (i.e. we're not sending floats over the network and expecting others
 to interpret them exactly as we do, right?).

 Ah okay, good. Then everything sounds fine to me.

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

Re: [tor-bugs] #24687 [Core Tor/Tor]: Tor eats all mbufs on FreeBSD

[Tor Bug Tracker & Wiki]

#24687: Tor eats all mbufs on FreeBSD
--+
 Reporter:  AMDmi3|  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.9
 Severity:  Major | Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by AMDmi3):

 * Attachment "mbufs-month.png" added.

 Graph illustrating the issue 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] #24687 [Core Tor/Tor]: Tor eats all mbufs on FreeBSD

[Tor Bug Tracker & Wiki]

#24687: Tor eats all mbufs on FreeBSD
--+
 Reporter:  AMDmi3|  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.9
 Severity:  Major | Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by AMDmi3):

 For the note, it looks like an update to 0.3.3.3 has fixed the issue
 completely - I don't see any more spikes in mbuf usage.

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

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

[Tor Bug Tracker & Wiki]

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

 * points:  1 => 3
 * sponsor:   => Sponsor8-can


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  isis
 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, review-group-34  |  Actual Points:
Parent ID: | Points:  1
 Reviewer:  catalyst   |Sponsor:
   |  Sponsor3-can
---+---

Comment (by isis):

 Replying to [comment:13 isis]:
 > I've thought about this a bit more, and—since our C code that I'm
 wrapping is currently tested for correctness in C—I think that an easy
 workaround for this, would be temporarily (assuming we're eventually only
 going to require implementations in C ''or'' Rust, not both) doing what
 Chelsea Komlo's Rust tor logging code is doing: the wrapping
 implementation in release mode, and a dummy implementation in testing
 mode.  For this, that would probably amount to a dev-dependency (Rust
 distinguishes between hard dependencies, optional dependencies, and "dev"
 or testing dependencies in Cargo.toml files) on
 [https://crates.io/crates/sha2 the sha2 crate].  This way, Rust code that
 is higher level (eventually) will actually be able to test correctness of
 results of functions which rely on the output of a hash function.
 (Probably we'll want to do the same for the [https://crates.io/crates/rand
 rand crate] when we wrap that. Except for the `rand` crate, it's a bit
 messed up, because we'll extremely want the `rand::Rng` trait in
 release/production in order to use generic code throughout the Rust
 ecosystem. Possibly we should nicely ask its maintainers to split the
 trait off into a separate crate, or otherwise rely on the fact that the
 crate is scheduled to be absorbed into libstd/libcore in Rust and just use
 it entirely, including calling it from C.)

 Err, sorry, I'm worried I wasn't explicit/clear enough. Let me try again,
 please. :)

 So, what I'm worried about isn't that somehow our hash functions in C are
 somehow incorrect. That would be absurd. Hash functions either pass test
 vectors or they don't, and it would be inconceivable for them to pass some
 vectors and fail others, that would undermine all cryptography based on
 the random oracle model.

 What I worry about is that, with the current code, there's no way to test
 higher-level, pure-Rust functionality.  So for example, if I were to
 implement ed25519 signing in Rust for tor, with my `ed25519-dalek`
 [https://crates.io/crates/ed25519-dalek crate], which takes the hash
 function as a generic, i.e.:

 {{{#!rust
 /// Sign a message with this `ExpandedSecretKey`.
 pub fn sign(, message: &[u8], public_key: ) ->
 Signature
 where D: Digest + Default {
 }}}

 Hence, if we ever needed to test e.g. a Rust parser for descriptors, which
 contain ed25519 `ntor-onion-key-crosscert` signatures, we'd be unable to,
 since the test code can't call the signatures code because the signature
 code won't be able to call the digest code which wraps the C. This seems
 kind of bad moving forward, since so much of our code relies on hash
 functions. One long-term solution is to say that some things are only Rust
 ''or'' C, not both. Another solution is to do something like #25386, but I
 had a stab at that in this ticket, and it seems like we're not really
 moving forward in a sustainable way with testing linker 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] #25458 [Applications/Tor Browser]: UI customization half-broken in Tor Browser 8.0a3

[Tor Bug Tracker & Wiki]

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

Comment (by cypherpunks):

 Reproducible on Windows:
 {{{
 16:54:02.700 CustomizeMode:Error entering customize mode TypeError:
 messageNode.querySelector(...) is null
 Stack trace:
 
CustomizeMode.prototype.maybeShowTip@resource:///modules/CustomizeMode.jsm:701:7
 CustomizeMode.prototype.enter/<@resource:///modules/CustomizeMode.jsm:358:7
 TaskImpl_run@resource://gre/modules/Task.jsm:319:42
 Handler.prototype.process@resource://gre/modules/Promise.jsm ->
 resource://gre/modules/Promise-backend.js:932:23
 this.PromiseWalker.walkerLoop@resource://gre/modules/Promise.jsm ->
 resource://gre/modules/Promise-backend.js:813:7
 this.PromiseWalker.scheduleWalkerLoop/<@resource://gre/modules/Promise.jsm
 -> resource://gre/modules/Promise-backend.js:747:11
  1 CustomizeMode.jsm:374
 }}}

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by cypherpunks):

 Strange, I can't reproduce the issue myself (linux 64 bit 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] #24487 [Core Tor/Tor]: Reverse path selection (choose outer hops first)

[Tor Bug Tracker & Wiki]

#24487: Reverse path selection (choose outer hops first)
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery-prop247-controller   |  Actual Points:
  needs-proposal |
Parent ID:  #9001| Points:
 Reviewer:  asn  |Sponsor:
 |  SponsorV-can
-+-
Changes (by asn):

 * reviewer:   => asn


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

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

[Tor Bug Tracker & Wiki]

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

 * priority:  Medium => High
 * keywords:   => tbb-regression
 * severity:  Normal => Major
 * parent:   => #25147


Comment:

 You shipped it, ignoring tor-qa, so hrm...

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

Re: [tor-bugs] #24826 [Core Tor/Tor]: consensus diffs stall Tor Browser launch for at least 20s or break it entirely if compiled with --enable-expensive-hardening

[Tor Bug Tracker & Wiki]

#24826: consensus diffs stall Tor Browser launch for at least 20s or break it
entirely if compiled with --enable-expensive-hardening
-+
 Reporter:  gk   |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  review-group-30  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by cypherpunks):

 * parent:  #22341 =>


Comment:

 Unfortunately, it is still happening on Windows XP.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25503 [- Select a component]: Use less space for client-side directory cache

[Tor Bug Tracker & Wiki]

#25503: Use less space for client-side directory cache
--+
 Reporter:  ahf   |  Owner:  ahf
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:  s8
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor8  |
--+
 Parent ticket for all bugs related to reducing space usage for client-side
 directory 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

[tor-bugs] #25502 [- Select a component]: Report intermediate PT bootstrapping status

[Tor Bug Tracker & Wiki]

#25502: Report intermediate PT bootstrapping status
--+
 Reporter:  ahf   |  Owner:  ahf
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor8  |
--+
 Parent ticket for all tickets about reporting intermediate PT bootstrap
 progress.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25501 [Core Tor/Tor]: Control-flow issues solved for WTF-pad

[Tor Bug Tracker & Wiki]

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

 See child tickets for specific tasks.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #25499| Points:
 Reviewer:|Sponsor:  Sponsor8
--+
Changes (by ahf):

 * status:  new => assigned
 * owner:  (none) => nickm
 * parent:   => #25499


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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: #25376, #25375, #25374, #25373

[Tor Bug Tracker & Wiki]

Batch modification to #25376, #25375, #25374, #25373 by dgoulet:
parent to #25500

Comment:
Setting master ticket parent ID.

--
Tickets URL: 

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

[tor-bugs] #25500 [Core Tor/Tor]: Reduce client CPU usage

[Tor Bug Tracker & Wiki]

#25500: Reduce client CPU usage
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-client
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor8  |
--+
 This is the master ticket for sponsor 8 on reducing client CPU usage.

 See child tickets for more specific tasks.

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

Re: [tor-bugs] #25497 [Core Tor/Tor]: Add "idleness" interface support in Orbot

[Tor Bug Tracker & Wiki]

#25497: Add "idleness" interface support in Orbot
--+
 Reporter:  ahf   |  Owner:  ahf
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:  #25499| Points:
 Reviewer:|Sponsor:  Sponsor8
--+
Changes (by ahf):

 * parent:   => #25499


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

Re: [tor-bugs] #25499 [Core Tor/Tor]: Finalize controller interface for idleness

[Tor Bug Tracker & Wiki]

#25499: Finalize controller interface for idleness
--+
 Reporter:  ahf   |  Owner:  ahf
 Type:  task  | Status:  assigned
 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 ahf):

 * 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] #25499 [Core Tor/Tor]: Finalize controller interface for idleness

[Tor Bug Tracker & Wiki]

#25499: Finalize controller interface for idleness
--+
 Reporter:  ahf   |  Owner:  ahf
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 We should finalize the controller interface for idleness handling in 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

[tor-bugs] #25498 [Core Tor/Tor]: module: Basic modularization preparation

[Tor Bug Tracker & Wiki]

#25498: module: Basic modularization preparation
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  modularization
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor3  |
--+
 Ticket #25494 was created to do some initial work in modularization in tor
 that is the code part. Then #25495 is about identifying the list of
 modules in a structured list which from there we'll open tickets to do the
 work to extract different modules.

 This ticket is a sponsor task and should be about what else we need then
 the list of modules before we start extracting modules.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25497 [Core Tor/Tor]: Add "idleness" interface support in Orbot

[Tor Bug Tracker & Wiki]

#25497: Add "idleness" interface support in Orbot
--+
 Reporter:  ahf   |  Owner:  ahf
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor8  |
--+
 A useful demo to have for sponsor 8 would be to patch Orbot to interact
 with the upcoming Tor "sleep/snooze/hibernate" interface.

 This depends upon the roadmap task called "Finalize controller interface
 for idleness".

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

Re: [tor-bugs] #24064 [Core Tor/Tor]: Memory profiling of Tor on Android device

[Tor Bug Tracker & Wiki]

#24064: Memory profiling of Tor on Android device
--+
 Reporter:  ahf   |  Owner:  ahf
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  s8-perf, s8-201710, internal  |  Actual Points:
Parent ID:  #24061| Points:
 Reviewer:|Sponsor:  Sponsor8
--+
Changes (by dgoulet):

 * 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] #25478 [Metrics/Onionoo]: Put out Onionoo 5.1-1.11.0

[Tor Bug Tracker & Wiki]

#25478: Put out Onionoo 5.1-1.11.0
-+
 Reporter:  karsten  |  Owner:  karsten
 Type:  task | Status:  needs_review
 Priority:  Medium   |  Milestone:  Onionoo 1.11.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by iwakeh):

 Replying to [comment:4 karsten]:
 >...
 > Fine question. I guess the version number just looked nicer with all
 1's. (More seriously, good catch!)

 :-)

 >
 > Please review
 
[https://gitweb.torproject.org/user/karsten/onionoo.git/commit/?h=task-25478=88ca11145535220973ce3bcfc54c62c1288b781d
 commit 88ca111 in my (force-updated) task-25478 branch] and at
 [https://people.torproject.org/~karsten/volatile/onionoo-5.1-1.11.0-pre1.tar.gz
 this new pre-release tarball].

 This looks fine, all checks pass, the bytecode is reproducible from
 the given sources and dependencies.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25496 [Core Tor/Tor]: Investigate Tor on ARM64 with Orbot

[Tor Bug Tracker & Wiki]

#25496: Investigate Tor on ARM64 with Orbot
--+
 Reporter:  ahf   |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  s8, s8-perf
Actual Points:|  Parent ID:
   Points:|   Reviewer:  ahf
  Sponsor:  Sponsor8  |
--+
 We should figure out if we currently ship Orbot with ARM64 compiled Tor
 and if it would make sense to do so, what problems exists, and should they
 be fixed.

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

[tor-bugs] #25495 [Core Tor/Tor]: module: Identify a list of tor module

[Tor Bug Tracker & Wiki]

#25495: module: Identify a list of tor module
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  modularization
Actual Points:|  Parent ID:  #25494
   Points:|   Reviewer:
  Sponsor:  Sponsor8  |
--+
 Write a list of all possible module of tor.

 Then we should use that list to start extracting module into compile time
 options so we can end up with a minimal mobile client binary.

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

[tor-bugs] #25494 [Core Tor/Tor]: Initial work on making modules conditionally compiled

[Tor Bug Tracker & Wiki]

#25494: Initial work on making modules conditionally compiled
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  task  | Status:  assigned
 Priority:  High  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  modularization
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor8  |
--+
 This is a roadmap master ticket. The idea is to try to extract modules out
 of Tor into compile time options in order to help the modularization
 effort and shrinking the binary size down for mobile.

 See child tickets for more specific tasks.

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

Re: [tor-bugs] #24587 [Core Tor/Tor]: Reset bootstrapping state on shutdown

[Tor Bug Tracker & Wiki]

#24587: Reset bootstrapping state on shutdown
+
 Reporter:  nickm   |  Owner:  nickm
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tor-mobile, s8-api  |  Actual Points:
Parent ID:  #23847  | Points:
 Reviewer:  asn |Sponsor:
+
Changes (by nickm):

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


Comment:

 Merged in master.

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

Re: [tor-bugs] #24587 [Core Tor/Tor]: Reset bootstrapping state on shutdown

[Tor Bug Tracker & Wiki]

#24587: Reset bootstrapping state on shutdown
+
 Reporter:  nickm   |  Owner:  nickm
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-mobile, s8-api  |  Actual Points:
Parent ID:  #23847  | Points:
 Reviewer:  asn |Sponsor:
+

Comment (by nickm):

 I've made #25493 to track looking for a better pattern here, since I think
 asn is right that the approach I've been using is fragile.  But for now,
 I'll merge, since the current behavior can break restart on mobile.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25493 [Core Tor/Tor]: Improve patterns for cleaning up static variables on exit/restart

[Tor Bug Tracker & Wiki]

#25493: Improve patterns for cleaning up static variables on exit/restart
--+
 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:  Sponsor8  |
--+
 In his review for #23524, asn says:
 >I feel like resetting all the global statics on `tor_free_all()` makes
 sense but it's all a very brittle logic. The moment someone adds a new
 global static in that file and doesn't know about this convention of
 wiping at `tor_free_all()`, it will introduce a bug IIUC. Furthermore, the
 fact that some of those vars get reset to 0 and others to 1 is kinda
 arbitrary (and you need to look at their definitions to see if it's
 correct).
 >
 >I wonder what we could do about `3809036` to make it better. Perhaps we
 should de-global those variables, put them in a struct, and initialize
 them in a function, then call that function from some entry-point and
 `tor_free_all()`? That seems like a better approach but probably not so
 trivial. Maybe subject for a future ticket on this area?

 We should indeed look for better patterns to solve this issue, since the
 current approach is indeed fragile.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25492 [Core Tor/Nyx]: Fix nyx crashing when failing to write torrc.

[Tor Bug Tracker & Wiki]

#25492: Fix nyx crashing when failing to write torrc.
--+
 Reporter:  Guinness  |  Owner:  atagar
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 When nyx tries to write torrc and fails, the exception handling was broken
 :

 {{{
 Traceback (most recent call last):
   File "/usr/local/lib/python3.5/dist-
 packages/nyx-2.0.4.dev0-py3.5.egg/nyx/starter.py", line 118, in main
 nyx.curses.start(nyx.draw_loop, acs_support =
 config.get('acs_support', True), transparent_background = True, cursor =
 False)
   File "/usr/local/lib/python3.5/dist-
 packages/nyx-2.0.4.dev0-py3.5.egg/nyx/curses.py", line 217, in start
 curses.wrapper(_wrapper)
   File "/usr/lib/python3.5/curses/__init__.py", line 94, in wrapper
 return func(stdscr, *args, **kwds)
   File "/usr/local/lib/python3.5/dist-
 packages/nyx-2.0.4.dev0-py3.5.egg/nyx/curses.py", line 215, in _wrapper
 function()
   File "/usr/local/lib/python3.5/dist-
 packages/nyx-2.0.4.dev0-py3.5.egg/nyx/__init__.py", line 243, in draw_loop
 keybinding.handle(key)
   File "/usr/local/lib/python3.5/dist-
 packages/nyx-2.0.4.dev0-py3.5.egg/nyx/panel/__init__.py", line 84, in
 handle
 self._action()
   File "/usr/local/lib/python3.5/dist-
 packages/nyx-2.0.4.dev0-py3.5.egg/nyx/panel/config.py", line 222, in
 _show_write_dialog
 show_message('Unable to save configuration (%s)' % exc.strerror,
 HIGHLIGHT, max_wait = 2)
 AttributeError: 'OperationFailed' object has no attribute 'strerror'
 }}}


 This commit patches this small bug, and add a more accurate exception
 handling for the save_conf call.

 The commit can be found here :
 
https://git.oudin.ml/Guinness/nyx/commit/8565384dc42b3f0faef027f890602b15513787be
 .

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

Re: [tor-bugs] #25489 [Webpages/Styleguide]: Implement a fallback mechanism for icon fonts and SVGs used in CSS for high-security mode

[Tor Bug Tracker & Wiki]

#25489: Implement a fallback mechanism for icon fonts and SVGs used in CSS for
high-security mode
-+--
 Reporter:  cypherpunks  |  Owner:  hiro
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Webpages/Styleguide  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by cypherpunks):

 > I am not yet aware of a method of doing this reliably across all
 browsers

 https://css-tricks.com/svg-fallbacks/  ;)

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

Re: [tor-bugs] #25485 [Applications/Tor Browser]: Browser/TorBrowser/Tor/libstdc++.so.6: version `CXXABI_1.3.11' not found (required by /usr/lib/x86_64-linux-gnu/libmirclient.so.9)

[Tor Bug Tracker & Wiki]

#25485: Browser/TorBrowser/Tor/libstdc++.so.6: version `CXXABI_1.3.11' not found
(required by /usr/lib/x86_64-linux-gnu/libmirclient.so.9)
--+--
 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]:
 > I wonder where the libmir* requirement is coming from. Cyperpunk: What
 Linux system is that and how are you extracting/starting Tor Browser?
 Ubuntu 17.10. For that case I did `cd Browser && ./start-tor-browser
 --debug`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25491 [Webpages/Styleguide]: Package lektor for Debian

[Tor Bug Tracker & Wiki]

#25491: Package lektor for Debian
-+--
 Reporter:  cypherpunks  |  Owner:  irl
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Webpages/Styleguide  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 I have filed an Debian bug for this, opening this ticket just for
 visibility in Tor Project.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25488 [Webpages/Styleguide]: Add an example for navigation within the site

[Tor Bug Tracker & Wiki]

#25488: Add an example for navigation within the site
-+
 Reporter:  cypherpunks  |  Owner:  hiro
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Webpages/Styleguide  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #25404
   Points:   |   Reviewer:
  Sponsor:   |
-+
 Some of this is based on the presentation at the dev meeting and it may be
 that I've misunderstood it.

 The top navigation in line with the brand and download button is to be
 used for inter-portal navigation, which makes sense, but I also saw a
 design for the dev portal that underneath the purple block at the top of
 the page had navigation to move between sections of the portal. Can an
 example for this be added to the styleguide? It doesn't seem to be
 implemented in any of the nav CSS classes in the CSS.

 This would be used for metrics to move between "Analysis, News, Sources,
 etc.".

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25490 [Webpages/Styleguide]: Give clear guidelines for the page footer

[Tor Bug Tracker & Wiki]

#25490: Give clear guidelines for the page footer
-+
 Reporter:  cypherpunks  |  Owner:  hiro
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Webpages/Styleguide  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #25404
   Points:   |   Reviewer:
  Sponsor:   |
-+
 I guess we want consistency with page footers across all the portals.
 There is currently no guidance on how to construct footers. Maybe an HTML
 template (similar to the templates included with Bootstrap) would help
 here.

 Note that some projects may have additional text that they may have to add
 to footers, e.g. metrics adds text about supporting grants.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25489 [Webpages/Styleguide]: Implement a fallback mechanism for icon fonts and SVGs used in CSS for high-security mode

[Tor Bug Tracker & Wiki]

#25489: Implement a fallback mechanism for icon fonts and SVGs used in CSS for
high-security mode
-+--
 Reporter:  cypherpunks  |  Owner:  hiro
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Webpages/Styleguide  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 It should be possible to fall back to PNG assets in high security mode
 where icon fonts (font awesome and tor icons) would not be available, and
 SVG graphics would also not be available.

 I am not yet aware of a method of doing this reliably across all browsers,
 it may be worth talking to the Tor Browser people before looking at this
 to see if they have ideas.

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

Re: [tor-bugs] #25487 [Webpages/Styleguide]: Add an example for cards that are also links

[Tor Bug Tracker & Wiki]

#25487: Add an example for cards that are also links
-+--
 Reporter:  cypherpunks  |  Owner:  hiro
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Webpages/Styleguide  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #25404   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by cypherpunks):

 * parent:   => #25404


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

Re: [tor-bugs] #25485 [Applications/Tor Browser]: Browser/TorBrowser/Tor/libstdc++.so.6: version `CXXABI_1.3.11' not found (required by /usr/lib/x86_64-linux-gnu/libmirclient.so.9)

[Tor Bug Tracker & Wiki]

#25485: Browser/TorBrowser/Tor/libstdc++.so.6: version `CXXABI_1.3.11' not found
(required by /usr/lib/x86_64-linux-gnu/libmirclient.so.9)
--+---
 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:
--+---

Comment (by yawning):

 Replying to [comment:1 gk]:
 > I wonder where the libmir* requirement is coming from.

 Stuff on the user's system (in this case nautlius) is compiled against it.
 My bet here would be Gtk 3 and or Mesa, but it doesn't really matter.

 If Tor Browser forks/execs things that are not part of the browser bundle
 (such as, oh, the file manager), it should clear LD_LIBRARY_PATH.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25487 [Webpages/Styleguide]: Add an example for cards that are also links

[Tor Bug Tracker & Wiki]

#25487: Add an example for cards that are also links
-+--
 Reporter:  cypherpunks  |  Owner:  hiro
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Webpages/Styleguide  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 The [[https://metrics.torproject.org/|current Metrics homepage]] has some
 custom CSS for the links to the different analysis pages. I've attempted
 to recreate this with cards instead of completely custom CSS.

 The HTML for the card looks like:

 {{{
 
   
 
Users
   Where Tor users are from and how
 they connect to Tor.
 
   
   
 }}}

 The extra CSS looks like:

 {{{
 
 /* external links */
 a[target="_blank"]:before {
 content: " \f08e";
 font-family: 'FontAwesome';
 font-size:14px;
 position:relative;
 top:1px;
 margin-right:3px;
 }

 a.btn[target="_blank"]:before {
 content: "";
 }

 a .card:hover { background-color: #ccc; }

 a { text-decoration: none!important; }
 
 }}}

 This CSS would need to be modified as currently it touches components that
 are unrelated, maybe a new class would need to be introduced.

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

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

[Tor Bug Tracker & Wiki]

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

 * cc: gk (added)


Comment:

 Replying to [ticket:25483 arlolra]:
 > Breaking this out from
 https://trac.torproject.org/projects/tor/ticket/19001#comment:36, where
 dcf wrote,
 >
 > > I pushed some preliminary code for getting started with a windows
 reproducible build.
 > >   https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/log/?h
 =snowflake-windows=0f48dc9e1904fa0643576fc8dcf3db50a4d2f959
 > >
 > > It doesn't work yet; after `./mkbundle-windows.sh versions.alpha`, it
 eventually fails with:
 > > {{{
 > > + /home/ubuntu/build/webrtc/src/out_bootstrap/gn gen out/Release '--
 args= target_os="win" target_cpu="x86" is_debug=false
 treat_warnings_as_errors=false is_component_build=false is_clang=true
 use_sysroot=false clang_use_chrome_plugins=false
 clang_base_path="/home/ubuntu/build/clang" rtc_include_opus=false
 rtc_include_ilbc=false rtc_include_internal_audio_device=false
 rtc_include_tests=true'
 > > ERROR at //build/config/BUILDCONFIG.gn:239:3: Assertion failed.
 > >   assert(target_os == host_os, "Win cross-compiles only work on win
 hosts.")
 > >   ^-
 > > Win cross-compiles only work on win hosts.
 > > }}}
 > > But at this point one can ssh into the build VM and start debugging
 the build failures.
 >
 > Some further notes from what we've discovered so far.
 >
 > *
 https://chromium.googlesource.com/chromium/src/+/master/docs/win_cross.md
 says that we need to add `target_os = ['win']` to our `.gclient` file
 before calling `gclient sync` to get some additional deps.
 >
 > *
 
https://chromium.googlesource.com/chromium/tools/depot_tools.git/+/master/win_toolchain/README.md
 says that Googlers have access to the necessary toolchain, but we don't.

 Ugh. So, you need to use clang to cross-compile the webrtc parts? We want
 to have this, too, for Firefox as Stylo needs that but we won't go the
 road Google takes but use a clang/mingw-w64 approach. See:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1390583 where we basically
 got this working.

 I am not thrilled to have two different clang-based approaches in our
 build setup for Windows. That said, what are the options for not having to
 pull in all the Chromium stuff to build the WebRTC parts we need? I can't
 imagine that everyone wanting to have that lib is always building the
 whole Chromium thing.

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

Re: [tor-bugs] #17901 [Core Tor/Tor]: Tor would bind ControlPort to public ip address if it has no localhost interface

[Tor Bug Tracker & Wiki]

#17901: Tor would bind ControlPort to public ip address if it has no localhost
interface
-+-
 Reporter:  s7r  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.6.10
 Severity:  Major| Resolution:
 Keywords:  tor-control misconfiguration |  Actual Points:
  security easy  |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-

Comment (by fristonio):

 Ok, I will wait until the code is tested and yes I would love to help test
 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] #25485 [Applications/Tor Browser]: Browser/TorBrowser/Tor/libstdc++.so.6: version `CXXABI_1.3.11' not found (required by /usr/lib/x86_64-linux-gnu/libmirclient.so.9)

[Tor Bug Tracker & Wiki]

#25485: Browser/TorBrowser/Tor/libstdc++.so.6: version `CXXABI_1.3.11' not found
(required by /usr/lib/x86_64-linux-gnu/libmirclient.so.9)
--+---
 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:  assigned => needs_information


Comment:

 I wonder where the libmir* requirement is coming from. Cyperpunk: What
 Linux system is that and how are you extracting/starting Tor Browser?

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