Re: [tor-bugs] #18859 [Core Tor]: A new SOCKS connection should use a pre-built circuit for its first stream (was: A new SOCKS connection should use a pre-built circuit for its stream)

2016-04-20 Thread Tor Bug Tracker & Wiki
#18859: A new SOCKS connection should use a pre-built circuit for its first 
stream
-+-
 Reporter:  arthuredelstein  |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

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


[tor-bugs] #18859 [Core Tor]: A new SOCKS connection should use a pre-built circuit for its stream

2016-04-20 Thread Tor Bug Tracker & Wiki
#18859: A new SOCKS connection should use a pre-built circuit for its stream
-+-
 Reporter:  arthuredelstein  |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Since #3455, we use SOCKS auth isolation in Tor Browser to separate URL
 bar domains to different tor circuits. When the user browses to a new URL
 bar domain, a new SOCKS connection is opened with a SOCKS
 username/password unique to the site's domain.

 By telneting to the tor control port, I observed that immediately after I
 entered a new URL bar domain in a Tor Browser tab, a new circuit was built
 and assigned the SOCK_USERNAME and SOCKS_PASSWORD for that URL bar domain.

 It seems there would be better performance if we could use an existing,
 pre-built (yet-unused) circuit when a new SOCKS connection opens, and
 assign the SOCKS_USERNAME and SOCKS_PASSWORD to the pre-built circuit.
 That way the user wouldn't have to wait for a circuit to be established
 after requesting a new website.

 I don't know yet whether this is something that can be adjusted by config
 settings or if we would need to patch tor somehow.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18858 [Applications/Orbot]: Orfox won't quit.

2016-04-20 Thread Tor Bug Tracker & Wiki
#18858: Orfox won't quit.
+---
 Reporter:  ikurua22|  Owner:  n8fr8
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  |   Keywords:  Orfox
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+---
 From about a few months ago.

 1. Open Orfox.
 2. Tap =.
 3. Tap "Quit" from long menu,
 4. Orfox never quit.

 Android 4.x + Latest Orfox from FDroid.
 Did you notice this bug?

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


Re: [tor-bugs] #18854 [Applications/Orbot]: Orfox is NOT ANONYMOUS - UserAgent different than other TBB

2016-04-20 Thread Tor Bug Tracker & Wiki
#18854: Orfox is NOT ANONYMOUS - UserAgent different than other TBB
+--
 Reporter:  ikurua22|  Owner:  n8fr8
 Type:  defect  | Status:  assigned
 Priority:  Very High   |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  Orfox   |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by ikurua22):

 > the size of your screen/browser window would fairly clearly indicate you
 were on an Android device

 If the user enable(default) Javascript, right?
 I turned off JS completely, so how the attacker know I'm using mobile?

 Ok, so
 > [X] Request Desktop Site
 Please consider replace this UA(linux #2) to Windows TBB UA.

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


Re: [tor-bugs] #17799 [Core Tor/Tor]: Hash All PRNG output before use

2016-04-20 Thread Tor Bug Tracker & Wiki
#17799: Hash All PRNG output before use
---+
 Reporter:  teor   |  Owner:  nickm
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:  Tor: unspecified
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201604  |  Actual Points:
Parent ID: | Points:  small/medium-remaining
 Reviewer:  asn|Sponsor:
---+

Comment (by cypherpunks):

 {{{
 static void *
 new_prng_page(void)
 {
   const size_t sz = sizeof(shake_prng_t);
   void *result = mmap(NULL, sz,
   PROT_READ | PROT_WRITE,
   MAP_ANON | MAP_PRIVATE,
   -1, 0);
   tor_assert(result);
 }}}
 Bug: Failure is indicated with MAP_FAILED (-1).

 In `free_prng_page` you test for `!page`, so if you don't like null
 addresses maybe you would want to
 {{{
 tor_assert(result && result != MAP_FAILED)
 }}}

 Nit: The Linux manpage says MAP_ANON is deprecated in favor of
 MAP_ANONYMOUS.

 I have other comments, but I'll wait until I've read more as there are
 things I don't fully understand yet.

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


Re: [tor-bugs] #18113 [Applications/Tor Launcher]: Dynamically allocate clients to default Tor Browser bridges of a certain type

2016-04-20 Thread Tor Bug Tracker & Wiki
#18113: Dynamically allocate clients to default Tor Browser bridges of a certain
type
---+---
 Reporter:  isis   |  Owner:  brade
 Type:  enhancement| Status:
 Priority:  Medium |  needs_revision
Component:  Applications/Tor Launcher  |  Milestone:
 Severity:  Normal |Version:
 Keywords:  tbb-bridges, TorBrowserTeam201604  | Resolution:
Parent ID: |  Actual Points:
 Reviewer: | Points:
   |Sponsor:
---+---

Comment (by mrphs):

 Replying to [comment:11 teor]:

 > I'm not sure what you mean here, surely there can only be one "first"
 bridge each time Tor Browser launches.

 If you take a look at `bridge_prefs.js` file, the first obfs4 bridge
 starts with:

 {{{
 pref("extensions.torlauncher.default_bridge.obfs4.1", "obfs4...
 }}}
 and the second one with

 {{{
 pref("extensions.torlauncher.default_bridge.obfs4.2", "obfs4...
 }}}
 What happens if they all areĀ `obfs4.1`? Does Tor Browser try to connect to
 all of them at once?

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

Re: [tor-bugs] #16326 [Applications/Tor Browser]: Verify cache isolation for Request and Fetch APIs

2016-04-20 Thread Tor Bug Tracker & Wiki
#16326: Verify cache isolation for Request and Fetch APIs
-+-
 Reporter:  mikeperry|  Owner:
 Type:  defect   |  arthuredelstein
 Priority:  Medium   | Status:
Component:  Applications/Tor Browser |  needs_review
 Severity:  Normal   |  Milestone:
 Keywords:  ff45-esr, tbb-6.0a5, |Version:
  TorBrowserTeam201604R  | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-

Comment (by arthuredelstein):

 I have updated this work, here: #18741::comment:8
 Please disregard the version in comment:11 of this ticket.

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


Re: [tor-bugs] #18741 [Applications/Tor Browser]: OCSP and favicon isolation is only partly working in ESR 45

2016-04-20 Thread Tor Bug Tracker & Wiki
#18741: OCSP and favicon isolation is only partly working in ESR 45
-+-
 Reporter:  gk   |  Owner:  tbb-
 Type:  defect   |  team
 Priority:  High | Status:
Component:  Applications/Tor Browser |  needs_review
 Severity:  Major|  Milestone:
 Keywords:  ff45-esr, tbb-6.0a5, |Version:
  TorBrowserTeam201604R  | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-

Comment (by arthuredelstein):

 OK, here's the new branch. I tested on Ubuntu and got all favicon and OCSP
 requests running through the first party domain:
 https://github.com/arthuredelstein/tor-browser/commits/16326+3
 Note there are three commits here.
 * 483bd1684d437f0e03743b9573990240d77e8acc adds a fix for #16326
 * 4117c6b544e4fba93d192262aeabc0be4f38c4d7 fixes favicon cache and network
 isolation
 * 8317e098f0b880eded1301fe40e3e9fd1b813fc3 adds network isolation testing
 to our cache isolation regression test 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] #18741 [Applications/Tor Browser]: OCSP and favicon isolation is only partly working in ESR 45

2016-04-20 Thread Tor Bug Tracker & Wiki
#18741: OCSP and favicon isolation is only partly working in ESR 45
-+-
 Reporter:  gk   |  Owner:  tbb-
 Type:  defect   |  team
 Priority:  High | Status:
Component:  Applications/Tor Browser |  needs_review
 Severity:  Major|  Milestone:
 Keywords:  ff45-esr, tbb-6.0a5, |Version:
  TorBrowserTeam201604R  | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-

Comment (by arthuredelstein):

 Replying to [comment:6 gk]:
 > Reading comment:11:ticket:16326 it seems we want to have this commit
 anyway. What broke without it?

 The favicon first-party cache isolation test was not working. My patch
 fixed the cache isolation, but I realize now that the TorButton error
 message you reported in the comment:description indicates a problem with
 network isolation. I have written a patch that I think will fix both cache
 and network isolation, which I will post today after testing.

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


Re: [tor-bugs] #18572 [Core Tor/Tor]: prop224: HSDir descriptor cache implementation

2016-04-20 Thread Tor Bug Tracker & Wiki
#18572: prop224: HSDir descriptor cache implementation
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  accepted
 Priority:  High |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #17238   | Points:  large
 Reviewer:   |Sponsor:  SponsorR-must
-+

Comment (by dgoulet):

 I'm still not 100% done that is missing some documentations and massive
 amount of tests. In the meantime, here is the development branch:
 `ticket18572_029_01`

 Relevant discussions about the implementation choices:
 https://lists.torproject.org/pipermail/tor-dev/2016-April/010781.html

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


Re: [tor-bugs] #18741 [Applications/Tor Browser]: OCSP and favicon isolation is only partly working in ESR 45

2016-04-20 Thread Tor Bug Tracker & Wiki
#18741: OCSP and favicon isolation is only partly working in ESR 45
-+-
 Reporter:  gk   |  Owner:  tbb-
 Type:  defect   |  team
 Priority:  High | Status:
Component:  Applications/Tor Browser |  needs_review
 Severity:  Major|  Milestone:
 Keywords:  ff45-esr, tbb-6.0a5, |Version:
  TorBrowserTeam201604R  | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-

Comment (by gk):

 Reading comment:11:ticket:16326 it seems we want to have this commit
 anyway. What broke without 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] #18603 [Applications/Tor Browser]: failIfMajorPerformanceCaveat in a WebGL context might aid in fingerprinting

2016-04-20 Thread Tor Bug Tracker & Wiki
#18603: failIfMajorPerformanceCaveat in a WebGL context might aid in 
fingerprinting
-+
 Reporter:  gk   |  Owner:  mcs
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff45-esr, TorBrowserTeam201604R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by gk):

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


Comment:

 Looks good. This is commit 08b28fedbf5eb3a57fb1f5a2e38a830366d5f78d on
 tor-browser-45.0.2esr-6.x-1.

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


[tor-bugs] #18857 [Core Tor/Tor]: Add a soft-deprecation mechanism for configuration options

2016-04-20 Thread Tor Bug Tracker & Wiki
#18857: Add a soft-deprecation mechanism for configuration options
--+--
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  029-proposed
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 I'd like to have a way to flag configuration options as "dubious but still
 supported", and warn users that those options might go away completely
 unless they explain to us that no, somebody is still using them.

 There's a ticket about killing off old options that nobody is using (can't
 find it, though), and I've started nominating options for my own person
 sadness at
 
