Re: [tor-bugs] #23947 [Obfuscation/Snowflake]: Move Snowflake proxy page somewhere devs can write

[Tor Bug Tracker & Wiki]

#23947: Move Snowflake proxy page somewhere devs can write
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by dcf):

 Replying to [comment:1 arma]:
 > Is there anything here that I/we can help with? Or is it just picking
 one and doing it?

 If the Tor Project can provide a host, that could help. (I know
 historically Tor has not wanted to do that.) The only technical
 requirement is an HTTPS server serving static files. Otherwise I was
 thinking of registering some domain name and setting up a server.

 The important thing is long-term name stability. The domain we choose will
 determine the URL that we tell people to paste into their pages, and once
 it's out there, we can't easily change it.

 And there's also the question of shared administration of the server, in
 order to avoid a single point of failure. We can easily share SSH access
 to the server. But it won't do if someone needs to bug me to make a DNS
 change, just because I happen to be the one who registered the domain
 name. I don't know if there's a way to do shared administration of a
 domain name (maybe Team Cymru does something like that?).

 Currently we're using subdomains of bamsoftware.com for certain snowflake
 services, for example the bridge at !https://snowflake.bamsoftware.com/.
 But that's different--the name isn't important, it only needs a name so it
 can have a certificate. And it doesn't really introduce a dependency on
 me. If I disappeared, some other team member could register another name
 pointing to the same IP address, reconfigure the bridge with a certificate
 for that name, and everything would work: even currently running proxies
 would restart themselves within 24h. I'm not nearly as concerned about
 permanence for easily changed domains like that. But the URL of the server
 actually hosting the proxy code does lock us 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] #23780 [Obfuscation/Snowflake]: Tor repeatedly tells me that "Your Guard is failing an extremely large amount of circuits" when using snowflake

[Tor Bug Tracker & Wiki]

#23780: Tor repeatedly tells me that "Your Guard is failing an extremely large
amount of circuits" when using snowflake
---+---
 Reporter:  cypherpunks|  Owner:  (none)
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:  Tor: 0.3.2.9
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by dcf):

 * 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] #23780 [Obfuscation/Snowflake]: Tor repeatedly tells me that "Your Guard is failing an extremely large amount of circuits" when using snowflake

[Tor Bug Tracker & Wiki]

#23780: Tor repeatedly tells me that "Your Guard is failing an extremely large
amount of circuits" when using snowflake
---+--
 Reporter:  cypherpunks|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:  Tor: 0.3.2.9
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 It's looking like the cause of this may have been unreliable standalone
 proxies--they were frequently crashing and being restarted. See
 comment:39:ticket:21312.

 But that should be fixed now: see comment:57:ticket:21312.

 So if you can, please try snowflake again and see if you continue to get
 the "Your Guard is failing an extremely large amount of circuits".

 You will need to unpack a fresh copy of the browser, because the
 information about failed circuits is cached in the state file. You can try
 this build, which I just made for #25579.
   https://people.torproject.org/~dcf/pt-
 bundle/snowflake/20180321-8.0a4-4a5889af2891/

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23780#comment:10>
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]: Memory and file descriptor leaks in programs that use go-webrtc

[Tor Bug Tracker & Wiki]

