Re: [tor-bugs] #24117 [Core Tor/Tor]: Make a repository to hold our rust dependencies in a form Cargo can use

2017-12-04 Thread Tor Bug Tracker & Wiki
#24117: Make a repository to hold our rust dependencies in a form Cargo can use
-+
 Reporter:  nickm|  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust jenkins rust-pilot  |  Actual Points:
Parent ID:  #24035   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by Sebastian):

 (that said, we should definitely plan to transition away from that repo
 eventually)

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

Re: [tor-bugs] #24117 [Core Tor/Tor]: Make a repository to hold our rust dependencies in a form Cargo can use

2017-12-04 Thread Tor Bug Tracker & Wiki
#24117: Make a repository to hold our rust dependencies in a form Cargo can use
-+
 Reporter:  nickm|  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust jenkins rust-pilot  |  Actual Points:
Parent ID:  #24035   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by Sebastian):

 I think this ticket originally was made without awareness of the personal
 repo

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

Re: [tor-bugs] #24035 [Internal Services/Service - jenkins]: It would be great to have a rust builder on jenkins

2017-12-04 Thread Tor Bug Tracker & Wiki
#24035: It would be great to have a rust builder on jenkins
-+
 Reporter:  nickm|  Owner:  weasel
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - jenkins  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  jenkins, rust, rust-pilot|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by isis):

 * keywords:   => jenkins, rust, rust-pilot


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

Re: [tor-bugs] #24117 [Core Tor/Tor]: Make a repository to hold our rust dependencies in a form Cargo can use

2017-12-04 Thread Tor Bug Tracker & Wiki
#24117: Make a repository to hold our rust dependencies in a form Cargo can use
-+
 Reporter:  nickm|  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust jenkins rust-pilot  |  Actual Points:
Parent ID:  #24035   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by isis):

 * keywords:  rust jenkins => rust jenkins rust-pilot


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

Re: [tor-bugs] #24117 [Core Tor/Tor]: Make a repository to hold our rust dependencies in a form Cargo can use

2017-12-04 Thread Tor Bug Tracker & Wiki
#24117: Make a repository to hold our rust dependencies in a form Cargo can use
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust jenkins  |  Actual Points:
Parent ID:  #24035| Points:
 Reviewer:|Sponsor:
--+

Comment (by isis):

 Is this ticket for making an "official" repo (i.e. other than
 https://gitweb.torproject.org/user/sebastian/tor-rust-dependencies.git/)?

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

Re: [tor-bugs] #24415 [Applications/Tor Browser]: Tor crashes when opening new tab, reason unknown

2017-12-04 Thread Tor Bug Tracker & Wiki
#24415: Tor crashes when opening new tab, reason unknown
--+---
 Reporter:  kouwei32  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by kouwei32):

 Now it's even worse. I downloaded a fresh install of Tor on my PC,
 installed it on a separate directory, and it worked fine at first, but
 today it's appearing to have the same problem. It seems like to happen
 after I changed to go into homepage directly and have my homepage as a
 custom StartPage setting link. Not sure why, but could be cause by system
 environments. Running Windows 10, Version 1709, Build 16299.64, x64. Using
 bootcamp on a MacBook Air (Which caused some other problems before). The
 problem shouldn't be across systems because Tor works perfectly on macos.

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

Re: [tor-bugs] #22768 [Internal Services/Service - jenkins]: Add building Tor with Rust support to Jenkins

2017-12-04 Thread Tor Bug Tracker & Wiki
#22768: Add building Tor with Rust support to Jenkins
-+-
 Reporter:  isis |  Owner:  weasel
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - jenkins  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, tor-ci |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by isis):

 * status:  new => needs_review


Comment:

 There is this issue with cargo in the jenkins builds:
 https://jenkins.torproject.org/job/tor-ci-linux-master-
 rust/ARCHITECTURE=i386,SUITE=sid/24/console where it spits out `error:
 error: attempting to make an HTTP request, but --frozen was specified`.

 This is due to part of the cargo source code,
 `init_git_transports(config);` in the `execute` function of
 `cargo.git/src/bin/cargo.rs`, trying to obtain a copy of the registry (the
 git repo that tells you about which crates are published). Alex Crichton
 realised that it's due to building in a directory which doesn't have a
 `cargo` subdirectory (nor do any of its parents), which is due to us doing
 jenkins builds out-of-tree. The solution, or at least a workaround, is to
 do `cp -aR build-tree/src/rust/.cargo ~/` after running
 `../tor/configure`.

 Here is a [https://github.com/isislovecruft/tor-jenkins-
 tools/commit/f8af924a75902f261874fe1670a56d63cef942eb patch].

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

Re: [tor-bugs] #24525 [Internal Services/Tor Sysadmin Team]: Please create LDAP access for sysrqb

2017-12-04 Thread Tor Bug Tracker & Wiki
#24525: Please create LDAP access for sysrqb
-+-
 Reporter:  ewyatt   |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 You're in luck! Matt already has an ldap account.

 You can see who has one by going to https://db.torproject.org and clicking
 'search'.

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

Re: [tor-bugs] #22068 [Core Tor/Torsocks]: Make it explicit that Torsocks won't work correctly in certain scenarios in the README

2017-12-04 Thread Tor Bug Tracker & Wiki
#22068: Make it explicit that Torsocks won't work correctly in certain 
scenarios in
the README
---+--
 Reporter:  Franciscouzo   |  Owner:  dgoulet
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Core Tor/Torsocks  |Version:
 Severity:  Normal | Resolution:
 Keywords:  easy, doc  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 >for any reason, there is no way for torsocks to provide the Tor anonymity
 guarantee to your application, torsocks will force the application to quit
 and stop everything.

 But torsocks does not do this. If there is no way to guarantee the traffic
 is torified, torsocks silently lets the traffic through (e.g. raw assembly
 being used to call syscalls).

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

Re: [tor-bugs] #24037 [Core Tor/Torsocks]: Use syscall blacklist rather than whitelist for torsocks

2017-12-04 Thread Tor Bug Tracker & Wiki
#24037: Use syscall blacklist rather than whitelist for torsocks
---+--
 Reporter:  cypherpunks|  Owner:  dgoulet
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/Torsocks  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 A few comments about the patch:

 >`unsigned long a0, a1, a2, a3, a4, a5;`

 While this type is certainly correct for 64-bit Linux on x86 systems, it
 might be better to use something like `ptrdiff_t`, and maybe even use a
 macro to choose the number of arguments dynamically (since `ptrdiff_t
 a[NUM]` would work perfectly as well), since Linux's isn't the only
 syscall ABI out there. I can't help but have the nagging feeling that
 there may be a way to avoid hardcoding the number of arguments at all, and
 instead use a single `va_arg` for everything.

 >`tsocks_libc_syscall(number, a0, a1, a2, a3, a4, a5);`

 This should probably be using a `return`, otherwise the `ret` could be
 used uninitialized.

 >`ret = tsocks_socket(a0, a1, a2);`
 >`break;`

 You could also replacing this (and others like it) with just a `return
 tsocks_socket(a0, a1, a2);`, to get rid of that temporary `ret` entirely
 and make the code a bit more clean.

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

Re: [tor-bugs] #24037 [Core Tor/Torsocks]: Use syscall blacklist rather than whitelist for torsocks

2017-12-04 Thread Tor Bug Tracker & Wiki
#24037: Use syscall blacklist rather than whitelist for torsocks
---+--
 Reporter:  cypherpunks|  Owner:  dgoulet
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/Torsocks  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 The seccomp solution is currently blocked by #14132, which is needed if we
 whitelist `AF_UNIX` for `socket()`.

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

Re: [tor-bugs] #24263 [Applications/Tor Browser]: Tor Browser 7.0.9 doesn't run background scripts from Web Extensions

2017-12-04 Thread Tor Bug Tracker & Wiki
#24263: Tor Browser 7.0.9 doesn't run background scripts from Web Extensions
--+--
 Reporter:  sajolida  |  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 learningcrumb):

 The problem described in 24504 goes away if I bundle the extension as an
 xpi.

 So it's clear it only happens when the extension is a directory of loose
 files rather than an xpi file.

 Therefore, I agree that 24504 is a duplicate of this ticket.

 I guess I could have saved myself some time building that test case if I'd
 looked more carefully at existing tickets... but mostly I'm just glad to
 have a workaround I can use immediately.

 Thanks for spotting the link gk!

 Incidentally, while testing just now I did see some strange behaviour with
 pings from an embedded WebExt only appearing in the Browser Console if the
 console was open when the button was hit, disappearing again when the
 console was closed and reopened, while messages from the outer extension
 itself behaved normally. It may not be important. If I have time I will
 look into it and open a separate ticket if necessary. Just mentioning it
 in case I don't get around to it and someone else feels like
 investigating. This was while using the test extension from 24504 bundled
 as an xpi.

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

Re: [tor-bugs] #24400 [Core Tor/Tor]: Seccomp filter incorrectly tries to act on strings, allowing sandbox bypass

2017-12-04 Thread Tor Bug Tracker & Wiki
#24400: Seccomp filter incorrectly tries to act on strings, allowing sandbox 
bypass
--+
 Reporter:  Sebastian |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Major | Resolution:
 Keywords:  sandbox   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 >It's sure not very clean code, though, and I can believe that there are
 ways around it that we don't know about. How does the brk() bypass work
 here? What are the other bypasses that we should know about?

 I saw a demonstration when I proposed this idea to... I think it was
 TheJH? I'd have to ask again to remember the details.

 >(and android?)

 Android works the same way as vanilla Linux in this respect.

 >In the shorter term, we could remove the logic that tries to list all the
 files and only permit those, and instead permit open, openat, rename, etc
 more generally, if there's a benefit to that.

 While removal would fix some bugs, it still provides (I think) benefit for
 systems with PaX MPROTECT, since that prevents making rx pages writable
 (such as `.text`).

 >We should also figure out what timeframe we can do the "right" solution
 on.

 This is an issue for many projects, so there is effort to remedy this
 (e.g. with an LSM). It might be best for the "right" solution to use that
 when it comes out. Having a separate process or greatly reworking the
 architecture of Tor doesn't seem likely.

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

Re: [tor-bugs] #24497 [Webpages/Website]: Improve documentation for tor relay operators

2017-12-04 Thread Tor Bug Tracker & Wiki
#24497: Improve documentation for tor relay operators
--+
 Reporter:  arthuredelstein   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 cross referencing #24526

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24526 [Core Tor/Tor]: Make it clear that multi-relay operators are expected to set a working ContactInfo and proper MyFamily

