Re: [tor-bugs] #24500 [Core Tor/Tor]: Confusing log message "Can't get entropy from getrandom()"

2017-12-02 Thread Tor Bug Tracker & Wiki
#24500: Confusing log message "Can't get entropy from getrandom()"
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 (For context, they say they are on Ubuntu Xenial.)

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

Re: [tor-bugs] #24164 [Core Tor/Tor]: errors I get after I installed 0.3.2.3 on my relay

2017-12-02 Thread Tor Bug Tracker & Wiki
#24164: errors I get after I installed 0.3.2.3 on my relay
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  not a bug
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by arma):

 Replying to [comment:8 dgoulet]:
 > You will _always_ see that warning with a kernel on 2.6.32, it doesn't
 have `get_random()` syscall but yet you are using a package or a tor
 compiled with its support.
 >
 > As long as you run tor not built for the system you are running it,
 you'll get these issues.

 I've opened #24500 for us to do something about the log 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

[tor-bugs] #24501 [Core Tor/Tor]: When we hit MaxMemInQueues, make the log message more quantitative

2017-12-02 Thread Tor Bug Tracker & Wiki
#24501: When we hit MaxMemInQueues, make the log message more quantitative
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 A relay operator on #tor shared these log lines, on a fast exit relay
 running with 1GByte of memory (so maxmeminqueues is 768MBytes):
 {{{
 Nov 30 03:13:52.000 [notice] We're low on memory.  Killing circuits with
 over-long queues. (This behavior is controlled by MaxMemInQueues.)
 Nov 30 03:13:52.000 [notice] Removed 118288 bytes by killing 124 circuits;
 0 circuits remain alive. Also killed 0 non-linked directory connections.
 Nov 30 03:13:52.000 [notice] We're low on memory.  Killing circuits with
 over-long queues. (This behavior is controlled by MaxMemInQueues.)
 Nov 30 03:13:52.000 [notice] Removed 25940496 bytes by killing 125
 circuits; 0 circuits remain alive. Also killed 0 non-linked directory
 connections.
 Nov 30 03:13:53.000 [notice] We're low on memory.  Killing circuits with
 over-long queues. (This behavior is controlled by MaxMemInQueues.)
 Nov 30 03:13:53.000 [notice] Removed 528 bytes by killing 1 circuits; 0
 circuits remain alive. Also killed 0 non-linked directory connections.
 Nov 30 03:13:53.000 [notice] We're low on memory.  Killing circuits with
 over-long queues. (This behavior is controlled by MaxMemInQueues.)
 Nov 30 03:13:53.000 [notice] Removed 528 bytes by killing 2 circuits; 0
 circuits remain alive. Also killed 0 non-linked directory connections.
 Nov 30 03:13:54.000 [notice] We're low on memory.  Killing circuits with
 over-long queues. (This behavior is controlled by MaxMemInQueues.)
 Nov 30 03:13:54.000 [notice] Removed 528 bytes by killing 1 circuits; 0
 circuits remain alive. Also killed 0 non-linked directory connections.
 Nov 30 03:13:54.000 [notice] We're low on memory.  Killing circuits with
 over-long queues. (This behavior is controlled by MaxMemInQueues.)
 Nov 30 03:13:54.000 [notice] Removed 528 bytes by killing 2 circuits; 0
 circuits remain alive. Also killed 0 non-linked directory connections.
 }}}

 I notice in cell_queues_check_size() that we sum up four things to compute
 alloc:
 {{{
   size_t alloc = cell_queues_get_total_allocation();
   alloc += buf_get_total_allocation();
   alloc += tor_compress_get_total_allocation();
   const size_t rend_cache_total = rend_cache_get_total_allocation();
   alloc += rend_cache_total;
 }}}
 For operators who are debugging their memory use, and for us poor people
 trying to help diagnose, it would seem smart for us to expose these four
 numbers when we say "We're low on memory".

 (I thought about this idea in particular because of the
 tor_compress_get_total_allocation() call and #24368.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24500 [Core Tor/Tor]: Confusing log message "Can't get entropy from getrandom()"

2017-12-02 Thread Tor Bug Tracker & Wiki
#24500: Confusing log message "Can't get entropy from getrandom()"
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 A relay operator on #tor shared these log lines:
 {{{
 Dec 01 16:33:00.000 [notice] Tor 0.3.1.8 (git-868c1b2b1eb7225a) opening
 log file.
 Dec 01 16:33:00.515 [warn] Can't get entropy from getrandom().
 Dec 01 16:33:00.534 [notice] Tor 0.3.1.8 (git-868c1b2b1eb7225a) running on
 Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g, Zlib 1.2.8, Liblzma
 5.1.0alpha[...]
 }}}

 The middle line is confusing -- why can't we get the entropy from it? Does
 that mean Tor has failed at something important? What should the relay
 operator do?

 If the relay operator shouldn't do anything, because it's fine, this
 should be a notice or less. If the relay operator ought to do something,
 because it's not fine, then we should suggest what to do and/or what the
 problem is with doing nothing.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24499 [Core Tor]: Bandwidth determination is flawed

2017-12-02 Thread Tor Bug Tracker & Wiki
#24499: Bandwidth determination is flawed
--+--
 Reporter:  Hassprediger  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor  |Version:  Tor: 0.3.1.8
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 I'm running a non-exit node in Australia. Please read "Australia" as a
 high latency area, that has not many other nodes around. I set
 RelayBandwidthRate to 1100, which is around 20% of my connection.

 Just like all people who start up a new node, I was wondering why the
 bandwidth was not used. Unfortunately most information, that can be found
 about the topic on the web is very outdated and does not apply to my
 situation.

 The measured bandwidth never exceeded 200 kb/s on atlas. So I decided to
 use my node as bridge and send junk traffic. Just downloading Ubnuntu and
 doing unnecessary uploades and running the CLI speedcheck script through
 the network. Now the nodes, that I am connected to, ackowledge, how much
 data can be send from/to my node and the bandwidth estimation on atlas
 suddenly goes up extremely. Beyond 500 (still not 1100 though).

 I thought I fixed it and turn my dummy-traffic-script off again. Now the
 estimation is down again, my node is mostly unused and I'll probably turn
 it off soon as it is just a waste of electricity.

 Apparently the bandwidth is measured in that useless 50-kilobytes-way,
 that the tor client does for the original setup. Well, sending 50
 kilobytes to a node and measuring the time is mostly a test of latency. So
 the test is currently faulty, it should actually send a few megabytes, or
 anything that results in a few seconds of measurement. Additionally it
 should also send 1 byte, to measure the latency and deduct it from the
 other measurement.

 Currently nodes in Australia, even if they have a high bandwidth fibre
 connection are largely disadvantaged. Only because the 'authorities' or
 the majority of the network is in Europe.

 Please don't get me wrong. I understand that a extremely high latency is
 also bad.  A 1 BGit/s connection is maybe not particularly useful if it
 has a latency of 30 seconds for each TCP packet. So latency should not go
 unnoticed. But you could at least be so kind and announce on your website,
 that nodes in Australia are not welcome and will be disadvantaged by the
 algorithm. Therefore people who live in areas like Australia (high
 bandwidth, high latency, high electricity costs) can at least be aware,
 that is is useless to run a node and they don't need to bother with it.

 Problems:
 1. The bandwidth estimation can be largely varied by sending unnecessary
 junk data over the tor network.
 2. The bandwidth estimation WILL be influenced, because the network uses
 it as a measure to determine if a node is "good" or should be used a lot.
 3. The bandwidth estimation measures latency and not bandwidth.
 4. Nodes that don't have many other nodes near, will be marked as useless,
 will go unused and therefore be turned off soon.
 5. The network will convert (or has already converted) to be concentrated
 in one location only, which is the highly connected areas in central
 Europe. The high speed nodes in North America are anyway on the ignore
 list of most people, 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

[tor-bugs] #24498 [Core Tor]: add configurables for eventdns settings

2017-12-02 Thread Tor Bug Tracker & Wiki
#24498: add configurables for eventdns settings
-+--
 Reporter:  Dhalgren |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor |Version:  Tor: unspecified
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 Scenarios exist where relay operators may wish to tune libevent evdns.c
 (eventdns) for specific exit relay requirements.  For example ideal values
 on a high-performance exit where a local instance of Unbound is utilized
 might be attempts=1 timeout=15, max-inflight=16384, but these settings are
 inappropriate when bind9/named or non-local Unbound are employed.

 Target settings:

 max-inflight
 max-timeouts
 timeout
 attempts

 Settings already configurable:

 randomize-case

 Other evdns.c settings exist that are not set in src/or/dns.c and it seems
 reasonable to omit them here as these can be adjusted via resolv.conf.
 The settings targeted here are under the control of the Tor daemon such
 that resolv.conf "options" have no effect.

 Predecessor tickets:  #18580 #21394

 I am willing to contribute a patch for this and unless I am advised
 otherwise will prepare and submit one in the next two or three weeks.

 A behavior I'm inclined to implement is to have the value -1 signify that
 dns.c should not touch the settings, permitting resolv.conf "options" to
 control.

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

Re: [tor-bugs] #21394 [Core Tor/Tor]: connection timeouts are affecting Tor Browser usability

2017-12-02 Thread Tor Bug Tracker & Wiki
#21394: connection timeouts are affecting Tor Browser usability
-+-
 Reporter:  arthuredelstein  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-backport 030-backport|  Actual Points:
  031-backport tbb-performance, tbb-usability,   |
  performance, tbb-needs |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by Dhalgren):

 Replying to [comment:81 Sebastian]:
 > I am not sure that retrying in the case of named is actually beneficial,
 which is why I didn't include it in the patch. Even if we succeed on the
 later retry it's unlikely that the client will actually benefit from that,
 because it will also give up on the request.

 I'm not following the the line of thought.  If evdns.c (in libevent) re-
 attempts the request at five seconds and succeeds, the client knows
 nothing about it.  All the client knows is that it required six-seven-
 whatever seconds for the circuit connection to complete.  In the retried-
 circuit scenario, it could take twelve, thirteen, on the outside fourteen
 seconds for success.

 Admittedly this will rarely matter (my Unbound histograms say about 0.5%
 of requests), but if attempts=1 timeout=5 is set, then the exit will
 literally throw away responses arriving after five seconds and the client
 will twiddle it's thumbs for the remaining five or ten seconds of its
 timeout interval with no chance of success.  My understanding is that
 evdns all-retries-exhausted events are _not_ relayed back to the client.

 > I had no intention to slight you in any way, I felt that I pushed very
 hard to actually get your work here recognized and a proper fix merged
 after your contributions had unfortunately been ignored for a very long
 time. I am just a volunteer myself and spending this time because I care
 about having a good outcome for the network.

 Very sorry for any misunderstanding!  I was not referring to you or anyone
 on this ticket above.  I was expressing my trepidation at spending time
 contributing in general because several times in the past I submitted
 carefully thought-out code changes (to Tor and other projects) that were
 summarily hacked on for no obvious reason, and without involving me.  Took
 much of the enjoyment out of it.

 In regard to this issue I am rather liking the experience.  I spent about
 six weeks understanding the problem, working on the fix, following up the
 results and documenting what I found on the wiki, and I it's a pleasure to
 have the work recognized and for it to effect a critical improvement to
 the network--though my original motive was simply to tame a single berserk
 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] #21394 [Core Tor/Tor]: connection timeouts are affecting Tor Browser usability

