Re: [tor-bugs] #26655 [Applications/Tor Browser]: onion button is wrong size and color

[Tor Bug Tracker & Wiki]

#26655: onion button is wrong size and color
+--
 Reporter:  arthuredelstein |  Owner:  antonela
 Type:  defect  | Status:
|  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201808  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * keywords:  ff60-esr, TorBrowserTeam201808R => ff60-esr,
 TorBrowserTeam201808


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

Re: [tor-bugs] #8228 [Applications/Tor Launcher]: Tor Launcher: Ensure we always have a Tor on 127.0.0.1:9050

[Tor Bug Tracker & Wiki]

#8228: Tor Launcher: Ensure we always have a Tor on 127.0.0.1:9050
---+---
 Reporter:  ioerror|  Owner:  brade
 Type:  enhancement| Status:  needs_information
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  needs-triage   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 Replying to [comment:7 traumschule]:
 > [https://www.torproject.org/docs/faq#WhereDidVidaliaGo Vidalia has been
 replaced with Tor Launcher]
 >
 > Is it currently possible on Mac / Windows to set SocksPort twice?

 Tor can open multiple SocksPorts on any platform.

 But if we make Tor Browser open 127.0.0.1:9050 on macOS and Windows, we'll
 interfere with everyone who runs a separate Tor on that port.

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

Re: [tor-bugs] #23588 [Core Tor/Tor]: Write fascist_firewall_choose_address_ls() and use it in hs_get_extend_info_from_lspecs()

[Tor Bug Tracker & Wiki]

#23588: Write fascist_firewall_choose_address_ls() and use it in
hs_get_extend_info_from_lspecs()
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:
  ipv6, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:  #23493   | Points:  1
 Reviewer:  teor |Sponsor:
-+-

Comment (by teor):

 We try not to duplicate code. I think your new patch is much simpler than
 fascist_firewall_choose_address_base(), because it doesn't actually choose
 addresses using the firewall rules on the client.

 Here's what I suggest:
 * If fascist_firewall_choose_address_base() doesn't work, then we should
 fix it.
 * If fascist_firewall_choose_address_ls() is calling
 fascist_firewall_choose_address_base() wrong, then we should fix the call.

 Also, I don't understand what you mean by:

 We compare
 addresses manually here as fascist_firewall_choose_address_base()
 doesn't always return addresses given from lspecs.

 Can you explain what behaviour you need from
 fascist_firewall_choose_address_base(), and what is happening instead?

 I think you might be expecting fascist_firewall_choose_address_base() to
 always return a valid address. But sometimes, there won't be any reachable
 addresses. If there aren't any reachable addresses, we need the 3-hop
 fallback code, which hasn't been written yet.

 But localhost (127.0.0.1 and ::1) should be reachable from the clients in
 the chutney networks. So I'm not sure why we're seeing this bug in
 chutney.

 Maybe some unit tests could help track it down.

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

Re: [tor-bugs] #26972 [Core Tor/Tor]: Create CI task to ensure that all Rust files have been formatted with rustfmt

[Tor Bug Tracker & Wiki]

#26972: Create CI task to ensure that all Rust files have been formatted with
rustfmt
+
 Reporter:  chelseakomlo|  Owner:  teor
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  rust, 036-proposed  |  Actual Points:
Parent ID:  #24629  | Points:
 Reviewer:  teor|Sponsor:
+
Changes (by teor):

 * status:  needs_revision => needs_review


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

Re: [tor-bugs] #26972 [Core Tor/Tor]: Create CI task to ensure that all Rust files have been formatted with rustfmt

[Tor Bug Tracker & Wiki]

#26972: Create CI task to ensure that all Rust files have been formatted with
rustfmt
+
 Reporter:  chelseakomlo|  Owner:  teor
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  rust, 036-proposed  |  Actual Points:
Parent ID:  #24629  | Points:
 Reviewer:  teor|Sponsor:
+

Comment (by teor):

 Please open a new ticket in 0.3.6 with a new branch containing the travis
 commit, so we remember to merge it when rustfmt 0.99.1 becomes stable.

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

Re: [tor-bugs] #26474 [Webpages/Website]: old experimental version 0.3.3.x https://www.torproject.org/docs/debian.html.en

[Tor Bug Tracker & Wiki]

#26474: old experimental version 0.3.3.x
https://www.torproject.org/docs/debian.html.en
---+--
 Reporter:  autodidactTor  |  Owner:  traumschule
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Webpages/Website   |Version:
 Severity:  Normal | Resolution:
 Keywords:  expert guide dead end  |  Actual Points:
Parent ID: | Points:
 Reviewer:  hiro   |Sponsor:
---+--
Changes (by teor):

 * status:  merge_ready => needs_review


Comment:

 I didn't see hiro review this patch on github or trac.

 "needs_review" means "this needs review before it is merged".
 "merge_ready" means "anyone with commit access can merge this".

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

Re: [tor-bugs] #26829 [Core Tor/Tor]: torspec: bandwidth file generators should write the file atomically

[Tor Bug Tracker & Wiki]

#26829: torspec: bandwidth file generators should write the file atomically
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  fast-fix, doc, tor-dirauth,  |  Actual Points:
  metrics, tor-bwauth, torspec   |
Parent ID:  #26851   | Points:
 Reviewer:  mikeperry|Sponsor:
-+-

Comment (by teor):

 Sorry for the typo, it's a torspec branch, not a torflow branch:

 https://github.com/teor2345/torspec/tree/ticket26829

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

Re: [tor-bugs] #27112 [Core Tor/Stem]: Decouple payload processing from pop/unpack + tune abstraction layers

[Tor Bug Tracker & Wiki]

#27112: Decouple payload processing from pop/unpack + tune abstraction layers
---+--
 Reporter:  dmr|  Owner:  dmr
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  client |  Actual Points:
Parent ID: | Points:
 Reviewer:  atagar |Sponsor:
---+--

Comment (by dmr):

 For the review, I thought it might help to indicate where I plan to go in
 the near future.

 Another method I want to define at the Cell level is `check_digest()` to
 be used for decryption, to correspond with the algorithm specified in
 section 6.1 //([[https://gitweb.torproject.org/torspec.git/tree/tor-
 spec.txt?id=2d33e5f2e95f068d783673865c08cf6d33c36614#n1548|spec
 reference]])//.

 I further want to define `encrypt()` and `decrypt()` methods at the Cell
 level, to make everything much more streamlined. While technically
 misnomers, these would each do the auxiliary functionality, too.

 So...
 In addition to actual encryption, `encrypt()` would:
 * apply the digest (see existing `apply_digest()`)
 * return a RawRelayCell

 And...
 In addition to actual decryption, `decrypt()` would:
 * check 'recognized'
 * check the digest (via NYI `check_digest()`)
 * return a RawRelayCell if still encrypted, or an unencrypted/unpacked
 RELAY Cell if fully decrypted/recognized

 (The above is an oversimplification, but I hope it helps illustrate my
 thoughts.)

 My commits are also a bit forward-looking for a few other things. You can
 see some early structure to make it possible to:
 * centralize ORPort reads/sends (demux/mux)
 * implement RelayCell subclasses (e.g. parsing/packing of decrypted body)
 * handle RELAY_EARLY similarly with a lot of code reuse after a mild bit
 of refactoring

 It's all still in a bit of flux, and I don't seem to be able to fully
 decouple my commits into entirely 1 specific goal - overall they're
 working toward a collective vision.

 === Next-steps summary:
 1. implement Cell `check_digest()`
 2. implement Cell `encrypt()`
 3. implement Cell `decrypt()`
 4/5(TBD - **and in different tickets**):
 * centralize ORPort reads/sends (demux/mux)
 * implement RelayCell subclasses (e.g. parsing/packing of decrypted body)

 Right now I'm leaning towards RelayCell subclasses for `4`.

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

Re: [tor-bugs] #27112 [Core Tor/Stem]: Decouple payload processing from pop/unpack + tune abstraction layers

[Tor Bug Tracker & Wiki]

#27112: Decouple payload processing from pop/unpack + tune abstraction layers
---+--
 Reporter:  dmr|  Owner:  dmr
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  client |  Actual Points:
Parent ID: | Points:
 Reviewer:  atagar |Sponsor:
---+--
Changes (by dmr):

 * status:  assigned => needs_review
 * reviewer:   => atagar


Comment:

 Here's my WIP changes PR:
 https://github.com/torproject/stem/pull/8
 branch head `e02cf0edb1292f67c87df95c7a406e5f94c1e7a8`

 I'd say it's mergeable - it's well-tested and I've weeded out a few
 failures I had in it.

 Along with changes to stem.client functional code, you'll see a tiny bit
 of exception/docstring/etc. cleanup.

 This should all be fairly well explained in commit messages, but feel free
 to ask any questions!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27112 [Core Tor/Stem]: Decouple payload processing from pop/unpack + tune abstraction layers

[Tor Bug Tracker & Wiki]

#27112: Decouple payload processing from pop/unpack + tune abstraction layers
---+--
 Reporter:  dmr|  Owner:  dmr
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:  client
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 A few goals here:
 - allow RELAY cells to be unpacked / popped without error, and passed to
 another level for decryption
 - put the encryption/decryption logic in cell.py, but require the crypto
 state be managed in Connection/Circuit/Stream layers

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

Re: [tor-bugs] #27101 [Applications/Tor Browser]: Error building tor in tor browser nightly builds

[Tor Bug Tracker & Wiki]

#27101: Error building tor in tor browser nightly builds
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by chelseakomlo):

 * cc: chelseakomlo (added)


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

Re: [tor-bugs] #27111 [Applications/Tor Browser]: TBA: Implement about:tor

[Tor Bug Tracker & Wiki]

#27111: TBA: Implement about:tor
--+--
 Reporter:  igt0  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #26531| Points:
 Reviewer:|Sponsor:
--+--
Changes (by igt0):

 * cc: igt0 (added)
 * parent:   => #26531


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27111 [Applications/Tor Browser]: TBA: Implement about:tor

[Tor Bug Tracker & Wiki]

#27111: TBA: Implement about:tor
--+--
 Reporter:  igt0  |  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:|
--+--
 Design:
 
https://trac.torproject.org/projects/tor/attachment/ticket/25696/24309%20-%20TBA%20-%20Welcome%20Page.png


 Onion circles implemeted in html + css:

 
