Re: [tor-bugs] #25967 [Core Tor/Tor]: v3 onion keep working without the HiddenServiceVersion 3 line

[Tor Bug Tracker & Wiki]

#25967: v3 onion keep working without the HiddenServiceVersion 3 line
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, 033-must-maybe, |  Actual Points:
  032-backport, 033-backport |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Hi again, I did some further testing and found out that you can enable
 BOTH v2 and v3 onions by starting with v3, then comment out the version
 line and SIGHUP, then reinstate the version line and SIGHUP.

 Final hostname is the v3 onion, but both v2 and v3 will work.

 I ran these tests using 2 tor instances on different socksport, one to
 create the hidden service, and the other as a client to access the hidden
 service. I stopped and started the second tor to make sure that there was
 no dns caching or stale circuits lying around.

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

Re: [tor-bugs] #25970 [Core Tor/Nyx]: Can not start nyx in a Raspberry pi 3

[Tor Bug Tracker & Wiki]

#25970: Can not start nyx in a Raspberry pi 3
--+
 Reporter:  cypherpunks   |  Owner:  atagar
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:  nyx,  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * version:  Tor: 0.2.9.14 =>
 * milestone:  Tor: 0.2.9.x-final =>


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

Re: [tor-bugs] #25970 [Core Tor/Nyx]: Can not start nyx in a Raspberry pi 3

[Tor Bug Tracker & Wiki]

#25970: Can not start nyx in a Raspberry pi 3
--+
 Reporter:  cypherpunks   |  Owner:  atagar
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Nyx  |Version:  Tor: 0.2.9.14
 Severity:  Normal| Resolution:
 Keywords:  nyx,  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by atagar):

 Hi cypherpunks, thanks for reporting this! New one to me. Quick search
 seems to indicate that this is sqlite corruption. Fortunately we just use
 it for caching. If you delete '~/.nyx/cache.sqlite' does nyx work?

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

Re: [tor-bugs] #25968 [Applications/Tor Browser]: No audio during video playback

[Tor Bug Tracker & Wiki]

#25968: No audio during video playback
--+--
 Reporter:  heyjoe|  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:
--+--

Comment (by Dbryrtfbcbhgf):

 I tested the video using TorBrowser 7.5.3 with the safest security setting
 and the audio works fine.
 1. Close TorBrowser and delete the {{{TorBrowser-Data}}} folder.
 2. Open TorBrowser and visit the link again and click on the video space
 and click Temporarily allow.
 3. refresh the page if the video is not visible.

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

Re: [tor-bugs] #25970 [Core Tor/Nyx]: Can not start nyx in a Raspberry pi 3

[Tor Bug Tracker & Wiki]

#25970: Can not start nyx in a Raspberry pi 3
--+
 Reporter:  cypherpunks   |  Owner:  atagar
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Nyx  |Version:  Tor: 0.2.9.14
 Severity:  Normal| Resolution:
 Keywords:  nyx,  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 Sorry I did not I could put the photos here.

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

Re: [tor-bugs] #25970 [Core Tor/Nyx]: Can not start nyx in a Raspberry pi 3

[Tor Bug Tracker & Wiki]

#25970: Can not start nyx in a Raspberry pi 3
--+
 Reporter:  cypherpunks   |  Owner:  atagar
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Nyx  |Version:  Tor: 0.2.9.14
 Severity:  Normal| Resolution:
 Keywords:  nyx,  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by cypherpunks):

 * Attachment "Captura de tela_2018-04-29_23-56-29-nyx-erro-02.png" 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] #25970 [Core Tor/Nyx]: Can not start nyx in a Raspberry pi 3

[Tor Bug Tracker & Wiki]

#25970: Can not start nyx in a Raspberry pi 3
--+
 Reporter:  cypherpunks   |  Owner:  atagar
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Nyx  |Version:  Tor: 0.2.9.14
 Severity:  Normal| Resolution:
 Keywords:  nyx,  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by cypherpunks):

 * Attachment "Captura de tela_2018-04-29_23-56-29-nyx-erro-03.png" 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] #25970 [Core Tor/Nyx]: Can not start nyx in a Raspberry pi 3

[Tor Bug Tracker & Wiki]

#25970: Can not start nyx in a Raspberry pi 3
--+
 Reporter:  cypherpunks   |  Owner:  atagar
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Nyx  |Version:  Tor: 0.2.9.14
 Severity:  Normal| Resolution:
 Keywords:  nyx,  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by cypherpunks):

 * Attachment "Captura de tela_2018-04-29_23-56-29-nyx-erro-01.png" 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] #25970 [Core Tor/Nyx]: Can not start nyx in a Raspberry pi 3

[Tor Bug Tracker & Wiki]

#25970: Can not start nyx in a Raspberry pi 3
--+
 Reporter:  cypherpunks   |  Owner:  atagar
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Nyx  |Version:  Tor: 0.2.9.14
 Severity:  Normal|   Keywords:  nyx,
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Dear friend I am a newbie and sorry to disturb you, but I really do not
 know why this is happening?

 When I try to start nyx I receive an error about sqlite3 database.

 Enclosed some pictures.

 https://ibb.co/fjgOBx;>https://preview.ibb.co/hYRZJc/Captura_de_tela_2018_04_29_23_56_29_nyx_erro_01.png;
 alt="Captura_de_tela_2018_04_29_23_56_29_nyx_erro_01" border="0">
 https://ibb.co/iKtQPH;>https://preview.ibb.co/m1wejH/Captura_de_tela_2018_04_29_23_56_29_nyx_erro_02.png;
 alt="Captura_de_tela_2018_04_29_23_56_29_nyx_erro_02" border="0">
 https://ibb.co/mwNVrx;>https://preview.ibb.co/buWOBx/Captura_de_tela_2018_04_29_23_56_29_nyx_erro_03.png;
 alt="Captura_de_tela_2018_04_29_23_56_29_nyx_erro_03" border="0">delete your
 account

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

Re: [tor-bugs] #25969 [Applications/Tor Browser]: SOCKS5 proxy hostname parsing problem

[Tor Bug Tracker & Wiki]

#25969: SOCKS5 proxy hostname parsing problem
--+--
 Reporter:  Elfeater  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  broken, proxy, parser |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * owner:  brade => tbb-team
 * component:  Applications/Tor Launcher => Applications/Tor 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] #25969 [Applications/Tor Launcher]: SOCKS5 proxy hostname parsing problem

[Tor Bug Tracker & Wiki]

