Re: [tor-bugs] #17857 [Core Tor/Tor]: Create a consensus param to disable (netflow) padding if RSOS is enabled

[Tor Bug Tracker & Wiki]

#17857: Create a consensus param to disable (netflow) padding if RSOS is enabled
---+
 Reporter:  teor   |  Owner:  mikeperry
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  rsos, sos, tor-hs  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:
---+

Comment (by teor):

 Replying to [comment:20 mikeperry]:
 > FYI: I am working on this. I am going to implement the simple emergency
 killswitch I described in comment:13. Clients won't be able to override
 the consensus, unless they recompile to remove the check (it will be
 client-side enforced, because relays don't know if we're RSOS or Tor2Web).
 >
 > To check for tor2web and RSOS, I'm going to check
 get_options()->Tor2WebMode and get_options()->HiddenServiceSingleHopMode.
 Let me know if I should be checking something else.

 rend_non_anonymous_mode_enabled() will tell you if either Tor2web or v2
 single onion services are enabled.

 I opened #22694 in 0.3.2 to make sure we do this for v3 single onion
 services. (v3 tor2web isn't being 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

[tor-bugs] #22694 [Core Tor/Tor]: prop224: Disable netflow padding if v3 single onion services are enabled

[Tor Bug Tracker & Wiki]

#22694: prop224: Disable netflow padding if v3 single onion services are enabled
--+---
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  prop224, single-onion
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+---
 Once #17857 is implemented, we need to do the same thing for v3 single
 onion services.

 That could be harder, because we need to decide what to do for a mixed
 single onion/anonymous onion instance. Maybe we shouldn't allow 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

[tor-bugs] #22693 [Applications/Tor Browser]: Connection not secure OS leak

[Tor Bug Tracker & Wiki]

#22693: Connection not secure OS leak
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 When I try to create a account on a onion site I get a message that says
 "connection is not secure logins entered here can be compromised." When I
 click on the dialog it links me to a support article, but the link shows
 my real OS, Darwin. Here is the link that

 https://support.mozilla.org/1/firefox/52.2.0/Darwin/en-US/insecure-
 password

 info on Darwin
 https://en.wikipedia.org/wiki/Darwin_%28operating_system%29

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

Re: [tor-bugs] #22659 [Applications/Tor Browser]: Changes to `intl.accept.languages` get overwritten after restart

[Tor Bug Tracker & Wiki]

#22659: Changes to `intl.accept.languages` get overwritten after restart
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-7.0-issues, tbb-regression,  |  Actual Points:
  TorBrowserTeam201706, GeorgKoppen201706|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:9 cypherpunks]:
 > Others enjoy it too https://bugzilla.mozilla.org/show_bug.cgi?id=654099

 But isn't that bug about the literal value
 `chrome://global/locale/intl.properties` showing up (as a string)? I think
 this ticket covers a different but possibly related problem.

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

Re: [tor-bugs] #21013 [Metrics/Censorship analysis]: We need a platform for users to report censorship events

[Tor Bug Tracker & Wiki]

#21013: We need a platform for users to report censorship events
-+--
 Reporter:  mrphs|  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  Rapid Response   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by dcf):

 * owner:   => metrics-team
 * component:  - Select a component => Metrics/Censorship analysis


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22692 [Applications/Tor Browser]: Backport Linux content sandboxing from Firefox 54

[Tor Bug Tracker & Wiki]