2017-12-02 Thread Tor Bug Tracker & Wiki
#21394: connection timeouts are affecting Tor Browser usability
-+-
 Reporter:  arthuredelstein  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-backport 030-backport|  Actual Points:
  031-backport tbb-performance, tbb-usability,   |
  performance, tbb-needs |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by Sebastian):

 I am not sure that retrying in the case of named is actually beneficial,
 which is why I didn't include it in the patch. Even if we succeed on the
 later retry it's unlikely that the client will actually benefit from that,
 because it will also give up on the request.

 I had no intention to slight you in any way, I felt that I pushed very
 hard to actually get your work here recognized and a proper fix merged
 after your contributions had unfortunately been ignored for a very long
 time. I am just a volunteer myself and spending this time because I care
 about having a good outcome for the network.

 I feel that it is unfair to suggest that anything I did on this bug I did
 to make this "mine" or to receive undue credit. I made sure the release
 notes mention your work and have tried to make everyone aware of who did
 the analysis. We happen to disagree on a technical point, but that should
 not be conflated with social 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] #21394 [Core Tor/Tor]: connection timeouts are affecting Tor Browser usability

2017-12-02 Thread Tor Bug Tracker & Wiki
#21394: connection timeouts are affecting Tor Browser usability
-+-
 Reporter:  arthuredelstein  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-backport 030-backport|  Actual Points:
  031-backport tbb-performance, tbb-usability,   |
  performance, tbb-needs |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * status:  reopened => needs_review