2017-12-04 Thread Tor Bug Tracker & Wiki
#24526: Make it clear that multi-relay operators are expected to set a working
ContactInfo and proper MyFamily
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 As per discussion with David on bad-relays@ I'm opening this ticket as he
 requested.

 We want to make it clear to tor relay operators that setting a proper
 ContactInfo (working email address) and MyFamily (fully mutual
 configuration) is strongly encouraged (required?) for relay operators that
 run more than 3 (?) tor instances, relays showing up without such
 configuration likely raise a red flag and might get rejected from the
 network.

 places to update:

 * manual page:
  * ContactInfo
  * MyFamily

 * relay documentation (#24497)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24525 [Internal Services/Tor Sysadmin Team]: Please create LDAP access for sysrqb

2017-12-04 Thread Tor Bug Tracker & Wiki
#24525: Please create LDAP access for sysrqb
-+-
 Reporter:  ewyatt   |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 Please create LDAP access for Matt. This request is per my conversation
 with Geko.

 Name: Matt Finkel
 Initial forwarding email address: matthew.fin...@gmail.com
 PGP key fingerprint: CE17 8262 4600 EE98 764C  6D9C CB8F C772 D1AA 1D30
 Username: sysrqb

 Thank you!
 -BEGIN PGP SIGNATURE-
 Comment: GPGTools - https://gpgtools.org

 iQIzBAEBCgAdFiEENecqn2ZVRfkstmYkugyUAPgPkc4FAlol4SgACgkQugyUAPgP
 kc6urw//YoOGr86UmdOIe/YCRpOmBWoyUJLITTOqSn0sgzBc41QNpRPKuRaMStF4
 lRPMJl5Hcgk+yfjfqfx6ej8iFxQJai1z7lvNdz7BNz/hejdGqUtRO8Xi9FkbXj0/
 huKiXZ4pgN35Wiz72fHruF24LgQivaJKTYJf+lVjrP/4wnXwdvOtDuPwiIWzYJSG
 84XxSyNP9s2qRbpYHhSlIoG86zdpStQneurz6DKj6nI+OFGMNgPBgMoXRH/I/DvN
 2XDDkIzl14li3F0ZB+xwPMmcUMnbsdK+0zYrhuX0Bj3fRMDeyGPnOClPNguWROMO
 ZlGcSuRnG+BTRmjVFLJzGhzu9aHbvUkjzIWhTZ4YvJlW9uanVeU136UsoG/MwS02
 WinUi08H79tobK/HICBdPkATpRF1l3iG7AjmyYRLZ6+nQahv7gYfkftdgXIcHg7l
 lAgjThARZUbkoK8RG1KDRpeYMj/O30Y/Y8amSNVKWWF8bMOFO4ASDUE6IZ3uuIqq
 LCkwguTCqGu/ReeujzJodX7qk57UDA1eOQK6t7vNRdGyZtDrqXPv8Xj0AVaqRY74
 XCsknmf7ZaPHeSSveefP19eIuGOcWsewX83A+pPPUssvOMIbEjsOrS/zIuutKEeA
 TC6uo5tmi6VLvygLSsE0sogHq/wwbuoB9GggzOyOzPzTCSCSKxo=
 =yihC
 -END PGP SIGNATURE-
 }}}

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

Re: [tor-bugs] #24524 [Internal Services/Tor Sysadmin Team]: Please create LDAP access for Richard

2017-12-04 Thread Tor Bug Tracker & Wiki
#24524: Please create LDAP access for Richard
-+-
 Reporter:  ewyatt   |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by ewyatt):

 Replying to [ticket:24524 ewyatt]:

 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 Name: Richard Pospesel
 Initial forwarding email address: pospes...@riseup.net
 PGP key fingerprint: BE7C 914C C922 CED9 D93D  23B7 DE47 3603 63F3 4B2C
 Username: richard

 Thank you!
 -BEGIN PGP SIGNATURE-
 Comment: GPGTools - https://gpgtools.org

 iQIzBAEBCgAdFiEENecqn2ZVRfkstmYkugyUAPgPkc4FAlol394ACgkQugyUAPgP
 kc4y+g//UQA2LyKq9ilh8zwFrI0AZfINf1f3AH0kIkNXsl8M3wD8qQEPgxk9sAYV
 Y3gf9ILE3gqXIcWR0wnH/PMujEQcxIWTCLbEIBxGVymUxjAiaZjMflWhoM9rPISw
 fXiplvHhRsjdM/N1nWADSL4AtzabpPu90ix/UJKho4EEuAVcj0pzlAT2NFVal9NS
 +wP62jCnIgpNCCdUFC0nkh6VWx/9AkNu9NCyxzeTOkACw5L7/WFhHtrDVid+AHL4
 2HX/QvF0AOT0198U0MQfJeAh6vxtKckSat0gHkfIVzpDryhVn4Of0vXz7ggivWuq
 W9LEZaR1EPEbXIxHYn5R7r1c+Ft56MiebIyiF7e24yARCEaYDAMH3ddVyY+t3GVr
 i70dJRsOHvbrH1+6fo9XCFX8h/JCdwuYrQfIVrPEehsdOeuRM4Ms/tRG87jzbSvj
 r37W1ElGp/pVyFCH1PdfkGUT9fiGIR3WKZbXYW6T12oc07Sh8m1SPcnn2sczrCkf
 Sq1rf1PzczmeOe+88Jf7+IMwyPRDlVmynXJ4IhhXiG2+p6MFHhJ8G8oDieyqDWE1
 dTF82/aB3DGx4tIlof2VrXJWUzNzD3C6tQfemmqZ/mAidVP2F6Yh30Gfbp9E8Wj8
 AJ9+jsB9x/OCaRyEc69a83mlCmNAoVm03ka+ttXYm1JWajlbsgI=
 =OxRI
 -END PGP SIGNATURE-
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24524 [Internal Services/Tor Sysadmin Team]: Please create LDAP access for Richard

2017-12-04 Thread Tor Bug Tracker & Wiki
#24524: Please create LDAP access for Richard
-+-
 Reporter:  ewyatt   |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512


 Please create LDAP access for Richard (rich...@torproject.org). This
 request is per my conversation with Geko.

 Thank you!

 -BEGIN PGP SIGNATURE-
 Comment: GPGTools - https://gpgtools.org

 iQIzBAEBCgAdFiEENecqn2ZVRfkstmYkugyUAPgPkc4FAlol3nEACgkQugyUAPgP
 kc7H8RAAgTmo1xG/nTwC9vV4N4/yMrDao1W+lq6s/6TytVF3GF9X1phZmGmDVmE1
 UfhK7j5D/rG5E/+NfT8tQV6whIVR7uEM0LYGSax/sDcXbBVepLKhceekvd/ChMKZ
 sTIIWem2LsK9pqL0hsP0oVFXxsESlL1iKdfkl6CvRlju9eNV7VteVnGdPJ99Toaf
 gzE0ZfTbtADJnKX1/C5UnRfC57sNoPSFfa1DDKcKlyxfBZtle9wTdZkg5VWo9Otc
 IvT2dOEBKCdZXfnrW3XW+oMWXuORibgE8Rf2WXbibK9bbb/E4O9at1lqY9DTm5/t
 U3ckqC4ukOYLrVAF2+/wvkzjw/ciDDoKhnJQp3Y3rdkMVHhlYcbCuw1/gpK7l4Mf
 5KOcQtojSDq81fJqvHUzBoW/vM+N2Jh4C5v2aRlJNnw6u6hMoqzIeI3rOQ+wMyb0
 NfAPmGGMsLTsdqMcLM4RZeXrszPgw5Q5DTFrr8qhdA7MPTNhR0RpMZ72oS/1h3gO
 WaTz1iGeX1jLWSi5k4qpDGXCCE620r08NwsAMy5zVc8DtsjuwR+Mz1YvnX7Mvik/
 UjJFrSgMqcWvU35LdZ+qjGJJSH8hloIBUp4+x9NOnUBOnkBbNV1h9G+RMlf3LuRt
 /9H20N9hnBUY4BhG8wek2EY4uHUibPzCvQTUBpkfcCsOyjbAkI4=
 =Uvb8
 -END PGP SIGNATURE-
 }}}

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

Re: [tor-bugs] #24500 [Core Tor/Tor]: Confusing log message "Can't get entropy from getrandom()"

2017-12-04 Thread Tor Bug Tracker & Wiki
#24500: Confusing log message "Can't get entropy from getrandom()"
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by ffmancera):

 * status:  new => needs_review


Comment:

 Done! I hope everything is fine!

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

Re: [tor-bugs] #24500 [Core Tor/Tor]: Confusing log message "Can't get entropy from getrandom()"

2017-12-04 Thread Tor Bug Tracker & Wiki
#24500: Confusing log message "Can't get entropy from getrandom()"
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by ffmancera):

 * Attachment "0001-Make-errno-error-log-more-useful-for-getrandom.patch"
 added.


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

Re: [tor-bugs] #24523 [Internal Services/Tor Sysadmin Team]: Please update my OpenPGP key in LDAP/db

2017-12-04 Thread Tor Bug Tracker & Wiki
#24523: Please update my OpenPGP key in LDAP/db
-+
 Reporter:  isis |  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


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

Re: [tor-bugs] #24523 [Internal Services/Tor Sysadmin Team]: Please update my OpenPGP key in LDAP/db

2017-12-04 Thread Tor Bug Tracker & Wiki
#24523: Please update my OpenPGP key in LDAP/db
-+-
 Reporter:  isis |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Description changed by isis:

Old description:

> As per usual, I rotated my OpenPGP subkeys in December, so they should be
> updated.
>
> {{{
>   Key fingerprint = 0A6A 58A1 4B59 46AB DE18  E207 A3AD B67A 2CDB
> 8B35
> uid   [ultimate] Isis 
> uid   [ultimate] Isis! 
> uid   [ultimate] Isis! 
> uid   [ultimate] Isis 
> sub   4096R/50C98D87B401100F 2011-09-09 [expired: 2013-09-07]
>   Key fingerprint = A6DA 4A68 76AE 9355 EAFD  43F6 50C9 8D87 B401
> 100F
> sub   4096R/01B426B20AE4EF5D 2011-12-24 [revoked: 2012-01-30]
>   Key fingerprint = 5B8B 8A93 26F3 44D8 10FC  769B 01B4 26B2 0AE4
> EF5D
> sub   4096R/36DB24500B30EE69 2013-04-24 [expired: 2014-09-07]
>   Key fingerprint = 9A89 F0C7 7C5E 82B1 4537  C8EA 36DB 2450 0B30
> EE69
> sub   4096R/D6FE9B624F740495 2013-09-08 [expired: 2014-09-07]
>   Key fingerprint = BBA8 3EC9 10C5 DA6F 7693  0ED6 D6FE 9B62 4F74
> 0495
> sub   4096R/5C17776E27F7E84D 2013-09-24 [expired: 2014-09-07]
>   Key fingerprint = FC63 AA5C D193 869C 3237  145A 5C17 776E 27F7
> E84D
> sub   4096R/520C96A5DF5BAC06 2014-09-08 [expired: 2015-09-11]
>   Key fingerprint = 76D6 ADC8 6CDB 4B8B 8D31  9674 520C 96A5 DF5B
> AC06
> sub   4096R/D89F40E1C319151F 2014-09-08 [expired: 2015-09-11]
>   Key fingerprint = 2939 BD53 8D44 7935 300A  089B D89F 40E1 C319
> 151F
> sub   4096R/18C16EC5F9F1D673 2014-09-08 [expired: 2015-09-11]
>   Key fingerprint = C2F0 33A6 1D00 1B55 2185  5A9E 18C1 6EC5 F9F1
> D673
> sub   4096R/13E41AB155E052D1 2015-09-08 [expired: 2016-09-11]
>   Key fingerprint = 9DB3 FFBD E878 7845 CC31  F312 13E4 1AB1 55E0
> 52D1
> sub   4096R/3C9937F994616C82 2015-09-08 [expired: 2016-09-11]
>   Key fingerprint = BF8D 1B8E DEBD 985D B29A  8F94 3C99 37F9 9461
> 6C82
> sub   4096R/07DC962E86BA94A0 2016-09-08 [expired: 2017-09-11]
>   Key fingerprint = 948B 7F0E 648C 0B99 8BA2  05FF 07DC 962E 86BA
> 94A0
> sub   4096R/C8E8B1AA4CF3844E 2016-09-08 [expired: 2017-09-11]
>   Key fingerprint = 072F 943B 13D4 508B 49CE  88D4 C8E8 B1AA 4CF3
> 844E
> sub   4096R/0C4A8FCF67EF255C 2017-09-08 [expires: 2018-09-11]
>   Key fingerprint = 8913 A9BF 6739 E57F 3421  C070 0C4A 8FCF 67EF
> 255C
> sub   4096R/B8938BC5E86C046F 2017-09-08 [expires: 2018-09-11]
>   Key fingerprint = DE3D 7834 468D E2B8 F204  6B68 B893 8BC5 E86C
> 046F
> }}}