#22692: Backport Linux content sandboxing from Firefox 54
--+--
 Reporter:  jld   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Tor Browser 7 is based on Firefox ESR 52, so it doesn't have content
 process sandboxing on Linux; that wasn't enabled for non-Nightly builds
 until 54.  It's possible to configure with `--enable-content-sandbox`, but
 there are some bug fixes and improvements that should be backported.  I'm
 told there's interest in doing that, so I came up with a list of patches
 (which merge cleanly, so I also ran some basic tests).

 First, a warning: The sandboxing isn't very strong yet, especially for the
 threats that Tor Browser deals with: it still allows reading any file and
 doing arbitrary `socket` and `connect` calls, for example, so there's
 probably a way for a determined attacker to get a generic sandbox escape,
 and it definitely allows obtaining PII such as MAC addresses.

 The short version: https://github.com/mozilla/gecko-
 dev/compare/esr52...jld:box52-test

 The long version, as a list of Git commit identifiers from the gecko-dev
 repository (I don't know if there's a way to map these to Hg besides
 manually searching for commit messages), with vague descriptions:
 {{{
 2f25df5d1e7405ae76a15fb1c16bc3dd17d6bd98 prlimit64
 f004938bbb928d3d9d04e119c6d448de4808f1d7 string split for pref
 0d2bf66dfdb9601baf8cda464db66dc5773f1758 syscall allowed-list pref
 5de2e3d5f6795f315a7e98319e4845e173b96ad8 vector fix for pref
 eb0d19601af5af2228f7069243044f8ff4c5be73 crash-on-error flag
 f2fa27edcadaa6ff38cbc16216b4cc63d438ae42 reporter part 1
 f0666046d67d7d384eb458506e472091822c198a reporter part 2
 6e97575e73b58a2ddcf76b244a93e4606d686a17 reporter part 3
 7d9acbdacefe00cca9f9eaf8144900d29fa16d9b less networking
 3c4e5389537a6841080e2e50390af2174e2d4f5c unbreak a11y (???)
 f6b03fa2606c2892ffc903967eb6d7eab0a763a6 socketpair workaround
 4821de2b5839e3f33d4ac647262d5d5255a71708 enable on non-nightly
 dc7a177384f8f7acb94654b81c1af45b427d9260 gdbinit signal change
 8f8a9f525559c6611de13fe5264753e5d62fa85b test "todo" fix
 }}}

 The most important part is the patch from bug 1286865 that makes
 unexpected syscalls just fail instead of crashing on non-Nightly builds
 ("crash-on-error flag", above).  There are two big optional pieces: the
 three patches from bugs 1330326 and 1335323 that add a pref that's a list
 of additional syscall numbers to allow (to make it easier to deal with
 system libraries doing unexpected things), and the three other patches
 from bug 1286865 that expose a log of rejected syscalls in about:support
 (the "reporter"; it will still log to stderr without those).

 The patch I've labelled "unbreak a11y" (which allows `accept4`) might not
 be necessary; I think we still disable e10s on non-Nightly if
 accessibility tools are in use.  Alternately, commit `293bbaf3e964` from
 bug 1361338 could be used instead but I haven't tried it on 52.

 The one thing I know this breaks is WebRTC getting local network addresses
 (see bugs 1345511, 1375122, and 1322506 for background; note that there
 are other ways of getting that info that aren't blocked yet), but Tor
 Browser disables WebRTC.  Similarly, I've left out the part of bug 1286865
 that submits Telemetry about rejected syscalls.  There are also some
 patches I omitted where returning an error won't break anything, or where
 it's related to a feature (like WebAssembly) that's not on 52 ESR.

 Hopefully that explains things well enough; let me know if anything needs
 more clarification.

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

Re: [tor-bugs] #4019 [Core Tor/Tor]: Tor warns about public SocksPort addresses twice on startup

[Tor Bug Tracker & Wiki]

#4019: Tor warns about public SocksPort addresses twice on startup
---+---
 Reporter:  rransom|  Owner:  isis
 Type:  defect | Status:
   |  needs_review
 Priority:  Low|  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-client, easy, review-group-18  |  Actual Points:
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:
---+---
Changes (by isis):

 * status:  assigned => needs_review


Comment:

 Okay, there's a patch in my `bug4091`
 [https://github.com/isislovecruft/tor/tree/bug4091 branch].  While I was
 at it, I also changed the function signature of
 `warn_nonlocal_client_ports()` to make an argument `const` because it's
 only ever read from.

 The patch is basically a one-line fix that says "only respect the value of
 the `CL_PORT_WARN_NONLOCAL` flag if `parse_ports()` wasn't called with
 `validate_only==1`".

 At first, I tried doing a different thing with setting a bit-field on each
 `port_cfg_t` in `warn_nonlocal_client_ports()` (which is called by
 `parse_port_config()`, which is then called by `parse_ports()` in two
 different places), but since `parse_port_config()` sets up the smartlist
 it just loses the marker that we had already warned and still warns twice.

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

[tor-bugs] #22691 [Core Tor/Chutney]: Add a chutney network with a HS via a bridge

[Tor Bug Tracker & Wiki]

#22691: Add a chutney network with a HS via a bridge
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 This would be useful to test the HSDir one-hop checks in #22688.

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

Re: [tor-bugs] #22689 [Core Tor/Tor]: prop224: Stop rend and intro points being used as single hop proxies

[Tor Bug Tracker & Wiki]

#22689: prop224: Stop rend and intro points being used as single hop proxies
---+
 Reporter:  teor   |  Owner:
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  prop224, relay-safety  |  Actual Points:
Parent ID:  #17945 | Points:  0.5
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * status:  new => needs_revision


Old description:

> This prevents them knowing both the service and client IP addresses, and
> therefore being targets for network traffic logging, sybil, or hacking
> attacks.
>
> We need to implement the following checks:
> * if the introduction point was made using a direct connection (single
> onion services), refuse direct client connections,
> * if the rend point was made using a direct connection (custom client, no
> tor2web for HSv3), refuse direct service connections (single onion
> services).
>
> See #22668 for how this is done for HSDir3s using channel_is_client().
> The comments in that patch explain why it works.
>
> We could even refactor the common code out of
> connection_dir_is_anonymous() into connection_is_anonymous(), and avoid
> including channel[tls].h into directory.c.
>
> I'm not sure if I will get time to do this, so please feel free to take
> this ticket.

New description:

 This prevents them knowing both the service and client IP addresses, and
 therefore being targets for network traffic logging, sybil, or hacking
 attacks.

 We need to implement the following checks:
 * if the introduction point was made using a direct connection (single
 onion services), refuse direct client connections,
 * if the rend point was made using a direct connection (custom client, no
 tor2web for HSv3), refuse direct service connections (single onion
 services).

 See #22688 for how this is done for HSDir3s using channel_is_client(). The
 comments in that patch explain why it works.

 We could even refactor the common code out of
 connection_dir_is_anonymous() into connection_is_anonymous(), and avoid
 including channel[tls].h into directory.c.

 I'm not sure if I will get time to do this, so please feel free to take
 this ticket.

--

Comment:

 See cddff59c0 in my branch bug22688-031 for code that might work for OR
 circuits.
 (I accidentally wrote the OR version rather than the directory 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] #22690 [Core Tor/Tor]: SR: Authorities can add a reveal to their own vote, but expect a commit in all votes

[Tor Bug Tracker & Wiki]

#22690: SR: Authorities can add a reveal to their own vote, but expect a commit 
in
all votes
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sr|  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+
Description changed by teor:

Old description:

> {{{
> PASS: hs-min
> Detail: chutney/tools/warnings.sh /Users/USERS/tor/tor-
> master/../chutney/tools/../net/nodes.1498090178
> Warning: SR: Commit from authority
> 234887728412ECD247629DD9888735F1A7AA has a reveal value during COMMIT
> phase. (voter: 234887728412ECD247629DD9888735F1A7AA) Number: 1
> }}}
>
> I will attach the full chutney directory.

New description:

 This is the chutney output:

 PASS: hs-min
 Detail: chutney/tools/warnings.sh /Users/USERS/tor/tor-
 master/../chutney/tools/../net/nodes.1498090178
 Warning: SR: Commit from authority
 234887728412ECD247629DD9888735F1A7AA has a reveal value during COMMIT
 phase. (voter: 234887728412ECD247629DD9888735F1A7AA) Number: 1

 I will attach the full chutney directory.

--

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

Re: [tor-bugs] #22688 [Core Tor/Tor]: Make sure HSDir3s never know service, client, or bridge IP addresses

[Tor Bug Tracker & Wiki]

#22688: Make sure HSDir3s never know service, client, or bridge IP addresses
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  prop224, relay-safety,   |  Actual Points:  0.3
  031-backport, maybe-030-backport-with-21406|
Parent ID:  #17945   | Points:  0.3
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:3 teor]:
 > Do we want to do this for HSv2 service descriptor uploads as well?
 >
 > (We can't do it for HSv2 client descriptor downloads, because tor2web
 does them directly.)

 Yolo, let's do the service descriptor post fix for HSv2 as well.
 See the latest commits in bug22688-031: there was a bug in the original
 code which I fixuped.

 I tested this for v2 hidden services and single onion services (make test-
 network-all) and they all worked. Someone should probably test it with a
 HS with a bridge. (We don't have that set up in chutney yet.)

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

[tor-bugs] #22690 [Core Tor/Tor]: SR: Authorities can add a reveal to their own vote, but expect a commit in all votes

[Tor Bug Tracker & Wiki]

#22690: SR: Authorities can add a reveal to their own vote, but expect a commit 
in
all votes
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-sr
Actual Points:|  Parent ID:
   Points:  2 |   Reviewer:
  Sponsor:|
--+
 {{{
 PASS: hs-min
 Detail: chutney/tools/warnings.sh /Users/USERS/tor/tor-
 master/../chutney/tools/../net/nodes.1498090178
 Warning: SR: Commit from authority
 234887728412ECD247629DD9888735F1A7AA has a reveal value during COMMIT
 phase. (voter: 234887728412ECD247629DD9888735F1A7AA) Number: 1
 }}}

 I will attach the full chutney directory.

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

Re: [tor-bugs] #22689 [Core Tor/Tor]: prop224: Stop rend and intro points being used as single hop proxies

[Tor Bug Tracker & Wiki]

#22689: prop224: Stop rend and intro points being used as single hop proxies
---+
 Reporter:  teor   |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  prop224, relay-safety  |  Actual Points:
Parent ID:  #17945 | Points:  0.5
 Reviewer: |Sponsor:
---+

Comment (by teor):

 We can do this for HSv2 rend points when we implement this patch, because
 single onion services retry a 3-hop path on failure.

 But we can't fix HSv2 intro points, because tor2web doesn't retry a 3-hop
 path (#19662).

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

Re: [tor-bugs] #20104 [Core Tor/Tor]: Tor2web should connect to HSDirs over a 3-hop path

[Tor Bug Tracker & Wiki]

#20104: Tor2web should connect to HSDirs over a 3-hop path
-+--
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor2web  |  Actual Points:
Parent ID:  #17945   | Points:  1
 Reviewer:   |Sponsor:
-+--
Changes (by teor):

 * parent:   => #17945


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

Re: [tor-bugs] #17945 [Core Tor/Tor]: Stop Tor2Web connecting to (Rendezvous) Single Onion Services

[Tor Bug Tracker & Wiki]

#17945: Stop Tor2Web connecting to (Rendezvous) Single Onion Services
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rsos, sos, tor2web, tor-hs,  |  Actual Points:
  029-proposed, 029-teor-no, needs-design,   |
  needs-proposal-maybe   |
Parent ID:   | Points:  5
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:20 teor]:
 > We should do this for HSDirs as well. If the upload came directly (a
 custom tor version - Single Onion Services use a 3-hop path), they should
 refuse direct downloads (Tor2web does direct downloads, but we want to fix
 this in #20104).
 >
 > But do we really want to store this information on HSDirs?

 #22668 fixes this issue for HSv3 by rejecting direct descriptor uploads
 and downloads.

 #22689 will fix this for rend and intro points for HSv3.

 So we can close this ticket once they are done and we have deprecated
 HSv2.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22689 [Core Tor/Tor]: prop224: Stop rend and intro points being used as single hop proxies

[Tor Bug Tracker & Wiki]

#22689: prop224: Stop rend and intro points being used as single hop proxies
--+---
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  prop224, relay-safety
Actual Points:|  Parent ID:  #17945
   Points:  0.5   |   Reviewer:
  Sponsor:|
--+---
 This prevents them knowing both the service and client IP addresses, and
 therefore being targets for network traffic logging, sybil, or hacking
 attacks.

 We need to implement the following checks:
 * if the introduction point was made using a direct connection (single
 onion services), refuse direct client connections,
 * if the rend point was made using a direct connection (custom client, no
 tor2web for HSv3), refuse direct service connections (single onion
 services).

 See #22668 for how this is done for HSDir3s using channel_is_client(). The
 comments in that patch explain why it works.

 We could even refactor the common code out of
 connection_dir_is_anonymous() into connection_is_anonymous(), and avoid
 including channel[tls].h into directory.c.

 I'm not sure if I will get time to do this, so please feel free to take
 this ticket.

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

Re: [tor-bugs] #22688 [Core Tor/Tor]: Make sure HSDir3s never know service, client, or bridge IP addresses

[Tor Bug Tracker & Wiki]

#22688: Make sure HSDir3s never know service, client, or bridge IP addresses
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  prop224, relay-safety,   |  Actual Points:  0.3
  031-backport, maybe-030-backport-with-21406|
Parent ID:  #17945   | Points:  0.3
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Do we want to do this for HSv2 service descriptor uploads as well?

 (We can't do it for HSv2 client descriptor downloads, because tor2web does
 them directly.)

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

Re: [tor-bugs] #22688 [Core Tor/Tor]: Make sure HSDir3s never know service, client, or bridge IP addresses

[Tor Bug Tracker & Wiki]

#22688: Make sure HSDir3s never know service, client, or bridge IP addresses
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  prop224, relay-safety,   |  Actual Points:  0.3
  031-backport, maybe-030-backport-with-21406|
Parent ID:  #17945   | Points:  0.3
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:   => #17945


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

Re: [tor-bugs] #21576 [Core Tor/Tor]: Bug: Assertion linked_dir_conn_base failed in connection_ap_handshake_send_begin

[Tor Bug Tracker & Wiki]

#21576: Bug: Assertion linked_dir_conn_base failed in
connection_ap_handshake_send_begin
-+
 Reporter:  alecmuffett  |  Owner:  teor
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.2.9.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  crash, 029-backport  |  Actual Points:  0.5
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+

Comment (by teor):

 nickm: we should probably backport this to 0.2.9 at some point, it seems
 to work in 0.3.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] #22106 [Core Tor/Tor]: Initial Rust support

[Tor Bug Tracker & Wiki]

#22106: Initial Rust support
--+
 Reporter:  Sebastian |  Owner:
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * type:  defect => enhancement


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

Re: [tor-bugs] #22688 [Core Tor/Tor]: Make sure HSDir3s never know service, client, or bridge IP addresses (was: HSDir3s should refuse direct client descriptor uploads and downloads, even if encrypted

[Tor Bug Tracker & Wiki]

#22688: Make sure HSDir3s never know service, client, or bridge IP addresses
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  prop224, relay-safety,   |  Actual Points:  0.3
  031-backport, maybe-030-backport-with-21406|
Parent ID:   | Points:  0.3
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  new => needs_review
 * keywords:  prop224, relay-safety, 031-backport, no-030-backport =>
 prop224, relay-safety, 031-backport, maybe-030-backport-with-21406
 * actualpoints:  0.2 => 0.3
 * points:  0.2 => 0.3


Comment:

 Please see my branch bug22688-031 on github.

 If we want to backport it to 0.3.0, we also need to backport the
 channel_is_client fix in #21406, which was merged in 0.3.1.1-alpha.

 This compiles, but can't actually test this, so dgoulet or asn will need
 to check it against their working HSv3 service and client code.

 This breaks the direct descriptor downloads tor2web used to do in HSv2,
 see #20104. But we don't plan on tor2web in HSv3, so that's ok. (And if we
 do, this is something we should fix.)

 (This patch doesn't check if the circuit is from a relay, that check would
 be redundant.)

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

Re: [tor-bugs] #20104 [Core Tor/Tor]: Tor2web should connect to HSDirs over a 3-hop path

[Tor Bug Tracker & Wiki]

#20104: Tor2web should connect to HSDirs over a 3-hop path
-+--
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor2web  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+--

Comment (by teor):

 And it avoids HSDirs knowing the IP addresses of clients.

 This is fixed for HSv3 in #22688.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22688 [Core Tor/Tor]: HSDir3s should refuse direct client descriptor uploads and downloads, even if encrypted

[Tor Bug Tracker & Wiki]

#22688: HSDir3s should refuse direct client descriptor uploads and downloads, 
even
if encrypted
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core |Version:  Tor: unspecified
  Tor/Tor|   Keywords:  prop224, relay-safety,
 Severity:  Normal   |  031-backport, no-030-backport
Actual Points:  0.2  |  Parent ID:
   Points:  0.2  |   Reviewer:
  Sponsor:   |
-+-
 handle_post_hs_descriptor and handle_get_hs_descriptor_v3 should check
 that the connection is:
 * encrypted, and
 * not from a client (channel_is_client in 0.3.1.1-alpha and later
 correctly identifies unauthenticated peers, which are clients and
 bridges).

 For extra safety, we can check if the circuit is from a relay.

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

Re: [tor-bugs] #4019 [Core Tor/Tor]: Tor warns about public SocksPort addresses twice on startup

[Tor Bug Tracker & Wiki]

#4019: Tor warns about public SocksPort addresses twice on startup
---+---
 Reporter:  rransom|  Owner:  isis
 Type:  defect | Status:  assigned
 Priority:  Low|  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-client, easy, review-group-18  |  Actual Points:
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:
---+---
Changes (by isis):

 * owner:  nickm => isis
 * 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

Re: [tor-bugs] #17625 [Core Tor/Tor]: Reduce initial and ongoing RendPostPeriod for SOS

[Tor Bug Tracker & Wiki]

#17625: Reduce initial and ongoing RendPostPeriod for SOS
+--
 Reporter:  teor|  Owner:  teor
 Type:  enhancement | Status:  closed
 Priority:  Low |  Milestone:  Tor:
|  unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  sos, rsos, single-onion tor-hs  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by teor):

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