#25969: SOCKS5 proxy hostname parsing problem
---+---
 Reporter:  Elfeater   |  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Major  |   Keywords:  broken, proxy,
   |  parser
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+---
 Hello, after updating to 7.5.3 from the previous version (which I believe
 was 7.5.2, I don't remember for sure but I update every time there is the
 option to do so) tor initially seemed to be working fine. However today I
 updated my Windows 8.1 install and after the update for whatever reason
 tor would not load. It kept giving me an error saying

 "Tor exited unexpectedly. You must restart tor to fix this problem etc"

 but no matter how many times I restarted tor this did not fix the problem.
 I then reinstalled tor to a different directory and then tried to start it
 up and surprisingly it worked just fine, but after setting up the bridge
 and the socks5 proxy I use again it told me that the settings could not be
 saved because it either could not connect to the host provided or could
 not parse the host name provided. I used the same proxy for firefox
 outside of tor and it was working fine with foxyproxy so it has to be with
 your parsing method.

 I don't know if something changed in the windows update to affect how
 proxy host names are parsed or if there was a change in 7.5.3 but if I
 type in the IP address instead of the domain name it works fine. I would
 rather not do this though because the host name automatically switches
 between about 200 different IPs for the fastest connection on the network
 so this way I am stuck to using 1 IP address.

 I also read online when looking for help initially that someone else had
 run into this problem and was able to fix it by running tor.exe separately
 and specific from the firefox.exe executable in the tor browser folder.
 His issue must have been do to something else because I tried this and it
 did not fix anything.

 Can you please look into this for me? Or at least tell me how I might fix
 it so that I can provide a host name instead of IP address for my SOCKS5
 proxy? the current host name looks like:

 thisis.howit.currentlylooks.com

 and before i just typed it in just like that, no protocol description or
 anything at the beginning and it worked just fine up till now.

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

Re: [tor-bugs] #25549 [Core Tor/Tor]: Add tor CI config for AppVeyor

[Tor Bug Tracker & Wiki]

#25549: Add tor CI config for AppVeyor
-+-
 Reporter:  isis |  Owner:  saper
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, tor-testing, 034-roadmap-|  Actual Points:
  subtask, 034-triage-20180328,  |
  034-included-20180328  |
Parent ID:  #25550   | Points:  2
 Reviewer:  isis, catalyst   |Sponsor:
 |  Sponsor3
-+-

Comment (by saper):

 Funny thing: we need utf-8 support for IRC:)

 {{{
 :charm.oftc.net NOTICE AUTH :*** Looking up your hostname...
 :charm.oftc.net NOTICE AUTH :*** Checking Ident
 :charm.oftc.net NOTICE AUTH :*** Couldn't look up your hostname
 :charm.oftc.net NOTICE AUTH :*** No Ident response
 :charm.oftc.net NOTICE appveyor-ci :*** Connected securely via TLSv1.2
 ECDHE-RSA-AES256-GCM-SHA384-256
 :charm.oftc.net 001 appveyor-ci :Welcome to the OFTC Internet Relay Chat
 Network appveyor-ci
 PRIVMSG #tor-ci :git://repo.or.cz/tor/appveyor.git 0master 5a3cbaf -
 Marcin Cieślak: tests: do not hardcode path for IRC notifications
 ERROR: Failed to send notification:
 Traceback (most recent call last):
   File "C:\projects\appveyor\scripts\test\appveyor-irc-notify.py", line
 195, in 
 notify()
   File "C:\projects\appveyor\scripts\test\appveyor-irc-notify.py", line
 188, in notify
 irc_sock.send('PRIVMSG #{} :{}\r\n'.format(channel, msg).encode())
 UnicodeDecodeError: 'ascii' codec can't decode byte 0xc5 in position 81:
 ordinal not in range(128)
 }}}

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

Re: [tor-bugs] #17810 [Core Tor/Torflow]: TorFlow should ignore self-reported bandwidths when measuring relays

[Tor Bug Tracker & Wiki]

#17810: TorFlow should ignore self-reported bandwidths when measuring relays
--+
 Reporter:  robgjansen|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Torflow  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by starlight):

 A consensus parameter already exists for applying a factor to progressive
 offset calculation:  `bwauthkp`

 employed at aggregate.py:120

 searched and it does not appear anyone has tried tuning it since
 {{{
 K_p = 1.0
 T_i = 0
 T_d = 0
 }}}
 were established in

 https://trac.torproject.org/projects/tor/ticket/4596#comment:2

 
https://gitweb.torproject.org/torflow.git/commit/NetworkScanners/BwAuthority/aggregate.py?id=4a4b8a73185f763f0def3e0d30c052f3abeb6fa0

 from observing Torflow behavior, it seems to me a K_p of 1.0 is a bit
 strong

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

Re: [tor-bugs] #25870 [Core Tor/Tor]: Fix vanguard restrictions

[Tor Bug Tracker & Wiki]

#25870: Fix vanguard restrictions
--+
 Reporter:  mikeperry |  Owner:  (none)
 Type:  defect| Status:  needs_review
 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:
--+

Comment (by asn):

 Replying to [comment:11 mikeperry]:
 > Ok I edited the commit message to clarify that A - B - A is for sub-
 paths. I also added a commit for Property 6. Otherwise asn's commits are
 taken as-is.
 >
 > https://oniongit.eu/mikeperry/tor/commits/bug25870_v2
 >
 > Leaving as needs_review for asn to have a look at the last commit on
 that branch, which does the refactoring he asked for on IRC, and gives us
 "strong" property 6.

 Sounds good. Please check my branch `bug25870_rebase` which tidies up the
 _v2
 branch a bit by squashing a few commits and giving a more logical flow.
 Feel
 free to not use if you don't like it. Check the diff between
 `bug25870_rebase`
 and `bug25870_v2` to see that the diff is just comments.

 BTW, should we use `DEFAULT_ROUTE_LEN+1` in the latest commit? What
 happens in
 the case of even longer RP/IP/HSDir circuits that could occur because of
 cannibalization? e.g. I remember that Tor clients extend failed IP
 circuits by
 one hop to connect to the next IP, this means that those circuits can end
 up
 being more than 5 hops.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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):

 The snippet of code in comment:11 is not called unless the circuit is in
 {{{CIRCUIT_PURPOSE_C_INTRODUCE_ACK_WAIT}}}.  It would be interesting to
 confirm the purpose of the circuit just before it is deleted.  More
 generally, it would be interesting to confirm how the circuit purposes
 change for the circuits that are in place during the period covered by the
 logs after we reach a bad intro point.  In the case of {{{debug.log.A}}},
 we can list all of the state transitions after 06:30:20:

 {{{
 $ tail -91500 debug.A.log | grep "changing purpose" | sed -e "s/.*[0-9]
 from/from/g" | sort | uniq -c

  89 from "General-purpose client" (5) to "Hidden service client:
 Connecting to intro point" (6)
  89 from "General-purpose client" (5) to "Hidden service client:
 Establishing rendezvous point" (9)
   3 from "General-purpose client" (5) to "Measuring circuit timeout"
 (13)
  89 from "Hidden service client: Connecting to intro point" (6) to
 "Hidden service client: Waiting for ack from intro point" (7)
  89 from "Hidden service client: Establishing rendezvous point" (9) to
 "Hidden service client: Pending rendezvous point" (10)
  89 from "Hidden service client: Pending rendezvous point" (10) to
 "Hidden service client: Pending rendezvous point (ack received)" (11)
  89 from "Hidden service client: Waiting for ack from intro point" (7)
 to "Hidden service client: Received ack from intro point" (8)
 }}}

 We can represent the purpose changes in a state transition diagram, as
 follows, where the numbers in the circles represent the purposes, and the
 values on the edges represent the number of state transitions observed:

 [[Image(tor-25882.png, 100%)]]

 For reference, here is a table containing the states:

 ||= State =||= Tag in {{{or.h}}} =||= Description =||
 || 5 || {{{CIRCUIT_PURPOSE_C_GENERAL}}} || "General-purpose client" ||
 || 6 || {{{CIRCUIT_PURPOSE_C_INTRODUCING}}} || "Hidden service client:
 Connecting to intro point" ||
 || 7 || {{{CIRCUIT_PURPOSE_C_INTRODUCE_ACK_WAIT}}} || ""Hidden service
 client: Waiting for ack from intro point ||
 || 8 || {{{CIRCUIT_PURPOSE_C_INTRODUCE_ACKED}}} || "Hidden service client:
 Connecting to intro point" ||
 || 9 || {{{CIRCUIT_PURPOSE_C_ESTABLISH_REND}}} || "Hidden service client:
 Establishing rendezvous point" ||
 || 10 || {{{CIRCUIT_PURPOSE_C_REND_READY}}} || "Hidden service client:
 Pending rendezvous point" ||
 || 11 || {{{CIRCUIT_PURPOSE_C_REND_READY_INTRO_ACKED}}} || "Hidden service
 client: Pending rendezvous point (ack received)" ||
 || 13 || {{{CIRCUIT_PURPOSE_C_MEASURE_TIMEOUT}}} || "Measuring circuit
 timeout" ||

 We can conclude from the state transitions that circuits are not in fact
 "freed" when they are in transition state 7
 ({{{CIRCUIT_PURPOSE_C_INTRODUCE_ACK_WAIT}}}).  In fact, all of our
 circuits are actually in either state 8
 ({{{CIRCUIT_PURPOSE_C_INTRODUCE_ACKED}}}) or state 11
 ({{{CIRCUIT_PURPOSE_C_REND_READY_INTRO_ACKED}}}) instead.  So, it is
 therefore not sufficient to require them to be in state 7 when we are
 reporting a timeout. We should also check for state 8.

 If a circuit is reaped whilst in state 8, then it is also in a timeout
 state worthy of reporting.

 Therefore, suggest that we consider the following change:

 {{{
 --- circuitlist.c.orig  2018-04-30 23:02:07.322368461 +
 +++ circuitlist.c   2018-04-30 23:03:01.721876917 +
 @@ -2004,7 +2004,8 @@
   orig_reason);
}

 -  if (circ->purpose == CIRCUIT_PURPOSE_C_INTRODUCE_ACK_WAIT) {
 +  if (circ->purpose == CIRCUIT_PURPOSE_C_INTRODUCE_ACK_WAIT ||
 +  circ->purpose == CIRCUIT_PURPOSE_C_INTRODUCE_ACKED) {
  origin_circuit_t *ocirc = TO_ORIGIN_CIRCUIT(circ);
  int timed_out = (reason == END_CIRC_REASON_TIMEOUT);
  tor_assert(circ->state == CIRCUIT_STATE_OPEN);
 }}}

 What do you think?

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

