Re: [tor-bugs] #25893 [Internal Services/Service - trac]: trac.tpo captcha broken

[Tor Bug Tracker & Wiki]

#25893: trac.tpo captcha broken
--+-
 Reporter:  cypherpunks   |  Owner:  qbi
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by teor):

 * owner:  (none) => qbi
 * component:  - Select a component => Internal Services/Service - trac


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

Re: [tor-bugs] #22388 [Webpages/Blog]: Put a favicon in place

[Tor Bug Tracker & Wiki]

#22388: Put a favicon in place
---+--
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  reopened
 Priority:  Low|  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22013 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 I'm a long TBB user and I never saw favicon on my browser.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25893 [- Select a component]: trac.tpo captcha broken

[Tor Bug Tracker & Wiki]

#25893: trac.tpo captcha broken
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
--+
 When I input "-x" where x is a positive integer, the trac will return an
 error.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25892 [Core Tor/Tor]: "AccessibleTorPorts" Add a new option and deprecate 2 options

[Tor Bug Tracker & Wiki]

#25892: "AccessibleTorPorts" Add a new option and deprecate 2 options
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
--+
 http://expyuzz4wqqyqhjn.onion/docs/tor-manual.html.en
 RejectPlaintextPorts port,port


 I want my Tor to allow only port 443(HTTPS) and 9877(XMPP).
 But current RejectPlaintextPorts is not easy to use because I have to
 set "RPP 0,1,2,3,4...65535".

 I want something like this:

 AccessibleTorPorts 443,9877
 AccessibleTorPorts reject *


 format:
 AccessibleTorPorts port[,port...]
 AccessibleTorPorts reject [port|*]

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

Re: [tor-bugs] #22388 [Webpages/Blog]: Put a favicon in place

[Tor Bug Tracker & Wiki]

#22388: Put a favicon in place
---+--
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  reopened
 Priority:  Low|  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22013 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by arma):

 Ok, in my Firefox I see the favico, but in my Tor Browser I do not see it.
 I've lost track of how browsers are supposed to behave. Is Tor Browser
 supposed to be displaying the favicon?

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

Re: [tor-bugs] #25882 [Core Tor/Tor]: clients not detecting stale onion service introduction points

[Tor Bug Tracker & Wiki]

#25882: clients not detecting stale onion service introduction points
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:  #22455| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Original poster: can you upload an info (or debug) level log of this bug
 happening for you? The above snippet isn't much to go on. For example, it
 doesn't show your 47 retries or your 112 seconds.

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

Re: [tor-bugs] #25882 [Core Tor/Tor]: clients not detecting stale onion service introduction points

[Tor Bug Tracker & Wiki]

#25882: clients not detecting stale onion service introduction points
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:  #22455| Points:
 Reviewer:|Sponsor:
--+
Changes (by arma):

 * cc: dgoulet (added)


Comment:

 I think #21600 is not as related as you might think, since I think that
 ticket is for the onion service side.

 Theory 1: the intro point went down or was otherwise unreachable, and the
 Tor client made a circuit to try to reach it, but the circuit timed out,
 and so we launch a new parallel one every second, rather than once like we
 had intended. See {{{intro_going_on_but_too_old}}} in circuituse.c.

 Also, while you're looking at that clause:
 {{{
 /* Log an info message if we're going to launch a new intro circ in
  * parallel */
 if (purpose == CIRCUIT_PURPOSE_C_INTRODUCE_ACK_WAIT &&
 !must_be_open && origin_circ->hs_circ_has_timed_out &&
 !circ->marked_for_close) {
 intro_going_on_but_too_old = 1;
 continue;
 }
 }}}

 It isn't until later, in circuit_is_acceptable, which we don't call
 because of the "continue", that we check that the
 origin_circ->hs_circ_has_timed_out was for *our* intended intro point,
 right? What's up with that? I'm cc'ing dgoulet since he touched that code
 recently. I guess it isn't *so* bad, since that bug only controls whether
 we log a (potentially confusing) info-level log?

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

Re: [tor-bugs] #24630 [Core Tor/Tor]: Stop initialising rust git submodules, travis does this automatically

[Tor Bug Tracker & Wiki]

#24630: Stop initialising rust git submodules, travis does this automatically
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very Low |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  tor-ci, 032-backport, teor-was-  |  Actual Points:
  assigned, 034-triage-20180328, |
  034-removed-20180328 very-small|
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:
 tor-ci, 032-backport, teor-was-assigned, 034-triage-20180328,
 034-removed-20180328
 =>
 tor-ci, 032-backport, teor-was-assigned, 034-triage-20180328,
 034-removed-20180328 very-small
 * milestone:  Tor: unspecified => Tor: 0.3.4.x-final


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

Re: [tor-bugs] #25890 [Core Tor/Nyx]: add instructions for running nyx safely to the FAQ

[Tor Bug Tracker & Wiki]