https://docs.google.com/spreadsheets/d/1Np1vBm0jSvUqxwaQdhkqDmYWxe4E3RO0R5RoRMtpkQQ/edit?usp=sharing
 .

 But unless we have a way to mark an option as "warn if set", then we won't
 have a nice way to do transitions here.

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


Re: [tor-bugs] #18853 [Internal Services/Tor Sysadmin Team]: Please make an ldap account for teor

2016-04-20 Thread Tor Bug Tracker & Wiki
#18853: Please make an ldap account for teor
-+
 Reporter:  arma |  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:
-+
Description changed by arma:

Old description:

> {{{
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> teor does a bunch of Tor patches, and it's high time to let him put
> those patches on a tor git repo if he wants.
>
> First name: Tom
> Last name: Wilson-Brown
> Desired uid: teor
> Forwarding address: teor2...@gmail.com
>
> $ gpg --fingerprint 968F094B
> pub   4096R/968F094B 2015-08-26 [expires: 2017-10-31]
>   Key fingerprint = C855 6CED 5D90 A0C5 29F6  4D43 450C BA7F 968F
> 094B
> uid  Tim Wilson-Brown (teor) 
> uid  Tim Wilson-Brown (teor) 
> uid  Tim Wilson-Brown 
> sub   4096R/CF68F553 2015-08-26 [expires: 2016-08-26]
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAEBCAAGBQJXF0GaAAoJEMIYUlgZ94RRPnsP/ijLSqolF2xjFQ9boeXk5PfD
> PhygnqIWy1QKn7gihe1BscB8GEqBO2XcPI1r5hG6TsiKGe7q1Z2rn77KK2i3DH1S
> E/3HeprX1tmlp6VvxFkYaVe7TEs2GBXUpm4VH8V0lyXbEqkoDx/j58j1ExR3IY16
> fkR3y96Co/I4CGF72QfRJFZaP9LgRgYoeTmoKjwNHGq/Y2peZ5NBwg9N8gRxzETE
> OBOGT7PLDQIPGBWLRpdDfvfAB+WxzEFbuzaikflv20DGn7+W0EoZoikLm8GrlKZ8
> NhHtXmaaP/imKi5wg1pLj7Z+NO+Mtu/YGfaE655rn1S2eOewG6WvpLsQ5LqM2DDP
> gBbdHP9onhQyoZiDBkK/WBnhhwFGoS/uG9cPyTE/MoPz15fnxQhc8nJTsaEH53FS
> vQoXpAQVZcGZc4Uyf249Yc8hBQ4opP5EkdoGyqJFb6TSXs0+dd6VI5mjAmNDMUZT
> mi8rk5f2Gzo5qt6z6+xny5eSkmTGisky2Q1zqPpP9nBGU2++dqtyoGcR4PmfrKp4
> mzAlOMlXBForrlqFRSXvzlZSPaYhDZzMsVtBH8TVwGMdfh37sIk+ww3YGdXjKQEl
> UZQ1GoAaCFlRnOJzm61jHoExvnML86hDCaaHPlKA8WtEbZIEzLqOT9U/yMZFBcPF
> 7ImJ1aO0H6ca8lzNY2A+
> =LCgx
> -END PGP SIGNATURE-
> }}}

New description:

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

 teor does a bunch of Tor patches, and it's high time to let him put
 those patches on a tor git repo if he wants.

 First name: Tim
 Last name: Wilson-Brown
 Desired uid: teor
 Forwarding address: teor2...@gmail.com

 $ gpg --fingerprint 968F094B
 pub   4096R/968F094B 2015-08-26 [expires: 2017-10-31]
   Key fingerprint = C855 6CED 5D90 A0C5 29F6  4D43 450C BA7F 968F 094B
 uid  Tim Wilson-Brown (teor) 
 uid  Tim Wilson-Brown (teor) 
 uid  Tim Wilson-Brown 
 sub   4096R/CF68F553 2015-08-26 [expires: 2016-08-26]

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQIcBAEBCAAGBQJXF8XpAAoJEMIYUlgZ94RR2KkQAKY2XyCpFUtLkcHLfItzcGdu
 U80Aq5h2IKn3Ix78IyG4u61DNiwyIa9kZUiQQ12HwfsFO6hSDZXHzPPBqhgqA7M7
 wDAB6aM+Y/5kDJYeJtURdHBDdshSj7czVVil4vPWNpNN54A3tSEHw/j18YWrYp5X
 RLOKYc/pWSWgdLVJZNfOfsd6AEXHkz+zUSc5JTblsNUVbQt4IRenHKx/j9yQvP6G
 /vGpxcNRn5wujOLpjKfjoHl6BTBf5wFBxKFahTjqR0syC4X3ALprWlNygSxXyn/0
 5nmUaz2P2g6cMTsbzi78qU/DQr4PlfKKf7qCIVpzk+HEgsASGzBzmQ8vuRHtg4zK
 0pWS0ENHvQhXgB0chh2Mlkka8+U6OHSzdLbEjpHwquGDKwHfNHgbFdhVALqI+sfw
 6IcCAmmWzHldJDX3xb08sPFwOzEU8avWAdWA4CGH0U7klqSOJJxKTRvAb6laTEVc
 ECCmKDIPebB1t6HOHNd5SXtjm09nhlJTUvqBvk7DQVbM7OYsLC73BL8A9jk3w4bL
 uXy6SOGG8hxAp85oC6xLGWZWd+OMLIJqFZlavFRxurXHJu9tyD1Mgh6H8Hmzft/Q
 HPeyFV611jrzu80KN81hPnxdsT/hRj/R87KfZzZ98xmJY5lkMY3SV0PNOKkQyWUJ
 hOLAbSC5+pY7VULLLUPg
 =3Q91
 -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] #18853 [Internal Services/Tor Sysadmin Team]: Please make an ldap account for teor