Re: [tor-bugs] #25967 [Core Tor/Tor]: v3 onion keep working without the HiddenServiceVersion 3 line

[Tor Bug Tracker & Wiki]

#25967: v3 onion keep working without the HiddenServiceVersion 3 line
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, 033-must-maybe, |  Actual Points:
  032-backport, 033-backport |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:   => tor-hs, prop224, 033-must-maybe, 032-backport,
   033-backport
 * version:   => Tor: 0.3.2.1-alpha
 * milestone:   => 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

[tor-bugs] #25968 [Applications/Tor Browser]: No audio during video playback

[Tor Bug Tracker & Wiki]

#25968: No audio during video playback
--+--
 Reporter:  heyjoe|  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:|
--+--
 STR:

 1. Try to play a video with audio, for example:

 
https://media.libreplanet.org/mgoblin_media/media_entries/2070/FSFKeynotewithSlidesHighRes.ogg

 EXPECTED:
 The video should play with audio.

 ACTUAL:
 There is no audio and a notification shows up saying: "To play audio, you
 may need to install the required PulseAudio software" + button "Learn
 how". But pulseaudio is already installed and works with other apps:

 [~]: rpm -q pulseaudio
 pulseaudio-9.0-8.1.x86_64

 Security level is set to "Safest"

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

Re: [tor-bugs] #25549 [Core Tor/Tor]: Add tor CI config for AppVeyor

[Tor Bug Tracker & Wiki]

#25549: Add tor CI config for AppVeyor
-+-
 Reporter:  isis |  Owner:  saper
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, tor-testing, 034-roadmap-|  Actual Points:
  subtask, 034-triage-20180328,  |
  034-included-20180328  |
Parent ID:  #25550   | Points:  2
 Reviewer:  isis, catalyst   |Sponsor:
 |  Sponsor3
-+-

Comment (by saper):

 IRC gateway path should not be hardcoded
 
(http://repo.or.cz/tor/appveyor.git/commitdiff/5a3cbaf3758d6e93ab0e206e6bd88d1001304628)
 also it would be cool if the notificator didn't we all run 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] #25960 [Core Tor/Tor]: Allow additional header lines in bandwidth measurements documents

[Tor Bug Tracker & Wiki]

#25960: Allow additional header lines in bandwidth measurements documents
-+-
 Reporter:  juga |  Owner:  juga
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bwauth, 029-backport, 031-backport,  |  Actual Points:
  032-backport, 033-backport |
Parent ID:  #25925   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => 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] #25960 [Core Tor/Tor]: Allow additional header lines in bandwidth measurements documents

[Tor Bug Tracker & Wiki]

#25960: Allow additional header lines in bandwidth measurements documents
-+-
 Reporter:  juga |  Owner:  juga
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bwauth, 029-backport, 031-backport,  |  Actual Points:
  032-backport, 033-backport |
Parent ID:  #25925   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Thanks, I left some comments on
 https://github.com/juga0/tor/tree/bug25960_maint-0.2.9_additional_headers

 1. A note about strict versus lax parsing. We don't need to change any
 code.
 2. Please add unit tests where header lines fail to parse.

 It would also be great if we had tests for entire version 1.0.0 and
 version 1.1.0 files, so we know we haven't broken parsing.

 Here's one way to code these tests, if the existing function takes a
 filename:
 1. Mock read_file_to_string to return the test data

 Here's another way:
 1. Refactor the existing tor code so it reads the file to a string in one
 function A, then passes the string to another function B
 2. Call function B with the test data

 Let me know if you need help with this code.

 Please add extra commits for each change, and don't squash until we're
 ready to merge,
 (When we squash, we keep commits that do different things separate.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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 cypherpunks):

 * Attachment "tor-25882.png" 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] #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 cypherpunks):

 * Attachment "tor-25882.pdf" 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] #25967 [Core Tor/Tor]: v3 onion keep working without the HiddenServiceVersion 3 line

[Tor Bug Tracker & Wiki]

#25967: v3 onion keep working without the HiddenServiceVersion 3 line
--+
 Reporter:  cypherpunks   |  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 cypherpunks):

 Hasty typing + bad english = Confusion.
 Sorry about that.

 I started off this experiment with an empty HiddenServiceDir folder, and
 yes I did save the torrc before doing kill -HUP. Otherwise the v2 onion
 private key wouldn't have been created.

 The point is, in the end, BOTH v2 and v3 ended up working and running
 using a single HiddenServiceDir block with no HiddenServiceVersion 3 line.

 The hostname file content eventually had the v2 address only. It did show
 the v3 address before I commented out the version line as expected.

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

Re: [tor-bugs] #17949 [Core Tor/Tor]: Make loopback address search more accurate

[Tor Bug Tracker & Wiki]