#21312: Memory and file descriptor leaks in programs that use go-webrtc
---+-
 Reporter:  arlolra|  Owner:  arlolra
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by dcf):

 Replying to [comment:59 dcf]:
 > I'm thinking about losing the periodic restarts, and just putting a
 memory ulimit on the processes (just in case).

 I've done this now, removing the periodic restarts. There are still the
 same number of proxies, 3 for the App Engine broker and 3 for the
 standalone broker.

 I first tried limiting the memory using the
 [http://smarden.org/runit/chpst.8.html chpst] program that we're already
 using to change the uid:
 {{{
 exec chpst -u snowflake-proxy -m 419430400 proxy-go
 }}}
 However chpst does not work, it seems due to some bad interaction with
 Cgo. No matter how much memory I give it, it aborts immediately with this
 error:
 {{{
 runtime/cgo: pthread_create failed: Resource temporarily unavailable
 SIGABRT: abort
 PC=0x7f0fe207afcf m=0

 goroutine 0 [idle]:

 goroutine 1 [running]:
 runtime.systemstack_switch()
 /usr/lib/go-1.7/src/runtime/asm_amd64.s:252 fp=0xc42001e768
 sp=0xc42001e760
 runtime.main()
 /usr/lib/go-1.7/src/runtime/proc.go:127 +0x6c fp=0xc42001e7c0
 sp=0xc42001e768
 runtime.goexit()
 /usr/lib/go-1.7/src/runtime/asm_amd64.s:2086 +0x1 fp=0xc42001e7c8
 sp=0xc42001e7c0

 goroutine 17 [syscall, locked to thread]:
 runtime.goexit()
 /usr/lib/go-1.7/src/runtime/asm_amd64.s:2086 +0x1
 }}}

 So instead, I'm just using ulimit like this:
 {{{
 ulimit -v 409600
 exec chpst -u snowflake-proxy proxy-go
 }}}
 I originally gave each process 200 MB. But they were restarting (on
 average once during the 15 minutes I was watching). So I then bumped it up
 to 400 MB. Here are the timestamps:
 ||2018-03-22 03:03:45 ||ulimit to 200 MB ||
 ||2018-03-22 03:19:19 ||ulimit to 400 MB ||

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25580 [Applications/Tor Browser]: Should Tor Browser auto update for me when it starts and it knows it's out of date?

[Tor Bug Tracker & Wiki]

#25580: Should Tor Browser auto update for me when it starts and it knows it's 
out
of date?
--+--
 Reporter:  arma  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 When I start my Tor Browser 7.5, it starts up, and gives me an about:tor
 page with a black arrow trying to get me to click on stuff.

 Shouldn't it instead just say "oh, you need to update, I'm doing that for
 you now"?

 When I close down my Tor Browser 7.5 and start it up again, I get the same
 black arrow, even though it could have already known from last time that
 it was going to be out of date.

 (I've gotten used to the choices that yawning made in the sandboxed tor
 browser, where it checks for an update on startup, and if there is one, it
 updates me then.)

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

Re: [tor-bugs] #25435 [Applications/rbm]: keyring/binutils.gpg modified by `make alpha`

[Tor Bug Tracker & Wiki]

#25435: keyring/binutils.gpg modified by `make alpha`
-+-
 Reporter:  dcf  |  Owner:  boklm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/rbm |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-rbm, boklm201803,|  Actual Points:
  TorBrowserTeam201803R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dcf):

 Hmm, I just had this problem again, this time with keyring/tor.gpg. These
 are the commits I was using:

 tor-browser-build [https://gitweb.torproject.org/builders/tor-browser-
 build.git/commit/?id=b8bae5882eac6159c8a6ad466b9dc4a7b18ba27b
 b8bae5882eac6159c8a6ad466b9dc4a7b18ba27b] (actually one commit ahead, for
 #25579)
 rbm
 
[https://gitweb.torproject.org/builders/rbm.git/commit/?id=db41d8e754ed8cd6cee7bca18d76d59f8f7f369b
 db41d8e754ed8cd6cee7bca18d76d59f8f7f369b]

 I think I'll just ignore this for now, as I'm not 100% sure that the file
 was not modified before I started. I'll post again if it happens again.

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

Re: [tor-bugs] #25579 [Applications/Tor Browser]: Bump snowflake/go-webrtc again for trac 21312

[Tor Bug Tracker & Wiki]

#25579: Bump snowflake/go-webrtc again for trac 21312
--+--
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  snowflake |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arlolra):

 > Although we only saw the crashes in the proxy and server components, not
 the client

 This is likely because `DefaultSnowflakeCapacity` is `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] #25579 [Applications/Tor Browser]: Bump snowflake/go-webrtc again for trac 21312

[Tor Bug Tracker & Wiki]

#25579: Bump snowflake/go-webrtc again for trac 21312
--+--
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  snowflake |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

 * 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] #25579 [Applications/Tor Browser]: Bump snowflake/go-webrtc again for trac 21312

[Tor Bug Tracker & Wiki]

#25579: Bump snowflake/go-webrtc again for trac 21312
--+--
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  snowflake |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

 * Attachment "0001-Bug-25579-Bump-snowflake-go-webrtc-again-for-
 trac-21.patch" added.


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

[tor-bugs] #25579 [Applications/Tor Browser]: Bump snowflake/go-webrtc again for trac 21312

[Tor Bug Tracker & Wiki]

#25579: Bump snowflake/go-webrtc again for trac 21312
--+---
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  snowflake
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 This is a followup to #25449.

 We discovered additional crashes having to do with the go-webrtc binding
 in #21312. Although we only saw the crashes in the proxy and server
 components, not the client, the attached patch applies the same
 synchronization fixes to the client.

 I did a `testbuild` and put the results here (I'm using it right now to
 file this ticket):
 https://people.torproject.org/~dcf/pt-
 bundle/snowflake/20180321-8.0a4-4a5889af2891/

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25579>
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

[tor-bugs] #25578 [Applications/Tor Browser]: Package and distribute Tor Browser using Flatpak

[Tor Bug Tracker & Wiki]

#25578: Package and distribute Tor Browser using Flatpak
--+--
 Reporter:  mjog  |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Please provide a Tor Browser package for Flatpak, and ideally publish it
 on Flathub. Aside from getting the added security benefit of the Flatpak
 sandbox, this will make it possible for normal people to install Tor
 Browser on Linux - the current binary tarball isn't great.

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => needs_revision


Comment:

 If I'm reading this correctly, it's not in stable yet?  I'm not familiar
 with the rust release engineering processes.

 https://github.com/rust-lang/rust/blob/stable/src/libstd/sys/unix/net.rs
 https://github.com/rust-lang/rust/pull/47334
 https://github.com/rust-
 lang/rust/commit/090a968fe7680cce0d3aa8fde25a5dc48948e43e

 I'm not sure whether we want to defer this until that fix hits rust
 stable, or do something else.

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

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

[Tor Bug Tracker & Wiki]

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

 * type:  defect => project


Comment:

 Maybe this is already known to people, but a future version of Chromium is
 going to use Clang instead of Microsoft's compiler, for building on
 Windows.

 http://blog.llvm.org/2018/03/clang-is-now-used-to-build-chrome-for.html
   but: "We still use Microsoft’s headers and libraries to build Chrome, we
 still use some SDK binaries like midl.exe and mc.exe"
 https://arstechnica.com/gadgets/2018/03/chrome-on-windows-ditches-
 microsofts-compiler-now-uses-clang/

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by catalyst):

 Maybe the fix didn't make it into rust 1.24?  It seems to work with
 nightly or whatever travis uses:
 https://travis-ci.org/tlyu/tor/jobs/356676338

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

Re: [tor-bugs] #25344 [Obfuscation/Snowflake]: proxy-go needs to relax between polls

[Tor Bug Tracker & Wiki]

#25344: proxy-go needs to relax between polls
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by dcf):

 #23356 shows the consequence if proxy-go gets into a tight loop of
 connection failures.
 > A power outage disconnected the network of a laptop on which I was
 running proxy-go. The laptop battery kept the computer running until the
 power came back on, but the network was still down. When I checked on it,
 the log was filled with 2.4 GB of
 > {{{
 > 2017/08/29 10:02:33 error polling broker: Post https://snowflake-
 reg.appspot.com/proxy: dial tcp: lookup snowflake-reg.appspot.com on :53: dial udp :53: connect: network is unreachable
 > 2017/08/29 10:02:33 error polling broker: Post https://snowflake-
 reg.appspot.com/proxy: dial tcp: lookup snowflake-reg.appspot.com on :53: dial udp :53: connect: network is unreachable
 > 2017/08/29 10:02:33 error polling broker: Post https://snowflake-
 reg.appspot.com/proxy: dial tcp: lookup snowflake-reg.appspot.com on :53: dial udp :53: connect: network is unreachable
 > }}}
 >
 > There were 11,879,088 of these messages over the course of about an hour
 (according to the log timestamps), so about 3,330 messages per second.

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

Re: [tor-bugs] #23356 [Obfuscation/Snowflake]: proxy-go starts using 100% CPU when network is disconnected

[Tor Bug Tracker & Wiki]

#23356: proxy-go starts using 100% CPU when network is disconnected
---+---
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:  duplicate
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by dcf):

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


Comment:

 This is really a duplicate of #25344.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by catalyst):

 MacOS 10.12.6, with rust from homebrew:

 {{{
   CCLD src/or/tor
 Undefined symbols for architecture x86_64:
   "_res_9_init", referenced from:
 std::sys::unix::net::res_init_if_glibc_before_2_26::he8c674397a656892 in
 libtor_rust.a(std-
 b11ab8f1585f119d.std15-94ef799fc274932c8f7e09df8e855996.rs.rcgu.o)
 ld: symbol(s) not found for architecture x86_64
 clang: error: linker command failed with exit code 1 (use -v to see
 invocation)
 make[1]: *** [src/or/tor] Error 1
 make: *** [all] Error 2
 mirkwood:tor tlyu$ rustc --version
 rustc 1.24.1
 }}}

 I haven't tracked down any further yet.

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

Re: [tor-bugs] #25399 [Core Tor/Tor]: mmap length doesn't need to be page-aligned

[Tor Bug Tracker & Wiki]

#25399: mmap length doesn't need to be page-aligned
-+
 Reporter:  Hello71  |  Owner:  (none)
 Type:  defect   | Status:  merge_ready
 Priority:  Low  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  review-group-34  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:  ahf  |Sponsor:
-+
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 As far as I can tell this looks good. Even the man pages mentions that
 `getpagesize()` is deprecated and `sysconf(_SC_PAGESIZE)` should be used
 instead.

 The interesting part from POSIX:

 {{{
 The off argument is constrained to be aligned and sized according to the
 value
 returned by sysconf() when passed _SC_PAGESIZE or _SC_PAGE_SIZE. When
 MAP_FIXED
 is specified, the argument addr must also meet these constraints. The
 implementation performs mapping operations over whole pages. Thus, while
 the
 argument len need not meet a size or alignment constraint, the
 implementation
 will include, in any mapping operation, any partial page specified by the
 range
 [pa, pa + len).
 }}}

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

Re: [tor-bugs] #25574 [Core Tor/Tor]: Eliminate "silent-drop" side channels in Tor protocol

[Tor Bug Tracker & Wiki]

#25574: Eliminate "silent-drop" side channels in Tor protocol
---+--
 Reporter:  mikeperry  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  guard-discovery-stats  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  SponsorV-can
---+--

Comment (by nickm):

 I really want to ask for a proposal on this -- if only a formal list of
 the stuff you want to change here.

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

[tor-bugs] #25577 [Core Tor/Tor]: cmux: CircuitPriorityHalflife value is never taken from the consensus

[Tor Bug Tracker & Wiki]

#25577: cmux: CircuitPriorityHalflife value is never taken from the consensus
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  regression
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Commit `6b1dba214db` introduced an issue that makes the cmux EWMA
 subsystem to never use the `CircuitPriorityHalflife` option from the
 consensus resulting in a warning at bootup:

 {{{
 Mar 21 22:31:24.001 [warn] CircuitPriorityHalflife is too small
 (-1.00). Adjusting to the smallest value allowed: 30.00.
 }}}

 The default config is:

 {{{
   V(CircuitPriorityHalflife, DOUBLE,  "-1.0"), /*negative:'Use
 default'*/
 }}}

 Which means that in `get_circuit_priority_halflife()` which is called at
 bootup when loading the config file and when a new consensus arrives,
 always skip the consensus param check due to this wrong condition
 (EPSILON=0.0001):

 {{{
 +  if (options && options->CircuitPriorityHalflife < EPSILON) {
 +halflife = options->CircuitPriorityHalflife;
 +*source_msg = "CircuitPriorityHalflife in configuration";
 +goto end;
 +  }
 }}}

 Originally, the condition was this which resulted in false with -1.0 and
 thus trying the consensus param instead:

 {{{
 -  if (options && options->CircuitPriorityHalflife >= -EPSILON) {
 -halflife = options->CircuitPriorityHalflife;
 -source = "CircuitPriorityHalflife in configuration";
 }}}

 The good news is that we didn't release that commit yet! and the default
 value is what currently the consensus is using (3) :). Nevertheless,
 this should be fixed asap.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25576 [Core Tor/Tor]: Fix non-standard use of keccak in v3 hidden service code

[Tor Bug Tracker & Wiki]

#25576: Fix non-standard use of keccak in v3 hidden service code
-+-
 Reporter:  isis |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core |Version:  Tor: 0.3.0.1-alpha
  Tor/Tor|   Keywords:  cryptography, crypto, tor-hs,
 Severity:  Normal   |  handshakes
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Currently in `src/common/crypto.c` there's the following construction:

 {{{#!C
 /** Compute a MAC using SHA3-256 of msg_len bytes in msg
 using a
  * key of length key_len and a salt of length
  * salt_len. Store the result of len_out bytes in in
  * mac_out. This function can't fail. */
 void
 crypto_mac_sha3_256(uint8_t *mac_out, size_t len_out,
 const uint8_t *key, size_t key_len,
 const uint8_t *msg, size_t msg_len)
 {
   crypto_digest_t *digest;

   const uint64_t key_len_netorder = tor_htonll(key_len);

   tor_assert(mac_out);
   tor_assert(key);
   tor_assert(msg);

   digest = crypto_digest256_new(DIGEST_SHA3_256);

   /* Order matters here that is any subsystem using this function should
* expect this very precise ordering in the MAC construction. */
   crypto_digest_add_bytes(digest, (const char *) _len_netorder,
   sizeof(key_len_netorder));
   crypto_digest_add_bytes(digest, (const char *) key, key_len);
   crypto_digest_add_bytes(digest, (const char *) msg, msg_len);
   crypto_digest_get_digest(digest, (char *) mac_out, len_out);
   crypto_digest_free(digest);
 }
 }}}

 Our code is currently using it here:

 {{{#!sh
 ∃!isisⒶwintermute:(master *$)~/code/torproject/tor ∴ ag
 crypto_mac_sha3_256
 src/test/test_crypto.c
 1105: * are gonna do is test our crypto_mac_sha3_256() function against
 manually
 1121:  crypto_mac_sha3_256(hmac_test, sizeof(hmac_test),

 src/common/crypto.c
 1259:crypto_mac_sha3_256(uint8_t *mac_out, size_t len_out,

 src/common/crypto.h
 197:void crypto_mac_sha3_256(uint8_t *mac_out, size_t len_out,

 src/or/hs_cell.c
 62:  crypto_mac_sha3_256(mac_out, mac_out_len,
 551:crypto_mac_sha3_256(mac, sizeof(mac),

 src/or/hs_intropoint.c
 131:crypto_mac_sha3_256(mac, sizeof(mac),

 src/or/hs_ntor.c
 94:  crypto_mac_sha3_256(ntor_key_seed, sizeof(ntor_key_seed),
 100:  crypto_mac_sha3_256(ntor_verify, sizeof(ntor_verify),
 126:  crypto_mac_sha3_256(rend_cell_auth, sizeof(rend_cell_auth),
 }}}

 So it looks like only the v3 hidden service code?

 This looks like a perfectly reasonable construction, and I believe other
 people do this too, except Ian has pointed out to me (in the context of
 #24988) that

 > The security proof of HMAC *relies* on the underlying hash function
 being Merkle-Damgård.

 I went back to the original '96 paper
 ([http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.134.8430
 ""Keying Hash Functions for Message Authentication""], search for
 "Iterated Constructions" and read from there on) to read the security
 proof, and it does in fact rely upon the collision resistance of the
 underlying ''compression function'', which obviously we don't have when
 using a sponge construction. So while this looks like a perfectly
 reasonable construction, there isn't actually any security proof for its
 collision resistance. Further, note that the `crypto_mac_sha3_256()`
 doesn't take any domain separators other than the key, which we probably
 should be doing all the time no matter what.

 Also the construction is not using the full state space of the keys, due
 to `htonll()` being used to pad the MAC key to a fixed-length of 64 bits,
 whereas the rate of the Keccak[512] function underlying the SHA3-256
 construction is 1088 bits, which are getting padded with `0` bits in
 length of the excess capacity of 512 bits to equal the block size of 1600.
 A nicer construction would be to ensure that the key is at least 1088
 bits, which is what KMAC does with the `bytepad(encode_string(X), 136)`
 part.

 When using Keccak, I believe the correct/standard construction for a MAC
 is KMAC (specification
 [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-185.pdf
 here]) with domain separators (a.k.a. in that publication "customisation
 strings") which uses SHAKE under-the-hood. (It might also be okay to use
 KangarooTwelve if we needed/wanted a parallelisable XOF, for some reason.)

 For a key `K`, message `X`, requested output length `L`, and domain
 separator `S`, the pseudocode is:

 {{{
 KMAC256(K, X, L, S):
 Validity Conditions: len(K)<2²⁰⁴⁰ and 0 ≤ L < 2²⁰⁴⁰ and len(S) < 2²⁰⁴⁰

 1. newX = bytepad(encode_string(K), 136) || X || right_encode(L).
 2. return cSHAKE256(newX, L, “KMAC”, S).
 }}}

 -

 Setting as "Tor: Unspecified" because this probably 

Re: [tor-bugs] #25425 [Core Tor/Tor]: Add unittests for bridges.c module

[Tor Bug Tracker & Wiki]

#25425: Add unittests for bridges.c module
-+-
 Reporter:  isis |  Owner:  isis
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-unittests, tor-bridge, review-   |  Actual Points:
  group-35   |
Parent ID:   | Points:  2
 Reviewer:  ahf  |Sponsor:
 |  Sponsor8-can
-+-
Changes (by ahf):

 * status:  needs_review => needs_revision


Comment:

 Very nice with more tests!

 I have some tiny nitpicks where some of them goes for most of the code:

 - In `test_bridges.c`: I have no idea if we do personal copyright as well
 as TPI copyright. Someone else from the team probably knows I just haven't
 seen it before.
 - I think we usually try to bind the * in pointer declarations to the
 symbol name (`foo_t *foo` instead of `foo_t* foo`). This is a minor
 nitpick, but might be worth going over.
 - The `ADD_BRIDGE()` macro should probably get undefined after it's no
 longer needed.

 In `test_bridges_helper_func_add_bridges_to_bridgelist()` the
 `tt_int_op(0, OP_EQ, 0)` looks a bit odd - if it's needed maybe add a
 comment for why? Maybe it should be some kind of macro like `tt_skip()`
 but where the test isn't marked as skipped?

 In `test_bridges_get_configured_bridge_by_orports_digest()` do you have to
 remove constness from the return value of `bridge_list_get()`? As far as I
 can tell it's only used via `smartlist_get()` which accepts a `const
 smartlist_t *`. You also don't have to check for a possible `NULL` value
 of the `orports` variable since the `FREE_AND_NULL()` macro handles those
 gracefully.

 In `test_bridges_get_configured_bridge_by_addr_port_digest_digest_only()`,
 `test_bridges_get_configured_bridge_by_addr_port_digest_address_only()`,
 `test_bridges_get_configured_bridge_by_exact_addr_port_digest_donly()`,
 `test_bridges_get_configured_bridge_by_exact_addr_port_digest_both()`,
 `test_bridges_get_configured_bridge_by_exact_addr_port_digest_aonly()`,
 `test_bridges_get_transport_by_bridge_addrport_no_ptlist()`, and
 `test_bridges_get_transport_by_bridge_addrport()`: No need to check for
 `NULL` before freeing the `addr` variable.

 In `test_bridges_get_transport_by_bridge_addrport()`:
 - No need to check for `NULL` before freeing the `transport` variable.
 - Constness is added to some variables before they are passed to
 `get_transport_by_bridge_addrport()` - is that needed here?


 These were the only things that caught my attention when going over 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] #24767 [Core Tor/Tor]: All relays are constantly connecting to down relays and failing over and over

[Tor Bug Tracker & Wiki]

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

Comment (by nickm):

 53a26acb6172b7eb looks okay to me.  I'll write another patch to simplify
 it after this is merged.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by nickm):

 Replying to [comment:34 dgoulet]:
 > Replying to [comment:31 nickm]:
 > > So on the hash function: You can't use a memcpy(tor_addr_t) like that,
 because some of the bytes of the tor_addr_t can be unspecified.  I can fix
 that up.
 >
 > Oh damn because of the union, if it is a v4, we'll copy bunch of uninit
 bytes from the larger v6. I guess setting the size according to the family
 is the way to do it.
 >
 > > On unable_connect_since_ts: Do we ever clear this field (re-set it to
 zero) on success?  It seems like it just stays set forever.  If so maybe a
 better name would be something like "last_failed_connect_ts"?
 >
 > It is a timestamp, we don't need to reset it. It always being compared
 to a cutoff so even thought it is set once and never touched again, that
 is fine since it will at some point always pass the cutoff.

 Is it okay with you if I change the name anyway?  The problem is that the
 "since" implies a continuous condition.  If I say "I have been unable to
 eat broccoli since 1982", it does not mean only that in 1982 I failed to
 eat broccoli: it also means that at every time since 1982, I have also
 been unable to eat broccoli.

 > >  Oh, and one more thing I noticed: It is not enough to just check
 "node_get_pref_orport(node, _addr_port);" -- the node may have
 multiple addresses, and "pref" just returns the one you would prefer to
 use yourself.
 >
 > Not sure it is a problem here. We use `node_get_pref_orport()` only to
 make sure the or connection we are about to note down as a failure matches
 the `node_t` we have from the identity digest. In this case, we use the
 node_t to keep the timestamp. If it doesn't match (because other port/addr
 for the identity), we note it down as a "unknown".
 >
 > This ends up to be the same result but just more precisely indexed by
 addr + port + digest always.

 But the preferred address can change while Tor is running, I think, based
 on configuration options. That would make the value cached in the node
 become incorrect, and that's why I think we should maybe just not have
 this in the node_t at all.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  closed
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  implemented
 Keywords:  rust, tor-doc, review-group-35  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:  SponsorM
+--
Changes (by nickm):

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


Comment:

 Woo.  I think I have these merged.

 I had to rebase the first one onto maint-0.3.3 first, to merge it to that
 branch.  And I had to update the tor_log module to also use the second
 one.  So it's possible that I've messed something up here.  Please let me
 know if anything goes wrong. :)

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

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

[Tor Bug Tracker & Wiki]

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

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


Comment:

 Great, thanks for checking! Closing.

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

Re: [tor-bugs] #25575 [Internal Services/Tor Sysadmin Team]: Server space request (175 GB total) for hosting Tor Browser downloads

[Tor Bug Tracker & Wiki]

#25575: Server space request (175 GB total) for hosting Tor Browser downloads
-+-
 Reporter:  arthuredelstein  |  Owner:  tpa
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * cc: boklm (added)


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

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => merge_ready


Comment:

 This is fine now, runs, and passes.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25575 [Internal Services/Tor Sysadmin Team]: Server space request (175 GB total) for hosting Tor Browser downloads

[Tor Bug Tracker & Wiki]

#25575: Server space request (175 GB total) for hosting Tor Browser downloads
-+-
 Reporter:  arthuredelstein  |  Owner:  tpa
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We would like to offer more Tor Browser locales for download, and we'll
 need more disk space. Currently we serve 16 locales using a total of 41.23
 GB of disk space (with two releases of Tor Browser currently on disk). In
 addition, we currently have an additional 16 further locales for which
 translations are 100% complete.

 A single locale (including alpha and stable, bundles and update (mar)
 files, and all platforms, and two consecutive releases) requires 2.5 GB,
 which means we expect approximately 40 GB additional would be needed to
 host two releases of the remaining Tor Browser versions. That means a
 total of roughly 82 GB.

 However, we might expect to sometimes host as much as many three
 consecutive releases simultaneously, or 123 GB. On top of that, in the
 future, we will be adding mobile support, which increases the estimate to
 ~150 GB.

 In the future, we likely also will want to add more locales. It's
 difficult to know exactly how many this will be, but I would guess it will
 be 5 or less. Therefore I'm inclined to request that we increase the total
 space to 175 GB for now (including the ~42 GB already in use) for this
 year, and re-evaluate 1 year from now. Happy to discuss my calculations
 further as needed.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by sysrqb):

 Replying to [comment:11 arthuredelstein]:
 > These patches look good to me in general (though I haven't tested them
 yet). I'm wondering if it's necessary to add moz.build file, or if we
 could still build with the traditional makefile inside torlauncher.git,
 and then just copy the .xpi to the appropriate place when we bundle
 everything together in tor-browser-build.git?

 Unfortunately there are two reasons integrating this into the moz build
 process is useful. The first is because now at packaging-time a manifest
 file is created containing metadata about all system add-ons. If we
 package the xpi separately and copy it into the bundle then rbm will need
 to modify the json file. The second, which is similar to the first, is
 that when we add Android packaging into this build system we'll have
 additional jar manifest files which contain file hashes, so we'll need to
 add/update a few files there, too - so that'll be an additional pain.

 >
 > Keeping the torlauncher and torbutton extension builds independent of
 the Mozilla build system (if possible) seems like it will give us more
 flexibility. For example, I sometimes hack on torbutton.git without having
 a clone of mozilla-central present. I just copy the XPI to an existing Tor
 Browser build. And I occasionally post the .XPI for other people to test.

 This shouldn't have any impact on being able to drop in new versions. The
 system add-on manifest file doesn't prevent modifying the add-on, it
 simply restricts which system add-ons are loaded at start-up (there aren't
 any (cryptographic) hashes associated with it). So, we can build
 everything together and you can update tor-button and tor-launcher XPIs as
 needed afterward. I'm specifically looking for a seamless way of
 integrating these extensions. This probably only buys us 6-12 months of
 legacy support before we need another solution.

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

Re: [tor-bugs] #25573 [Core Tor/Tor]: Create a RELAY_COMMAND_END_ACK cell type

[Tor Bug Tracker & Wiki]

#25573: Create a RELAY_COMMAND_END_ACK cell type
---+--
 Reporter:  mikeperry  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  guard-discovery-stats  |  Actual Points:
Parent ID:  #25574 | Points:
 Reviewer: |Sponsor:  SponsorV-can
---+--
Changes (by mikeperry):

 * parent:   => #25574


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

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

[Tor Bug Tracker & Wiki]

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

Comment (by sysrqb):

 Replying to [comment:10 igt0]:
 > sysrqb, I see that the tor-launcher is still using
 `general.useragent.locale` and `intl.locale.matchOS`. Looks like a new
 XPCOM method was added `LocaleService::GetRequestedLocales`[1] to replace
 them.
 >
 > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1346616

 Oh, yes, good find. I'll correct this.

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

[tor-bugs] #25574 [Core Tor/Tor]: Eliminate "silent-drop" side channels in Tor protocol

[Tor Bug Tracker & Wiki]

#25574: Eliminate "silent-drop" side channels in Tor protocol
--+---
 Reporter:  mikeperry |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  guard-discovery-stats
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  SponsorV-can  |
--+---
 https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00

 There are lots of ways to inject data into Tor streams, and this is a
 vector of attack for guard discovery and confirmation:
 https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf

 I have a branch that tries to eliminate a pile of these from a while ago,
 but it has lots of false positives due to the common occurrence of invalid
 stream IDs in practice (see #25573).
 https://gitweb.torproject.org/mikeperry/tor.git/log/?h
 =timing_sidechannel_fix-squashed1

 I think we may want to do #25573 before trying to merge that branch.

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

Re: [tor-bugs] #20283 [Applications/Tor Browser]: Tor Browser should run without a `/proc` filesystem.

[Tor Bug Tracker & Wiki]

#20283: Tor Browser should run without a `/proc` filesystem.
--+---
 Reporter:  yawning   |  Owner:  pospeselr
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-sandboxing|  Actual Points:
Parent ID:  #20773| Points:
 Reviewer:|Sponsor:
--+---
Changes (by boklm):

 * cc: tbb-team (added)


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

Re: [tor-bugs] #25562 [Applications/Tor Browser]: Update Tor Browser Hacking page with Orfox instructions

[Tor Bug Tracker & Wiki]

#25562: Update Tor Browser Hacking page with Orfox instructions
--+--
 Reporter:  sysrqb|  Owner:  sysrqb
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by sysrqb):

 * cc: igt0 (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] #24767 [Core Tor/Tor]: All relays are constantly connecting to down relays and failing over and over

[Tor Bug Tracker & Wiki]

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

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:34 dgoulet]:
 > Replying to [comment:31 nickm]:
 > > So on the hash function: You can't use a memcpy(tor_addr_t) like that,
 because some of the bytes of the tor_addr_t can be unspecified.  I can fix
 that up.
 >
 > Oh damn because of the union, if it is a v4, we'll copy bunch of uninit
 bytes from the larger v6. I guess setting the size according to the family
 is the way to do it.

 Ok, did an attempt of this in fixup `53a26acb6172b7eb`. Not the prettiest
 but I don't see a way. Maybe we can abstract that in an inline function
 somehow like "tor_addr_get_ptr_size()" or sth around those lines?

 Still branch: `bug24767_033_02`

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25573 [Core Tor/Tor]: Create a RELAY_COMMAND_END_ACK cell type

[Tor Bug Tracker & Wiki]

#25573: Create a RELAY_COMMAND_END_ACK cell type
--+---
 Reporter:  mikeperry |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  guard-discovery-stats
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  SponsorV-can  |
--+---
 In order to eliminate a side channel attack described in
 https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf we
 need a way to determine if a stream id is invalid.

 Many clients (particularly Firefox) will hang up on streams that still
 have data in flight. In this case, Tor clients send RELAY_COMMAND_END when
 they are done with a stream, and immediately remove that stream ID from
 their valid stream mapping. The remaining application data continues to
 arrive, but is silently dropped by the Tor client. The result is that this
 ignored stream data currently can't be distinguished from injected dummy
 traffic with completely random stream IDs, and this fact can be used to
 mount side channel attacks.

 A similar situation exists for spurious RELAY_ENDs.

 This isn't a full fix, because malicious relays can withhold the ack, but
 having it in place would simplify a lot of the code for dealing with
 unexpected packets.

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

Re: [tor-bugs] #25572 [Applications/Tor Browser]: Of course, you don't care, but anyway (was: Upgrade to NoScript 5.1.8.5)

[Tor Bug Tracker & Wiki]

#25572: Of course, you don't care, but anyway
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 This summary shouldn't be modified by cypherpunks.

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

Re: [tor-bugs] #261 [Core Tor/Tor]: getinfo orconn-status sometimes crashes

[Tor Bug Tracker & Wiki]

#261: getinfo orconn-status sometimes crashes
--+
 Reporter:  goodell   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Blocker   | Resolution:  Fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickl):

 * severity:   => Blocker


Comment:

 Found this whitepaper: https://eprint.iacr.org/2018/162.pdf

 Not sure if it is still any use.

 Untagging Tor: A Formal Treatment of Onion Encryption


 Abstract. Tor is a primary tool for maintaining anonymity online. It
 provides a low-latency, circuit-based, bidirectional secure channel be-
 tween two parties through a network of onion routers, with the aim of
 obscuring exactly who is talking to whom, even to adversaries control-
 ling part of the network. Tor relies heavily on cryptographic techniques,
 yet its onion encryption scheme is susceptible to tagging attacks (Fu and
 Ling, 2009), which allow an active adversary controlling the first and
 last node of a circuit to deanonymize with near-certainty. This contrasts
 with less active traffic correlation attacks, where the same adversary can
 at best deanonymize with high probability. The Tor project has been ac-
 tively looking to defend against tagging attacks and its most concrete al-
 ternative is proposal 261, which specifies a new onion encryption scheme
 based on a variable-input-length tweakable cipher.
 We provide a formal treatment of low-latency, circuit-based onion en-
 cryption, relaxed to the unidirectional setting, by expanding existing
 secure channel notions to the new setting and introducing circuit hiding
 to capture the anonymity aspect of Tor. We demonstrate that circuit hiding
 prevents tagging attacks and show proposal 261’s relay protocol is circuit
 hiding and thus resistant against tagging attacks.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by dgoulet):

 Replying to [comment:31 nickm]:
 > So on the hash function: You can't use a memcpy(tor_addr_t) like that,
 because some of the bytes of the tor_addr_t can be unspecified.  I can fix
 that up.

 Oh damn because of the union, if it is a v4, we'll copy bunch of uninit
 bytes from the larger v6. I guess setting the size according to the family
 is the way to do it.

 > On unable_connect_since_ts: Do we ever clear this field (re-set it to
 zero) on success?  It seems like it just stays set forever.  If so maybe a
 better name would be something like "last_failed_connect_ts"?

 It is a timestamp, we don't need to reset it. It always being compared to
 a cutoff so even thought it is set once and never touched again, that is
 fine since it will at some point always pass the cutoff.

 >  Oh, and one more thing I noticed: It is not enough to just check
 "node_get_pref_orport(node, _addr_port);" -- the node may have
 multiple addresses, and "pref" just returns the one you would prefer to
 use yourself.

 Not sure it is a problem here. We use `node_get_pref_orport()` only to
 make sure the or connection we are about to note down as a failure matches
 the `node_t` we have from the identity digest. In this case, we use the
 node_t to keep the timestamp. If it doesn't match (because other port/addr
 for the identity), we note it down as a "unknown".

 This ends up to be the same result but just more precisely indexed by addr
 + port + digest always.

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

Re: [tor-bugs] #25562 [Applications/Tor Browser]: Update Tor Browser Hacking page with Orfox instructions

[Tor Bug Tracker & Wiki]

#25562: Update Tor Browser Hacking page with Orfox instructions
--+--
 Reporter:  sysrqb|  Owner:  sysrqb
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sysrqb):

 Replying to [comment:1 sysrqb]:
 > I wonder if Mozilla corrected the build-tools issues in Firefox 52+,
 I'll take a look at that and see if we can backport an easy patch (we can
 easily write our own patch, too).

 Okay, no, they were using the same versions [0] until last year [1]. Now I
 wonder if Google recently changed which version of build-tools they
 provide. If Google stopped supporting build-tools-23.0.3 with android-
 sdk-r24.0.1 then that adds some complexity for us. When I looked into this
 last night, I found the the manifest downloaded with sdk-r24.0.1 does not
 contain build-tools-23.0.3 [2], but the manifest downloaded with
 sdk-r25.2.5 does contain it [3].

 I think patching |mach bootstrap| so it fetches build-tools-23.0.1 (for
 the next few months) is the easiest solution.

 [0] https://hg.mozilla.org/mozilla-central/rev/01b0a01a38b1
 [1] https://hg.mozilla.org/mozilla-central/rev/0bae2cd79169
 [2] https://dl-ssl.google.com/android/repository/repository-10.xml
 [3] https://dl.google.com/android/repository/repository-11.xml

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

Re: [tor-bugs] #20283 [Applications/Tor Browser]: Tor Browser should run without a `/proc` filesystem.

[Tor Bug Tracker & Wiki]

#20283: Tor Browser should run without a `/proc` filesystem.
--+---
 Reporter:  yawning   |  Owner:  pospeselr
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-sandboxing|  Actual Points:
Parent ID:  #20773| Points:
 Reviewer:|Sponsor:
--+---

Comment (by jld):

 If `SECCOMP_FILTER_FLAG_TSYNC` isn't available and `/proc/self/task` can't
 be listed, the sandbox can't start.  The process is already multithreaded,
 so we have to signal all the threads to tell them to apply seccomp, and we
 don't have access to the libc's internal list of threads (or the lock
 protecting it) so we have to ask the kernel via procfs.

 The single-threadedness check, however, has been removed in Firefox 60, as
 part of https://bugzilla.mozilla.org/show_bug.cgi?id=1401062.

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

Re: [tor-bugs] #25572 [Applications/Tor Browser]: Upgrade to NoScript 5.1.8.5

[Tor Bug Tracker & Wiki]

#25572: Upgrade to   NoScript 5.1.8.5
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Important change from the changelog

 {{{
  x Automatic updates test
  + Updates for NoScript Classic are now served directly from
   secure.informaction.com due to beta channel deprecation and
   other problems with dual branches on AMO
 }}}

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

Re: [tor-bugs] #25572 [Applications/Tor Browser]: Upgrade to NoScript 5.1.8.5 (was: Of course, you don't care, but anyway)

[Tor Bug Tracker & Wiki]

#25572: Upgrade to   NoScript 5.1.8.5
--+--
 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:
--+--

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by boklm):

 Replying to [comment:57 boklm]:
 > I filed an upstream bug report:
 > https://sourceware.org/bugzilla/show_bug.cgi?id=22989
 This issue is actually already fixed in git (I should have tried a build
 using master before starting to bisect), so it should be fixed in the next
 binutils release.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25572 [Applications/Tor Browser]: Of course, you don't care, but anyway

[Tor Bug Tracker & Wiki]

#25572: Of course, you don't care, but anyway
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 NoScript 5.1.8.5 is out.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  merge_ready
 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
+--

Comment (by isis):

 Replying to [comment:11 nickm]:
 > I can't find `bug25310_r1`, and the `update/libc-0.2.39_r1` branch
 appears to have no new commits.  Did you forget to push it these?  Am I
 looking in the wrong place?

 I uh… yes. Totally did not push them! Heh. Sorry sorry, they are there
 now:

 https://gitweb.torproject.org/user/isis/tor.git/log/?h=bug25310_r1
 https://github.com/isislovecruft/tor-rust-
 dependencies/tree/update/libc-0.2.39_r1

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25571 [Metrics/Website]: Add an iCalendar feed of metrics events

[Tor Bug Tracker & Wiki]

#25571: Add an iCalendar feed of metrics events
-+--
 Reporter:  irl  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 #23854 added an ATOM feed for the news page. It also laid down enough
 framework that adding an iCalendar feed would be relatively easy.

 I'm adding this with a low priority, but if there are requests for it to
 be increased to medium (indicating that it would be used) then we should
 change the priority to medium.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25570 [Metrics/Website]: Allow autodiscovery of the news atom feed

[Tor Bug Tracker & Wiki]

#25570: Allow autodiscovery of the news atom feed
-+--
 Reporter:  irl  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   |   Keywords:  ux-team
Actual Points:   |  Parent ID:  #25404
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 A  needs to be added to the head of the news page to
 allow autodiscovery of the feed. As this will require changes to the
 templates used in all pages, I've not done this as part of adding the feed
 but will instead do it when we update templates for Bootstrap 4.

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

Re: [tor-bugs] #24965 [Applications/Tor Browser]: Automatically remove metadata from images (EXIF) before upload

[Tor Bug Tracker & Wiki]

#24965: Automatically remove metadata from images (EXIF) before upload
---+--
 Reporter:  arthuredelstein|  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-fingerprinting, gsoc-proposed  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by arthuredelstein):

 This project has been proposed for the Tor Summer of Privacy program for
 2018 and we are currently receiving applicants.

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

Re: [tor-bugs] #23947 [Obfuscation/Snowflake]: Move Snowflake proxy page somewhere devs can write

[Tor Bug Tracker & Wiki]

#23947: Move Snowflake proxy page somewhere devs can write
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by arma):

 Is there anything here that I/we can help with? Or is just picking one and
 doing 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] #25561 [Applications/Tor Check]: Update TBB User Agent String for detecting Orfox

[Tor Bug Tracker & Wiki]

#25561: Update TBB User Agent String for detecting Orfox
+-
 Reporter:  sysrqb  |  Owner:  arlolra
 Type:  enhancement | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Check  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by arlolra):

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


Comment:

 This was merged as
 
https://gitweb.torproject.org/check.git/commit/?id=aa25675a220bc91104fd887216d09314ca26c822

 > Thoughts on how long this will take to deploy?

 Done

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

Re: [tor-bugs] #23854 [Metrics/Website]: Add an RSS feed for https://metrics.torproject.org/news.html

[Tor Bug Tracker & Wiki]

#23854: Add an RSS feed for https://metrics.torproject.org/news.html
-+
 Reporter:  cypherpunks  |  Owner:  irl
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:  2.5
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by karsten):

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


Comment:

 Looks good! Merged and deployed! Yay. :)

 Regarding checkstyle and the diamond operator, I don't know whether we can
 put in a check specifically for that.

 Closing. Thanks!

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

Re: [tor-bugs] #23854 [Metrics/Website]: Add an RSS feed for https://metrics.torproject.org/news.html

[Tor Bug Tracker & Wiki]

#23854: Add an RSS feed for https://metrics.torproject.org/news.html
-+--
 Reporter:  cypherpunks  |  Owner:  irl
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:  2.5
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by irl):

 * actualpoints:   => 2.5


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  merge_ready
 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
+--

Comment (by nickm):

 I can't find `bug25310_r1`, and the `update/libc-0.2.39_r1` branch appears
 to have no new commits.  Did you forget to push it these?  Am I looking in
 the wrong place?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25569 [Webpages]: Add decoded:Legal's v3 onion service to NextGenOnions wiki

[Tor Bug Tracker & Wiki]

#25569: Add decoded:Legal's v3 onion service to NextGenOnions wiki
-+--
 Reporter:  cypherpunks  |  Owner:  asn
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Webpages |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 https://trac.torproject.org/projects/tor/wiki/doc/NextGenOnions

 Please add decoded:Legal's v3 onion service:

 `http://dlegal66uj5u2dvcbrev7vv6fjtwnd4moqu7j6jnd42rmbypv3coigyd.onion/`

 For verification purpose: `https://raw.githubusercontent.com/alecmuffett
 /onion-sites-that-dont-suck/master/README.md`

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