#25890: add instructions for running nyx safely to the FAQ
--+---
 Reporter:  arma  |  Owner:  atagar
 Type:  enhancement   | Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by arma):

 Replying to [comment:5 atagar]:
 > We already have a FAQ entry for
 [https://nyx.torproject.org/#getting_started how to connect].

 Do the instructions there work for Debian relays? Don't they have cookie
 auth set up already, but they put the cookie into a place that you, the
 nyx user, can't reach?

 > But it might require discussing DisableDebuggerAttachment and tor's
 CookieAuthFileGroupReadable default.

 Yeah, I definitely don't want to try to teach users to poorly reconstruct
 part of the debian config just so they can run nyx as a different user. I
 am thinking of the people who are already on debian, who have been
 thinking that recommended advice is for them to sudo to debian-tor and run
 nyx there.

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

Re: [tor-bugs] #25803 [Core Tor/Tor]: Infinite restart loop when daemon crashes

[Tor Bug Tracker & Wiki]

#25803: Infinite restart loop when daemon crashes
--+
 Reporter:  tiejohg2sahth |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  systemd, tor-relay, security-low  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:4 arma]:
 > Replying to [comment:3 teor]:
 > > It doesn't make sense to restart in any of the listed failure modes:
 >
 > I haven't learned much about systemd yet, so please ignore this if you
 have a better handle on things, but: in the past one of Tor's transient
 failure modes was that the system would start it before the system had set
 up its IP addresses (especially true with the world of ipv6), or before
 the system had set up its network interfaces, and if it just gave up right
 then, the system Tor would stay down. So retrying some times, especially
 at first boot, used to make sense.

 It still does, see #25182.

 Here's what I suggest we do:

 Restart after 60 seconds, rather than 0.1 seconds. Slowing the restart
 rate limits automated exploitation, and increases the likelihood that the
 network will be available.
 {{{
 RestartSec=60
 }}}

 We could also avoid restarting when Tor crashes, or exits badly. We would
 need to work out a list of signals and exit statuses that should prevent a
 restart. For example:
 {{{
 RestartPreventExitStatus= 1 6 SIGABRT SIGSEGV
 }}}

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

Re: [tor-bugs] #25890 [Core Tor/Nyx]: add instructions for running nyx safely to the FAQ

[Tor Bug Tracker & Wiki]

#25890: add instructions for running nyx safely to the FAQ
--+---
 Reporter:  arma  |  Owner:  atagar
 Type:  enhancement   | Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by arma):

 nusenu: right, the tor-relay-debian page did indeed assume you were using
 the deb.

 atagar, the goal here is to provide some concrete advice for all the
 people who were trained by arm in the past to su to debian-tor and run arm
 as the debian-tor user. That was a bad idea (because it gives arm
 permissions to things that it doesn't need). The better idea is to add
 the-user-that-will-run-nyx to the debian-tor group, and then use the fact
 that the controlsocket is reachable by anybody in the group so
 authentication can happen smoothly.

 To be more specific, I suggest the question would be something like "How
 should I connect nyx to my relay on Debian?" and the answer would be
 something like "as the user that will be running nyx, run "sudo adduser
 $USER debian-tor" to add your user to the debian-tor group so it can reach
 Tor's controlsocket. Then log out and log back in (so your user is
 actually in the group), and run nyx. This approach is safer than the one
 where you run nyx as the debian-tor user directly, since in that case
 you'd be giving nyx more access to your Tor private files than it needs."

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

Re: [tor-bugs] #25803 [Core Tor/Tor]: Infinite restart loop when daemon crashes

[Tor Bug Tracker & Wiki]

#25803: Infinite restart loop when daemon crashes
--+
 Reporter:  tiejohg2sahth |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  systemd, tor-relay, security-low  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Replying to [comment:3 teor]:
 > It doesn't make sense to restart in any of the listed failure modes:

 I haven't learned much about systemd yet, so please ignore this if you
 have a better handle on things, but: in the past one of Tor's transient
 failure modes was that the system would start it before the system had set
 up its IP addresses (especially true with the world of ipv6), or before
 the system had set up its network interfaces, and if it just gave up right
 then, the system Tor would stay down. So retrying some times, especially
 at first boot, used to make sense.

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

Re: [tor-bugs] #24659 [Core Tor/Tor]: Wrap our sha2 interface in Rust which implements the appropriate traits

[Tor Bug Tracker & Wiki]

#24659: Wrap our sha2 interface in Rust which implements the appropriate traits
-+-
 Reporter:  isis |  Owner:  isis
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, tor-crypto, review-group-34,   |  Actual Points:
  034-triage-20180328|
Parent ID:   | Points:  1
 Reviewer:  nickm|Sponsor:
 |  Sponsor3-can
-+-

Comment (by Hello71):

 I am in favor of option 3.

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

Re: [tor-bugs] #25890 [Core Tor/Nyx]: add instructions for running nyx safely to the FAQ

[Tor Bug Tracker & Wiki]

