Re: [tor-bugs] #20468 [Applications/Tor Launcher]: TorBrowser using a secert HASHEDPASSWORD

[Tor Bug Tracker & Wiki]

#20468: TorBrowser using a secert HASHEDPASSWORD
---+---
 Reporter:  cypherpunks|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by gk):

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


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

Re: [tor-bugs] #20450 [Applications/Tor Browser]: Add extra Referer protection when security slider is higher?

[Tor Bug Tracker & Wiki]

#20450: Add extra Referer protection when security slider is higher?
--+---
 Reporter:  lunar |  Owner:  tbb-team
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 Marking this as a duplicate of #17228. See especially
 comment:3:ticket:17228 for a proposol how to adjust Referer settings
 depending on security slider level. However, my comment:4:ticket:17228
 still stands.

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

Re: [tor-bugs] #17228 [Applications/Tor Browser]: Consideration for disabling referrers within TBB

[Tor Bug Tracker & Wiki]

#17228: Consideration for disabling referrers within TBB
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * cc: lunar (added)


Comment:

 Marking #20450 as duplicate. See http://feeding.cloud.geek.nz/posts
 /tweaking-referrer-for-privacy-in-firefox/ for a good overview of possible
 options for tweaking Referer preferences.

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

Re: [tor-bugs] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

[Tor Bug Tracker & Wiki]

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Here's a fresh bug report: synchronizing relay descriptors takes a few
 ''hours'' on average on my laptop, and I think I know why.  Whenever we
 append to an existing file in `recent/`, we copy the entire file content
 to a temporary file, append the new content there, and then rename.  And
 we do that for every single server descriptor or extra-info descriptor we
 receive.  That is bad for two reasons.  First reason is that it obviously
 doesn't scale, with some sync runs taking 4 hours or longer.  Second
 reason is that files in `recent/` shouldn't change after they're included
 in `index.json` (with the inglorious exception of Torperf measurements),
 which is why we should append all descriptors to a temporary file and
 rename when we're sure we're done.  See also
 `ArchiveWriter.cleanUpRsyncDirectory()` where we're renaming temporary
 files to destination files at the very end of the update run.

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

Re: [tor-bugs] #13052 [Applications/Tor Browser]: Torbrowser window size/rendering issue

[Tor Bug Tracker & Wiki]

#13052: Torbrowser window size/rendering issue
-+-
 Reporter:  oierror  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-fingerprinting-   |  Actual Points:
  resolution |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-usability => tbb-usability, tbb-fingerprinting-resolution
 * severity:   => Normal


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

Re: [tor-bugs] #20458 [Core Tor/Tor]: Integration tests should be run locally before committing code changes

[Tor Bug Tracker & Wiki]

#20458: Integration tests should be run locally before committing code changes
--+
 Reporter:  chelseakomlo  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  test, doc |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by rubiate):

 It may be worth noting that running `make test-network-all` requires a
 later version of automake. The minimum required version to build tor and
 run its tests is 1.11 but test-network-all needs 1.13 because it needs
 test-driver.

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

Re: [tor-bugs] #18175 [Applications/Tor Browser]: Maximizing Tor Browser on Windows and restarting/doing New Identity leads to non-rounded window size (was: Updating a maximized Tor Browser to 5.5 on

[Tor Bug Tracker & Wiki]

#18175: Maximizing Tor Browser on Windows and restarting/doing New Identity 
leads
to non-rounded window size
---+--
 Reporter:  gk |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-fingerprinting-resolution  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gk):

 * priority:  Medium => High
 * keywords:  tbb-fingerprinting-resolution tbb-5.5-regression => tbb-
 fingerprinting-resolution


Comment:

 That's actually a more generic problem: even if I maximize the browser
 window and then either restart or hit `New Identity` I get those results.
 And this is not Tor Browser 5.5 related.

 It does not get fixed by #19459 either (I tested v11) even though the new
 dimensions look more like 990x589 or 998x591.

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

Re: [tor-bugs] #20451 [Obfuscation/meek]: The communication stream of managed proxy '/usr/bin/meek-client' is 'closed'

[Tor Bug Tracker & Wiki]

#20451: The communication stream of managed proxy '/usr/bin/meek-client' is
'closed'
--+-
 Reporter:  tagener-noisu |  Owner:  dcf
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by tagener-noisu):

 Replying to [comment:3 dcf]:
 > You might have to report this bug to the maintainer of the AUR package.
 >
 > What do you get when you run this command?
 > {{{
 > TOR_PT_MANAGED_TRANSPORT_VER=1 TOR_PT_CLIENT_TRANSPORTS=meek /usr/bin
 /meek-client --log meek-client.log
 > }}}
 >
 > It should produce on the terminal:
 > {{{
 > VERSION 1
 > CMETHOD meek socks5 127.0.0.1:38561
 > CMETHODS DONE
 > }}}
 >
 > meek-client.log should contain at least:
 > {{{
 > 2016/10/25 15:42:28 listening on 127.0.0.1:38561
 > }}}
 >
 > (Of course the port number may be different.)

 Everything is ok, I've got this:
 {{{
 VERSION 1
 CMETHOD meek socks5 127.0.0.1:44461
 CMETHODS DONE
 }}}
 And a log file here:
 {{{
 2016/10/26 15:55:44 listening on 127.0.0.1:44461
 2016/10/26 15:55:52 got signal interrupt
 2016/10/26 15:55:52 done
 }}}
 I interrupted it with C-c.

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

Re: [tor-bugs] #19969 [Core Tor/Tor]: tor client does not immediately open new circuits after standby

[Tor Bug Tracker & Wiki]

#19969: tor client does not immediately open new circuits after standby
--+
 Reporter:  weasel|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.6
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 In 0.2.8, we redesigned the timer table.
 And we redesigned how we retrieve new consensuses when our consensus has
 expired.
 Maybe we need to tweak one or more of these things.

 I think we implemented expotential backoff in 0.2.9. Not sure if that will
 make it better or worse.

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

Re: [tor-bugs] #4810 [Applications/Tor Browser]: Weird screen sizes reported by Panopticlick

[Tor Bug Tracker & Wiki]

#4810: Weird screen sizes reported by Panopticlick
---+---
 Reporter:  erikd  |  Owner:  mikeperry
 Type:  enhancement| Status:
   |  needs_revision
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-fingerprinting-resolution  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by trippylizard):

 Why is this ticket still open 5 years after being reported, given an
 utterly sensible solution (snap reported desktop resolution to one of two
 values that will fit client window) has been proposed?

 Why is there not consensus that reporting a desktop resolution that no
 physical monitor has ever has is not a serious flaw, resorting to a deeply
 suspect argument 'we only need tor browser bundle users to be
 indistinguisable from each other'. The proposed fix would maintain that
 ability, while simultaneously removing the ability for a few lines of
 javascript to pick out a tor browser user from a non tor browser user.

 Seriously guys, it would take 5 minutes to patch this. Change
 getDesktopWidth() from { return window.width; } to { return window.width <
 1920 && window.height < 1080 ? 1920 : 2880; } and getDesktopHeight() from
 { return window.height; } to { return window.width < 1920 && window.height
 < 1080 ? 1080 : 1800; }

 See? Simple.

 So stop bloody prevaricating and arguing about this and just do it, or
 explain why it's taking so long.

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

Re: [tor-bugs] #19459 [Applications/Tor Browser]: Write (C++) patch for window resizing parts

[Tor Bug Tracker & Wiki]

#19459: Write (C++) patch for window resizing parts
-+-
 Reporter:  gk   |  Owner:
 |  arthuredelstein
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton-conversion,|  Actual Points:
  TorBrowserTeam201610   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-

Comment (by gk):

 Okay, this looks mostly good to me I think. Two comments to the C++ code

 1) We might want to add an `NS_ENSURE_STATE(shellWindow);` after and an
 `NS_ENSURE_STATE(mPrimaryContentShell);` before
 `nsCOMPtr
 shellWindow(do_QueryInterface(mPrimaryContentShell));`. There is code that
 does this in r306252 and this seems reasonable to me.

 2) We might want to check the return value of `GetAvailScreenSize()`
 called in `ResizeToBoundedDimensions()` as well (as is done at the other
 place you use it)? Not sure what should happen in case this fails, though.

 Regarding my testing: it looks good on all machines I tried it. I
 encounerted an issue I mentioned in comment:18 (1)) again but after
 digging a bit deeper it seems older versions have this problem, too. So,
 no regression at least. This is #18175 fwiw.

 I think we can leave the debugging statements in for now.

 The Torbutton patch looks good to me as well. Nice work!

 mcs/brade could you have a look at the C++ portion 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] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

[Tor Bug Tracker & Wiki]

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 1. Valid points about file-io.  My local runs identified the network as
 the bottleneck rather than file-io when doing an initial sync to an empty
 CollecTor instance.  Subsequent runs were way shorter.  The mirror as a
 running Collector instance needed only 20 min on the first sync-run and
 now way less (3 to 1 min).
  But anyway, it's true that some of the copying could and should be
 reduced.

 2. Ideally index.json should be a true picture of 'recent', but actually,
 it'll always only be a snapshot, even if it's updated with each change,
 b/c then the syncing instance cannot update index.json continuously.  So,
 CollecTor's sync should accommodate the possible differences, which it
 does currently, I think.


 How to proceed?
 Do you think this is a halt to the release?
 I think it can be released as is, because the current set-up increases
 descriptor availability a lot and is tested.
 I'm wary of tuning it now without a release delay.  And, regarding both
 writing and parsing there are duplicate and trip-licate implementations in
 the code-base, which should be streamlined and can be tuned in that
 process.

 I'd suggest to release and have new tickets (which will be part of the
 other tickets for planning the streamlining, modularization, and other
 improvements):
 1. streamline writing all over the code-base with an emphasis on reducing
 file-io for CollecTor;
 2. Make index.json as close to the current state as necessary and
 feasible, which includes pondering about how accurate it should be with
 the given use-cases. Maybe have a clean-up module before index-run.

 Is that an ok plan?

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

Re: [tor-bugs] #20410 [Core Tor/Tor]: Tor master breaks bridge clients

[Tor Bug Tracker & Wiki]

#20410: Tor master breaks bridge clients
-+
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Core Tor/Tor |Version:  Tor: 0.3.0.0-alpha-dev
 Severity:  Major| Resolution:  fixed
 Keywords:  crash bridge-client  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

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


Comment:

 Applied; thanks, all!

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

Re: [tor-bugs] #20410 [Core Tor/Tor]: Tor master breaks bridge clients

[Tor Bug Tracker & Wiki]

#20410: Tor master breaks bridge clients
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.0.0-alpha-
 |  dev
 Severity:  Major| Resolution:  fixed
 Keywords:  crash bridge-client  |  Actual Points:  .2
  TorCoreTeam201610  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  crash bridge-client => crash bridge-client TorCoreTeam201610
 * actualpoints:   => .2
 * milestone:   => Tor: 0.3.0.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] #20468 [Applications/Tor Launcher]: TorBrowser using a secert HASHEDPASSWORD

[Tor Bug Tracker & Wiki]

#20468: TorBrowser using a secert HASHEDPASSWORD
---+---
 Reporter:  cypherpunks|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by mcs):

 * cc: mcs (added)


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

Re: [tor-bugs] #20204 [Applications/Tor Browser]: Windows don't drag on macOS Sierra

[Tor Bug Tracker & Wiki]

#20204: Windows don't drag on macOS Sierra
-+-
 Reporter:  arlolra  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff52-esr-will-have, tbb-usability,   |  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Woah, that's subtle, good find. I tested a build with it and it fixes the
 issue for me. I applied the fixup patch to tor-browser-45.4.0esr-6.5-1
 (commit a6b4bb9a9d2769e8be110f2f0486b9ec74882575).

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

Re: [tor-bugs] #20462 [Core Tor/Tor]: Make test failures/bugs on Raspberry Pi 3

[Tor Bug Tracker & Wiki]

#20462: Make test failures/bugs on Raspberry Pi 3
--+
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor:
  |  0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression TorCoreTeam201610  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * keywords:   => regression TorCoreTeam201610


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

Re: [tor-bugs] #20460 [Core Tor/Tor]: tortls test failures with recent LibreSSL (OpenBSD -current)

[Tor Bug Tracker & Wiki]

#20460: tortls test failures with recent LibreSSL (OpenBSD -current)
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.0-alpha-dev
 Severity:  Normal| Resolution:
 Keywords:  libressl openbsd  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 I think the right fix is to have the tests say "ECDHE" instead; they were
 probably supposed to in the first place.

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