New description:

 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512



 As per usual, I rotated my OpenPGP subkeys in December, so they should be
 updated.

 {{{
 ∃!isisⒶwintermute:~ ∴ gpg2 --list-keys --fingerprint --fingerprint
 a3adb67a2cdb8b35
 pub   4096R/A3ADB67A2CDB8B35 2011-09-09 [expires: 2018-09-11]
   Key fingerprint = 0A6A 58A1 4B59 46AB DE18  E207 A3AD B67A 2CDB 8B35
 uid   [ultimate] Isis 
 uid   [ultimate] Isis! 
 uid   [ultimate] Isis! 
 uid   [ultimate] Isis 
 sub   4096R/50C98D87B401100F 2011-09-09 [expired: 2013-09-07]
   Key fingerprint = A6DA 4A68 76AE 9355 EAFD  43F6 50C9 8D87 B401 100F
 sub   4096R/01B426B20AE4EF5D 2011-12-24 [revoked: 2012-01-30]
   Key fingerprint = 5B8B 8A93 26F3 44D8 10FC  769B 01B4 26B2 0AE4 EF5D
 sub   4096R/36DB24500B30EE69 2013-04-24 [expired: 2014-09-07]
   Key fingerprint = 9A89 F0C7 7C5E 82B1 4537  C8EA 36DB 2450 0B30 EE69
 sub   4096R/D6FE9B624F740495 2013-09-08 [expired: 2014-09-07]
   Key fingerprint = BBA8 3EC9 10C5 DA6F 7693  0ED6 D6FE 9B62 4F74 0495
 sub   4096R/5C17776E27F7E84D 2013-09-24 [expired: 2014-09-07]
   Key fingerprint = FC63 AA5C D193 869C 3237  145A 5C17 776E 27F7 E84D
 sub   4096R/520C96A5DF5BAC06 2014-09-08 [expired: 2015-09-11]
   Key fingerprint = 76D6 ADC8 6CDB 4B8B 8D31  9674 520C 96A5 DF5B AC06
 sub   4096R/D89F40E1C319151F 2014-09-08 [expired: 2015-09-11]
   Key fingerprint = 2939 BD53 8D44 7935 300A  089B D89F 40E1 C319 151F
 sub   4096R/18C16EC5F9F1D673 2014-09-08 [expired: 2015-09-11]
   Key fingerprint = C2F0 33A6 1D00 1B55 2185  5A9E 18C1 6EC5 F9F1 D673
 sub   4096R/13E41AB155E052D1 2015-09-08 [expired: 2016-09-11]
 

Re: [tor-bugs] #24523 [Internal Services/Tor Sysadmin Team]: Please update my OpenPGP key in LDAP/db

2017-12-04 Thread Tor Bug Tracker & Wiki
#24523: Please update my OpenPGP key in LDAP/db
-+-
 Reporter:  isis |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by weasel):

 Please sign key update tickets.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24523 [Internal Services/Tor Sysadmin Team]: Please update my OpenPGP key in LDAP/db

2017-12-04 Thread Tor Bug Tracker & Wiki
#24523: Please update my OpenPGP key in LDAP/db
-+-
 Reporter:  isis |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 As per usual, I rotated my OpenPGP subkeys in December, so they should be
 updated.

 {{{
   Key fingerprint = 0A6A 58A1 4B59 46AB DE18  E207 A3AD B67A 2CDB 8B35
 uid   [ultimate] Isis 
 uid   [ultimate] Isis! 
 uid   [ultimate] Isis! 
 uid   [ultimate] Isis 
 sub   4096R/50C98D87B401100F 2011-09-09 [expired: 2013-09-07]
   Key fingerprint = A6DA 4A68 76AE 9355 EAFD  43F6 50C9 8D87 B401 100F
 sub   4096R/01B426B20AE4EF5D 2011-12-24 [revoked: 2012-01-30]
   Key fingerprint = 5B8B 8A93 26F3 44D8 10FC  769B 01B4 26B2 0AE4 EF5D
 sub   4096R/36DB24500B30EE69 2013-04-24 [expired: 2014-09-07]
   Key fingerprint = 9A89 F0C7 7C5E 82B1 4537  C8EA 36DB 2450 0B30 EE69
 sub   4096R/D6FE9B624F740495 2013-09-08 [expired: 2014-09-07]
   Key fingerprint = BBA8 3EC9 10C5 DA6F 7693  0ED6 D6FE 9B62 4F74 0495
 sub   4096R/5C17776E27F7E84D 2013-09-24 [expired: 2014-09-07]
   Key fingerprint = FC63 AA5C D193 869C 3237  145A 5C17 776E 27F7 E84D
 sub   4096R/520C96A5DF5BAC06 2014-09-08 [expired: 2015-09-11]
   Key fingerprint = 76D6 ADC8 6CDB 4B8B 8D31  9674 520C 96A5 DF5B AC06
 sub   4096R/D89F40E1C319151F 2014-09-08 [expired: 2015-09-11]
   Key fingerprint = 2939 BD53 8D44 7935 300A  089B D89F 40E1 C319 151F
 sub   4096R/18C16EC5F9F1D673 2014-09-08 [expired: 2015-09-11]
   Key fingerprint = C2F0 33A6 1D00 1B55 2185  5A9E 18C1 6EC5 F9F1 D673
 sub   4096R/13E41AB155E052D1 2015-09-08 [expired: 2016-09-11]
   Key fingerprint = 9DB3 FFBD E878 7845 CC31  F312 13E4 1AB1 55E0 52D1
 sub   4096R/3C9937F994616C82 2015-09-08 [expired: 2016-09-11]
   Key fingerprint = BF8D 1B8E DEBD 985D B29A  8F94 3C99 37F9 9461 6C82
 sub   4096R/07DC962E86BA94A0 2016-09-08 [expired: 2017-09-11]
   Key fingerprint = 948B 7F0E 648C 0B99 8BA2  05FF 07DC 962E 86BA 94A0
 sub   4096R/C8E8B1AA4CF3844E 2016-09-08 [expired: 2017-09-11]
   Key fingerprint = 072F 943B 13D4 508B 49CE  88D4 C8E8 B1AA 4CF3 844E
 sub   4096R/0C4A8FCF67EF255C 2017-09-08 [expires: 2018-09-11]
   Key fingerprint = 8913 A9BF 6739 E57F 3421  C070 0C4A 8FCF 67EF 255C
 sub   4096R/B8938BC5E86C046F 2017-09-08 [expires: 2018-09-11]
   Key fingerprint = DE3D 7834 468D E2B8 F204  6B68 B893 8BC5 E86C 046F
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24522 [Internal Services/Tor Sysadmin Team]: Please create email alias/UID and LDAP access for Igor

2017-12-04 Thread Tor Bug Tracker & Wiki
#24522: Please create email alias/UID and LDAP access for Igor
-+-
 Reporter:  ewyatt   |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512


 Please create email/uid and LDAP access for Igor (new Android mobile
 browser dev):

 First name: Igor
 Last name: Oliveira
 Desired alias/uid: igt0
 Forwarding email: igor.olive...@posteo.net
 PGP key: A78C BB96 4B8C 351A 8AB2  0A69 609E 5D4A EDCA 83FF

 Thank you!

 -BEGIN PGP SIGNATURE-
 Comment: GPGTools - https://gpgtools.org

 iQIzBAEBCgAdFiEENecqn2ZVRfkstmYkugyUAPgPkc4FAlolzPMACgkQugyUAPgP
 kc7RxhAAgCpz1SKgl6arfGL1a2Sda7Er/UXq+Ni/uykOTGpassB6FMBonHvZSfCc
 XYiHweJZTr1qWPZ5XYedh9df6X8AbNCvSszfO0WSuhA0yRK0bnqYHhRzmApY+sLx
 JIgLT3QhBdZj7QSr67P2kb2nrZaJloRzsYZwWSxKf2CRJLJmEKjbOEQLo97rHqxB
 7wmkf04vdawaKj2R5qb33E4OB9meyz5ahyvZwfLd7X6sKMkPTn2qFvI3c9Ti9xsw
 1//lfBqk/JeQ7ePwrEG80US4Iz0zs72Pe+4CE/9OE/uiofif3LwR/cR6NToFsGg9
 6QAycQ8EVwZ8C3EG1QEmOydUMHSwPEFsIP1PYybJPZIOlTZPUTFyjb46jgmg7fMM
 VEqQpaSJLSYspmIFlX7tnyTrHevIE4gUje/QkQRmt7DBTyeUsY3O3kw9REBovrkc
 KvsHa3nqZyYjCRZ1waL5DKODuDFLai0L962IqjAzbaEn7mr59D+riszSRYpdFYNi
 wcPWcxnhDOldMdHkk8KNnvwnwP2eMcfpisJ5CRbCo712+xvvcAF7D6CpPa1y1c7F
 B4jWI5T8UR4c8joCg2iDAWqucFn3kBOmwQnB1DXpi0hesEowHNRoSNbD/LXP1lDu
 6i/2aidah7obv4AFC06/frO7MW55BGBydO+zdUA0iu0sKpOgVZU=
 =aAhk
 -END PGP SIGNATURE-
 }}}

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

Re: [tor-bugs] #23709 [Core Tor/Tor]: channel: `outgoing_queue` and `incoming_queue` are always empty

2017-12-04 Thread Tor Bug Tracker & Wiki
#23709: channel: `outgoing_queue` and `incoming_queue` are always empty
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  needs_revision
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:  #23993| Points:
 Reviewer:|Sponsor:  SponsorV
--+
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 This was less frightening than I had feared.

 I left some comments and question on oniongit.

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

Re: [tor-bugs] #24509 [Core Tor/Tor]: circuit_can_use_tap() should only allow TAP for v2 onion services

2017-12-04 Thread Tor Bug Tracker & Wiki
#24509: circuit_can_use_tap() should only allow TAP for v2 onion services
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, security-low,   |  Actual Points:
  easy, intro|
Parent ID:   | Points:  0.5
 Reviewer:  dgoulet  |Sponsor:
-+-

Comment (by teor):

 Ah, undocumented state machines, aren't they fun?

 I'd suggest you look for the code that changes circuit purposes to the
 ones we're looking for, Hopefully these functions come on v2 and v3
 varieties, or they otherwise have some context that lets us know which
 version we're using.

 When you find those call sites, if there is no existing struct member that
 gives us the version information, add a 1-bit flag to the circuit struct
 that tells us whether it's v2 or 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] #24509 [Core Tor/Tor]: circuit_can_use_tap() should only allow TAP for v2 onion services

2017-12-04 Thread Tor Bug Tracker & Wiki
#24509: circuit_can_use_tap() should only allow TAP for v2 onion services
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, security-low,   |  Actual Points:
  easy, intro|
Parent ID:   | Points:  0.5
 Reviewer:  dgoulet  |Sponsor:
-+-

Comment (by irl):

 There's something I'm missing here perhaps. Every time
 `circuit_can_use_tap` is called, there's never a `rend_data` or `hs_ident`
 defined (pointers are both nil). Maybe this has not been added yet, or
 maybe it's been removed before, when the function is called. This is true
 even when I'm requesting a v2 onion service and the check for purpose has
 returned correctly.

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

Re: [tor-bugs] #20699 [Core Tor/Tor]: prop224: Add control port events and commands

2017-12-04 Thread Tor Bug Tracker & Wiki
#20699: prop224: Add control port events and commands
-+-
 Reporter:  dgoulet  |  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-hs, needs-proposal,  |  Actual Points:
  prop224-extra, tor-control, prop284, review-   |
  group-26   |
Parent ID:   | Points:  6
 Reviewer:  nickm|Sponsor:
 |  SponsorR-must
-+-
Changes (by nickm):

 * status:  needs_review => 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] #20699 [Core Tor/Tor]: prop224: Add control port events and commands

2017-12-04 Thread Tor Bug Tracker & Wiki
#20699: prop224: Add control port events and commands
-+-
 Reporter:  dgoulet  |  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-hs, needs-proposal,  |  Actual Points:
  prop224-extra, tor-control, prop284, review-   |
  group-26   |
Parent ID:   | Points:  6
 Reviewer:  nickm|Sponsor:
 |  SponsorR-must
-+-

Comment (by nickm):

 Nice!  This looks pretty solid and straightforward.  I've left some
 comments on the oniongit ticket.

 Additionally:

 It needs a changes file.

 Do all the stem tests still pass?

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

Re: [tor-bugs] #24519 [Webpages/Website]: Make section headings in the FAQ linkable

2017-12-04 Thread Tor Bug Tracker & Wiki
#24519: Make section headings in the FAQ linkable
--+--
 Reporter:  kat5  |  Owner:  kat5
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 Notice that we, in addition to these new anchors and links, already have
 anchors for each section farther down on the page. But I think we aren't
 exposing these anchors in any way that users might run across them (other
 than by looking at the source).

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

Re: [tor-bugs] #24518 [Core Tor/Tor]: Remove the --quiet from our cargo build invocation

2017-12-04 Thread Tor Bug Tracker & Wiki
#24518: Remove the --quiet from our cargo build invocation
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  rust cargo|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 merged to master after weasel-approval

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24521 [Applications/Tor Browser]: Investigate Making Canvas Unfingerprintable

2017-12-04 Thread Tor Bug Tracker & Wiki
#24521: Investigate Making Canvas Unfingerprintable
--+--
 Reporter:  tom   |  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:|
--+--
 If we can make  unfingerprintable, we could remove the permission
 prompt. I wanted to capture the discussion on this here.

 From long ago, what needed to be fixed to make  unfingerprintable:

  # software rendering
  # system colors were standardized
  # and the browser shipped a fixed collection of fonts

 I believe we have patches for 2 and 3.

 1 is doable (see below).

 But the font stuff is still tricky. See #16672 which is an example of the
 same OS (but different versions of it) rendering the same font
 differently.

 And #17999 which is the default GUI font allowing distinguishing the
 version of the gUI. (That's not specific *to* canvas but it does probably
 *affect* canvas.)

 {{{
 13:48:11 T mstange: After talking with the Tor folks, there were
 three main areas for canvas fingerprinting: fonts (we can partly that),
 system colors (we can handle that), and software rendering.
 13:48:14 T But the font stuff is trickier than I thought at first.
 While we can whitelist fonts, it turns out the same font is sometimes
 rendered differently in different versions of the same OS, and that
 different versions of the same OS can be fingerprinted by the default font
 chosen.
 13:48:17 T We suspect there are other vectors inside canvas, but
 switching to software rendering would be a big help. Is that easy to do?
 Tor would consider shipping that in an Alpha.
 13:49:45 M tjr: interesting!
 13:49:59 M switching to Skia software is as easy as setting
 gfx.canvas.azure.backends to "Skia" and gfx.canvas.azure.accelerated to
 false
 13:50:51 M for system-setting-dependent font rendering, maybe we
 can add a way of rendering fonts into canvas that does not respect any
 system settings
 13:51:16 M lsalzman: how hard would that be? maybe we could ship
 some ugly freetype rasterization on all platforms?
 13:51:25 L how hard would what be?
 13:51:35 M "add a way of rendering fonts into canvas that does
 not respect any system settings"
 13:51:56 L depends what that means
 13:52:04 L if you mean using freetype on all platforms, that
 would be insane right now
 13:52:09 M ok
 13:52:10 L we're not architected for that
 13:52:29 L we have a lot of assumptions built in like, if you're
 on windows, you're using dwrite, etc.
 13:53:13 M I'm looking for a way to render fonts that doesn't
 leak any more bits of entropy than the OS you're on
 13:53:14 L i mean, you can certainly make dwrite rendering ugly
 and standardized to some degree
 13:53:35 L but forcing things like gamma, contrast, AA, hinting,
 to known values
 13:53:46 L that's somewhat what Chrome does already ;)
 13:53:57 M that sounds interesting
 13:54:22 L the gfx.font_rendering.cleartype_params already allow
 this, i think
 13:54:36 L there may be some cases where they're not properly
 respected everywhere, though
 13:54:58 M thanks
 13:55:23 M tjr: ^ this seems like a good place to start
 investigating
 13:56:40 L linux settings will be hell because of fontconfig
 13:56:47 L no idea what we're doing as far as prefs on mac
 13:57:13 ⇐ pcwalton quit (pcwal...@moz-vhk0rb.hfc.comcastbusiness.net)
 Client exited
 13:57:30 M I don't think there are any prefs on mac, other than
 the 1 bit "allow font smoothing" pref
 13:58:01 M and now that we know that we can override it with
 CGContextSetAllowsFontSmoothing, this one shouldn't be a problem either :)
 13:59:11 T When you say fontconfig, is that taking into account that
 we are planning to bundle and whitelist what fonts are available to the
 browser (when privacy.resistFingerprinting is enabled)?
 }}}


 One idea would be to enable system rendering, do some due diligence on if
 _we_ can detect anything, and if not, put it in the Alpha and allow bug
 bounty folks to poke at 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] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