Re: [tor-bugs] #24965 [Applications/Tor Browser]: Automatically remove metadata from images (EXIF) before upload

[Tor Bug Tracker & Wiki]

#24965: Automatically remove metadata from images (EXIF) before upload
---+--
 Reporter:  arthuredelstein|  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-fingerprinting, gsoc-proposed  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by arma):

 I spoke to a person in Facebook legal who said that Facebook strips
 metadata from uploaded media (yay), but that they quietly store it
 separately in case somebody asks them for it (boo).

 So, yes, having Tor Browser do it on the user side would be yet another
 good case of having the user enforce their own safety through technical
 means, rather than hoping (policy means) that some third party does the
 right 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] #22079 [Community]: Community governance documents

[Tor Bug Tracker & Wiki]

#22079: Community governance documents
---+
 Reporter:  alison |  Owner:  alison
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Community  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by pospeselr):

 * cc: richard@… (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] #25568 [Core Tor/Tor]: hs: Lookup failure cache when introducing to an intro point

[Tor Bug Tracker & Wiki]

#25568: hs: Lookup failure cache when introducing to an intro point
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  security, tor-hs  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 > I think the same level of attack could happen just by listing a bunch of
 slightly different unreachable intro points.

 Right.  For example, I think it would waste waste just about as much
 resources if the descriptor were to just list 10 randomly generated
 nonexistent introduction points.

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