Comment:

 We aren't going to implement the ORPort form of single onion services, so
 this ticket is done.

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

Re: [tor-bugs] #17358 [Core Tor/Tor]: Decide what options to disable with Single Onion Services

[Tor Bug Tracker & Wiki]

#17358: Decide what options to disable with Single Onion Services
+--
 Reporter:  teor|  Owner:  teor
 Type:  enhancement | Status:  closed
 Priority:  Medium  |  Milestone:  Tor:
|  unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  sos, rsos, single-onion tor-hs  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by teor):

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


Comment:

 We aren't going to implement the ORPort form of single onion services, so
 this ticket is done.

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

Re: [tor-bugs] #17217 [Core Tor/Tor]: Change clients to automatically use IPv6 if they can bootstrap over it

[Tor Bug Tracker & Wiki]

#17217: Change clients to automatically use IPv6 if they can bootstrap over it
-+-
 Reporter:  teor |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Major| Resolution:
 Keywords:  ipv6 tor-client robustness   |  Actual Points:
  censorship-resistance  |
Parent ID:  #17811   | Points:  medium
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  ipv6 tor-client robustness => ipv6 tor-client robustness
 censorship-resistance


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

Re: [tor-bugs] #17857 [Core Tor/Tor]: Create a consensus param to disable (netflow) padding if RSOS is enabled

[Tor Bug Tracker & Wiki]

#17857: Create a consensus param to disable (netflow) padding if RSOS is enabled
---+
 Reporter:  teor   |  Owner:  mikeperry
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  rsos, sos, tor-hs  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:
---+

Comment (by mikeperry):

 FYI: I am working on this. I am going to implement the simple emergency
 killswitch I described in comment:13. Clients won't be able to override
 the consensus, unless they recompile to remove the check (it will be
 client-side enforced, because relays don't know if we're RSOS or Tor2Web).

 To check for tor2web and RSOS, I'm going to check
 get_options()->Tor2WebMode and get_options()->HiddenServiceSingleHopMode.
 Let me know if I should be checking something 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] #7890 [Core Tor/Tor]: meaningless error message displayed by tor at start up

[Tor Bug Tracker & Wiki]

#7890: meaningless error message displayed by tor at start up
-+-
 Reporter:  mr-4 |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.6-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, usability, english,  |  Actual Points:  0
  logging, easy, review-group-18 |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by catalyst):

 * status:  needs_review => merge_ready