2017-12-04 Thread Tor Bug Tracker & Wiki
#23136: moat integration (fetch bridges for the user)
---+---
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_information
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201711   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+---

Comment (by antonela):

 Replying to [comment:15 mcs]:
 > Replying to [comment:13 antonela]:
 > > Hi all!
 > >
 > > I think is pretty clear when you have 3 options.
 > > ...
 >
 > Thank you for creating a new mockup.


 No problem, we're here to help :)


 >
 > When viewed at a high level, it is definitely clearer to have 3 radio
 buttons. But for the following reason that I mentioned in comment:10,
 Kathy and I do not think a radio button is the correct UI element to use
 here:
 > * What do we do after a bridge is received via moat? The obvious answer
 is that the bridge configuration line will show up in the "Provide a
 bridge I know" text area. But that means that having a radio button for
 the moat interaction does not make a lot of sense; it is a short-lived
 modal interaction (stop what you are doing, interact with BridgeDB, done)
 rather than a state that needs to be maintained.
 >


 Yes, I understand. I think that is what we do after the bridge is received
 is where we are missing. If we replace the content with the bridge phrase
 seems more clear that you are going to connect to this bridge. If the user
 wants, again, another bridge, he can click on [New Bridge]. After that,
 the captcha block will appears again.

 I that way we are not compromising the other options if they are the
 needed ones.

 Take a look at this mockup
 https://trac.torproject.org/projects/tor/attachment/ticket/23136/23136-1.png


 > Also, *not* using an overlay approach will require either a really large
 window or a small CAPTCHA image (and neither of these is ideal).
 Got it. We can still have the overlay if we keep the 3 options.

 Definitely is something we could test with users :)

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

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

2017-12-04 Thread Tor Bug Tracker & Wiki
#23136: moat integration (fetch bridges for the user)
---+---
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_information
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201711   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+---
Changes (by antonela):

 * Attachment "23136-1.png" 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] #24519 [Webpages/Website]: Make section headings in the FAQ linkable

2017-12-04 Thread Tor Bug Tracker & Wiki
#24519: Make section headings in the FAQ linkable
--+--
 Reporter:  kat5  |  Owner:  kat5
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by kat5):

 * status:  assigned => needs_review


Comment:

 Fixed: https://gitweb.torproject.org/user/kat/webwml.git/commit/?h=faq-
 section-anchors

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

Re: [tor-bugs] #24337 [Core Tor/Tor]: Every _free() function should be a macro that sets the corresponding pointer to NULL.

2017-12-04 Thread Tor Bug Tracker & Wiki
#24337: Every _free() function should be a macro that sets the corresponding
pointer to NULL.
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-26  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor8-can
-+
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 I've made a new branch based on the old one.  It removes the uppercasing
 commits.  It also adds a new pair of commits that change tor_free() and
 object_free() so that they can withstand usage like `tor_free(ptr++);`.

 The branch is now `macro_free_v2`.  The only new commits are
 d6549f0d1d68e09d260968af95016218ae16072d and
 534e6094fc5336785105deeaacd487e9e79ebbab (and the revised changes file).

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

Re: [tor-bugs] #24519 [Webpages/Website]: Make section headings in the FAQ linkable

2017-12-04 Thread Tor Bug Tracker & Wiki
#24519: Make section headings in the FAQ linkable
--+--
 Reporter:  kat5  |  Owner:  kat5
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by kat5):

 To be clear, the idea is to have links to the headings in the question
 list.

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

Re: [tor-bugs] #24503 [Core Tor/RPM packaging]: Rust build fails

2017-12-04 Thread Tor Bug Tracker & Wiki
#24503: Rust build fails
+
 Reporter:  tortux  |  Owner:  hiviah
 Type:  defect  | Status:  needs_information
 Priority:  Medium  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/RPM packaging  |Version:  Tor: 0.3.1.9
 Severity:  Normal  | Resolution:
 Keywords:  rust packaging  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by tortux):

 Download the tar.gz file + signature and compile it, like it is shown in
 the logs.

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