Re: [tor-bugs] #20458 [Core Tor/Tor]: Integration tests should be run locally before committing code changes

[Tor Bug Tracker & Wiki]

#20458: Integration tests should be run locally before committing code changes
--+
 Reporter:  chelseakomlo  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  test, doc |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by chelseakomlo):

 Ok, I see. It looks like we have `make test-full` and `make test-full-
 online` which runs all tests. This is in WritingTests.md, but maybe we can
 make this info consistent in CodingStandards.md 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] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

[Tor Bug Tracker & Wiki]

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Well, the sync runs don't take just 3 or 20 minutes here, but many hours.
 I could imagine that it's the backup daemon trying to capture all file
 system changes for the next backup, or something.  I could imagine that
 similar things can happen on servers.  The issue is that the update run
 cannot start if the sync run keeps running, and that means we'll lose
 data.  I'm afraid we can't ship this yet.

 I don't understand your reasoning about `index.json` not being a true
 picture of `recent/`.  We're skipping `*.tmp` files when creating that
 file, and we always append to `.tmp` and only rename to the destination
 file when we're sure the file won't change anymore.  Where does that get
 inaccurate?

 I'd rather want to change the sync code to do the same as the update code.
 I can give that a try if you don't want to touch that code anymore.

 By the way, we'll need to merge #20380 before putting out the release.
 And I'd want to start a test run over night before releasing, so the
 release cannot happen today anyway. :(

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

Re: [tor-bugs] #16485 [Applications/Tor Browser]: Firefox bug - Unrecognized storage name 'null' in about:cache URL (was: about:cache does not show anything in Tor Browser based on ESR 38)

[Tor Bug Tracker & Wiki]

#16485: Firefox bug - Unrecognized storage name 'null' in about:cache URL
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by bugzilla):

 Replying to [ticket:16485 gk]:
 > Opening `about:cache` does not show any entries.
 It's good. But not all entries are `Private`, even `Anonymous` ;)
 > The reason seems to be that `Private` is unchecked. Doing that and
 trying to update the cache is resulting in an error:
 > {{{
 > Unrecognized storage name 'null' in about:cache URL
 > }}}
 That's because URL is `about:cache?storage=null&context=p,`. `Update`
 works if it's not disabled by NoScript.
 > This is actually a Mozilla bug as this happens in a vanilla Firefox as
 well. But now clicking on `Back to overview` does give us the cache
 entries as `Private` is checked.
 Hmm, still an issue for ESR45, but not so easy reproducible.
 STR was found for blocked by NoScript page: check `Private`, allow page
 and get `about:cache?storage=null&context=`.
 So, it seems only users with weird NoScript config, like in TBB, are
 affected, because Mozilla knows nothing about it. But the only one ticket
 with "Unrecognized storage" is great:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1074485.
 As this ticket is about usability: `about:config` is neither usable, nor
 reliable, e.g. bugs 469677, 633747, 927919, etc.

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

Re: [tor-bugs] #20380 [Metrics/CollecTor]: Expand INSTALL.md to a more complete operator's guide

[Tor Bug Tracker & Wiki]

#20380: Expand INSTALL.md to a more complete operator's guide
---+-
 Reporter:  karsten|  Owner:
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Replying to [comment:9 karsten]:
 > ...
 > A few thoughts:
 >
 >  - When you say that closer monitoring will be needed when disk space
 drops below a given number, do you mean 200G or 20G or a different number?

 I was referring to the disk space available when starting,  i.e. very
 close to 150G and logging to the same disk requires more attention than a
 terabyte setup.  Hmm, but if that is confusing just discard it.

 >
 >  - We shouldn't add new section headers easily.  The chosen section
 headers and even paragraphs in this document (will) have equivalents in
 the other operator's guides for other metrics tools.  If we want to add
 new sections, we'll also have to add those sections to the other manuals.
 The current sections are:
 >
 > {{{
 > $ grep "^#" INSTALL.md
 > # CollecTor Operator's Guide
 > ## Setting up the host
 > ## Setting up the service
 > ## Maintaining the service
 > }}}
 >

 It's important to have a consistent structure, but it would be helpful for
 readers to have sub-headings, which are application dependent.  Scrolling
 through a document with only generic headings when looking for particular
 information takes longer (of course, there is a search).
 So, maybe keep the top level consistent and allow for application
 dependent headlines below?

 >  - (continued) What other sections or even subsections should we
 include, and what instructions would go into those vs. the existing
 sections?

 I see two more sections.
 * 'Planning the Service' contrasts those sections giving a to-do list.
 People running instances will have different needs that can be better
 covered this way.
 * and even more important, a section 'Bootstrapping' or similar.  What
 data to download before a first run etc.  Again this is not a to-do list
 as it depends what data should be processed.

 >
 > > The idea behind my changes is that I think the service shouldn't be
 run from the unpacked tar
 > > folder.  The tar contains a development environment, so the jar would
 disappear after 'ant clean' or changed etc.
 > > The runtime directory should only contain files that are really
 necessary for the application or which were created by the application.
 > > Hope this doesn't make the description too complicated.
 >
 > Yes, makes sense, let's change that.  There are still a few paths left
 where we refer to files in `collector-/` and where we should tell
 the user to copy those files to the working directory and run them from
 there.  I can update those places.
 >
 > > I also would like have even less description of tools from the OS,
 because such things should be decided by the operator.
 >
 > Which parts would that include?  The crontab, `@reboot`, `screen`, etc.?
 Can you make a list?

 When we avoid mentioning any such tools and methods, we avoid getting out
 of date and stay platform independent.  People operating servers have
 their favorite tools for and know what to do when told

 * run this script every three days
 * provide an http server for serving data and files in folders X, Y, Z.
 * for continuous operation ensure start-up on reboot and
 * monitoring of logs as well as running service is important
 etc.

 CollecTor does not depend on apache or crontab only the services provided
 by them.  Even the suggested install of openjdk could be left out.  Also
 apt-get.  Attempt of a list:

 * apt-get
 * apache2
 * crontab
 * gpg
 * openjdk, only Java 7
 * screen
 * ...

 Another thing would be to use `/recent` and similar instead of
 the default choices provided.  So, it is clear which option is referred
 to.

 The backup recommendation I would also leave out.  It depends on the setup
 and the kind of data collected.  Or, move it to 'Planning the service'?

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

Re: [tor-bugs] #19869 [Core Tor/Tor]: tor_fragile_assert() in evdns_get_orig_address() on tor-0.2.9-alpha-1

[Tor Bug Tracker & Wiki]

#19869: tor_fragile_assert() in evdns_get_orig_address() on tor-0.2.9-alpha-1
-+-
 Reporter:  isis |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.2.???
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  isaremoved, regression,  |  Actual Points:
  nickwants029, tor-guards-revamp,   |
  TorCoreTeam201610  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by isis):

 * keywords:
 isaremoved, regression, nickwants029, tor-guards-revamp,
 TorCoreTeam201609
 =>
 isaremoved, regression, nickwants029, tor-guards-revamp,
 TorCoreTeam201610


Comment:

 This got left in September.

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

Re: [tor-bugs] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