Comment:

 Setting to needs review for Dhalgren's touch-up patch in the previous
 comment.

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

Re: [tor-bugs] #21394 [Core Tor/Tor]: connection timeouts are affecting Tor Browser usability

2017-12-02 Thread Tor Bug Tracker & Wiki
#21394: connection timeouts are affecting Tor Browser usability
-+-
 Reporter:  arthuredelstein  |  Owner:  (none)
 Type:  defect   | Status:
 |  reopened
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-backport 030-backport|  Actual Points:
  031-backport tbb-performance, tbb-usability,   |
  performance, tbb-needs |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by Dhalgren):

 I uploaded my suggested revision.  Targets maint-0.2.9 as requested.

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

Re: [tor-bugs] #21394 [Core Tor/Tor]: connection timeouts are affecting Tor Browser usability

2017-12-02 Thread Tor Bug Tracker & Wiki
#21394: connection timeouts are affecting Tor Browser usability
-+-
 Reporter:  arthuredelstein  |  Owner:  (none)
 Type:  defect   | Status:
 |  reopened
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-backport 030-backport|  Actual Points:
  031-backport tbb-performance, tbb-usability,   |
  performance, tbb-needs |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by Dhalgren):

 * Attachment "bug21394_touch_up.patch" added.

 recommended touch-up patch

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

Re: [tor-bugs] #24497 [Webpages/Website]: Publish tor relay auto-update instructions

2017-12-02 Thread Tor Bug Tracker & Wiki
#24497: Publish tor relay auto-update instructions
--+
 Reporter:  arthuredelstein   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Description changed by arthuredelstein:

Old description:

> In our documentation pages that give instructions on how to set up a tor
> relay, we should explicitly show how to set up auto-update. Over time
> that will hopefully decrease the number of relays running out-of-date
> versions that are have security flaws or other bugs.
>
> We can patch the following pages:
> https://www.torproject.org/docs/tor-relay-debian.html.en
> https://www.torproject.org/docs/debian.html.en#ubuntu
> https://www.torproject.org/download/download-unix.html.en
>
> ahf has been collecting instructions here:
> https://trac.torproject.org/projects/tor/wiki/OperatorsTips

New description:

 In our documentation pages that give instructions on how to set up a tor
 relay, we should explicitly show how to set up auto-update. Over time that
 will hopefully decrease the number of relays running out-of-date versions
 that are have security flaws or other bugs.

 We can patch the following pages:
 https://www.torproject.org/docs/tor-relay-debian.html.en
 https://www.torproject.org/docs/debian.html.en#ubuntu
 https://www.torproject.org/download/download-unix.html.en

 irl has been collecting instructions here:
 https://trac.torproject.org/projects/tor/wiki/OperatorsTips

--

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

Re: [tor-bugs] #24497 [Webpages/Website]: Publish tor relay auto-update instructions

2017-12-02 Thread Tor Bug Tracker & Wiki
#24497: Publish tor relay auto-update instructions
--+
 Reporter:  arthuredelstein   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by arthuredelstein):

 * cc: irl (added)


Comment:

 Oops, sorry!

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

Re: [tor-bugs] #24497 [Webpages/Website]: Publish tor relay auto-update instructions

2017-12-02 Thread Tor Bug Tracker & Wiki
#24497: Publish tor relay auto-update instructions
--+
 Reporter:  arthuredelstein   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by ahf):

 It's irl who has been collecting instructions on the OperatorsTips wiki
 page - not 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] #24497 [Webpages/Website]: Publish tor relay auto-update instructions

2017-12-02 Thread Tor Bug Tracker & Wiki
#24497: Publish tor relay auto-update instructions
--+
 Reporter:  arthuredelstein   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 Related: #24442 (that script sets up auto updates 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] #24497 [Webpages/Website]: Publish tor relay auto-update instructions

2017-12-02 Thread Tor Bug Tracker & Wiki
#24497: Publish tor relay auto-update instructions
--+
 Reporter:  arthuredelstein   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by arthuredelstein):

 * cc: nusenu, ahf (added)


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

[tor-bugs] #24497 [Webpages/Website]: Publish tor relay auto-update instructions

2017-12-02 Thread Tor Bug Tracker & Wiki
#24497: Publish tor relay auto-update instructions
--+
 Reporter:  arthuredelstein   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 In our documentation pages that give instructions on how to set up a tor
 relay, we should explicitly show how to set up auto-update. Over time that
 will hopefully decrease the number of relays running out-of-date versions
 that are have security flaws or other bugs.

 We can patch the following pages:
 https://www.torproject.org/docs/tor-relay-debian.html.en
 https://www.torproject.org/docs/debian.html.en#ubuntu
 https://www.torproject.org/download/download-unix.html.en

 ahf has been collecting instructions here:
 https://trac.torproject.org/projects/tor/wiki/OperatorsTips

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

Re: [tor-bugs] #23742 [Obfuscation/Snowflake]: Make a snowflake package and distribute it

2017-12-02 Thread Tor Bug Tracker & Wiki
#23742: Make a snowflake package and distribute it
---+---
 Reporter:  cypherpunks|  Owner:  (none)
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:  duplicate
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by cypherpunks):

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


Comment:

 Duplicate of #19409

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

Re: [tor-bugs] #19409 [Obfuscation/Snowflake]: make a deb of snowflake and get into Debian

2017-12-02 Thread Tor Bug Tracker & Wiki
#19409: make a deb of snowflake and get into Debian
---+
 Reporter:  adrelanos  |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by cypherpunks):

 #23742 is a duplicate.

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

Re: [tor-bugs] #19409 [Obfuscation/Snowflake]: Make a deb of snowflake and get into Debian (was: make a deb of snowflake and get into Debian)

2017-12-02 Thread Tor Bug Tracker & Wiki
#19409: Make a deb of snowflake and get into Debian
---+
 Reporter:  adrelanos  |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by cypherpunks):

 * priority:  Medium => High
 * severity:  Normal => Major


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

Re: [tor-bugs] #10573 [Applications/Tor Browser]: `nsILocalFile` should be replaced with `nsIFile` in our extensions

2017-12-02 Thread Tor Bug Tracker & Wiki
#10573: `nsILocalFile` should be replaced with `nsIFile` in our extensions
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Minor | Resolution:
 Keywords:  tbb-easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * status:  new => needs_review


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