Comment:

 The branch doesn't build for me currently, but it does build when cherry-
 picked onto master.  (It looks like the branch was based on something that
 my compiler doesn't like.)  Otherwise, it looks good to me.

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

Re: [tor-bugs] #4019 [Core Tor/Tor]: Tor warns about public SocksPort addresses twice on startup

[Tor Bug Tracker & Wiki]

#4019: Tor warns about public SocksPort addresses twice on startup
---+---
 Reporter:  rransom|  Owner:  nickm
 Type:  defect | Status:
   |  needs_revision
 Priority:  Low|  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-client, easy, review-group-18  |  Actual Points:
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:
---+---
Changes (by isis):

 * status:  needs_review => needs_revision


Comment:

 If I understood nickm correctly, this needs a revision to use a local
 static variable to keep track of whether we've already warned the user.
 (Also because it's been a while and the patch no longer applies.)

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

Re: [tor-bugs] #22212 [Core Tor/Tor]: [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel padding timeout scheduled 164729ms in the past. Did the monotonic clock just jump?

[Tor Bug Tracker & Wiki]

#22212: [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel
padding timeout scheduled 164729ms in the past. Did the monotonic clock
just jump?
--+
 Reporter:  arma  |  Owner:  mikeperry
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Also you could write the body as:
 {{{
   if (ms_until_pad_for_netflow < 0) {
 int severity = (ms_until_pad_for_netflow < -DFLT_ETC) ? LOG_NOTICE,
 LOG_INFO;
 log_fn(severity, LD_OR, ...)
 return 0;
   }
 }}}
 but I don't know if that's actually any more clear.

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

Re: [tor-bugs] #22212 [Core Tor/Tor]: [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel padding timeout scheduled 164729ms in the past. Did the monotonic clock just jump?

[Tor Bug Tracker & Wiki]

#22212: [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel
padding timeout scheduled 164729ms in the past. Did the monotonic clock
just jump?
--+
 Reporter:  arma  |  Owner:  mikeperry
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 looks ok, needs a changes file?

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

Re: [tor-bugs] #17161 [Core Tor/Tor]: Conform to C++ Core Guidelines for C?

[Tor Bug Tracker & Wiki]

#17161: Conform to C++ Core Guidelines for C?
-+-
 Reporter:  mikeperry|  Owner:
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:  security, c++, c-style maybe-bad-|  Actual Points:
  idea   |
Parent ID:   | Points:  large
 Reviewer:   |Sponsor:
-+-
Changes (by mikeperry):

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


Comment:

 Closing this since there has not been much movement on a safe subset of
 C++, and we're going to look into Rust first for this purpose.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22687 [Webpages/Website]: Please remove text from "Jobs" webpage

[Tor Bug Tracker & Wiki]

#22687: Please remove text from "Jobs" webpage
--+-
 Reporter:  ewyatt|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Please remove/disable the following text from the jobs webpage:

 "At the moment, we don't have any official open positions. Please check
 back soon, though! In the meantime, you may want to glance at our
 volunteers page."

 Thank 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] #22608 [Core Tor/Tor]: Refactor connection_or_set_state(OPEN) to connection_or_set_state_open()

[Tor Bug Tracker & Wiki]

#22608: Refactor connection_or_set_state(OPEN) to connection_or_set_state_open()
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:  review-group-18  |  Actual Points:  .3
Parent ID:   | Points:  .2
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

 * status:  merge_ready => closed
 * resolution:   => implemented
 * actualpoints:   => .3


Comment:

 Merged; thanks for reviewing!

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

Re: [tor-bugs] #22684 [Core Tor/Tor]: Expose we_fetch_{micro, router_}descriptors on control port

[Tor Bug Tracker & Wiki]

#22684: Expose we_fetch_{micro,router_}descriptors on control port
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-control   |  Actual Points:  .1
Parent ID:| Points:  .1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  accepted => needs_review
 * actualpoints:   => .1


Comment:

 See branch `ticket22684` in my public tor repository, and branch
 `ticket22684_spec` in my public torspec repository.

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

Re: [tor-bugs] #20497 [Applications/Tor Browser]: Add --enable-tor-browser-data-in-home-dir configure option and code

[Tor Bug Tracker & Wiki]

#20497: Add --enable-tor-browser-data-in-home-dir configure option and code
--+--
 Reporter:  attila|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TBB   |  Actual Points:
Parent ID:  #20557| Points:
 Reviewer:|Sponsor:
--+--

Comment (by attila):

 It looks like the world has changed, autoconf is out and python is in.
 The patch I attached to this ticket is probably never going to fly.

 I am studying the new python config/build stuff.  I would like to produce
 a patch that you guys would find acceptable on this in whatever form is
 best, if a patch is even needed.  Please advise at your earliest.

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

Re: [tor-bugs] #22212 [Core Tor/Tor]: [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel padding timeout scheduled 164729ms in the past. Did the monotonic clock just jump?

[Tor Bug Tracker & Wiki]

#22212: [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel
padding timeout scheduled 164729ms in the past. Did the monotonic clock
just jump?
--+
 Reporter:  arma  |  Owner:  mikeperry
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by mikeperry):

 * status:  assigned => needs_review


Comment:

 Ok, I demoted this to notice if the callback is over 10s late, and to info
 if it is less than that. I don't think there is anything more we can do
 here, until we're either multi-threaded for we have a solution for #16585.

 See mikeperry/bug22212 (7914091445e076871bc9fdd41f8304a9b3af8e8c).

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

Re: [tor-bugs] #22686 [Webpages]: Link in Browser Developer job posting doesn't work

[Tor Bug Tracker & Wiki]

#22686: Link in Browser Developer job posting doesn't work
--+-
 Reporter:  ewyatt|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by catalyst):

 Interesting.  Looks like there's a wayward U+200B (zero-width space) in
 the beginning of the href, which causes the link to act like it links to:

 {{{
 
https://www.torproject.org/about/%E2%80%8Bhttps://www.torproject.org/projects/torbrowser/design/#DesignRequirements
 }}}

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

Re: [tor-bugs] #22681 [Metrics/Onionoo]: adapt onionoo to use metrics-lib 1.9.0

[Tor Bug Tracker & Wiki]

#22681: adapt onionoo to use metrics-lib 1.9.0
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Please review
 [https://gitweb.torproject.org/user/karsten/onionoo.git/log/?h=task-22681
 my branch task-22681] which is an improved version of my branch above (and
 which also contains a variant of your patch to make tests compile again).

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

Re: [tor-bugs] #17147 [Core Tor/Tor]: long-running client path-selection not seeing some (fast) exit nodes

[Tor Bug Tracker & Wiki]

#17147: long-running client path-selection not seeing some (fast) exit nodes
-+-
 Reporter:  starlight|  Owner:
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.6.10
 Severity:  Normal   | Resolution:
 Keywords:  tor-client path-selection needs- |  Actual Points:
  diagnosis  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by starlight):

 Running 0.2.9.11 client lately.  I can attempt to reproduce this again if
 it seems relevant and if this version is current enough w/r/t path
 selection code to be useful.

 Reasonably sure the last approach I came up with could work, i.e. set
 UseMicrodescriptors=0, clear caches and restart.  Then awk out a list of
 exits with exit policies.  After awhile repeat and look for cases as
 described above.  I recall thinking some problem exists in the code that
 translates policy descriptors to internal structures used by the path
 selection code.  Even wrote that into the ticket it seems

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

Re: [tor-bugs] #22584 [Applications/Tor Browser]: More RWX memory pages for TBB on some Windows versions

[Tor Bug Tracker & Wiki]

#22584: More RWX memory pages for TBB on some Windows versions
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Some linker fun:
 {{{
 --enable-auto-import
 Do sophisticated linking of _symbol to __imp__symbol for DATA imports
 from DLLs, and create the necessary thunking symbols when building the
 import libraries with those DATA exports. Note: Use of the 'auto-import'
 extension will cause the text section of the image file to be made
 writable. This does not conform to the PE-COFF format specification
 published by Microsoft.
 }}}

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

Re: [tor-bugs] #22422 [Core Tor/Tor]: Add noise to PaddingStatistics

[Tor Bug Tracker & Wiki]

#22422: Add noise to PaddingStatistics
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  privcount |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by mikeperry):

 Replying to [comment:7 teor]:
 > Replying to [comment:6 mikeperry]:
 > > To know how many padding cells to expect for a client, we need
 information on how long an average client's connection lasts,
 >
 > Using closed connections to count clients (and also not quite the time
 interval you're after):
 > "Tor has about 700 thousand unique clients connecting to the network
 during an average 10-minute interval."

 This doesn't tell us how long a *single* client remains connected on
 average.

 > > how often they make connections during a 24 hour interval,
 >
 > "Compared to Tor’s own estimate of about 1.75 million clients per day in
 May 2016..., this suggests that the client population turns over about 2.5
 times a day."

 This doesn't tell us how many connections a *single* makes in a day.

 > > and what percentage of the time those connections are idle. Do we have
 this data?
 >
 > "Somewhat surprisingly, we found that about 130 thousand clients have
 in-
 > active circuits during an average 10 minutes."
 >
 > (That is, closed connections with no circuits with more than 8 cells
 either sent or received.)

 This doesn't tell us how *long* a single connection remains idle, on
 average.

 > > Also, is there a good example of where we add noise in a way
 successfully calculates how to hide a single client's activity? It would
 be helpful to have a reference to work off of.
 >
 > Pages 7-8 of the PrivCount paper give the theory behind differential
 noise.
 > I am not sure where to find anything similar in the tor code.
 > When we add noise, we've done it inconsistently and arbitrarily in the
 past.

 Right now, it looks like this is where we're headed here, too.

 > Perhaps Rob or Aaron can help?

 I'm hoping Karsten can 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] #22255 [Core Tor/Tor]: Frequent OOM kills of tor process

[Tor Bug Tracker & Wiki]

#22255: Frequent OOM kills of tor process
--+
 Reporter:  DeS   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by DeS):

 Sorry about the late reply - Summer flu got me.

 Swappiness
 {{{
 root@tor1:~#  cat /proc/sys/vm/swappiness
 60
 }}}
 smem -kwt  added to memory logger.

 DisableAllSwap 1 configured. Had to add
 {{{
   capability sys_resource,
   capability ipc_lock,
 }}}
 to apparmor config for tor to start it.


 Waiting for next event.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22686 [Webpages]: Link in Browser Developer job posting doesn't work