#25890: add instructions for running nyx safely to the FAQ
--+---
 Reporter:  arma  |  Owner:  atagar
 Type:  enhancement   | Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by atagar):

 We already have a FAQ entry for
 [https://nyx.torproject.org/#getting_started how to connect]. The ask here
 is to add something specifically about permissions. Seems to me this has
 two parts...

 * Our advice for the debian-tor setup. That should probably go in
 [https://trac.torproject.org/projects/tor/wiki/TorRelayGuide#DebianUbuntu
 its trac section].

 * What, if anything, Nyx's FAQ should say. This advice should be
 applicable to everyone.

 The second may take some discussion, and I'd like to see what Roger would
 care to propose first.

 Roger and I are generally in agreement, but we have some difference of
 priorities. In particular Roger is concerned with security edge cases
 whereas I care about usability. This is fine, and no doubt we'll get on
 the same page. But it might require discussing DisableDebuggerAttachment
 and tor's CookieAuthFileGroupReadable default.

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

Re: [tor-bugs] #25024 [Core Tor/Tor]: Add optional spell check to makefile to check for typos in tor source code.

[Tor Bug Tracker & Wiki]

#25024: Add optional spell check to makefile to check for typos in tor source 
code.
-+-
 Reporter:  fristonio|  Owner:  alison
 Type:  enhancement  | Status:  closed
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  tor-comment, review-group-34,|  implemented
  034-triage-20180328|  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:  asn  |Sponsor:
-+-

Comment (by fristonio):

 asn, nickm thanks for your help and feedback.

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

Re: [tor-bugs] #25024 [Core Tor/Tor]: Add optional spell check to makefile to check for typos in tor source code.

[Tor Bug Tracker & Wiki]

#25024: Add optional spell check to makefile to check for typos in tor source 
code.
-+-
 Reporter:  fristonio|  Owner:  alison
 Type:  enhancement  | Status:  closed
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  tor-comment, review-group-34,|  implemented
  034-triage-20180328|  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:  asn  |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Indeed, lgtm!  Merging this to master.  Thanks for the hard work,
 everybody!

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

Re: [tor-bugs] #25705 [Core Tor/Tor]: Refactor circuit_build_failed to separate build vs path failures

[Tor Bug Tracker & Wiki]

#25705: Refactor circuit_build_failed to separate build vs path failures
--+
 Reporter:  mikeperry |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #25546| Points:
 Reviewer:  asn   |Sponsor:  SponsorV-can
--+

Comment (by nickm):

 Roger, are you persuaded?  Asn's testing seems convincing to me, and the
 code looks okay, to the extent that I understand the subtleties.

 Mike and Asn, how far do you think we might want to backport it?  It's
 generally most convenient to have a branch that we plan to backport based
 on the earliest point to which we might want to merge it.

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

Re: [tor-bugs] #24630 [Core Tor/Tor]: Stop initialising rust git submodules, travis does this automatically

[Tor Bug Tracker & Wiki]

#24630: Stop initialising rust git submodules, travis does this automatically
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very Low |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  tor-ci, 032-backport, teor-was-  |  Actual Points:
  assigned, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by Hello71):

 * priority:  Medium => Very Low
 * cc: alex_y_xu@… (added)
 * status:  assigned => needs_review
 * severity:  Normal => Minor


Comment:

 unless I'm missing something, we can just cherry-pick
 https://github.com/teor2345/tor/commit/d219c568abb82e4c564fb8fe95eeb4ac423affc2
 onto the relevant branches. it's not strictly necessary, but good to
 remove unnecessary cruft.

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

Re: [tor-bugs] #25400 [Core Tor/Tor]: CIRC_BW event miscounts, should count all circ data

[Tor Bug Tracker & Wiki]

#25400: CIRC_BW event miscounts, should count all circ data
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-stats, review-group-34, 034  |  Actual Points:
  -roadmap-subtask, 034-triage-20180328, |
  034-included-20180328  |
Parent ID:  #25546   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 lgtm; merged to master!

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

Re: [tor-bugs] #25762 [Core Tor/Tor]: Make periodic events array with flags including when they are enabled/disabled

[Tor Bug Tracker & Wiki]

#25762: Make periodic events array with flags including when they are
enabled/disabled
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-roadmap-subtask, client, |  Actual Points:
  s8-perf|
Parent ID:  #25500   | Points:
 Reviewer:  nickm|Sponsor:
 |  Sponsor8
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 I had a couple of questions on some of the flags, but otherwise this looks
 good.


 Once you've looked at the above questions, and made changes as
 appropriate, two final tests to do, if you haven't already:
   * Does it regress make test-network-all?
   * Does it cause any problems when you change flags on a running Tor
 instance and send it a SIGHUP?

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

Re: [tor-bugs] #24659 [Core Tor/Tor]: Wrap our sha2 interface in Rust which implements the appropriate traits

[Tor Bug Tracker & Wiki]

#24659: Wrap our sha2 interface in Rust which implements the appropriate traits
-+-
 Reporter:  isis |  Owner:  isis
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, tor-crypto, review-group-34,   |  Actual Points:
  034-triage-20180328|
Parent ID:   | Points:  1
 Reviewer:  nickm|Sponsor:
 |  Sponsor3-can
-+-

Comment (by nickm):

 How about

 5. Merge, but don't write any code that requires our hash functions until
 we have the linking issues solved?

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

Re: [tor-bugs] #24378 [Core Tor/Tor]: Prune the list of supported consensus methods

[Tor Bug Tracker & Wiki]

#24378: Prune the list of supported consensus methods
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop290, 034-triage-20180328, fast-  |  implemented
  fix|  Actual Points:
Parent ID:   | Points:  .5
 Reviewer:  teor |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Both merged to 'master' and/or squashed as appropriate.

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

Re: [tor-bugs] #24658 [Core Tor/Tor]: Split/refactor crypto.h into smaller separate modules

[Tor Bug Tracker & Wiki]

#24658: Split/refactor crypto.h into smaller separate modules
-+-
 Reporter:  isis |  Owner:
 |  ffmancera
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-crypto, refactor, review-|  Actual Points:
  group-32, review-group-34, |
  033-triage-20180320, 033-included-20180320 |
Parent ID:   | Points:
 Reviewer:  nickm|Sponsor:
 |  Sponsor8-can
-+-
Changes (by nickm):

 * status:  merge_ready => needs_revision


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

Re: [tor-bugs] #24660 [Core Tor/Tor]: Wrap our PRNG interface(s) in Rust with appropriate traits

[Tor Bug Tracker & Wiki]

#24660: Wrap our PRNG interface(s) in Rust with appropriate traits
-+-
 Reporter:  isis |  Owner:  isis
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, tor-crypto, rng, roadmap, 034  |  Actual Points:
  -roadmap-master, 034-triage-20180328,  |
  034-included-20180328  |
Parent ID:   | Points:  2
 Reviewer:  nickm|Sponsor:
 |  SponsorQ
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Lgtm, except that I instead of exposing only crypto_strongest_rand() as an
 Rng, I think we should either expose only crypto_rand(), or expose both.
 Once that's done I think this is merge_ready.

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

Re: [tor-bugs] #25691 [Core Tor/Tor]: Bridges don't work: Non-fatal assertion !(exit_ei == NULL) failed in onion_pick_cpath_exit

[Tor Bug Tracker & Wiki]

#25691: Bridges don't work: Non-fatal assertion !(exit_ei == NULL) failed in
onion_pick_cpath_exit
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, 034-must 033-backport|  Actual Points:
  033-maybe-must |
Parent ID:   | Points:  0.5
 Reviewer:  dgoulet, teor|Sponsor:
-+-
Changes (by nickm):

 * status:  needs_revision => merge_ready


Comment:

 wow; four typos on two lines.  I ''am'' in rare form!

 Branch updated on github, and squashed as `bug25691_033_again_squashed`.

 That latter branch has now been merged on 0.3.4.  If it causes no trouble
 there, we can backport to 0.3.3

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

Re: [tor-bugs] #24351 [Applications/Tor Browser]: Block Global Active Adversary Cloudflare

[Tor Bug Tracker & Wiki]

#24351: Block Global Active Adversary Cloudflare
-+-
 Reporter:  nullius  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  reopened
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  security, privacy, anonymity, mitm,  |  Actual Points:
  cloudflare |
Parent ID:  #18361   | Points:  1000
 Reviewer:   |Sponsor:
-+-

Comment (by 4chanuser):

 https://boards.4chan.org/g/thread/65641909/and-this-is-why-4chan-https-
 doesnt-matter

 :)

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

Re: [tor-bugs] #25890 [Core Tor/Nyx]: add instructions for running nyx safely to the FAQ

[Tor Bug Tracker & Wiki]

#25890: add instructions for running nyx safely to the FAQ
--+---
 Reporter:  arma  |  Owner:  atagar
 Type:  enhancement   | Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 The question for the FAQ would be:

 "I'm a relay operator, what is the safest way to connect Nyx to my relay?"

 the answer is up to you since you are the best on answering it.

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

Re: [tor-bugs] #25890 [Core Tor/Nyx]: add instructions for running nyx safely to the FAQ

[Tor Bug Tracker & Wiki]

#25890: add instructions for running nyx safely to the FAQ
--+---
 Reporter:  arma  |  Owner:  atagar
 Type:  enhancement   | Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by atagar):

 * status:  assigned => needs_information


Comment:

 This sounds specific to our debian-tor setup to me. That said, happy to
 discuss a Nyx FAQ addition if someone has a particular entry they'd care
 to propose.

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

Re: [tor-bugs] #25803 [Core Tor/Tor]: Infinite restart loop when daemon crashes

[Tor Bug Tracker & Wiki]

#25803: Infinite restart loop when daemon crashes
--+
 Reporter:  tiejohg2sahth |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  systemd, tor-relay, security-low  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * keywords:  systemd? => systemd, tor-relay, security-low
 * points:   => 0.1


Comment:

 I think we might want to use Restart=on-success instead.

 It doesn't make sense to restart in any of the listed failure modes:
 https://www.freedesktop.org/software/systemd/man/systemd.service.html

 Would you like to submit a patch for this?

 The relevant file is:
 https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in

 You may also need to submit separate bugs to the Debian and Ubuntu bug
 trackers to get them fixed.

 I am marking this as security-low, because it could make exploitation
 easier.
 But, it also makes maintaining availability harder, so it weakens our DoS
 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] #25890 [Core Tor/Nyx]: add instructions for running nyx safely to the FAQ (was: relay guide lost the instructions for running nyx safely)

[Tor Bug Tracker & Wiki]

