Re: [tor-bugs] #29562 [Core Tor/Tor]: APPCRASH of tor.exe on Windows when PT bootstrap is cancelled

[Tor Bug Tracker & Wiki]

#29562: APPCRASH of tor.exe on Windows when PT bootstrap is cancelled
---+---
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor:
   |  0.4.0.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.4.0.1-alpha
 Severity:  Normal | Resolution:
 Keywords:  regression 040-must crash  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by gk):

 * cc: gk (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] #29080 [Applications/Tor Browser]: Merge OrbotService and TOPL

[Tor Bug Tracker & Wiki]

#29080: Merge OrbotService and TOPL
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a3,  |  Actual Points:
  TorBrowserTeam201902R  |
Parent ID:  #27609   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  needs_review => needs_information


Comment:

 sisbell: What exactly should we review here? Could you point me/us to the
 relevant branches/commits?

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

Re: [tor-bugs] #28716 [Applications/Tor Browser]: Create a mingw-w64-clang project

[Tor Bug Tracker & Wiki]

#28716: Create a mingw-w64-clang project
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201902,   |  Actual Points:
  GeorgKoppen201902  |
Parent ID:  #28238   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  needs_review => needs_revision
 * keywords:  tbb-rbm, TorBrowserTeam201902R, GeorgKoppen201902 => tbb-rbm,
 TorBrowserTeam201902, GeorgKoppen201902


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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: #28329, #29080

[Tor Bug Tracker & Wiki]

Batch modification to #28329, #29080 by gk:


Comment:
Setting the "R" keyword

--
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] #25930 [Applications/Tor Browser]: Update gcc to 7.X

[Tor Bug Tracker & Wiki]

#25930: Update gcc to 7.X
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 We could get `-fwrapv` back for our debug builds if we switched to GCC 8.x
 (see: #27597). As a data point: I've been compiling (and using) some
 custom Tor Browser with GCC 8.x for a while now and did not run into any
 issues. Thus, we might consider 8.x sufficiently stable to switch to it in
 particular when preparing for eser68.

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

Re: [tor-bugs] #29194 [Applications/rbm]: Set DEBIAN_FRONTEND=noninteractive when installing packages

[Tor Bug Tracker & Wiki]

#29194: Set DEBIAN_FRONTEND=noninteractive when installing packages
---+---
 Reporter:  boklm  |  Owner:  boklm
 Type:  defect | Status:
   |  needs_information
 Priority:  Medium |  Milestone:
Component:  Applications/rbm   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201901, tbb-rbm  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by gk):

 * status:  new => needs_information


Comment:

 Replying to [comment:4 boklm]:
 > In branch `bug_29194` I made a patch setting
 `DEBIAN_FRONTEND=noninteractive`. However, I didn't fully test it yet, and
 because it is changing build instructions for all containers, it will
 require everything to be rebuilt.
 >
 > With #29235 we stopped using buster in `projects/https-everywhere`,
 however we still use in in `projects/tor-browser` for `android-armv7`.
 Before merging the fix that will require rebuilding everything, I think we
 could start by fixing it only for `projects/tor-browser` on `android-
 armv7`:
 > https://gitweb.torproject.org/user/boklm/tor-browser-
 
build.git/commit/?h=bug_29194_android&id=c87154eadb5920aa54e52763fd092dea56e97485
 >
 > And later merge the full fix, after more testing.

 What's the plan here? Bite the bullet and merge the full fix for getting
 everything rebuilt and tested before 8.5 gets stable? Or anything 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] #27597 [Applications/Tor Browser]: ASan build option in tor-browser-build is broken

[Tor Bug Tracker & Wiki]

#27597: ASan build option in tor-browser-build is broken
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-8.0-issues, tbb-regression,  |  Actual Points:
  tbb-rbm, TorBrowserTeam201901R |
Parent ID:   | Points:
 Reviewer:  boklm|Sponsor:
-+-

