Re: [tor-bugs] #22399 [Applications/Tor Launcher]: Tor launcher third-party censorship circumvention tools support

[Tor Bug Tracker & Wiki]

#22399: Tor launcher third-party censorship circumvention tools support
---+---
 Reporter:  iry|  Owner:  brade
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID:  #21951 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by iry):

 * cc: iry (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] #20348 [Metrics/Censorship analysis]: Kazakhstan blocking of vanilla Tor and obfs4 by Allot Communications hardware, 2016-06

[Tor Bug Tracker & Wiki]

#20348: Kazakhstan blocking of vanilla Tor and obfs4 by Allot Communications
hardware, 2016-06
-+-
 Reporter:  dcf  |  Owner:
 Type:  project  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:  censorship block kz  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dcf):

 I uploaded several months worth of data of bridge connection attempts from
 the U.S. and Kazakhstan over several months (since December 2016). I
 haven't done much analysis of this yet. For each of the connection
 attempts there is a tor log and for some of them there is additionally a
 pcap. The file bridgetest/bridgetest.csv is probably what you want to look
 at first; it's timestamps of tor connection bootstrap percentages per
 attempt.

 https://www.bamsoftware.com/proxy-probe/kz-data/

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

Re: [tor-bugs] #22402 [Webpages/Website]: Usablity and accessiblity improvement on the Tor assistant page

[Tor Bug Tracker & Wiki]

#22402: Usablity and accessiblity improvement on the Tor assistant page
--+---
 Reporter:  iry   |  Owner:  linda
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:  #21951| Points:
 Reviewer:|Sponsor:
--+---
Changes (by iry):

 * cc: iry (added)
 * keywords:   => ux-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] #22402 [Webpages/Website]: Usablity and accessiblity improvement on the Tor assistant page

[Tor Bug Tracker & Wiki]

#22402: Usablity and accessiblity improvement on the Tor assistant page
--+---
 Reporter:  iry   |  Owner:  linda
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #21951| Points:
 Reviewer:|Sponsor:
--+---

Comment (by iry):

 For the first issue, it may be a good idea to Unblock Tor assistance
 webpage by collateral freedom. That is to say, we may host a mirror
 assistant page on website like Github which is "too expensive to block" by
 a censor. Tor has already had some positive attempt to unblock the content
 by collateral freedom. One example is the gettorbrowser page hosted on
 Github: https://github.com/TheTorProject/gettorbrowser

 For the second issue, although the best hope is that the instruction
 provided by Tor Launcher is clear enough for helping users configure the
 Tor, it will still be helpful to provide a detailed tutorial webpage on
 how to use Tor launcher in different cases.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22402 [Webpages/Website]: Usablity and accessiblity improvement on the Tor assistant page

[Tor Bug Tracker & Wiki]

#22402: Usablity and accessiblity improvement on the Tor assistant page
--+
 Reporter:  iry   |  Owner:  linda
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #21951
   Points:|   Reviewer:
  Sponsor:|
--+
 The current version of Tor Launcher shows "For assistance, visit
 torproject.org/about/contact.html#support". The link is usually used by
 users who meet trouble in configuring the Tor using the Tor Launcher.

 However, there are two problems with that:
 1. The webpage is hosted on Tor official website, which means users who
 live in heavily censored area may not be able to access the webpage
 directly.
 2. Even if they can access the webpage, the instruction is too general to
 solve their most likely problem which is how to configure the Tor
 Launcher.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22401 [Webpages/Blog]: Pictures don't load in blog posts

[Tor Bug Tracker & Wiki]

#22401: Pictures don't load in blog posts
---+
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #22013
   Points: |   Reviewer:
  Sponsor: |
---+
 https://blog.torproject.org/blog/lifecycle-of-a-new-relay
 is supposed to have a picture:
 {{{
 https://extra.torproject.org/blog/2013-09-11-lifecycle-of-a
 -new-relay/lifecycle.png" rel="nofollow">
 }}}

 But it doesn't show up on the page.

 See also
 https://blog.torproject.org/blog/what-tor-supporter-looks-edward-snowden

 Is it being blocked by some sort of content security policy? Or is it
 something else?

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

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

[Tor Bug Tracker & Wiki]

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Old description:

> I started my Tor client (0.3.1.1-alpha (git-ab9976b7245f05a9)) with these
> three guards (and only these three guards) in my state file:
> {{{
> Guard in=default rsa_id=BB119A5A4D5DA2BBB7B796ECC50E3C0F1D4FD910
> nickname=onslaught sampled_on=2017-04-29T09:28:05 sampled_by=0.3.1.0
> -alpha-dev listed=1 confirmed_on=2017-05-02T22:48:40 confirmed_idx=1
> Guard in=default rsa_id=7369A0E14C59B11D78357EC5AFE573A259264BBD
> nickname=yono1 sampled_on=2017-05-02T20:44:35 sampled_by=0.3.1.0-alpha-
> dev listed=1 confirmed_on=2017-04-25T13:14:11 confirmed_idx=0
> pb_use_attempts=3.00 pb_use_successes=3.00
> pb_circ_attempts=105.00 pb_circ_successes=105.00
> pb_successful_circuits_closed=95.00 pb_collapsed_circuits=10.00
> pb_timeouts=8.00
> Guard in=default rsa_id=62DA0256BBC28992D41CBAFB549FFD7C9B846A99
> nickname=IRejectTorFoundatnN sampled_on=2017-05-21T02:25:50
> sampled_by=0.3.1.0-alpha-dev listed=1 confirmed_on=2017-05-23T22:28:05
> confirmed_idx=2
> }}}
>
> I figured that since there were three, and they were all confirmed, they
> would be my primary guards.
>
> Also, my cached-microdesc-consensus file was about a day old.
>
> When Tor starts, it says
> {{{
> May 25 20:58:06.155 [info] sampled_guards_update_from_consensus(): No
> live consensus; can't update sampled entry guards.
> }}}
> Ok, great, it's not going to go deleting or modifying any of my guards
> before it's even tried to load my consensus file from disk. Makes sense.
>
> Then it goes through to update my three guards to say that they're not
> working:
> {{{
> May 25 20:58:06.155 [debug] entry_guard_set_filtered_flags(): Updated
> sampled guard onslaught ($BB119A5A4D5DA2BBB7B796ECC50E3C0F1D4FD910):
> filtered=0; reachable_filtered=0.
> May 25 20:58:06.155 [debug] entry_guard_set_filtered_flags(): Updated
> sampled guard yono1 ($7369A0E14C59B11D78357EC5AFE573A259264BBD):
> filtered=0; reachable_filtered=0.
> May 25 20:58:06.156 [debug] entry_guard_set_filtered_flags(): Updated
> sampled guard IRejectTorFoundatnN
> ($62DA0256BBC28992D41CBAFB549FFD7C9B846A99): filtered=0;
> reachable_filtered=0.
> }}}
> I'm guessing that happened because of entry_guards_update_filtered_sets()
> which got called from entry_guards_update_all(), but there are several
> possible paths to that function so I'm not sure which one it was. Maybe
> it's decided they're all down, since it hasn't even loaded a consensus
> yet, so they're all missing from the nonexistent consensus?
>
> Then we get to:
> {{{
> May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
> Trying to sample a reachable guard: We know of 0 in the USABLE_FILTERED
> set.
> May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
> (That isn't enough. Trying to expand the sample.)
> May 25 20:58:06.156 [info] entry_guards_expand_sample(): Expanding the
> sample guard set. We have 3 guards in the sample, and 0 eligible guards
> to extend it with.
> May 25 20:58:06.156 [info] entry_guards_expand_sample(): Not expanding
> the guard sample any further; just ran out of eligible guards
> May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
> (After filters [b], we have 0 guards to consider.)
> }}}
> Ok, great, we refuse to expand the guard list now. That's good because we
> don't have any consensus loaded yet.
>
> Then I finish loading the state file, and load other stuff from my
> datadirectory, like the cached-microdesc-consensus file:
> {{{
> May 25 20:58:06.644 [info] A consensus needs 5 good signatures from
> recognized authorities for us to accept it. This one has 8 (dannenberg
> tor26 longclaw maatuska moria1 dizum gabelmoo Faravahar).
> May 25 20:58:06.797 [info] microdesc_cache_reload(): Reloaded
> microdescriptor cache. Found 7298 descriptors.
> May 25 20:58:06.812 [info]
> update_consensus_networkstatus_fetch_time_impl(): No live microdesc
> consensus; we should fetch one immediately.
> May 25 20:58:06.812 [info] cell_ewma_set_scale_factor(): Enabled
> cell_ewma algorithm because of value in CircuitPriorityHalflifeMsec in
> consensus; scale factor is 0.793701 per 10 seconds
> May 25 20:58:07.046 [info] networkstatus_set_current_consensus(): Loaded
> an expired consensus. Discarding.
> May 25 20:58:07.046 [info] router_reload_consensus_networkstatus():
> Couldn't load 

Re: [tor-bugs] #20604 [Core Tor/Tor]: Allow exponential backoff to configure a once-off initial delay

[Tor Bug Tracker & Wiki]

#20604: Allow exponential backoff to configure a once-off initial delay
--+
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.1-alpha
 Severity:  Normal| Resolution:  worksforme
 Keywords:  triaged-out-20170116  |  Actual Points:
Parent ID:  #20534| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by teor):

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


Comment:

 This is already how the code is written, but it doesn't work in most cases
 because we don't reset the download status before we use it, see #17750.

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

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

[Tor Bug Tracker & Wiki]

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:4 teor]:
 > Replying to [ticket:22400 arma]:
 > > And it launches a parallel fetch to an authority too, just like it's
 supposed to:
 > > {{{
 > > May 25 20:58:07.185 [info] directory_send_command(): Downloading
 consensus from 154.35.175.225:443 using /tor/status-vote/current
 /consensus-
 microdesc/0232AF+14C131+23D15D+49015F+D586D1+E8A9C4+ED03BB+EFCBE7.z
 > > }}}
 >
 > No, that's a bug: #20604.
 >
 > There's no need for every client to contact an authority: they didn't in
 0.2.8, and they all worked fine. But when the exponential backoff code was
 merged, there was no provision for a set initial delay, and we couldn't
 define the schedules so that we'd get a short delay without blowing out
 the remaining attempts. So we got this compromise.

 Sorry, I was wrong.

 This happened because we never reset download statuses before we use them.
 See #17750.

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

Re: [tor-bugs] #22399 [Applications/Tor Launcher]: Tor launcher third-party censorship circumvention tools support

[Tor Bug Tracker & Wiki]

#22399: Tor launcher third-party censorship circumvention tools support
---+---
 Reporter:  iry|  Owner:  brade
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID:  #21951 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by iry):

 Two common way a censorship circumvention tools can work with Tor:

 1. The censorship circumvention tools, for example a VPN, will handle all
 the traffic generated by Tor automatically.

 2. The other case is that the censorship circumvention tools, for example
 Lantern, Psiphon3 or Shadowsocks, will open a HTTP/Sock port(s) as an
 interface, listening the traffic coming from Tor.

 In the first case, users can simply click the "connect" button on the Tor
 Launcher and the censorship circumvention tool will help Tor bypass the
 Tor censorship. However, the current instruction ask users whether they
 would like to "make a direct connection to the Tor network". People who
 use a VPN may not think they are connecting to the Tor network "directly".
 So the instruction seems to be a little be misleading.

 In the second case, users need to configure the proxy setting on Tor
 launcher to use the interface provided by the third-party censorship
 circumvention tools. In this case, things are a little bit complex. The
 current instruction asks users if their connections to the Tor network are
 censored. If so, they will be guided to use a Tor bridge or some
 pluggable-transports. However, in heavily censored area, those tools may
 not be very effective. Therefore, it would be better to provide some
 instruction for users in heavily censored area on how to configure Tor to
 use some third-party censorship circumvention tools.

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

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

[Tor Bug Tracker & Wiki]

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 (It could be argued, though, that it's better to have more load on the
 directory authorities rather than clients waiting for 10 seconds when the
 3 fallbacks they choose are down. Someone else can work that one out!)

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

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

[Tor Bug Tracker & Wiki]

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Old description:

> I started my Tor client (0.3.1.1-alpha (git-ab9976b7245f05a9)) with these
> three guards (and only these three guards) in my state file:
> {{{
> Guard in=default rsa_id=BB119A5A4D5DA2BBB7B796ECC50E3C0F1D4FD910
> nickname=onslaught sampled_on=2017-04-29T09:28:05 sampled_by=0.3.1.0
> -alpha-dev listed=1 confirmed_on=2017-05-02T22:48:40 confirmed_idx=1
> Guard in=default rsa_id=7369A0E14C59B11D78357EC5AFE573A259264BBD
> nickname=yono1 sampled_on=2017-05-02T20:44:35 sampled_by=0.3.1.0-alpha-
> dev listed=1 confirmed_on=2017-04-25T13:14:11 confirmed_idx=0
> pb_use_attempts=3.00 pb_use_successes=3.00
> pb_circ_attempts=105.00 pb_circ_successes=105.00
> pb_successful_circuits_closed=95.00 pb_collapsed_circuits=10.00
> pb_timeouts=8.00
> Guard in=default rsa_id=62DA0256BBC28992D41CBAFB549FFD7C9B846A99
> nickname=IRejectTorFoundatnN sampled_on=2017-05-21T02:25:50
> sampled_by=0.3.1.0-alpha-dev listed=1 confirmed_on=2017-05-23T22:28:05
> confirmed_idx=2
> }}}
>
> I figured that since there were three, and they were all confirmed, they
> would be my primary guards.
>
> Also, my cached-microdesc-consensus file was about a day old.
>
> When Tor starts, it says
> {{{
> May 25 20:58:06.155 [info] sampled_guards_update_from_consensus(): No
> live consensus; can't update sampled entry guards.
> }}}
> Ok, great, it's not going to go deleting or modifying any of my guards
> before it's even tried to load my consensus file from disk. Makes sense.
>
> Then it goes through to update my three guards to say that they're not
> working:
> {{{
> May 25 20:58:06.155 [debug] entry_guard_set_filtered_flags(): Updated
> sampled guard onslaught ($BB119A5A4D5DA2BBB7B796ECC50E3C0F1D4FD910):
> filtered=0; reachable_filtered=0.
> May 25 20:58:06.155 [debug] entry_guard_set_filtered_flags(): Updated
> sampled guard yono1 ($7369A0E14C59B11D78357EC5AFE573A259264BBD):
> filtered=0; reachable_filtered=0.
> May 25 20:58:06.156 [debug] entry_guard_set_filtered_flags(): Updated
> sampled guard IRejectTorFoundatnN
> ($62DA0256BBC28992D41CBAFB549FFD7C9B846A99): filtered=0;
> reachable_filtered=0.
> }}}
> I'm guessing that happened because of entry_guards_update_filtered_sets()
> which got called from entry_guards_update_all(), but there are several
> possible paths to that function so I'm not sure which one it was. Maybe
> it's decided they're all down, since it hasn't even loaded a consensus
> yet, so they're all missing from the nonexistent consensus?
>
> Then we get to:
> {{{
> May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
> Trying to sample a reachable guard: We know of 0 in the USABLE_FILTERED
> set.
> May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
> (That isn't enough. Trying to expand the sample.)
> May 25 20:58:06.156 [info] entry_guards_expand_sample(): Expanding the
> sample guard set. We have 3 guards in the sample, and 0 eligible guards
> to extend it with.
> May 25 20:58:06.156 [info] entry_guards_expand_sample(): Not expanding
> the guard sample any further; just ran out of eligible guards
> May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
> (After filters [b], we have 0 guards to consider.)
> }}}
> Ok, great, we refuse to expand the guard list now. That's good because we
> don't have any consensus loaded yet.
>
> Then I finish loading the state file, and load other stuff from my
> datadirectory, like the cached-microdesc-consensus file:
> {{{
> May 25 20:58:06.644 [info] A consensus needs 5 good signatures from
> recognized authorities for us to accept it. This one has 8 (dannenberg
> tor26 longclaw maatuska moria1 dizum gabelmoo Faravahar).
> May 25 20:58:06.797 [info] microdesc_cache_reload(): Reloaded
> microdescriptor cache. Found 7298 descriptors.
> May 25 20:58:06.812 [info]
> update_consensus_networkstatus_fetch_time_impl(): No live microdesc
> consensus; we should fetch one immediately.
> May 25 20:58:06.812 [info] cell_ewma_set_scale_factor(): Enabled
> cell_ewma algorithm because of value in CircuitPriorityHalflifeMsec in
> consensus; scale factor is 0.793701 per 10 seconds
> May 25 20:58:07.046 [info] networkstatus_set_current_consensus(): Loaded
> an expired consensus. Discarding.
> May 25 20:58:07.046 [info] router_reload_consensus_networkstatus():
> Couldn't load 

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

[Tor Bug Tracker & Wiki]

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Description changed by arma:

Old description:

> I started my Tor client (0.3.1.1-alpha (git-ab9976b7245f05a9)) with these
> three guards (and only these three guards) in my state file:
> {{{
> Guard in=default rsa_id=BB119A5A4D5DA2BBB7B796ECC50E3C0F1D4FD910
> nickname=onslaught sampled_on=2017-04-29T09:28:05 sampled_by=0.3.1.0
> -alpha-dev listed=1 confirmed_on=2017-05-02T22:48:40 confirmed_idx=1
> Guard in=default rsa_id=7369A0E14C59B11D78357EC5AFE573A259264BBD
> nickname=yono1 sampled_on=2017-05-02T20:44:35 sampled_by=0.3.1.0-alpha-
> dev listed=1 confirmed_on=2017-04-25T13:14:11 confirmed_idx=0
> pb_use_attempts=3.00 pb_use_successes=3.00
> pb_circ_attempts=105.00 pb_circ_successes=105.00
> pb_successful_circuits_closed=95.00 pb_collapsed_circuits=10.00
> pb_timeouts=8.00
> Guard in=default rsa_id=62DA0256BBC28992D41CBAFB549FFD7C9B846A99
> nickname=IRejectTorFoundatnN sampled_on=2017-05-21T02:25:50
> sampled_by=0.3.1.0-alpha-dev listed=1 confirmed_on=2017-05-23T22:28:05
> confirmed_idx=2
> }}}
>
> I figured that since there were three, and they were all confirmed, they
> would be my primary guards.
>
> Also, my cached-microdesc-consensus file was about a day old.
>
> When Tor starts, it says
> {{{
> May 25 20:58:06.155 [info] sampled_guards_update_from_consensus(): No
> live consensus; can't update sampled entry guards.
> }}}
> Ok, great, it's not going to go deleting or modifying any of my guards
> before it's even tried to load my consensus file from disk. Makes sense.
>
> Then it goes through to update my three guards to say that they're not
> working:
> {{{
> May 25 20:58:06.155 [debug] entry_guard_set_filtered_flags(): Updated
> sampled guard onslaught ($BB119A5A4D5DA2BBB7B796ECC50E3C0F1D4FD910):
> filtered=0; reachable_filtered=0.
> May 25 20:58:06.155 [debug] entry_guard_set_filtered_flags(): Updated
> sampled guard yono1 ($7369A0E14C59B11D78357EC5AFE573A259264BBD):
> filtered=0; reachable_filtered=0.
> May 25 20:58:06.156 [debug] entry_guard_set_filtered_flags(): Updated
> sampled guard IRejectTorFoundatnN
> ($62DA0256BBC28992D41CBAFB549FFD7C9B846A99): filtered=0;
> reachable_filtered=0.
> }}}
> I'm guessing that happened because of entry_guards_update_filtered_sets()
> which got called from entry_guards_update_all(), but there are several
> possible paths to that function so I'm not sure which one it was. Maybe
> it's decided they're all down, since it hasn't even loaded a consensus
> yet, so they're all missing from the nonexistent consensus?
>
> Then we get to:
> {{{
> May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
> Trying to sample a reachable guard: We know of 0 in the USABLE_FILTERED
> set.
> May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
> (That isn't enough. Trying to expand the sample.)
> May 25 20:58:06.156 [info] entry_guards_expand_sample(): Expanding the
> sample guard set. We have 3 guards in the sample, and 0 eligible guards
> to extend it with.
> May 25 20:58:06.156 [info] entry_guards_expand_sample(): Not expanding
> the guard sample any further; just ran out of eligible guards
> May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
> (After filters [b], we have 0 guards to consider.)
> }}}
> Ok, great, we refuse to expand the guard list now. That's good because we
> don't have any consensus loaded yet.
>
> Then I finish loading the state file, and load other stuff from my
> datadirectory, like the cached-microdesc-consensus file:
> {{{
> May 25 20:58:06.644 [info] A consensus needs 5 good signatures from
> recognized authorities for us to accept it. This one has 8 (dannenberg
> tor26 longclaw maatuska moria1 dizum gabelmoo Faravahar).
> May 25 20:58:06.797 [info] microdesc_cache_reload(): Reloaded
> microdescriptor cache. Found 7298 descriptors.
> May 25 20:58:06.812 [info]
> update_consensus_networkstatus_fetch_time_impl(): No live microdesc
> consensus; we should fetch one immediately.
> May 25 20:58:06.812 [info] cell_ewma_set_scale_factor(): Enabled
> cell_ewma algorithm because of value in CircuitPriorityHalflifeMsec in
> consensus; scale factor is 0.793701 per 10 seconds
> May 25 20:58:07.046 [info] networkstatus_set_current_consensus(): Loaded
> an expired consensus. Discarding.
> May 25 20:58:07.046 [info] 

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

[Tor Bug Tracker & Wiki]

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Description changed by arma:

Old description:

> I started my Tor client (0.3.1.1-alpha (git-ab9976b7245f05a9)) with these
> three guards (and only these three guards) in my state file:
> {{{
> Guard in=default rsa_id=BB119A5A4D5DA2BBB7B796ECC50E3C0F1D4FD910
> nickname=onslaught sampled_on=2017-04-29T09:28:05 sampled_by=0.3.1.0
> -alpha-dev listed=1 confirmed_on=2017-05-02T22:48:40 confirmed_idx=1
> Guard in=default rsa_id=7369A0E14C59B11D78357EC5AFE573A259264BBD
> nickname=yono1 sampled_on=2017-05-02T20:44:35 sampled_by=0.3.1.0-alpha-
> dev listed=1 confirmed_on=2017-04-25T13:14:11 confirmed_idx=0
> pb_use_attempts=3.00 pb_use_successes=3.00
> pb_circ_attempts=105.00 pb_circ_successes=105.00
> pb_successful_circuits_closed=95.00 pb_collapsed_circuits=10.00
> pb_timeouts=8.00
> Guard in=default rsa_id=62DA0256BBC28992D41CBAFB549FFD7C9B846A99
> nickname=IRejectTorFoundatnN sampled_on=2017-05-21T02:25:50
> sampled_by=0.3.1.0-alpha-dev listed=1 confirmed_on=2017-05-23T22:28:05
> confirmed_idx=2
> }}}
>
> I figured that since there were three, and they were all confirmed, they
> would be my primary guards.
>
> Also, my cached-microdesc-consensus file was about a day old.
>
> When Tor starts, it says
> {{{
> May 25 20:58:06.155 [info] sampled_guards_update_from_consensus(): No
> live consensus; can't update sampled entry guards.
> }}}
> Ok, great, it's not going to go deleting or modifying any of my guards
> before it's even tried to load my consensus file from disk. Makes sense.
>
> Then it goes through to update my three guards to say that they're not
> working:
> {{{
> May 25 20:58:06.155 [debug] entry_guard_set_filtered_flags(): Updated
> sampled guard onslaught ($BB119A5A4D5DA2BBB7B796ECC50E3C0F1D4FD910):
> filtered=0; reachable_filtered=0.
> May 25 20:58:06.155 [debug] entry_guard_set_filtered_flags(): Updated
> sampled guard yono1 ($7369A0E14C59B11D78357EC5AFE573A259264BBD):
> filtered=0; reachable_filtered=0.
> May 25 20:58:06.156 [debug] entry_guard_set_filtered_flags(): Updated
> sampled guard IRejectTorFoundatnN
> ($62DA0256BBC28992D41CBAFB549FFD7C9B846A99): filtered=0;
> reachable_filtered=0.
> }}}
> I'm guessing that happened because of entry_guards_update_filtered_sets()
> which got called from entry_guards_update_all(), but there are several
> possible paths to that function so I'm not sure which one it was. Maybe
> it's decided they're all down, since it hasn't even loaded a consensus
> yet, so they're all missing from the nonexistent consensus?
>
> Then we get to:
> {{{
> May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
> Trying to sample a reachable guard: We know of 0 in the USABLE_FILTERED
> set.
> May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
> (That isn't enough. Trying to expand the sample.)
> May 25 20:58:06.156 [info] entry_guards_expand_sample(): Expanding the
> sample guard set. We have 3 guards in the sample, and 0 eligible guards
> to extend it with.
> May 25 20:58:06.156 [info] entry_guards_expand_sample(): Not expanding
> the guard sample any further; just ran out of eligible guards
> May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
> (After filters [b], we have 0 guards to consider.)
> }}}
> Ok, great, we refuse to expand the guard list now. That's good because we
> don't have any consensus loaded yet.
>
> Then I finish loading the state file, and load other stuff from my
> datadirectory, like the cached-microdesc-consensus file:
> {{{
> May 25 20:58:06.644 [info] A consensus needs 5 good signatures from
> recognized authorities for us to accept it. This one has 8 (dannenberg
> tor26 longclaw maatuska moria1 dizum gabelmoo Faravahar).
> May 25 20:58:06.797 [info] microdesc_cache_reload(): Reloaded
> microdescriptor cache. Found 7298 descriptors.
> May 25 20:58:06.812 [info]
> update_consensus_networkstatus_fetch_time_impl(): No live microdesc
> consensus; we should fetch one immediately.
> May 25 20:58:06.812 [info] cell_ewma_set_scale_factor(): Enabled
> cell_ewma algorithm because of value in CircuitPriorityHalflifeMsec in
> consensus; scale factor is 0.793701 per 10 seconds
> May 25 20:58:07.046 [info] networkstatus_set_current_consensus(): Loaded
> an expired consensus. Discarding.
> May 25 20:58:07.046 [info] 

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

[Tor Bug Tracker & Wiki]

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Description changed by arma:

Old description:

> I started my Tor client (0.3.1.1-alpha (git-ab9976b7245f05a9)) with these
> three guards (and only these three guards) in my state file:
> {{{
> Guard in=default rsa_id=BB119A5A4D5DA2BBB7B796ECC50E3C0F1D4FD910
> nickname=onslaught sampled_on=2017-04-29T09:28:05 sampled_by=0.3.1.0
> -alpha-dev listed=1 confirmed_on=2017-05-02T22:48:40 confirmed_idx=1
> Guard in=default rsa_id=7369A0E14C59B11D78357EC5AFE573A259264BBD
> nickname=yono1 sampled_on=2017-05-02T20:44:35 sampled_by=0.3.1.0-alpha-
> dev listed=1 confirmed_on=2017-04-25T13:14:11 confirmed_idx=0
> pb_use_attempts=3.00 pb_use_successes=3.00
> pb_circ_attempts=105.00 pb_circ_successes=105.00
> pb_successful_circuits_closed=95.00 pb_collapsed_circuits=10.00
> pb_timeouts=8.00
> Guard in=default rsa_id=62DA0256BBC28992D41CBAFB549FFD7C9B846A99
> nickname=IRejectTorFoundatnN sampled_on=2017-05-21T02:25:50
> sampled_by=0.3.1.0-alpha-dev listed=1 confirmed_on=2017-05-23T22:28:05
> confirmed_idx=2
> }}}
>
> I figured that since there were three, and they were all confirmed, they
> would be my primary guards.
>
> Also, my cached-microdesc-consensus file was about a day old.
>
> When Tor starts, it says
> {{{
> May 25 20:58:06.155 [info] sampled_guards_update_from_consensus(): No
> live consensus; can't update sampled entry guards.
> }}}
> Ok, great, it's not going to go deleting or modifying any of my guards
> before it's even tried to load my consensus file from disk. Makes sense.
>
> Then it goes through to update my three guards to say that they're not
> working:
> {{{
> May 25 20:58:06.155 [debug] entry_guard_set_filtered_flags(): Updated
> sampled guard onslaught ($BB119A5A4D5DA2BBB7B796ECC50E3C0F1D4FD910):
> filtered=0; reachable_filtered=0.
> May 25 20:58:06.155 [debug] entry_guard_set_filtered_flags(): Updated
> sampled guard yono1 ($7369A0E14C59B11D78357EC5AFE573A259264BBD):
> filtered=0; reachable_filtered=0.
> May 25 20:58:06.156 [debug] entry_guard_set_filtered_flags(): Updated
> sampled guard IRejectTorFoundatnN
> ($62DA0256BBC28992D41CBAFB549FFD7C9B846A99): filtered=0;
> reachable_filtered=0.
> }}}
> I'm guessing that happened because of entry_guards_update_filtered_sets()
> which got called from entry_guards_update_all(), but there are several
> possible paths to that function so I'm not sure which one it was. Maybe
> it's decided they're all down, since it hasn't even loaded a consensus
> yet, so they're all missing from the nonexistent consensus?
>
> Then we get to:
> {{{
> May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
> Trying to sample a reachable guard: We know of 0 in the USABLE_FILTERED
> set.
> May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
> (That isn't enough. Trying to expand the sample.)
> May 25 20:58:06.156 [info] entry_guards_expand_sample(): Expanding the
> sample guard set. We have 3 guards in the sample, and 0 eligible guards
> to extend it with.
> May 25 20:58:06.156 [info] entry_guards_expand_sample(): Not expanding
> the guard sample any further; just ran out of eligible guards
> May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
> (After filters [b], we have 0 guards to consider.)
> }}}
> Ok, great, we refuse to expand the guard list now. That's good because we
> don't have any consensus loaded yet.
>
> Then I finish loading the state file, and load other stuff from my
> datadirectory, like the cached-microdesc-consensus file:
> {{{
> May 25 20:58:06.644 [info] A consensus needs 5 good signatures from
> recognized authorities for us to accept it. This one has 8 (dannenberg
> tor26 longclaw maatuska moria1 dizum gabelmoo Faravahar).
> May 25 20:58:06.797 [info] microdesc_cache_reload(): Reloaded
> microdescriptor cache. Found 7298 descriptors.
> May 25 20:58:06.812 [info]
> update_consensus_networkstatus_fetch_time_impl(): No live microdesc
> consensus; we should fetch one immediately.
> May 25 20:58:06.812 [info] cell_ewma_set_scale_factor(): Enabled
> cell_ewma algorithm because of value in CircuitPriorityHalflifeMsec in
> consensus; scale factor is 0.793701 per 10 seconds
> May 25 20:58:07.046 [info] networkstatus_set_current_consensus(): Loaded
> an expired consensus. Discarding.
> May 25 20:58:07.046 [info] 

[tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

[Tor Bug Tracker & Wiki]

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.7
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 I started my Tor client (0.3.1.1-alpha (git-ab9976b7245f05a9)) with these
 three guards (and only these three guards) in my state file:
 {{{
 Guard in=default rsa_id=BB119A5A4D5DA2BBB7B796ECC50E3C0F1D4FD910
 nickname=onslaught sampled_on=2017-04-29T09:28:05 sampled_by=0.3.1.0
 -alpha-dev listed=1 confirmed_on=2017-05-02T22:48:40 confirmed_idx=1
 Guard in=default rsa_id=7369A0E14C59B11D78357EC5AFE573A259264BBD
 nickname=yono1 sampled_on=2017-05-02T20:44:35 sampled_by=0.3.1.0-alpha-dev
 listed=1 confirmed_on=2017-04-25T13:14:11 confirmed_idx=0
 pb_use_attempts=3.00 pb_use_successes=3.00
 pb_circ_attempts=105.00 pb_circ_successes=105.00
 pb_successful_circuits_closed=95.00 pb_collapsed_circuits=10.00
 pb_timeouts=8.00
 Guard in=default rsa_id=62DA0256BBC28992D41CBAFB549FFD7C9B846A99
 nickname=IRejectTorFoundatnN sampled_on=2017-05-21T02:25:50
 sampled_by=0.3.1.0-alpha-dev listed=1 confirmed_on=2017-05-23T22:28:05
 confirmed_idx=2
 }}}

 I figured that since there were three, and they were all confirmed, they
 would be my primary guards.

 Also, my cached-microdesc-consensus file was about a day old.

 When Tor starts, it says
 {{{
 May 25 20:58:06.155 [info] sampled_guards_update_from_consensus(): No live
 consensus; can't update sampled entry guards.
 }}}
 Ok, great, it's not going to go deleting or modifying any of my guards
 before it's even tried to load my consensus file from disk. Makes sense.

 Then it goes through to update my three guards to say that they're not
 working:
 {{{
 May 25 20:58:06.155 [debug] entry_guard_set_filtered_flags(): Updated
 sampled guard onslaught ($BB119A5A4D5DA2BBB7B796ECC50E3C0F1D4FD910):
 filtered=0; reachable_filtered=0.
 May 25 20:58:06.155 [debug] entry_guard_set_filtered_flags(): Updated
 sampled guard yono1 ($7369A0E14C59B11D78357EC5AFE573A259264BBD):
 filtered=0; reachable_filtered=0.
 May 25 20:58:06.156 [debug] entry_guard_set_filtered_flags(): Updated
 sampled guard IRejectTorFoundatnN
 ($62DA0256BBC28992D41CBAFB549FFD7C9B846A99): filtered=0;
 reachable_filtered=0.
 }}}
 I'm guessing that happened because of entry_guards_update_filtered_sets()
 which got called from entry_guards_update_all(), but there are several
 possible paths to that function so I'm not sure which one it was. Maybe
 it's decided they're all down, since it hasn't even loaded a consensus
 yet, so they're all missing from the nonexistent consensus?

 Then we get to:
 {{{
 May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
 Trying to sample a reachable guard: We know of 0 in the USABLE_FILTERED
 set.
 May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
 (That isn't enough. Trying to expand the sample.)
 May 25 20:58:06.156 [info] entry_guards_expand_sample(): Expanding the
 sample guard set. We have 3 guards in the sample, and 0 eligible guards to
 extend it with.
 May 25 20:58:06.156 [info] entry_guards_expand_sample(): Not expanding the
 guard sample any further; just ran out of eligible guards
 May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
 (After filters [b], we have 0 guards to consider.)
 }}}
 Ok, great, we refuse to expand the guard list now. That's good because we
 don't have any consensus loaded yet.

 Then I finish loading the state file, and load other stuff from my
 datadirectory, like the cached-microdesc-consensus file:
 {{{
 May 25 20:58:06.644 [info] A consensus needs 5 good signatures from
 recognized authorities for us to accept it. This one has 8 (dannenberg
 tor26 longclaw maatuska moria1 dizum gabelmoo Faravahar).
 May 25 20:58:06.797 [info] microdesc_cache_reload(): Reloaded
 microdescriptor cache. Found 7298 descriptors.
 May 25 20:58:06.812 [info]
 update_consensus_networkstatus_fetch_time_impl(): No live microdesc
 consensus; we should fetch one immediately.
 May 25 20:58:06.812 [info] cell_ewma_set_scale_factor(): Enabled cell_ewma
 algorithm because of value in CircuitPriorityHalflifeMsec in consensus;
 scale factor is 0.793701 per 10 seconds
 May 25 20:58:07.046 [info] networkstatus_set_current_consensus(): Loaded
 an expired consensus. Discarding.
 May 25 20:58:07.046 [info] router_reload_consensus_networkstatus():
 Couldn't load unverified consensus microdesc networkstatus from cache
 }}}
 Ok, fine, it's expired so we discarded it, no problem.

 {{{
 May 

[tor-bugs] #22399 [Applications/Tor Launcher]: Tor launcher third-party censorship circumvention tools support

[Tor Bug Tracker & Wiki]

#22399: Tor launcher third-party censorship circumvention tools support
---+-
 Reporter:  iry|  Owner:  brade
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal |   Keywords:  ux-team
Actual Points: |  Parent ID:  #21951
   Points: |   Reviewer:
  Sponsor: |
---+-
 It seems that neither the current nor the proposed design of the Tor
 Launcher takes much care about the use case where Tor users use third-
 party censorship circumvention tools to bypass the Tor censorship.
 However, those third-party censorship circumvention tools are actually
 widely used in heavily censored area where Tor bridges and pluggable-
 transports are not effective.

 Therefore, it would be helpful to do more research on how we can design a
 better Tor Launcher to guide users configure the Tor to work with those
 third-party censorship circumvention tools.

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

Re: [tor-bugs] #21951 [Webpages]: Tor Launcher improvements and automation

[Tor Bug Tracker & Wiki]

#21951: Tor Launcher improvements and automation
--+---
 Reporter:  linda |  Owner:  linda
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by iry):

 * keywords:   => ux-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] #22212 [Core Tor/Tor]: [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel padding timeout scheduled 164729ms in the past. Did the monotonic clock just jump?

[Tor Bug Tracker & Wiki]

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

Comment (by mikeperry):

 Hrmm.. So in this log it looks like circuit construction delayed the
 connection housekeeping/run_scheduled_events() for a few seconds. This
 delay meant that the padding time elapsed before
 channelpadding_decide_to_pad_channel() was called, which meant that the
 time was in the past by the time it was called.. See also
 https://trac.torproject.org/projects/tor/ticket/16585

 I am not sure what to do about this. I could change the code to always
 schedule an actual timer right away and cancel it if data is sent instead
 (instead of waiting around until we get within a second before scheduling
 a timer). This may mean more timer churn, but now that the timers are more
 efficient, perhaps this is not an issue.

 Or, we could demote the log message to notice.

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

Re: [tor-bugs] #22398 [Applications/Tor Browser]: Upgrade Go to 1.8.3

[Tor Bug Tracker & Wiki]

#22398: Upgrade Go to 1.8.3
--+--
 Reporter:  yawning   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-gitian|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by yawning):

 Just for clarity the P-256 fix is in the Go 1.8.2 release as the only
 change, made a day prior.  But there isn't really a reason not to go to Go
 1.8.3.

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

[tor-bugs] #22398 [Applications/Tor Browser]: Upgrade Go to 1.8.3

[Tor Bug Tracker & Wiki]

#22398: Upgrade Go to 1.8.3
--+
 Reporter:  yawning   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-gitian
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Minor release notes: https://golang.org/doc/devel/release.html#go1.8.minor

 This also should include: https://github.com/golang/go/issues/20040

 Certain parts of our code do use P-256, but it's probably not exploitable.
 Updating is still a good idea.

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

Re: [tor-bugs] #22335 [Webpages/Blog]: Please remove "The" from the blog title

[Tor Bug Tracker & Wiki]

#22335: Please remove "The" from the blog title
---+--
 Reporter:  teor   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Low|  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID:  #22013 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by teor):

 * keywords:   => ux-team


Comment:

 I'd like someone from the UX team to give an opinion on 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] #22397 [Webpages/Blog]: Add a (single) onion service for the new tor blog

[Tor Bug Tracker & Wiki]

#22397: Add a (single) onion service for the new tor blog
---+--
 Reporter:  teor   |  Owner:  hiro
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22013 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by arma):

 Replying to [ticket:22397 teor]:
 > onion service compatibility (mainly URL rewrites)

 This one is an interesting question.

 I have no idea how we're doing on it. Probably not perfectly yet.

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

Re: [tor-bugs] #22397 [Webpages/Blog]: Add a (single) onion service for the new tor blog

[Tor Bug Tracker & Wiki]

#22397: Add a (single) onion service for the new tor blog
---+--
 Reporter:  teor   |  Owner:  hiro
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22013 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by arma):

 The reason we didn't do it for the old blog was that the old blog server
 not got into the main tor server rotation, so deploying the onion set-up
 on it was not easy.

 This new blog is run by the pantheon people, so it is also not in the main
 tor server rotation. I expect that means it continues to be not easy.

 That said, hiro has spoken of setting up a proxy, so we don't have to
 wonder what logs the pantheon folks keep: #22018. That step might make
 this ticket easier too.

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

[tor-bugs] #22397 [Webpages/Blog]: Add a (single) onion service for the new tor blog

[Tor Bug Tracker & Wiki]

#22397: Add a (single) onion service for the new tor blog
---+
 Reporter:  teor   |  Owner:  hiro
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #22013
   Points: |   Reviewer:
  Sponsor: |
---+
 When we asked for this for the old blog, it wasn't technically feasible
 (or it was a legacy system, so we decided not to do it).

 I hope that onion service compatibility (mainly URL rewrites) was one of
 the requirements for the new blog.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22396 [Applications/Tor Browser]: What does "never for this site" for the canvas warning really mean?

[Tor Bug Tracker & Wiki]

#22396: What does "never for this site" for the canvas warning really mean?
--+--
 Reporter:  arma  |  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:|
--+--
 When I get an html5 canvas warning in Tor Browser, it suggests that I pick
 "never for this site".

 To me, the word "never" implies that Tor Browser is writing down my
 answer, and it will use that answer forever after. Like the "permanent
 exceptions" for SSL certs.

 On the other hand, my understanding of Tor Browser behavior is that it
 wouldn't write it to disk, so my choice would be lost on the next browser
 reset or new identity click.

 There's a contradiction here. I'm assuming the second one is right. Is
 there a better phrase we can use than "never"?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22395 [Webpages/Blog]: find a way to present the comment threading more intuitively

[Tor Bug Tracker & Wiki]

#22395: find a way to present the comment threading more intuitively
---+
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #22013
   Points: |   Reviewer:
  Sponsor: |
---+
 Check out
 https://blog.torproject.org/blog/did-fbi-pay-university-attack-tor-
 users#comments
 then scroll down and try to figure out which comment is replying to which
 comment.

 The hierarchy is still basically flat, and you have to count the number of
 vertical lines to the left of the comment to try to figure out what's
 going on.

 I think it could be improved by indenting comments as a function of where
 they are in the nested hierarchy.

 But that's not the only possible way. I suspect there are other, better,
 options too.

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

[tor-bugs] #22394 [Webpages/Blog]: Missing styling on user pages

[Tor Bug Tracker & Wiki]

#22394: Missing styling on user pages
---+
 Reporter:  cypherpunks|  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #22013
   Points: |   Reviewer:
  Sponsor: |
---+
 Some pages on the user pages are missing styling. For example;

 https://blog.torproject.org/users/arma (see latest (top) post).
 https://blog.torproject.org/users/arma?page=1 (all posts).
 https://blog.torproject.org/users/gk?page=1 (all posts).

 However, not all pages all like this. For example;

 https://blog.torproject.org/users/arma?page=2
 https://blog.torproject.org/users/gk?page=2

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

Re: [tor-bugs] #22383 [Webpages/Blog]: Upcoming events are not showing up

[Tor Bug Tracker & Wiki]

#22383: Upcoming events are not showing up
---+--
 Reporter:  anadahz|  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22013 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 The events calender link on https://blog.torproject.org/events/upcoming
 links to http://dev-tor-blog-8.pantheonsite.io/events/month which requires
 authentication.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22393 [Webpages/Blog]: Commenter names are duplicated and inconsistent

[Tor Bug Tracker & Wiki]

#22393: Commenter names are duplicated and inconsistent
---+
 Reporter:  cypherpunks|  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #22013
   Points: |   Reviewer:
  Sponsor: |
---+
 The names of the commenters are duplicated in the comment and are
 inconsistent.

 For example https://blog.torproject.org/comment/268725#comment-268725
 shows
 {{{
 Anonymous

 Submitted by John (not verified) on May 25, 2017
 }}}

 Curiously when replying to the comment and previewing it results in
 {{{
 John

 Submitted by John (not verified) on May 25, 2017
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22392 [Webpages/Blog]: Should we remove or compress the left column on the blog?

[Tor Bug Tracker & Wiki]

#22392: Should we remove or compress the left column on the blog?
---+-
 Reporter:  arma   |  Owner:  hiro
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal |   Keywords:  ux-team
Actual Points: |  Parent ID:  #22013
   Points: |   Reviewer:
  Sponsor: |
---+-
 We have a new blog (yay), and it comes with a new template (mostly yay).

 The engineers among us have been staring at the left of the three columns
 on the blog, and wondering if that is the best amount of whitespace to
 use, while smushing all the content into the middle column.

 See e.g.
 https://blog.torproject.org/blog/tor-0306-released-new-series-stable
 and scroll down a bit. Notice how you're now reading a narrow column of
 text, with plentiful whitespace on either side of it.

 Maybe whoever designed this layout had a big screen resolution, and it
 worked better there.

 I have no clue how this looks on mobile, but ... ok, actually I went to go
 check, and on ios safari it just shows me the middle column, and it
 pretends those left and right columns aren't there. Lucky mobile users. :)

 I am adding the ux-team keyword in hopes that they can help us move
 forward. I know that "hey user experience people, can you help with
 layout, that's the same thing right" must drive you crazy, and I apologize
 in advance, but you're still our best hope 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] #22364 [Applications/Tor Browser]: nexusmods.com broken in Tor Browser

[Tor Bug Tracker & Wiki]

#22364: nexusmods.com broken in Tor Browser
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 Some possibilities:

 - Bug not reproducible on Linux
 - It is some kind of an IP ban, retrying with new circuit may help
 - You clicked the links at the top of the page (Files, Images, Videos ..)
 instead of the tabs that are at the middle (Desc, Files, Images, Posts ..)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22391 [Internal Services/Service - deb.tpo]: Add torrc.d configuration directory on deb packages

[Tor Bug Tracker & Wiki]

#22391: Add torrc.d configuration directory on deb packages
-+-
 Reporter:  Jigsaw52 |  Owner:  weasel
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service -  |Version:  Tor:
  deb.tpo|  0.3.1.1-alpha
 Severity:  Normal   |   Keywords:  deb torrc
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 A torrc.d style configuration directory could be added to the debian
 packages for version 0.3.1.1-alpha and above. Since #1922 is now
 implemented, it is easy to add this feature.

 I attempted to add this feature on this branch:
 https://github.com/Jigsaw52/debian-tor/tree/add-torrc.d

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

Re: [tor-bugs] #22327 [Applications/Tor Browser]: First party isolation of Page Info

[Tor Bug Tracker & Wiki]

#22327: First party isolation of Page Info
+--
 Reporter:  arthuredelstein |  Owner:  tbb-team
 Type:  defect  | Status:
|  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-7.0-must TorBrowserTeam201705R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by mcs):

 Kathy and I reviewed the changes and they look okay to us. But since we
 are not very familiar with the new way of doing isolation, we applied the
 patches and tried to run the revised code. Unfortunately, at least with
 our OSX debug build, invoking page info (Cmd+I) always causes an assertion
 failure:
 {{{
 Assertion failure: pb == (doa.mPrivateBrowsingId > 0), at /.../tor-
 browser/netwerk/base/LoadContextInfo.cpp:147
 }}}

 To make things more challenging, my lldb seems to have forgotten how to
 use symbols. I am not sure if we should be concerned about the assertion
 failure or not, but we will try again with an optimized build.

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

Re: [tor-bugs] #21861 [Applications/Tor Browser]: Make sure new mDNS code is disabled in ESR 52-based Tor Browsers

[Tor Bug Tracker & Wiki]

#21861: Make sure new mDNS code is disabled in ESR 52-based Tor Browsers
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, TorBrowserTeam201705R, |  Actual Points:
  tbb-7.0-must   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by gk):

 * status:  assigned => needs_review
 * keywords:  ff52-esr, TorBrowserTeam201705, tbb-7.0-must => ff52-esr,
 TorBrowserTeam201705R, tbb-7.0-must


Comment:

 `bug_21861_v2` (https://gitweb.torproject.org/user/gk/tor-
 browser.git/commit/?h=bug_21861_v2=e1216ec38f9a2a544763bde44c758275c1f2cb78)
 has a fix for this bug. I built with it for all three platforms in our
 Gitian environment and nothing blew up. Although, the Linux build did not
 want to compile first. I tried with the same patch locally and later on in
 Gitian as well and things worked then. Thus, I guess the first build
 failure was unrelated (the log was not really clear about why the build
 failed).

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

Re: [tor-bugs] #22017 [Webpages/Blog]: Provide per-tag comment moderation queues

[Tor Bug Tracker & Wiki]

#22017: Provide per-tag comment moderation queues
---+--
 Reporter:  hiro   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22013 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by arma):

 Do we really mean per-tag here? Where tag is the set of keywords you can
 put on a post? I think the original vision might have been "per blog
 post".

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

Re: [tor-bugs] #22013 [Webpages/Blog]: Migrate blog.tpo

[Tor Bug Tracker & Wiki]

#22013: Migrate blog.tpo
---+--
 Reporter:  hiro   |  Owner:  hiro
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Old description:

> This ticket will be used to track blog.tpo migration to a newer drupal
> installation.

New description:

 This ticket will be used to track blog.tpo migration to a newer drupal
 installation.

 Here is a list of still open tickets:
 
[[TicketQuery(status=accepted|assigned|needs_information|needs_review|needs_revision|new|reopened,parent=#22013,order=priority,format=table,col=status|summary|reporter|priority)]]

--

Comment (by arma):

 (added a table to the body of the ticket, with open tickets)

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

Re: [tor-bugs] #22098 [Applications/Tor Browser]: PulseAudio alert banner leads to a 404 page

[Tor Bug Tracker & Wiki]

#22098: PulseAudio alert banner leads to a 404 page
--+--
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff52-esr, tbb-7.0-must|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 `sumo` is determined by
 {{{
 if (type == "cannot-initialize-pulseaudio") {
   return "fix-common-audio-and-video-issues";
 }
 }}}
 in `browser-media.js` and the full URL opened by
 {{{
 let baseURL =
 Services.urlFormatter.formatURLPref("app.support.baseURL");
 openUILinkIn(baseURL + sumo, "tab");
 }}}
 `app.support.baseURL` points to
 `https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/`, so, hm.

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

Re: [tor-bugs] #22386 [Webpages/Blog]: Make the www.tpo script to pull blog rss files resume working

[Tor Bug Tracker & Wiki]

#22386: Make the www.tpo script to pull blog rss files resume working
---+--
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22013 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by arma):

 Could #22021 be related? It says it is fixed but it doesn't say what the
 url is.

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

Re: [tor-bugs] #22021 [Webpages/Blog]: Provide an RSS feed of blog posts that is accessible at its previous URL.

[Tor Bug Tracker & Wiki]

#22021: Provide an RSS feed of blog posts that is accessible at its previous 
URL.
---+
 Reporter:  hiro   |  Owner:  hiro
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID:  #22013 | Points:
 Reviewer: |Sponsor:
---+

Comment (by arma):

 See #22386 for how this part isn't working yet.

 Unless there is a different rss feed url that you made work 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] #22390 [Webpages/Blog]: How do I edit an existing blog post?

[Tor Bug Tracker & Wiki]

#22390: How do I edit an existing blog post?
---+--
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22013 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by arma):

 On
 https://blog.torproject.org/blog/transparency-openness-and-
 our-2015-financials
 I do see an option to 'view' or 'edit'.

 So maybe I am not permitted to edit blog posts made by others?

 I wonder if that means there is a configuration setting somewhere, that
 dictates whether users can edit other users' blog posts.

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

Re: [tor-bugs] #14828 [Core Tor/Tor]: Multiple hidden services can share a pk_digest/service_id.

[Tor Bug Tracker & Wiki]

#14828: Multiple hidden services can share a pk_digest/service_id.
--+--
 Reporter:  yawning   |  Owner:  twim
 Type:  defect| Status:  needs_revision
 Priority:  Very Low  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7
 Severity:  Minor | Resolution:
 Keywords:  easy, tor-hs  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

 * sponsor:  SponsorR-can =>


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22390 [Webpages/Blog]: How do I edit an existing blog post?

[Tor Bug Tracker & Wiki]

#22390: How do I edit an existing blog post?
---+
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #22013
   Points: |   Reviewer:
  Sponsor: |
---+
 I've logged in, and I'm at
 https://blog.torproject.org/blog/we-are-upgrading-our-blog
 How do I edit this blog post?

 There is a button on the top right that says "Edit", but when I click it,
 nothing happens (maybe it works in Chrome but not in Firefox? Or maybe it
 just doesn't work?). In any case, that same button is there when I'm on
 the front page (https://blog.torproject.org/) so I'm guessing it is not
 actually the way to edit a blog post.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22389 [Webpages/Blog]: No way to save a draft blog post without publishing it?

[Tor Bug Tracker & Wiki]

#22389: No way to save a draft blog post without publishing it?
---+
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Low|  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #22013
   Points: |   Reviewer:
  Sponsor: |
---+
 https://blog.torproject.org/node/add/article
 doesn't have any options for selecting "published status" or the like.

 In the past, we could draft a blog post, and pass the URL around to other
 people who had blog accounts, and they could edit it, without needing to
 publish it to the frontpage.

 That seems like a useful feature to resurrect.

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

Re: [tor-bugs] #22343 [Applications/Tor Browser]: Save as... in the context menu results in using the catch-all circuit

[Tor Bug Tracker & Wiki]

#22343: Save as... in the context menu results in using the catch-all circuit
-+-
 Reporter:  gk   |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-linkability, ff52-esr,   |  Actual Points:
  tbb-7.0-must, TorBrowserTeam201705 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * cc: brade, mcs (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] #22388 [Webpages/Blog]: Put a favicon in place

[Tor Bug Tracker & Wiki]

#22388: Put a favicon in place
---+
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Low|  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #22013
   Points: |   Reviewer:
  Sponsor: |
---+
 The blog tab in my browser now has the little angry blue drupal guy as its
 icon.

 That's fine for now, so no rush, but we can do better! :)

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

Re: [tor-bugs] #22019 [Webpages/Blog]: Integrate a Captcha and Honeypot

[Tor Bug Tracker & Wiki]

#22019: Integrate a Captcha and Honeypot
---+
 Reporter:  hiro   |  Owner:  hiro
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID:  #22013 | Points:
 Reviewer: |Sponsor:
---+

Comment (by arma):

 What is the captcha that we integrated?

 I just tried adding an anonymous comment and it let me queue it right 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] #22019 [Webpages/Blog]: Integrate a Captcha and Honeypot

[Tor Bug Tracker & Wiki]

#22019: Integrate a Captcha and Honeypot
---+
 Reporter:  hiro   |  Owner:  hiro
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID:  #22013 | Points:
 Reviewer: |Sponsor:
---+
Changes (by arma):

 * component:  Webpages/Website => Webpages/Blog


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

Re: [tor-bugs] #22334 [Webpages/Blog]: Missing top-right links in blog

[Tor Bug Tracker & Wiki]

#22334: Missing top-right links in blog
---+--
 Reporter:  teor   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Low|  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22013 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by arma):

 * priority:  Medium => Low


Comment:

 Worthwhile to do, but not critical for getting things working. We might
 even leave this one for when we have a uniform style across websites. But
 it would be sad to leave it for a year if it takes a year to have that
 uniform style.

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

Re: [tor-bugs] #22335 [Webpages/Blog]: Please remove "The" from the blog title

[Tor Bug Tracker & Wiki]

#22335: Please remove "The" from the blog title
---+--
 Reporter:  teor   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Low|  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22013 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by arma):

 * priority:  Medium => Low


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

Re: [tor-bugs] #22383 [Webpages/Blog]: Upcoming events are not showing up

[Tor Bug Tracker & Wiki]

#22383: Upcoming events are not showing up
---+--
 Reporter:  anadahz|  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22013 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by arma):

 So we've lost all our previous events? Ok.

 1) Let's get the upcoming events into the new blog then. Let us know if we
 can help. (I think nobody has the upcoming events anymore, besides you,
 now that the old blog is gone?)

 2) As a low priority thing, can we export the previous events somehow, so
 our new press person or whoever can use them when doing
 historical/retrospective things like annual reports?

 Thanks!

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

Re: [tor-bugs] #22385 [Webpages/Blog]: Migrate new blog posts from old blog to new blog

[Tor Bug Tracker & Wiki]

#22385: Migrate new blog posts from old blog to new blog
---+--
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22013 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by arma):

 * priority:  Medium => High


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

Re: [tor-bugs] #22386 [Webpages/Blog]: Make the www.tpo script to pull blog rss files resume working

[Tor Bug Tracker & Wiki]

#22386: Make the www.tpo script to pull blog rss files resume working
---+--
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22013 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by arma):

 * priority:  Medium => High


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

Re: [tor-bugs] #16404 [Applications/Tor Browser]: Review WebGL2 spec for fingerprinting issues

[Tor Bug Tracker & Wiki]

#16404: Review WebGL2 spec for fingerprinting issues
-+-
 Reporter:  mikeperry|  Owner:  gk
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff52-esr, tbb-fingerprinting,|  Actual Points:
  TorBrowserTeam201705R, GeorgKoppen201705,  |
  tbb-7.0-must   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:  None
-+-
Changes (by gk):

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


Comment:

 Applied to `tor-browser-52.1.1esr-7.0-1`and `tor-browser-52.1.0esr-7.0-2`
 (commit b9bff8b465284d1ad0a95ca19e2318b4e200f63f and
 2931426f6f8f2541ca6e5b43c62a61ab8bc9eec4).

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

Re: [tor-bugs] #17928 [Core Tor/Tor]: Warnings in syslog for wrong permissions on hidden service dir are misleading

[Tor Bug Tracker & Wiki]

#17928: Warnings in syslog for wrong permissions on hidden service dir are
misleading
-+--
 Reporter:  throwaway232344  |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Very Low |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:  Tor: 0.2.7.5
 Severity:  Trivial  | Resolution:
 Keywords:  tor-hs   |  Actual Points:
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+--
Changes (by dgoulet):

 * sponsor:  SponsorR-can =>


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

Re: [tor-bugs] #22385 [Webpages/Blog]: Migrate new blog posts from old blog to new blog

[Tor Bug Tracker & Wiki]

#22385: Migrate new blog posts from old blog to new blog
---+--
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22013 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by arma):

 Replying to [comment:3 cypherpunks]:
 > Yes, these 2 posts, i.e. can users add comments to them and be sure they
 won't disappear?

 Feel free to try. They -- the blog posts -- are 404 right 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] #13828 [Core Tor/Tor]: Refactor rend_cache_store_v2_desc_as_dir and rend_cache_store_v2_desc_as_client to avoid duplicate code

[Tor Bug Tracker & Wiki]

#13828: Refactor rend_cache_store_v2_desc_as_dir and
rend_cache_store_v2_desc_as_client to avoid duplicate code
+--
 Reporter:  arma|  Owner:
 Type:  enhancement | Status:  new
 Priority:  Very Low|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, easy, refactor  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+--
Changes (by dgoulet):

 * keywords:  tor-hs, easy => tor-hs, easy, refactor
 * points:  small => 1
 * sponsor:  SponsorR-can =>


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

Re: [tor-bugs] #11148 [Core Tor/Tor]: add UPLOAD action to HS_DESC control event

[Tor Bug Tracker & Wiki]

#11148: add UPLOAD action to HS_DESC control event
--+--
 Reporter:  dave2008  |  Owner:
 Type:  enhancement   | Status:  closed
 Priority:  Very Low  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:  small
 Reviewer:|Sponsor:  SponsorR-can
--+--
Changes (by dgoulet):

 * status:  needs_revision => closed
 * resolution:   => fixed
 * severity:   => Normal


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

Re: [tor-bugs] #11147 [Core Tor/Tor]: spec: add UPLOAD action to HS_DESC control event

[Tor Bug Tracker & Wiki]

#11147: spec: add UPLOAD action to HS_DESC control event
--+--
 Reporter:  dave2008  |  Owner:
 Type:  enhancement   | Status:  closed
 Priority:  Very Low  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:  small
 Reviewer:|Sponsor:  SponsorR-can
--+--
Changes (by dgoulet):

 * status:  needs_revision => 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] #20289 [Core Tor/Tor]: HS_DESC event while waiting for upload

[Tor Bug Tracker & Wiki]

#20289: HS_DESC event while waiting for upload
-+--
 Reporter:  meejah   |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  tor-hs, tor-control  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by dgoulet):

 * keywords:  tor-hs => tor-hs, tor-control
 * sponsor:  SponsorR-can =>


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

Re: [tor-bugs] #18295 [Core Tor/Tor]: Make shared random rounds configurable in test networks

[Tor Bug Tracker & Wiki]

#18295: Make shared random rounds configurable in test networks
-+--
 Reporter:  teor |  Owner:  dgoulet
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-sr, tor-dirauth  |  Actual Points:
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+--
Changes (by dgoulet):

 * keywords:  tor-sr => tor-sr, tor-dirauth
 * status:  accepted => new
 * sponsor:  SponsorR-must =>


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

Re: [tor-bugs] #15557 [Core Tor/Tor]: Improve relaunch logic for failed rendezvous circuits

[Tor Bug Tracker & Wiki]

#15557: Improve relaunch logic for failed rendezvous circuits
-+-
 Reporter:  asn  |  Owner:
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-client, prop224  |  Actual Points:
Parent ID:  #17242   | Points:  3
 Reviewer:   |Sponsor:  SponsorR-can
-+-
Changes (by dgoulet):

 * keywords:  tor-hs => tor-hs, tor-client, prop224
 * points:  medium => 3
 * severity:   => Normal
 * parent:  #15463 => #17242


Comment:

 Very relevant to prop224 client implementation. Re-parenting.

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

Re: [tor-bugs] #22354 [Webpages/Blog]: Blog comment titles are redundant and can be left out?

[Tor Bug Tracker & Wiki]

#22354: Blog comment titles are redundant and can be left out?
---+
 Reporter:  arma   |  Owner:  hiro
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID:  #22013 | Points:
 Reviewer: |Sponsor:
---+
Changes (by arma):

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


Comment:

 Looks like titles are gone, both from comments and from the comment
 submission form.

 Sounds great to me! Thanks.

 I'm going to close this one -- please reopen if I'm mistaken and there is
 more to 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] #22385 [Webpages/Blog]: Migrate new blog posts from old blog to new blog

[Tor Bug Tracker & Wiki]

#22385: Migrate new blog posts from old blog to new blog
---+--
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22013 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 Replying to [comment:2 arma]:
 > Replying to [comment:1 cypherpunks]:
 > > Are they ready for commenting?
 >
 > "they"?
 Yes, these 2 posts, i.e. can users add comments to them and be sure they
 won't disappear?

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

Re: [tor-bugs] #13494 [Core Tor/Tor]: Regression test about Hidden Service time synchronization

[Tor Bug Tracker & Wiki]

#13494: Regression test about Hidden Service time synchronization
---+--
 Reporter:  asn|  Owner:
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:  Tor: 0.2.7
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, tests  |  Actual Points:
Parent ID: | Points:  6
 Reviewer: |Sponsor:
---+--
Changes (by dgoulet):

 * points:  medium/large => 6
 * sponsor:  SponsorR SponsorS =>


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

Re: [tor-bugs] #13484 [Core Tor/Tor]: Do we have edge cases with rend_consider_descriptor_republication()? Can we refactor it to be cleaner?

[Tor Bug Tracker & Wiki]

#13484: Do we have edge cases with rend_consider_descriptor_republication()? 
Can we
refactor it to be cleaner?
-+--
 Reporter:  arma |  Owner:
 Type:  task | Status:  new
 Priority:  Low  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:  SponsorR-can
-+--
Changes (by dgoulet):

 * keywords:  tor-hs => tor-hs, prop224
 * points:  small/medium => 3


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

Re: [tor-bugs] #22018 [Webpages/Blog]: Prevent users from being individually tracked in Drupal’s logs.

[Tor Bug Tracker & Wiki]

#22018: Prevent users from being individually tracked in Drupal’s logs.
---+
 Reporter:  hiro   |  Owner:  hiro
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID:  #22013 | Points:
 Reviewer: |Sponsor:
---+

Comment (by arma):

 What did we do to fix this one?

 In particular, are we running a sane log version on the pantheon side,
 like the one we do on other Tor and Debian servers?
 https://anonscm.debian.org/cgit/mirror/dsa-
 puppet.git/tree/modules/apache2/files/logformat-privacy

 If not, we should make it clear what we did. :)

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

Re: [tor-bugs] #20371 [Core Tor/Tor]: Lower HSDir query backoff delay

[Tor Bug Tracker & Wiki]

#20371: Lower HSDir query backoff delay
---+--
 Reporter:  twim   |  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, research, prop224  |  Actual Points:
Parent ID:  #17242 | Points:
 Reviewer: |Sponsor:  SponsorR-can
---+--
Changes (by dgoulet):

 * keywords:  tor-hs, research => tor-hs, research, prop224
 * parent:   => #17242


Comment:

 Must be considered in client implementation of prop224.

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

Re: [tor-bugs] #20332 [Core Tor/Tor]: Duplicate rendezvous cookie in ESTABLISH_RENDEZVOUS

[Tor Bug Tracker & Wiki]

#20332: Duplicate rendezvous cookie in ESTABLISH_RENDEZVOUS
--+--
 Reporter:  asn   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

 * points:  ? =>
 * sponsor:  SponsorR-can =>


Comment:

 As stated before, this can happen with a buggy tor client implementation
 so maybe the move is to change this log statement to protocol warning?...

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

Re: [tor-bugs] #20082 [Core Tor/Tor]: Lower initial descriptor upload delay for hidden services

[Tor Bug Tracker & Wiki]

#20082: Lower initial descriptor upload delay for hidden services
--+--
 Reporter:  twim  |  Owner:  twim
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, research  |  Actual Points:
Parent ID:| Points:
 Reviewer:  teor  |Sponsor:
--+--
Changes (by dgoulet):

 * sponsor:  SponsorR-can =>


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

Re: [tor-bugs] #19522 [Core Tor/Tor]: HS intro circuit retry logic fails when network interface is down

[Tor Bug Tracker & Wiki]

#19522: HS intro circuit retry logic fails when network interface is down
--+--
 Reporter:  asn   |  Owner:
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:  #16387| Points:  1.5
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

 * sponsor:  SponsorR-can =>


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

Re: [tor-bugs] #22385 [Webpages/Blog]: Migrate new blog posts from old blog to new blog

[Tor Bug Tracker & Wiki]

#22385: Migrate new blog posts from old blog to new blog
---+--
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22013 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by arma):

 Replying to [comment:1 cypherpunks]:
 > Are they ready for commenting?

 "they"?

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

Re: [tor-bugs] #19204 [Core Tor/Tor]: Make rend_service_descriptor_t struct immutable

[Tor Bug Tracker & Wiki]

#19204: Make rend_service_descriptor_t struct immutable
--+--
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  SponsorR-can
--+--
Changes (by dgoulet):

 * status:  new => closed
 * keywords:   => tor-hs
 * resolution:   => fixed


Comment:

 prop224 does NOT use `rend_service_descriptor_t` so let's not poke the
 dragon 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] #22320 [Applications/Tor Browser]: Referrer not hidden when comming from a .onion address

[Tor Bug Tracker & Wiki]

#22320: Referrer not hidden when comming from a .onion address
-+-
 Reporter:  pege |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff52-esr, tbb-7.0-must,  |  Actual Points:
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Applied to `tor-browser-52.1.1esr-7.0-1` and `tor-browser-52.1.0esr-7.0-2`
 (commit 326e9aedfec184325ae95059d12e6b674bfa9013 and
 f59a7bc0288dcf5efaa71ebe8f591d7edea7b7b7).

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

Re: [tor-bugs] #19166 [Core Tor/Tor]: HS connections randomly fail

[Tor Bug Tracker & Wiki]

#19166: HS connections randomly fail
--+--
 Reporter:  TvdW  |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.6
 Severity:  Normal| Resolution:  user disappeared
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  SponsorR-can
--+--
Changes (by dgoulet):

 * status:  new => closed
 * resolution:   => user disappeared


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22387 [Webpages/Blog]: Make unapproved comments visually different from approved comments

[Tor Bug Tracker & Wiki]

#22387: Make unapproved comments visually different from approved comments
---+
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #22013
   Points: |   Reviewer:
  Sponsor: |
---+
 Right now when looking at a blog post, e.g.
 https://blog.torproject.org/blog/stem-release-15
 There are some comments that are approved, and some that are unapproved,
 but they all look just like comments.

 In the old blog, they were a darker color and had the word 'unapproved' or
 'unpublished' or something written over them.

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

Re: [tor-bugs] #19114 [Core Tor/Tor]: Rejecting INTRODUCE1 on non-OR or non-edge circuit

[Tor Bug Tracker & Wiki]

#19114: Rejecting INTRODUCE1 on non-OR or non-edge circuit
--+
 Reporter:  toralf|  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.2-alpha
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  SponsorR-can
--+
Changes (by dgoulet):

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


Comment:

 This warning is at protocol warning level since
 a4eb17ed89d4761146280490e838cf850bc81296 released in tor-0.3.0.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] #22385 [Webpages/Blog]: Migrate new blog posts from old blog to new blog

[Tor Bug Tracker & Wiki]

#22385: Migrate new blog posts from old blog to new blog
---+--
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22013 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 Are they ready for commenting?

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

Re: [tor-bugs] #19045 [Core Tor/Tor]: Keep trying to form a new shared random value during the next commit phase

[Tor Bug Tracker & Wiki]

#19045: Keep trying to form a new shared random value during the next commit 
phase
--+--
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sr|  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

 * keywords:  tor-hs, tor-sr => tor-sr
 * reviewer:  dgoulet =>
 * sponsor:  SponsorR-can =>


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

Re: [tor-bugs] #19022 [Core Tor/Tor]: Extract intro_nodes status tracking from rend_service_descriptor_t

[Tor Bug Tracker & Wiki]

#19022: Extract intro_nodes status tracking from rend_service_descriptor_t
+--
 Reporter:  arma|  Owner:
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  wontfix
 Keywords:  tor-hs, tor-client  |  Actual Points:
Parent ID:  #19204  | Points:
 Reviewer:  |Sponsor:  SponsorR-can
+--
Changes (by dgoulet):

 * keywords:   => tor-hs, tor-client
 * status:  new => closed
 * resolution:   => wontfix


Comment:

 I seriously do not want to touch the legacy HS subsystem too much. Rest
 assure, prop224 code behaves very differently with different objects for
 the state.

 Please re-open if you think we should really put time into that.

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

Re: [tor-bugs] #18620 [Core Tor/Tor]: HSFORGET command to clear cached client state for a HS

[Tor Bug Tracker & Wiki]

#18620: HSFORGET command to clear cached client state for a HS
-+--
 Reporter:  str4d|  Owner:  str4d
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:  Tor: 0.2.7.6
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-control  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:  asn, special |Sponsor:
-+--
Changes (by dgoulet):

 * keywords:  tor-hs, 029-accepted => tor-hs, tor-control
 * sponsor:  SponsorR-can =>


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

Re: [tor-bugs] #18564 [Core Tor/Tor]: Improve our client HS descriptor fetch logic

[Tor Bug Tracker & Wiki]

#18564: Improve our client HS descriptor fetch logic
+--
 Reporter:  dgoulet |  Owner:
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tor-hs, tor-client  |  Actual Points:
Parent ID:  | Points:  3
 Reviewer:  |Sponsor:  SponsorR-can
+--
Changes (by dgoulet):

 * status:  new => closed
 * keywords:  tor-hs => tor-hs, tor-client
 * points:  medium => 3
 * resolution:   => fixed


Comment:

 Not doing that.

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

Re: [tor-bugs] #18608 [Core Tor/Tor]: Limiting ADD_ONION TARGET access.

[Tor Bug Tracker & Wiki]

#18608: Limiting ADD_ONION TARGET access.
-+--
 Reporter:  cypherpunks  |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-control  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+--
Changes (by dgoulet):

 * points:  smally => 1
 * sponsor:  SponsorR-can =>


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

Re: [tor-bugs] #11045 [Core Tor/Stem]: Check consensus signatures

[Tor Bug Tracker & Wiki]

#11045: Check consensus signatures
---+-
 Reporter:  atagar |  Owner:  nickm
 Type:  enhancement| Status:  closed
 Priority:  High   |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords:  descriptor |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by atagar):

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


Comment:

 Thanks to teor we now have unit test coverage for this too! \o/

 https://gitweb.torproject.org/stem.git/commit/?id=68afdd6
 https://gitweb.torproject.org/stem.git/commit/?id=2f92235

 Finally resolving. :P

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

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

[Tor Bug Tracker & Wiki]

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

 * cc: dgoulet (removed)
 * keywords:  needs-proposal => tor-hs, tor-spec
 * sponsor:  SponsorR-must => SponsorR-can


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

Re: [tor-bugs] #18157 [Core Tor/Tor]: Which hidden services am I running?

[Tor Bug Tracker & Wiki]

#18157: Which hidden services am I running?
-+--
 Reporter:  cypherpunks  |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-control  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by dgoulet):

 * keywords:  tor-hs => tor-hs, tor-control
 * sponsor:  SponsorR-can =>


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22386 [Webpages/Blog]: Make the www.tpo script to pull blog rss files resume working

[Tor Bug Tracker & Wiki]

#22386: Make the www.tpo script to pull blog rss files resume working
---+
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #22013
   Points: |   Reviewer:
  Sponsor: |
---+
 See include/blog-recent.wmi in the webwml git.

 It gets included by en/index.wml in the webwml git.

 It gets built on jenkins, when jenkins builds our website:
 https://gitweb.torproject.org/project/jenkins/tools.git/tree/slaves/linux
 /website-build-blog-snippets
 In particular, by this script:
 https://gitweb.torproject.org/project/jenkins/tools.git/tree/slaves/linux
 /website-build-blog-snippets/make-recent-posts
 which looks like it loads this page from the blog:
 https://blog.torproject.org/blog/feed
 and that page seems to return 404 currently.

 So we should either find out where that blog feed page is now, and change
 the link, or make one and make it 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] #17520 [Core Tor/Tor]: Relax the rend cache failure cleanup timer

[Tor Bug Tracker & Wiki]

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

 * keywords:   => tor-hs, tor-client
 * points:  small/medium => 1
 * type:  defect => enhancement
 * parent:   => #17242


Comment:

 This is relevant to prop224 client implementation 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] #22384 [Internal Services/Tor Sysadmin Team]: Duplicate Blog component