#25890: add instructions for running nyx safely to the FAQ
--+--
 Reporter:  arma  |  Owner:  atagar
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nusenu):

 * owner:  Nusenu => atagar
 * status:  new => assigned
 * component:  Community/Relays => Core Tor/Nyx
 * 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] #25891 [Community/Outreach]: Make sure that our lists have enough moderators

[Tor Bug Tracker & Wiki]

#25891: Make sure that our lists have enough moderators
+
 Reporter:  arma|  Owner:  alison
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Community/Outreach  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by arma):

 a parallel approach we might take would be to block all mail from qq.com
 to those addresses. that could work short-term 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] #25891 [Community/Outreach]: Make sure that our lists have enough moderators

[Tor Bug Tracker & Wiki]

#25891: Make sure that our lists have enough moderators
+
 Reporter:  arma|  Owner:  alison
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Community/Outreach  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by arma):

 atagar notes that he has also stopped reading *-owner aliases this past
 week.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25891 [Community/Outreach]: Make sure that our lists have enough moderators

[Tor Bug Tracker & Wiki]

#25891: Make sure that our lists have enough moderators
+
 Reporter:  arma|  Owner:  alison
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Community/Outreach  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+
 We have a bunch of mailing lists. There are a few people on the
 "listmaster" default list -- me, nickm, qbi, atagar. Some other lists have
 other owners.

 Step one should be to go through
 https://trac.torproject.org/projects/tor/wiki/doc/emailLists
 and see if the maintainers listed on that table are accurate. And update
 it with what we learn. Also there are probably internal (unlisted) lists
 that we should track down and do that process for too.

 Then step two should be to figure out which lists need more help, or a
 fresh set of maintainers, and make that part happen.

 I'm filing this ticket because I'm probably the most active maintainer for
 tor-talk, tor-relays, and tor-dev, and the *-owner aliases for those three
 lists are being bombed with spam starting a week or so ago, and I was
 trying to survive it for the past week but I've now given up and I'm
 filtering all of that mail into a mailbox that I will probably just
 ignore. So, here is our heads-up that the main lists have just lost their
 main maintainer, and maybe we can build a plan to handle it.

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

Re: [tor-bugs] #25890 [Community/Relays]: relay guide lost the instructions for running nyx safely

[Tor Bug Tracker & Wiki]

#25890: relay guide lost the instructions for running nyx safely
--+
 Reporter:  arma  |  Owner:  Nusenu
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Community/Relays  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nusenu):

 thanks for reporting this, would it also satisfy you if this would be in
 the nyx faq?
 https://nyx.torproject.org/#faq

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

Re: [tor-bugs] #25691 [Core Tor/Tor]: Bridges don't work: Non-fatal assertion !(exit_ei == NULL) failed in onion_pick_cpath_exit

[Tor Bug Tracker & Wiki]

#25691: Bridges don't work: Non-fatal assertion !(exit_ei == NULL) failed in
onion_pick_cpath_exit
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, 034-must 033-backport|  Actual Points:
  033-maybe-must |
Parent ID:   | Points:  0.5
 Reviewer:  dgoulet, teor|Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 There are four comment typos: I added comments on GitHub,

 Once that's done, this branch is ready for 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] #23693 [Core Tor/Tor]: 0.3.1.7: Assertion threadpool failed in cpuworker_queue_work

[Tor Bug Tracker & Wiki]

#23693: 0.3.1.7: Assertion threadpool failed in cpuworker_queue_work
-+-
 Reporter:  alif |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.9
 Severity:  Normal   | Resolution:
 Keywords:  prop286, 034-triage-20180328,|  Actual Points:
  034-must crash 033-backport 032-backport   |
  031-backport   |
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by nickm):

 * status:  new => needs_review


Comment:

 I've updated `bug23693_031_redux` with an actual commit to actually work.
 I'm fine merging it to 0.3.1 and forward; we can open a separate ticket to
 test or disable the feature.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25890 [Community/Relays]: relay guide lost the instructions for running nyx safely

[Tor Bug Tracker & Wiki]

#25890: relay guide lost the instructions for running nyx safely
--+
 Reporter:  arma  |  Owner:  Nusenu
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Community/Relays  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 On the tor-relay-debian page, we used to tell people how to configure
 arm/nyx safely: see item 13 on
 https://web.archive.org/web/20171019233402/https://www.torproject.org/docs
 /tor-relay-debian
 The trick is to add your user to the debian-tor group, not to sudo your
 nyx to run as the debian-tor user.

 We seem to have dropped those instructions when we migrated to the wiki
 page at https://trac.torproject.org/projects/tor/wiki/TorRelayGuide

 I noticed just now because I was trying to help another arm/nyx user on
 #tor, who was doing it the wrong way (presumably because they were
 following old instructions from somewhere else, like the old arm
 documentation).

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

Re: [tor-bugs] #25888 [Webpages/Website]: add support for Ubuntu 18.04 LTS to sources.list generator

[Tor Bug Tracker & Wiki]

#25888: add support for Ubuntu 18.04 LTS to sources.list generator
--+--
 Reporter:  cypherpunks   |  Owner:  hiro
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #25889| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * parent:   => #25889


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