Comment (by gk):

 Replying to [comment:2 gk]:
 > Okay, I pushed another commit (commit
 570ae84b5182a7d6986e467540318e5282fe0f2e) that fixes the `--enable-tests`
 related problem. It turns out that `fwrapv` does not like the code added
 in https://bugzilla.mozilla.org/show_bug.cgi?id=1432646 and breaks. I have
 not looked closer whether that's a compiler bug or something else.

 Seems indeed to be a compiler issue. GCC >= 8.1 has not issues with it.

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

Re: [tor-bugs] #9336 [Applications/Tor Browser]: Odd wyswig schemes without isolation for browserspy.dk

[Tor Bug Tracker & Wiki]

#9336: Odd wyswig schemes without isolation for browserspy.dk
-+-
 Reporter:  mikeperry|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-linkability, tbb-firefox-patch,  |  Actual Points:
  ff68-esr-will-have |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-linkability, tbb-firefox-patch => tbb-linkability, tbb-
 firefox-patch, ff68-esr-will-have


Comment:

 https://bugzilla.mozilla.org/show_bug.cgi?id=1489308 gets rid of the
 wyciwyg protocol handler.

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

Re: [tor-bugs] #29576 [- Select a component]: Tor Browser won't start

[Tor Bug Tracker & Wiki]

#29576: Tor Browser won't start
--+
 Reporter:  thelamper |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Major | Resolution:
 Keywords:  Tor not loading   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by thelamper):

 * Attachment "0 Tor log messages ready.jpg" 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] #29576 [- Select a component]: Tor Browser won't start

[Tor Bug Tracker & Wiki]

#29576: Tor Browser won't start
--+
 Reporter:  thelamper |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Major | Resolution:
 Keywords:  Tor not loading   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by thelamper):

 * Attachment "tor unexpectedly exited.jpg" added.


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

[tor-bugs] #29576 [- Select a component]: Tor Browser won't start

[Tor Bug Tracker & Wiki]

#29576: Tor Browser won't start
-+--
 Reporter:  thelamper|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Component:  - Select a component
  Version:   |   Severity:  Major
 Keywords:  Tor not loading  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 I am having the following issue when I try to start the Tor Browser.

 The browser won't load, and I see the following message: "Tor unexpectedly
 exited. This might be due to a bug in Tor itself, another program on your
 system, or faulty hardware".

 I have tried restarting my computer, and using Windows Task Manager to see
 if the Tor Browser is already running in the background (it is not).

 As suggested by the browser, I try to copy the Tor log to the clipboard,
 but nothing is copied to the clipboard. I just see the message: 'copy
 complete. 0 Tor log messages are ready to be pasted into a text editor or
 an email message’.

 I have included screenshots to show you what happens exactly.

 I can't confirm which version of the Tor Browser it is because the Tor
 Browser won't start, but I am almost certain that it is the most latest
 version as I update whenever there is a new version. The Tor Browser only
 stopped working on my computer a few days ago.

 I would just uninstall the Tor Browser and re-install it, but I have some
 bookmarks in there that I don't want to lose.

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

Re: [tor-bugs] #29017 [Core Tor/Tor]: PaddingStatistics should be disabled when ExtraInfoStatistics is 0

[Tor Bug Tracker & Wiki]

#29017: PaddingStatistics should be disabled when ExtraInfoStatistics is 0
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Low  |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  fast-fix, 035-backport,  |  Actual Points:  1.3
  034-backport, 033-backport, postfreeze-ok, |
  040-can|
Parent ID:   | Points:  0.2
 Reviewer:  nickm|Sponsor:
 |  SponsorV-can
-+-

Comment (by teor):

 Replying to [comment:13 nickm]:
 > This seems okay for 0.4.0. I'm not 100% sure on backporting any farther,
 but I wouldn't object much.

 My feeling is that getting it in 0.3.5 would be nice. Putting it in 0.3.4
 seems less important, and 0.3.3 is not supported in 3 days' time.

 I'll check it against our backport policy when I do my next backport 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] #29527 [Core Tor/Tor]: Division by zero: undefined behaviour in circuitpadding/circuitpadding_sample_distribution test

[Tor Bug Tracker & Wiki]