Re: [tor-bugs] #25285 [Applications/Tor Check]: Atlas is now called Relay Search and it has a new URL

[Tor Bug Tracker & Wiki]

#25285: Atlas is now called Relay Search and it has a new URL
+
 Reporter:  irl |  Owner:  irl
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Check  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  #25283  | Points:
 Reviewer:  arlolra |Sponsor:
+
Changes (by arlolra):

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


Comment:

 Thanks, merged as
 
https://gitweb.torproject.org/check.git/commit/?id=21b48f63d24a8ab2b900d158e06dd4bf979148f1

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

Re: [tor-bugs] #25486 [Applications/Tor Check]: Clicking "run a relay" on check.torproject.org should link to the TorRelayGuide

[Tor Bug Tracker & Wiki]

#25486: Clicking "run a relay" on check.torproject.org should link to the
TorRelayGuide
+-
 Reporter:  Dbryrtfbcbhgf   |  Owner:  arlolra
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Check  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by arlolra):

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


Comment:

 Fixed in
 
https://gitweb.torproject.org/check.git/commit/?id=dc2bd6e0f05626e14074916b5e634a98e97f250a

 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] #24767 [Core Tor/Tor]: All relays are constantly connecting to down relays and failing over and over

[Tor Bug Tracker & Wiki]

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