https://trac.torproject.org/projects/tor/attachment/ticket/25696/onion_circles_pattern.html

 Onion circles implemented in svg:

 
https://trac.torproject.org/projects/tor/attachment/ticket/25696/onion_circles_pattern.py

 .png and .svg version were ready to be exported at
 ​​https://marvelapp.com/5981a4b/screen/44384308/handoff

 more info:
 https://trac.torproject.org/projects/tor/ticket/25696#comment:15

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

Re: [tor-bugs] #27053 [Core Tor/Stem]: Check controller's event error handling

[Tor Bug Tracker & Wiki]

#27053: Check controller's event error handling
---+--
 Reporter:  atagar |  Owner:  atagar
 Type:  defect | Status:  reopened
 Priority:  Very High  |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Major  | Resolution:
 Keywords:  controller |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dmr):

 Replying to [comment:11 atagar]:
 > As for the unit test failures I have a theory. When we run all our tests
 'run_tests.py --all' it performs our heaviest integ tests asynchronously
 along with our unit tests to speed things up. This tends to peg the CPU,
 possibly enough for the bumped sleep to still not be enough. Sleeping like
 that was a lazy hack anyway so replaced it with something better.
 >
 > https://gitweb.torproject.org/stem.git/commit/?id=c9cc0f5
 >
 > Does that do the trick?

 Still seeing unit-test failures. :(
 `tox -- -a` again.

 py27:
 {{{
 ==
 FAIL: test_event_listing_with_error
 --
 Traceback (most recent call last):
   File "/path/to/.tox/py27/local/lib/python2.7/site-
 packages/mock/mock.py", line 1305, in patched
 return func(*args, **keywargs)
   File "/path/to/test/unit/control/controller.py", line 663, in
 test_event_listing_with_error
 self.circ_listener.assert_called_once_with(CIRC_EVENT)
   File "/path/to/.tox/py27/local/lib/python2.7/site-
 packages/mock/mock.py", line 947, in assert_called_once_with
 raise AssertionError(msg)
 AssertionError: Expected 'mock' to be called once. Called 0 times.

 --
 Ran 33 tests in 0.308s

 FAILED (failures=1)
 }}}

 py35:
 {{{
 ==
 ERROR: test_event_listing_with_malformed_event
 --
 Traceback (most recent call last):
   File "/usr/lib/python3.5/unittest/mock.py", line 1159, in patched
 return func(*args, **keywargs)
   File "/path/to/test/unit/control/controller.py", line 688, in
 test_event_listing_with_malformed_event
 self.malformed_listener.assert_called_once()
   File "/usr/lib/python3.5/unittest/mock.py", line 585, in __getattr__
 raise AttributeError(name)
 AttributeError: assert_called_once

 --
 Ran 33 tests in 0.327s

 FAILED (errors=1)
 }}}

 Note that these are different tests!

 > Thanks Dave. Yup, you're right, this caused the lingering thread
 regression. Fixed.
 >
 > https://gitweb.torproject.org/stem.git/commit/?id=bc06836

 On the plus side, it does look like the lingering threads are gone for 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

[tor-bugs] #27110 [Applications/Tor Browser]: TBB segfaults on I/O error and silently fails to restart

[Tor Bug Tracker & Wiki]

#27110: TBB segfaults on I/O error and silently fails to restart
--+--
 Reporter:  traumschule   |  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:|
--+--
 After turning off an external drive, TBB 8.0a9 was started from, it
 segfaults:

 {{{
 Aug 12 13:47:17 x86 kernel: [1971770.627095] EXT4-fs warning (device
 dm-6): dx_probe:745: inode #102236259: lblock 0: comm Cache2 I/O: error -5
 reading directory block
 Aug 12 13:47:17 x86 kernel: [1971770.627185] EXT4-fs warning (device
 dm-6): dx_probe:745: inode #102236259: lblock 0: comm Cache2 I/O: error -5
 reading directory block
 Aug 12 13:47:29 x86 kernel: [1971782.202525] EXT4-fs error (device dm-6):
 ext4_find_entry:1437: inode #102236233: comm DOM Worker: reading directory
 lblock 0
 Aug 12 13:47:29 x86 kernel: [1971782.202548] EXT4-fs (dm-6): previous I/O
 error to superblock detected
 Aug 12 13:47:29 x86 kernel: [1971782.202696] Buffer I/O error on dev dm-6,
 logical block 0, lost sync page write
 Aug 12 13:47:59 x86 kernel: [1971812.552221] EXT4-fs error (device dm-6):
 ext4_find_entry:1437: inode #102236256: comm StreamT~s #1422: reading
 directory lblock 0
 Aug 12 13:47:59 x86 kernel: [1971812.552243] EXT4-fs (dm-6): previous I/O
 error to superblock detected
 Aug 12 13:47:59 x86 kernel: [1971812.552398] Buffer I/O error on dev dm-6,
 logical block 0, lost sync page write
 Aug 12 13:49:11 x86 kernel: [1971884.170995] EXT4-fs error (device dm-6):
 ext4_find_entry:1437: inode #101585396: comm Gecko_IOThread: reading
 directory lblock 0
 Aug 12 13:49:11 x86 kernel: [1971884.171023] EXT4-fs (dm-6): previous I/O
 error to superblock detected
 Aug 12 13:49:11 x86 kernel: [1971884.171266] Buffer I/O error on dev dm-6,
 logical block 0, lost sync page write
 Aug 12 13:50:36 x86 kernel: [1971969.303373] EXT4-fs warning (device
 dm-6): dx_probe:745: inode #102236259: lblock 0: comm Cache2 I/O: error -5
 reading directory block
 Aug 12 13:50:38 x86 kernel: [1971971.122734] Chrome_~dThread[20024]:
 segfault at 0 ip af213ca7 sp ae9c6080 error 6 in
 libxul.so[aed68000+6b9e000]
 Aug 12 13:50:38 x86 kernel: [1971971.123304] Chrome_~dThread[3967]:
 segfault at 0 ip af198ca7 sp ae94b080 error 6 in
 libxul.so[aeced000+6b9e000]
 Aug 12 13:50:38 x86 kernel: [1971971.297396] Chrome_~dThread[6821]:
 segfault at 0 ip af1f6ca7 sp ae9a6080 error 6 in
 libxul.so[aed4b000+6b9e000]
 }}}

 This is not unexpected although it could be handled to inform the user and
 close the virtual fs. The left behind process prevents the OS (debian
 buster) to remount the partition. (tor-browser_en-US and a swap partition
 sit on an external drive that wasn't turned on again before resume from
 suspend)

 /media/user/external/src is linked to /home/user/src

 {{{
 $ lsof|grep Browser
 gvfsd-met  5787user  mem   REG  254,2
 327681729380 /home/user/src/tor/tor-browser_en-US/Browser/.local/share
 /gvfs-metadata/home-2c0742ce.log
 gvfsd-met  5787user  mem   REG  254,6
 32768  102238628 /media/user/external/src/tor/tor-browser_en-
 US/Browser/.local/share/gvfs-metadata/uuid-57c3410d-3392-409c-a36d-
 bff9fd86bdfb-fb3931d1.log
 gvfsd-met  5787user  mem   REG  254,6
 37124  102239578 /media/user/external/src/tor/tor-browser_en-
 US/Browser/.local/share/gvfs-metadata/root
 gvfsd-met  5787user  mem   REG  254,6
 32768  102239579 /media/user/external/src/tor/tor-browser_en-
 US/Browser/.local/share/gvfs-metadata/root-5a546c95.log
 gvfsd-met  5787user  mem   REG  254,6
 2068  102238576 /media/user/external/src/tor/tor-browser_en-
 US/Browser/.local/share/gvfs-metadata/uuid-57c3410d-3392-409c-a36d-
 bff9fd86bdfb
 gvfsd-met  5787user  mem   REG  254,2
 20281729336 /home/user/src/tor/tor-browser_en-US/Browser/.local/share
 /gvfs-metadata/home
 gvfsd-met  5787user   10r  REG  254,6
 37124  102239578 /media/user/external/src/tor/tor-browser_en-
 US/Browser/.local/share/gvfs-metadata/root
 gvfsd-met  5787user   11u  REG  254,6
 32768  102239579 /media/user/external/src/tor/tor-browser_en-
 US/Browser/.local/share/gvfs-metadata/root-5a546c95.log
 gvfsd-met  5787user   15r  REG  254,2
 20281729336 /home/user/src/tor/tor-browser_en-US/Browser/.local/share
 /gvfs-metadata/home
 gvfsd-met  5787user   16u  REG  254,2
 327681729380 

Re: [tor-bugs] #20784 [Applications/Tor Browser]: TBB on OSX: "Something went wrong..." (was: Tor Browser not working)

[Tor Bug Tracker & Wiki]

#20784: TBB on OSX: "Something went wrong..."
--+---
 Reporter:  devildevine   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by traumschule):

 Any chance to get more out of this? Question that came to my mind: Has TBB
 a way to recognize inconsistencies in the file structure?

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

Re: [tor-bugs] #27053 [Core Tor/Stem]: Check controller's event error handling

[Tor Bug Tracker & Wiki]

#27053: Check controller's event error handling
---+--
 Reporter:  atagar |  Owner:  atagar
 Type:  defect | Status:  reopened
 Priority:  Very High  |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Major  | Resolution:
 Keywords:  controller |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by atagar):

 Thanks Dave. Yup, you're right, this caused the lingering thread
 regression. Fixed.

 https://gitweb.torproject.org/stem.git/commit/?id=bc06836

 As for the unit test failures I have a theory. When we run all our tests
 'run_tests.py --all' it performs our heaviest integ tests asynchronously
 along with our unit tests to speed things up. This tends to peg the CPU,
 possibly enough for the bumped sleep to still not be enough. Sleeping like
 that was a lazy hack anyway so replaced it with something better.

 https://gitweb.torproject.org/stem.git/commit/?id=c9cc0f5

 Does that do the trick?

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

Re: [tor-bugs] #8228 [Applications/Tor Launcher]: Tor Launcher: Ensure we always have a Tor on 127.0.0.1:9050 (was: Ensure we always have a Tor on 127.0.0.1:9050)

[Tor Bug Tracker & Wiki]

#8228: Tor Launcher: Ensure we always have a Tor on 127.0.0.1:9050
---+---
 Reporter:  ioerror|  Owner:  brade
 Type:  enhancement| Status:  needs_information
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  needs-triage   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by traumschule):

 * status:  new => needs_information
 * owner:  tbb-team => brade
 * component:  Applications/Tor Browser => Applications/Tor Launcher


Comment:

 [https://www.torproject.org/docs/faq#WhereDidVidaliaGo Vidalia has been
 replaced with Tor Launcher]

 Is it currently possible on Mac / Windows to set SocksPort twice?

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

Re: [tor-bugs] #10105 [Applications/Tor Browser]: start-tor-browser reports an error on start

[Tor Bug Tracker & Wiki]

#10105: start-tor-browser reports an error on start
--+---
 Reporter:  phobos|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-torbutton |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by traumschule):

 * status:  new => needs_information