[Tor Bug Tracker & Wiki]

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Replying to [comment:90 karsten]:
 > Well, the sync runs don't take just 3 or 20 minutes here, but many
 hours.  I could imagine that it's the backup daemon trying to capture all
 file system changes for the next backup, or something.  I could imagine
 that similar things can happen on servers.

 Well, please  investigate, if the backup is the reason.  A backup
 shouldn't hamper the productive system.

 Just to make sure we're talking about the same use case:
 * A fresh installation without previous data is not what sync is for.
 Here the archived data of the last three days should be provided and one
 or two regular download runs. After that, sync can be turned on.
 * A running instance like a mirror can be enhanced with the sync.

 > I don't understand your reasoning about `index.json` not being a true
 picture of `recent/`.  We're skipping `*.tmp` files when creating that
 file, and we always append to `.tmp` and only rename to the destination
 file when we're sure the file won't change anymore.  Where does that get
 inaccurate?

 Now I see we're talking about different accuracies:

 You're referring to the single file assembled in one download (or
 hopefully soon sync-run).  Thus, the index.json of a syncing instance
 could become inaccurate in this case.

 I'm referring to the accuracy lost by regular operation after creation or
 download of index.json.  For example ticket #20430, the syncing instance
 retrieves index.json, shortly after that the main instance has a clean-up
 run, and thus files listed in index.json don't exist anymore.

 >
 > ...
 >
 > By the way, we'll need to merge #20380 before putting out the release.
 And I'd want to start a test run over night before releasing, so the
 release cannot happen today anyway. :(

 That is vital information.
 When postponing the release there is time for changing the code and
 testing, that's what I said before.
 I'll take a look.

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

Re: [tor-bugs] #19869 [Core Tor/Tor]: tor_fragile_assert() in evdns_get_orig_address() on tor-0.2.9-alpha-1

[Tor Bug Tracker & Wiki]

#19869: tor_fragile_assert() in evdns_get_orig_address() on tor-0.2.9-alpha-1
-+-
 Reporter:  isis |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.2.???
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  isaremoved, regression,  |  Actual Points:
  nickwants029, tor-guards-revamp,   |
  TorCoreTeam201610  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by isis):

 This is still present in 0.2.9.4-alpha-1:

 {{{
 Oct 26 14:38:45 sys-tor Tor[783]: Tor has successfully opened a circuit.
 Looks like client functionality is working.
 Oct 26 14:38:45 sys-tor Tor[783]: Bootstrapped 100%: Done
 Oct 26 14:38:48 sys-tor Tor[783]: tor_bug_occurred_(): Bug:
 ../src/or/dnsserv.c:294: evdns_get_orig_address: This line should not have
 been reached. (Future instances of this warnin
 Oct 26 14:38:48 sys-tor Tor[783]: Bug: Line unexpectedly reached at
 evdns_get_orig_address at ../src/or/dnsserv.c:294. Stack trace: (on Tor
 0.2.9.4-alpha 8b0755c9bb296ae2)
 Oct 26 14:38:48 sys-tor Tor[783]: Bug:
 /usr/bin/tor(log_backtrace+0x42) [0x556e06b5e692] (on Tor 0.2.9.4-alpha
 8b0755c9bb296ae2)
 Oct 26 14:38:48 sys-tor Tor[783]: Bug:
 /usr/bin/tor(tor_bug_occurred_+0xb7) [0x556e06b77217] (on Tor
 0.2.9.4-alpha 8b0755c9bb296ae2)
 Oct 26 14:38:48 sys-tor Tor[783]: Bug:
 /usr/bin/tor(dnsserv_resolved+0x1dc) [0x556e06b4871c] (on Tor
 0.2.9.4-alpha 8b0755c9bb296ae2)
 Oct 26 14:38:48 sys-tor Tor[783]: Bug:
 /usr/bin/tor(connection_ap_handshake_socks_resolved+0x9e) [0x556e06b10d4e]
 (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
 Oct 26 14:38:48 sys-tor Tor[783]: Bug: /usr/bin/tor(+0x6bcf3)
 [0x556e06a7ecf3] (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
 Oct 26 14:38:48 sys-tor Tor[783]: Bug:
 /usr/bin/tor(circuit_receive_relay_cell+0x2a9) [0x556e06a7f069] (on Tor
 0.2.9.4-alpha 8b0755c9bb296ae2)
 Oct 26 14:38:48 sys-tor Tor[783]: Bug:
 /usr/bin/tor(command_process_cell+0x280) [0x556e06af0dc0] (on Tor
 0.2.9.4-alpha 8b0755c9bb296ae2)
 Oct 26 14:38:48 sys-tor Tor[783]: Bug:
 /usr/bin/tor(channel_tls_handle_cell+0x233) [0x556e06ad2ea3] (on Tor
 0.2.9.4-alpha 8b0755c9bb296ae2)
 Oct 26 14:38:48 sys-tor Tor[783]: Bug: /usr/bin/tor(+0x103de4)
 [0x556e06b16de4] (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
 Oct 26 14:38:48 sys-tor Tor[783]: Bug: /usr/bin/tor(+0xfafc5)
 [0x556e06b0dfc5] (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
 Oct 26 14:38:48 sys-tor Tor[783]: Bug: /usr/bin/tor(+0x43231)
 [0x556e06a56231] (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
 Oct 26 14:38:48 sys-tor Tor[783]: Bug: /usr/lib/x86_64-linux-
 gnu/libevent-2.0.so.5(event_base_loop+0x7fc) [0x7f252b3273dc] (on Tor
 0.2.9.4-alpha 8b0755c9bb296ae2)
 Oct 26 14:38:48 sys-tor Tor[783]: Bug:
 /usr/bin/tor(do_main_loop+0x294) [0x556e06a57304] (on Tor 0.2.9.4-alpha
 8b0755c9bb296ae2)
 Oct 26 14:38:48 sys-tor Tor[783]: Bug: /usr/bin/tor(tor_main+0x1c25)
 [0x556e06a5ab65] (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
 Oct 26 14:38:48 sys-tor Tor[783]: Bug: /usr/bin/tor(main+0x19)
 [0x556e06a52c09] (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
 Oct 26 14:38:48 sys-tor Tor[783]: Bug: /lib/x86_64-linux-
 gnu/libc.so.6(__libc_start_main+0xf5) [0x7f252a0d4b45] (on Tor
 0.2.9.4-alpha 8b0755c9bb296ae2)
 Oct 26 14:38:48 sys-tor Tor[783]: Bug: /usr/bin/tor(+0x3fc59)
 [0x556e06a52c59] (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
 }}}

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

Re: [tor-bugs] #19869 [Core Tor/Tor]: tor_fragile_assert() in evdns_get_orig_address() on tor-0.2.9-alpha-1

[Tor Bug Tracker & Wiki]

#19869: tor_fragile_assert() in evdns_get_orig_address() on tor-0.2.9-alpha-1
-+-
 Reporter:  isis |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  isaremoved, regression,  |  Actual Points:
  nickwants029, tor-guards-revamp,   |
  TorCoreTeam201610  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * milestone:  Tor: 0.2.??? => Tor: 0.2.9.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] #20004 [Core Tor/Tor]: prop224: Add a trunnel subdirectory specifically for HS

[Tor Bug Tracker & Wiki]

#20004: prop224: Add a trunnel subdirectory specifically for HS
+--
 Reporter:  dgoulet |  Owner:  dgoulet
 Type:  enhancement | Status:
|  needs_revision
 Priority:  High|  Milestone:  Tor:
|  0.3.0.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, prop224, TorCoreTeam201610  |  Actual Points:  0.5
Parent ID:  #17241  | Points:  1
 Reviewer:  asn |Sponsor:
|  SponsorR-must
+--
Changes (by dgoulet):

 * priority:  Medium => High
 * keywords:  tor-hs, prop224, nickm-deferred-20161005 => tor-hs, prop224,
 TorCoreTeam201610


Comment:

 Bumping priority and scheduling this for October work. It will be quite
 intertwined with #19043.

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

Re: [tor-bugs] #20004 [Core Tor/Tor]: prop224: Add a trunnel subdirectory specifically for HS

[Tor Bug Tracker & Wiki]

#20004: prop224: Add a trunnel subdirectory specifically for HS
+--
 Reporter:  dgoulet |  Owner:  dgoulet
 Type:  enhancement | Status:
|  needs_revision
 Priority:  High|  Milestone:  Tor:
|  0.3.0.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, prop224, TorCoreTeam201610  |  Actual Points:  0.5
Parent ID:  #17241  | Points:  1
 Reviewer:  asn |Sponsor:
|  SponsorR-must
+--

Comment (by asn):

 Pushed an initial branch here `ticket20004_rebased` which is basically
 David's branch rebased to latest tor git master, and also using latest
 trunnel git master.

 It still does not address the issues from comment:11. I will take care of
 those soon.

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

Re: [tor-bugs] #20380 [Metrics/CollecTor]: Expand INSTALL.md to a more complete operator's guide

[Tor Bug Tracker & Wiki]

#20380: Expand INSTALL.md to a more complete operator's guide
---+-
 Reporter:  karsten|  Owner:
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Thanks for the detailed feedback!  Please take a look at
 [https://gitweb.torproject.org/karsten/metrics-db.git/log/?h=task-20380 my
 updated task-20380 branch] for changes discussed below.

 Replying to [comment:10 iwakeh]:
 > Replying to [comment:9 karsten]:
 > > ...
 > > A few thoughts:
 > >
 > >  - When you say that closer monitoring will be needed when disk space
 drops below a given number, do you mean 200G or 20G or a different number?
 >
 > I was referring to the disk space available when starting,  i.e. very
 close to 150G and logging to the same disk requires more attention than a
 terabyte setup.  Hmm, but if that is confusing just discard it.

 Ah, now I understand.  Hmm, I think I'd rather pick a different number
 than 150G than going into more detail there.  After all, a CollecTor
 instance that doesn't download and serve the full tarball archive will
 need a lot less than 150G, and an instance that does serve tarballs might
 run out of disk space in a year or two even with 150G.  Let's just change
 it to 200G to have some more room to breathe.

 > >  - We shouldn't add new section headers easily.  The chosen section
 headers and even paragraphs in this document (will) have equivalents in
 the other operator's guides for other metrics tools.  If we want to add
 new sections, we'll also have to add those sections to the other manuals.
 The current sections are:
 > >
 > > {{{
 > > $ grep "^#" INSTALL.md
 > > # CollecTor Operator's Guide
 > > ## Setting up the host
 > > ## Setting up the service
 > > ## Maintaining the service
 > > }}}
 > >
 >
 > It's important to have a consistent structure, but it would be helpful
 for readers to have sub-headings, which are application dependent.
 Scrolling through a document with only generic headings when looking for
 particular information takes longer (of course, there is a search).
 > So, maybe keep the top level consistent and allow for application
 dependent headlines below?

 I admit that there could be more sections, though I have not yet given up
 on keeping them independent of the application.  I added a few more
 section headers.

 > >  - (continued) What other sections or even subsections should we
 include, and what instructions would go into those vs. the existing
 sections?
 >
 > I see two more sections.
 > * 'Planning the Service' contrasts those sections giving a to-do list.
 People running instances will have different needs that can be better
 covered this way.
 > * and even more important, a section 'Bootstrapping' or similar.  What
 data to download before a first run etc.  Again this is not a to-do list
 as it depends what data should be processed.

 Added the first but not yet the second.  Let me know if anything is still
 missing.

 > > > The idea behind my changes is that I think the service shouldn't be
 run from the unpacked tar
 > > > folder.  The tar contains a development environment, so the jar
 would disappear after 'ant clean' or changed etc.
 > > > The runtime directory should only contain files that are really
 necessary for the application or which were created by the application.
 > > > Hope this doesn't make the description too complicated.
 > >
 > > Yes, makes sense, let's change that.  There are still a few paths left
 where we refer to files in `collector-/` and where we should tell
 the user to copy those files to the working directory and run them from
 there.  I can update those places.
 > >
 > > > I also would like have even less description of tools from the OS,
 because such things should be decided by the operator.
 > >
 > > Which parts would that include?  The crontab, `@reboot`, `screen`,
 etc.?  Can you make a list?
 >
 > When we avoid mentioning any such tools and methods, we avoid getting
 out of date and stay platform independent.  People operating servers have
 their favorite tools for and know what to do when told
 >
 > * run this script every three days
 > * provide an http server for serving data and files in folders X, Y, Z.
 > * for continuous operation ensure start-up on reboot and
 > * monitoring of logs as well as running service is important
 > etc.
 >
 > CollecTor does not depend on apache or crontab only the services
 provided by them.  Even the suggested install of openjdk could be left
 out.  Also apt-get.  Attempt of a list:
 >
 > * apt-get
 > * apache2
 > * cr

Re: [tor-bugs] #10606 [Applications/Tor Browser]: about:tor may fetch the "you're using Tor" page from browser cache

[Tor Bug Tracker & Wiki]

#10606: about:tor  may fetch the "you're using Tor" page from browser cache
--+--
 Reporter:  konotrea  |  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

 * status:  new => assigned
 * owner:  erinn => tbb-team
 * component:  Applications/Tor bundles/installation => Applications/Tor
 Browser
 * severity:   => Normal
 * keywords:  needs-triage => tbb-usability


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

Re: [tor-bugs] #10521 [Applications/Tor Browser]: TBB 3.5 for OS X v. 10.9.1 does not connect to any websites

[Tor Bug Tracker & Wiki]

#10521: TBB 3.5 for OS X v. 10.9.1 does not connect to any websites
--+--
 Reporter:  kovagi|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:  tbb-helpdesk-frequent |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

 * keywords:  OS, X, tbb-helpdesk-frequent => tbb-helpdesk-frequent
 * status:  new => closed
 * version:  Tor: 0.2.4.19 =>
 * resolution:   => invalid
 * severity:   => Normal


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

Re: [tor-bugs] #10255 [Applications/Tor Browser]: about:tor page in torbrowser features futile link to "run a Tor relay node"

[Tor Bug Tracker & Wiki]

#10255: about:tor page in torbrowser features futile link to "run a Tor relay 
node"
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  Very Low  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

 * status:  new => assigned
 * owner:   => tbb-team
 * severity:   => Normal
 * keywords:  tbb-3.0, needs-triage =>


Comment:

 Looks like a website issue.

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

Re: [tor-bugs] #19869 [Core Tor/Tor]: tor_fragile_assert() in evdns_get_orig_address() on tor-0.2.9-alpha-1

[Tor Bug Tracker & Wiki]

#19869: tor_fragile_assert() in evdns_get_orig_address() on tor-0.2.9-alpha-1
-+-
 Reporter:  isis |  Owner:
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  isaremoved, regression,  |  Actual Points:
  nickwants029, tor-guards-revamp,   |
  TorCoreTeam201610  |
Parent ID:   | Points:  .1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  new => needs_review
 * points:   => .1


Comment:

 Well that was easy enough! This happens every time a hostname lookup over
 DNSPort fails.

 See `bug19869_029` in my public repository.  Does that 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] #20204 [Applications/Tor Browser]: Windows don't drag on macOS Sierra

[Tor Bug Tracker & Wiki]

#20204: Windows don't drag on macOS Sierra
-+-
 Reporter:  arlolra  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff52-esr-will-have, tbb-usability,   |  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arlolra):

 Can this go on tor-browser-45.4.0esr-6.0-1 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] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

[Tor Bug Tracker & Wiki]

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Replying to [comment:91 iwakeh]:
 > Replying to [comment:90 karsten]:
 > > Well, the sync runs don't take just 3 or 20 minutes here, but many
 hours.  I could imagine that it's the backup daemon trying to capture all
 file system changes for the next backup, or something.  I could imagine
 that similar things can happen on servers.
 >
 > Well, please  investigate, if the backup is the reason.  A backup
 shouldn't hamper the productive system.

 This was just a guess.  I didn't further investigate after finding out
 what the code was doing.  And even if backup daemons were not the reason
 for the slowness here, we shouldn't ship this code, now that we know about
 its inefficiency.

 > Just to make sure we're talking about the same use case:
 > * A fresh installation without previous data is not what sync is for.
 Here the archived data of the last three days should be provided and one
 or two regular download runs. After that, sync can be turned on.
 > * A running instance like a mirror can be enhanced with the sync.

 Why would we discourage turning on sync right from the start?  In this
 case, it was not the first run that was slow, but later sync runs were
 even slower.

 > > I don't understand your reasoning about `index.json` not being a true
 picture of `recent/`.  We're skipping `*.tmp` files when creating that
 file, and we always append to `.tmp` and only rename to the destination
 file when we're sure the file won't change anymore.  Where does that get
 inaccurate?
 >
 > Now I see we're talking about different accuracies:
 >
 > You're referring to the single file assembled in one download (or
 hopefully soon sync-run).  Thus, the index.json of a syncing instance
 could become inaccurate in this case.

 Yes, that's what I was referring to.

 > I'm referring to the accuracy lost by regular operation after creation
 or download of index.json.  For example ticket #20430, the syncing
 instance retrieves index.json, shortly after that the main instance has a
 clean-up run, and thus files listed in index.json don't exist anymore.

 True, that's unrelated to what I meant above.

 > > By the way, we'll need to merge #20380 before putting out the release.
 And I'd want to start a test run over night before releasing, so the
 release cannot happen today anyway. :(
 >
 > That is vital information.
 > When postponing the release there is time for changing the code and
 testing, that's what I said before.
 > I'll take a look.

 If you have some code for me today, I'll run it over night, and maybe we
 can release tomorrow! :)

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

Re: [tor-bugs] #19869 [Core Tor/Tor]: tor_fragile_assert() in evdns_get_orig_address() on tor-0.2.9-alpha-1

[Tor Bug Tracker & Wiki]

#19869: tor_fragile_assert() in evdns_get_orig_address() on tor-0.2.9-alpha-1
-+-
 Reporter:  isis |  Owner:
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  isaremoved, regression,  |  Actual Points:
  nickwants029, tor-guards-revamp,   |
  TorCoreTeam201610  |
Parent ID:   | Points:  .1
 Reviewer:  isis |Sponsor:
-+-
Changes (by isis):

 * status:  needs_review => merge_ready
 * reviewer:   => isis


Comment:

 Replying to [comment:9 nickm]:
 > Well that was easy enough! This happens every time a hostname lookup
 over DNSPort fails.
 >
 > See `bug19869_029` in my public repository.  Does that work for you?

 Okay, LGTM.

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

Re: [tor-bugs] #20451 [Obfuscation/meek]: The communication stream of managed proxy '/usr/bin/meek-client' is 'closed'

[Tor Bug Tracker & Wiki]

#20451: The communication stream of managed proxy '/usr/bin/meek-client' is
'closed'
--+-
 Reporter:  tagener-noisu |  Owner:  dcf
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by dcf):

 Replying to [comment:4 tagener-noisu]:
 > Everything is ok, I've got this:
 > And a log file here:

 Hm, I don't know what to suggest. You can try increasing the tor log
 verbosity from "notice" to "info":
 {{{
 Log info syslog
 }}}
 That should give you some more information about it starting its
 subprocesses.

 Is it possible you have some kind of hardening like seccomp or apparmor
 that applies to tor? That might be restricting what it can do with its
 child processes. Are you able to use an obfs4 bridge with obfs4proxy?

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

Re: [tor-bugs] #20468 [Applications/Tor Launcher]: TorBrowser using a secert HASHEDPASSWORD

[Tor Bug Tracker & Wiki]

#20468: TorBrowser using a secert HASHEDPASSWORD
---+---
 Reporter:  cypherpunks|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by mcs):

 When Tor Launcher starts the tor daemon, it assumes that it should
 configure it so that everything in Tor Browser will work. If you do not
 want Tor Launcher to start and configure tor, you should start tor
 yourself and then set the TOR_SKIP_LAUNCH env var to "1" before starting
 Tor Browser.

 That said, we could add another env var which would cause Tor Launcher to
 just start tor using whatever configuration is present. See also ticket
 #16017 (somewhat related).

 Also, it is not a good idea to edit torrc-defaults because it will be
 overwritten during software updates. It is better to just modify torrc.

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

Re: [tor-bugs] #20470 [- Select a component]: Move security slider to about:preferences#security (was: Move securityslider to about:preferences#security)

[Tor Bug Tracker & Wiki]

#20470: Move security slider to about:preferences#security
--+-
 Reporter:  8u9H  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |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] #20470 [- Select a component]: Move securityslider to about:preferences#security

[Tor Bug Tracker & Wiki]

#20470: Move securityslider to about:preferences#security
--+-
 Reporter:  8u9H  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Like what are make with privacy checkboxes in #20244

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

Re: [tor-bugs] #10606 [Applications/Tor Browser]: about:tor may fetch the "you're using Tor" page from browser cache

[Tor Bug Tracker & Wiki]

#10606: about:tor  may fetch the "you're using Tor" page from browser cache
--+
 Reporter:  konotrea  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by mcs):

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