[Tor Bug Tracker & Wiki]

#22686: Link in Browser Developer job posting doesn't work
--+-
 Reporter:  ewyatt|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 The link in the Browser Developer job posting doesn't work. It displays
 the correct url, but doesn't link to it when you click on it.

 https://www.torproject.org/projects/torbrowser/design/#DesignRequirements

 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] #22608 [Core Tor/Tor]: Refactor connection_or_set_state(OPEN) to connection_or_set_state_open()

[Tor Bug Tracker & Wiki]

#22608: Refactor connection_or_set_state(OPEN) to connection_or_set_state_open()
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-18  |  Actual Points:
Parent ID:   | Points:  .2
 Reviewer:   |Sponsor:
-+
Changes (by catalyst):

 * status:  needs_review => merge_ready


Comment:

 Thanks! Looks good to me. Definitely a noteworthy achievement!

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

Re: [tor-bugs] #22684 [Core Tor/Tor]: Expose we_fetch_{micro, router_}descriptors on control port

[Tor Bug Tracker & Wiki]

#22684: Expose we_fetch_{micro,router_}descriptors on control port
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-control   |  Actual Points:
Parent ID:| Points:  .1
 Reviewer:|Sponsor:
--+

Comment (by atagar):

 Sure, those names sound fine to me.

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

Re: [tor-bugs] #22685 [Core Tor/Tor]: policy for acceptable licenses from contributors

[Tor Bug Tracker & Wiki]

#22685: policy for acceptable licenses from contributors
--+
 Reporter:  catalyst  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Basically, I'm okay with 3-clause BSD or anything more permissive.

 I have no philosophical objection to copylefted stuff in general, but I am
 not okay with changing the terms under which we distribute Tor.

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

Re: [tor-bugs] #16858 [Core Tor/Tor]: Non-ascii country code in extrainfo descriptor

[Tor Bug Tracker & Wiki]

#16858: Non-ascii country code in extrainfo descriptor
-+
 Reporter:  atagar   |  Owner:
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-relay geoip  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by cypherpunks):

 Replying to [comment:9 atagar]:
 > Relay's still around. I'm now
 
[https://gitweb.torproject.org/doctor.git/commit/?id=96014b1ad9f349c88ae3df160e6a073a165857fa
 suppressing these notices in DocTor]. Unfortunately this will mask other
 issues regarding malformed extrainfo descriptors.
 Maybe the DocTor commit should be reverted now. This will help in
 verifying whether the issue is really 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] #22608 [Core Tor/Tor]: Refactor connection_or_set_state(OPEN) to connection_or_set_state_open()

[Tor Bug Tracker & Wiki]

#22608: Refactor connection_or_set_state(OPEN) to connection_or_set_state_open()
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-18  |  Actual Points:
Parent ID:   | Points:  .2
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 new branch is callgraph_reduction_v2.  Better?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22685 [Core Tor/Tor]: policy for acceptable licenses from contributors

[Tor Bug Tracker & Wiki]

#22685: policy for acceptable licenses from contributors
--+
 Reporter:  catalyst  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 We should have a policy statement about what licenses we will accept for
 contributions to Core Tor.  Maybe it should go into `CodingStandards.md`
 or similar.

 It seems like we currently want BSD-licensed code (3-clause?) and maybe
 don't want copylefted stuff?

 Maybe also clarify that patches to an existing file are assumed to be
 copyright-assigned to us or licensed under the same license as the
 original file.

 Bonus points if there's a well-written rationale for our licensing
 choices.  (But maybe that should be a separate ticket.)

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

Re: [tor-bugs] #22608 [Core Tor/Tor]: Refactor connection_or_set_state(OPEN) to connection_or_set_state_open()

[Tor Bug Tracker & Wiki]

#22608: Refactor connection_or_set_state(OPEN) to connection_or_set_state_open()
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-18  |  Actual Points:
Parent ID:   | Points:  .2
 Reviewer:   |Sponsor:
-+

Comment (by nickm):

 Replying to [comment:4 catalyst]:
 > Looks mostly good.

 Thanks for the review!

 >  A few nits: callgraph reduction numbers don't match between commit
 message and this ticket; also it fails check-spaces.

 Will fix; the numbers have fluctuated between when I originally wrote the
 patch and now.  Right now the reduction is 58 -> 28.

 > If it's a factor-of-three reduction in the largest SCC then maybe it
 should get a changes file, too?

 Will fix that too. 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] #22356 [Core Tor/Tor]: [warn] assign_to_cpuworker failed. Ignoring.

[Tor Bug Tracker & Wiki]

#22356: [warn] assign_to_cpuworker failed. Ignoring.
--+
 Reporter:  arma  |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Merged to maint-0.3.1; not considering for backport.

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

Re: [tor-bugs] #22311 [Core Tor/Tor]: authdir_mode_any_nonhidserv() is an obsolete concept

[Tor Bug Tracker & Wiki]

#22311: authdir_mode_any_nonhidserv() is an obsolete concept
---+---
 Reporter:  arma   |  Owner:
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords:  easy, tor-hs, review-group-18  |  Actual Points:
Parent ID: | Points:
 Reviewer:  arma   |Sponsor:
---+---
Changes (by nickm):

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


Comment:

 Fixed; squashed; merged!  Thank 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] #22683 [Metrics/Metrics website]: adapt metrics-web to metrics-lib 2.0.0/1.9.0 changes

[Tor Bug Tracker & Wiki]

#22683: adapt metrics-web to metrics-lib 2.0.0/1.9.0 changes
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  needs_information => needs_review


Comment:

 Please review [https://gitweb.torproject.org/karsten/metrics-
 web.git/log/?h=task-22683 my branch task-22683] which is an improved
 version of the branch above.

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

Re: [tor-bugs] #22684 [Core Tor/Tor]: Expose we_fetch_{micro, router_}descriptors on control port

[Tor Bug Tracker & Wiki]

#22684: Expose we_fetch_{micro,router_}descriptors on control port
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-control   |  Actual Points:
Parent ID:| Points:  .1
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Maybe dir/download-enabled or md/download-enabled ? To me the name
 `is_available` sounds like it's is about whether we have the data right
 now, not whether we will try to get the data and keep it up to date.

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

Re: [tor-bugs] #22684 [Core Tor/Tor]: Expose we_fetch_{micro, router_}descriptors on control port

[Tor Bug Tracker & Wiki]

#22684: Expose we_fetch_{micro,router_}descriptors on control port
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-control   |  Actual Points:
Parent ID:| Points:  .1
 Reviewer:|Sponsor:
--+

Comment (by atagar):

 Thanks Nick! We already have namespacess for descriptors so how about
 these?

 {{{
 GETINFO dir/is_available
 GETINFO md/is_available
 }}}

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

Re: [tor-bugs] #22679 [Core Tor/Stem]: Tor and stem library : non consistent error message with wrong password

[Tor Bug Tracker & Wiki]

#22679: Tor and stem library : non consistent error message with wrong password
---+
 Reporter:  daftaupe   |  Owner:  atagar
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by atagar):

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


Comment:

 That was an interesting one. Turns out there were two issues here...

 * I was improperly performing post-authentication activities when auth
 fails. These follow-up requests caused the socket failures you were
 seeing. Fixed.

 * When closing the socket we called 'QUIT'. When unauthenticated tor
 sometimes responded with 'closing connection' but other times would just
 hang. Stem now skips calling QUIT if not yet authenticated, and reached
 out to Nick to see if this is something we'd care to fix in tor.

 Fixed pushed on...

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

 Thanks for reporting this! Feel free to reopen if you run into any further
 issues.

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

Re: [tor-bugs] #22311 [Core Tor/Tor]: authdir_mode_any_nonhidserv() is an obsolete concept

[Tor Bug Tracker & Wiki]