#29527: Division by zero: undefined behaviour in
circuitpadding/circuitpadding_sample_distribution test
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, tor-ci, tor-test,|  Actual Points:
  040-must   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 From https://trac.torproject.org/projects/tor/ticket/29528#comment:3
 > There is an open Clang bug for this:
 https://bugs.llvm.org/show_bug.cgi?id=19535
 >
 > Possible workaround: use `-fno-sanitize=float-divide-by-zero` in
 addition to `-fsanitize=undefined`.

 Let's also implement this workaround for the warnings that are obviously
 not bugs.

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

Re: [tor-bugs] #29528 [Core Tor/Tor]: UndefinedBehaviorSanitizer errors should fail the unit tests

[Tor Bug Tracker & Wiki]

#29528: UndefinedBehaviorSanitizer errors should fail the unit tests
+--
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-ci, tor-test, 041-proposed  |  Actual Points:
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:
+--

Comment (by teor):

 Replying to [comment:3 riastradh]:
 > There is an open Clang bug for this:
 https://bugs.llvm.org/show_bug.cgi?id=19535
 >
 > Possible workaround: use `-fno-sanitize=float-divide-by-zero` in
 addition to `-fsanitize=undefined`.

 Ok, that's a workaround for the specific cases in #29527 which are not
 bugs.
 Let's implement it as part of that ticket?

 We should still fail tests when they encounter genuinely undefined
 behaviour.

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

Re: [tor-bugs] #29527 [Core Tor/Tor]: Division by zero: undefined behaviour in circuitpadding/circuitpadding_sample_distribution test

[Tor Bug Tracker & Wiki]

#29527: Division by zero: undefined behaviour in
circuitpadding/circuitpadding_sample_distribution test
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, tor-ci, tor-test,|  Actual Points:
  040-must   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:7 riastradh]:
 >
 > ...
 >
 > I tried running the tests with tinytest.c modified to do
 `feenableexcept(FE_INVALID)` first thing in tinytest_main (needs `#define
 _GNU_SOURCE` and `#include `).  This turned up only one invalid
 operation in the tests: the logsumexp in test_stochastic_geometric_impl
 slightly exceeds zero, so log1mexp performs an invalid operation (log of
 negative); it is safe to replace `log1mexp(logsumexp(...))` here by
 `log1mexp(fmin(0, logsumexp(...)))` to avoid this.
 >
 > (The issue in test_stochastic_geometric_impl does not invalidate any of
 the test results: the NaN it produced without exceptions trapped was never
 used again in the subsequent computation, because it should have been an
 effectively zero probability (less than e^-100^ = 2^-144^ or something)
 and the corresponding ''count'' is always zero in tests as it should be,
 so psi_test ignores the probability.  If the count were ever nonzero,
 indicating a broken geometric sampler, psi would be computed as a NaN and
 the psi test would fail.  So floating-point arithmetic once again does the
 right thing in the end, though it still would probably be better to use
 `log1mexp(fmin(0, logsumexp(...)))`.)

 Ok, let's fix these issues in this ticket?
 #29528 deals with the general case.

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

Re: [tor-bugs] #29570 [Core Tor/Tor]: Enforce mutually exclusive logic for IPv6 ORPort flags

[Tor Bug Tracker & Wiki]