Comment:

 In my tests using Tor Browser 6.0.5 with Tor Launcher is disabled, the
 about:tor page correctly reports that there is a problem. Also, there is
 nothing that prevents users from changing their home page to
 https://check.torproject.org/ if they prefer to have an end-to-end check.
 Therefore, I am closing this ticket. Please reopen it if you can provide
 steps to reproduce the problem reported in the original ticket
 description.

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

Re: [tor-bugs] #19869 [Core Tor/Tor]: tor_fragile_assert() in evdns_get_orig_address() on tor-0.2.9-alpha-1

[Tor Bug Tracker & Wiki]

#19869: tor_fragile_assert() in evdns_get_orig_address() on tor-0.2.9-alpha-1
-+-
 Reporter:  isis |  Owner:
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  isaremoved, regression,  |  Actual Points:
  nickwants029, tor-guards-revamp,   |
  TorCoreTeam201610  |
Parent ID:   | Points:  .1
 Reviewer:  isis |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 thanks; merged!

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

Re: [tor-bugs] #20451 [Obfuscation/meek]: The communication stream of managed proxy '/usr/bin/meek-client' is 'closed'

[Tor Bug Tracker & Wiki]

#20451: The communication stream of managed proxy '/usr/bin/meek-client' is
'closed'
--+-
 Reporter:  tagener-noisu |  Owner:  dcf
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by tagener-noisu):

 Replying to [comment:5 dcf]:
 > Hm, I don't know what to suggest. You can try increasing the tor log
 verbosity from "notice" to "info":
 > {{{
 > Log info syslog
 > }}}
 >
 Still nothing usefull in the log.
 {{{
 Oct 26 23:54:13 laptop Tor[32547]: launch_managed_proxy(): Managed proxy
 at '/usr/bin/meek-client' has spawned with PID '32555'.
 Oct 26 23:54:13 laptop Tor[32547]: cell_ewma_set_scale_factor(): Disabled
 cell_ewma algorithm because of value in Default value
 Oct 26 23:54:13 laptop Tor[32547]: Parsing GEOIP IPv4 file
 /usr/share/tor/geoip.
 Oct 26 23:54:13 laptop Tor[32547]: Parsing GEOIP IPv6 file
 /usr/share/tor/geoip6.
 Oct 26 23:54:13 laptop Tor[32547]: crypto_global_init(): NOT using OpenSSL
 engine support.
 Oct 26 23:54:13 laptop Tor[32547]: evaluate_evp_for_aes(): This version of
 OpenSSL has a known-good EVP counter-mode implementation. Using it.
 Oct 26 23:54:13 laptop Tor[32547]: Bootstrapped 0%: Starting
 Oct 26 23:54:13 laptop Tor[32547]: trusted_dirs_load_certs_from_string():
 Adding cached certificate for directory authority Faravahar with signing
 key 81FFA14EDAECD6CD8167A81556643486A7D30077
 Oct 26 23:54:13 laptop Tor[32547]: trusted_dirs_load_certs_from_string():
 Not adding cached certificate for unrecognized directory authority with
 signing key 11160AE7FE48BEBE4716E8CD4ED9711FD9E3DDBF
 Oct 26 23:54:13 laptop Tor[32547]: trusted_dirs_load_certs_from_string():
 Adding cached certificate for directory authority tor26 with signing key
 30F18E63064ECEB50C4D6339F5F6B12F9D6671DA
 Oct 26 23:54:13 laptop Tor[32547]: trusted_dirs_load_certs_from_string():
 Adding cached certificate for directory authority longclaw with signing
 key B54530637B8E758C5CB008ADF2BDB4D86DD74946
 Oct 26 23:54:13 laptop Tor[32547]: trusted_dirs_load_certs_from_string():
 Adding cached certificate for directory authority maatuska with signing
 key E9E6767366FB9056675D7A99B1D3E4F712752C81
 Oct 26 23:54:13 laptop Tor[32547]: trusted_dirs_load_certs_from_string():
 Adding cached certificate for directory authority moria1 with signing key
 25EA246B93803795E871FBA60C1A4D6224A837F8
 Oct 26 23:54:13 laptop Tor[32547]: trusted_dirs_load_certs_from_string():
 Adding cached certificate for directory authority gabelmoo with signing
 key 9E5ECDF8D87A1B11C000A11B57AEB31D2EE48A72
 Oct 26 23:54:13 laptop Tor[32547]: trusted_dirs_load_certs_from_string():
 Adding cached certificate for directory authority dizum with signing key
 2FD3DEFEA7E7965FB10ABF316E188DDB638AD506
 Oct 26 23:54:13 laptop Tor[32547]: read_file_to_str(): Could not open
 "/var/lib/tor/cached-consensus": No such file or directory
 Oct 26 23:54:13 laptop Tor[32547]: read_file_to_str(): Could not open
 "/var/lib/tor/unverified-consensus": No such file or directory
 Oct 26 23:54:13 laptop Tor[32547]: read_file_to_str(): Could not open
 "/var/lib/tor/unverified-microdesc-consensus": No such file or directory
 Oct 26 23:54:13 laptop Tor[32547]: microdesc_cache_reload(): Reloaded
 microdescriptor cache. Found 7906 descriptors.
 Oct 26 23:54:13 laptop Tor[32547]: tor_mmap_file(): Could not open
 "/var/lib/tor/cached-descriptors" for mmap(): No such file or directory
 Oct 26 23:54:13 laptop Tor[32547]: tor_mmap_file(): Could not open
 "/var/lib/tor/cached-extrainfo" for mmap(): No such file or directory
 Oct 26 23:54:13 laptop Tor[32547]: compute_weighted_bandwidths(): Empty
 routerlist passed in to consensus weight node selection for rule weight as
 guard
 Oct 26 23:54:13 laptop Tor[32547]: should_delay_dir_fetches(): Delaying
 dir fetches (no running bridges known)
 Oct 26 23:54:13 laptop Tor[32547]: Delaying directory fetches: No running
 bridges
 Oct 26 23:54:13 laptop Tor[32547]: I learned some more directory
 information, but not enough to build a circuit: No running bridges
 Oct 26 23:54:13 laptop Tor[32547]: compute_weighted_bandwidths(): Empty
 routerlist passed in to consensus weight node selection for rule weight as
 guard
 Oct 26 23:54:13 laptop Tor[32547]: should_delay_dir_fetches(): Delaying
 dir fetches (no running bridges known)
 Oct 26 23:54:13 laptop Tor[32547]: compute_weighted_bandwidths(): Empty
 routerlist passed in to consensus weight node selection for rule weight as
 guard
 Oct 26 23:54:13 laptop Tor[32547]: should_delay_dir_fetches(): Delaying
 dir fetches (no running bridges known)
 Oct 26 23:54:14 laptop Tor[32547]: compute_weighted_b

Re: [tor-bugs] #20204 [Applications/Tor Browser]: Windows don't drag on macOS Sierra

[Tor Bug Tracker & Wiki]

#20204: Windows don't drag on macOS Sierra
-+-
 Reporter:  arlolra  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff52-esr-will-have, tbb-usability,   |  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:27 arlolra]:
 > Can this go on tor-browser-45.4.0esr-6.0-1 as well?

 It should. Done with commit 41f1c54ad978155f964fca1100f0c2eda1bef88a.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20471 [Applications/Tor Browser]: Allow javascript: links from HTTPS first party pages

[Tor Bug Tracker & Wiki]

#20471: Allow javascript: links from HTTPS first party pages
--+---
 Reporter:  mikeperry |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-usability
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 When we consolidate the security slider options into just "High",
 "Medium", and "Default", we should ask Giorgio if he can give us a way to
 allow javascript: links when JS is enabled for HTTPS first party pages
 (but not http pages).

 This is the main thing that I've noticed breaking on "Medium-High", which
 if we make the new "Medium", we should definitely fix.

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

Re: [tor-bugs] #20471 [Applications/Tor Browser]: Allow javascript: links from HTTPS first party pages

[Tor Bug Tracker & Wiki]

#20471: Allow javascript: links from HTTPS first party pages
-+-
 Reporter:  mikeperry|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability-website, tbb-  |  Actual Points:
  security-slider|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-usability => tbb-usability-website, tbb-security-slider


Comment:

 This got reported as #20097 and on our blog:

 https://blog.torproject.org/blog/tor-browser-604-released#comment-203337

 https://bug1259785.bmoattachments.org/attachment.cgi?id=8734814 is the
 testcase mentioned there. Closing #20097 in favor of this one which takes
 our new security slider (just 3 states instead of 4) into account.

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

Re: [tor-bugs] #20097 [Applications/Tor Browser]: javascript: execution is disabled on medium-high security level on HTTPS website

[Tor Bug Tracker & Wiki]

#20097: javascript: execution is disabled on medium-high security level on HTTPS
website
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security-slider, tbb-usability-  |  duplicate
  website|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Making this a duplicate of #20471

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

Re: [tor-bugs] #20429 [Applications/Tor Launcher]: TOR_SKIP_LAUNCH=1: progress window stays open

[Tor Bug Tracker & Wiki]

#20429: TOR_SKIP_LAUNCH=1: progress window stays open
-+-
 Reporter:  mcs  |  Owner:  mcs
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Launcher|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability,TorBrowserTeam201610R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * status:  new => needs_review
 * keywords:   => tbb-usability,TorBrowserTeam201610R


Comment:

 Here is a fix:
 https://gitweb.torproject.org/user/brade/tor-
 launcher.git/commit/?h=bug20429-01

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

Re: [tor-bugs] #20429 [Applications/Tor Launcher]: TOR_SKIP_LAUNCH=1: progress window stays open

[Tor Bug Tracker & Wiki]

#20429: TOR_SKIP_LAUNCH=1: progress window stays open
-+-
 Reporter:  mcs  |  Owner:  mcs
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Launcher|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability,TorBrowserTeam201610R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * cc: gk, arthuredelstein (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] #20204 [Applications/Tor Browser]: Windows don't drag on macOS Sierra

[Tor Bug Tracker & Wiki]

#20204: Windows don't drag on macOS Sierra
-+-
 Reporter:  arlolra  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff52-esr-will-have, tbb-usability,   |  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arlolra):

 Thanks gk!

 Also, thanks Kathy and Mark for hunting this down.  Confirmed that fixes
 the issue in comment:23 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] #19043 [Core Tor/Tor]: prop224: Implementation of ESTABLISH_INTRO cell