2016-04-20 Thread Tor Bug Tracker & Wiki
#18853: Please make an ldap account for teor
-+
 Reporter:  arma |  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] #18853 [Internal Services/Tor Sysadmin Team]: Please make an ldap account for teor

2016-04-20 Thread Tor Bug Tracker & Wiki
#18853: Please make an ldap account for teor
-+-
 Reporter:  arma |  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 weasel:

Old description:

> {{{
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> teor does a bunch of Tor patches, and it's high time to let him put
> those patches on a tor git repo if he wants.
>
> First name: Tom
> Last name: Wilson-Brown
> Desired uid: teor
> Forwarding address: teor2...@gmail.com
>
> $ gpg --fingerprint 968F094B
> pub   4096R/968F094B 2015-08-26 [expires: 2017-10-31]
>   Key fingerprint = C855 6CED 5D90 A0C5 29F6  4D43 450C BA7F 968F
> 094B
> uid  Tim Wilson-Brown (teor) 
> uid  Tim Wilson-Brown (teor) 
> uid  Tim Wilson-Brown 
> sub   4096R/CF68F553 2015-08-26 [expires: 2016-08-26]
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> iQIcBAEBCAAGBQJXF0GaAAoJEMIYUlgZ94RRPnsP/ijLSqolF2xjFQ9boeXk5PfD
> PhygnqIWy1QKn7gihe1BscB8GEqBO2XcPI1r5hG6TsiKGe7q1Z2rn77KK2i3DH1S
> E/3HeprX1tmlp6VvxFkYaVe7TEs2GBXUpm4VH8V0lyXbEqkoDx/j58j1ExR3IY16
> fkR3y96Co/I4CGF72QfRJFZaP9LgRgYoeTmoKjwNHGq/Y2peZ5NBwg9N8gRxzETE
> OBOGT7PLDQIPGBWLRpdDfvfAB+WxzEFbuzaikflv20DGn7+W0EoZoikLm8GrlKZ8
> NhHtXmaaP/imKi5wg1pLj7Z+NO+Mtu/YGfaE655rn1S2eOewG6WvpLsQ5LqM2DDP
> gBbdHP9onhQyoZiDBkK/WBnhhwFGoS/uG9cPyTE/MoPz15fnxQhc8nJTsaEH53FS
> vQoXpAQVZcGZc4Uyf249Yc8hBQ4opP5EkdoGyqJFb6TSXs0+dd6VI5mjAmNDMUZT
> mi8rk5f2Gzo5qt6z6+xny5eSkmTGisky2Q1zqPpP9nBGU2++dqtyoGcR4PmfrKp4
> mzAlOMlXBForrlqFRSXvzlZSPaYhDZzMsVtBH8TVwGMdfh37sIk+ww3YGdXjKQEl
> UZQ1GoAaCFlRnOJzm61jHoExvnML86hDCaaHPlKA8WtEbZIEzLqOT9U/yMZFBcPF
> 7ImJ1aO0H6ca8lzNY2A+
> =LCgx
> -END PGP SIGNATURE-
> }}}

New description:

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

 teor does a bunch of Tor patches, and it's high time to let him put
 those patches on a tor git repo if he wants.

 First name: Tom
 Last name: Wilson-Brown
 Desired uid: teor
 Forwarding address: teor2...@gmail.com

 $ gpg --fingerprint 968F094B
 pub   4096R/968F094B 2015-08-26 [expires: 2017-10-31]
   Key fingerprint = C855 6CED 5D90 A0C5 29F6  4D43 450C BA7F 968F 094B
 uid  Tim Wilson-Brown (teor) 
 uid  Tim Wilson-Brown (teor) 
 uid  Tim Wilson-Brown 
 sub   4096R/CF68F553 2015-08-26 [expires: 2016-08-26]

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQIcBAEBCAAGBQJXF0GaAAoJEMIYUlgZ94RRPnsP/ijLSqolF2xjFQ9boeXk5PfD
 PhygnqIWy1QKn7gihe1BscB8GEqBO2XcPI1r5hG6TsiKGe7q1Z2rn77KK2i3DH1S
 E/3HeprX1tmlp6VvxFkYaVe7TEs2GBXUpm4VH8V0lyXbEqkoDx/j58j1ExR3IY16
 fkR3y96Co/I4CGF72QfRJFZaP9LgRgYoeTmoKjwNHGq/Y2peZ5NBwg9N8gRxzETE
 OBOGT7PLDQIPGBWLRpdDfvfAB+WxzEFbuzaikflv20DGn7+W0EoZoikLm8GrlKZ8
 NhHtXmaaP/imKi5wg1pLj7Z+NO+Mtu/YGfaE655rn1S2eOewG6WvpLsQ5LqM2DDP
 gBbdHP9onhQyoZiDBkK/WBnhhwFGoS/uG9cPyTE/MoPz15fnxQhc8nJTsaEH53FS
 vQoXpAQVZcGZc4Uyf249Yc8hBQ4opP5EkdoGyqJFb6TSXs0+dd6VI5mjAmNDMUZT
 mi8rk5f2Gzo5qt6z6+xny5eSkmTGisky2Q1zqPpP9nBGU2++dqtyoGcR4PmfrKp4
 mzAlOMlXBForrlqFRSXvzlZSPaYhDZzMsVtBH8TVwGMdfh37sIk+ww3YGdXjKQEl
 UZQ1GoAaCFlRnOJzm61jHoExvnML86hDCaaHPlKA8WtEbZIEzLqOT9U/yMZFBcPF
 7ImJ1aO0H6ca8lzNY2A+
 =LCgx
 -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] #16943 [Core Tor/Tor]: Implement prop250 (Random Number Generation During Tor Voting)

2016-04-20 Thread Tor Bug Tracker & Wiki
#16943: Implement prop250 (Random Number Generation During Tor Voting)
---+---
 Reporter:  asn|  Owner:  dgoulet
 Type:  enhancement| Status:  merge_ready
 Priority:  High   |  Milestone:  Tor:
Component:  Core Tor/Tor   |  0.2.9.x-final
 Severity:  Normal |Version:
 Keywords:  tor-hs, TorCoreTeam201604  | Resolution:
Parent ID:  #8244  |  Actual Points:
 Reviewer:  nickm  | Points:  large
   |Sponsor:  SponsorR-must
---+---

Comment (by dgoulet):

 Since this one is humongeous, here is an experiment for code review on
 Gitlab using the merge request feature:

 https://gitlab.com/dgoulet/tor/merge_requests/1

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


Re: [tor-bugs] #18844 [Applications/Tor Browser]: browser hangs when clicking in bookmarks window