#17949: Make loopback address search more accurate
-+-
 Reporter:  teor |  Owner:  rl1987
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy tor-client tor-relay loopback   |  Actual Points:
  weird-configuration|
Parent ID:  #17991   | Points:
 Reviewer:  ahf, teor|Sponsor:
-+-
Changes (by ahf):

 * status:  needs_review => needs_revision


Comment:

 Commented on GH PR.

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

Re: [tor-bugs] #25549 [Core Tor/Tor]: Add tor CI config for AppVeyor

[Tor Bug Tracker & Wiki]

#25549: Add tor CI config for AppVeyor
-+-
 Reporter:  isis |  Owner:  saper
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, tor-testing, 034-roadmap-|  Actual Points:
  subtask, 034-triage-20180328,  |
  034-included-20180328  |
Parent ID:  #25550   | Points:  2
 Reviewer:  isis, catalyst   |Sponsor:
 |  Sponsor3
-+-

Comment (by saper):

 I think `zstd` is not working because, again, there is no `zstd-devel`
 available.

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

Re: [tor-bugs] #15015 [Core Tor/Tor]: tor --verify-config should not bind to ports

[Tor Bug Tracker & Wiki]

#15015: tor --verify-config should not bind to ports
-+-
 Reporter:  cypherpunks  |  Owner:  rl1987
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, intro, startup,   |  Actual Points:
  configuration, torrc, bootstrap, refactor, |
  technical-debt |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => needs_revision
 * points:  small =>
 * milestone:  Tor: unspecified => Tor: 0.3.4.x-final


Comment:

 Thanks for this patch.

 The code looks good, but I think we can improve the man page:
 * please put parse-config immediately after verify-config
 * please explicitly document the different use cases for verify and parse:
   * verify may fail if the tor service is already running
   * parse should be used if the tor service is running

 If you'd like, you can also set up Travis CI on your branch, or open a
 pull request on https://github.com/torproject/tor
 https://trac.torproject.org/projects/tor/ticket/23883#comment:3
 It's the first thing the next reviewer will do.

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

Re: [tor-bugs] #25942 [Core Tor/Tor]: Fix win32 test failure for crypto/openssl_version

[Tor Bug Tracker & Wiki]

#25942: Fix win32 test failure for crypto/openssl_version
+--
 Reporter:  isis|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Tor|Version:  Tor:
|  0.3.3.5-rc
 Severity:  Normal  | Resolution:
 Keywords:  tor-ci tor-windows tor-testing  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+--

Comment (by saper):

 If there is anyone to blame are those cool Linux architects who invented
 "devel" packages.

 (I think this is because there is no `mingw-w64-x86_64-openssl-devel`
 pendant to `mingw-w64-x86_64-openssl`, as there is `openssl-devel` for
 `openssl`).

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

Re: [tor-bugs] #25942 [Core Tor/Tor]: Fix win32 test failure for crypto/openssl_version

[Tor Bug Tracker & Wiki]

#25942: Fix win32 test failure for crypto/openssl_version
+--
 Reporter:  isis|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Tor|Version:  Tor:
|  0.3.3.5-rc
 Severity:  Normal  | Resolution:
 Keywords:  tor-ci tor-windows tor-testing  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+--

Comment (by saper):

 I think that this is related to two openssl's being installed, one from
 MSYS, the other one from MinGW. One comes with headers, but the other one
 comes with DLL. I thought once I understand the theory between MSYS and
 MinGW ("One is just enough unix to let you run configure, the other one is
 real stuff you link you app with") but this is kind of confusing.

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

Re: [tor-bugs] #20522 [Core Tor/Tor]: Enable DISABLE_DISABLING_ED25519

[Tor Bug Tracker & Wiki]

#20522: Enable DISABLE_DISABLING_ED25519
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ed25519-proto,   |  Actual Points:
  034-triage-20180328, 034-included-20180405 |
  fast-fix   |
Parent ID:   | Points:  0.5
 Reviewer:  ahf  |Sponsor:
 |  SponsorZ
-+-
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 I think this looks good to me code-wise, I saw the email had been send
 out. Marking this 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] #25967 [Core Tor/Tor]: v3 onion keep working without the HiddenServiceVersion 3 line

[Tor Bug Tracker & Wiki]

#25967: v3 onion keep working without the HiddenServiceVersion 3 line
--+
 Reporter:  cypherpunks   |  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:
--+
Changes (by Dbryrtfbcbhgf):

 * component:  - Select a component => Core Tor/Tor


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

Re: [tor-bugs] #25967 [- Select a component]: v3 onion keep working without the HiddenServiceVersion 3 line

[Tor Bug Tracker & Wiki]

#25967: v3 onion keep working without the HiddenServiceVersion 3 line
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by Dbryrtfbcbhgf):

 1. when you comment out {{{HiddenServiceVersion 3}}} make sure you save
 the new torrc
 2. Try restarting the Tor service using {{{systemctl restart tor@default
 }}} this works on Linux.

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

Re: [tor-bugs] #23107 [Core Tor/Tor]: prop224: Optimize hs_circ_service_get_intro_circ() digest calculation

[Tor Bug Tracker & Wiki]

#23107: prop224: Optimize hs_circ_service_get_intro_circ() digest calculation
-+-
 Reporter:  asn  |  Owner:  neel
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, prop224-extra, tor-hs,  |  Actual Points:
  optimization, 032-unreached|
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_revision => needs_review
 * 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] #25549 [Core Tor/Tor]: Add tor CI config for AppVeyor

[Tor Bug Tracker & Wiki]

#25549: Add tor CI config for AppVeyor
-+-
 Reporter:  isis |  Owner:  saper
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, tor-testing, 034-roadmap-|  Actual Points:
  subtask, 034-triage-20180328,  |
  034-included-20180328  |
Parent ID:  #25550   | Points:  2
 Reviewer:  isis, catalyst   |Sponsor:
 |  Sponsor3
-+-
Changes (by saper):

 * cc: saper@… (added)


Comment:

 Ouch, didn't see there were so many updates! Thank you isis for picking it
 up! (Now I think I am subscribed to notifications).

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

Re: [tor-bugs] #17810 [Core Tor/Torflow]: TorFlow should ignore self-reported bandwidths when measuring relays

[Tor Bug Tracker & Wiki]

#17810: TorFlow should ignore self-reported bandwidths when measuring relays
--+
 Reporter:  robgjansen|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Torflow  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by starlight):

 * Attachment "bwscan_cnsns.20180429-1345-plus.xlsx" added.

 Torflow + consensus what-if spreadsheet as-of 20180429-1345 -- rev 3

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17810>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
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] #25967 [- Select a component]: v3 onion keep working without the HiddenServiceVersion 3 line

[Tor Bug Tracker & Wiki]

#25967: v3 onion keep working without the HiddenServiceVersion 3 line
--+
 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:
  Sponsor:|
--+
 I started by defining a v3 hidden service in torrc and running tor, thus
 creating a v3 private key.

 Then I commented out the HiddenServiceVersion 3 line and sent the tor
 process a sighup using kill -HUP processid.

 The v2 private key and hostname were generated, but the v3 address kept
 working the v2 address did not work.

 I then sent sighup again, and this time both the v2 and v3 addresses
 worked.

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

Re: [tor-bugs] #25966 [- Select a component]: Report on Tor in the UAE (and question about Snowflake)

[Tor Bug Tracker & Wiki]