[Tor Bug Tracker & Wiki]

#19043: prop224: Implementation of ESTABLISH_INTRO cell
-+-
 Reporter:  alec.heif|  Owner:  asn
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, 6.s194, |  Actual Points:
  TorCoreTeam201610  |
Parent ID:  #17241   | Points:  3
 Reviewer:  asn, dgoulet |Sponsor:
 |  SponsorR-must
-+-
Changes (by asn):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:28 dgoulet]:
 > Ok I've done a round of review on the merge request.

 Thanks for the review.

 I addressed most of your comments and pushed a fixup branch at
 `bug19043_v2_dgoulet_review`. I also replied to the gitlab comments. This
 is just a ticket for you to review the fixes.
 Let me know when you feel OK with them and I can squash all the fixup
 commits back to the original commit structure.

 Also, please let me know if you'd like to get the code mutex for now to do
 miscellaneous improvements (e.g. try out the hs_cells API). Personally, I
 found
 it useful when I took the HSDir code from you at the very end, so maybe
 you also find it useful.

 Putting this in `needs_review` again for now.

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

Re: [tor-bugs] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

[Tor Bug Tracker & Wiki]

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Please find another commit on this
 [https://gitweb.torproject.org/user/iwakeh/collector.git/commit/?h=task-18910
 -release-prep&id=d339c3931eb3721024f0982186ba94445019e3d3 branch].

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

Re: [tor-bugs] #20291 [Applications/Tor Browser]: Create user experience for security slider on Android (wireframes)

[Tor Bug Tracker & Wiki]

#20291: Create user experience for security slider on Android (wireframes)
+--
 Reporter:  isabela |  Owner:  tbb-team
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  android, ux-mobile, tbb-mobile  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by isabela):

 We worked on the copy for the UI at this document:

 
https://docs.google.com/document/d/1U_tbrC1lpuKHZg_QKD_TUVd6ImjTJ3jWZkSxjXgceZI/edit#heading=h.h3uj8yc4b3jd

 (now finalized)

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

Re: [tor-bugs] #20459 [Core Tor/Tor]: ewma_cmp_cmux never considers policies different

[Tor Bug Tracker & Wiki]

#20459: ewma_cmp_cmux never considers policies different
--+
 Reporter:  pastly|  Owner:
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.6.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  029-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * keywords:   => 029-backport
 * milestone:  Tor: 0.3.0.x-final => Tor: 0.2.9.x-final


Comment:

 Gosh.  I can also see getting this in place for 0.2.9.  But it does at
 least seem like an obvious merge for 0.3.0.  I'll merge for master.  If we
 choose to backport to 0.2.9, the thing to cherry-pick is
 c09993fdf6beb80d8c5f34250092c931333f7ac0

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

Re: [tor-bugs] #20060 [Core Tor/Tor]: torspec patch for new bandwidth weight defaults

[Tor Bug Tracker & Wiki]

#20060: torspec patch for new bandwidth weight defaults
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  torspec, tor-auth, nickm-|  Actual Points:
  deferred-20161005  |
Parent ID:  #14881   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * cc: pastly (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] #20060 [Core Tor/Tor]: torspec patch for new bandwidth weight defaults

[Tor Bug Tracker & Wiki]

#20060: torspec patch for new bandwidth weight defaults
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  torspec, tor-auth, nickm-|  Actual Points:
  deferred-20161005  |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * parent:  #14881 =>


Old description:

> If #14881 merges, torspec needs a patch saying that consensus method 24
> in tor version 0.2.9 initialises G, M, E, and D with 1, and T with 4.

New description:

 If #14881 merges, torspec needs a patch saying that consensus method
 ~~24~~ 26 in tor version ~~0.2.9~~ 0.3.0 initialises G, M, E, and D with
 1, and T with 4.

--

Comment:

 unparenting, to close parent.  Editing description to reflect reality.

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

Re: [tor-bugs] #14881 [Core Tor/Tor]: incorrect defaults when producing bandwidth-weights line in directory footer

[Tor Bug Tracker & Wiki]

#14881: incorrect defaults when producing bandwidth-weights line in directory
footer
-+-
 Reporter:  robgjansen   |  Owner:  pastly
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:  fixed
 Keywords:  027-triaged-1-in, 028-triaged,   |  Actual Points:
  pre028-patch, tor-sponsorU-orphan, |
  TorCoreTeam-postponed-201604, nickm-   |
  deferred-20161005, review-group-10 |
Parent ID:   | Points:  3
 Reviewer:  mikeperry|Sponsor:
 |  SponsorU-can
-+-
Changes (by nickm):

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


Comment:

 This looks safe enough.  I'm going to rebase and re-merge, though, since
 the original merge was faulty: It re-used consensus method 24, when it
 should have allocated a new consensus method.  I've grabbed 26.  Thanks
 for all the work!

 Pastly, would you like to take a go at #20060 ?

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

Re: [tor-bugs] #19999 [Core Tor/Tor]: Maybe test-cases should complete without BUG warnings?

[Tor Bug Tracker & Wiki]

#1: Maybe test-cases should complete without BUG warnings?
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  testing, TorCoreTeam201609, review-  |  implemented
  group-10   |  Actual Points:  3
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


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

Re: [tor-bugs] #19661 [Core Tor/Tor]: tor refuses to use /dev/null as a config file

[Tor Bug Tracker & Wiki]

#19661: tor refuses to use /dev/null as a config file
-+-
 Reporter:  weasel   |  Owner:
 |  cypherpunks
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.5-rc
 Severity:  Normal   | Resolution:
 Keywords:  easy, lorax, integration, review-|  Actual Points:
  group-10   |
Parent ID:   | Points:  .1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  assigned => needs_revision


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

Re: [tor-bugs] #19661 [Core Tor/Tor]: tor refuses to use /dev/null as a config file

[Tor Bug Tracker & Wiki]

#19661: tor refuses to use /dev/null as a config file
-+-
 Reporter:  weasel   |  Owner:
 |  cypherpunks
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.5-rc
 Severity:  Normal   | Resolution:
 Keywords:  easy, lorax, integration, review-|  Actual Points:
  group-10   |
Parent ID:   | Points:  .1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * owner:   => cypherpunks
 * status:  needs_revision => assigned


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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #15055, #20241, #20269

[Tor Bug Tracker & Wiki]

Batch modification to #15055, #20241, #20269 by nickm:
keywords to review-group-11

Comment:
Moving these to review-group-11. 

--
Tickets URL: 

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #15055, #18988, #19142, #19661, ...

[Tor Bug Tracker & Wiki]

Batch modification to #15055, #18988, #19142, #19661, #20070, #20241, #20269 by 
nickm:
keywords to review-group-10

--
Tickets URL: 

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #20278, #20459, #20168, #14828, ...

[Tor Bug Tracker & Wiki]

Batch modification to #20278, #20459, #20168, #14828, #15055, #16861, #17238, 
#17592, #17604, #17868, #17975, #19043, #20082, #20262, #20284, #20376 by nickm:
keywords to review-group-11

--
Tickets URL: 

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

Re: [tor-bugs] #20028 [Core Tor/Tor]: Fix typos in tor-spec.txt [circID -> CircID]

[Tor Bug Tracker & Wiki]

#20028: Fix typos in tor-spec.txt [circID -> CircID]
-+
 Reporter:  twim |  Owner:
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-11  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

 * keywords:   => review-group-11
 * milestone:   => Tor: 0.3.0.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] #20028 [Core Tor/Tor]: Fix typos in tor-spec.txt [circID -> CircID]

[Tor Bug Tracker & Wiki]

#20028: Fix typos in tor-spec.txt [circID -> CircID]
-+
 Reporter:  twim |  Owner:
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-11  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by nickm):

 I don't think this is a typo or a bug; IMO both capitalizations are fine.
 (Somebody let me know if I'm wrong though)

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

Re: [tor-bugs] #17610 [Core Tor/Tor]: Merge ExitPolicyRejectPrivate changes into 0.2.6.10

[Tor Bug Tracker & Wiki]

#17610: Merge ExitPolicyRejectPrivate changes into 0.2.6.10
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.2.7.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:  fixed
 Keywords:  security, 026-backport,  |  Actual Points:
  201512-deferred|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => closed
 * resolution:   => fixed
 * parent:  #17027 =>
 * milestone:  Tor: 0.2.6.x-final => Tor: 0.2.7.x-final


Comment:

 Not backportable. Marking as closed-in-0.2.7

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #18211, #18204, #18626, #18686, ...

[Tor Bug Tracker & Wiki]

Batch modification to #18211, #18204, #18626, #18686, #17902 by nickm:
milestone to Tor: 0.2.8.x-final

Action: resolve

Comment:
Marking these items as "no backport planned in 0.2.7".  Since there is a newer 
stable, and these aren't security holes or major stability problems, they don't 
get a backport.

--
Tickets URL: 

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

Re: [tor-bugs] #14828 [Core Tor/Tor]: Multiple hidden services can share a pk_digest/service_id.

[Tor Bug Tracker & Wiki]

#14828: Multiple hidden services can share a pk_digest/service_id.
---+---
 Reporter:  yawning|  Owner:  twim
 Type:  defect | Status:  needs_review
 Priority:  Very Low   |  Milestone:  Tor:
   |  0.3.0.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.2.7
 Severity:  Minor  | Resolution:
 Keywords:  easy, tor-hs, review-group-11  |  Actual Points:
Parent ID: | Points:  small
 Reviewer: |Sponsor:  SponsorR-can
---+---
Changes (by nickm):

 * status:  assigned => 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] #14828 [Core Tor/Tor]: Multiple hidden services can share a pk_digest/service_id.

[Tor Bug Tracker & Wiki]

#14828: Multiple hidden services can share a pk_digest/service_id.
---+---
 Reporter:  yawning|  Owner:  twim
 Type:  defect | Status:  assigned
 Priority:  Very Low   |  Milestone:  Tor:
   |  0.3.0.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.2.7
 Severity:  Minor  | Resolution:
 Keywords:  easy, tor-hs, review-group-11  |  Actual Points:
Parent ID: | Points:  small
 Reviewer: |Sponsor:  SponsorR-can
---+---
Changes (by nickm):

 * owner:   => twim
 * status:  needs_review => assigned


Comment:

 setting owner

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

Re: [tor-bugs] #20376 [Core Tor/Tor]: Do not mark circs for close again after relay_send_command_from_edge()

[Tor Bug Tracker & Wiki]

#20376: Do not mark circs for close again after relay_send_command_from_edge()
-+
 Reporter:  twim |  Owner:  twim
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  review-group-11  |  Actual Points:
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

 * owner:   => twim
 * status:  needs_review => assigned


Comment:

 setting owner

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

Re: [tor-bugs] #20376 [Core Tor/Tor]: Do not mark circs for close again after relay_send_command_from_edge()

[Tor Bug Tracker & Wiki]

#20376: Do not mark circs for close again after relay_send_command_from_edge()
-+
 Reporter:  twim |  Owner:  twim
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  review-group-11  |  Actual Points:
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

 * status:  assigned => 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] #20284 [Core Tor/Tor]: consensus weight case 2b3 does not follow dir-spec