2016-04-20 Thread Tor Bug Tracker & Wiki
#18844: browser hangs when clicking in bookmarks window
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 I can't reproduce this connecting directly to the local X.

 Does it happen in Firefox/Ice* with your setup?

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


Re: [tor-bugs] #18856 [Core Tor/Stem]: Talk with tor's ORPort

2016-04-20 Thread Tor Bug Tracker & Wiki
#18856: Talk with tor's ORPort
---+
 Reporter:  atagar |  Owner:  atagar
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Minor  | Resolution:
 Keywords:  descriptor |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Description changed by atagar:

Old description:

> Long ago tor served and received descriptors on its DirPort but nowadays
> it uses single-hop circuits on its ORPort instead. In fact, the DirPort
> is essentially unused besides Stem.
>
> It would be nice if Stem learned how to download descriptors from tor's
> ORPort. This would allow us to better test relays and the directory
> authorities. This is a very minor benefit and not worth the amount of
> effort it would likely take, but we might be able to make this easier by
> taking advantage of other tor implementations written in python...
>
> * [https://github.com/cea-sec/TorPylle/ TorPylle]
> * [https://github.com/pycepa/pycepa/ Pycepa]
> * [https://github.com/nskinkel/oppy Oppy]

New description:

 Long ago tor served and received descriptors on its DirPort but nowadays
 it uses single-hop circuits on its ORPort instead. In fact, the DirPort is
 essentially unused besides Stem.

 It would be nice if Stem learned how to download descriptors from tor's
 ORPort. This would allow us to better test relays and the directory
 authorities. This is a very minor benefit and not worth the amount of
 effort it would likely take, but we might be able to make this easier by
 taking advantage of other tor implementations written in python...

 * [https://github.com/cea-sec/TorPylle/ TorPylle]
 * [https://github.com/pycepa/pycepa/ Pycepa]
 * [https://github.com/nskinkel/oppy Oppy]

 A list of all known tor implementations can be found
 [https://trac.torproject.org/projects/tor/wiki/doc/ListOfTorImplementations
 here].

--

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


[tor-bugs] #18856 [Core Tor/Stem]: Talk with tor's ORPort

2016-04-20 Thread Tor Bug Tracker & Wiki
#18856: Talk with tor's ORPort
---+
 Reporter:  atagar |  Owner:  atagar
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Minor  |   Keywords:  descriptor
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 Long ago tor served and received descriptors on its DirPort but nowadays
 it uses single-hop circuits on its ORPort instead. In fact, the DirPort is
 essentially unused besides Stem.

 It would be nice if Stem learned how to download descriptors from tor's
 ORPort. This would allow us to better test relays and the directory
 authorities. This is a very minor benefit and not worth the amount of
 effort it would likely take, but we might be able to make this easier by
 taking advantage of other tor implementations written in python...

 * [https://github.com/cea-sec/TorPylle/ TorPylle]
 * [https://github.com/pycepa/pycepa/ Pycepa]
 * [https://github.com/nskinkel/oppy Oppy]

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


Re: [tor-bugs] #18603 [Applications/Tor Browser]: failIfMajorPerformanceCaveat in a WebGL context might aid in fingerprinting

2016-04-20 Thread Tor Bug Tracker & Wiki
#18603: failIfMajorPerformanceCaveat in a WebGL context might aid in 
fingerprinting
-+-
 Reporter:  gk   |  Owner:  mcs
 Type:  task | Status:
 Priority:  Medium   |  needs_review
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  ff45-esr, TorBrowserTeam201604R  | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-
Changes (by mcs):

 * status:  assigned => needs_review
 * keywords:  ff45-esr, TorBrowserTeam201604 => ff45-esr,
 TorBrowserTeam201604R


Comment:

 I patch is available here:
 https://gitweb.torproject.org/user/brade/tor-
 browser.git/commit/?h=bug18603-01&id=08b28fedbf5eb3a57fb1f5a2e38a830366d5f78d

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


Re: [tor-bugs] #18671 [Core Tor/Stem]: ExitPolicy doesn't play well with ipv6

2016-04-20 Thread Tor Bug Tracker & Wiki
#18671: ExitPolicy doesn't play well with ipv6
---+--
 Reporter:  Sebastian  |  Owner:  atagar
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  user disappeared
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by atagar):

 * status:  needs_information => closed
 * resolution:   => user disappeared


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


Re: [tor-bugs] #18603 [Applications/Tor Browser]: failIfMajorPerformanceCaveat in a WebGL context might aid in fingerprinting (was: failIfMajorPerformanceCaveat in a WebGL context migth aid in fingerp

2016-04-20 Thread Tor Bug Tracker & Wiki
#18603: failIfMajorPerformanceCaveat in a WebGL context might aid in 
fingerprinting
+--
 Reporter:  gk  |  Owner:  mcs
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff45-esr, TorBrowserTeam201604  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by mcs):

 * status:  new => assigned
 * cc: brade, tbb-team (added)
 * keywords:  ff45-esr => ff45-esr, TorBrowserTeam201604
 * owner:  tbb-team => mcs


Old description:

> https://bugzilla.mozilla.org/show_bug.cgi?id=1164970 implemented
> `failIfMajorPerformanceCaveat` that makes the context creation fail when
> layer acceleration is not supported. We should investigate whether our
> WebGL noramlizing is affected by this.

New description:

 https://bugzilla.mozilla.org/show_bug.cgi?id=1164970 implemented
 `failIfMajorPerformanceCaveat` that makes the context creation fail when
 layer acceleration is not supported. We should investigate whether our
 WebGL normalizing is affected by this.

--

Comment:

 Kathy and I looked at this.  Unless we disable this feature, we think it
 could be used as a fingerprinting vector.  We will create a patch to pref
 it off.

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


Re: [tor-bugs] #17119 [Applications/Tor Browser]: Make sure the expanded malware protection is disabled in Tor Browser based on ESR 45

2016-04-20 Thread Tor Bug Tracker & Wiki
#17119: Make sure the expanded malware protection is disabled in Tor Browser 
based
on ESR 45
-+-
 Reporter:  gk   |  Owner:  tbb-
 Type:  task |  team
 Priority:  Medium   | Status:  closed
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  tbb-linkability, ff45-esr,   | Resolution:  fixed
  TorBrowserTeam201604   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * keywords:  tbb-linkability, ff45-esr => tbb-linkability, ff45-esr,
 TorBrowserTeam201604
 * status:  new => closed
 * resolution:   => fixed
 * severity:   => Normal


Comment:

 This is already disabled in 000-tor-browser.js on the tor-
 browser-45.0.2esr-6.x-1 branch (browser.safebrowsing.malware.enabled is
 set to false).

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


Re: [tor-bugs] #18821 [Applications/Tor Browser]: Make sure libmdns is Android only and disabled for Orfox

2016-04-20 Thread Tor Bug Tracker & Wiki
#18821: Make sure libmdns is Android only and disabled for Orfox
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  task | Status:
 Priority:  High |  needs_review
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Critical |Version:
 Keywords:  ff45-esr, tbb-6.0a5, | Resolution:
  TorBrowserTeam201604R GeorgKoppen201604|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Yes, this is quite some amount of code and complexity. Good catch,
 although I am less worried about OS X as the preference
 (`dom.presentation.discovery.enabled` seems to get obeyed). I've fixed
 this in bug_18821_v3 (https://gitweb.torproject.org/user/gk/tor-
 browser.git/commit/?h=bug_18821_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] #18848 [Applications/Tor Browser]: Additional welcome URL is shown in ESR 45 based Tor Browser

2016-04-20 Thread Tor Bug Tracker & Wiki
#18848: Additional welcome URL is shown in ESR 45 based Tor Browser
-+-
 Reporter:  gk   |  Owner:  tbb-
 Type:  defect   |  team
 Priority:  High | Status:  closed
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Major|Version:
 Keywords:  ff45-esr, tbb-6.0a5, | Resolution:  fixed
  TorBrowserTeam201604R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Fixed with commit 5d9a6f8007e36a0276ffd5bcad2ffe69a2f7 on tor-
 browser-45.0.2esr-6.x-1.

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


Re: [tor-bugs] #17799 [Core Tor/Tor]: Hash All PRNG output before use

2016-04-20 Thread Tor Bug Tracker & Wiki
#17799: Hash All PRNG output before use
---+
 Reporter:  teor   |  Owner:  nickm
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:  Tor: unspecified
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201604  |  Actual Points:
Parent ID: | Points:  small/medium-remaining
 Reviewer:  asn|Sponsor:
---+

Comment (by cypherpunks):

 {{{
 #define PRNG_CARRYFORWARD (PRNG_SHAKE_BITS * 2)
 }}}

 Did you mean something like `(PRNG_SHAKE_BITS / 8 * 2)`, by any chance?

 I'll keep reading.

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


Re: [tor-bugs] #18741 [Applications/Tor Browser]: OCSP and favicon isolation is only partly working in ESR 45

2016-04-20 Thread Tor Bug Tracker & Wiki
#18741: OCSP and favicon isolation is only partly working in ESR 45
-+-
 Reporter:  gk   |  Owner:  tbb-
 Type:  defect   |  team
 Priority:  High | Status:
Component:  Applications/Tor Browser |  needs_review
 Severity:  Major|  Milestone:
 Keywords:  ff45-esr, tbb-6.0a5, |Version:
  TorBrowserTeam201604R  | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:4 gk]:
 > Hm... I still see the issue in a test build applied with the patch it
 seems.

 On a Linux box in case this matters.

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


Re: [tor-bugs] #18854 [Applications/Orbot]: Orfox is NOT ANONYMOUS - UserAgent different than other TBB

2016-04-20 Thread Tor Bug Tracker & Wiki
#18854: Orfox is NOT ANONYMOUS - UserAgent different than other TBB
+--
 Reporter:  ikurua22|  Owner:  n8fr8
 Type:  defect  | Status:  assigned
 Priority:  Very High   |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  Orfox   |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by n8fr8):

 * status:  new => assigned
 * severity:  Critical => Normal


Comment:

 We made the conscious decision to use a mobile user agent for Orfox so
 that you would receive mobile formatted sites when browsing. This means
 your user-agent is within the set of Firefox for Android users on the same
 version, etc, and definitely within the pool of 1 million or so current
 Orfox users.

 Even if we used the same TBB user agent, the size of your screen/browser
 window would fairly clearly indicate you were on an Android device, or at
 least a mobile device.

 There is only so much we can do at this time.

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


Re: [tor-bugs] #18821 [Applications/Tor Browser]: Make sure libmdns is Android only and disabled for Orfox

2016-04-20 Thread Tor Bug Tracker & Wiki
#18821: Make sure libmdns is Android only and disabled for Orfox
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  task | Status:
 Priority:  High |  needs_review
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Critical |Version:
 Keywords:  ff45-esr, tbb-6.0a5, | Resolution:
  TorBrowserTeam201604R GeorgKoppen201604|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * cc: brade, mcs, arthuredelstein (added)


Comment:

 Do we also want to back out the
 netwerk/dns/mdns/libmdns/nsMulticastDNSModule.cpp changes that were made
 by https://hg.mozilla.org/mozilla-central/rev/6bfb430de85d ?  It is not
 clear to me how all of these pieces fit together

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


Re: [tor-bugs] #18741 [Applications/Tor Browser]: OCSP and favicon isolation is only partly working in ESR 45

2016-04-20 Thread Tor Bug Tracker & Wiki
#18741: OCSP and favicon isolation is only partly working in ESR 45
-+-
 Reporter:  gk   |  Owner:  tbb-
 Type:  defect   |  team
 Priority:  High | Status:
Component:  Applications/Tor Browser |  needs_review
 Severity:  Major|  Milestone:
 Keywords:  ff45-esr, tbb-6.0a5, |Version:
  TorBrowserTeam201604R  | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-

Comment (by gk):

 Hm... I still see the issue in a test build applied with the patch it
 seems.

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


Re: [tor-bugs] #15621 [Core Tor/Tor]: Kill the pre-version 3 intro protocol code with fire.

2016-04-20 Thread Tor Bug Tracker & Wiki
#15621: Kill the pre-version 3 intro protocol code with fire.
---+---
 Reporter:  yawning|  Owner:  dgoulet
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
Component:  Core Tor/Tor   |  0.2.9.x-final
 Severity:  Normal |Version:
 Keywords:  tor-hs, TorCoreTeam201604  | Resolution:
Parent ID:  #6418  |  Actual Points:
 Reviewer:  asn| Points:  small
   |Sponsor:  SponsorR-can
---+---

Comment (by nickm):

 Ack on NM1...NM2.  I think that for NM3, you're right, but we should add a
 tor_fragile_assert() there to make intent more clear.  (Or even
 tor_assert_nonfatal_unreached().)

 For NM4, the fingerprinting issue: The case I'm worried about is where we
 learn that an HS upgraded at the same time that some other view of the HS
 upgraded.  (eg, it's being used as a client too, and they're trying to
 keep the client identity separate from the HS identity, but both changes
 are observable.)  Am I being too paranoid here?

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


Re: [tor-bugs] #18848 [Applications/Tor Browser]: Additional welcome URL is shown in ESR 45 based Tor Browser

2016-04-20 Thread Tor Bug Tracker & Wiki
#18848: Additional welcome URL is shown in ESR 45 based Tor Browser
-+-
 Reporter:  gk   |  Owner:  tbb-
 Type:  defect   |  team
 Priority:  High | Status:
Component:  Applications/Tor Browser |  needs_review
 Severity:  Major|  Milestone:
 Keywords:  ff45-esr, tbb-6.0a5, |Version:
  TorBrowserTeam201604R  | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:2 gk]:
 > bug_18848 (https://gitweb.torproject.org/user/gk/tor-
 browser.git/commit/?h=bug_18848) has a fix for review (disabling the
 Windows 10 first start URL as well)

 r=brade, r=mcs
 Looks good.

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


Re: [tor-bugs] #18546 [Applications/Tor Browser]: Review networking code for Firefox 45

2016-04-20 Thread Tor Bug Tracker & Wiki
#18546: Review networking code for Firefox 45
-+-
 Reporter:  gk   |  Owner:
 Type:  task |  mikeperry
 Priority:  Very High| Status:
Component:  Applications/Tor Browser |  assigned
 Severity:  Critical |  Milestone:
 Keywords:  ff45-esr, MikePerry201604,   |Version:
  TorBrowserTeam201604   | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:4 mikeperry]:
 > Here's the quick notes for stuff that really needs another set of eyes:
 >  * We need to verify the proper application of our OCSP and NSS safety
 patches in security/nss. Last time we improperly applied the DNS patch
 while rebasing. That might happen again here, too.

 They look good to me.

 >  * We should make sure that ./netwerk/dns/mdns/libmdns/ is Android only
 and also disabled for OrFox

 This is #18221.

 >  * The "Presentation API" stuff seems new, but possibly not enabled yet.
 It has lots of networking things. We should make sure it is disabled.
 >  * The nsDNSService patches should be verified for the same reason as
 the NSS ones
 >  * There's some resolver stuff in Android that uses SOCK_DGRAM. We
 should make sure this is not active in OrFox
 >  * It looks like
 ./toolkit/modules/secondscreen/SimpleServiceDiscovery.jsm is included now?
 Can we kill it? And what is this second screen stuff?
 >  * dom.udpsocket and dom.moztcpsocket are still off, yes?
 >  * We disabled/patched the debugger and related discovery stuff before,
 right? Is that still off?

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


Re: [tor-bugs] #18821 [Applications/Tor Browser]: Make sure libmdns is Android only and disabled for Orfox

2016-04-20 Thread Tor Bug Tracker & Wiki
#18821: Make sure libmdns is Android only and disabled for Orfox
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  task | Status:
 Priority:  High |  needs_review
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Critical |Version:
 Keywords:  ff45-esr, tbb-6.0a5, | Resolution:
  TorBrowserTeam201604R GeorgKoppen201604|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  ff45-esr, tbb-6.0a5, TorBrowserTeam201604 GeorgKoppen201604 =>
 ff45-esr, tbb-6.0a5, TorBrowserTeam201604R GeorgKoppen201604
 * status:  assigned => needs_review


Comment:

 libdmns is not Android only.
 https://bugzilla.mozilla.org/show_bug.cgi?id=1225726 makes it available
 for OS X as well. However, do to stability issues it got disabled by
 https://bugzilla.mozilla.org/show_bug.cgi?id=1217807. That one in turn
 does not seem to affect Orfox, though. Thus, we have a non-preference
 approach backing basically the patches out that enabled mDNS on OSX and
 Android.
 bug_18221_v2 (https://gitweb.torproject.org/user/gk/tor-
 browser.git/commit/?h=bug_18821_v2) has it up for review.

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


Re: [tor-bugs] #16224 [Applications/Tor Browser]: Get rid of BUILD_HOSTNAME if building Tor Browser inside Gititan

2016-04-20 Thread Tor Bug Tracker & Wiki
#16224: Get rid of BUILD_HOSTNAME if building Tor Browser inside Gititan
-+-
 Reporter:  gk   |  Owner:  tbb-
 Type:  enhancement  |  team
 Priority:  Medium   | Status:  closed
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  tbb-gitian, ff45-esr,| Resolution:  fixed
  TorBrowserTeam201604R, GeorgKoppen201604   |  Actual Points:
Parent ID:  #18226   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Fixed in commit aa737d315bab537d94a14d7f2dca16d7b54edc38.

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


Re: [tor-bugs] #16224 [Applications/Tor Browser]: Get rid of BUILD_HOSTNAME if building Tor Browser inside Gititan

2016-04-20 Thread Tor Bug Tracker & Wiki
#16224: Get rid of BUILD_HOSTNAME if building Tor Browser inside Gititan
-+-
 Reporter:  gk   |  Owner:  tbb-
 Type:  enhancement  |  team
 Priority:  Medium   | Status:
Component:  Applications/Tor Browser |  needs_review
 Severity:  Normal   |  Milestone:
 Keywords:  tbb-gitian, ff45-esr,|Version:
  TorBrowserTeam201604R, GeorgKoppen201604   | Resolution:
Parent ID:  #18226   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-

Comment (by mcs):

 r=mcs
 This looks fine to me.

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


Re: [tor-bugs] #18829 [Applications/Tor Browser]: Media Preview in Page Info may not meet TBB expectations for media handling

2016-04-20 Thread Tor Bug Tracker & Wiki
#18829: Media Preview in Page Info may not meet TBB expectations for media 
handling
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Related: #18770.

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


Re: [tor-bugs] #18770 [Applications/Tor Browser]: SVGs should not show in Page Info when disabled

2016-04-20 Thread Tor Bug Tracker & Wiki
#18770: SVGs should not show in Page Info when disabled
--+-
 Reporter:  mcs   |  Owner:  mcs
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff45-esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by cypherpunks):

 Related: #18829.

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


Re: [tor-bugs] #18030 [Applications/Tor Browser]: Favicons loaded via the Page Info dialog are going over the catch-all circuit

2016-04-20 Thread Tor Bug Tracker & Wiki
#18030: Favicons loaded via the Page Info dialog are going over the catch-all
circuit
-+-
 Reporter:  gk   |  Owner:  tbb-
 Type:  defect   |  team
 Priority:  Medium   | Status:  closed
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  tbb-linkability, | Resolution:  fixed
  TorBrowserTeam201602R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Did this patch fixed it for all media or just images? Because, according
 to the logs, I see in Tor Browser 5.5.4 that images go through the first-
 party domain circuit, but other media such as HTML5 `` and
 `` sources fall into the "catchall" circuit (the first-party domain
 seems to be "--unknown--").

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


Re: [tor-bugs] #18616 [Core Tor/Tor]: Relay fails to self-test its DirPort with AccountingMax enabled

2016-04-20 Thread Tor Bug Tracker & Wiki
#18616: Relay fails to self-test its DirPort with AccountingMax enabled
-+-
 Reporter:  toralf   |  Owner:
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  regression, must-fix-before-028-rc,  |Version:  Tor:
  TorCoreTeam201604  |  0.2.8.1-alpha
Parent ID:   | Resolution:
 Reviewer:  dgoulet  |  Actual Points:  16
 |  hours
 | Points:  medium
 |Sponsor:
-+-

Comment (by arma):

 1)
 {{{
 \ No newline at end of file
 }}}
 for the changes file will produce surprising results when somebody cats
 all the changes files together.

 2)
 {{{
 +static int router_reachability_checks_disabled(void)
  {
const or_options_t *options = get_options();
 }}}
 As a static helper function, it might be a bit cleaner to pass in
 {{{options}}} to it, especially since one of the two callers already has
 an 'options' hanging out ready to be passed in. We're certainly not
 consistent about this, but I think it's the righter thing to do.

 3) I like 004e1c2704 but it looks like it does two things -- first is the
 refactor, and second is the change where check_whether_orport_reachable()
 considers net_is_disabled(). "Refactor" commits are easiest to review when
 they don't also change behavior. This could become two commits, the first
 adding the net_is_disabled() to check_whether_orport_reachable(), and the
 second adding the modular function along with a note "no actual changes in
 behavior" to make it clear that it's just a refactor.

 3b) Does the behavior change from 004e1c2704 warrant a changelog entry? I
 think it probably does.

 Also, I looked through the calls to check_whether_orport_reachable() and I
 don't think that behavior change will surprise us. Good.

 3c) in control.c:
 {{{
 } else if (!strcmp(question, "status/reachability-succeeded/or")) {
   *answer = tor_strdup(check_whether_orport_reachable() ? "1" : "0");
 } else if (!strcmp(question, "status/reachability-succeeded/dir")) {
   *answer = tor_strdup(check_whether_dirport_reachable() ? "1" : "0");
 } else if (!strcmp(question, "status/reachability-succeeded")) {
   tor_asprintf(answer, "OR=%d DIR=%d",
check_whether_orport_reachable() ? 1 : 0,
check_whether_dirport_reachable() ? 1 : 0);
 }}}
 are documented as
 {{{
 "status/reachability-succeeded/or"
   0 or 1, depending on whether we've found our ORPort reachable.
 "status/reachability-succeeded/dir"
   0 or 1, depending on whether we've found our DirPort reachable.
 "status/reachability-succeeded"
 }}}
 I think the "we aren't trying to test reachability on it, so return 1"
 behavior might be surprising here. On the other hand, the reachability did
 *succeed*, in that we're not unhappy with the current state of things.
 Yuck. No need to fix it here but maybe we want to clean this up in the
 future?

 4) In commit 4dda75fc0 we end up with a new function
 decide_to_advertise_begindir(), that looks like it shares a lot of code
 with the place you cut-and-pasted it from (decide_to_advertise_dirport())?
 Leaving these two functions in place together is begging for bugs in the
 future where one gets out of sync from the other.

 5)
 {{{
 +  /* redundant - if DirPort is unreachable, we don't publish a descriptor
 */
if (!check_whether_dirport_reachable())
 }}}
 I agree. Let's add a commit to take that check out?

 6) It seems we still have a complicated mess of similar sounding
 functions, directory-permits-this, dirport-set-that, etc. Not something
 that needs to be fixed for this ticket, but certainly something worth
 working on for the future!

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