[Tor Bug Tracker & Wiki]

#22384: Duplicate Blog component
-+-
 Reporter:  cypherpunks  |  Owner:  hiro
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

 * owner:  qbi => hiro
 * status:  new => assigned
 * component:  Internal Services/Service - trac => Internal Services/Tor
 Sysadmin Team


Comment:

 Blog and Wiki are not `Internal Services`.

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

Re: [tor-bugs] #17360 [Core Tor/Tor]: Hidden service option for the number of predicted circuits

[Tor Bug Tracker & Wiki]

#17360: Hidden service option for the number of predicted circuits
--+--
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

 * points:  1 => 0.1
 * sponsor:  SponsorR-can =>


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

Re: [tor-bugs] #17357 [Core Tor/Tor]: rend_service_relaunch_rendezvous() ignores rend_service_requires_uptime()

[Tor Bug Tracker & Wiki]

#17357: rend_service_relaunch_rendezvous() ignores 
rend_service_requires_uptime()
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

 * keywords:  tor-hs, thought-needed => tor-hs
 * points:  small/medium => 0.5
 * sponsor:  SponsorR-can =>


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

Re: [tor-bugs] #17254 [Core Tor/Tor]: Scalable HSes by splitting intro/rendezvous

[Tor Bug Tracker & Wiki]