#29570: Enforce mutually exclusive logic for IPv6 ORPort flags
---+---
 Reporter:  s7r|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:  Tor:
   |  unspecified
 Severity:  Normal | Resolution:
 Keywords:  tor-relay, ipv6, reachability  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 Replying to [ticket:29570 s7r]:
 >
 > ...
 >
 > This is one rare and strange setup of using IPv6 in a way it is not
 intended, but we should still make sure that:
 >
 > - if ORPort [IPv6:address::x]:port '''NoListen''' was set in torrc, and
 there is no following ORPort [IPv6:address::y]:port '''NoAdvertise''' or
 [::]:port '''NoAdvertise''' (as in use all available IPv6 addresses) is
 set, warn in the log and '''do not build the descriptor using the NoListen
 address''', since the daemon is not listening on any address from the v6
 class.

 Here's another way of expressing that rule:
 * on a relay, for each IP family, the number of configured advertised
 addresses must be less than or equal to the number of configured listening
 addresses

 This will require a tor man page change. The spec only talks about
 advertised addresses, so there's no need for a spec change.

 > - check if the logic is applied for IPv4 also, even it's impossible to
 experience this in IPv4 since UnreachableIPv4 doesn't exist and can't
 possibly exist.

 UnreachableIPv4 does exist in the current Tor network. It's called "not
 Running", and it means that the relay is not in the consensus.

 Here are our current address rules:
 1. descriptors can have multiple advertised IPv4 and IPv6 addresses
   * but our tor implementation only puts the first configured address from
 each family in the descriptor
 2. there must be at least one advertised IPv4 addresses in a descriptor
 3. authorities take the first advertised address from each IP family on
 each relay, and test it for reachability
 4. if all of the tested addresses from a relay are reachable, authorities
 put the tested addresses in the consensus

 Rule 2 may change to require dual-stack or IPv6-only in the far future. So
 we shouldn't lock in IPv4 in any other rule.

 > Otherwise we fill the descriptor with useless data and also have the
 directory authorities chase green horses.

 You're right: there's no point in advertising two addresses that go to the
 same port. If we do want a configuration like that, the appropriate way to
 do it is with a (null) pluggable transport.

 > I think we have this since forever, but not marking this as a backport
 given the rare cases when it can occur and the state of current IPv6
 adoption.

 I agree, no backport on this one, it's too risky.

 Replying to [comment:2 s7r]:
 > Actually I am not sure if the correct action here is to just correct the
 descriptor and continue with a warning in logs (in cases of dual stack
 relays where v4 is correctly set-up, but just v6 is not configured
 properly) or better '''terminate and exit''' until everything is either
 corrected, either removed entirely from the config.
 >
 > Thinking on the really long term when IPv6 will take over or at least be
 mandatory in Tor, so we don't have to go back to this. After all, it's
 broken config / setup in terms of relay ports, it's not bad to exit on
 mistakes at such important config parameters.

 Our general policy with address config errors is to break as early and as
 severely as possible.

 We used to try to cope by gracefully degrading to IPv4. But relay
 operators asked us to send a stronger signal, so they know when their IPv6
 configs are broken.

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

Re: [tor-bugs] #29080 [Applications/Tor Browser]: Merge OrbotService and TOPL

[Tor Bug Tracker & Wiki]

#29080: Merge OrbotService and TOPL
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a3,  |  Actual Points:
  TorBrowserTeam201902   |
Parent ID:  #27609   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by sisbell):

 * status:  new => needs_review


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

Re: [tor-bugs] #29573 [Core Tor/Tor]: Tests fail without network interface configured

[Tor Bug Tracker & Wiki]

#29573: Tests fail without network interface configured
-+-
 Reporter:  atsampson|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.8
 Severity:  Normal   | Resolution:
 Keywords:  041-proposed 040-backport|  Actual Points:
  035-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by atsampson):

 Sure - I can reproduce it as root with just:

 {{{
 ./configure
 make
 unshare --net make test
 }}}

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

Re: [tor-bugs] #24338 [Core Tor/Tor]: DirAuths that have IPv6 addresses don't include them in their vote on themself

[Tor Bug Tracker & Wiki]

#24338: DirAuths that have IPv6 addresses don't include them in their vote on
themself
-+-
 Reporter:  tom  |  Owner:  neel
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth, easy, intro,|  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #24403   | Points:  1
 Reviewer:  nickm|Sponsor:
 |  SponsorV-can
-+-
Changes (by nickm):

 * status:  needs_review => merge_ready


Comment:

 Yes; this looks great.  Thanks!

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

Re: [tor-bugs] #25614 [Core Tor/Tor]: tor sets `TOR_PT_EXIT_ON_STDIN_CLOSE=1` only for server transports, not client transports

[Tor Bug Tracker & Wiki]