[tor-bugs] #18855 [Applications/Tor Browser]: Add-on directory clean-up error after update check

2016-04-20 Thread Tor Bug Tracker & Wiki
#18855: Add-on directory clean-up error after update check
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  ff45-esr
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 It seems we get an error after the add-on update check with ESR45:
 {{{
 1461145678000   addons.xpi  ERROR   Failed to clean updated system
 add-ons directories.: Unix error 2 during operation
 DirectoryIterator.prototype.next on file /path/to/tor-
 browser/Browser/TorBrowser/Data/Browser/profile.default/features (file or
 directory not found) ((unknown module)) No traceback available
 }}}

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


Re: [tor-bugs] #18848 [Applications/Tor Browser]: Additional welcome URL is shown in ESR 45 based Tor Browser

2016-04-20 Thread Tor Bug Tracker & Wiki
#18848: Additional welcome URL is shown in ESR 45 based Tor Browser
-+-
 Reporter:  gk   |  Owner:  tbb-
 Type:  defect   |  team
 Priority:  High | Status:
Component:  Applications/Tor Browser |  needs_review
 Severity:  Major|  Milestone:
 Keywords:  ff45-esr, tbb-6.0a5, |Version:
  TorBrowserTeam201604R  | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-
Changes (by gk):

 * keywords:  ff45-esr, tbb-6.0a5, TorBrowserTeam201604 => ff45-esr,
 tbb-6.0a5, TorBrowserTeam201604R
 * status:  new => needs_review