Re: [tor-bugs] #24496 [Core Tor/DirAuth]: Remove old Tor versions from recommended server versions

2017-12-02 Thread Tor Bug Tracker & Wiki
#24496: Remove old Tor versions from recommended server versions
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by cypherpunks):

 * component:  Core Tor/Tor => Core Tor/DirAuth


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

Re: [tor-bugs] #24227 [Core Tor/DirAuth]: remove v0.3.2.x before 0.3.2.4-alpha from recommended server versions

2017-12-02 Thread Tor Bug Tracker & Wiki
#24227: remove v0.3.2.x before 0.3.2.4-alpha from recommended server versions
--+---
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by cypherpunks):

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


Comment:

 superseded by #24496

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24496 [Core Tor/Tor]: Remove old Tor versions from recommended server versions

2017-12-02 Thread Tor Bug Tracker & Wiki
#24496: Remove old Tor versions from recommended server versions
--+
 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:
  Sponsor:|
--+
 Important updates got released lately, recommended versions should be
 updated accordingly.

 only the following tor versions should be recommended:
 0.2.5.16, 0.2.8.17, 0.2.9.14, 0.3.0.13, 0.3.1.9 and 0.3.2.6-alpha

 motivation:
 -  #21394 DNS issue for exits
 http://arthuredelstein.net/exits
 Arthur and I are trying to reach out to affected operators but some have
 no contactInfo, increasing the recommended versions would at least show
 them some information in their log entries.

 https://trac.torproject.org/projects/tor/wiki/TROVE
 - #24244
 - #24245
 - #24246
 - #24333
 - #24430

 debian packages via deb.tpo are available, lets make this change once
 0.3.1.9 is available on FreeBSD repos (I'll post to this ticket when that
 happens).

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

Re: [tor-bugs] #24482 [Core Tor/Tor]: Upload all stable binaries to torproject debian repository

2017-12-02 Thread Tor Bug Tracker & Wiki
#24482: Upload all stable binaries to torproject debian repository
---+---
 Reporter:  entr0py|  Owner:  (none)
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Tor   |Version:  Tor:
   |  unspecified
 Severity:  Normal | Resolution:  wontfix
 Keywords:  tor repository deb.torproject.org  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by irl):

 Right, but these don't appear on deb.torproject.org even though they've
 been built for Debian, which means waiting for clearing stable-proposed-
 updates or having the package migrate from unstable to testing and then
 backporting (not sure how that works when you have newer versions in
 unstable). Either way, the package exists but is not available to others
 to test in their derivatives.

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

Re: [tor-bugs] #24482 [Core Tor/Tor]: Upload all stable binaries to torproject debian repository

2017-12-02 Thread Tor Bug Tracker & Wiki
#24482: Upload all stable binaries to torproject debian repository
---+---
 Reporter:  entr0py|  Owner:  (none)
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Tor   |Version:  Tor:
   |  unspecified
 Severity:  Normal | Resolution:  wontfix
 Keywords:  tor repository deb.torproject.org  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by nickm):

 There are LTS releases of Tor -- they're the ones that go into Debian
 stable.

 We have a policy for how long we (the Tor team) support each release:
 
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases

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

Re: [tor-bugs] #24482 [Core Tor/Tor]: Upload all stable binaries to torproject debian repository

2017-12-02 Thread Tor Bug Tracker & Wiki
#24482: Upload all stable binaries to torproject debian repository
---+---
 Reporter:  entr0py|  Owner:  (none)
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Tor   |Version:  Tor:
   |  unspecified
 Severity:  Normal | Resolution:  wontfix
 Keywords:  tor repository deb.torproject.org  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by irl):

 I feel like we should have at least an LTS suite. The description of this
 ticket perhaps describes something that would be too much, but I'm not
 sure we can claim long-term support without also providing the releases in
 formats people use, especially if it's just a minor release and the
 packaging work is already done.

 Looking at it, it seems we already have nightly builds for these.

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

Re: [tor-bugs] #24482 [Core Tor/Tor]: Upload all stable binaries to torproject debian repository

2017-12-02 Thread Tor Bug Tracker & Wiki
#24482: Upload all stable binaries to torproject debian repository
---+---
 Reporter:  entr0py|  Owner:  (none)
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Tor   |Version:  Tor:
   |  unspecified
 Severity:  Normal | Resolution:  wontfix
 Keywords:  tor repository deb.torproject.org  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by Sebastian):

 what?

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

Re: [tor-bugs] #10573 [Applications/Tor Browser]: `nsILocalFile` should be replaced with `nsIFile` in our extensions

2017-12-02 Thread Tor Bug Tracker & Wiki
#10573: `nsILocalFile` should be replaced with `nsIFile` in our extensions
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Minor | Resolution:
 Keywords:  tbb-easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by aruna1234):

 * Attachment "tl-protocol.patch" added.

 Modified tl-protocol.js

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

Re: [tor-bugs] #24482 [Core Tor/Tor]: Upload all stable binaries to torproject debian repository

2017-12-02 Thread Tor Bug Tracker & Wiki
#24482: Upload all stable binaries to torproject debian repository
---+---
 Reporter:  entr0py|  Owner:  (none)
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Tor   |Version:  Tor:
   |  unspecified
 Severity:  Normal | Resolution:  wontfix
 Keywords:  tor repository deb.torproject.org  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by adrelanos):

 Replying to [comment:5 Sebastian]:
 > Our debian package maintainer has already indicated elsewhere that this
 is an unreasonable amount of work. You could build the packages yourself
 for your distribution if you need it, however.

 deb.torproject.org is dead?

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

Re: [tor-bugs] #24492 [Applications]: Set default /path/ to/ torrc

2017-12-02 Thread Tor Bug Tracker & Wiki
#24492: Set default  /path/ to/ torrc
--+
 Reporter:  0brand|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor defaults  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by adrelanos):

 Could you define a default path for {{{/etc/tor.d}}} please?

 I.e. could {{{/usr/share/tor/tor-service-defaults-torrc}}} reference
 {{{/etc/tor.d}}}? I guess that is...

 add torrc.d configuration directory
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866187

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

Re: [tor-bugs] #24277 [Metrics/Website]: Reduce vertical header size

2017-12-02 Thread Tor Bug Tracker & Wiki
#24277: Reduce vertical header size
-+--
 Reporter:  Hello71  |  Owner:  irl
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Minor| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by irl):

 * status:  accepted => needs_review