#17254: Scalable HSes by splitting intro/rendezvous
--+--
 Reporter:  TvdW  |  Owner:  TvdW
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:  6
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

 * points:  medium => 6
 * sponsor:  SponsorR-can =>


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

Re: [tor-bugs] #15463 [Core Tor/Tor]: Tor deals poorly with a very large number of incoming connection requests.

[Tor Bug Tracker & Wiki]

#15463: Tor deals poorly with a very large number of incoming connection 
requests.
-+--
 Reporter:  alberto  |  Owner:  yawning
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:  Tor: 0.2.5.11
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, performance  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by dgoulet):

 * keywords:  tor-hs => tor-hs, performance
 * status:  assigned => new
 * severity:   => Normal
 * sponsor:  SponsorR-can =>


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

Re: [tor-bugs] #7534 [Core Tor/Stem]: AUTHDIR_NEWDESCS example

[Tor Bug Tracker & Wiki]

#7534: AUTHDIR_NEWDESCS example
---+--
 Reporter:  atagar |  Owner:  atagar
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords:  tor-spec, tor-dirauth  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by atagar):

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


Comment:

 Thanks to teor got some AUTHDIR_NEWDESCS test data. Unit tests added...

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

 Thanks Tim!

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

Re: [tor-bugs] #16646 [Core Tor/Tor]: Cannibalized intro point circuits are now 4 hops, instead of 3 (HS-side)