[Tor Bug Tracker & Wiki]

#20284: consensus weight case 2b3 does not follow dir-spec
-+
 Reporter:  pastly   |  Owner:  pastly
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-11  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

 * owner:   => pastly
 * status:  needs_review => assigned


Comment:

 setting owner

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

Re: [tor-bugs] #20284 [Core Tor/Tor]: consensus weight case 2b3 does not follow dir-spec

[Tor Bug Tracker & Wiki]

#20284: consensus weight case 2b3 does not follow dir-spec
-+
 Reporter:  pastly   |  Owner:  pastly
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-11  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

 * status:  assigned => 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] #20278 [Core Tor/Tor]: cert-spec.txt contains incomplete reference / documentation for certificate types

[Tor Bug Tracker & Wiki]

#20278: cert-spec.txt contains incomplete reference / documentation for 
certificate
types
---+---
 Reporter:  patrickod  |  Owner:  dgoulet
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-spec, review-group-11  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * owner:   => dgoulet
 * status:  needs_review => assigned


Comment:

 setting owner

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

Re: [tor-bugs] #20278 [Core Tor/Tor]: cert-spec.txt contains incomplete reference / documentation for certificate types

[Tor Bug Tracker & Wiki]

#20278: cert-spec.txt contains incomplete reference / documentation for 
certificate
types
---+---
 Reporter:  patrickod  |  Owner:  dgoulet
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-spec, review-group-11  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * status:  assigned => 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] #20262 [Core Tor/Tor]: Onion services startup time always gets revealed

[Tor Bug Tracker & Wiki]

#20262: Onion services startup time always gets revealed
---+---
 Reporter:  twim   |  Owner:  twim
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Major  | Resolution:
 Keywords:  tor-hs, research, review-group-11  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  SponsorR-
   |  can
---+---
Changes (by nickm):

 * status:  needs_review => assigned
 * owner:   => twim


Comment:

 setting owner

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

Re: [tor-bugs] #20262 [Core Tor/Tor]: Onion services startup time always gets revealed

[Tor Bug Tracker & Wiki]

#20262: Onion services startup time always gets revealed
---+---
 Reporter:  twim   |  Owner:  twim
 Type:  defect | Status:
   |  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Major  | Resolution:
 Keywords:  tor-hs, research, review-group-11  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  SponsorR-
   |  can
---+---
Changes (by nickm):

 * status:  assigned => 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] #20082 [Core Tor/Tor]: Lower initial descriptor upload delay for hidden services

[Tor Bug Tracker & Wiki]

#20082: Lower initial descriptor upload delay for hidden services
-+-
 Reporter:  twim |  Owner:  twim
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, research,|  Actual Points:
  TorCoreTeam201610, review-group-11 |
Parent ID:   | Points:
 Reviewer:  teor |Sponsor:
 |  SponsorR-can
-+-
Changes (by nickm):

 * status:  assigned => 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] #20082 [Core Tor/Tor]: Lower initial descriptor upload delay for hidden services

[Tor Bug Tracker & Wiki]

#20082: Lower initial descriptor upload delay for hidden services
-+-
 Reporter:  twim |  Owner:  twim
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, research,|  Actual Points:
  TorCoreTeam201610, review-group-11 |
Parent ID:   | Points:
 Reviewer:  teor |Sponsor:
 |  SponsorR-can
-+-
Changes (by nickm):

 * owner:   => twim
 * status:  needs_review => assigned


Comment:

 setting owner

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

Re: [tor-bugs] #20060 [Core Tor/Tor]: torspec patch for new bandwidth weight defaults

[Tor Bug Tracker & Wiki]

#20060: torspec patch for new bandwidth weight defaults
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  torspec, tor-auth, nickm-|  Actual Points:
  deferred-20161005  |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by pastly):

 * status:  new => needs_review