#22311: authdir_mode_any_nonhidserv() is an obsolete concept
---+---
 Reporter:  arma   |  Owner:
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  easy, tor-hs, review-group-18  |  Actual Points:
Parent ID: | Points:
 Reviewer:  arma   |Sponsor:
---+---

Comment (by huyvq):

 Replying to [comment:10 nickm]:
 > If this still looks okay, I'll rebase and squash and merge.

 It's okay for me. Thanks for the fixup.

 Nitpicking: my handle is `huyvq` (in
 a96fd1263dfb46af1c49d1e5788d7d7996cf812e 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

Re: [tor-bugs] #22356 [Core Tor/Tor]: [warn] assign_to_cpuworker failed. Ignoring.

[Tor Bug Tracker & Wiki]

#22356: [warn] assign_to_cpuworker failed. Ignoring.
--+
 Reporter:  arma  |  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by catalyst):

 * status:  needs_review => merge_ready


Comment:

 Looks good to me.

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

Re: [tor-bugs] #22311 [Core Tor/Tor]: authdir_mode_any_nonhidserv() is an obsolete concept

[Tor Bug Tracker & Wiki]

#22311: authdir_mode_any_nonhidserv() is an obsolete concept
---+---
 Reporter:  arma   |  Owner:
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  easy, tor-hs, review-group-18  |  Actual Points:
Parent ID: | Points:
 Reviewer:  arma   |Sponsor:
---+---
Changes (by nickm):

 * status:  needs_review => merge_ready


Comment:

 Thanks!  I've pulled this into my public repository as `bug22311`.  Here
 are the additional changes I suggest, which I've made on that branch:

  * I've made a fix to use authdir_mode_v3() instead of looking at
 V3AuthoritativeDir directly.
  * Since we no longer call authdir_mode_handles_descs() with purpose==-1,
 I am calling that behavior a bug.

 I also think that we _shouldn't_ take
 99c49cae9f8a354660a53dc2744cd0cc14c2e5b6 ("Remove
 authdir_mode_tests_reachability()") -- at some point in the future, we are
 likely to severely change how reachability testing works, especially on
 the bridge authorities.

 If this still looks okay, I'll rebase and squash and merge.

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

Re: [tor-bugs] #22608 [Core Tor/Tor]: Refactor connection_or_set_state(OPEN) to connection_or_set_state_open()

[Tor Bug Tracker & Wiki]

#22608: Refactor connection_or_set_state(OPEN) to connection_or_set_state_open()
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-18  |  Actual Points:
Parent ID:   | Points:  .2
 Reviewer:   |Sponsor:
-+
Changes (by catalyst):

 * status:  needs_review => needs_revision


Comment:

 Looks mostly good.  A few nits: callgraph reduction numbers don't match
 between commit message and this ticket; also it fails check-spaces.  If
 it's a factor-of-three reduction in the largest SCC then maybe it should
 get a changes file, too?

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

Re: [tor-bugs] #22684 [Core Tor/Tor]: Expose we_fetch_{micro, router_}descriptors on control port

[Tor Bug Tracker & Wiki]

#22684: Expose we_fetch_{micro,router_}descriptors on control port
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-control   |  Actual Points:
Parent ID:| Points:  .1
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Here's the snippet, for when we decide what to name it:
 {{{
 +  } else if (!strcmp(question, "config/we-download-microdescs")) {
 +int r = we_download_microdescriptors(get_options());
 +tor_asprintf(answer, "%d", !!r);
 +  } else if (!strcmp(question, "config/we-download-routerdescs")) {
 +int r = we_download_router_descriptors(get_options());
 +tor_asprintf(answer, "%d", !!r);
}
 }}}

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

Re: [tor-bugs] #22684 [Core Tor/Tor]: Expose we_fetch_{micro, router_}descriptors on control port

[Tor Bug Tracker & Wiki]

#22684: Expose we_fetch_{micro,router_}descriptors on control port
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-control   |  Actual Points:
Parent ID:| Points:  .1
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 16:24 < nickm> "info" seems wrong as a prefix; it's all info
 16:24 < nickm> and config is already used as a prefix

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

Re: [tor-bugs] #5847 [Core Tor/Tor]: Better error message on GETINFO desc/* when you only have MDs.

[Tor Bug Tracker & Wiki]

#5847: Better error message on GETINFO desc/* when you only have MDs.
-+-
 Reporter:  mickeyc  |  Owner:
 Type:  defect   | Status:  closed
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.3.15-alpha
 Severity:  Normal   | Resolution:
 Keywords:  easy, tor-client, tor-control,   |  implemented
  review-group-18|  Actual Points:
Parent ID:   | Points:  small
 Reviewer:  nickm|Sponsor:
-+-
Changes (by nickm):

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


Comment:

 great; merged Ryman-bug5847-squashed, and opened #22684 to talk about a
 better alternative to GETCONF UseMicrodescriptors.

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

Re: [tor-bugs] #22684 [Core Tor/Tor]: Expose we_fetch_{micro, router_}descriptors on control port

[Tor Bug Tracker & Wiki]

#22684: Expose we_fetch_{micro,router_}descriptors on control port
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-control   |  Actual Points:
Parent ID:| Points:  .1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * owner:   => nickm
 * status:  new => accepted


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22684 [Core Tor/Tor]: Expose we_fetch_{micro, router_}descriptors on control port

[Tor Bug Tracker & Wiki]

#22684: Expose we_fetch_{micro,router_}descriptors on control port
--+
 Reporter:  nickm |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-control
Actual Points:|  Parent ID:
   Points:  .1|   Reviewer:
  Sponsor:|
--+
 Right now, stem has some slightly wrong logic:
  https://gitweb.torproject.org/stem.git/tree/stem/control.py#n1828

 We should make GETINFO commands to fetch these.  How about
 {{{
 info/config/we-download-microdescs and
 info/config/we-download-routerdescs
 }}}
 ?

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

Re: [tor-bugs] #22659 [Applications/Tor Browser]: Changes to `intl.accept.languages` get overwritten after restart

[Tor Bug Tracker & Wiki]

#22659: Changes to `intl.accept.languages` get overwritten after restart
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-7.0-issues, tbb-regression,  |  Actual Points:
  TorBrowserTeam201706, GeorgKoppen201706|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Others enjoy it too https://bugzilla.mozilla.org/show_bug.cgi?id=654099

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

Re: [tor-bugs] #7176 [Core Tor/Tor]: Reduced TOR memory consumption for embedded devices

[Tor Bug Tracker & Wiki]

#7176: Reduced TOR memory consumption for embedded devices
-+-
 Reporter:  cypherpunks  |  Owner:
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, embedded, low-memory,|  Actual Points:
  sponsor8-maybe, review-group-18|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => needs_information


Comment:

 > (Are we sure the license on these is cool?)

 I'm not sure we can merge these at all.  The tor-openwrt_0.2.3.19-rc-3.tgz
 file from which they are taken is confusing: It has a GPLv2 LICENSE file
 in its toplevel, and I can't tell whether they wanted that license to
 apply to their patches or not.

 I'm going to try to find out to see if anybody from Access Now can make a
 definitive statement here before I consider them for real merge or
 revision.  Alternatively, if we can't get clarity on the licensing terms,
 we may need to recreate similar work independently in the time-honored
 manner.

 Here is what the patches seem to be trying to do:
   0001-anon_mmap: instead of using a journal file and keeping journaled
 descs in ram, tries to use mmap stuff to append them to the mmap on disk.
   0001-persistent_keys_in_etc: Changes where keys are stored. This should
 be replaced with a separate KeyDirectory torrc option.
   001-rebuild_when_big_dropped: Changes some logic in
 should_rebuild_md_cache() to rebuild the cache more aggressively.
   001-shorter_desc_lifetime: Lowers TOLERATE_MICRODESC_AGE.  This is risky
 and should only be done after analysis of microdescriptor lifetime. Also
 lowers ROUTER_MAX_AGE and OLD_ROUTER_DESC_MAX_AGE.
   002-gzipped-cache: Stores microdescriptors and routerdescs compressed
 with gzip, uses anonymous mmap for decompressing them. May have sync/flush
 issues.

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

Re: [tor-bugs] #5847 [Core Tor/Tor]: Better error message on GETINFO desc/* when you only have MDs.

[Tor Bug Tracker & Wiki]

#5847: Better error message on GETINFO desc/* when you only have MDs.
-+-
 Reporter:  mickeyc  |  Owner:
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.3.15-alpha
 Severity:  Normal   | Resolution:
 Keywords:  easy, tor-client, tor-control,   |  Actual Points:
  review-group-18|