Re: [tor-bugs] #24502 [Core Tor/Tor]: scheduler_release_channel: Non-fatal assertion

2017-12-04 Thread Tor Bug Tracker & Wiki
#24502: scheduler_release_channel: Non-fatal assertion
---+
 Reporter:  toralf |  Owner:  dgoulet
 Type:  defect | Status:  needs_review
 Priority:  Low|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.3.2.6-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-sched, regression  |  Actual Points:
Parent ID: | Points:
 Reviewer:  pastly |Sponsor:
---+

Comment (by toralf):

 Another example from today:
 {{{
 Dec 04 21:03:05.000 [warn] tor_bug_occurred_(): Bug:
 src/or/scheduler.c:631: scheduler_release_channel: Non-fatal assertion
 !(smartlist_pos(channels_pending, chan) =
 = -1) failed. (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
 Dec 04 21:03:05.000 [warn] Bug: Non-fatal assertion
 !(smartlist_pos(channels_pending, chan) == -1) failed in
 scheduler_release_channel at src/or/scheduler.c:631. Sta
 ck trace: (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
 Dec 04 21:03:05.000 [warn] Bug: /usr/bin/tor(log_backtrace+0x53)
 [0x55ad3ea64e73] (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
 Dec 04 21:03:05.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xc5)
 [0x55ad3ea81b75] (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
 Dec 04 21:03:05.000 [warn] Bug:
 /usr/bin/tor(scheduler_release_channel+0x19a) [0x55ad3e99312a] (on Tor
 0.3.2.6-alpha 87012d076ef58bb9)
 Dec 04 21:03:05.000 [warn] Bug: /usr/bin/tor(+0xc7408)
 [0x55ad3e99f408] (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
 Dec 04 21:03:05.000 [warn] Bug:
 /usr/bin/tor(connection_or_about_to_close+0x4d) [0x55ad3e9f43dd] (on Tor
 0.3.2.6-alpha 87012d076ef58bb9)
 Dec 04 21:03:05.000 [warn] Bug: /usr/bin/tor(+0x4ff8c)
 [0x55ad3e927f8c] (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
 Dec 04 21:03:05.000 [warn] Bug: /usr/bin/tor(+0x50788)
 [0x55ad3e928788] (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
 Dec 04 21:03:05.000 [warn] Bug: /usr/lib64/libevent-2.1.so.6(+0x2373a)
 [0x7ff15d09073a] (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
 Dec 04 21:03:05.000 [warn] Bug:
 /usr/lib64/libevent-2.1.so.6(event_base_loop+0x57f) [0x7ff15d09168f] (on
 Tor 0.3.2.6-alpha 87012d076ef58bb9)
 Dec 04 21:03:05.000 [warn] Bug: /usr/bin/tor(do_main_loop+0x24d)
 [0x55ad3e929f3d] (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
 Dec 04 21:03:05.000 [warn] Bug: /usr/bin/tor(tor_main+0x1c2d)
 [0x55ad3e92d9bd] (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
 Dec 04 21:03:05.000 [warn] Bug: /usr/bin/tor(main+0x28)
 [0x55ad3e9252b8] (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
 Dec 04 21:03:05.000 [warn] Bug:
 /lib64/libc.so.6(__libc_start_main+0xfd) [0x7ff15bc055ad] (on Tor
 0.3.2.6-al
 pha 87012d076ef58bb9)
 Dec 04 21:03:05.000 [warn] Bug: /usr/bin/tor(_start+0x2a)
 [0x55ad3e92530a] (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
 Dec 04 21:03:05.000 [warn] scheduler_bug_occurred(): Bug: Channel 1204645
 in state channel error and scheduler state 3. Num cells on cmux: 3.
 Connection outbuf len: 0. Num pending channels: 98. Channel in pending
 list: no. (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
 Dec 04 21:03:05.000 [warn] Scheduler asked to release channel 1204645 but
 it wasn't in channels_pending
 }}}

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

Re: [tor-bugs] #24508 [Core Tor/Nyx]: Nyx does not have access to its cache folder unless it is run as root

2017-12-04 Thread Tor Bug Tracker & Wiki
#24508: Nyx does not have access to its cache folder unless it is run as root
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  atagar
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Nyx   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by atagar):

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


Comment:

 Oh. Actually, Nyx already does the right thing. If it can't make a cache
 directory it simply disables it. Reducing the logged message to INFO level
 so it's not visible by default...

 https://gitweb.torproject.org/nyx.git/commit/?id=1e0f9a1

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

Re: [tor-bugs] #24502 [Core Tor/Tor]: scheduler_release_channel: Non-fatal assertion

2017-12-04 Thread Tor Bug Tracker & Wiki
#24502: scheduler_release_channel: Non-fatal assertion
---+
 Reporter:  toralf |  Owner:  dgoulet
 Type:  defect | Status:  needs_review
 Priority:  Low|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.3.2.6-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-sched, regression  |  Actual Points:
Parent ID: | Points:
 Reviewer:  pastly |Sponsor:
---+
Changes (by dgoulet):

 * status:  accepted => needs_review
 * reviewer:   => pastly


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

Re: [tor-bugs] #24502 [Core Tor/Tor]: scheduler_release_channel: Non-fatal assertion

2017-12-04 Thread Tor Bug Tracker & Wiki
#24502: scheduler_release_channel: Non-fatal assertion
---+
 Reporter:  toralf |  Owner:  dgoulet
 Type:  defect | Status:  accepted
 Priority:  Low|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.3.2.6-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-sched, regression  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dgoulet):

 * status:  needs_review => accepted
 * owner:  (none) => dgoulet


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

Re: [tor-bugs] #24508 [Core Tor/Nyx]: Nyx does not have access to its cache folder unless it is run as root

2017-12-04 Thread Tor Bug Tracker & Wiki
#24508: Nyx does not have access to its cache folder unless it is run as root
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Nyx   |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 Thanks Dbryrtfbcbhgf, great catch. You can sidestep this by having
 'data_directory disabled' or 'data_directory /tmp/cache' in your nyxrc...

 https://nyx.torproject.org/#configuration

 I'll change Nyx so it disables this by default when it lacks a writable
 home directory.

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

Re: [tor-bugs] #24337 [Core Tor/Tor]: Every _free() function should be a macro that sets the corresponding pointer to NULL.

2017-12-04 Thread Tor Bug Tracker & Wiki
#24337: Every _free() function should be a macro that sets the corresponding
pointer to NULL.
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-26  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor8-can
-+
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 After discussion at today's meeting, we're leaning towards having this be
 in lowercase, given various factors, and in the interest of avoiding a
 permanent bikeshed debate.

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

Re: [tor-bugs] #24502 [Core Tor/Tor]: scheduler_release_channel: Non-fatal assertion

2017-12-04 Thread Tor Bug Tracker & Wiki
#24502: scheduler_release_channel: Non-fatal assertion
---+
 Reporter:  toralf |  Owner:  (none)
 Type:  defect | Status:  needs_review
 Priority:  Low|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.3.2.6-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-sched, regression  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dgoulet):

 * keywords:  tor-sched => tor-sched, regression
 * status:  needs_information => needs_review
 * priority:  High => Low


Comment:

 Thanks toralf!

 Bottom line here is that a release on a channel has been done by
 `connection_or_about_to_close()` meaning the channel's connection was
 closed in error state. This seems to be coming from the libevent main
 loop, most likely the `write_event` of the connection.

 I think what happened is that the channel was in pending state in the
 scheduler, it got into the first condition `if
 (socket_can_write(_table, chan)) {` but then because the channel
 wasn't opened, we moved to the next channel.

 This had two consequences. First, the channel scheduler state is kept at
 `PENDING` but it is not put back in the channel pending list. Second,
 because it is still in that state, `scheduler_release_channel()` triggered
 that bug but at least clean it up properly. A `PENDING` state for a
 channel implies that it *has* to be in the pending list.

 The KIST scheduler has 4 conditions and each of them should end with
 setting the channel scheduler state to reflect what has been done with it.

 The condition I outlined above is really the only place I can find where
 we fail to update the state properly. It has been introduced with
 `dcabf801e52` (0.3.2.4-alpha). Fortunately, this is harmless but annoying.

 Branch: `bug24502_032_01`

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

Re: [tor-bugs] #24309 [Applications/Tor Browser]: Activity 4.1: Improve how circuits are displayed to the user

2017-12-04 Thread Tor Bug Tracker & Wiki
#24309: Activity 4.1: Improve how circuits are displayed to the user
--+--
 Reporter:  isabela   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:  antonela  |Sponsor:
--+--

Comment (by arthuredelstein):

 Replying to [comment:4 antonela]:

 > I'd like to suggest moving this windows to a
 [http://design.firefox.com/photon/components/doorhangers.html doorhanger].
 This component is used by Firefox Photon UI on their latest version and
 seems a good move looking forward to March 18 items.

 I wonder where the doorhanger should hang from. Should it be another
 toolbar button, or something inside the URL bar? I think it's important to
 keep the "New Tor Circuit for this Site" button associated with the "Tor
 Circuit for this Site" diagram.

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

Re: [tor-bugs] #24512 [Core Tor/Stem]: Stem directory authority documentation is outdated

2017-12-04 Thread Tor Bug Tracker & Wiki
#24512: Stem directory authority documentation is outdated
---+
 Reporter:  teor   |  Owner:  atagar
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Minor  | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by atagar):

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


Comment:

 Change pushed and should be live on the site in a bit. Thanks for pointing
 these 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] #24512 [Core Tor/Stem]: Stem directory authority documentation is outdated

2017-12-04 Thread Tor Bug Tracker & Wiki
#24512: Stem directory authority documentation is outdated
---+
 Reporter:  teor   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Minor  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 Oh! My bad, was grepping for the whole year. Sorry about that, dropping
 that bit too.

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

Re: [tor-bugs] #24512 [Core Tor/Stem]: Stem directory authority documentation is outdated

2017-12-04 Thread Tor Bug Tracker & Wiki
#24512: Stem directory authority documentation is outdated
---+
 Reporter:  teor   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Minor  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 Thanks Tim, dropped the line number from the link. Not sure I grok the
 part about 2014 though. What do you mean by that?

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

Re: [tor-bugs] #24487 [Core Tor/Tor]: Reverse path selection (choose outer hops first)

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

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


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

Re: [tor-bugs] #24309 [Applications/Tor Browser]: Activity 4.1: Improve how circuits are displayed to the user

2017-12-04 Thread Tor Bug Tracker & Wiki
#24309: Activity 4.1: Improve how circuits are displayed to the user
--+--
 Reporter:  isabela   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:  antonela  |Sponsor:
--+--

Comment (by arthuredelstein):

 Replying to [comment:4 antonela]:

 > Let me know what do you think

 I like all these suggestions -- I think they could be combined into one
 design. I think the (i) symbol in Version A is a nice touch and could even
 be combined the the "Guard" annotation in Version B. We might also
 consider hiding the Guard IP address so that users are less likely to leak
 their Guard information.

 Regarding Version D, I would suggest using a
 [https://en.wikipedia.org/wiki/Tooltip tooltip] so that when the user
 clicks or hovers over (i) symbol, an explanatory message appears.

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

Re: [tor-bugs] #24487 [Core Tor/Tor]: Reverse path selection (choose outer hops first)

2017-12-04 Thread Tor Bug Tracker & Wiki
#24487: Reverse path selection (choose outer hops first)
+--
 Reporter:  mikeperry   |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:  Tor:
|  0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  guard-discovery-prop247-controller  |  Actual Points:
Parent ID:  #9001   | Points:
 Reviewer:  |Sponsor:
|  SponsorV-can
+--
Changes (by mikeperry):

 * keywords:  guard-discovery => guard-discovery-prop247-controller


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

Re: [tor-bugs] #22084 [Applications/Tor Browser]: Neuter NetworkInformation API on Tor Browser Mobile

2017-12-04 Thread Tor Bug Tracker & Wiki
#22084: Neuter NetworkInformation API on Tor Browser Mobile
---+--
 Reporter:  gk |  Owner:  igt0
 Type:  task   | Status:  accepted
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-mobile tbb-fingerprinting  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by mcs):

 * cc: brade, mcs (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] #24520 [Webpages/Blog]: Change menu capitalization on blog

2017-12-04 Thread Tor Bug Tracker & Wiki
#24520: Change menu capitalization on blog
---+--
 Reporter:  steph  |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 Change menu from:

 ABOUT TOR
 DONATE

 to:

 About Tor
 Donate

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

Re: [tor-bugs] #24518 [Core Tor/Tor]: Remove the --quiet from our cargo build invocation

2017-12-04 Thread Tor Bug Tracker & Wiki
#24518: Remove the --quiet from our cargo build invocation
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust cargo|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  assigned => needs_review


Comment:

 Trivial fix as `ticket24518`

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24519 [Webpages/Website]: Make section headings in the FAQ linkable

2017-12-04 Thread Tor Bug Tracker & Wiki
#24519: Make section headings in the FAQ linkable
--+--
 Reporter:  kat5  |  Owner:  kat5
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Create anchors for the FAQ sections so that other pages can link to
 particular sections.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24518 [Core Tor/Tor]: Remove the --quiet from our cargo build invocation

2017-12-04 Thread Tor Bug Tracker & Wiki
#24518: Remove the --quiet from our cargo build invocation
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  rust cargo
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 It seems to suppress some errors, which is Not What We 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] #18586 [Webpages/Website]: Bug tracker not easy to find

2017-12-04 Thread Tor Bug Tracker & Wiki
#18586: Bug tracker not easy to find
+-
 Reporter:  cypherpunks |  Owner:  cypherpunks
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Webpages/Website|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tbb-usability, ux-team  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by kat5):

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


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

Re: [tor-bugs] #22609 [Webpages/Website]: Fix 3 links in FAQ "What would The Tor Project do with more funding?"

2017-12-04 Thread Tor Bug Tracker & Wiki
#22609: Fix 3 links in FAQ "What would The Tor Project do with more funding?"
--+
 Reporter:  pastly|  Owner:  linda
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  website-content   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by kat5):

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


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

Re: [tor-bugs] #22412 [Webpages/Website]: Add "How report bad tor relays" info to www.torproject.org

2017-12-04 Thread Tor Bug Tracker & Wiki
#22412: Add "How report bad tor relays" info to www.torproject.org
--+
 Reporter:  cypherpunks   |  Owner:  linda
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  website-content, ux-team  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by kat5):

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


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

Re: [tor-bugs] #22522 [Webpages/Website]: Fix broken links

2017-12-04 Thread Tor Bug Tracker & Wiki
#22522: Fix broken links
--+
 Reporter:  Fleming   |  Owner:  linda
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  website-content   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by kat5):

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


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

Re: [tor-bugs] #22907 [Core Tor/Tor]: Investigate using cargo-vendor for offline dependencies

2017-12-04 Thread Tor Bug Tracker & Wiki
#22907: Investigate using cargo-vendor for offline dependencies
-+-
 Reporter:  isis |  Owner:  isis
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, rust-pilot, tor-build, |  Actual Points:
  032-unreached  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorZ
-+-

Comment (by nickm):

 Looks okay; merged this to master.  Please close or set to "new" again as
 appropriate?

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

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

2017-12-04 Thread Tor Bug Tracker & Wiki
#23136: moat integration (fetch bridges for the user)
---+---
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_information
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201711   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+---

Comment (by mcs):

 Replying to [comment:13 antonela]:
 > Hi all!
 >
 > I think is pretty clear when you have 3 options.
 > ...

 Thank you for creating a new mockup.

 When viewed at a high level, it is definitely clearer to have 3 radio
 buttons. But for the following reason that I mentioned in comment:10,
 Kathy and I do not think a radio button is the correct UI element to use
 here:
 * What do we do after a bridge is received via moat? The obvious answer is
 that the bridge configuration line will show up in the "Provide a bridge I
 know" text area. But that means that having a radio button for the moat
 interaction does not make a lot of sense; it is a short-lived modal
 interaction (stop what you are doing, interact with BridgeDB, done) rather
 than a state that needs to be maintained.

 Also, *not* using an overlay approach will require either a really large
 window or a small CAPTCHA image (and neither of these is ideal).

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

Re: [tor-bugs] #24400 [Core Tor/Tor]: Seccomp filter incorrectly tries to act on strings, allowing sandbox bypass

2017-12-04 Thread Tor Bug Tracker & Wiki
#24400: Seccomp filter incorrectly tries to act on strings, allowing sandbox 
bypass
--+
 Reporter:  Sebastian |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Major | Resolution:
 Keywords:  sandbox   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 So, I'm sure that the orgininal reporter knows this, but I don't think
 that all the people on this thread know it: the current sandbox code tries
 to do what the the original reporter describes as

 >ensur[ing] the buffers are read-only and disallow `mprotect()` accessing
 that address.

 That's what Tor tries to do right now with all the crazy logic in
 prot_strings().  It tries to prevent mprotect() changes, munmap() or
 mremap() of the memory region, and any mprotect() changes that would
 overlap with the protected region.   It's sure not very clean code,
 though, and I can believe that there are ways around it that we don't know
 about.  How does the `brk()` bypass work here?  What are the other
 bypasses that we should know about?

 

 But let's assume that the bypass issues do affect us here.

 I think that in the longer timeframe, the right solution is to have a
 separate process that retains more syscall permissions.  This will take
 more design and implementation work, though.  It would have to be an
 optional thing that only happens when a sandbox needs it, or we'll make
 ios (and android?) sad.  It's a good candidate for a rust thing IMO.

 In the shorter term, we could remove the logic that tries to list all the
 files and only permit those, and instead permit open, openat, rename, etc
 more generally, if there's a benefit to that.

 We should also figure out what timeframe we can do the "right" solution
 on.

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

Re: [tor-bugs] #24502 [Core Tor/Tor]: scheduler_release_channel: Non-fatal assertion

2017-12-04 Thread Tor Bug Tracker & Wiki
#24502: scheduler_release_channel: Non-fatal assertion
--+
 Reporter:  toralf|  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.6-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by toralf):

 Indeed, here's the missing info :
 {{{
 /tmp/warn.log-Dec 03 01:19:02.000 [warn] Tried to establish rendezvous on
 non-OR circuit with purpose Acting as rendevous (pending)
 /tmp/warn.log-Dec 03 01:20:50.000 [warn] Tried to establish rendezvous on
 non-OR circuit with purpose Acting as rendevous (pending)
 /tmp/warn.log-Dec 03 01:21:51.000 [warn] Tried to establish rendezvous on
 non-OR circuit with purpose Acting as rendevous (pending)
 mr-fox ~ # grep -A 100 sched /tmp/warn*
 /tmp/warn.log:Dec 03 01:07:47.000 [warn] tor_bug_occurred_(): Bug:
 src/or/scheduler.c:631: scheduler_release_channel: Non-fatal assertion
 !(smartlist_pos(channels_pending, chan) == -1) failed. (on Tor
 0.3.2.6-alpha 87012d076ef58bb9)
 /tmp/warn.log:Dec 03 01:07:47.000 [warn] Bug: Non-fatal assertion
 !(smartlist_pos(channels_pending, chan) == -1) failed in
 scheduler_release_channel at src/or/scheduler.c:631. Stack trace: (on Tor
 0.3.2.6-alpha 87012d076ef58bb9)
 /tmp/warn.log-Dec 03 01:07:47.000 [warn] Bug:
 /usr/bin/tor(log_backtrace+0x53) [0x55ad3ea64e73] (on Tor 0.3.2.6-alpha
 87012d076ef58bb9)
 /tmp/warn.log-Dec 03 01:07:47.000 [warn] Bug:
 /usr/bin/tor(tor_bug_occurred_+0xc5) [0x55ad3ea81b75] (on Tor
 0.3.2.6-alpha 87012d076ef58bb9)
 /tmp/warn.log:Dec 03 01:07:47.000 [warn] Bug:
 /usr/bin/tor(scheduler_release_channel+0x19a) [0x55ad3e99312a] (on Tor
 0.3.2.6-alpha 87012d076ef58bb9)
 /tmp/warn.log-Dec 03 01:07:47.000 [warn] Bug: /usr/bin/tor(+0xc7408)
 [0x55ad3e99f408] (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
 /tmp/warn.log-Dec 03 01:07:47.000 [warn] Bug:
 /usr/bin/tor(connection_or_about_to_close+0x4d) [0x55ad3e9f43dd] (on Tor
 0.3.2.6-alpha 87012d076ef58bb9)
 /tmp/warn.log-Dec 03 01:07:47.000 [warn] Bug: /usr/bin/tor(+0x4ff8c)
 [0x55ad3e927f8c] (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
 /tmp/warn.log-Dec 03 01:07:47.000 [warn] Bug: /usr/bin/tor(+0x50788)
 [0x55ad3e928788] (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
 /tmp/warn.log-Dec 03 01:07:47.000 [warn] Bug:
 /usr/lib64/libevent-2.1.so.6(+0x2373a) [0x7ff15d09073a] (on Tor
 0.3.2.6-alpha 87012d076ef58bb9)
 /tmp/warn.log-Dec 03 01:07:47.000 [warn] Bug:
 /usr/lib64/libevent-2.1.so.6(event_base_loop+0x57f) [0x7ff15d09168f] (on
 Tor 0.3.2.6-alpha 87012d076ef58bb9)
 /tmp/warn.log-Dec 03 01:07:47.000 [warn] Bug:
 /usr/bin/tor(do_main_loop+0x24d) [0x55ad3e929f3d] (on Tor 0.3.2.6-alpha
 87012d076ef58bb9)
 /tmp/warn.log-Dec 03 01:07:47.000 [warn] Bug:
 /usr/bin/tor(tor_main+0x1c2d) [0x55ad3e92d9bd] (on Tor 0.3.2.6-alpha
 87012d076ef58bb9)
 /tmp/warn.log-Dec 03 01:07:47.000 [warn] Bug: /usr/bin/tor(main+0x28)
 [0x55ad3e9252b8] (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
 /tmp/warn.log-Dec 03 01:07:47.000 [warn] Bug:
 /lib64/libc.so.6(__libc_start_main+0xfd) [0x7ff15bc055ad] (on Tor
 0.3.2.6-alpha 87012d076ef58bb9)
 /tmp/warn.log-Dec 03 01:07:47.000 [warn] Bug:
 /usr/bin/tor(_start+0x2a) [0x55ad3e92530a] (on Tor 0.3.2.6-alpha
 87012d076ef58bb9)
 /tmp/warn.log:Dec 03 01:07:47.000 [warn] scheduler_bug_occurred(): Bug:
 Channel 431733 in state channel error and scheduler state 3. Num cells on
 cmux: 0. Connection outbuf len: 0. Num pending channels: 127. Channel in
 pending list: no. (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
 /tmp/warn.log-Dec 03 01:07:47.000 [warn] Scheduler asked to release
 channel 431733 but it wasn't in channels_pending
 /tmp/warn.log-Dec 03 01:10:05.000 [warn] Tried to establish rendezvous on
 non-OR circuit with purpose Acting as rendevous (pending)
 /tmp/warn.log-Dec 03 01:11:45.000 [warn] Tried to establish rendezvous on
 non-OR circuit with purpose Acting as rendevous (pending)
 /tmp/warn.log-Dec 03 01:11:47.000 [warn] Tried to establish rendezvous on
 non-OR circuit with purpose Acting as rendevous (pending)
 /tmp/warn.log-Dec 03 01:13:36.000 [warn] Tried to establish rendezvous on
 non-OR circuit with purpose Acting as rendevous (pending)
 /tmp/warn.log-Dec 03 01:16:41.000 [warn] Tried to establish rendezvous on
 non-OR circuit with purpose Acting as rendevous (pending)
 /tmp/warn.log-Dec 03 01:18:19.000 [warn] Tried to establish rendezvous on
 non-OR circuit with purpose Acting as rendevous (pending)
 /tmp/warn.log-Dec 03 01:19:02.000 [warn] Tried to establish rendezvous on
 non-OR circuit with purpose Acting as rendevous (pending)
 }}}
 and FWIW I set the loglevel from warn to notice.

--
Ticket URL: 

Re: [tor-bugs] #23738 [Applications/Quality Assurance and Testing]: Setup fpcentral VM

2017-12-04 Thread Tor Bug Tracker & Wiki
#23738: Setup fpcentral VM
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  defect   | Status:
 |  assigned
 Priority:  Very High|  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing|
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201711 |  Actual Points:
Parent ID:  #6119| Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 In branch `bug_23738` I added some ansible scripts to deploy fpcentral to
 forrestii.torproject.org:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_23738=0666d4f59ee35a110400bf323757d1965db09488

 We are using wsgi to run it from apache:
 http://flask.pocoo.org/docs/0.12/deploying/mod_wsgi/

 The missing part is the apache config, for which I need to open a new
 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] #24233 [Webpages/Website]: has strange <U+200B> character at the front

2017-12-04 Thread Tor Bug Tracker & Wiki
#24233:  has strange  character at the front
--+
 Reporter:  arma  |  Owner:  hiro
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by hiro):

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


Comment:

 Thanks for pointing this out. This should be fixed now.

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

Re: [tor-bugs] #23100 [Core Tor/Tor]: Circuit Build Timeout needs to count hidden service circuits

2017-12-04 Thread Tor Bug Tracker & Wiki
#23100: Circuit Build Timeout needs to count hidden service circuits
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, path-bias, guard-discovery-  |  Actual Points:
  prop247-controller, needs-proposal, mike-can,  |
  prop247, tor-guard, review-group-25, review-   |
  group-26   |
Parent ID:  #9001| Points:
 Reviewer:  asn  |Sponsor:
-+-

Comment (by nickm):

 `mikeperry/bug23114` is the branch to look at.

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

Re: [tor-bugs] #23114 [Core Tor/Tor]: Circuit Build Timeout should apply at circuit completion

2017-12-04 Thread Tor Bug Tracker & Wiki
#23114: Circuit Build Timeout should apply at circuit completion
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery-prop247-controller,  |  Actual Points:
  review-group-25, review-group-26   |
Parent ID:  #23100   | Points:
 Reviewer:  asn  |Sponsor:
-+-

Comment (by nickm):

 `mikeperry/bug23114` is the branch to look at.

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

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

2017-12-04 Thread Tor Bug Tracker & Wiki
#23136: moat integration (fetch bridges for the user)
---+---
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_information
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201711   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+---

Comment (by isabela):

 +1 to this suggestion

 Replying to [comment:13 antonela]:
 > Hi all!
 >
 > I think is pretty clear when you have 3 options.
 >
 > [ ] I will select a built-in bridge [i]
 > [ ] I would like to request a bridge
 > [ ] I have a trusted bridge
 >
 > If the user request for a bridge, the Captcha should appear.
 >
 > [ ] I will select a built-in bridge [i]
 > [x] I would like to request a bridge
 >   CAPTCHA section - horizontal layout
 > [ ] I have a trusted bridge
 >
 > Agreed about the horizontal layout, works better for sure.
 >
 > Quick mockup attached
 >
 https://trac.torproject.org/projects/tor/attachment/ticket/23136/23136.png
 >
 >

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

Re: [tor-bugs] #13837 [Core Tor/Tor]: Mitigate guard discovery by pinning middle node

2017-12-04 Thread Tor Bug Tracker & Wiki
#13837: Mitigate guard discovery by pinning middle node
-+-
 Reporter:  asn  |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-guard, guard-discovery-  |  Actual Points:
  prop247-controller |
Parent ID:  #9001| Points:
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-

Comment (by mikeperry):

 Replying to [comment:23 asn]:
 > Furthermore, this feature seems to come with at least 3 (major) design
 changes:
 > - Adds extra hops to reduce linkability.
 > - Disables cannibalization.
 > - Disable prev hop path restriction.
 >
 > I wonder where's the best way to document these design changes. On the
 manual page? On a spec somewhere? Not sure.

 Unless I fucked up, all of these design changes should only apply when the
 option is enabled. The first one can be a manpage line. The second two are
 actually filed as bugs #23101 and #24487. I don't think they warrant much
 more than a changelog note, because I want them fixed in the 0.3.3 release
 cycle, if not in the very same 0.3.3 point 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

Re: [tor-bugs] #23696 [Core Tor/Tor]: Bug: scheduler_kist.c:520: kist_scheduler_schedule: Non-fatal assertion !((diff < 0)) failed.

2017-12-04 Thread Tor Bug Tracker & Wiki
#23696: Bug: scheduler_kist.c:520: kist_scheduler_schedule: Non-fatal assertion
!((diff < 0)) failed.
-+-
 Reporter:  cypherpunks  |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-client, tor-sched, 0.3.2.2   |  Actual Points:
  -alpha-must|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 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] #24503 [Core Tor/RPM packaging]: Rust build fails

2017-12-04 Thread Tor Bug Tracker & Wiki
#24503: Rust build fails
+
 Reporter:  tortux  |  Owner:  hiviah
 Type:  defect  | Status:  needs_information
 Priority:  Medium  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/RPM packaging  |Version:  Tor: 0.3.1.9
 Severity:  Normal  | Resolution:
 Keywords:  rust packaging  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by Sebastian):

 * status:  new => needs_information


Comment:

 This is expected if you don't clone the submodule, did you do that? Can
 you provide more information on what exactly you did?

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

Re: [tor-bugs] #24503 [Core Tor/RPM packaging]: Rust build fails

2017-12-04 Thread Tor Bug Tracker & Wiki
#24503: Rust build fails
+
 Reporter:  tortux  |  Owner:  hiviah
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/RPM packaging  |Version:  Tor: 0.3.1.9
 Severity:  Normal  | Resolution:
 Keywords:  rust packaging  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by catalyst):

 * keywords:   => rust packaging


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

Re: [tor-bugs] #24501 [Core Tor/Tor]: When we hit MaxMemInQueues, make the log message more quantitative

2017-12-04 Thread Tor Bug Tracker & Wiki
#24501: When we hit MaxMemInQueues, make the log message more quantitative
--+--
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by ffmancera):

 * status:  new => needs_review


Comment:

 Done, I hope everything is fine!

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

Re: [tor-bugs] #24501 [Core Tor/Tor]: When we hit MaxMemInQueues, make the log message more quantitative

2017-12-04 Thread Tor Bug Tracker & Wiki
#24501: When we hit MaxMemInQueues, make the log message more quantitative
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by ffmancera):

 * Attachment "0001-Make-the-log-message-more-quantitative.patch" added.


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

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