Comment:

 Can this be closed? It is unclear which versions are affected.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27109 [Core Tor/Tor]: Tor 0.3.5.0-alpha-dev: [warn] connection_mark_unattached_ap_(): Bug: stream (marked at ../src/core/or/connection_edge.c:2605) sending two socks replies?

[Tor Bug Tracker & Wiki]

#27109: Tor 0.3.5.0-alpha-dev: [warn] connection_mark_unattached_ap_(): Bug: 
stream
(marked at ../src/core/or/connection_edge.c:2605) sending two socks
replies?
--+
 Reporter:  traumschule   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 This version is more verbose compared to 0.3.4.5-rc. Two messages stick
 out:

 > Aug 12 20:05:26.000 [warn] Saying "HTTP/1.0 405 Method Not
 Allowed\r\n\r\n"
 > Aug 12 20:05:26.000 [warn] connection_mark_unattached_ap_(): Bug: stream
 (marked at ../src/core/or/connection_edge.c:2605) sending two socks
 replies? (on Tor 0.3.5.0-alpha-dev )

 Accessing an offline site tor got loud showing the first line many times:

 > Aug 12 17:54:55.000 [notice] We tried for 15 seconds to connect to
 '[scrubbed]' using exit $  at 
 . Retrying on a new circuit.
 > Aug 12 17:55:55.000 [notice] Tried for 125 seconds to get a connection
 to [scrubbed]:80. Giving up.

 Since several days I see:

 > Aug 12 22:39:00.000 [notice] Bootstrapped 0%: Starting
 > Aug 12 22:39:01.000 [warn] Illegal nickname "$2947B29E843D@last-listed"
 in family line

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