#25614: tor sets `TOR_PT_EXIT_ON_STDIN_CLOSE=1` only for server transports, not
client transports
---+---
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Minor  | Resolution:
 Keywords:  040-backport 035-backport  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * keywords:   => 040-backport 035-backport
 * milestone:  Tor: unspecified => Tor: 0.4.1.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] #29528 [Core Tor/Tor]: UndefinedBehaviorSanitizer errors should fail the unit tests

[Tor Bug Tracker & Wiki]

#29528: UndefinedBehaviorSanitizer errors should fail the unit tests
+--
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-ci, tor-test, 041-proposed  |  Actual Points:
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:
+--

Comment (by nickm):

 Seems plausible, but could I ask your opinion on the rest of that thread,
 where people are arguing about what's undefined and what isn't?

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

Re: [tor-bugs] #29573 [Core Tor/Tor]: Tests fail without network interface configured

[Tor Bug Tracker & Wiki]

#29573: Tests fail without network interface configured
-+-
 Reporter:  atsampson|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.8
 Severity:  Normal   | Resolution:
 Keywords:  041-proposed 040-backport|  Actual Points:
  035-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:   => 041-proposed 040-backport 035-backport
 * milestone:   => Tor: unspecified


Comment:

 Could you include a short set of instructions to replicate your testing
 environment here, to help us check whether we've fixed it?

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

Re: [tor-bugs] #29537 [Core Tor/Tor]: verify intptr_t round-trip through void *

[Tor Bug Tracker & Wiki]

#29537: verify intptr_t round-trip through void *
+--
 Reporter:  catalyst|  Owner:  (none)
 Type:  defect  | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.4.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  portability technical-debt  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

 * status:  needs_review => needs_revision
 * milestone:  Tor: unspecified => Tor: 0.4.1.x-final


Comment:

 This is a good start! I'd suggest a few more things:

  * Let's not only use 42. Let's check this property for a bunch of
 suspicious values, including: 0..1024 and UINT_MAX-1024..UINT_MAX.  That
 won't catch all possible weird systems, but it will give us a few more
 chances to find corner cases.

  * Let's not put this in test.c; probably, nothing should be in test.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] #29532 [Core Tor/Tor]: Update pre-push hook so that only maint-* and release-* can get pushed to origin.

[Tor Bug Tracker & Wiki]

#29532: Update pre-push hook so that only maint-* and release-* can get pushed 
to
origin.
--+
 Reporter:  nickm |  Owner:  rl1987
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  git-scripts   |  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 I left one more question on the branch. This one might be pretty ignorant,
 since I don't know shell very 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] #25417 [Core Tor/Tor]: HSFETCH support for v3 Hidden Services

[Tor Bug Tracker & Wiki]

#25417: HSFETCH support for v3 Hidden Services
-+-
 Reporter:  atagar   |  Owner:  neel
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-control, tor-hs, prop224-extra,  |  Actual Points:
  onionbalance, 041-proposed |
Parent ID:  #28841   | Points:  0.5
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Seems plausible.  Merging!

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

Re: [tor-bugs] #29065 [Core Tor/Tor]: shellcheck: test_switch_id.sh issues

[Tor Bug Tracker & Wiki]

#29065: shellcheck: test_switch_id.sh issues
+
 Reporter:  rl1987  |  Owner:  rl1987
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  implemented
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  mikeperry   |Sponsor:
+
Changes (by nickm):

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


Comment:

 Squashed and 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] #29562 [Core Tor/Tor]: APPCRASH of tor.exe on Windows when PT bootstrap is cancelled

[Tor Bug Tracker & Wiki]

#29562: APPCRASH of tor.exe on Windows when PT bootstrap is cancelled
---+---
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor:
   |  0.4.0.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.4.0.1-alpha
 Severity:  Normal | Resolution:
 Keywords:  regression 040-must crash  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * cc: ahf (added)
 * keywords:   => regression 040-must crash
 * priority:  Medium => High
 * milestone:   => Tor: 0.4.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] #29080 [Applications/Tor Browser]: Merge OrbotService and TOPL