2017-12-04 Thread Tor Bug Tracker & Wiki
#23136: moat integration (fetch bridges for the user)
---+---
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_information
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201711   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+---

Comment (by antonela):

 Hi all!

 I think is pretty clear when you have 3 options.

 [ ] I will select a built-in bridge [i]
 [ ] I would like to request a bridge
 [ ] I have a trusted bridge

 If the user request for a bridge, the Captcha should appear.

 [ ] I will select a built-in bridge [i]
 [x] I would like to request a bridge
 CAPTCHA section - horizontal layout
 [ ] I have a trusted bridge

 Agreed about the horizontal layout, works better for sure.

 Quick mockup attached
 https://trac.torproject.org/projects/tor/attachment/ticket/23136/23136.png

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

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

2017-12-04 Thread Tor Bug Tracker & Wiki
#23136: moat integration (fetch bridges for the user)
---+---
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_information
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201711   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+---
Changes (by antonela):

 * Attachment "23136.png" 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] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

2017-12-04 Thread Tor Bug Tracker & Wiki
#23136: moat integration (fetch bridges for the user)
---+---
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_information
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201711   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+---

Comment (by mcs):

 Replying to [comment:11 gk]:
 > I think the overlay idea is a good one. I am not sure about a good
 layout for the "Use a different bridge" part. There are basically three
 different UI elements pretty close together and all three interact somehow
 with each other. Might be confusing to users.

 You make a good point. Here is a attempt at addressing that problem, and
 also making it more obvious that the user needs to choose between
 requesting a bridge and entering info they obtained via another method.
 The overlay part would remain as shown in attachment:moat-3b-proposed.png.

 [[Image(moat-4a-proposed.png)]]

 [[Image(moat-4b-proposed.png)]]

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

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