Parent ID:   | Points:  small
 Reviewer:  nickm|Sponsor:
-+-

Comment (by atagar):

 Hi Nick. Stem should be fine. We explicitly check 'GETCONF
 UseMicrodescriptors' rather than relying on the error message so you can
 change that without impacting us.

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

Re: [tor-bugs] #22682 [Metrics/ExoneraTor]: adapt ExoneraTor to metrics-lib 2.0.0/1.9.0 changes

[Tor Bug Tracker & Wiki]

#22682: adapt ExoneraTor to metrics-lib 2.0.0/1.9.0 changes
+--
 Reporter:  iwakeh  |  Owner:  metrics-team
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by karsten):

 * status:  needs_information => needs_review


Comment:

 Please review
 [https://gitweb.torproject.org/user/karsten/exonerator.git/log/?h=task-22682
 my branch task-22682] which is an improved version of the branch above.

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

Re: [tor-bugs] #5847 [Core Tor/Tor]: Better error message on GETINFO desc/* when you only have MDs.

[Tor Bug Tracker & Wiki]

#5847: Better error message on GETINFO desc/* when you only have MDs.
-+-
 Reporter:  mickeyc  |  Owner:
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.3.15-alpha
 Severity:  Normal   | Resolution:
 Keywords:  easy, tor-client, tor-control,   |  Actual Points:
  review-group-18|
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => merge_ready
 * cc: atagar (added)


Comment:

 Looks good.  I rebased and tweaked this as Ryman-bug5847. Damian, will it
 break anything in stem if we merge this?

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

Re: [tor-bugs] #5847 [Core Tor/Tor]: Better error message on GETINFO desc/* when you only have MDs.

[Tor Bug Tracker & Wiki]

#5847: Better error message on GETINFO desc/* when you only have MDs.
-+-
 Reporter:  mickeyc  |  Owner:
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.3.15-alpha
 Severity:  Normal   | Resolution:
 Keywords:  easy, tor-client, tor-control,   |  Actual Points:
  review-group-18|
Parent ID:   | Points:  small
 Reviewer:  nickm|Sponsor:
-+-
Changes (by nickm):

 * reviewer:   => nickm


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

Re: [tor-bugs] #1667 [Core Tor/Tor]: Give a more appropriate "I'm not an HTTP proxy" message when we get an HTTP request on the control port

[Tor Bug Tracker & Wiki]

#1667: Give a more appropriate "I'm not an HTTP proxy" message when we get an 
HTTP
request on the control port
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Very Low  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-client|  Actual Points:
Parent ID:| Points:  small
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * keywords:  easy, tor-client, review-group-18 => tor-client
 * status:  assigned => needs_review


Comment:

 I've rebased and squashed neena's original branch, and made a couple of
 fixes, in branch `neena-fix-1667` in my public repository.  But now I need
 another 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] #1667 [Core Tor/Tor]: Give a more appropriate "I'm not an HTTP proxy" message when we get an HTTP request on the control port

[Tor Bug Tracker & Wiki]

#1667: Give a more appropriate "I'm not an HTTP proxy" message when we get an 
HTTP
request on the control port
---+---
 Reporter:  nickm  |  Owner:  nickm
 Type:  enhancement| Status:  assigned
 Priority:  Very Low   |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  easy, tor-client, review-group-18  |  Actual Points:
Parent ID: | Points:  small
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * owner:  neena => nickm
 * status:  needs_review => assigned


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

Re: [tor-bugs] #18913 [Applications/Tor Browser]: about:tor should not have chrome privileges

[Tor Bug Tracker & Wiki]

#18913: about:tor should not have chrome privileges
-+-
 Reporter:  mcs  |  Owner:  mcs
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, TorBrowserTeam201706R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * status:  needs_revision => needs_review
 * keywords:  ff52-esr, TorBrowserTeam201706 => ff52-esr,
 TorBrowserTeam201706R


Comment:

 Replying to [comment:9 gk]:
 > Looks good to me, thanks! Just some nits:
 > ...

 Thanks for your review! Here is a revised patch that fixes the things you
 found:
 https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug18913-02

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

Re: [tor-bugs] #17665 [Core Tor/Tor]: Drop scheduler config options

[Tor Bug Tracker & Wiki]

#17665: Drop scheduler config options
-+-
 Reporter:  atagar   |  Owner:
 Type:  defect   | Status:  new
 Priority:  Very Low |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Trivial  | Resolution:
 Keywords:  kist-related scheduler tor-relay |  Actual Points:
  kist-may-obsolete  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by pastly):

 If we want to simplify the "vanilla" (current) scheduler with the merge of
 kist, these could certainly go away and either be replaced by `#define`s
 or simplifications of the scheduling loop logic. The behavior of the
 vanilla scheduler vs. the behavior implied by the code is very different,
 and these options are a big reason for that confusion.

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

Re: [tor-bugs] #22659 [Applications/Tor Browser]: Changes to `intl.accept.languages` get overwritten after restart

[Tor Bug Tracker & Wiki]

#22659: Changes to `intl.accept.languages` get overwritten after restart
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-7.0-issues, tbb-regression,  |  Actual Points:
  TorBrowserTeam201706, GeorgKoppen201706|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Kathy and I can reproduce the problem on Linux (but still not on OSX). The
 incorrect value definitely comes from the en-US file (toolkit/locales/en-
 US/chrome/global/intl.properties). We confirmed that by changing the value
 there to `en-US, en, fr` and seeing that when this bug occurs the
 "default" value is indeed `en-US, en, fr`. Your comment:7 experiment is
 interesting. From the URL bar, you saw the correct data but somehow the
 prefs system seems to be ignoring the language pack and consulting the en-
 US intl.properties file. The mystery is why. The
 `general.useragent.locale` pref does not seem to be suffer from the same
 bug even though its value should be determined by the same mechanism.

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

Re: [tor-bugs] #5190 [Core Tor/Tor]: Collect Rob's patch for throttling flows at guards

[Tor Bug Tracker & Wiki]

#5190: Collect Rob's patch for throttling flows at guards
-+-
 Reporter:  arma |  Owner:
 |  robgjansen
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  performance, scheduling, SponsorZ,   |  Actual Points:
  tor-relay, review-group-18 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 I'd put this as needs_review under the impression that somebody should be
 looking at the code at some point. If that's not so, we can put it back
 into "tor:unspecified".

 The "assigned" event was to set you as the owner, since (I think?) you
 wrote the original code here?

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

Re: [tor-bugs] #17684 [Core Tor/Tor]: Simplify directory_get_from_dirserver so it can be unit tested

[Tor Bug Tracker & Wiki]

#17684: Simplify directory_get_from_dirserver so it can be unit tested
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-tests-coverage, tor-tests-unit,  |  Actual Points:
  refactor, technical-debt   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorS-can
-+-
Changes (by nickm):

 * keywords:  tor-tests-coverage, tor-tests-unit => tor-tests-coverage, tor-
 tests-unit, refactor, technical-debt


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

Re: [tor-bugs] #17673 [Core Tor/Tor]: circuit_handle_first_hop assumes all one-hop circuits are directory circuits

[Tor Bug Tracker & Wiki]

#17673: circuit_handle_first_hop assumes all one-hop circuits are directory
circuits
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  technical-debt tor-hs tor-client |  Actual Points:
  accident-waiting-to-happen |
Parent ID:  #17692   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  teordoesntcare029 => technical-debt tor-hs tor-client
 accident-waiting-to-happen


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

Re: [tor-bugs] #17640 [Core Tor/Tor]: Handle CREATE/CREATED cell processing gracefully under load.

[Tor Bug Tracker & Wiki]

#17640: Handle CREATE/CREATED cell processing gracefully under load.
-+-
 Reporter:  yawning  |  Owner:  yawning
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, scaling, tor-dos, tor-relay  |  Actual Points:
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
 |  SponsorU-can
-+-
Changes (by nickm):

 * keywords:  tor-hs, scaling, tor-dos => tor-hs, scaling, tor-dos, tor-
   relay


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

Re: [tor-bugs] #17665 [Core Tor/Tor]: Drop scheduler config options

[Tor Bug Tracker & Wiki]

#17665: Drop scheduler config options
-+-
 Reporter:  atagar   |  Owner:
 Type:  defect   | Status:  new
 Priority:  Very Low |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Trivial  | Resolution:
 Keywords:  kist-related scheduler tor-relay |  Actual Points:
  kist-may-obsolete  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:   => kist-related scheduler tor-relay kist-may-obsolete
 * 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] #17636 [Core Tor/Tor]: Can a single IPv6 bridge failure stop Tor connecting?