Comment:

 bug_18848 (https://gitweb.torproject.org/user/gk/tor-
 browser.git/commit/?h=bug_18848) has a fix for review (disabling the
 Windows 10 first start URL as well)

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


Re: [tor-bugs] #18848 [Applications/Tor Browser]: Additional welcome URL is shown in ESR 45 based Tor Browser

2016-04-20 Thread Tor Bug Tracker & Wiki
#18848: Additional welcome URL is shown in ESR 45 based Tor Browser
-+-
 Reporter:  gk   |  Owner:  tbb-
 Type:  defect   |  team
 Priority:  High | Status:  new
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Major|Version:
 Keywords:  ff45-esr, tbb-6.0a5, | Resolution:
  TorBrowserTeam201604   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 This is due to
 {{{
 additionalPage =
 Services.urlFormatter.formatURLPref("startup.homepage_welcome_url.additional");
 }}}

 and

 {{{
 if (additionalPage && additionalPage != "about:blank") {
   if (overridePage) {
 overridePage += "|" + additionalPage;
   } else {
 overridePage = additionalPage;
   }
 }
 }}}
 In Tor Browser based on ESR38 `overridePage` is an empty string.

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


Re: [tor-bugs] #18715 [Applications/Orbot]: Outbound proxy is not working if set to HTTP