[Tor Bug Tracker & Wiki]

#29080: Merge OrbotService and TOPL
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a3,  |  Actual Points:
  TorBrowserTeam201902   |
Parent ID:  #27609   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 The pull request has been merged over:
 
https://github.com/thaliproject/Tor_Onion_Proxy_Library/commit/f8124f40e44985938b5d59f8eccf76c56ac72761

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29575 [Applications/Tor Browser]: Configure Firefox Project to Use New TOPL Dependencies

[Tor Bug Tracker & Wiki]

#29575: Configure Firefox Project to Use New TOPL Dependencies
-+-
 Reporter:  sisbell  |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-mobile, TBA-a3,
 Severity:  Normal   |  TorBrowserTeam201902
Actual Points:   |  Parent ID:  #27609
   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] #29574 [Applications/Tor Browser]: Configure Orbot to Use TOPL and tor-android-service Libraries

[Tor Bug Tracker & Wiki]

#29574: Configure Orbot to Use TOPL and tor-android-service Libraries
-+-
 Reporter:  sisbell  |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-mobile, TBA-a3,
 Severity:  Normal   |  TorBrowserTeam201902
Actual Points:   |  Parent ID:  #27609
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 TOPL and tor-android-service libraries will replace orbotservice module
 within orbot project.

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

Re: [tor-bugs] #29572 [Applications/Tor Browser]: Fetching latest commits fails with older git versions when building testbuilds

[Tor Bug Tracker & Wiki]

#29572: Fetching latest commits fails with older git versions when building
testbuilds
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [comment:1 boklm]:
 > Maybe the test to see if we are on a branch is not working?
 >
 > To check that, you can go to the directory `git_clones/tor` and run:
 > {{{
 >  git symbolic-ref HEAD
 > }}}
 > And check that the output from this command exist in `.git`.

 I get `refs/heads/master` and `.git/HEAD` shows `ref: refs/heads/master`.

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

Re: [tor-bugs] #29545 [Internal Services/Tor Sysadmin Team]: Please create email alias/forwarding and LDAP for anarcat

[Tor Bug Tracker & Wiki]

#29545: Please create email alias/forwarding and LDAP for anarcat
-+
 Reporter:  ewyatt   |  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  High |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by ln5):

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


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

Re: [tor-bugs] #29537 [Core Tor/Tor]: verify intptr_t round-trip through void *

[Tor Bug Tracker & Wiki]

#29537: verify intptr_t round-trip through void *
+--
 Reporter:  catalyst|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  portability technical-debt  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by rl1987):

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

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

Re: [tor-bugs] #29537 [Core Tor/Tor]: verify intptr_t round-trip through void *

[Tor Bug Tracker & Wiki]

#29537: verify intptr_t round-trip through void *
+--
 Reporter:  catalyst|  Owner:  (none)
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  portability technical-debt  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by rl1987):

 * status:  new => needs_review


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

[tor-bugs] #29573 [Core Tor/Tor]: Tests fail without network interface configured

[Tor Bug Tracker & Wiki]

#29573: Tests fail without network interface configured
--+--
 Reporter:  atsampson |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Low   |  Component:  Core Tor/Tor
  Version:  Tor: 0.3.5.8  |   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 I build packages on Linux as an unprivileged user inside a network
 namespace with no interfaces configured (to catch packages that try to use
 Internet resources during the build process). With tor 0.3.5.7 and
 earlier, this worked fine and the test suite passed completely.

 With tor 0.3.5.8, three test cases fail:

 {{{
 address/get_if_addrs_list_internal: Feb 24 12:59:28.031 [err] connect()
 failed: Network is unreachable
   [get_if_addrs_list_internal FAILED]
 address/get_if_addrs_list_no_internal: Feb 24 12:59:28.040 [err] connect()
 failed: Network is unreachable
   [get_if_addrs_list_no_internal FAILED]
 address/get_if_addrs: Feb 24 12:59:28.309 [err] connect() failed: Network
 is unreachable
   [get_if_addrs FAILED]
 }}}

 Here's strace output for one of the failures:

 {{{
 socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_UDP) = 6
 connect(6, {sa_family=AF_INET, sin_port=htons(9),
 sin_addr=inet_addr("18.0.0.1")}, 16) = -1 ENETUNREACH (Network is
 unreachable)
 }}}

 So this looks like get_interface_address6_via_udp_socket_hack failing -
 comments in the tests suggest that they ought to be getting an empty list
 rather than an error in this circumstance?

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