#25966: Report on Tor in the UAE (and question about Snowflake)
--+
 Reporter:  mwolfe|  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Very Low  |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:  snowflake |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 Replying to [comment:1 dcf]:
 > You can work around it by using the alternative domain fronts from
 #22782.
 Small tutorial on how to do that in case you don't know: (although someone
 should confirm if I didn't make any mistake)

 1. Go to your Tor Browser directory. Then go the folder `Browser` then
 `TorBrowser` then `Data` then `Tor`.
 2. Open the `torrc-defaults` using a text editor and change the snowflake
 line from
 {{{
 ClientTransportPlugin snowflake exec ./TorBrowser/Tor/PluggableTransports
 /snowflake-client -url https://snowflake-reg-test.appspot.com/ -front
 www.google.com -ice stun:stun.l.google.com:19302
 }}}
 to
 {{{
 ClientTransportPlugin snowflake exec ./TorBrowser/Tor/PluggableTransports
 /snowflake-client -url https://d3prdmp6d0elsl.cloudfront.net/ -front
 a0.awsstatic.com -ice stun:stun.l.google.com:19302
 }}}
 3. Save, and enjoy!

 --

 Also by obfs4 you mean you got them from the BridgeDB or you used the
 default ones (in the dropdown menu when they ask which pluggable transport
 to use)?

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

Re: [tor-bugs] #17810 [Core Tor/Torflow]: TorFlow should ignore self-reported bandwidths when measuring relays

[Tor Bug Tracker & Wiki]

#17810: TorFlow should ignore self-reported bandwidths when measuring relays
--+
 Reporter:  robgjansen|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Torflow  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by starlight):

 replaced sheet with correction for a mistake

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

Re: [tor-bugs] #17810 [Core Tor/Torflow]: TorFlow should ignore self-reported bandwidths when measuring relays

[Tor Bug Tracker & Wiki]

#17810: TorFlow should ignore self-reported bandwidths when measuring relays
--+
 Reporter:  robgjansen|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Torflow  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by starlight):

 * Attachment "bwscan_cnsns.20180429-1345-plus.xlsx" removed.

 Torflow + consensus what-if spreadsheet as-of 20180429-1345

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

Re: [tor-bugs] #17810 [Core Tor/Torflow]: TorFlow should ignore self-reported bandwidths when measuring relays

[Tor Bug Tracker & Wiki]

#17810: TorFlow should ignore self-reported bandwidths when measuring relays
--+
 Reporter:  robgjansen|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Torflow  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by starlight):

 * Attachment "bwscan_cnsns.20180429-1345-plus.xlsx" added.

 orflow + consensus what-if spreadsheet as-of 20180429-1345

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

Re: [tor-bugs] #25966 [- Select a component]: Report on Tor in the UAE (and question about Snowflake)

[Tor Bug Tracker & Wiki]

#25966: Report on Tor in the UAE (and question about Snowflake)
--+
 Reporter:  mwolfe|  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Very Low  |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:  snowflake |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dcf):

 * keywords:   => snowflake


Comment:

 Snowflake stopped working because Google blocked domain fronting to App
 Engine, which Snowflake uses for rendezvous: #25804.

 You can work around it by using the alternative domain fronts from #22782.

 See also #25594 about alternative rendezvous methods.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25966 [- Select a component]: Report on Tor in the UAE (and question about Snowflake)

[Tor Bug Tracker & Wiki]

#25966: Report on Tor in the UAE (and question about Snowflake)
--+
 Reporter:  mwolfe|  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Very Low  |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Trivial   |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Early in '17, Tor stopped working. Turned out, they'd turned on blocking,
 but obfs4 worked. Then obfs4 stopped, and someone suggested I try
 Snowflake, which worked back then. But Snowflake stopped working one day,
 and I learned it was alpha, and not well supported, so I switched to meek.
 Now I can't get Snowflake to work at all (Tor doesn't even load), but
 obfs4 is working again, and seems to work much better than meek.

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

Re: [tor-bugs] #17569 [Applications/Tor Browser]: Add uBlock Origin to the Tor Browser

[Tor Bug Tracker & Wiki]

#17569: Add uBlock Origin to the Tor Browser
-+-
 Reporter:  kernelcorn   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability tbb-security, tbb- |  Actual Points:
  performance|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 This would also be a good step in the right direction for Firefox
 upstream:
 https://wiki.mozilla.org/Firefox/Roadmap

 has entries like

 Filter certain types of ads by default: Firefox will offer users a simple
 ad filtering option. We're in the early stages still, researching types of
 advertisements that should be blocked by default. (Q3)

 as well as making tracking more difficult and stop auto-play videos like
 chrome has done it.
 Instead of just having the "basics" it could be a joint effort to have the
 logic for blocking and replacing in FF/TBB and the filter lists by the
 community.

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

Re: [tor-bugs] #25960 [Core Tor/Tor]: Allow additional header lines in bandwidth measurements documents

[Tor Bug Tracker & Wiki]

#25960: Allow additional header lines in bandwidth measurements documents
-+-
 Reporter:  juga |  Owner:  juga
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bwauth, 029-backport, 031-backport,  |  Actual Points:
  032-backport, 033-backport |
Parent ID:  #25925   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by juga):

 * status:  needs_revision => 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] #25960 [Core Tor/Tor]: Allow additional header lines in bandwidth measurements documents

[Tor Bug Tracker & Wiki]

#25960: Allow additional header lines in bandwidth measurements documents
-+-
 Reporter:  juga |  Owner:  juga
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bwauth, 029-backport, 031-backport,  |  Actual Points:
  032-backport, 033-backport |
Parent ID:  #25925   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by juga):

 I think i implemented all the points in branch
 bug25960_maint-0.2.9_additional_headers (github, my fork). Ready for
 review again.

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

Re: [tor-bugs] #17810 [Core Tor/Torflow]: TorFlow should ignore self-reported bandwidths when measuring relays

[Tor Bug Tracker & Wiki]

#17810: TorFlow should ignore self-reported bandwidths when measuring relays
--+
 Reporter:  robgjansen|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Torflow  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by starlight):

 * Attachment "bwscan_cnsns.20180429-1345-plus.xlsx" added.

 Torflow + consensus what-if spreadsheet as-of 20180429-1345

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

Re: [tor-bugs] #17810 [Core Tor/Torflow]: TorFlow should ignore self-reported bandwidths when measuring relays

[Tor Bug Tracker & Wiki]

#17810: TorFlow should ignore self-reported bandwidths when measuring relays
--+
 Reporter:  robgjansen|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Torflow  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by starlight):

 Fair enough.  Appears to be a terrible idea anyway.

 Cooked up the attached spreadsheet and eliminating self-measure does not
 seem to work.  Also tried applying a 20% linear factor to Torflow's
 progressive-offset vote generation method; perhaps retaining scanner
 biased self-advertised bandwidth while demphasizing its consensus impact
 has merit.

 This spreadsheet might be useful for brainstorming and what-if analysis.

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

Re: [tor-bugs] #25852 [Core Tor/Tor]: GETINFO exit-policy for tor client should return 551

[Tor Bug Tracker & Wiki]

#25852: GETINFO exit-policy for tor client should return 551
--+--
 Reporter:  dmr   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec, tor-client  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by rl1987):

 * status:  new => needs_review