Comment:

 I've attached a solution that does not use the 8000px hack.

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

Re: [tor-bugs] #24277 [Metrics/Website]: Reduce vertical header size

2017-12-02 Thread Tor Bug Tracker & Wiki
#24277: Reduce vertical header size
-+--
 Reporter:  Hello71  |  Owner:  irl
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Minor| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by irl):

 * Attachment "0001-Reduces-default-vertical-header-size-Fixes-24277.patch"
 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] #24482 [Core Tor/Tor]: Upload all stable binaries to torproject debian repository

2017-12-02 Thread Tor Bug Tracker & Wiki
#24482: Upload all stable binaries to torproject debian repository
---+---
 Reporter:  entr0py|  Owner:  (none)
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Tor   |Version:  Tor:
   |  unspecified
 Severity:  Normal | Resolution:  wontfix
 Keywords:  tor repository deb.torproject.org  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by entr0py):

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


Comment:

 Understood. Thanks for considering!

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

Re: [tor-bugs] #24461 [Metrics/Atlas]: Require less scrolling on advanced search page

2017-12-02 Thread Tor Bug Tracker & Wiki
#24461: Require less scrolling on advanced search page
---+
 Reporter:  cypherpunks|  Owner:  irl
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by irl):

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


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

Re: [tor-bugs] #24461 [Metrics/Atlas]: Require less scrolling on advanced search page

2017-12-02 Thread Tor Bug Tracker & Wiki
#24461: Require less scrolling on advanced search page
---+--
 Reporter:  cypherpunks|  Owner:  irl
 Type:  enhancement| Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by irl):

 Fixed in a0beabb.

 #24277 will further improve this once 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] #23782 [Metrics/Atlas]: Expose all possible query features in an "Advanced Search" HTML form

2017-12-02 Thread Tor Bug Tracker & Wiki
#23782: Expose all possible query features in an "Advanced Search" HTML form
---+
 Reporter:  cypherpunks|  Owner:  irl
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by irl):

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


Comment:

 Fixed in a0beabb.

 Once #21366 is done we can revisit this to take advantage of 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] #24463 [Metrics/Atlas]: Advanced search: Add a client auto-completion filter to AS field

2017-12-02 Thread Tor Bug Tracker & Wiki
#24463: Advanced search: Add a client auto-completion filter to AS field
---+--
 Reporter:  cypherpunks|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Very Low   |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by irl):

 Blocked by #24495.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24495 [Metrics/Onionoo]: Add aggregated summary documents

2017-12-02 Thread Tor Bug Tracker & Wiki
#24495: Add aggregated summary documents
-+--
 Reporter:  irl  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 This would be incredibly useful for #23782. These could also be a form of
 summary document to give basic stats about the number of relays/bridges
 having a particular value for a property. An example would be:

 https://onionoo.torproject.org/aggregated_summary?group=version

 ```
 {"version":"4.4",
 "next_major_version_scheduled":"2017-12-17",
 "build_revision":"25021a8",
 "relays_published":"2017-12-02 14:00:00",
 "aggregated_relays":{
 "0.3.1.8": 30,
 "0.3.1.9": 34,
 "0.4.5.8": 2
 },
 "bridges_published":"2017-12-02 13:05:07",
 "aggregated_bridges":{
 "0.3.1.8": 31,
 "0.3.1.9": 24,
 "0.4.5.8": 2
 }
 }
 ```

 (not real data)

 You could use this to produce autocompletion lists for the advanced search
 form, but it would also have a secondary use for generating bar charts.

 It should be easy enough to have the group argument be for any Onionoo
 details field.

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

Re: [tor-bugs] #24495 [Metrics/Onionoo]: Add aggregated summary documents

2017-12-02 Thread Tor Bug Tracker & Wiki
#24495: Add aggregated summary documents
-+--
 Reporter:  irl  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Old description:

> This would be incredibly useful for #23782. These could also be a form of
> summary document to give basic stats about the number of relays/bridges
> having a particular value for a property. An example would be:
>
> https://onionoo.torproject.org/aggregated_summary?group=version
>
> ```
> {"version":"4.4",
> "next_major_version_scheduled":"2017-12-17",
> "build_revision":"25021a8",
> "relays_published":"2017-12-02 14:00:00",
> "aggregated_relays":{
> "0.3.1.8": 30,
> "0.3.1.9": 34,
> "0.4.5.8": 2
> },
> "bridges_published":"2017-12-02 13:05:07",
> "aggregated_bridges":{
> "0.3.1.8": 31,
> "0.3.1.9": 24,
> "0.4.5.8": 2
> }
> }
> ```
>
> (not real data)
>
> You could use this to produce autocompletion lists for the advanced
> search form, but it would also have a secondary use for generating bar
> charts.
>
> It should be easy enough to have the group argument be for any Onionoo
> details field.

New description:

 This would be incredibly useful for #23782. These could also be a form of
 summary document to give basic stats about the number of relays/bridges
 having a particular value for a property. An example would be:

 https://onionoo.torproject.org/aggregated_summary?group=version

 {{{
 {"version":"4.4",
 "next_major_version_scheduled":"2017-12-17",
 "build_revision":"25021a8",
 "relays_published":"2017-12-02 14:00:00",
 "aggregated_relays":{
 "0.3.1.8": 30,
 "0.3.1.9": 34,
 "0.4.5.8": 2
 },
 "bridges_published":"2017-12-02 13:05:07",
 "aggregated_bridges":{
 "0.3.1.8": 31,
 "0.3.1.9": 24,
 "0.4.5.8": 2
 }
 }
 }}}

 (not real data)

 You could use this to produce autocompletion lists for the advanced search
 form, but it would also have a secondary use for generating bar charts.

 It should be easy enough to have the group argument be for any Onionoo
 details field.

--

Comment (by irl):

 Fixed description formatting.

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

Re: [tor-bugs] #19610 [Core Tor/Tor]: IPv6-only clients fetch microdescriptors from a small number of IPv6 fallbacks

2017-12-02 Thread Tor Bug Tracker & Wiki
#19610: IPv6-only clients fetch microdescriptors from a small number of IPv6
fallbacks
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.4-rc
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, microdesc, fallbacks, tor- |  Actual Points:
  client network-health user-enumeration |
Parent ID:  #23827   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  new => needs_review
 * parent:  #20916 => #23827