2017-12-04 Thread Tor Bug Tracker & Wiki
#23136: moat integration (fetch bridges for the user)
---+---
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_information
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201711   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+---
Changes (by mcs):

 * Attachment "moat-4b-proposed.png" 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] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

2017-12-04 Thread Tor Bug Tracker & Wiki
#23136: moat integration (fetch bridges for the user)
---+---
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_information
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201711   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+---
Changes (by mcs):

 * Attachment "moat-4a-proposed.png" 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] #10573 [Applications/Tor Browser]: `nsILocalFile` should be replaced with `nsIFile` in our extensions

2017-12-04 Thread Tor Bug Tracker & Wiki
#10573: `nsILocalFile` should be replaced with `nsIFile` in our extensions
--+
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Minor | Resolution:
 Keywords:  tbb-easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by aruna1234):

 * Attachment "0001-Release-preparations-for-0.2.14.1.patch" added.

 Bug 10573: Replace deprecated nsILocalFile with nsIFile

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

Re: [tor-bugs] #23696 [Core Tor/Tor]: Bug: scheduler_kist.c:520: kist_scheduler_schedule: Non-fatal assertion !((diff < 0)) failed.

2017-12-04 Thread Tor Bug Tracker & Wiki
#23696: Bug: scheduler_kist.c:520: kist_scheduler_schedule: Non-fatal assertion
!((diff < 0)) failed.
-+-
 Reporter:  cypherpunks  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, tor-sched, 0.3.2.2   |  Actual Points:
  -alpha-must|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  accepted => merge_ready