Comment:

 * https://github.com/rl1987/tor/compare/bug25852
 * https://github.com/rl1987/torspec/compare/bug25852

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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 dcf):

 Replying to [comment:25 twim]:
 > It turns out that AppEngine is not the only option for domain fronting
 with Google.
 > Google also provides a service called
 [https://developers.google.com/amp/cache/ AMP cache] for
 [https://ampproject.org/ AMP pages]. What it basically does is proxying
 random pages on the Internet and making them load faster (e.g. on Google
 search results). It requires pages to comply with some format though and
 also strips invisible content, resizes images, etc.
 > Despite it is being served via different domain names (one per real
 domain) it is still hosted at Google infrastructure which can be fronted.

 Thanks, twim, this is good work. Would you create a new ticket for the
 Snowflake part and link it from #25594?

 I think, for the broker side, all we would need to do is add a new route,
 `/amp/client` or whatever, which is the same as the existing `/client`
 except that it adds the AMP header and trailer.

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

Re: [tor-bugs] #15015 [Core Tor/Tor]: tor --verify-config should not bind to ports

[Tor Bug Tracker & Wiki]

#15015: tor --verify-config should not bind to ports
-+-
 Reporter:  cypherpunks  |  Owner:  rl1987
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, intro, startup,   |  Actual Points:
  configuration, torrc, bootstrap, refactor, |
  technical-debt |
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-
Changes (by rl1987):

 * status:  assigned => needs_review


Comment:

 Added `--parse-config` CLI option:
 * https://github.com/rl1987/tor/compare/ticket15015

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

Re: [tor-bugs] #25603 [Applications/Tor Browser]: Update Orfox HTTPS-E Add-on

[Tor Bug Tracker & Wiki]

#25603: Update Orfox HTTPS-E Add-on
--+--
 Reporter:  sysrqb|  Owner:  sysrqb
 Type:  enhancement   | Status:  assigned
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201804  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sysrqb):

 Process for creating new https-everywhere xpi:

 1) Checkout tag `2018.4.11`
 2) Copy src/chrome/content/rules into another directory outside working
 directory (`cp -r src/chrome/content/rules ../`)
 3) Checkout tag `5.2.21`
 4) Edit src/install.rdf - clear updateURL and updateKey [0] (this prevents
 auto-updating)
 5) Delete directory src/META-INF/ (`rm -r src/META-INF`)
 6) Delete all current rules (`rm -r src/chrome/content/rules/`)
 7) Copy new rules into working directory (`cp -r ../rules
 src/chrome/content/`)
 8) `./makexpi.sh`
 9 `sha256sum pkg/https-everywhere-5.2.21~4c7803208b-dirty-eff.xpi` is
 {{{
 7a33c13dbd80fd881b1508fca6dc10fca787f8eb4da754104321537240ffb866  pkg
 /https-everywhere-5.2.21~4c7803208b-dirty-eff.xpi
 }}}
 10) Copy pkg/https-everywhere-5.2.21~4c7803208b-dirty-eff.xpi into `tor-
 browser/mobile/android/orfox/distribution/assets/distribution/extensions
 /https-everywhere-...@eff.org.xpi`

 [0] Diff from step (4)
 {{{
 diff --git a/src/install.rdf b/src/install.rdf
 index fe321f48b0..6fa8ece9c7 100644
 --- a/src/install.rdf
 +++ b/src/install.rdf
 @@ -15,8 +15,8 @@
  chrome://https-everywhere/content/observatory-
 preferences.xul
  chrome://https-everywhere/skin/icon-
 active-48.png
  false
 -https://www.eff.org/files/https-everywhere-eff-
 update-2048.rdf 
 -
 
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6MR8W/galdxnpGqBsYbqOzQb2eyW15YFjDDEMI0ZOzt8f504obNs920lDnpPD2/KqgsfjOgw2K7xWDJIj/18xUvWPk3LDkrnokNiRkA3KOx3W6fHycKL+zID7zy+xZYBuh2fLyQtWV1VGQ45iNRp9+Zo7rH86cdfgkdnWTlNSHyTLW9NbXvyv/E12bppPcEvgCTAQXgnDVJ0/sqmeiijn9tTFh03aM+R2V/21h8aTraAS24qiPCz6gkmYGC8yr6mglcnNoYbsLNYZ69zF1XHcXPduCPdPdfLlzVlKK1/U7hkA28eG3BIAMh6uJYBRJTpiGgaGdPd7YekUB8S6cy+CQIDAQAB
 + 
 + 
  
  
  
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.9
 Severity:  Normal   | Resolution:  fixed
 Keywords:  prop286, 034-triage-20180328,|  Actual Points:
  034-must crash 033-backport 032-backport   |
  031-backport   |
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-

Comment (by teor):

 No, this fix is not in 0.3.3.5-rc:
 https://blog.torproject.org/tor-0335-rc-released
 But it is in nightly.

 The fix will be available in the next 0.3.1, 0.3.2, and 0.3.3 releases.

 Your options are:
 * upgrade to nightly using the instructions at
 https://www.torproject.org/docs/debian.html.en
 * downgrade to 0.2.9
 * add the following lines to your torrc as a workaround:
 {{{
 ORPort 12345
 PublishDescriptor 0
 }}}

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

Re: [tor-bugs] #25962 [Applications/Tor Browser]: Tor Browser crash: [xcb] Unknown sequence number while processing queue

[Tor Bug Tracker & Wiki]

#25962: Tor Browser crash: [xcb] Unknown sequence number while processing queue
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Happens a lot unfortunately, and can be triggered by opening up a lot of
 links in new tabs (go to news.ycombinator.com for example and start
 opening up all of the links there in new tabs consecutively until it
 crashes).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.9
 Severity:  Normal   | Resolution:  fixed
 Keywords:  prop286, 034-triage-20180328,|  Actual Points:
  034-must crash 033-backport 032-backport   |
  031-backport   |
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-

Comment (by tiejohg2sahth):

 My I ask when the fix will be available through the official PPA on Ubuntu
 18.04?

 I see with:
 {{{
 curl -s https://deb.torproject.org/torproject.org/pool/main/t/tor/ | grep
 -o '"tor_.*bionic.*_amd64\.deb"'
 }}}
 that 0.3.3.5-rc1 and 0.3.4.0-alpha are available in the PPA, presumably
 with the fix for this bug merged in it, however when I update with apt, I
 am still stuck with the 0.3.2.10 version which is unfortunately unusable.

 Or is there a particular step to do to be able to update to the pre-
 release versions?

 Thank you

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

Re: [tor-bugs] #25965 [Core Tor/Tor]: Document default value of Nickname parameter [patch]

[Tor Bug Tracker & Wiki]

#25965: Document default value of Nickname parameter [patch]
--+
 Reporter:  saper |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Very Low  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  doc   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  needs_revision => merge_ready


Comment:

 Replying to [comment:2 saper]:
 > Updated, thanks. Had no idea what this "staging" thing is.

 Thanks, this patch is ready to merge.

 > How long is the branch open? I have some further ideas to improve the
 manpage.

 Just open another ticket, and it will go in whichever release is
 available.
 We are on 0.3.3.5-rc, so this patch or your next patch might go in 0.3.4.

 Or if your patch fixes something that's really bad, it might go all the
 way back to 0.2.9.

 We'll make it work.

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

Re: [tor-bugs] #25965 [Core Tor/Tor]: Document default value of Nickname parameter [patch]

[Tor Bug Tracker & Wiki]

#25965: Document default value of Nickname parameter [patch]
--+
 Reporter:  saper |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Very Low  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  doc   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by saper):

 Updated, thanks. Had now idea what this "staging" thing is. How long is
 the branch open? I have some further ideas to improve the manpage.

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

Re: [tor-bugs] #25965 [Core Tor/Tor]: Document default value of Nickname parameter [patch]

[Tor Bug Tracker & Wiki]

#25965: Document default value of Nickname parameter [patch]
--+
 Reporter:  saper |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Very Low  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  doc   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * keywords:   => doc
 * status:  new => needs_revision
 * milestone:   => Tor: 0.3.3.x-final


Comment:

 Thanks for this patch, but minor changes go in torrc-minimal.in-staging,
 not torrc-minimal.in.
 Please make that change, and then flip to merge ready.

 Assigning to 0.3.3 because it's still open to doc fixes.
 We'll need to cherry-pick the commit, then marge forward.

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

Re: [tor-bugs] #25854 [Metrics/Relay Search]: Improve advertised/observed bandwidth mouseover text

[Tor Bug Tracker & Wiki]

#25854: Improve advertised/observed bandwidth mouseover text
--+--
 Reporter:  irl   |  Owner:  metrics-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by irl):

 Replying to [comment:3 teor]:
 > Can you help me understand why you need to know details about overheads?
 > The exact overheads that are included will change over time as we
 improve Tor's code and statistics.

 Mainly just to be precise about what it is we expect the numbers to
 represent, and to avoid ambiguity in the UI and documentation.

 Thanks for the detailed response, hopefully will get to updating the text
 soon.

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

[tor-bugs] #25965 [Core Tor/Tor]: Document default value of Nickname parameter [patch]

[Tor Bug Tracker & Wiki]

#25965: Document default value of Nickname parameter [patch]
--+
 Reporter:  saper |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Very Low  |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 While responding to an inquiry on IRC regarding [[https://salsa.debian.org
 /freedombox-team/plinth/issues/1294|Freedombox Plinth issue #1294: tor:
 let the user verify if the relay is connected]] I was wondering what
 happens if the `Nickname` is not set.

 I had to refer to the source code to find out.

 I have published a change that fixes this:

 http://repo.or.cz/tor/appveyor.git/shortlog/refs/heads/default_nickname

 ("default_nickname" branch on http://repo.or.cz/tor/appveyor.git)

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

[tor-bugs] #25964 [Core Tor/Tor]: Remove hs_index_t fetch, and use one of the stores instead

[Tor Bug Tracker & Wiki]

#25964: Remove hs_index_t fetch, and use one of the stores instead
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  technical-debt, refactor
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Split off from
 https://trac.torproject.org/projects/tor/ticket/23094#comment:9

 Replying to [#23094:comment:3 asn]:
 > After our #23387 refactoring of hsdir index logic Nick suggested that we
 don't need to keep all 3 around in memory, since two of them are always
 identical:
 > https://oniongit.eu/asn/tor/merge_requests/6#note_1201

 We need to:
 * analyse the state machine of fetch, store_first, and store_second to
 make sure that fetch is always equal to store_first or store_second
 * work out the condition that we can use to select betweeen store_first or
 store_second when we want fetch
 * write a function that produces fetch from a hsdir_index_t, and use it
 instead of fetch

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

Re: [tor-bugs] #23094 [Core Tor/Tor]: prop224: Optimize hsdir_index calculation

[Tor Bug Tracker & Wiki]

#23094: prop224: Optimize hsdir_index calculation
-+-
 Reporter:  asn  |  Owner:  neel
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, prop224-extra,  |  Actual Points:
  032-unreached  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Ok, I opened #24964 for the remaining work.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25963 [Core Tor/Tor]: Clarify the bandwidth part of dir-spec

[Tor Bug Tracker & Wiki]

#25963: Clarify the bandwidth part of dir-spec
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  metrics-wants, tor-spec, doc, fast-
 Severity:  Normal   |  fix
Actual Points:   |  Parent ID:  #25854
   Points:  0.2  |   Reviewer:
  Sponsor:   |
-+-
 People keep asking about the precise meaning of relay bandwidths. We
 should make the spec clearer:

 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n424

 In particular:
 * there is a separate limit on inbound and outbound traffic
 * traffic includes origin circuits and BEGINDIR requests
 * let's check if traffic includes DirPort, I think it would have to

 There may also be more feedback in #25854.

 I'm tagging this fast-fix, because I can fix it fast, and it will save me
 time when I next explain 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] #25854 [Metrics/Relay Search]: Improve advertised/observed bandwidth mouseover text

[Tor Bug Tracker & Wiki]

#25854: Improve advertised/observed bandwidth mouseover text
--+--
 Reporter:  irl   |  Owner:  metrics-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 Oh, I forgot. If you want a simple amendment to your text, here is
 something to start with:

 The volume of traffic that the relay is willing to sustain. The rate
 and burst limits apply separately to inbound and outbound traffic. The
 observed bandwidth is the minimum of recent inbound and outbound traffic,
 as reported by the 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] #25854 [Metrics/Relay Search]: Improve advertised/observed bandwidth mouseover text

[Tor Bug Tracker & Wiki]

#25854: Improve advertised/observed bandwidth mouseover text
--+--
 Reporter:  irl   |  Owner:  metrics-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 Relay Search is currently ambiguous:

 The volume of traffic, both incoming and outgoing, that the relay is
 willing to sustain, as configured by the operator and claimed to be
 observed from recent data transfers.

 Replying to [comment:2 irl]:
 > The problem here is that dir-spec is not particularly clear on this, so
 probably some reading of the code is needed to make sure.

 I'll open a ticket to improve dir-spec, once we know what isn't clear.

 > Someone asked in IRC whether this was the sum of the total bandwidth
 (directory fetches, relay traffic, client traffic) in and out, or whether
 this was just for traffic that is relayed, or relayed traffic + overhead
 just for relaying traffic (and then whether it's the total in+out or just
 total throughput).

 I answered a similar question for tjr in #tor-project a week or so ago. If
 anyone has the IRC backlog, they can get the full details.
 I'll try to reconstruct it here.

 This is what the spec currently says:

Estimated bandwidth for this router, in bytes per second.  The
"average" bandwidth is the volume per second that the OR is willing
 to
sustain over long periods; the "burst" bandwidth is the volume that
the OR is willing to sustain in very short intervals.  The
 "observed"
value is an estimate of the capacity this relay can handle.  The
relay remembers the max bandwidth sustained output over any ten
second period in the past day, and another sustained input.  The
"observed" value is the lesser of these two numbers.

 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n424

 In other words, the spec says that:
 * average bandwidth limit is the maximum bandwidth the relay is willing to
 handle over long periods
 * burst bandwidth limit is the maximum bandwidth the relay is willing to
 handle over short periods
 * observed bandwidth rate is min(in, out) where in and out are the maximum
 bandwidths sustained inbound or outbound over any recent 10 second period
 over the last day

 The spec isn't explicit about the direction of the traffic, except for
 observed bandwidth. Here is how Tor currently implements the bandwidth
 limits:
 * there is a token bucket for inbound traffic, and tor stops reading from
 the kernel once the bucket is empty
 * there is a token bucket for outbound traffic, and tor stops writing to
 the kernel once the bucket is empty

 The difference between kernel and link-level traffic causes some
 interesting issues for people who are trying to get precise bandwidths.
 See, for example, #25687. Our general advice is "don't worry about that
 level of detail".

 So there is a separate limit on both inbound and outbound traffic.
 The effective relayed rate is min(in, out), and includes some overheads,
 just like the observed bandwidth.
 We can update dir-spec to clarify this.

 The spec also doesn't specify whether the bandwidth includes overheads, so
 you should assume that it does include some overheads, and it doesn't
 include others. In particular:
 * Recent tor versions include everything over an ORPort, whether it
 originates at the relay, is relayed for a client, or is sent to a client
 in response to a BEGINDIR request. We can update the spec to clarify this.
 * I'm not sure if Tor includes DirPort traffic. We could find out what tor
 does and specify it. But I'm not sure if this level of detail is relevant.
 * As far as I recall, Tor includes all cell packing overhead, but not TLS,
 TCP, IP, or link layer overhead. But I'm not sure if this level of detail
 is relevant.

 Can you help me understand why you need to know details about overheads?
 The exact overheads that are included will change over time as we improve
 Tor's code and statistics.

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

Re: [tor-bugs] #23094 [Core Tor/Tor]: prop224: Optimize hsdir_index calculation

[Tor Bug Tracker & Wiki]

#23094: prop224: Optimize hsdir_index calculation
-+-
 Reporter:  asn  |  Owner:  neel
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, prop224-extra,  |  Actual Points:
  032-unreached  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by neel):

 Replying to [comment:9 teor]:
 > We can do this in a separate ticket if you'd like to merge just the
 first patch. They are independent. And integers are cheap.

 I think think we should just 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