Comment:

 #23827 has a branch which fixes 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] #19990 [Core Tor/Tor]: EntryNodes is incompatible with IPv6-only bootstrap

2017-12-02 Thread Tor Bug Tracker & Wiki
#19990: EntryNodes is incompatible with IPv6-only bootstrap
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  ipv6 tor-client robustness   |  Actual Points:
  bootstrap sponsor8-maybe   |
Parent ID:  #20916   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  assigned => needs_information


Comment:

 We need to test this once we've merged the rest of #20916.

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

Re: [tor-bugs] #23975 [Core Tor/Tor]: Make node_get_*_orport() check addresses in the right order

2017-12-02 Thread Tor Bug Tracker & Wiki
#23975: Make node_get_*_orport() check addresses in the right order
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  ipv6  |  Actual Points:  1
Parent ID:  #20916| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * keywords:  ipv6, regression => ipv6
 * actualpoints:   => 1


Comment:

 This branch also obsoletes ReachableDirAddresses and removes all IPv6
 DirPort code.
 Removing it was easier than trying to fix 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] #23975 [Core Tor/Tor]: Make node_get_*_orport() check addresses in the right order

2017-12-02 Thread Tor Bug Tracker & Wiki
#23975: Make node_get_*_orport() check addresses in the right order
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  ipv6, regression  |  Actual Points:
Parent ID:  #20916| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by teor):

 I wrote a draft branch bug23975_tree, which uses the new consensus methods
 from bug23826-23828.

 It still needs revision to fix some unit test failures.

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

Re: [tor-bugs] #24494 [Metrics/Onionoo]: Specification says nickname is optional in documents but it's always there

2017-12-02 Thread Tor Bug Tracker & Wiki
#24494: Specification says nickname is optional in documents but it's always 
there
-+--
 Reporter:  irl  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Agreed, we should take out that optimization. It seemed like a good idea
 to save some bandwidth at the beginning, but we added so many more fields
 that this one doesn't really matter anymore. Reducing complexity seems
 more important. Let's do 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] #24414 [Metrics/Website]: Update list of services in services.html

2017-12-02 Thread Tor Bug Tracker & Wiki
#24414: Update list of services in services.html
-+--
 Reporter:  cypherpunks  |  Owner:  irl
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by irl):

 * status:  accepted => needs_review


Comment:

 I've updated the services page as in the description, and attached a
 patch. This is ready to be reviewed.

 If we think we might want to keep the OnionView thing around, we should
 clone the repo somewhere else as I think CodePlex is going away, and we
 could move the link to the development or maybe an ideas page for someone
 else to pick up.

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

Re: [tor-bugs] #24414 [Metrics/Website]: Update list of services in services.html

2017-12-02 Thread Tor Bug Tracker & Wiki
#24414: Update list of services in services.html
-+--
 Reporter:  cypherpunks  |  Owner:  irl
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by irl):

 * Attachment "0001-Updates-list-of-services-Fixes-24414.patch" 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] #24414 [Metrics/Website]: Update list of services in services.html (was: Add Tor relay map and OrNetStats to services.html)

2017-12-02 Thread Tor Bug Tracker & Wiki
#24414: Update list of services in services.html
-+--
 Reporter:  cypherpunks  |  Owner:  irl
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Old description:

> https://tormap.void.gr/  (code: https://github.com/kargig/tormap )
> originally written by Moritz, maintained by
> https://twitter.com/kargig
>
> (unfortunately it does not work reliably for TorBrowser users, probably
> due to Google blocking access to map data via certain exit relays)
>
> this uses also onionoo:
> https://nusenu.github.io/OrNetStats/

New description:

 Add the following services:
 * https://tormap.void.gr/ (code: https://github.com/kargig/tormap )
 * https://nusenu.github.io/OrNetStats/

 Remove:
 * Compass (being retired)
 * OnionView (this link is not really useful anymore)

--

Comment (by irl):

 Updated the description.

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #13350

2017-12-02 Thread Tor Bug Tracker & Wiki
Batch modification to #13350 by irl:


Action: resolve

Comment:
This ticket has been archived, but there is still a bug open at 
https://bugs.debian.org/826467 which is the best place to have it.

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

[tor-bugs] #24494 [Metrics/Onionoo]: Specification says nickname is optional in documents but it's always there

2017-12-02 Thread Tor Bug Tracker & Wiki
#24494: Specification says nickname is optional in documents but it's always 
there
-+--
 Reporter:  irl  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 Example:

 https://onionoo.torproject.org/details?search=Unnamed&limit=4&fields=nickname

 Specification says:

 > Relay nickname consisting of 1–19 alphanumerical characters. Omitted if
 the relay nickname is "Unnamed".

 I think I would prefer to fix the specification than to fix the Onionoo
 behaviour, as it's useful to have only one code path in Relay Search
 instead of more code paths depending on whether or not the field is
 present.

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

Re: [tor-bugs] #23827 [Core Tor/Tor]: Clients/Relays: Use IPv6 Addresses from microdesc consensus

2017-12-02 Thread Tor Bug Tracker & Wiki
#23827: Clients/Relays: Use IPv6 Addresses from microdesc consensus
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6  |  Actual Points:  1
Parent ID:  #20916| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * keywords:  ipv6, regression => ipv6
 * status:  needs_revision => needs_review
 * actualpoints:   => 1


Comment:

 Please see my branch bug23827_tree, which uses the new consensus methods
 from bug23826-23828.

 We will probably need to do some squashing and rebasing before 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] #24399 [Webpages/Website]: Consistent set of icons for relay flags

2017-12-02 Thread Tor Bug Tracker & Wiki
#24399: Consistent set of icons for relay flags
--+
 Reporter:  irl   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Old description:

> Relay Search currently uses a set of icons for relay flags that exist as
> 16x16 PNGs. Over time we have added new icons but we've never considered
> consistency across projects or reusability of these icons.
>
> Ideally, we could have icons for the following flags that are reusable
> across projects (meanings are in dir-spec):
>
> * Authority
> * BadExit
> * Fast
> * Guard
> * HSDir
> * NoEdConsensus
> * Running
> * Stable
> * V2Dir
> * Valid
> * Exit
>
> Atlas also synthesises additional flags, as does consensus-health:
>
> * Not Recommended - This relay is running a Tor version that is not
> recommended by the directory authorities and may contain known issues.
> * Unmeasured - This relay has not been measured by at least 3 bandwidth
> authorities and so its consensus weight is currently capped.
> * FallbackDir - This relay is hardcoded into the tor source code as a
> fallback directory.
> * IPv6 ORPort - This relay listens for OR connections using IPv6.
> (consensus-health calls this "ReachableIPv6", because it looks at votes.)
> * IPv6 Exit - This relay allows exit connections using IPv6.
> * Unreachable ORPort - This relay has an unreachable OR address according
> to at least one directory authority.
> * T-Shirt - This relay has met the t-shirt team criteria for a t-shirt
> (in theory).
>
> Ideally these icons would be available for use in projects in the
> following formats:
>
> * Web Icon Font
> * SVG
> * 16x16, 32x32 and 64x64 PNGs
>
> If we could also throw in an onion, and relay and bridge icons, a
> fingerprint icon, AS icon, country icon (maybe a globe), this could be a
> really useful tool for user facing projects that has consistent UX across
> those projects.

New description:

 Relay Search currently uses a set of icons for relay flags that exist as
 16x16 PNGs. Over time we have added new icons but we've never considered
 consistency across projects or reusability of these icons.

 Ideally, we could have icons for the following flags that are reusable
 across projects (meanings are in dir-spec):

 * Authority
 * BadExit
 * Fast
 * Guard
 * HSDir
 * NoEdConsensus
 * Running
 * Stable
 * V2Dir
 * Valid
 * Exit

 Atlas also synthesises additional flags, as does consensus-health:

 * Not Recommended - This relay is running a Tor version that is not
 recommended by the directory authorities and may contain known issues.
 * Unmeasured - This relay has not been measured by at least 3 bandwidth
 authorities and so its consensus weight is currently capped.
 * FallbackDir - This relay is hardcoded into the tor source code as a
 fallback directory.
 * IPv6 ORPort - This relay listens for OR connections using IPv6.
 * Unreachable IPv6 ORPort - This relay listens for OR connections using
 IPv6 but the directory authorities failed to confirm it was reachable.
 * ReachableIPv6 - This relay has at least one reachable OR port using
 IPv6. (in votes)
 * UnreachableIPv6 - This relay has at least one unreachable OR port using
 IPv6. (in votes)
 * IPv6 Exit - This relay allows exit connections using IPv6.
 * Unreachable ORPort - This relay has an unreachable OR address according
 to at least one directory authority.
 * T-Shirt - This relay has met the t-shirt team criteria for a t-shirt (in
 theory).
 * Hibernating - This relay is not currently running, and indicated that it
 was hibernating in its last known server descriptor.

 Ideally these icons would be available for use in projects in the
 following formats:

 * Web Icon Font
 * SVG
 * 16x16, 32x32 and 64x64 PNGs

 If we could also throw in an onion, and relay and bridge icons, a
 fingerprint icon, AS icon, country icon (maybe a globe), this could be a
 really useful tool for user facing projects that has consistent UX across
 those projects.

--

Comment (by irl):

 Ok, I see. There is some plan to add votes to Onionoo so that this
 information may one day be available in Relay Search so we should keep
 this distinction. I've updated the description, and also added
 "Hibernating" which I should really add to Relay Search.

 I think I'll do the code to have it available in the model on Relay Search
 but wait for the new icons before actually deploying it.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing 

[tor-bugs] #24493 [Applications/Tor Browser]: Circuit refuses to change when clicking on "New Circuit for this site" when I hit a "Secure Connection Failed" error

2017-12-02 Thread Tor Bug Tracker & Wiki
#24493: Circuit refuses to change when clicking on "New Circuit for this site" 
when
I hit a "Secure Connection Failed" error
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Steps to reproduce:

 1. Open Tor Browser.
 2. Visit https://documents.tips/
 3. You'll be hit with a "Secure Connection Failed" error page.
 4. Click on Torbutton > "New Tor circuit for this site".
 5. Circuit stays the same.

 Not sure if this is intentional behavior (In this example it's because the
 certificate has been revoked, but in other cases changing the exit may
 solve the problem with some other errors - I can give an example if that's
 necessary).

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

Re: [tor-bugs] #10573 [Applications/Tor Browser]: `nsILocalFile` should be replaced with `nsIFile` in our extensions

2017-12-02 Thread Tor Bug Tracker & Wiki
#10573: `nsILocalFile` should be replaced with `nsIFile` in our extensions
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Minor | Resolution:
 Keywords:  tbb-easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:6 aruna1234]:
 > Actually, I am not able to find the block of code that needs editing.
 Could you help me through?
 https://gitweb.torproject.org/tor-launcher.git/tree/src/components/tl-
 protocol.js#n1354

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

Re: [tor-bugs] #24414 [Metrics/Website]: Add Tor relay map and OrNetStats to services.html

2017-12-02 Thread Tor Bug Tracker & Wiki
#24414: Add Tor relay map and OrNetStats to services.html
-+--
 Reporter:  cypherpunks  |  Owner:  irl
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by irl):

 * status:  new => accepted
 * owner:  metrics-team => irl


Comment:

 Moving this into my queue.

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

Re: [tor-bugs] #24492 [Applications]: Set default /path/ to/ torrc

2017-12-02 Thread Tor Bug Tracker & Wiki
#24492: Set default  /path/ to/ torrc
--+
 Reporter:  0brand|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor defaults  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by Sebastian):

 There already is a default path, it is $sysconfdir/tor/torrc. $sysconfdir
 is set during configure and defaults to /etc

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

[tor-bugs] #24492 [Applications]: Set default /path/ to/ torrc

2017-12-02 Thread Tor Bug Tracker & Wiki
#24492: Set default  /path/ to/ torrc
--+--
 Reporter:  0brand|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications  |Version:
 Severity:  Normal|   Keywords:  tor defaults
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Would there be any interest in setting a default path to torrc ( i.e.
 /usr/share/tor/tor-service-defaults-torrc, /etc/tor/torrc, /etc/tor.d ) I
 think this would cause less confusion ( simplicity ). Also other
 projects/devs try to mirror Tor defaults, and for good reason ( obvious
 why ). This would lead to better continuity.

 I understand its not as simple as "This /path/to/torrc is now the default"
 but I think its something that should be on the road map for the future.

 Thanks for your time!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24491 [- Select a component]: Orbot/orfox IP location advice required

2017-12-02 Thread Tor Bug Tracker & Wiki
#24491: Orbot/orfox IP location advice required
--+
 Reporter:  BulsaraBiggs  |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Major |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Help.

 Im running orbot+ orfox on an android cell.
 I am outside the destination country in which i am required to be located
 for a url to work in orfox.

 Pls advise on what steps are needed and that i must follow
 to enable access to the blocked site.

 Blocked detination url location:  UK

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