Comment (by nickm):

 Oh, and one more thing I noticed: It is not enough to just check
 "node_get_pref_orport(node, _addr_port);" -- the node may have
 multiple addresses, and "pref" just returns the one you would prefer to
 use yourself.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust 033-must protover security  |  Actual Points:  5
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:  SponsorM-
 |  can
-+-
Changes (by nickm):

 * cc: teor (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] #25568 [Core Tor/Tor]: hs: Lookup failure cache when introducing to an intro point

[Tor Bug Tracker & Wiki]

#25568: hs: Lookup failure cache when introducing to an intro point
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  security, tor-hs  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Replying to [ticket:25568 dgoulet]:
 > a malicious service would induce many circuits out of the client than
 necessary. This can be used, theoretically, for a client guard discovery
 attack.

 I think the same level of attack could happen just by listing a bunch of
 slightly different unreachable intro points. So I don't think we should
 think of ourselves as fixing a client guard discovery attack at all, when
 we fix this ticket.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by nickm):

 So on the hash function: You can't use a memcpy(tor_addr_t) like that,
 because some of the bytes of the tor_addr_t can be unspecified.  I can fix
 that up.

 On unable_connect_since_ts: Do we ever clear this field (re-set it to
 zero) on success?  It seems like it just stays set forever.  If so maybe a
 better name would be something like "last_failed_connect_ts"?

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