[Tor Bug Tracker & Wiki]

#16646: Cannibalized intro point circuits are now 4 hops, instead of 3 (HS-side)
---+---
 Reporter:  asn|  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:  Tor: 0.2.7
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, performance, research  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by dgoulet):

 * keywords:  tor-hs, performance => tor-hs, performance, research
 * points:  small =>
 * sponsor:  SponsorR-can =>


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

Re: [tor-bugs] #16558 [Core Tor/Tor]: Dir auths should vote about Invalid like they do about BadExit

[Tor Bug Tracker & Wiki]

#16558: Dir auths should vote about Invalid like they do about BadExit
--+--
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:  #16538| Points:  6
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

 * points:  large => 6
 * sponsor:  SponsorR-must =>


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22385 [Webpages/Blog]: Migrate new blog posts from old blog to new blog

[Tor Bug Tracker & Wiki]

#22385: Migrate new blog posts from old blog to new blog
---+
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #22013
   Points: |   Reviewer:
  Sponsor: |
---+
 https://blog.torproject.org/blog/state-internet-censorship-indonesia
 and
 https://blog.torproject.org/blog/tor-browser-70a4-released
 both got posted to the old blog but aren't on the new blog yet.

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

Re: [tor-bugs] #16538 [Core Tor/Tor]: Limit the impact of a malicious HSDir