Re: [tor-bugs] #25889 [Community/Relays]: add support for Ubuntu 18.04

[Tor Bug Tracker & Wiki]

#25889: add support for Ubuntu 18.04
--+-
 Reporter:  cypherpunks   |  Owner:  cypherpunks
 Type:  enhancement   | Status:  accepted
 Priority:  Medium|  Milestone:
Component:  Community/Relays  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by cypherpunks):

 * owner:  Nusenu => cypherpunks
 * 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

Re: [tor-bugs] #25889 [Community/Relays]: add support for Ubuntu 18.04 (was: add support)

[Tor Bug Tracker & Wiki]

#25889: add support for Ubuntu 18.04
--+
 Reporter:  cypherpunks   |  Owner:  Nusenu
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Community/Relays  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

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

[tor-bugs] #25889 [Community/Relays]: add support

[Tor Bug Tracker & Wiki]

#25889: add support
--+
 Reporter:  cypherpunks   |  Owner:  Nusenu
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Community/Relays  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 The relay guide should be ready once Ubuntu 18.04 is released
 (2018-04-26),
 this depends on #25888

 - wait for #25888 to get committed
 - confirm current instructions work on Ubuntu 18.04

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

Re: [tor-bugs] #25888 [Webpages/Website]: add support for Ubuntu 18.04 LTS to sources.list generator

[Tor Bug Tracker & Wiki]

#25888: add support for Ubuntu 18.04 LTS to sources.list generator
--+--
 Reporter:  cypherpunks   |  Owner:  hiro
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * status:  assigned => needs_review


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

[tor-bugs] #25888 [Webpages/Website]: add support for Ubuntu 18.04 LTS to sources.list generator

[Tor Bug Tracker & Wiki]

#25888: add support for Ubuntu 18.04 LTS to sources.list generator
--+--
 Reporter:  cypherpunks   |  Owner:  hiro
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 patch:

 https://github.com/nusenu/torproject-
 webwml/commit/736c09728ab767bfd4bd9cc454ff65c906a6a82b

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

Re: [tor-bugs] #23354 [Core Tor/Tor]: Remove deterministic download schedule code and configs

[Tor Bug Tracker & Wiki]

#23354: Remove deterministic download schedule code and configs
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  refactor, s8-perf, technical-debt,   |  Actual Points:
  tor-bootstrap, 034-triage-20180328, fast-fix   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 >There is an extra commit c9c26d0 at the start of this branch.

 Okay; I've rebased the branch to remove this commit.

 >I think it was 0.2.9. Do we want to say 0.2.9 in the changes file?

 Makes sense; doing that too.

 I've re-pushed the branch: there are no other changes.

 >The rest seems sensible to me, but I would like someone else to review
 this too.

 Okay -- into needs_review it goes!

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

Re: [tor-bugs] #25440 [Core Tor/Tor]: Broken openat syscall in Sandbox mode

[Tor Bug Tracker & Wiki]

#25440: Broken openat syscall in Sandbox mode
-+-
 Reporter:  ageisp0lis   |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  sandbox, 033-must, regression,   |  Actual Points:
  033-triage-20180326, 033-included-20180326 |
  033-backport, AffectsTails |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 This is also a problem on the soon to be released (2018-04-26) Ubuntu
 18.04 with tor 0.3.2.10.

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

Re: [tor-bugs] #25887 [Applications/GetTor]: OneDrive

[Tor Bug Tracker & Wiki]

#25887: OneDrive
-+-
 Reporter:  sainslie |  Owner:  ilv
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 > I'd like help

 Thanks a lot for offering your help! Patches are welcome:
 https://gitweb.torproject.org/gettor.git/tree/

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25887 [Applications/GetTor]: OneDrive

[Tor Bug Tracker & Wiki]

#25887: OneDrive
-+-
 Reporter:  sainslie |  Owner:  ilv
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 I'd like help to add Amazon Web Services and OneDrive support so as not to
 be reliant upon Google Drive and Dropbox.

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

Re: [tor-bugs] #25885 [Core Tor/Tor]: count_acceptable_nodes() would be more accurate using node_has_preferred_descriptor()

[Tor Bug Tracker & Wiki]

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

 * cc: teor (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] #25691 [Core Tor/Tor]: Bridges don't work: Non-fatal assertion !(exit_ei == NULL) failed in onion_pick_cpath_exit

[Tor Bug Tracker & Wiki]

#25691: Bridges don't work: Non-fatal assertion !(exit_ei == NULL) failed in
onion_pick_cpath_exit
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, 034-must 033-backport|  Actual Points:
  033-maybe-must |
Parent ID:   | Points:  0.5
 Reviewer:  dgoulet, teor|Sponsor:
-+-
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 I've made the requested revisions and opened tickets #25885 and #25886 for
 the more complicated 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

[tor-bugs] #25886 [Core Tor/Tor]: Have frac_nodes_with_descriptors() take and use for_direct_connect

[Tor Bug Tracker & Wiki]