Re: [tor-bugs] #24489 [Core Tor/Tor]: Add some consts to networkstatus_getinfo_by_purpose()

2017-12-02 Thread Tor Bug Tracker & Wiki
#24489: Add some consts to networkstatus_getinfo_by_purpose()
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  code-correctness  |  Actual Points:  0.1
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  new => needs_review


Comment:

 Please see my branch bug24489 on github, which adds some consts and a note
 for future refactoring.

 I opened a follow-up ticket to avoid the bridge authority changing the
 running flag in networkstatus_getinfo_by_purpose(). See #24490.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24490 [Core Tor/Tor]: Stop setting bridges running in networkstatus_getinfo_by_purpose()

2017-12-02 Thread Tor Bug Tracker & Wiki
#24490: Stop setting bridges running in networkstatus_getinfo_by_purpose()
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core |Version:
  Tor/Tor|   Keywords:  easy, intro, refactor, code-
 Severity:  Normal   |  correctness
Actual Points:   |  Parent ID:
   Points:  1|   Reviewer:
  Sponsor:   |
-+-
 A GETINFO controller function shouldn't modify vital data structures.

 Instead, we should make sure the list is up to date regularly, or that it
 is updated before we call this function.

 This bug was introduced in commit 74d05f4 in tor-0.2.0.13-alpha.

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

[tor-bugs] #24489 [Core Tor/Tor]: Add some consts to networkstatus_getinfo_by_purpose()

2017-12-02 Thread Tor Bug Tracker & Wiki
#24489: Add some consts to networkstatus_getinfo_by_purpose()
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  code-correctness
Actual Points:  0.1   |  Parent ID:
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+
 We shouldn't modify any of the data structures passed to
 networkstatus_getinfo_by_purpose(). But the current design modifies the
 running flag in the GETINFO.

 The patch I'm about to post makes sure we don't accidentally modify any
 more of the data structures.



 Thanks to komlo - the patch was her idea, and she helped create 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] #24488 [Core Tor/Tor]: Make set_routerstatus_from_routerinfo() set IPv6 unspecified addresses

2017-12-02 Thread Tor Bug Tracker & Wiki
#24488: Make set_routerstatus_from_routerinfo() set IPv6 unspecified addresses
+
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.2.4.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  ipv6, code-correctness  |  Actual Points:  0.1
Parent ID:  | Points:  0.1
 Reviewer:  |Sponsor:  SponsorV-can
+
Changes (by teor):

 * status:  new => needs_review
 * parent:  #20916 =>


Comment:

 (Un-parenting, because this doesn't depend on any of the rest of #20916.)

 Replying to [comment:1 Sebastian]:
 > isn't the unspecified address ::/0 (or all bits equal to zero)?

 Yes, the unspecified IPv6 address has all bits equal to zero.

 But struct tor_addr_t also has a `sa_family_t family;` member. In this
 case, it's more correct to have it set to AF_INET6 rather than AF_UNSPEC:
 * it makes for better formatting when we print out the address, and
 * if ipv6_addr is always AF_INET6, it makes it less likely we will
 introduce bugs.

 The initialisation of ipv6_orport is completely redundant, but it's nice
 to do it explicitly so it's consistent with the `if` case.

 Please see my branch bug24488 on github.

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

Re: [tor-bugs] #24488 [Core Tor/Tor]: Make set_routerstatus_from_routerinfo() set IPv6 unspecified addresses

2017-12-02 Thread Tor Bug Tracker & Wiki
#24488: Make set_routerstatus_from_routerinfo() set IPv6 unspecified addresses
+
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.2.4.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  ipv6, code-correctness  |  Actual Points:  0.1
Parent ID:  #20916  | Points:  0.1
 Reviewer:  |Sponsor:  SponsorV-can
+

Comment (by Sebastian):

 isn't the unspecified address ::/0 (or all bits equal to zero)?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24488 [Core Tor/Tor]: Make set_routerstatus_from_routerinfo() set IPv6 unspecified addresses

2017-12-02 Thread Tor Bug Tracker & Wiki
#24488: Make set_routerstatus_from_routerinfo() set IPv6 unspecified addresses
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.4.1-alpha
 Severity:  Normal|   Keywords:  ipv6, code-correctness
Actual Points:  0.1   |  Parent ID:  #20916
   Points:  0.1   |   Reviewer:
  Sponsor:  SponsorV-can  |
--+
 set_routerstatus_from_routerinfo() currently sets ipv6_orport to all
 zeroes. But it should be set to the unspecified IPv6 address.

 This is unlikely to cause any bugs in previous Tor versions, but we should
 fix this for correctness.

 This is a bug on commit 6d99c51 in 0.2.4.1-alpha.

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

Re: [tor-bugs] #22431 [Applications/Tor Browser]: Firefox bug - Browser Console stops auto-scrolling sometimes

2017-12-02 Thread Tor Bug Tracker & Wiki
#22431: Firefox bug - Browser Console stops auto-scrolling sometimes
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Minor| Resolution:
 Keywords:  ff52-esr, tbb-usability, |  Actual Points:
  tbb-7.0-issues, tbb-regression |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:4 gk]:
 > Replying to [comment:3 cypherpunks]:
 > > Not fixed with new Browser Console in Firefox 57.
 >
 > I think step 1 would be to file a bug at https://bugzilla.mozilla.org as
 I suspect there are some devs at Mozilla who could help with that?
 Really? Have you found a way to submit tickets anonymously and without
 JavaScript?
 > Has that been done (ideally with some steps to reproduce the problem or
 to narrow it down) already? If so, what's the bug number?
 https://bugzilla.mozilla.org/show_bug.cgi?id=1412294

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

Re: [tor-bugs] #24482 [Core Tor/Tor]: Upload all stable binaries to torproject debian repository

2017-12-02 Thread Tor Bug Tracker & Wiki
#24482: Upload all stable binaries to torproject debian repository
---+---
 Reporter:  entr0py|  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Tor   |Version:  Tor:
   |  unspecified
 Severity:  Normal | Resolution:
 Keywords:  tor repository deb.torproject.org  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by Sebastian):

 Our debian package maintainer has already indicated elsewhere that this is
 an unreasonable amount of work. You could build the packages yourself for
 your distribution if you need it, however.

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