Re: [tor-bugs] #29572 [Applications/Tor Browser]: Fetching latest commits fails with older git versions when building testbuilds

[Tor Bug Tracker & Wiki]

#29572: Fetching latest commits fails with older git versions when building
testbuilds
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by boklm):

 I have also been doing some builds using git 2.1.4 (from Debian Jessie),
 and did not have this issue. So I am not sure it is related to the git
 version.

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

Re: [tor-bugs] #29572 [Applications/Tor Browser]: Fetching latest commits fails with older git versions when building testbuilds

[Tor Bug Tracker & Wiki]

#29572: Fetching latest commits fails with older git versions when building
testbuilds
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by boklm):

 The issue seems to be that we are on a branch while we do the `git fetch`.

 But we are supposed to do a `git checkout --detach` when we are on a
 branch:
 {{{
 my ($ref, undef, $success) = capture_exec('git', 'symbolic-ref',
 'HEAD');
 chomp $ref;
 if ($success && -e ".git/$ref") {
 system('git', 'checkout', '-q', '--detach') == 0
 || exit_error "Error running git checkout --detach";
 }
 }}}

 Maybe the test to see if we are on a branch is not working?

 To check that, you can go to the directory `git_clones/tor` and run:
 {{{
  git symbolic-ref HEAD
 }}}
 And check that the output from this command exist in `.git`.

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

[tor-bugs] #29572 [Applications/Tor Browser]: Fetching latest commits fails with older git versions when building testbuilds

[Tor Bug Tracker & Wiki]

#29572: Fetching latest commits fails with older git versions when building
testbuilds
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-rbm
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Trying to build a test build on one of my build machines surprisingly
 failed during the fetch step with the following error:
 {{{
 ./rbm/rbm build release --target testbuild --target torbrowser-
 windows-i686
 fatal: Refusing to fetch into current branch refs/heads/master of non-bare
 repository
 Error: Error fetching git repository
 Makefile:117: recipe for target 'testbuild-windows-i686' failed
 }}}
 Instrumenting `rbm` showed me that this happens when `git` is trying to
 fetch the latest commits for the `tor` repo but there aren't any new ones.
 I compared the `rbm` config etc. with one of my other build machines where
 this issue does not show up and the only difference I found so far is the
 `git` version. On the succeeding machine I have 2.11.0 and on the failing
 one 2.1.4.

 So, I am assuming right now that something between those versions got
 fixed in `git` that made the error go away. We should (a) figure out
 whether that theory is correct and, if so, (b) think about whether we want
 to support the older `git` versions affected by this and, if so, (c) think
 about a good workaround.

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

Re: [tor-bugs] #28933 [Core Tor/sbws]: Run one sbws main loop using the test network as part of integration tests

[Tor Bug Tracker & Wiki]

#28933: Run one sbws main loop using the test network as part of integration 
tests
---+---
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:  implemented
 Keywords: |  Actual Points:
Parent ID:  #28663 | Points:
 Reviewer:  dgoulet|Sponsor:
---+---
Changes (by juga):

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


Comment:

 Merged.

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

Re: [tor-bugs] #28866 [Core Tor/sbws]: ResultDump.queue.put() can hang if the queue is full

[Tor Bug Tracker & Wiki]

#28866: ResultDump.queue.put() can hang if the queue is full
---+---
 Reporter:  teor   |  Owner:  juga
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28663 | Points:  1
 Reviewer:  mikeperry  |Sponsor:
---+---
Changes (by juga):

 * status:  needs_revision => needs_review


Comment:

 I like last solution, i added a commit with it.
 Changed slightly the commit message.

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