#25886: Have frac_nodes_with_descriptors() take and use for_direct_connect
--+--
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 On their review for #25691, teor notes (about for_direct_connect):

 >We should pass for_direct_conn into this function, and use
 node_has_preferred_descriptor().

 >For the mid and exit case:
 >We won't bootstrap unless we have enough actual mid and exit bandwidth,
 even if we have mids or exits listed as our bridges.
 >
 >For the guard case:
 >The guard case is unchanged for non-bridge clients.
 >
 >The bridge client case could be tricky, because:
 >
 >   1. compute_frac_paths_available() only checks guard-flagged nodes, not
 bridges
 >   2. even if it did check bridges, they don't have bandwidths
 >   3. even if we used a weight of 1 for each bridge, we don't require 65%
 of bridges to be up to bootstrap
 >
 >To workaround this issue, I suggest we make f_guard = 1.0 in
 compute_frac_paths_available() if we are using bridges, and have at least
 one bridge with the preferred descriptor.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25885 [Core Tor/Tor]: count_acceptable_nodes() would be more accurate using node_has_preferred_descriptor()

[Tor Bug Tracker & Wiki]

#25885: count_acceptable_nodes() would be more accurate using
node_has_preferred_descriptor()
--+--
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 On a github review for #25691, Teor notes about count_acceptable_nodes():


 >I think this code is correct, but it's not obvious:
 >
 >  1.  new_route_len() is the only caller
 >  2.  new_route_len() will fail if count_acceptable_nodes() is less than
 the route length.
 >  3.  later functions will fail if there is no guard
 >  4.  later functions will fail if there are not enough subsequent nodes
 for the rest of the route
 >
 >So this check can spuriously succeed when we have no guards, or when we
 have many bridges, and no subsequent nodes. But it can never fail when
 there are actually enough nodes for the path. So this is just an
 optimisation to stop us trying to build lots of circuits when we have no
 descriptors.
 >
 > We could return the number that pass for_direct_connect = 1 and
 for_direct_connect = 0, but that seems unnecessarily complicated.

 I think that we should probably adjust this function to do the careful
 count, but it's safe to defer.

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

Re: [tor-bugs] #25874 [Obfuscation/Snowflake]: DNS-based rendezvous for Snowflake

[Tor Bug Tracker & Wiki]

#25874: DNS-based rendezvous for Snowflake
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by cypherpunks):

 [https://developers.cloudflare.com/1.1.1.1/fun-stuff/dns-over-telegram/
 Bulletproof transport]. Joke, based on real life.

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

Re: [tor-bugs] #25804 [Obfuscation/Snowflake]: Domain fronting to App Engine stopped working

[Tor Bug Tracker & Wiki]