Re: [tor-bugs] #27053 [Core Tor/Stem]: Check controller's event error handling

[Tor Bug Tracker & Wiki]

#27053: Check controller's event error handling
---+--
 Reporter:  atagar |  Owner:  atagar
 Type:  defect | Status:  reopened
 Priority:  Very High  |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Major  | Resolution:
 Keywords:  controller |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by dmr):

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


Comment:

 Replying to [comment:9 dmr]:
 > That said, I'll let you know if I happen to still see them now that
 you've submitted
 
[[https://gitweb.torproject.org/stem.git/commit/?id=ed6460df4a6fa8446a1e2923bddde652f5d91ed7|ed6460df4a6fa8446a1e2923bddde652f5d91ed7]].
 (About to rebase my work onto that.)

 Ok, just finished a test run on `master`
 
([[https://gitweb.torproject.org/stem.git/commit/?id=ed6460df4a6fa8446a1e2923bddde652f5d91ed7|ed6460df4a6fa8446a1e2923bddde652f5d91ed7]]).

 Based on the output (still failing) and past experience prior to this
 change, I'm going to reopen this ticket - something in these commits seems
 to be causing this.

 atagar, if you think it's something specific to my configuration / setup,
 let's discuss over IRC to nail this down.

 Ran:
 `tox -- -a`
 (which is basically `run_tests.py -a` on py27 and p35

 Here's snippet output...

 py27:
 {{{
 py27 runtests: commands[1] | python run_tests.py -a
 ==
  INITIALISING
 ==

   checking stem version... 1.6.0-dev
   checking tor version...  0.3.2.10
   checking python version...   2.7.13
   checking cryptography version... 2.2.2
   checking pynacl version...   1.2.1
   checking mock version... 2.0.0
   checking pyflakes version... 2.0.0
   checking pycodestyle version...  2.4.0
   checking for orphaned .pyc files...  done (0.0s)
   checking for unused tests... done (0.1s)
   importing test modules...done (0.1s)
   running pyflakes...  running
   running pycodestyle...   running

 ...
 Shutting down tor... done

 Threads lingering after test run:
   <_MainThread(MainThread, started 140094097536768)>
   
   
   
 69 TESTS WERE SKIPPED
 TESTING PASSED (23 seconds)
 }}}


 py35:
 {{{
 py35 runtests: commands[1] | python run_tests.py -a
 ==
  INITIALISING
 ==

   checking stem version... 1.6.0-dev
   checking tor version...  0.3.2.10
   checking python version...   3.5.3
   checking cryptography version... 2.2.2
   checking pynacl version...   1.2.1
   checking mock version... 1.0
   checking pyflakes version... 2.0.0
   checking pycodestyle version...  2.4.0
   checking for orphaned .pyc files...  done (0.0s)
   checking for unused tests... done (0.0s)
   importing test modules...done (0.3s)
   running pyflakes...  running
   running pycodestyle...   running

 ==
   UNIT TESTS
 ==

 ...
   control.controller...failed (0.58s)
 test_add_event_listener4 ms  [SUCCESS]
 test_attach_stream 0 ms  [SUCCESS]
 test_drop_guards   1 ms  [SUCCESS]
 test_event_description 7 ms  [SUCCESS]
 test_event_description_includes_all_events 0 ms  [SUCCESS]
 test_event_listing_with_error170 ms  [SUCCESS]
 test_event_listing_with_malformed_event  [FAILURE]
 test_events_get_received 103 ms  [SUCCESS]
 test_get_accounting_stats  1 ms  [SUCCESS]
 test_get_effective_rate1 ms  [SUCCESS]
 test_get_exit_policy   4 ms  [SUCCESS]
 test_get_exit_policy_if_not_relaying   0 ms  [SUCCESS]
 

Re: [tor-bugs] #27039 [Metrics/Onionoo]: Timestamps in graph history documents are incorrectly formatted

[Tor Bug Tracker & Wiki]

#27039: Timestamps in graph history documents are incorrectly formatted
-+-
 Reporter:  starlight|  Owner:  karsten
 Type:  defect   | Status:  merge_ready
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  irl  |Sponsor:
-+-
Changes (by irl):

 * status:  needs_review => merge_ready


Comment:

 Ok. I've run this on a local copy of the Onionoo data directory. For the
 deployment, I'll document the steps I took during testing, so we can just
 duplicate these:

 * Upload the JAR file that includes the `--rewrite-only` command.
 * Upload the new release's JAR and WAR files.
 * Wait for hourly updater to end.
 * Stop hourly updater and the web server.
 * Run `java -jar onionoo-6.2-1.16.0-rewrite.jar --rewrite-only`.
 * Remove the intermediate JAR file to avoid confusion.
 * Re-start the web server and the hourly updater.

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

Re: [tor-bugs] #27053 [Core Tor/Stem]: Check controller's event error handling

[Tor Bug Tracker & Wiki]

#27053: Check controller's event error handling
---+
 Reporter:  atagar |  Owner:  atagar
 Type:  defect | Status:  closed
 Priority:  Very High  |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Major  | Resolution:  fixed
 Keywords:  controller |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by dmr):

 Replying to [comment:8 atagar]:
 > We've sorted those when they cropped up in the past but presently I'm
 not seeing it. If you get a reliable repro then a patch would be great.
 That said, shouldn't be related to this ticket.

 They were reproducing pretty reliably at
 
[[https://gitweb.torproject.org/stem.git/commit/?id=b557d09c2721858785b6310f331e29c06b76887f|b557d09c2721858785b6310f331e29c06b76887f]]
 and later **(my commits)**, and not at
 
[[https://gitweb.torproject.org/stem.git/commit/?id=d1284e6d0301de59ddf286b5e799dee50a5d4a5a|d1284e6d0301de59ddf286b5e799dee50a5d4a5a]]
 (right before the WIP test-repo commit). I'd say: either the aformentioned
 test would fail OR the threads would linger - I never saw a case where
 neither happened.

 That said, I'll let you know if I happen to still see them now that you've
 submitted
 
[[https://gitweb.torproject.org/stem.git/commit/?id=ed6460df4a6fa8446a1e2923bddde652f5d91ed7|ed6460df4a6fa8446a1e2923bddde652f5d91ed7]].
 (About to rebase my work onto 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] #25885 [Core Tor/Tor]: count_acceptable_nodes() would be more accurate using node_has_preferred_descriptor()

[Tor Bug Tracker & Wiki]

#25885: count_acceptable_nodes() would be more accurate using
node_has_preferred_descriptor()
--+
 Reporter:  nickm |  Owner:  neel
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #27107 [Core Tor/sbws]: Transition plan from Torflow to sbws

[Tor Bug Tracker & Wiki]

#27107: Transition plan from Torflow to sbws
---+-
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #25925 | Points:
 Reviewer: |Sponsor:
---+-
Changes (by juga):

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


Old description:

> Ticket for the tasks related to get sbws in production.
> These would include work we have been already doing, but probably we
> should need to add more tasks:
>
> 1. Get sbws in Debian (#26848)
> 2. Check that the bandwidth files results are similar to Torflow:
>We have being doing this in https://github.com/pastly/simple-bw-
> scanner/issues/182, though is growing.
>So far we checked:
>- sbws raw results compared to torflow: shape is quite different
>Measured from the same box in different days:
>- sbws raw results compared to sbws scaled: big relays get bigger bw,
> but shape still different from torflow
>- sbws raw results compared to sbws raw results having a bigger time
> for downloading: they're similar
>- sbws raw results compared to sbws raw results resting the rtt from
> the dowload time: they're similar
>- implement parsing Torflow raw files
>- sbws raw results compared to Torflow results: they are similar, so
> it is the scaling method which makes results different
>
> 2.1 i'd create child tickets for the WIP
>- implement torflow scaling
>- check sbws using torflow scaling compare to Torflow
>- change specification
>- ...
>
> 3. Get one bwauth to run sbws
> 4. Archive bw files (#21378)
> 5. Compare Tor bw files from bwauths running Torflow and from the one
> running sbws
> 6. ...

New description:

 Ticket for the tasks related to get sbws in production.
 These would include work we have been already doing, but probably we
 should need to add more tasks:

 1. Get sbws in Debian (#26848)
 2. Check that the bandwidth files results are similar to Torflow:
We have being doing this in https://github.com/pastly/simple-bw-
 scanner/issues/182, though is growing.
So far we checked:
   - sbws raw results compared to torflow: shape is quite different
   - sbws raw results compared to sbws scaled: big relays get bigger bw,
 but shape still different from torflow
   - sbws raw results compared to sbws raw results having a bigger time for
 downloading: they're similar
   - sbws raw results compared to sbws raw results resting the rtt from the
 dowload time: they're similar
   - implement parsing Torflow raw files
   - sbws raw results compared to Torflow results: they are similar, so it
 is the scaling method which makes results different
 3. i'd create child tickets for the WIP
 - implement torflow scaling
 - check sbws using torflow scaling compare to Torflow
 - change specification
 - ...
 4. Get one bwauth to run sbws
 5. Archive bw files (#21378)
 6. Compare Tor bw files from bwauths running Torflow and from the one
 running sbws
 7. ...

 Edit:
 - formatting

--

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

Re: [tor-bugs] #27108 [Core Tor/sbws]: Implement torflow's scaling method in sbws

[Tor Bug Tracker & Wiki]

#27108: Implement torflow's scaling method in sbws
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #27107 | Points:
 Reviewer: |Sponsor:
---+-
Changes (by juga):

 * status:  assigned => needs_review


Comment:

 https://github.com/pastly/simple-bw-scanner/pull/243

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

Re: [tor-bugs] #27096 [Core Tor/Tor]: Stop relying on $HOME being set in the unit tests

[Tor Bug Tracker & Wiki]

#27096: Stop relying on $HOME being set in the unit tests
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-test  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by rl1987):

 * status:  new => needs_review


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

Re: [tor-bugs] #27096 [Core Tor/Tor]: Stop relying on $HOME being set in the unit tests

[Tor Bug Tracker & Wiki]

#27096: Stop relying on $HOME being set in the unit tests
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-test  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by rl1987):

 https://github.com/torproject/tor/pull/272

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27108 [Core Tor/sbws]: Implement torflow's scaling method in sbws

[Tor Bug Tracker & Wiki]

#27108: Implement torflow's scaling method in sbws
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #27107
   Points: |   Reviewer:
  Sponsor: |
---+-
 As commented in https://github.com/pastly/simple-bw-
 scanner/issues/182#issuecomment-410703335

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27107 [- Select a component]: Transition plan from Torflow to sbws

[Tor Bug Tracker & Wiki]

#27107: Transition plan from Torflow to sbws
--+-
 Reporter:  juga  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  sbws 1.0 (MVP must)
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #25925
   Points:|   Reviewer:
  Sponsor:|
--+-
 Ticket for the tasks related to get sbws in production.
 These would include work we have been already doing, but probably we
 should need to add more tasks:

 1. Get sbws in Debian (#26848)
 2. Check that the bandwidth files results are similar to Torflow:
We have being doing this in https://github.com/pastly/simple-bw-
 scanner/issues/182, though is growing.
So far we checked:
- sbws raw results compared to torflow: shape is quite different
Measured from the same box in different days:
- sbws raw results compared to sbws scaled: big relays get bigger bw,
 but shape still different from torflow
- sbws raw results compared to sbws raw results having a bigger time
 for downloading: they're similar
- sbws raw results compared to sbws raw results resting the rtt from
 the dowload time: they're similar
- implement parsing Torflow raw files
- sbws raw results compared to Torflow results: they are similar, so it
 is the scaling method which makes results different

 2.1 i'd create child tickets for the WIP
- implement torflow scaling
- check sbws using torflow scaling compare to Torflow
- change specification
- ...

 3. Get one bwauth to run sbws
 4. Archive bw files (#21378)
 5. Compare Tor bw files from bwauths running Torflow and from the one
 running sbws
 6. ...

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

Re: [tor-bugs] #26992 [Core Tor/Tor]: Add intro point IPv6 address to service descriptors

[Tor Bug Tracker & Wiki]

#26992: Add intro point IPv6 address to service descriptors
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:
  ipv6, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:  #23576   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by asn):

 * status:  needs_review => needs_revision


Comment:

 Reviewed as part of #23576.

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

Re: [tor-bugs] #23576 [Core Tor/Tor]: Make service_intro_point_new() take a node instead of an extend_info

[Tor Bug Tracker & Wiki]

#23576: Make service_intro_point_new() take a node instead of an extend_info
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:
  ipv6, 034-triage-20180328, |
  034-removed-20180328, fast-fix |
Parent ID:  #23493   | Points:  1
 Reviewer:  asn  |Sponsor:
-+-
Changes (by asn):

 * status:  needs_review => needs_revision


Comment:

 This looks good and I like the code simplification!

 I left a few nitpicks on the PR that you might want to handle.

 Also, should we try to rebase this so that we can see the appveyor green
 checkmark (now that #26986 got 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] #27066 [Core Tor/Tor]: circuit_build_times_update_alpha(): Bug: Could not determine largest build time

[Tor Bug Tracker & Wiki]

#27066: circuit_build_times_update_alpha(): Bug: Could not determine largest 
build
time
---+---
 Reporter:  cstest |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.5.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.3.3.9
 Severity:  Normal | Resolution:
 Keywords:  034-backport 033-backport  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by cstest):

 Prior to CBT bug line here are warning lines that happened after enabling
 v3 domains.


 {{{
 Aug 07 00:02:15.000 [notice] Our hidden services received 41808 v2 and 18
 v3 INTRODUCE2 cells and attempted to launch 42259 rendezvous circuits.
 (this is almost exact time when I have enabled v3 domains and for several
 hours both v3 and v2 domains were working together)


 Aug 07 03:01:23.000 [warn] Error launching circuit to node
 $E0EAA536856FBD3C3AB46C2BAA398E7CDFDAFF5D~as44194a36s01 at 77.87.50.6 for
 service v2domain...
 Aug 07 03:01:23.000 [warn] Error launching circuit to node
 $B247BA9E0AEA93E6D7BF4080CFBB964034AF2B28~kitten2 at 163.172.218.10 for
 service v2domain...
 Aug 07 03:01:23.000 [warn] Error launching circuit to node
 $C793A33F28826D1F184504312C668EA8157AEF28~Unnamed at 217.182.95.221 for
 service v2domain...
 Aug 07 03:01:23.000 [warn] Error launching circuit to node
 $71DA45C2AF1551F32CA83E2AD2D5ADA684505391~Unnamed at 34.241.138.212 for
 service v2domain...
 Aug 07 03:01:23.000 [warn] Error launching circuit to node
 $F3FA0D45D35E987484848345F8D92AB1D883889B~Hermes at 86.29.190.220 for
 service v2domain...
 Aug 07 03:01:23.000 [warn] Error launching circuit to node
 $4204C1B166CCE784CF38B02E4A0C94640A2BECA2~TheEpTic2 at 51.15.51.36 for
 service v2domain...
 Aug 07 03:01:23.000 [warn] Error launching circuit to node
 $DB510E2AA40A462AD77DB83617F6F340E234D952~Unnamed at 206.189.24.66 for
 service v2domain...
 Aug 07 03:01:23.000 [warn] Error launching circuit to node
 $74D6D1E8BF5159066768F48C1EA4951C9C97BEF9~lara at 148.251.42.164 for
 service v2domain...
 (above lines are just for one v2 domain but they have been repeated for
 other v2 domains too)


 Aug 07 03:01:41.000 [notice] Your network connection speed appears to have
 changed. Resetting timeout to 60s after 18 timeouts and 409 buildtimes.
 Aug 07 03:01:43.000 [warn] Failed to find node for hop #1 of our path.
 Discarding this circuit.
 Aug 07 03:01:44.000 [notice] Our circuit 0 (id: 641032) died due to an
 invalid selected path, purpose Hidden service: Establishing introduction
 point. This may be a torrc configuration issue, or a bug.
 (all lines in torrc are simple except one line "MaxClientCircuitsPending
 256")


 Aug 07 03:12:39.000 [notice] Your Guard loki
 ($5A6451D4E4B4FFDE0B2682D8D8DAA0D10A500066) is failing more circuits than
 usual. Most likely this means the Tor network is overloaded. Success
 counts are 184/267. Use counts are 132/132. 184 circuits completed, 0 were
 unusable, 0 collapsed, and 2 timed out. For reference, your timeout cutoff
 is 463 seconds.
 Aug 07 03:13:43.000 [warn] Giving up launching first hop of circuit to
 rendezvous point
 $5FA794BF301AF35E4AED185E939CBA9D2CFC2360~$5FA794BF301AF35E4A at
 192.42.132.106 for service v2
 Aug 07 03:13:43.000 [warn] Giving up launching first hop of circuit to
 rendezvous point
 $7961C9991F022C8A363FD440CA395D47DB5D44D5~$7961C9991F022C8A36 at
 51.254.35.151 for service v2..
 Aug 07 03:13:43.000 [warn] Giving up on launching a rendezvous circuit to
 $DBAD17D706E2B6D5D917C2077961750513BDF879~ at 109.236.90.209 for hidden
 service v3
 Aug 07 03:13:43.000 [warn] Giving up on launching a rendezvous circuit to
 $C13D13DE33C2DAB4AF849014ECAB962A328D6806~ at 85.10.216.118 for hidden
 service v3
 Aug 07 03:13:44.000 [warn] Giving up on launching a rendezvous circuit to
 $372082F3E01DE6A6333D30329C6903A19D0E8E87~ at 176.193.113.234 for hidden
 service v3
 ("giving up" lines were repeating aprox 50 times for the same 4-5 v3
 domains and 2 v2 domains)


 Aug 07 03:15:31.000 [warn] Failed to find node for hop #1 of our path.
 Discarding this circuit.
 Aug 07 03:15:37.000 [notice] Extremely large value for circuit build
 timeout: 157s. Assuming clock jump. Purpose 14 (Measuring circuit timeout)
 Aug 07 03:15:37.000 [notice] Extremely large value for circuit build
 timeout: 147s. Assuming clock jump. Purpose 14 (Measuring circuit timeout)
 Aug 07 03:15:37.000 [notice] Extremely large value for circuit build
 timeout: 157s. Assuming clock jump. Purpose 14 (Measuring circuit timeout)
 Aug 07 03:15:37.000 [notice] Extremely large value for circuit build
 timeout: 154s.