[tor-bugs] #25962 [Applications/Tor Browser]: Tor Browser crash: [xcb] Unknown sequence number while processing queue

[Tor Bug Tracker & Wiki]

#25962: Tor Browser crash: [xcb] Unknown sequence number while processing queue
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-crash
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 Happened after I switched to Lubuntu (latest LTS, latest Tor Browser alpha
 64),

 {{{
 [notice] Have tried resolving or connecting to address '[scrubbed]' at 3
 different places. Giving up.
 [xcb] Unknown sequence number while processing queue
 [xcb] Most likely this is a multi-threaded client and XInitThreads has not
 been called
 [xcb] Aborting, sorry about that.
 firefox: ../../src/xcb_io.c:259: poll_for_event: Assertion
 `!xcb_xlib_threads_sequence_lost' failed.
 [Child 4116] WARNING: pipe error (3): Connection reset by peer: file
 /var/tmp/build/firefox-
 90e16dd25b6e/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 322
 [Child 4116] ###!!! ABORT: Aborting on channel error.: file /var/tmp/build
 /firefox-90e16dd25b6e/ipc/glue/MessageChannel.cpp, line 2152
 [Child 4116] ###!!! ABORT: Aborting on channel error.: file /var/tmp/build
 /firefox-90e16dd25b6e/ipc/glue/MessageChannel.cpp, line 2152
 [notice] Owning controller connection has closed -- exiting now.
 [notice] Catching signal TERM, exiting cleanly.
 ./start-tor-browser: line 372:  4023 Aborted (core dumped)
 TOR_CONTROL_PASSWD=${TOR_CONTROL_PASSWD} ./firefox --class "Tor Browser"
 -profile TorBrowser/Data/Browser/profile.default "${@}" < /dev/null
 }}}

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

Re: [tor-bugs] #25961 [Internal Services/Tor Sysadmin Team]: URGENT:!!

[Tor Bug Tracker & Wiki]

#25961: URGENT:!!
-+-
 Reporter:  cypherpunks  |  Owner:  tpa
 Type:  defect   | Status:  closed
 Priority:  Immediate|  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Blocker  | Resolution:  invalid
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by weasel):

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


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

Re: [tor-bugs] #25854 [Metrics/Relay Search]: Improve advertised/observed bandwidth mouseover text

[Tor Bug Tracker & Wiki]

#25854: Improve advertised/observed bandwidth mouseover text
--+--
 Reporter:  irl   |  Owner:  metrics-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by irl):

 The problem here is that dir-spec is not particularly clear on this, so
 probably some reading of the code is needed to make sure.

 Someone asked in IRC whether this was the sum of the total bandwidth
 (directory fetches, relay traffic, client traffic) in and out, or whether
 this was just for traffic that is relayed, or relayed traffic + overhead
 just for relaying traffic (and then whether it's the total in+out or just
 total throughput).

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

Re: [tor-bugs] #25961 [Internal Services/Tor Sysadmin Team]: URGENT:!!

[Tor Bug Tracker & Wiki]

#25961: URGENT:!!
-+-
 Reporter:  cypherpunks  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Immediate|  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Blocker  | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 @teor why are you marking this under tor sys? The cypherpunks seems to
 have said that the problem was with gettor but he was unspecific anyways.

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

Re: [tor-bugs] #25961 [Internal Services/Tor Sysadmin Team]: URGENT:!!

[Tor Bug Tracker & Wiki]

#25961: URGENT:!!
-+-
 Reporter:  cypherpunks  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Immediate|  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Blocker  | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * owner:  ilv => tpa
 * component:  Applications/GetTor => Internal Services/Tor Sysadmin Team


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

Re: [tor-bugs] #25961 [Applications/GetTor]: URGENT:!!

[Tor Bug Tracker & Wiki]

#25961: URGENT:!!
-+-
 Reporter:  cypherpunks  |  Owner:  ilv
 Type:  defect   | Status:  new
 Priority:  Immediate|  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Blocker  | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

 * version:  Tor: 0.3.3.5-rc =>
 * milestone:  Tor: unspecified =>


Comment:

 Please be more specific.

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

[Tor Bug Tracker & Wiki]

#25961: URGENT:!!
-+--
 Reporter:  cypherpunks  |  Owner:  ilv
 Type:  defect   | Status:  new
 Priority:  Immediate|  Milestone:  Tor: unspecified
Component:  Applications/GetTor  |Version:  Tor: 0.3.3.5-rc
 Severity:  Blocker  |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 There is a worm in your servers. Trust me! :) have fun
 I know how it got in and i know how to remove it. A little puzzle 4 u

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

Re: [tor-bugs] #25957 [Core Tor/Tor]: Tor 0.3.3.5-rc died: Caught signal 11

[Tor Bug Tracker & Wiki]

#25957: Tor 0.3.3.5-rc died: Caught signal 11
--+
 Reporter:  Pine64ARMv8   |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.5-rc
 Severity:  Normal| Resolution:
 Keywords:  crash, openssl, 033-must  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 https://stackoverflow.com/questions/22051294/malloc-segmentation-fault
 > A SIGSEGV (segmentation fault) is firing in malloc is usually caused by
 heap corruption. Heap corruption does not cause a segmentation fault, so
 you would see that only when malloc tries to access there. **The problem
 is that the code that creates the heap corruption could be in any point
 even far away from where the malloc is called.** It is usually the next-
 block pointer inside the malloc that is changed by your heap corruption to
 an invalid address, so that when you call malloc an invalid pointer gets
 dereferenced and you get a segmentation fault.

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