Re: [tor-bugs] #25568 [Core Tor/Tor]: hs: Lookup failure cache when introducing to an intro point

[Tor Bug Tracker & Wiki]

#25568: hs: Lookup failure cache when introducing to an intro point
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  security, tor-hs  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 My original suggestion for fixing was that we should consult our failure
 cache when we're about to launch another try.

 But then I realized that maybe we should instead strip duplicate intro
 points when we process the descriptor.

 But then I realized that maybe we should disallow duplicate intro points
 in the protocol, i.e. say in that spec that you can't do that, and then
 refuse descriptors that do.

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  merge_ready => needs_revision


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

Re: [tor-bugs] #24989 [Core Tor/Tor]: Count hsdir requests against maxcircuitspending

[Tor Bug Tracker & Wiki]

#24989: Count hsdir requests against maxcircuitspending
-+
 Reporter:  mikeperry|  Owner:  mikeperry
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-34  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+

Comment (by asn):

 Patch LGTM. I pushed a branch `bug24989` in my github repo (!):
 `https://github.com/asn-d6/tor` which is rebased to latest master, and
 also fixes the change entry a bit.

 Mike please check it out, and let's put this in `merge_ready`.

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

Re: [tor-bugs] #25560 [Core Tor/Tor]: test all rust crates for realsies

[Tor Bug Tracker & Wiki]

#25560: test all rust crates for realsies
-+-
 Reporter:  isis |  Owner:  (none)
 Type:  defect   | Status:  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-testing, rust, 033-must  |  Actual Points:
Parent ID:   | Points:  .2
 Reviewer:  nickm|Sponsor:  SponsorM-can
-+-
Changes (by nickm):

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


Comment:

 Right, we need to handle the case.  Let's make sure that we're actually
 testing this in a checkout that's in a directory in a space with it, or
 else some poor Windows user will be the first person to debug this.

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

Re: [tor-bugs] #25568 [Core Tor/Tor]: hs: Lookup failure cache when introducing to an intro point

[Tor Bug Tracker & Wiki]

#25568: hs: Lookup failure cache when introducing to an intro point
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  security, tor-hs  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by asn):

 * cc: asn (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] #17799 [Core Tor/Tor]: Use a better PRNG unless OpenSSL starts using a better one on their own.

[Tor Bug Tracker & Wiki]

#17799: Use a better PRNG unless OpenSSL starts using a better one on their own.
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-client, prng, |  worksforme
  crypto, review-group-34|  Actual Points:  5
Parent ID:   | Points:  5
 Reviewer:  asn  |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 > Nick also told me something about future OpenSSL releases changing their
 RNG algorithm too, but I could't find info about this...

 From the OpenSSL 1.1.1 changelog:

 {{{
   *) Grand redesign of the OpenSSL random generator

  The default RAND method now utilizes an AES-CTR DRBG according to
  NIST standard SP 800-90Ar1. The new random generator is essentially
  a port of the default random generator from the OpenSSL FIPS 2.0
  object module. It is a hybrid deterministic random bit generator
  using an AES-CTR bit stream and which seeds and reseeds itself
  automatically using trusted system entropy sources.

  Some of its new features are:
   o Support for multiple DRBG instances with seed chaining.
   o Add a public DRBG instance for the default RAND method.
   o Add a dedicated DRBG instance for generating long term private
 keys.
   o Make the DRBG instances fork-safe.
   o Keep all global DRBG instances on the secure heap if it is
 enabled.
   o Add a DRBG instance to every SSL instance for lock free operation
 and to increase unpredictability.
  [Paul Dale, Benjamin Kaduk, Kurt Roeckx, Rich Salz, Matthias St.
 Pierre]
 }}}

 So yeah, I think it's fine for us to drop this.  No worries; I had fun
 writing the code, but I don't need to maintain it forever.

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

[tor-bugs] #25568 [Core Tor/Tor]: hs: Lookup failure cache when introducing to an intro point

[Tor Bug Tracker & Wiki]

#25568: hs: Lookup failure cache when introducing to an intro point
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  security, tor-hs
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 It turns out that if a descriptor contains 10 times the same intro point,
 and that the first introduction attempt fails, we'll try to connect to the
 same failing intro point again for all subsequent remaining intro points.

 The intro point failure cache was introduced to avoid such a situation but
 it is only used between two descriptors that is if an intro point failed
 from the first descriptor and that intro point is still present in the
 second descriptor fetched, we ignore it.

 However, this situation is about the same intro point in the same
 descriptor. In normal circumstances, this can't happen but it is still
 allowed by the protocol.

 One issue with this is that a malicious service would induce many circuits
 out of the client than necessary. This can be used, theoretically, for a
 client guard discovery attack.

 This affects both v2 and v3.

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

Re: [tor-bugs] #25561 [Applications/Tor Check]: Update TBB User Agent String for detecting Orfox

[Tor Bug Tracker & Wiki]

#25561: Update TBB User Agent String for detecting Orfox
+--
 Reporter:  sysrqb  |  Owner:  arlolra
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Check  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by n8fr8):

 Thoughts on how long this will take to deploy?

 Juts wondering if I should hold the Orfox release to wait for 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] #25239 [Metrics/Relay Search]: Link to server descriptor and extra info descriptor when relays have a DirPort

[Tor Bug Tracker & Wiki]

#25239: Link to server descriptor and extra info descriptor when relays have a
DirPort
--+--
 Reporter:  irl   |  Owner:  metrics-team
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  0.1
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+--
Changes (by irl):

 * status:  new => merge_ready
 * actualpoints:   => 0.1


Comment:

 This is now implemented in my
 
[[https://gitweb.torproject.org/user/irl/atlas.git/log/?h=task/25239|task/25239]]
 branch.

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => merge_ready


Comment:

 LGTM! :)

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

Re: [tor-bugs] #25558 [Metrics/Relay Search]: Warning on Relay Search about outdated Tor is misleading

[Tor Bug Tracker & Wiki]

#25558: Warning on Relay Search about outdated Tor is misleading
--+-
 Reporter:  pastly|  Owner:  irl
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by irl):

 * status:  accepted => merge_ready


Comment:

 I've made these changes on my
 