#25804: Domain fronting to App Engine stopped working
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords:  moat   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by cypherpunks):

 Replying to [comment:23 cypherpunks]:
 > > Seems like Signal was affected by this as well (and they seem to have
 been aware of it in advance - from Mar 27, 2018)
 > [https://news.ycombinator.com/item?id=16869269 Rumors]:
 > > Hey, everyone. We spent a decent amount of time at Signal trying to
 come up with alternatives when we first heard rumors that Google was
 disabling domain fronting on GAE.
 Wow, maybe sometime in the future will start learning about Google
 deprecating this or that from SecureDrop leakers at the nytimes/bezos
 post. Truly epic that they didn't even bother to put a notice or
 something, not even a two line blog post. Maybe people should no longer
 base things off anything Google related, and maybe RMS was right.

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

Re: [tor-bugs] #25879 [Applications/Tor Browser]: WebExtensions panels are broken when javascript.enabled is set to false (was: HTTPS Everywhere control panel is broken when JavaScript is turned off)

[Tor Bug Tracker & Wiki]

#25879: WebExtensions panels are broken when javascript.enabled is set to false
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * keywords:  javascript =>
 * owner:  (none) => tbb-team
 * component:  HTTPS Everywhere => Applications/Tor Browser


Comment:

 `status:confirmed`

 > and the question stands whether the new WebExtension API is actually
 less secure than the old XUL in that it has some kind of tied requirements
 to JavaScript for sites :/

 That's not the case since with Safest security setting JS is disabled for
 sites but the WebExtensions are working, it's only when that
 `about:config` switch is manually/extension-ally changed.

 Also I do stand with my (off-topic) comments about your setup being
 dangerous and useless.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25884 [Core Tor/Torsocks]: add support for exitmap requirements

[Tor Bug Tracker & Wiki]

#25884: add support for exitmap requirements
---+-
 Reporter:  cypherpunks|  Owner:  dgoulet
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Torsocks  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 phw wrote a patch for torsocks a long time ago,
 it would be great if this could be adapted to a current version of
 torsocks and merged

 


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

Re: [tor-bugs] #25879 [HTTPS Everywhere]: HTTPS Everywhere control panel is broken when JavaScript is turned off

[Tor Bug Tracker & Wiki]

#25879: HTTPS Everywhere control panel is broken when JavaScript is turned off
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  HTTPS Everywhere  |Version:
 Severity:  Normal| Resolution:
 Keywords:  javascript|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 >> I have HTTPS Everywhere in my toolbar. I also have an old addon called
 JS Switch that turns off JavaScript at the about:config level, it's just a
 toggle for that config option.
 \\
 > Torbutton does the same.
 \\
 Sure. The Button makes for fewer steps. Most of the time I restrict all
 JavaScript.
 \\
 >>Whenever I've used it (or the about:config option directly) to turn off
 JavaScript, HTTPS Everywhere, Privacy Badger, and AdBlock Plus are all
 unable to display their toolbar menus properly or at all. In the case of
 HTTPS Everywhere and Privacy Badger, the menu balloon appears with a few
 words, but most of the words are missing and some of the toggles. The few
 toggles that remain are non functional.
 \\
 > That's a dangerous game you're doing, Privacy Badger and AdBlock Plus
 would make you easily fingerprintable? Also doesn't Privacy Badger record
 all the websites that you visited so that its algorithm works?
 \\
 Not relevant to the bug. Just to answer your question:

 ''This particular'' setup isn't meant to blend the fingerprint, and I'll
 repeat what many users have said over the years, that if TBB had its own
 blockers for ads, tracking, and cross-site requests we wouldn't have to
 install addons to do so. Resistance to the penetration forced by trackers,
 ads, and cross-site requests is every bit as important as anonymity for
 security, in many cases more so.

 If I was interested in blending in completely, I'd just allow my data to
 be collected like everyone else's. At that point the TBB becomes useful
 for only an extremely narrow use case, that being a totally average,
 exposed, and susceptible session which just happens to appear to be online
 at the same location as the exit node. In that mode the TBB is powerful
 pretty much only for very careful espionage and clandestine file transfer.
 Without a few key addons, it does not protect average daily traffic in any
 way other than to trivially (for modern forensics) complicate the trail.
 If I login to my banking site, for instance, with JavaScript permissions
 active, there are easy ways to use it aside from IP to determine origin.

 Furthermore, Privacy Badger is made by EFF just like HTTPS Everywhere, and
 while they do different things, if I as a user can't expect two addons
 made by the same organization, who partners with the Tor project to the
 point that they share a bug tracker, then the whole system is broken and
 there isn't hope for anyway.

 TL;DR, please don't introduce irrelevant conversations to the report.
 \\
 >> Is this some new fallout from the move to WebExtensions?
 \\
 > Are you sure that you have the latest Tor Browser release? I can't
 reproduce this with Safest security setting in the Torbutton.
 \\
 Absolutely certain. All addons and the browser are latest. Also, please
 try turning off JavaScript in about:config just in case you're wrong
 somehow that they work the same.

 Poking into it further, I've realized that the most pronounced effect
 happens when the browser is restarted with JavaScript either on or off.
 Shutting off JavaScript, then restarting the browser, results in text
 balloons for HTTPS Everywhere and AdBlock Plus that are crippled for the
 duration of the session.

 Privacy Badger is actually less affected, after the restarted session, if
 JavaScript is toggled on again, it will function.

 Once JavaScript is turned back on, if the browser is restarted, on start
 every text balloon has functionality restored.

 All of these details are hopefully useful, but don't address **why**
 about:config JavaScript settings affect these addons at all, and the
 question stands whether the new WebExtension API is actually less secure
 than the old XUL in that it has some kind of tied requirements to
 JavaScript for sites :/

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

Re: [tor-bugs] #25804 [Obfuscation/Snowflake]: Domain fronting to App Engine stopped working

[Tor Bug Tracker & Wiki]

#25804: Domain fronting to App Engine stopped working
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords:  moat   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by cypherpunks):

 > Seems like Signal was affected by this as well (and they seem to have
 been aware of it in advance - from Mar 27, 2018)
 [https://news.ycombinator.com/item?id=16869269 Rumors]:
 > Hey, everyone. We spent a decent amount of time at Signal trying to come
 up with alternatives when we first heard rumors that Google was disabling
 domain fronting on GAE.

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

Re: [tor-bugs] #25803 [Core Tor/Tor]: Infinite restart loop when daemon crashes

[Tor Bug Tracker & Wiki]

#25803: Infinite restart loop when daemon crashes
---+--
 Reporter:  tiejohg2sahth  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  systemd?   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by tiejohg2sahth):

 It appears that the file causing this behavior is
 ''/lib/systemd/system/tor[AT]default.service'' (replace [AT] by @, Trac
 thinks it's an email), because of the line:

 {{{
 Restart=on-failure
 }}}
 Possibles fix for this:

  * remove the Restart= line, the daemon won't restart if it crashed
  * add RestartSec=X to increase the time systemd waits before restarting
 the daemon, by default it is 100ms

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

Re: [tor-bugs] #25882 [Core Tor/Tor]: clients not detecting stale onion service introduction points

[Tor Bug Tracker & Wiki]

#25882: clients not detecting stale onion service introduction points
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:  #22455| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 Another interesting characteristic of this phenomenon is that there is a
 correlation between the incidence of the behaviour in which a Tor client
 will reach out to introduction points many times in futility to reach a
 particular service, even when the Tor clients in question reside on
 different machines living on different parts of the Internet.  Suggest
 that this means that there is something specific to the service that
 periodically breaks.  Since restarting Tor solves the problem almost
 always, we might surmise that something cached is going stale.

 This corroborates the inference that the introduction points are at fault.
 They are contained in the onion service descriptor, which is cached by the
 client.

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