[Tor Bug Tracker & Wiki]

#16538: Limit the impact of a malicious HSDir
-+--
 Reporter:  arma |  Owner:
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth, tor-hs  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  SponsorR-can
-+--
Changes (by dgoulet):

 * keywords:  tor-dirauth => tor-dirauth, tor-hs
 * sponsor:  SponsorR-must => SponsorR-can
 * severity:   => Normal


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

Re: [tor-bugs] #4152 [Core Tor/Tor]: Implement Bottom Up Randomization (Windows platform)

[Tor Bug Tracker & Wiki]

#4152: Implement Bottom Up Randomization (Windows platform)
-+-
 Reporter:  bastik   |  Owner:  tom
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay windows hardening aslr |  Actual Points:
  security   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:10 tom]:
 > Replying to [comment:9 cypherpunks]:
 > > The correct implementation has already been written in
 https://blog.didierstevens.com/2012/03/29/update-se_aslr-version-0-0-0-2/
 > > (Usually TBB Team makes hardening on Windows, but if you make it for
 Tor and TBB, it would be great. :)
 >
 >
 > My reading of https://blogs.technet.microsoft.com/srd/2013/12/11
 /software-defense-mitigating-common-exploitation-techniques/ is that this
 technique is used by default in Windows 8+ if you turn on ASLR. So adding
 the code manually would improve the situation on Windows 7; but would
 probably just eat memory (although this may not be a real problem) on
 anything above that.
 As you like this doc, please, think about Force ASLR for TBB. But your
 worries about the code may be applied to old implementations only (Firefox
 uses that pseudo-ASLR in its pseudo-sandbox from pseudo-google
 https://dxr.mozilla.org/mozilla-
 
central/source/security/sandbox/chromium/sandbox/win/src/process_mitigations.cc#302).
 See the researches of Didier Stevens in articles, subsequent to one in the
 description. Version in comment:9 includes all his findings. EMET SHIM DLL
 also uses something similar with no problems.

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

Re: [tor-bugs] #16537 [Core Tor/Tor]: Allow onion services to publish voluntary usage stats

[Tor Bug Tracker & Wiki]

#16537: Allow onion services to publish voluntary usage stats
+--
 Reporter:  arma|  Owner:
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, statistics  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by dgoulet):

 * keywords:  tor-hs => tor-hs, statistics
 * sponsor:  SponsorR-can =>
 * severity:   => Normal


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