[[https://gitweb.torproject.org/user/irl/atlas.git/log/?h=task/25558|task/25558]]
 branch.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by arma):

 I'm a fan.

 In fact, if we're doing just-in-time refilling, we might even be able to
 get more fine-grained than once-every-100-ms. That is, we could look at
 how far through the second we are, and refill proportional to that
 fraction.

 (It is an open question whether we still have strange bumps in our
 bandwidth flows now that we moved to 10-refills per second. We definitely
 had the strange bumps when it was 1-refill-per-second. Also, refill rates
 interact in subtle ways with the scheduler, so it might be good to check
 with pastly/rob/dgoulet to see if they have any guidance here.)

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

Re: [tor-bugs] #17799 [Core Tor/Tor]: Use a better PRNG unless OpenSSL starts using a better one on their own.

[Tor Bug Tracker & Wiki]

#17799: Use a better PRNG unless OpenSSL starts using a better one on their own.
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-client, prng, |  Actual Points:  5
  crypto, review-group-34|
Parent ID:   | Points:  5
 Reviewer:  asn  |Sponsor:
-+-
Changes (by asn):

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


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

Re: [tor-bugs] #17799 [Core Tor/Tor]: Use a better PRNG unless OpenSSL starts using a better one on their own.

[Tor Bug Tracker & Wiki]

#17799: Use a better PRNG unless OpenSSL starts using a better one on their own.
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-client, prng, |  Actual Points:  5
  crypto, review-group-34|
Parent ID:   | Points:  5
 Reviewer:  asn  |Sponsor:
-+-
Changes (by asn):

 * status:  needs_review => new


Comment:

 Hmm, this ticket again! My intuition here is to NACK this for now even tho
 I feel like the code is probably OK, and that's for the following reasons:
 - The code here is 2 years old, and will add about 1k LoC to our PRNG
 subsystem. Even tho the code is probably OK, it's quite complicated and we
 will need to maintain it. This is also a pretty big feature for something
 not on the roadmap.
 - All this is done to protect against the threat of backdoored RNGs like
 Dual-EC, or horribly bad RNGs which get broken if some of their state gets
 leaked. I haven't heard of this threat since the Dual-EC thing happened,
 and not sure if trying to fix it on the Tor-layer is a good idea.
 - WRT fixing this on the Tor layer, this might be suboptimal since our
 other libraries (like our SSL lib) can also reveal the state of our RNG
 and hence leak it even tho we patched it in Tor. In general, I feel that
 if we don't trust OpenSSL or our crypto libraries we are already pretty-
 much screwed up...

 In general, I feel inclined to put this back in `Tor: unspecified` or
 `WONTFIX` it and revive it in the future if we ever need to (hopefully
 not).

 Nick also told me something about future OpenSSL releases changing their
 RNG algorithm too, but I could't find info about this...

 Setting this is as `new` for now.
 Nick, what do you think? This ticket was lots of work and I don't want to
 put it to waste so easily.

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

Re: [tor-bugs] #25154 [Applications/Tor Browser Sandbox]: Tab crashing in sandboxed 8.0a1, sandbox 0.0.16, linux x86_64

[Tor Bug Tracker & Wiki]

#25154: Tab crashing in sandboxed 8.0a1, sandbox 0.0.16, linux x86_64
--+-
 Reporter:  ln5   |  Owner:  yawning
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by arma):

 For posterity, my complaints in stdout were:
 {{{
 2018/03/21 09:29:10 firefox: [Parent 3] WARNING: pipe error (88):
 Connection reset by peer: file /var/tmp/build/firefox-
 fcaf1340c7f0/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 322
 2018/03/21 09:29:10 firefox: [Parent 3] WARNING: pipe error (57):
 Connection reset by peer: file /var/tmp/build/firefox-
 fcaf1340c7f0/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 322
 2018/03/21 09:29:10 firefox: [Parent 3] WARNING: pipe error (30):
 Connection reset by peer: file /var/tmp/build/firefox-
 fcaf1340c7f0/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 322
 2018/03/21 09:29:10 firefox: ###!!! [Parent][MessageChannel] Error:
 (msgtype=0x2C0084,name=PBrowser::Msg_Destroy) Channel error: cannot
 send/recv
 2018/03/21 09:29:10 firefox: ###!!! [Parent][MessageChannel] Error:
 (msgtype=0x2C0084,name=PBrowser::Msg_Destroy) Channel error: cannot
 send/recv
 2018/03/21 09:29:10 firefox: ###!!! [Parent][MessageChannel] Error:
 (msgtype=0x2C0084,name=PBrowser::Msg_Destroy) Channel error: cannot
 send/recv
 2018/03/21 09:29:10 firefox: ###!!! [Parent][MessageChannel] Error:
 (msgtype=0x2C0084,name=PBrowser::Msg_Destroy) Channel error: cannot
 send/recv
 2018/03/21 09:29:10 firefox: ###!!! [Parent][MessageChannel] Error:
 (msgtype=0x2C0084,name=PBrowser::Msg_Destroy) Channel error: cannot
 send/recv
 }}}

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

Re: [tor-bugs] #25567 [Applications/Tor Browser Sandbox]: Frequent "Gah. Your tab just crashed" with sandboxed-tor-browser

[Tor Bug Tracker & Wiki]

#25567: Frequent "Gah. Your tab just crashed" with sandboxed-tor-browser
--+---
 Reporter:  arma  |  Owner:  yawning
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by arma):

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


Comment:

 Closing as duplicate of #25154.

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

Re: [tor-bugs] #25154 [Applications/Tor Browser Sandbox]: Tab crashing in sandboxed 8.0a1, sandbox 0.0.16, linux x86_64

[Tor Bug Tracker & Wiki]

#25154: Tab crashing in sandboxed 8.0a1, sandbox 0.0.16, linux x86_64
--+-
 Reporter:  ln5   |  Owner:  yawning
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by arma):

 https://www.washingtonpost.com/news/morning-mix/wp/2018/03/21/austin-
 bombing-suspect-dies-after-detonating-explosive-in-his-vehicle-police-say/
 does it to me too, in my sandboxed-tor-browser running tor browser 7.5.2.

 I just filed #25567 which apparently is a duplicate of this one.

 For me it started with the upgrade from 7.5 to 7.5.1: 7.5 in sandboxed-
 tor-browser was solid, and 7.5.1 was not.

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

Re: [tor-bugs] #25500 [Core Tor/Tor]: Reduce client CPU usage when idle (was: Reduce client CPU usage whien idle)

[Tor Bug Tracker & Wiki]

#25500: Reduce client CPU usage when idle
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-client|  Actual Points:
Parent ID:| Points:
 Reviewer:|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

Re: [tor-bugs] #14389 [Applications/Tor Browser]: Improve TBB UI of hidden service client authorization

[Tor Bug Tracker & Wiki]

#14389: Improve TBB UI of hidden service client authorization
+--
 Reporter:  asn |  Owner:  tbb-team
 Type:  defect  | Status:
|  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, tbb-usability, ux-team  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by dgoulet):

 Replying to [comment:22 asn]:
 > Executive summary No2: v2 descriptors do not let us distinguish between
 descs where the auth is enabled or whether they are corrupted, so Tor
 keeps on trying new directories in hope of finding a non-corrupted desc.
 In this sense, the current approach of the patch is not bad.

 Indeed... and not only that but a warning will be emitted because we'll
 try to parse the introduction point using a binary blob (encrypted).

 Proposition:

 Upon receiving a descriptor from the HSDir, if we can parse it (passes
 `rend_parse_v2_service_descriptor()`) but unable to decode intro points,
 we actually keep it in the client cache. Meaning that once Tor browser (or
 tor client) comes back with the authentication token, we don't have to
 refetch it. We'll probably to patch couples things here to make sure that
 we can use a descriptor in our cache with client auth but also that if the
 auth token is invalid, we trigger a `BAD_DESC` event.

 Another approach would be to have a control port option (or torrc) to tell
 tor to keep any invalid but parseable descriptor which TB would enable.
 But honestly, for the sake of simplicity, I think we could easily keep it
 in the client cache which is bound to expire after a while normally.

 That being said, TB does need to check for the `BAD_DESC` event of
 `HS_DESC` mentioned in comment:11. Once you get that, you should prompt
 for a client authorization. If you don't see that event after, it should
 be connecting. Else, tor should trigger the event again and TB should ask
 again for the auth code.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25567 [Applications/Tor Browser Sandbox]: Frequent "Gah. Your tab just crashed" with sandboxed-tor-browser

[Tor Bug Tracker & Wiki]

#25567: Frequent "Gah. Your tab just crashed" with sandboxed-tor-browser
--+-
 Reporter:  arma  |  Owner:  yawning
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Sometimes my sandboxed-tor-browser (running Tor Browser 7.5.2) works ok.
 But sometimes it gets into a fit of "Gah. Your tab just crashed" failures.
 When those happen, I get this string of complaints in my stdout:
 {{{
 2018/03/21 09:29:10 firefox: [Parent 3] WARNING: pipe error (88):
 Connection reset by peer: file /var/tmp/build/firefox-
 fcaf1340c7f0/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 322
 2018/03/21 09:29:10 firefox: [Parent 3] WARNING: pipe error (57):
 Connection reset by peer: file /var/tmp/build/firefox-
 fcaf1340c7f0/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 322
 2018/03/21 09:29:10 firefox: [Parent 3] WARNING: pipe error (30):
 Connection reset by peer: file /var/tmp/build/firefox-
 fcaf1340c7f0/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 322
 2018/03/21 09:29:10 firefox: ###!!! [Parent][MessageChannel] Error:
 (msgtype=0x2C0084,name=PBrowser::Msg_Destroy) Channel error: cannot
 send/recv
 2018/03/21 09:29:10 firefox: ###!!! [Parent][MessageChannel] Error:
 (msgtype=0x2C0084,name=PBrowser::Msg_Destroy) Channel error: cannot
 send/recv
 2018/03/21 09:29:10 firefox: ###!!! [Parent][MessageChannel] Error:
 (msgtype=0x2C0084,name=PBrowser::Msg_Destroy) Channel error: cannot
 send/recv
 2018/03/21 09:29:10 firefox: ###!!! [Parent][MessageChannel] Error:
 (msgtype=0x2C0084,name=PBrowser::Msg_Destroy) Channel error: cannot
 send/recv
 2018/03/21 09:29:10 firefox: ###!!! [Parent][MessageChannel] Error:
 (msgtype=0x2C0084,name=PBrowser::Msg_Destroy) Channel error: cannot
 send/recv
 }}}

 Is this just #25540-come-early, or is this a little simple bug that should
 be found and squashed? :)

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

Re: [tor-bugs] #25558 [Metrics/Relay Search]: Warning on Relay Search about outdated Tor is misleading

[Tor Bug Tracker & Wiki]