2016-04-20 Thread Tor Bug Tracker & Wiki
#18715: Outbound proxy is not working if set to HTTP
+---
 Reporter:  ikurua22|  Owner:  n8fr8
 Type:  task| Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:  duplicate
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
Changes (by ikurua22):

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


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


Re: [tor-bugs] #18854 [Applications/Orbot]: Orfox is NOT ANONYMOUS - UserAgent different than other TBB

2016-04-20 Thread Tor Bug Tracker & Wiki
#18854: Orfox is NOT ANONYMOUS - UserAgent different than other TBB
+---
 Reporter:  ikurua22|  Owner:  n8fr8
 Type:  defect  | Status:  new
 Priority:  Very High   |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Critical| Resolution:
 Keywords:  Orfox   |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
Changes (by ikurua22):

 * severity:  Normal => Critical


Comment:

 FYI, in current Orfox, if I check that box:
 

 Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0

 & new:
 HTTP_PRAGMA | no-cache


 Hmm... not so anonymous, don't 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] #18854 [Applications/Orbot]: Orfox is NOT ANONYMOUS - UserAgent different than other TBB

2016-04-20 Thread Tor Bug Tracker & Wiki
#18854: Orfox is NOT ANONYMOUS - UserAgent different than other TBB
+---
 Reporter:  ikurua22|  Owner:  n8fr8
 Type:  defect  | Status:  new
 Priority:  Very High   |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  Orfox   |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---

Comment (by ikurua22):

 Or,

 [X] Request Desktop Site <---set it to default, then use Windows UA.

 if the user uncheck it, show a big warning, something like

 "You are willing to let website to know you are using Android, rather than
 stay Anonymous with other TBB users.
 Are you really want to do this?

 Yes | No"

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18854 [Applications/Orbot]: Orfox is NOT ANONYMOUS - UserAgent different than other TBB