Comment:

 pastly did agree on IRC to downgrade the warning to info.

 Branch: `bug23696_032_01`

 Patch is pretty 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

[tor-bugs] #24517 [Applications/Tor Browser]: can't load domains defined in `network.proxy.no_proxies_on` when `network.proxy.socks_remote_dns` is set to `true`

2017-12-04 Thread Tor Bug Tracker & Wiki
#24517: can't load domains defined in `network.proxy.no_proxies_on` when
`network.proxy.socks_remote_dns` is set to `true`
--+--
 Reporter:  tokotoko  |  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:|
--+--
 {{{
 Unable to find the proxy server

 Firefox is configured to use a proxy server that can’t be found.

 Check the proxy settings to make sure that they are correct.
 Check to make sure your computer has a working network connection.
 If your computer or network is protected by a firewall or proxy, make
 sure that Tor Browser is permitted to access the Web.
 }}}

 Same with the pac file:

 {{{
 if (shExpMatch(host,"www.etsy.com"))
 {
 return DIR;
 }
 }}}

 Gives the same error.

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

Re: [tor-bugs] #12514 [Applications/Tor Browser]: Tor Button does not work unless Navigation toolbar is enabled

2017-12-04 Thread Tor Bug Tracker & Wiki
#12514: Tor Button does not work unless Navigation toolbar is enabled
-+-
 Reporter:  pursuit81|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-torbutton, tbb-   |  Actual Points:
  easy   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by aruna1234):

 Thanks for the suggestion! Will look into it!
 Can you give me definite steps to reproduce this bug for better
 understanding.

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

Re: [tor-bugs] #23603 [Core Tor/Tor]: hs: Cleanup race between circuit close and free with the HS circuitmap

2017-12-04 Thread Tor Bug Tracker & Wiki
#23603: hs: Cleanup race between circuit close and free with the HS circuitmap
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:  asn   |Sponsor:
--+
Changes (by dgoulet):

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


Comment:

 I've taken the old patch and asn's test. Rebased it on latest 032.

 This fixes two things that this ticket found as issues. They are in two
 separate commits. Third commit adds asn's test.

 The issue with `circuit_retries` is *not* addressed in here but it is also
 not critical, the service will still work and it should be a rare case.
 But, we should definitely fix it. I propose its own ticket once this is
 merged and we agree.

 Branch: `bug23603_032_01`

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

Re: [tor-bugs] #23898 [Core Tor/Tor]: tor-spec: move IPv6 addresses from microdescs to microdesc consensus

2017-12-04 Thread Tor Bug Tracker & Wiki
#23898: tor-spec: move IPv6 addresses from microdescs to microdesc consensus
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  proposal, ipv6, tor-spec, prop283,   |  implemented
  review-group-26|  Actual Points:  1.0
Parent ID:  #20916   | Points:  0.5
 Reviewer:  nickm|Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Merged to torspec.

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

Re: [tor-bugs] #13043 [Core Tor/Tor]: torspec lies about accepting both IPv4 and IPv6 for ORAddress lines

2017-12-04 Thread Tor Bug Tracker & Wiki
#13043: torspec lies about accepting both IPv4 and IPv6 for ORAddress lines
-+-
 Reporter:  isis |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-spec, spec, 032-unreached,   |  Actual Points:
  ipv6, review-group-26  |
Parent ID:  #23898   | Points:  .1
 Reviewer:  nickm|Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Merged #23898 to torspec.

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

Re: [tor-bugs] #24392 [Core Tor/Tor]: Ignore cached bridge descriptors until we check if they are running

2017-12-04 Thread Tor Bug Tracker & Wiki
#24392: Ignore cached bridge descriptors until we check if they are running
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, tor-bridge-client,   |  Actual Points:  0.3
  s8-errors  |
Parent ID:  #24367   | Points:  0.3
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Roger, please let me know if you think I should not merge this fix until
 #24486 is resolved.  Otherwise I plan to merge it for inclusion in the
 next alpha.

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

Re: [tor-bugs] #23826 [Core Tor/Tor]: Authorities: Put Relay IPv6 addresses in the microdesc consensus

2017-12-04 Thread Tor Bug Tracker & Wiki
#23826: Authorities: Put Relay IPv6 addresses in the microdesc consensus
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, prop283, review-group-25,  |  implemented
  review-group-26|  Actual Points:  0.2
Parent ID:  #20916   | Points:  0.5
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-
Changes (by nickm):

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


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

Re: [tor-bugs] #23826 [Core Tor/Tor]: Authorities: Put Relay IPv6 addresses in the microdesc consensus

2017-12-04 Thread Tor Bug Tracker & Wiki
#23826: Authorities: Put Relay IPv6 addresses in the microdesc consensus
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, prop283, review-group-25,  |  Actual Points:  0.2
  review-group-26|
Parent ID:  #20916   | Points:  0.5
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-

Comment (by nickm):

 Still looks good: merged to master.

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

Re: [tor-bugs] #23870 [Core Tor/Tor]: Authorities: document what happens when relays have misconfigured IPv6

2017-12-04 Thread Tor Bug Tracker & Wiki
#23870: Authorities: document what happens when relays have misconfigured IPv6
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ipv6, doc, review-group-25, review-  |  Actual Points:  0.1
  group-26   |
Parent ID:  #23826   | Points:  0.2
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Parent 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] #23828 [Core Tor/Tor]: Authorities: Remove IPv6 addresses from microdescriptors

2017-12-04 Thread Tor Bug Tracker & Wiki
#23828: Authorities: Remove IPv6 addresses from microdescriptors
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, review-group-25, review-   |  implemented
  group-26   |  Actual Points:  0.2
Parent ID:  #20916   | Points:  0.5
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-
Changes (by nickm):

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


Comment:

 Still looks good; squashed and merged to master.

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

Re: [tor-bugs] #18599 [Applications/Tor Browser]: Make sure OffScreenCanvas API does not render moot our canvas fingerprinting protection

2017-12-04 Thread Tor Bug Tracker & Wiki
#18599: Make sure OffScreenCanvas API does not render moot our canvas
fingerprinting protection
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff59-esr, tbb-fingerprinting,|  Actual Points:
  GeorgKoppen201705, TorBrowserTeam201711|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by gk):

 See: https://bugzilla.mozilla.org/show_bug.cgi?id=1422862.

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

Re: [tor-bugs] #24278 [Internal Services/Tor Sysadmin Team]: VMs to deploy static website at styleguide.tpo

2017-12-04 Thread Tor Bug Tracker & Wiki
#24278: VMs to deploy static website at styleguide.tpo
-+-
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  website
 |  redesign
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #24280   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by hiro):

 So there has been a little change of plan.

 We are going to code the styleguide w/ https://www.getlektor.com/

 Lektor isn't packaged for debian, so the idea is to include it in a git
 repository in order for it to build w a jenkins job.

 Meanwhile, while I setup the repository and make some test to have it
 build w jenkins, I'd like to be able to put the built files on the static
 rotation. Is that possible?

 The static file should resolve to styleguide.torproject.org

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

Re: [tor-bugs] #24309 [Applications/Tor Browser]: Activity 4.1: Improve how circuits are displayed to the user

2017-12-04 Thread Tor Bug Tracker & Wiki
#24309: Activity 4.1: Improve how circuits are displayed to the user
--+--
 Reporter:  isabela   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:  antonela  |Sponsor:
--+--

Comment (by antonela):

 I created a few UI mockups that are trying to render all the ideas emerged
 around this ticket so we can discuss how the next iteration will look,
 before the implementation.

 I'd like to suggest moving this windows to a
 [http://design.firefox.com/photon/components/doorhangers.html doorhanger].
 This component is used by Firefox Photon UI on their latest version and
 seems a good move looking forward to March 18 items.

 [https://share.riseup.net/#boR6hSJqZb9SH7hkDUDRTg
 https://trac.torproject.org/projects/tor/attachment/ticket/24309/24309.png]

 '''Version A'''
 Nothing is clickable but the [i] icon.
 [i] icon will link to external link [guard node explainer]

 '''Version B'''
 All relay's IPs clickables to external link [atlas relay information]
 Guard Badge Added. Will link to external link [guard node explainer]

 '''Version C'''
 All relay's IPs clickables to external link [atlas relay information]
 Info Icon Added. Will link to external link [guard node explainer]

 '''Version D - Experimental'''
 I wanted to render a version where the user can find more information in a
 collapsible menu inside the relay. This option could be useful if we see
 extremely necessary adding more information before the user clicks to
 Learn More.

 Let me know what do you think

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

Re: [tor-bugs] #24309 [Applications/Tor Browser]: Activity 4.1: Improve how circuits are displayed to the user

2017-12-04 Thread Tor Bug Tracker & Wiki
#24309: Activity 4.1: Improve how circuits are displayed to the user
--+--
 Reporter:  isabela   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:  antonela  |Sponsor:
--+--
Changes (by antonela):

 * Attachment "24309.png" 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] #24200 [Applications/Tor Launcher]: improve bridge and proxy help text

2017-12-04 Thread Tor Bug Tracker & Wiki
#24200: improve bridge and proxy help text
---+---
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #21951 | Points:
 Reviewer: |Sponsor:
---+---
Description changed by isabela:

Old description:

> We should discuss and improve the bridge and proxy help text that is
> included in the new Tor Launcher. This is a spinoff from #23261, so
> several comments from that ticket are relevant:
> ticket:23261#comment:25
> ticket:23261#comment:26
> ticket:23261#comment:27
> ticket:23261#comment:28

New description:

 We should discuss and improve the bridge and proxy help text that is
 included in the new Tor Launcher. This is a spinoff from #23261, so
 several comments from that ticket are relevant:
 ticket:23261#comment:25
 ticket:23261#comment:26
 ticket:23261#comment:27
 ticket:23261#comment:28

 UX team is updating help text for both (proxy and bridge) here:
 https://docs.google.com/document/d/1y4NwoSM-
 oAzs9KsxQvetNm4r2m8SWJjanhRRKwiGy4I/edit?usp=sharing

--

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

Re: [tor-bugs] #24516 [Applications/Tor Launcher]: Update Tor Browser manual + support pages

2017-12-04 Thread Tor Bug Tracker & Wiki
#24516: Update Tor Browser manual + support pages
---+---
 Reporter:  isabela|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID:  #21951 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by mcs):

 * cc: phoul (added)


Comment:

 The component does not seem correct for this ticket. Also, while I am not
 sure if there is already a ticket to cover revisions to the support pages,
 the Tor Browser Manual work is already covered by #24391.

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

  1   2   >