#25558: Warning on Relay Search about outdated Tor is misleading
--+--
 Reporter:  pastly|  Owner:  irl
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by irl):

 arma suggested to change the last sentence to:

 > Development versions (versions that are too new) will also trigger this
 warning message (see bug xxx).

 I think we should make that change.

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

Re: [tor-bugs] #25564 [Community/Relays]: DNS-over-HTTPS for exit relays

[Tor Bug Tracker & Wiki]

#25564: DNS-over-HTTPS for exit relays
--+--
 Reporter:  cypherpunks   |  Owner:  Nusenu
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Community/Relays  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by irl):

 There are open source implementations for DNS resolvers supporting DNS-
 over-HTTPS. For example [[https://github.com/m13253/dns-over-https|this
 one]]. More will probably appear as work in the IETF progresses. I would
 still hope that exit operators would set up a local stub resolver to
 perform DNSSEC validation, so the instructions would be about how to
 configure that stub resolver to forward to a DNS-over-HTTPS resolver.

 Even having 20 resolvers is too concentrated in my opinion, but this is
 just based on my general feelings about it, not based on any actual
 research. Someone should do some research (or find some that has already
 been done) so that we can decide if this is a good thing that we should
 recommend or if it's actually a thing that would make the situation worse.

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

Re: [tor-bugs] #25564 [Community/Relays]: DNS-over-HTTPS for exit relays

[Tor Bug Tracker & Wiki]

#25564: DNS-over-HTTPS for exit relays
--+--
 Reporter:  cypherpunks   |  Owner:  Nusenu
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Community/Relays  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * status:  closed => reopened
 * priority:  Very Low => Medium
 * resolution:  fixed =>
 * severity:  Trivial => Normal


Comment:

 Could you outline your threat model? (what do you want to protect from
 whom)
 (in a context of: most tor traffic is http/https)


 You need more than one semi-trusted resolver (we don't want to give _any_
 single entity all exit DNS traffic), we would need at least ~20.

 I prefer DNS-over-TLS over DNS-over-HTTPS.

 https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers

 The problem is: even if you hide DNS content with encryption from a
 passive observer, they can still watch HTTP and TLS/SNI hostnames and get
 the same 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] #18854 [Applications/Tor Browser]: Orfox's UserAgent different than other TBB

[Tor Bug Tracker & Wiki]

#18854: Orfox's UserAgent different than other TBB
--+-
 Reporter:  ikurua22  |  Owner:  n8fr8
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by cypherpunks):

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


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

Re: [tor-bugs] #25564 [Community/Relays]: DNS-over-HTTPS for exit relays

[Tor Bug Tracker & Wiki]

#25564: DNS-over-HTTPS for exit relays
--+
 Reporter:  cypherpunks   |  Owner:  Nusenu
 Type:  defect| Status:  closed
 Priority:  Very Low  |  Milestone:
Component:  Community/Relays  |Version:
 Severity:  Trivial   | Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by cypherpunks):

 * status:  new => closed
 * priority:  Medium => Very Low
 * resolution:   => fixed
 * severity:  Normal => Trivial


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

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

[Tor Bug Tracker & Wiki]

#16472: Upgrade Binutils to 2.25+ for Tor Browser builds
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-rbm, TorBrowserTeam201803R,  |  Actual Points:
  boklm201803|
Parent ID:  #12968   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

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


Comment:

 I filed an upstream bug report:
 https://sourceware.org/bugzilla/show_bug.cgi?id=22989

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

Re: [tor-bugs] #25558 [Metrics/Relay Search]: Warning on Relay Search about outdated Tor is misleading

[Tor Bug Tracker & Wiki]

#25558: Warning on Relay Search about outdated Tor is misleading
--+--
 Reporter:  pastly|  Owner:  irl
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by irl):

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


Comment:

 Replying to [comment:3 cypherpunks]:
 > I'd say lets close this (#25558) as a duplicate of #24256

 This is not a duplicate. This ticket is about updating the text to make it
 more useful as an intermediate step between now and #24256 being
 implemented.

 Replying to [comment:4 arma]:
 > Remember also that *users* use atlas to better understand the relays
 they might use. Do you want the people who make relay blacklists to add
 all of the relays-running-new-versions to their lists, because we said
 they are insecure?

 That too, indeed.

 My attempt:

 {{{
 This relay is running a version of Tor that is not recommended.
 It is most likely too old and may be missing important security fixes. If
 this is the case, and this is your relay, you should update it as soon as
 possible. Pre-release versions (versions that are too new) are also not
 recommended and so will trigger this warning message.
 }}}

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

Re: [tor-bugs] #18361 [Applications/Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  1000
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 > Addon reviewers aren't "Mozilla"

 Addon reviewers are Mozilla because they can control what they want.

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

Re: [tor-bugs] #25564 [Community/Relays]: DNS-over-HTTPS for exit relays

[Tor Bug Tracker & Wiki]

#25564: DNS-over-HTTPS for exit relays
--+
 Reporter:  cypherpunks   |  Owner:  Nusenu
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Community/Relays  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 Replying to [comment:1 cypherpunks]:
 > Yes, I had the same idea but I came to the conclusion that it is worse
 since you give all data to 3th party (your DNS-over-HTTPS resolver)
 instead of not using any forwarding at all.
 With plaintext DNS with ISP's own DNS server, those who can see the DNS
 requests: ISP + anyone snooping on the exit.

 With DNS-over-HTTPS with a DNS server other than ISP: Only DNS server can
 see the requests (+ anyone who can force them to hand that data). ISP +
 anyone snooping on the exit isn't included.

 I think it's less, isn't it? The only problem is finding some trustworthy
 DNS-over-HTTPS server (Google and Cloudflare are not okay).

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

Re: [tor-bugs] #18361 [Applications/Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  1000
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:288 cypherpunks]:
 > Mozilla is controlled by idiots.
 Addon reviewers aren't "Mozilla". I think you can come to a resolution to
 get the addon back but please don't spam this bugtracker.

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

Re: [tor-bugs] #25566 [Applications/Tor Browser]: Include or add an option to close connection to Cloudflare.

[Tor Bug Tracker & Wiki]

#25566: Include or add an option to close connection to Cloudflare.
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  project  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  security, privacy, anonymity, mitm,  |  duplicate
  cloudflare,mozilla |  Actual Points:
Parent ID:  #18361   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

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


Comment:

 Please don't create duplicates of ticket #24351

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

Re: [tor-bugs] #23854 [Metrics/Website]: Add an RSS feed for https://metrics.torproject.org/news.html

[Tor Bug Tracker & Wiki]

#23854: Add an RSS feed for https://metrics.torproject.org/news.html
-+--
 Reporter:  cypherpunks  |  Owner:  irl
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by irl):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:14 karsten]:
 >  - You should read about "Java diamond operator". In several places
 you're undoing changes that we made quite recently when switching to Java
 7. For example, we prefer `List aList = new ArrayList<>();` over
 `List aList = new ArrayList();'.

 Fixed.

 That's going to be a hard habit to break. Is there something we can add to
 checkstyle to catch this?

 >  - Please add a space after the closing bracket in `return (String[])
 this.protocols.toArray()` and related places.

 Fixed.

 >  - I think your code prints a news entry with `start == end` as "start
 to end", whereas the current code would print it as just "start". Can you
 change that back?

 Fixed.

 >  - You picked non-standard Java variable names like `short_desc` and
 fixed them in a later commit. Can you rather make such fixes to your own
 commits as "fixup" or "squash" commits and either squash them yourself or
 let me do that as part of the merge process?

 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] #25566 [Applications/Tor Browser]: Include or add an option to close connection to Cloudflare.

[Tor Bug Tracker & Wiki]

#25566: Include or add an option to close connection to Cloudflare.
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  project  | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  security, privacy, anonymity, mitm,  |  Actual Points:
  cloudflare,mozilla |
Parent ID:  #18361   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

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


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

Re: [tor-bugs] #18342 [Metrics/Onionoo]: Provide more accurate reverse DNS results

[Tor Bug Tracker & Wiki]

#18342: Provide more accurate reverse DNS results
-+--
 Reporter:  cypherpunks  |  Owner:  irl
 Type:  defect   | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by irl):

 I really don't like the `dns_ptr` name for the field. I think Onionoo
 works at a higher level than that.  I think I definitely prefer the
 `unverified_host_name` and `host_name` approach. To get the behaviour
 you're looking for in JavaScript would be:

 {{{
 dns_ptr = relay['host_name'] || relay['unverified_host_name'];
 }}}

 or Python:

 {{{
 dns_ptr = relay.get('host_name', None) or
 relay.get('unverified_host_name', None)
 }}}

 The approach where you have dns_ptr and host_name means that when
 correctly configured, the host name would end up included twice. I just
 don't feel that that's the most elegant solution.

 I'll take a look at a patch for the spec later this week, but to outline:

 * For `host_name` we implement the spec as it is (actually omitting the
 field instead of returning IP addresses).
 * For `unverified_host_name`, this will include the DNS PTR record's name.
 It would be updated at the same time as the host_name record. Omitted if
 the host name was verified by looking up an A record, or if no PTR record
 was found.

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

Re: [tor-bugs] #25564 [Community/Relays]: DNS-over-HTTPS for exit relays

[Tor Bug Tracker & Wiki]

#25564: DNS-over-HTTPS for exit relays
--+
 Reporter:  cypherpunks   |  Owner:  Nusenu
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Community/Relays  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 Yes, I had the same idea but I came to the conclusion that it is worse
 since you give all data to 3th party (your DNS-over-HTTPS resolver)
 instead of not using any forwarding at all.

 Unless there are strong arguments against it I'll leave it as is.

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