Comment:

 [https://github.com/pastly/torspec/tree/ticket20060 branch]

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

Re: [tor-bugs] #14881 [Core Tor/Tor]: incorrect defaults when producing bandwidth-weights line in directory footer

[Tor Bug Tracker & Wiki]

#14881: incorrect defaults when producing bandwidth-weights line in directory
footer
-+-
 Reporter:  robgjansen   |  Owner:  pastly
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:  fixed
 Keywords:  027-triaged-1-in, 028-triaged,   |  Actual Points:
  pre028-patch, tor-sponsorU-orphan, |
  TorCoreTeam-postponed-201604, nickm-   |
  deferred-20161005, review-group-10 |
Parent ID:   | Points:  3
 Reviewer:  mikeperry|Sponsor:
 |  SponsorU-can
-+-

Comment (by teor):

 Replying to [comment:40 teor]:
 > Replying to [comment:39 pastly]:
 > > ...
 > > - 1/1 does not sound like a lot to me. If this is a big enough
 concern, we'll have to figure something else out.
 >
 > I'm not worried about the inaccuracy, but I'd like to know what the
 impact is - where does the extra weight change which nodes we choose, and
 how often? Which nodes get chosen more often because of it?

 For the record, this is the impact of this patch in the public Tor
 network:
 * each category gains a very small increment, which has negligible impact
 on the final weights,
 And on very small or very new Tor networks:
 * each category is weighted at least 1, even if there are no relays for
 that category. This may be good, because it allows the calculation to
 proceed. But it might also make some cases unreachable (if they rely on
 zero values), or add weight for things that aren't there.

 We should run this consensus method on the tor test network before the
 0.3.0 Tor release.

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

Re: [tor-bugs] #20060 [Core Tor/Tor]: torspec patch for new bandwidth weight defaults

[Tor Bug Tracker & Wiki]

#20060: torspec patch for new bandwidth weight defaults
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  torspec, tor-auth, nickm-|  Actual Points:
  deferred-20161005  |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 We should mention that:
 * T is initialised to 4
 * a shart summary of the impact of this change, something like: "With this
 change, test tor networks that are small or new are much more likely to
 produce valid bandwidth weights. The extra bandwidth has a negligible
 impact on the bandwidth weights in the public tor network."

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20472 [Core Tor/Tor]: circuit_pick_extend_handshake: Non-fatal assertion !(node_prev == NULL) failed

[Tor Bug Tracker & Wiki]

#20472: circuit_pick_extend_handshake: Non-fatal assertion !(node_prev == NULL)
failed
--+
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.3-alpha
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 {{{
 Oct 26 16:32:51.000 [warn] tor_bug_occurred_: Bug:
 src/or/circuitbuild.c:859: circuit_pick_extend_handshake: Non-fatal
 assertion !(node_prev == NULL) failed. (on Tor 0.2.9.3-alpha-dev
 153ff4f559d9b7ee)
 Oct 26 16:32:51.000 [warn] Bug: Non-fatal assertion !(node_prev == NULL)
 failed in circuit_pick_extend_handshake at src/or/circuitbuild.c:859.
 Stack trace: (on Tor 0.2.9.3-alpha-dev 153ff4f559d9b7ee)
 Oct 26 16:32:51.000 [warn] Bug: 0   tor
 0x00010b4d8f00 log_backtrace + 64 (on Tor 0.2.9.3-alpha-dev
 153ff4f559d9b7ee)
 Oct 26 16:32:51.000 [warn] Bug: 1   tor
 0x00010b586906 tor_bug_occurred_ + 790 (on Tor 0.2.9.3-alpha-dev
 153ff4f559d9b7ee)
 Oct 26 16:32:51.000 [warn] Bug: 2   tor
 0x00010ad024f3 circuit_pick_extend_handshake + 435 (on Tor 0.2.9.3
 -alpha-dev 153ff4f559d9b7ee)
 Oct 26 16:32:51.000 [warn] Bug: 3   tor
 0x00010acfbf6a circuit_send_next_onion_skin + 12362 (on Tor 0.2.9.3
 -alpha-dev 153ff4f559d9b7ee)
 Oct 26 16:32:51.000 [warn] Bug: 4   tor
 0x00010ad0b99f circuit_extend_to_new_exit + 335 (on Tor 0.2.9.3-alpha-
 dev 153ff4f559d9b7ee)
 Oct 26 16:32:51.000 [warn] Bug: 5   tor
 0x00010b2dcd0a rend_client_reextend_intro_circuit + 1450 (on Tor
 0.2.9.3-alpha-dev 153ff4f559d9b7ee)
 Oct 26 16:32:51.000 [warn] Bug: 6   tor
 0x00010b2df3dc rend_client_introduction_acked + 5276 (on Tor 0.2.9.3
 -alpha-dev 153ff4f559d9b7ee)
 Oct 26 16:32:51.000 [warn] Bug: 7   tor
 0x00010b2f8848 rend_process_relay_cell + 1464 (on Tor 0.2.9.3-alpha-
 dev 153ff4f559d9b7ee)
 Oct 26 16:32:51.000 [warn] Bug: 8   tor
 0x00010b2a3fe2 connection_edge_process_relay_cell + 37938 (on Tor
 0.2.9.3-alpha-dev 153ff4f559d9b7ee)
 Oct 26 16:32:51.000 [warn] Bug: 9   tor
 0x00010b2960ce circuit_receive_relay_cell + 2798 (on Tor 0.2.9.3
 -alpha-dev 153ff4f559d9b7ee)
 Oct 26 16:32:51.000 [warn] Bug: 10  tor
 0x00010add98a0 command_process_relay_cell + 5488 (on Tor 0.2.9.3
 -alpha-dev 153ff4f559d9b7ee)
 Oct 26 16:32:51.000 [warn] Bug: 11  tor
 0x00010add38f9 command_process_cell + 409 (on Tor 0.2.9.3-alpha-dev
 153ff4f559d9b7ee)
 Oct 26 16:32:51.000 [warn] Bug: 12  tor
 0x00010ac7e89f channel_queue_cell + 2447 (on Tor 0.2.9.3-alpha-dev
 153ff4f559d9b7ee)
 Oct 26 16:32:51.000 [warn] Bug: 13  tor
 0x00010ac9f3a3 channel_tls_handle_cell + 4099 (on Tor 0.2.9.3-alpha-
 dev 153ff4f559d9b7ee)
 Oct 26 16:32:51.000 [warn] Bug: 14  tor
 0x00010af2af62 connection_or_process_cells_from_inbuf + 3170 (on Tor
 0.2.9.3-alpha-dev 153ff4f559d9b7ee)
 Oct 26 16:32:51.000 [warn] Bug: 15  tor
 0x00010af2881e connection_or_process_inbuf + 1454 (on Tor 0.2.9.3
 -alpha-dev 153ff4f559d9b7ee)
 Oct 26 16:32:51.000 [warn] Bug: 16  tor
 0x00010aed2e9b connection_process_inbuf + 427 (on Tor 0.2.9.3-alpha-
 dev 153ff4f559d9b7ee)
 Oct 26 16:32:51.000 [warn] Bug: 17  tor
 0x00010aeafc19 connection_handle_read_impl + 7033 (on Tor 0.2.9.3
 -alpha-dev 153ff4f559d9b7ee)
 Oct 26 16:32:51.000 [warn] Bug: 18  tor
 0x00010aeae068 connection_handle_read + 40 (on Tor 0.2.9.3-alpha-dev
 153ff4f559d9b7ee)
 Oct 26 16:32:51.000 [warn] Bug: 19  tor
 0x00010b15eb2a conn_read_callback + 490 (on Tor 0.2.9.3-alpha-dev
 153ff4f559d9b7ee)
 Oct 26 16:32:51.000 [warn] Bug: 20  tor
 0x00010b6c71a6 event_base_loop + 1858 (on Tor 0.2.9.3-alpha-dev
 153ff4f559d9b7ee)
 Oct 26 16:32:51.000 [warn] Bug: 21  tor
 0x00010b181819 run_main_loop_once + 1433 (on Tor 0.2.9.3-alpha-dev
 153ff4f559d9b7ee)
 Oct 26 16:32:51.000 [warn] Bug: 22  tor
 0x00010b16bb62 run_main_loop_until_done + 34 (on Tor 0.2.9.3-alpha-dev
 153ff4f559d9b7ee)
 Oct 26 16:32:51.000 [warn] Bug: 23  tor
 0x00010b168f58 do_main_loop + 4504 (on Tor 0.2.9.3-alpha-dev
 153ff4f559d9b7ee)
 Oct 26 16:32:51.000 [warn] Bug: 24  tor
 0x00010b16f0ac tor_main + 1132 (on Tor 0.2.9.3-alpha-dev
 153ff4f559d9b7ee)
 Oct 26 16:32:51.000 [warn] Bug: 25  tor
 0x00010ac269d0 main + 48 (on Tor 0.2.9.3-alpha-dev 153ff4f559d9b7ee)
 Oct 26 16:32:51.000 [warn] Bug: 26  libdyld.dylib
 0x7fff9d8c65ad start + 1 (on Tor 0.2.9.3-alpha-dev 153ff4f559d9b7ee)
 Oct 26 16:32:51.000 [warn] Bug: 27  ???
 0x000f 0x0 + 15 (on Tor 0.2.9.3-alpha-dev 153ff4f559d9b7ee)
 }}}

--
Ticket URL: 
Tor Bug T

Re: [tor-bugs] #14881 [Core Tor/Tor]: incorrect defaults when producing bandwidth-weights line in directory footer

[Tor Bug Tracker & Wiki]

#14881: incorrect defaults when producing bandwidth-weights line in directory
footer
-+-
 Reporter:  robgjansen   |  Owner:  pastly
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:  fixed
 Keywords:  027-triaged-1-in, 028-triaged,   |  Actual Points:
  pre028-patch, tor-sponsorU-orphan, |
  TorCoreTeam-postponed-201604, nickm-   |
  deferred-20161005, review-group-10 |
Parent ID:   | Points:  3
 Reviewer:  mikeperry|Sponsor:
 |  SponsorU-can
-+-

Comment (by pastly):

 I've tested this in chutney now. One set of tests was run at the tip of
 current master, which includes this ticket, and is commit 48d7b69. The
 other set is a few commits back, does not include this ticket, and is
 commit 5a1779b.

 I ran basic-min, bridges-ipv6-min, bridges-min, hs-ipv6, hs-min, ipv6
 -exit-min, mixed, single-onion, and single-onion-ipv6.

 I wrote a script to see what nodes, if any, fail to bootstrap based on the
 presense of "Bootstrapped 100" in notice.log. The following output is the
 same with and without this ticket.

 {{{
 ./nodes.basic-min/000a/ probably failed to bootstrap
 ./nodes.basic-min/001a/ probably failed to bootstrap
 ./nodes.basic-min/002r/ probably failed to bootstrap
 ./nodes.bridges-ipv6-min/000a/ probably failed to bootstrap
 ./nodes.bridges-ipv6-min/001ba/ probably failed to bootstrap
 ./nodes.bridges-ipv6-min/002r/ probably failed to bootstrap
 ./nodes.bridges-min/000a/ probably failed to bootstrap
 ./nodes.bridges-min/001ba/ probably failed to bootstrap
 ./nodes.bridges-min/002r/ probably failed to bootstrap
 ./nodes.ipv6-exit-min/000a/ probably failed to bootstrap
 ./nodes.ipv6-exit-min/001a/ probably failed to bootstrap
 ./nodes.ipv6-exit-min/002r/ probably failed to bootstrap
 }}}

 `make test-network-all` says all PASS with and without this ticket.

 ---

 With this ticket, the authorities output lines like the following.

 {{{
 Oct 26 18:53:35.000 [notice] Time to compute a consensus.
 Oct 26 18:53:35.000 [notice] Computed bandwidth weights for Case 2b1
 (Wgg=weight_scale, Wmd=Wgd) with v10: G=1 M=1 E=1 D=1 T=4
 Oct 26 18:53:35.000 [notice] Bandwidth-weight Case 1 is verified and
 valid.
 Oct 26 18:53:35.000 [notice] Computed bandwidth weights for Case 2b1
 (Wgg=weight_scale, Wmd=Wgd) with v10: G=1 M=1 E=1 D=1 T=4
 Oct 26 18:53:35.000 [notice] Bandwidth-weight Case 1 is verified and
 valid.
 Oct 26 18:53:35.000 [notice] Consensus computed; uploading signature(s)
 Oct 26 18:53:35.000 [notice] Signature(s) posted.
 Oct 26 18:53:35.000 [notice] Uploaded signature(s) to dirserver
 127.0.0.1:7001
 Oct 26 18:53:35.000 [notice] Got a signature from 127.0.0.1. Adding it to
 the pending consensus.
 Oct 26 18:53:35.000 [notice] Added a signature for test001a from
 127.0.0.1.
 Oct 26 18:53:36.000 [notice] Time to fetch any signatures that we're
 missing.
 Oct 26 18:53:36.000 [notice] Time to publish the consensus and discard old
 votes
 Oct 26 18:53:36.000 [notice] Published ns consensus
 }}}

 And the `bandwidth-weights` line in the consensus is always

 {{{
 bandwidth-weights Wbd= Wbe=0 Wbg=0 Wbm=1 Wdb=1 Web=1
 Wed= Wee=1 Weg= Wem=1 Wgb=1 Wgd= Wgg=1
 Wgm=1 Wmb=1 Wmd= Wme=0 Wmg=0 Wmm=1
 }}}

 ---

 Without this ticket, the authorities output lines like the following.

 {{{
 Oct 26 19:55:59.000 [notice] Time to compute a consensus.
 Oct 26 19:55:59.000 [warn] Consensus with empty bandwidth: G=0 M=0 E=0 D=0
 T=0
 Oct 26 19:55:59.000 [warn] Consensus with empty bandwidth: G=0 M=0 E=0 D=0
 T=0
 Oct 26 19:55:59.000 [notice] Consensus computed; uploading signature(s)
 Oct 26 19:55:59.000 [notice] Signature(s) posted.
 Oct 26 19:55:59.000 [warn] No available nodes when trying to choose node.
 Failing.
 Oct 26 19:55:59.000 [warn] No available nodes when trying to choose node.
 Failing.
 Oct 26 19:55:59.000 [warn] Failed to find node for hop 1 of our path.
 Discarding this circuit.
 Oct 26 19:55:59.000 [notice] Uploaded signature(s) to dirserver
 127.0.0.1:7001
 Oct 26 19:55:59.000 [notice] Got a signature from 127.0.0.1. Adding it to
 the pending consensus.
 Oct 26 19:55:59.000 [notice] Added a signature for test001a from
 127.0.0.1.
 Oct 26 19:56:00.000 [notice] Time to fetch any signatures that we're
 missing.
 Oct 26 19:56:00.000 [warn] No ava

Re: [tor-bugs] #20060 [Core Tor/Tor]: torspec patch for new bandwidth weight defaults

[Tor Bug Tracker & Wiki]

#20060: torspec patch for new bandwidth weight defaults
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  torspec, tor-auth, nickm-|  Actual Points:
  deferred-20161005  |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-

Comment (by pastly):

 Replying to [comment:6 teor]:
 > * a shart summary of the impact of this change, something like: "With
 this change, test tor networks that are small or new are much more likely
 to produce valid bandwidth weights [...]"

 Do you mean "more likely to produce **invalid** bandwidth weights" because
 we might be giving weight to categories that have no relays? Or do you
 mean **valid** because at least we were able to produce a `bandwidth-
 weights` 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

[tor-bugs] #20473 [Core Tor/Chutney]: Fix Chutney Nodes that don't bootstrap

[Tor Bug Tracker & Wiki]

#20473: Fix Chutney Nodes that don't bootstrap
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 In https://trac.torproject.org/projects/tor/ticket/14881#comment:58 ,
 pastly reports:
 > {{{
 > ./nodes.basic-min/000a/ probably failed to bootstrap
 > ./nodes.basic-min/001a/ probably failed to bootstrap
 > ./nodes.basic-min/002r/ probably failed to bootstrap
 > ./nodes.bridges-ipv6-min/000a/ probably failed to bootstrap
 > ./nodes.bridges-ipv6-min/001ba/ probably failed to bootstrap
 > ./nodes.bridges-ipv6-min/002r/ probably failed to bootstrap
 > ./nodes.bridges-min/000a/ probably failed to bootstrap
 > ./nodes.bridges-min/001ba/ probably failed to bootstrap
 > ./nodes.bridges-min/002r/ probably failed to bootstrap
 > ./nodes.ipv6-exit-min/000a/ probably failed to bootstrap
 > ./nodes.ipv6-exit-min/001a/ probably failed to bootstrap
 > ./nodes.ipv6-exit-min/002r/ probably failed to bootstrap
 > }}}

 We should fix this.
 We should also integrate this check into chutney.

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

Re: [tor-bugs] #14881 [Core Tor/Tor]: incorrect defaults when producing bandwidth-weights line in directory footer

[Tor Bug Tracker & Wiki]

#14881: incorrect defaults when producing bandwidth-weights line in directory
footer
-+-
 Reporter:  robgjansen   |  Owner:  pastly
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:  fixed
 Keywords:  027-triaged-1-in, 028-triaged,   |  Actual Points:
  pre028-patch, tor-sponsorU-orphan, |
  TorCoreTeam-postponed-201604, nickm-   |
  deferred-20161005, review-group-10 |
Parent ID:   | Points:  3
 Reviewer:  mikeperry|Sponsor:
 |  SponsorU-can
-+-

Comment (by pastly):

 Oh, one final comment to make something explicit. Consensus method 2b1 was
 always used in the `with14881` networks. No method was used in the
 `without14881` networks because `networkstatus_compute_bw_weights_v10`
 refuses to do so if G, M, E, or D are <= 0.

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

Re: [tor-bugs] #20473 [Core Tor/Chutney]: Fix Chutney Nodes that don't bootstrap

[Tor Bug Tracker & Wiki]

#20473: Fix Chutney Nodes that don't bootstrap
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * points:   => 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] #20474 [Core Tor/Tor]: Tor should try harder to choose nodes in small networks

[Tor Bug Tracker & Wiki]

#20474: Tor should try harder to choose nodes in small networks
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  easy
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+--
 In https://trac.torproject.org/projects/tor/ticket/14881#comment:58 ,
 pastly reports that in networks without bandwidth weights, tor says:
 > Oct 26 19:56:00.000 [warn] Failed to find node for hop 1 of our path.
 Discarding this circuit.

 We should fix this at some point by falling back to choosing a random
 node.

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

Re: [tor-bugs] #14881 [Core Tor/Tor]: incorrect defaults when producing bandwidth-weights line in directory footer

[Tor Bug Tracker & Wiki]

#14881: incorrect defaults when producing bandwidth-weights line in directory
footer
-+-
 Reporter:  robgjansen   |  Owner:  pastly
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:  fixed
 Keywords:  027-triaged-1-in, 028-triaged,   |  Actual Points:
  pre028-patch, tor-sponsorU-orphan, |
  TorCoreTeam-postponed-201604, nickm-   |
  deferred-20161005, review-group-10 |
Parent ID:   | Points:  3
 Reviewer:  mikeperry|Sponsor:
 |  SponsorU-can
-+-

Comment (by teor):

 Replying to [comment:58 pastly]:
 > I've tested this in chutney now. One set of tests was run at the tip of
 current master, which includes this ticket, and is commit 48d7b69. The
 other set is a few commits back, does not include this ticket, and is
 commit 5a1779b.
 >
 > I ran basic-min, bridges-ipv6-min, bridges-min, hs-ipv6, hs-min, ipv6
 -exit-min, mixed, single-onion, and single-onion-ipv6.
 >
 > I wrote a script to see what nodes, if any, fail to bootstrap based on
 the presense of "Bootstrapped 100" in notice.log. The following output is
 the same with and without this ticket.
 >
 > {{{
 > ./nodes.basic-min/000a/ probably failed to bootstrap
 > ./nodes.basic-min/001a/ probably failed to bootstrap
 > ./nodes.basic-min/002r/ probably failed to bootstrap
 > ./nodes.bridges-ipv6-min/000a/ probably failed to bootstrap
 > ./nodes.bridges-ipv6-min/001ba/ probably failed to bootstrap
 > ./nodes.bridges-ipv6-min/002r/ probably failed to bootstrap
 > ./nodes.bridges-min/000a/ probably failed to bootstrap
 > ./nodes.bridges-min/001ba/ probably failed to bootstrap
 > ./nodes.bridges-min/002r/ probably failed to bootstrap
 > ./nodes.ipv6-exit-min/000a/ probably failed to bootstrap
 > ./nodes.ipv6-exit-min/001a/ probably failed to bootstrap
 > ./nodes.ipv6-exit-min/002r/ probably failed to bootstrap
 > }}}
 >
 > `make test-network-all` says all PASS with and without this ticket.

 I logged #20473 for this issue.

 >
 > ---
 >
 > With this ticket, the authorities output lines like the following.
 >
 > {{{
 > Oct 26 18:53:35.000 [notice] Time to compute a consensus.
 > Oct 26 18:53:35.000 [notice] Computed bandwidth weights for Case 2b1
 (Wgg=weight_scale, Wmd=Wgd) with v10: G=1 M=1 E=1 D=1 T=4
 > Oct 26 18:53:35.000 [notice] Bandwidth-weight Case 1 is verified and
 valid.
 > Oct 26 18:53:35.000 [notice] Computed bandwidth weights for Case 2b1
 (Wgg=weight_scale, Wmd=Wgd) with v10: G=1 M=1 E=1 D=1 T=4
 > Oct 26 18:53:35.000 [notice] Bandwidth-weight Case 1 is verified and
 valid.
 > Oct 26 18:53:35.000 [notice] Consensus computed; uploading signature(s)
 > Oct 26 18:53:35.000 [notice] Signature(s) posted.
 > Oct 26 18:53:35.000 [notice] Uploaded signature(s) to dirserver
 127.0.0.1:7001
 > Oct 26 18:53:35.000 [notice] Got a signature from 127.0.0.1. Adding it
 to the pending consensus.
 > Oct 26 18:53:35.000 [notice] Added a signature for test001a from
 127.0.0.1.
 > Oct 26 18:53:36.000 [notice] Time to fetch any signatures that we're
 missing.
 > Oct 26 18:53:36.000 [notice] Time to publish the consensus and discard
 old votes
 > Oct 26 18:53:36.000 [notice] Published ns consensus
 > }}}
 >
 > And the `bandwidth-weights` line in the consensus is always
 >
 > {{{
 > bandwidth-weights Wbd= Wbe=0 Wbg=0 Wbm=1 Wdb=1 Web=1
 Wed= Wee=1 Weg= Wem=1 Wgb=1 Wgd= Wgg=1
 Wgm=1 Wmb=1 Wmd= Wme=0 Wmg=0 Wmm=1
 > }}}
 >
 > ---
 >
 > Without this ticket, the authorities output lines like the following.
 >
 > {{{
 > Oct 26 19:55:59.000 [notice] Time to compute a consensus.
 > Oct 26 19:55:59.000 [warn] Consensus with empty bandwidth: G=0 M=0 E=0
 D=0 T=0
 > Oct 26 19:55:59.000 [warn] Consensus with empty bandwidth: G=0 M=0 E=0
 D=0 T=0
 > Oct 26 19:55:59.000 [notice] Consensus computed; uploading signature(s)
 > Oct 26 19:55:59.000 [notice] Signature(s) posted.
 > Oct 26 19:55:59.000 [warn] No available nodes when trying to choose
 node. Failing.
 > Oct 26 19:55:59.000 [warn] No available nodes when trying to choose
 node. Failing.
 > Oct 26 19:55:59.000 [warn] Failed to find node for hop 1 of our path.
 Discarding this circuit.
 > Oct 26 19:55:59.000 [notice] Uploaded signature(s) to dirserver
 127.0.0.1:7001
 > Oct 26 19:55:59.000 [notice] Got a signature from 127.0.0.1. Adding it
 to the pending consensu

[tor-bugs] #20475 [Metrics/Torflow]: Setting bwscanner min_exits to 1 causes no exits to be selected

[Tor Bug Tracker & Wiki]

#20475: Setting bwscanner min_exits to 1 causes no exits to be selected
-+
 Reporter:  teor |  Owner:  aagbsn
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Torflow  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 It looks like there's an off-by-one error in the code that handles this
 minimun:
 {{{
 diff --git a/NetworkScanners/BwAuthority/bwauthority_child.py
 b/NetworkScanners/BwAuthority/bwauthority_child.py
 index a36728f..248c6d0 100755
 --- a/NetworkScanners/BwAuthority/bwauthority_child.py
 +++ b/NetworkScanners/BwAuthority/bwauthority_child.py
 @@ -67,7 +68,7 @@ __selmgr = PathSupport.SelectionManager(
   use_guards=False,
   exit_ports=[443],
   order_by_ratio=True, # XXX: may be a poor idea for PID control?
 -  min_exits=10)
 +  min_exits=1)

 # exit code to indicate scan completion
 # make sure to update this in bwauthority.py 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] #20060 [Core Tor/Tor]: torspec patch for new bandwidth weight defaults

[Tor Bug Tracker & Wiki]

#20060: torspec patch for new bandwidth weight defaults
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  torspec, tor-auth, nickm-|  Actual Points:
  deferred-20161005  |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:7 pastly]:
 > Replying to [comment:6 teor]:
 > > * a shart summary of the impact of this change, something like: "With
 this change, test tor networks that are small or new are much more likely
 to produce valid bandwidth weights [...]"
 >
 > Do you mean "more likely to produce **invalid** bandwidth weights"
 because we might be giving weight to categories that have no relays?Or do
 you mean **valid** because at least we were able to produce a `bandwidth-
 weights` line?

 Ok, so I mean "much more likely to produce a `bandwidth-weights` line".

 We don't need to mention that this might cause node selection issues in
 small tor networks, because tor thinks there is a node of a particular
 type, and then can't find one. That's something we should find and fix
 during the 0.3.0 series.

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

Re: [tor-bugs] #20060 [Core Tor/Tor]: torspec patch for new bandwidth weight defaults

[Tor Bug Tracker & Wiki]

#20060: torspec patch for new bandwidth weight defaults
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  torspec, tor-auth, nickm-|  Actual Points:
  deferred-20161005  |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by pastly):

 * status:  needs_revision => needs_review


Comment:

 Updated [https://github.com/pastly/torspec/tree/ticket20060 branch] with
 new commit.

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

Re: [tor-bugs] #14881 [Core Tor/Tor]: incorrect defaults when producing bandwidth-weights line in directory footer

[Tor Bug Tracker & Wiki]

#14881: incorrect defaults when producing bandwidth-weights line in directory
footer
-+-
 Reporter:  robgjansen   |  Owner:  pastly
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:  fixed
 Keywords:  027-triaged-1-in, 028-triaged,   |  Actual Points:
  pre028-patch, tor-sponsorU-orphan, |
  TorCoreTeam-postponed-201604, nickm-   |
  deferred-20161005, review-group-10 |
Parent ID:   | Points:  3
 Reviewer:  mikeperry|Sponsor:
 |  SponsorU-can
-+-

Comment (by teor):

 For the record, the test network will run this consensus method once we
 all upgrade to tor 0.3.0.1-alpha (or an 0.3.0-alpha-dev containing this
 particular commit).

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

Re: [tor-bugs] #20060 [Core Tor/Tor]: torspec patch for new bandwidth weight defaults

[Tor Bug Tracker & Wiki]

#20060: torspec patch for new bandwidth weight defaults
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  torspec, tor-auth, nickm-|  Actual Points:
  deferred-20161005, CoreTorTeam201610   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => merge_ready
 * keywords:  torspec, tor-auth, nickm-deferred-20161005 => torspec, tor-
 auth, nickm-deferred-20161005, CoreTorTeam201610


Old description:

> If #14881 merges, torspec needs a patch saying that consensus method
> ~~24~~ 26 in tor version ~~0.2.9~~ 0.3.0 initialises G, M, E, and D with
> 1, and T with 4.

New description:

 If #14881 merges, torspec needs a patch saying that consensus method
 ~~24~~ 26 in tor version ~~0.2.9~~ ~~0.3.0~~ 0.3.0.1-alpha initialises G,
 M, E, and D with 1, and T with 4.

--

Comment:

 (Fixed the actual first version this will be released in: tor
 0.3.0.1-alpha. We don't include versions in dir-spec.txt, so no changes
 needed.)

 Looks good, let's get this squashed and merged to torspec.

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

Re: [tor-bugs] #20204 [Applications/Tor Browser]: Windows don't drag on macOS Sierra

[Tor Bug Tracker & Wiki]

#20204: Windows don't drag on macOS Sierra
-+-
 Reporter:  arlolra  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff52-esr-will-have, tbb-usability,   |  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 There is a related bug I just found where clicking on the insertion point
 in some (multi-line?) editable text fields on macOS Sierra causes the
 window to be dragged. It's hard to reproduce, and not worth fixing, as it
 is so rare. But we should check that we don't make it worse with this fix.

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

Re: [tor-bugs] #20241 [Core Tor/Tor]: Fix compilation on osx sierra (10.12)

[Tor Bug Tracker & Wiki]

#20241: Fix compilation on osx sierra (10.12)
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.8.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  osx, TorCoreTeam201609, review-  |  Actual Points:  .1
  group-11   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => merge_ready


Comment:

 It would be really nice to get this patch into fink/MacPorts/HomeBrew and
 similar, but it's not urgent, because most macOS users just use tor
 browser.

 These changes look fine, and are low risk on macOS Sierra.

 The only risk would be breaking compilation somewhere else.

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

Re: [tor-bugs] #20472 [Core Tor/Tor]: circuit_pick_extend_handshake: Non-fatal assertion !(node_prev == NULL) failed

[Tor Bug Tracker & Wiki]

#20472: circuit_pick_extend_handshake: Non-fatal assertion !(node_prev == NULL)
failed
---+---
 Reporter:  cypherpunks|  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.2.9.3-alpha
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201610, regression  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * keywords:   => TorCoreTeam201610, regression


Comment:

 Thanks for this bug report.

 This is a rare case:
 * tor creates an introduction circuit
 * some time later, the introduction point sends a NAK
 * tor extends through the previous intro point to a new intro point
 * the previous intro point is not in the consensus, either because it
 dropped out, or because it was never there to begin with.

 This is the calling code:
 {{{
 {
   const node_t *prev_node;
   prev_node = node_get_by_id(hop->prev->extend_info->identity_digest);
   circuit_pick_extend_handshake(&ec.cell_type,
 &ec.create_cell.cell_type,
 &ec.create_cell.handshake_type,
 prev_node,
 hop->extend_info);
 }
 }}}

 I think the correct way to fix this is to allow node_prev to be NULL, and
 skip the version checks in that case. We can't just do this for old-style
 hidden service, because it's also possible that nodes drop out of the
 consensus while the circuit is being built.

 Bugfix on commit 10aa913 from #19163 in tor-0.2.9.3-alpha.

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

Re: [tor-bugs] #19459 [Applications/Tor Browser]: Write (C++) patch for window resizing parts

[Tor Bug Tracker & Wiki]

#19459: Write (C++) patch for window resizing parts
-+-
 Reporter:  gk   |  Owner:
 |  arthuredelstein
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton-conversion,|  Actual Points:
  TorBrowserTeam201610   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-

Comment (by arthuredelstein):

 Replying to [comment:32 gk]:

 Thanks as always for testing and reviewing!

 > 1) We might want to add an `NS_ENSURE_STATE(shellWindow);` after and an
 `NS_ENSURE_STATE(mPrimaryContentShell);` before
 > `nsCOMPtr
 shellWindow(do_QueryInterface(mPrimaryContentShell));`. There is code that
 does this in r306252 and this seems reasonable to me.

 Added.

 > 2) We might want to check the return value of `GetAvailScreenSize()`
 called in `ResizeToBoundedDimensions()` as well (as is done at the other
 place you use it)? Not sure what should happen in case this fails, though.

 I have added this as well. For now it causes ResizeToBoundedDimensions to
 abort.

 > Regarding my testing: it looks good on all machines I tried it. I
 encounerted an issue I mentioned in comment:18 (1)) again but after
 digging a bit deeper it seems older versions have this problem, too. So,
 no regression at least. This is #18175 fwiw.

 I was able to reproduce this problem on a Windows machine and fixed it by
 adding a little piece of the old JS patch. It's annoying to me to have to
 add special-case code to two different files, but there is so much magic
 in Firefox window sizing that I don't know how else to do it. I wonder if
 this patch fixes the problem on your test system as well.

 Here's the new version:
 ​https://github.com/arthuredelstein/tor-browser/commit/19459+13

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20476 [Core Tor/Stem]: stem exit policy tests fail on master

[Tor Bug Tracker & Wiki]

#20476: stem exit policy tests fail on master
---+
 Reporter:  teor   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 The following stem tests fail on master:
 {{{
 test_all_private_policy  [FAILURE]
 ...
 test_mixed_private_policy[FAILURE]
 }}}

 I think it's likely this is due to ExitPolicyRejectLocalInterfaces in
 #18456.

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