2016-04-20 Thread Tor Bug Tracker & Wiki
#18854: Orfox is NOT ANONYMOUS - UserAgent different than other TBB
+---
 Reporter:  ikurua22|  Owner:  n8fr8
 Type:  defect  | Status:  new
 Priority:  Very High   |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  |   Keywords:  Orfox
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+---
 https://tor.stackexchange.com/questions/4890/tor-browser-user-agent-
 strings

 Currently, TBB use Windows UA as a default.

 (tested with latest TBB, if I'm a mistake correct me with latest data.)
 Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Firefox/38.0

 However, Orfox use Android itself.
 Mozilla/5.0 (Android; Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

 Even Orfox is for Android smartphone,
 I think Orfox should use default TBB's UA for anti-fingerprint.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18853 [Internal Services/Tor Sysadmin Team]: Please make an ldap account for teor

2016-04-20 Thread Tor Bug Tracker & Wiki
#18853: Please make an ldap account for teor
-+-
 Reporter:  arma |  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: SHA256

 teor does a bunch of Tor patches, and it's high time to let him put
 those patches on a tor git repo if he wants.

 First name: Tom
 Last name: Wilson-Brown
 Desired uid: teor
 Forwarding address: teor2...@gmail.com

 $ gpg --fingerprint 968F094B
 pub   4096R/968F094B 2015-08-26 [expires: 2017-10-31]
   Key fingerprint = C855 6CED 5D90 A0C5 29F6  4D43 450C BA7F 968F 094B
 uid  Tim Wilson-Brown (teor) 
 uid  Tim Wilson-Brown (teor) 
 uid  Tim Wilson-Brown 
 sub   4096R/CF68F553 2015-08-26 [expires: 2016-08-26]

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1
 iQIcBAEBCAAGBQJXF0GaAAoJEMIYUlgZ94RRPnsP/ijLSqolF2xjFQ9boeXk5PfD
 PhygnqIWy1QKn7gihe1BscB8GEqBO2XcPI1r5hG6TsiKGe7q1Z2rn77KK2i3DH1S
 E/3HeprX1tmlp6VvxFkYaVe7TEs2GBXUpm4VH8V0lyXbEqkoDx/j58j1ExR3IY16
 fkR3y96Co/I4CGF72QfRJFZaP9LgRgYoeTmoKjwNHGq/Y2peZ5NBwg9N8gRxzETE
 OBOGT7PLDQIPGBWLRpdDfvfAB+WxzEFbuzaikflv20DGn7+W0EoZoikLm8GrlKZ8
 NhHtXmaaP/imKi5wg1pLj7Z+NO+Mtu/YGfaE655rn1S2eOewG6WvpLsQ5LqM2DDP
 gBbdHP9onhQyoZiDBkK/WBnhhwFGoS/uG9cPyTE/MoPz15fnxQhc8nJTsaEH53FS
 vQoXpAQVZcGZc4Uyf249Yc8hBQ4opP5EkdoGyqJFb6TSXs0+dd6VI5mjAmNDMUZT
 mi8rk5f2Gzo5qt6z6+xny5eSkmTGisky2Q1zqPpP9nBGU2++dqtyoGcR4PmfrKp4
 mzAlOMlXBForrlqFRSXvzlZSPaYhDZzMsVtBH8TVwGMdfh37sIk+ww3YGdXjKQEl
 UZQ1GoAaCFlRnOJzm61jHoExvnML86hDCaaHPlKA8WtEbZIEzLqOT9U/yMZFBcPF
 7ImJ1aO0H6ca8lzNY2A+
 =LCgx
 -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] #18663 [Metrics/Onionoo]: Onionoo doesn't send certain headers on even-numbered responses

2016-04-20 Thread Tor Bug Tracker & Wiki
#18663: Onionoo doesn't send certain headers on even-numbered responses
-+--
 Reporter:  dcf  |  Owner:  karsten
 Type:  defect   | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * severity:  Normal => Major


Comment:

 H.  I don't have a solution yet, but here's a quick update: I can
 confirm that the problem still persists, and the disabled GzipFilter is
 not reflected in Git yet, because I only took it out locally on the server
 without committing.  I'll have to take a closer look at this and will
 report back once I have found something.

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


Re: [tor-bugs] #18771 [Applications/Tor Messenger]: Fails to extract correctly v1.0b6

2016-04-20 Thread Tor Bug Tracker & Wiki
#18771: Fails to extract correctly v1.0b6
+--
 Reporter:  cypherpunks |  Owner:
 Type:  defect  | Status:
 Priority:  Medium  |  needs_information
Component:  Applications/Tor Messenger  |  Milestone:
 Severity:  Normal  |Version:
 Keywords:  | Resolution:
Parent ID:  |  Actual Points:
 Reviewer:  | Points:
|Sponsor:
+--
Changes (by gk):

 * status:  new => needs_information


Comment:

 We have nightly builds for Tor Browser based on ESR45 which come close to
 the build and packaging setup Tor Messenger uses:
 https://people.torproject.org/~linus/builds/tbb-nightly-2016-04-19/ Does
 the Windows one work for you?

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


Re: [tor-bugs] #18616 [Core Tor/Tor]: Relay fails to self-test its DirPort with AccountingMax enabled

2016-04-20 Thread Tor Bug Tracker & Wiki
#18616: Relay fails to self-test its DirPort with AccountingMax enabled
-+-
 Reporter:  toralf   |  Owner:
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  regression, must-fix-before-028-rc,  |Version:  Tor:
  TorCoreTeam201604  |  0.2.8.1-alpha
Parent ID:   | Resolution:
 Reviewer:  dgoulet  |  Actual Points:  16
 |  hours
 | Points:  medium
 |Sponsor:
-+-

Comment (by teor):

 Oops, see my branch bug18616-v3 on https://github.com/teor2345/tor.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] #18616 [Core Tor/Tor]: Relay fails to self-test its DirPort with AccountingMax enabled

2016-04-20 Thread Tor Bug Tracker & Wiki
#18616: Relay fails to self-test its DirPort with AccountingMax enabled
-+-
 Reporter:  toralf   |  Owner:
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  regression, must-fix-before-028-rc,  |Version:  Tor:
  TorCoreTeam201604  |  0.2.8.1-alpha
Parent ID:   | Resolution:
 Reviewer:  dgoulet  |  Actual Points:  16
 |  hours
 | Points:  medium
 |Sponsor:
-+-
Changes (by teor):

 * status:  needs_revision => needs_review
 * reviewer:   => dgoulet
 * points:   => medium
 * actualpoints:   => 16 hours


Comment:

 I think part of this bug was due to #18623, and the logging is being
 tracked in #18849.

 This leaves the fixes for #12538 and #18050:

 Replying to [comment:18 teor]:
 > I think I can update the patch so it cleanly answers the following
 questions:
 > * do we have a dirport open?

 get_options()->DirPort_set needs no changes.

 >   * if we have a dirport open, is the DirPort reachable?

 check_whether_dirport_reachable() returns 0 when we need to do a
 reachability check,
 and 1 if we've successfully done a reachability check, or if there's no
 reason to do a reachability check. It needs changes for clarity.

 004e1c27 refactors common parts of the ORPort and DirPort
 check_*_reachable functions into router_reachability_checks_disabled(),
 and updates the function comments. It disables OR reahcability checks when
 net_is_disabled(), for consistency with Dir reachability checks.

 #18851 updates the control-spec to clarify this behaviour.

 > * if the DirPort is reachable, do we want to advertise it?

 decide_to_advertise_dirport() needs no changes.

  * do we have an orport open?

 get_options()->ORPort_set needs no changes.

 > * would we answer begindir requests?

 directory_permits_begindir_requests() needs no changes, but should be used
 to set supports_tunnelled_dir_requests. (See 4dda75fc below.)

 This resolves a nasty edge case with bridges, which should always support
 begindir.

 >   * ~~if we would answer begindir requests,~~ is the ORPort reachable?

 check_whether_orport_reachable() is refactored in 004e1c27, see notes
 above

 > * if the ORPort is reachable, do we want to advertise begindir
 support?

 4dda75fc creates decide_to_advertise_begindir(), like
 decide_to_advertise_dirport(), which should clean up a lot of nasty edge
 cases:
 * directory authorities should always support and advertise begindir,
 * ORs with disabled networks shouldn't advertise support for begindir
 (possibly not an issue, but done for consistency with DirPort),
 * ORPort reachability is required for advertisement (possibly not an
 issue, but done for consistency with DirPort),
 * we now call router_should_be_directory_server() once per descriptor
 upload, which I hope satisfies nickm's request to call it infrequently
 (NM1).

 > As nickm notes in comment 11, I need to make sure we do the reachability
 and advertisability checks, store the results, and then use the results to
 answer these questions.

 NM1: This now happens once per descriptor upload, which means tor only
 logs when actually making the decision for each descriptor.

 > As dgoulet notes in 13 & 15, I should also remove redundant function
 calls.

 DG1: I don't believe there are any redundant function calls in this patch.

 Also, a28d98f4 adds the options used by these functions to the list of
 options we check to see if we need to rebuild our descriptor.

 Finally, we need to update our descriptor when we change our mind about
 advertising the dirport or begindir support due to accounting max. We
 didn't do this in the past for DirPort, and we do it every 18 hours
 anyway, so I'm splitting it off into #18852 in case we want to defer it to
 0.2.9 or later.

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


Re: [tor-bugs] #18846 [Core Tor/Tor]: Tor never shut up even the user set Log level ERROR.

2016-04-20 Thread Tor Bug Tracker & Wiki
#18846: Tor never shut up even the user set Log level ERROR.
--+---
 Reporter:  ikurua22  |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 The [https://www.torproject.org/docs/tor-manual.html.en#opt-quiet manual]
 also mentions this and offers the `--quiet` and `--hush` options.

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


Re: [tor-bugs] #18852 [Core Tor/Tor]: Directory mirrors should check accounting usage more frequently

2016-04-20 Thread Tor Bug Tracker & Wiki
#18852: Directory mirrors should check accounting usage more frequently
+
 Reporter:  teor|  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.2.8.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  must-fix-before-028-rc  |  Actual Points:
Parent ID:  #18616  | Points:
 Reviewer:  |Sponsor:
+
Changes (by teor):

 * keywords:   => must-fix-before-028-rc


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