[Tor Bug Tracker & Wiki]

#17636: Can a single IPv6 bridge failure stop Tor connecting?
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.6.10
 Severity:  Normal   | Resolution:
 Keywords:  tor-client tor-bridges, ipv6 needs-  |  Actual Points:
  diagnosis  | Points:
Parent ID:   |  medium??
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  bridges, ipv6 => tor-client tor-bridges, ipv6 needs-diagnosis


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

Re: [tor-bugs] #17627 [Core Tor/Tor]: Add missing controller events so we can link every step of the HS dance

[Tor Bug Tracker & Wiki]

#17627: Add missing controller events so we can link every step of the HS dance
---+---
 Reporter:  robgjansen |  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, tor-spec, privcount-maybe  |  Actual Points:
Parent ID: | Points:  3
 Reviewer: |Sponsor:  SponsorR-
   |  can
---+---
Changes (by nickm):

 * keywords:  tor-hs, tor-spec => tor-hs, tor-spec, privcount-maybe


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

Re: [tor-bugs] #17625 [Core Tor/Tor]: Reduce initial and ongoing RendPostPeriod for SOS

[Tor Bug Tracker & Wiki]

#17625: Reduce initial and ongoing RendPostPeriod for SOS
+--
 Reporter:  teor|  Owner:  teor
 Type:  enhancement | Status:  assigned
 Priority:  Low |  Milestone:  Tor:
|  unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  sos, rsos, single-onion tor-hs  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

 * keywords:  sos, rsos, single-onion => sos, rsos, single-onion tor-hs


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

Re: [tor-bugs] #17623 [Core Tor/Tor]: Improve not-a-server behavior of server-only timer callbacks

[Tor Bug Tracker & Wiki]

#17623: Improve not-a-server behavior of server-only timer callbacks
-+-
 Reporter:  nickm|  Owner:
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  tor-relay mainloop refactor  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:   => tor-relay mainloop refactor


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

Re: [tor-bugs] #17591 [Core Tor/Tor]: Use channel padding to obscure circuit setup

[Tor Bug Tracker & Wiki]

#17591: Use channel padding to obscure circuit setup
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  mike-can, term-project-ideas,|  Actual Points:
  padding, intersection-attack   |
Parent ID:   | Points:  6
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  mike-can, term-project-ideas => mike-can, term-project-ideas,
 padding, intersection-attack


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

Re: [tor-bugs] #17387 [Core Tor/Tor]: ExtraRelayDescriptorFields needs proposal number

[Tor Bug Tracker & Wiki]

#17387: ExtraRelayDescriptorFields needs proposal number
--+--
 Reporter:  virgil|  Owner:
 Type:  task  | Status:  new
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-relay |  Actual Points:
Parent ID:| Points:  medium
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * keywords:   => tor-relay


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

Re: [tor-bugs] #17391 [Core Tor/Tor]: (Sandbox) Caught a bad syscall attempt (syscall time) (__NR_time not defined?) (was: (Sandbox) Caught a bad syscall attempt (syscall time))

[Tor Bug Tracker & Wiki]

#17391: (Sandbox) Caught a bad syscall attempt (syscall time) (__NR_time not
defined?)
--+--
 Reporter:  TORques   |  Owner:
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 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

Re: [tor-bugs] #17438 [Core Tor/Tor]: if HSDir is set then report a (blurred) uptime of > 96h

[Tor Bug Tracker & Wiki]

#17438: if HSDir is set then report a (blurred) uptime of > 96h
+--
 Reporter:  toralf  |  Owner:
 Type:  defect  | Status:  new
 Priority:  Very Low|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:  Tor: 0.2.7.4-rc
 Severity:  Normal  | Resolution:
 Keywords:  tor-relay needs-design  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

 * keywords:   => tor-relay needs-design


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

Re: [tor-bugs] #17451 [Core Tor/Tor]: Tor controller [ControlPort] - bruteforce defence measures & detailed logging when listening non-locally

[Tor Bug Tracker & Wiki]

#17451: Tor controller [ControlPort] - bruteforce defence measures & detailed
logging when listening non-locally
-+-
 Reporter:  programings  |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Very Low |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  lorax tor-control defense-in-depth   |  Actual Points:
  dont-do-that-then  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  lorax => lorax tor-control defense-in-depth dont-do-that-then


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

Re: [tor-bugs] #17520 [Core Tor/Tor]: Relax the rend cache failure cleanup timer

[Tor Bug Tracker & Wiki]

#17520: Relax the rend cache failure cleanup timer
-+-
 Reporter:  dgoulet  |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-client, prop224  |  Actual Points:
Parent ID:  #17242   | Points:  1
 Reviewer:   |Sponsor:  SponsorR-can
-+-
Changes (by nickm):

 * keywords:  tor-hs, tor-client => tor-hs, tor-client, prop224


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

Re: [tor-bugs] #17495 [Core Tor/Tor]: Unit-test launch_resolve() in dns.c

[Tor Bug Tracker & Wiki]

#17495: Unit-test launch_resolve() in dns.c
-+-
 Reporter:  rl1987   |  Owner:
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.4-rc
 Severity:  Normal   | Resolution:
 Keywords:  tor-testing, tor-unit-tests dns  |  Actual Points:
Parent ID:  #16831   | Points:  medium?
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  testing, dns, SponsorS-deferred => tor-testing, tor-unit-tests
 dns


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

Re: [tor-bugs] #17521 [Core Tor/Tor]: Support capsicum(4) on FreeBSD

[Tor Bug Tracker & Wiki]

#17521: Support capsicum(4) on FreeBSD
-+-
 Reporter:  yawning  |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, security, sandboxing, |  Actual Points:
  BSD, capsicum  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  tor-relay, security, sandboxing, BSD => tor-relay, security,
 sandboxing, BSD, capsicum


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

Re: [tor-bugs] #17543 [Core Tor/Tor]: Bring some clarity to behavior of net_is_disabled() vs DisableNetwork vs we_are_hibernating()

[Tor Bug Tracker & Wiki]

#17543: Bring some clarity to behavior of net_is_disabled() vs DisableNetwork vs
we_are_hibernating()
-+-
 Reporter:  nickm|  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client sponsor8-maybe|  Actual Points:
  technical-debt refactor|
Parent ID:  #2149| Points:  medium
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:   => tor-client sponsor8-maybe technical-debt refactor


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

Re: [tor-bugs] #17555 [Core Tor/Tor]: Uninstalling deb.torproject.org-keyring doesn't remove the key

[Tor Bug Tracker & Wiki]

#17555: Uninstalling deb.torproject.org-keyring doesn't remove the key
--+
 Reporter:  ageisp0lis|  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  debian|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  new => closed
 * resolution:   => fixed
 * milestone:  Tor: unspecified =>


Comment:

 I see above that it looks like this was indeed fixed in debian, but please
 reopen if not.

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

Re: [tor-bugs] #17579 [Core Tor/Tor]: Split tor-gencert into "make cert" and "sign" portions

[Tor Bug Tracker & Wiki]

#17579: Split tor-gencert into "make cert" and "sign" portions
-+-
 Reporter:  nickm|  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay key-management cli |  Actual Points:
  security   |
Parent ID:   | Points:  medium
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:   => tor-relay key-management cli security


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

Re: [tor-bugs] #22652 [Metrics/CollecTor]: Adapt CollecTor to metrics-lib 1.9.0

[Tor Bug Tracker & Wiki]

#22652: Adapt CollecTor to metrics-lib 1.9.0
---+
 Reporter:  iwakeh |  Owner:  metrics-team
 Type:  enhancement| Status:  needs_revision
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by iwakeh):

 Replying to [comment:7 karsten]:
 > Hmm, I was just about to push to master, but it looks my last patch
 fixed a regression but at the same time broke the unit tests. I'm not
 entirely sure what the best fix is there. Would you want to take a look?

 Sure.

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

Re: [tor-bugs] #22652 [Metrics/CollecTor]: Adapt CollecTor to metrics-lib 1.9.0

[Tor Bug Tracker & Wiki]

#22652: Adapt CollecTor to metrics-lib 1.9.0
---+
 Reporter:  iwakeh |  Owner:  metrics-team
 Type:  enhancement| Status:  needs_revision
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by karsten):

 * status:  merge_ready => needs_revision


Comment:

 Hmm, I was just about to push to master, but it looks my last patch fixed
 a regression but at the same time broke the unit tests. I'm not entirely
 sure what the best fix is there. Would you want to 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