Re: [tor-bugs] #20928 [Community/Outreach]: Document our privacy-preserving webserver log setup for the world

[Tor Bug Tracker & Wiki]

#20928: Document our privacy-preserving webserver log setup for the world
+--
 Reporter:  arma|  Owner:  mrphs, ailanthus
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Community/Outreach  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by weasel):

 https://anonscm.debian.org/cgit/mirror/dsa-
 puppet.git/tree/modules/apache2/files/logformat-privacy

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20928 [Community/Outreach]: Document our privacy-preserving webserver log setup for the world

[Tor Bug Tracker & Wiki]

#20928: Document our privacy-preserving webserver log setup for the world
+--
 Reporter:  arma|  Owner:  mrphs, ailanthus
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Community/Outreach  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+--
 We use a novel log format for our webservers, which makes sure we don't
 collect the IP addresses of our visitors, and doesn't record the precise
 timestamp of the visits, yet still produces a format compatible with
 various log parsing tools.

 Everybody in the world should be doing this.

 We should document what we do and how and why, and tell the world so
 everybody else can do it too.

 Apparently Debian uses the same approach we do, so we have some adoption
 already, but much more remains!

 See
 http://seclists.org/nmap-announce/2004/16
 for some of our original motivation.

 And see
 http://lists.spi-inc.org/pipermail/spi-general/2016-December/003645.html
 for a summary of what we do currently.

 We should also invite/encourage people to find bugs in our set-up. It can
 always get better!

 And lastly, a blog post like this will be really useful to point to when
 we start doing analysis and graphs and metrics and stuff.

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

Re: [tor-bugs] #19960 [Core Tor/Tor]: Tor v0.2.9.1-alpha-dev (git-b3f43a22ab921ce6) - failing options/validate__transproxy test on NetBSD

[Tor Bug Tracker & Wiki]

#19960: Tor v0.2.9.1-alpha-dev (git-b3f43a22ab921ce6) - failing
options/validate__transproxy test on NetBSD
-+-
 Reporter:  yancm|  Owner:
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  self test regression netbsd  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 I've rebased my patch onto `bug19960_2` which addresses the points in
 comment: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] #20572 [Core Tor/Tor]: hs: Remove the private key material from hs_descriptor.h

[Tor Bug Tracker & Wiki]

#20572: hs: Remove the private key material from hs_descriptor.h
+--
 Reporter:  dgoulet |  Owner:  jryans
 Type:  defect  | Status:
|  needs_review
 Priority:  High|  Milestone:  Tor:
|  0.3.0.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, prop224, TorCoreTeam201612  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  |Sponsor:
|  SponsorR-must
+--
Changes (by jryans):

 * status:  assigned => needs_review


Comment:

 Branch available at https://github.com/jryans/tor/commits/hs-rm-private-
 key.

 `hs_desc_encode_descriptor` takes a new arg for the signing keypair so
 signing the descriptor can still be done (from tests, etc).  Not sure if
 it's okay to expose `ed25519_keypair_t` at this level, since it could be
 v3 specific, but perhaps that can be revised in follow up work.

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

[tor-bugs] #20927 [Applications/Tor Browser]: Upgrade Go to 1.7.4

[Tor Bug Tracker & Wiki]

#20927: Upgrade Go to 1.7.4
--+
 Reporter:  dcf   |  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:|
--+
 1.7.4 is a security release.

 https://golang.org/doc/devel/release.html#go1.7
 > go1.7.4 (released 2016/12/01) includes two security fixes. See the
 [https://github.com/golang/go/issues?q=milestone%3AGo1.7.4 Go 1.7.4
 milestone] on our issue tracker for details.

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

Re: [tor-bugs] #20840 [Applications/Tor Browser]: Rotate ports third time for default obfs4 bridges

[Tor Bug Tracker & Wiki]

#20840: Rotate ports third time for default obfs4 bridges
---+---
 Reporter:  lynntsai   |  Owner:  tbb-team
 Type:  task   | Status:
   |  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-bridges TorBrowserTeam201612R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by dcf):

 I reviewed the patch and the changed ports look right to me.

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

Re: [tor-bugs] #20840 [Applications/Tor Browser]: Rotate ports third time for default obfs4 bridges

[Tor Bug Tracker & Wiki]

#20840: Rotate ports third time for default obfs4 bridges
---+---
 Reporter:  lynntsai   |  Owner:  tbb-team
 Type:  task   | Status:
   |  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-bridges TorBrowserTeam201612R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by dcf):

 * status:  new => needs_review
 * keywords:   => tbb-bridges TorBrowserTeam201612R
 * component:  Applications => Applications/Tor Browser


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

Re: [tor-bugs] #20471 [Applications/Tor Browser]: Allow javascript: links from HTTPS first party pages

[Tor Bug Tracker & Wiki]

#20471: Allow javascript: links from HTTPS first party pages
-+-
 Reporter:  mikeperry|  Owner:  ma1
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability-website, tbb-  |  Actual Points:
  security-slider, TorBrowserTeam201612  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by ma1):

 * status:  new => assigned
 * owner:  tbb-team => ma1


Comment:

 Fixing this is in my TODO list for next release, thank you.

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

Re: [tor-bugs] #20348 [Metrics/Censorship analysis]: cyberoam assists bloody dictatorships.

[Tor Bug Tracker & Wiki]

#20348: cyberoam assists bloody dictatorships.
-+-
 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):

 Replying to [comment:128 cypherpunks]:
 > How to reliably confirm/deny vendor of censorship box? It can be
 fortinet, cyberoam, bluecoat, something yet.

 In the past we got a report that changing the meek TLS signature would get
 through a Cyberoam firewall. If you can reproduce it with the Kazakh
 firewall, it would be another small piece of evidence.

 To try it, edit the file Browser\TorBrowser\Data\Tor\torrc-defaults and
 change the line
 {{{
 ClientTransportPlugin meek exec TorBrowser\Tor\PluggableTransports
 \terminateprocess-buffer TorBrowser\Tor\PluggableTransports\meek-client-
 torbrowser -- TorBrowser\Tor\PluggableTransports\meek-client
 }}}
 to
 {{{
 ClientTransportPlugin meek exec TorBrowser\Tor\PluggableTransports
 \terminateprocess-buffer TorBrowser\Tor\PluggableTransports\meek-client
 }}}
 Those are the lines for Windows, but other platforms are similar. Just
 remove the `meek-client-torbrowser --` part.

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

Re: [tor-bugs] #20471 [Applications/Tor Browser]: Allow javascript: links from HTTPS first party pages

[Tor Bug Tracker & Wiki]

#20471: Allow javascript: links from HTTPS first party pages
-+-
 Reporter:  mikeperry|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability-website, tbb-  |  Actual Points:
  security-slider, TorBrowserTeam201612  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dcf):

 #18679 is a duplicate.

 I have occasionally worked around this problem by opening the inspector
 and manually changing
 {{{
 
 }}}
 to
 {{{
 
 }}}

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

Re: [tor-bugs] #18679 [Applications/Tor Browser]: javascript: hrefs don't run at medium-high security level, even on an HTTPS page

[Tor Bug Tracker & Wiki]

#18679: javascript: hrefs don't run at medium-high security level, even on an 
HTTPS
page
--+---
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by dcf):

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


Comment:

 Duplicate of #20471.

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

Re: [tor-bugs] #20923 [Internal Services/Service - lists]: Please create tor-employees mailing list

[Tor Bug Tracker & Wiki]

#20923: Please create tor-employees mailing list
---+-
 Reporter:  ewyatt |  Owner:  qbi
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by atagar):

 > Honestly, I can't imagine the list will get that much traffic.

 Great, glad to hear it.

 As discussed previously I haven't yet heard a decent use for such a list.
 Employee announcements presently go to tor-internal@. Even if they're not
 relevant to volunteers they still can be of interest to us as prospective
 future tor employees.

 The only thing an employee-only list does is ensure volunteers like me
 don't see... whatever it receives.

 That said, Shari's clearly set on this so guess we'll see how it goes. :)

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

Re: [tor-bugs] #20909 [Core Tor/Tor]: Tor 0.2.9.5-alpha still delivers outdated consensuses

[Tor Bug Tracker & Wiki]

#20909: Tor 0.2.9.5-alpha still delivers outdated consensuses
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.5-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, must-fix-|  Actual Points:
  before-029-stable  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Today's crop:

 0.2.9.6-rc
 {{{
 WARNING::Consensus download: 2.2s outdated consensus, expired 1794s ago
 from Quintex10 (199.249.223.71:80)
 B6320E44A230302C7BF9319E67597A9B87882241, max download time 15.0s.
 WARNING::Consensus download: 2.6s outdated consensus, expired 952s ago
 from torrelay1ph3xat (86.59.119.83:80)
 FC9AC8EA0160D88BCCFDE066940D7DD9FA45495B, max download time 15.0s.
 }}}

 The oldest I've seen so far was ~13 hours, none seems to have made it past
 24 hours yet.
 And it's pretty rare, about 2-3% of the relays I'm testing.

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

Re: [tor-bugs] #20923 [Internal Services/Service - lists]: Please create tor-employees mailing list

[Tor Bug Tracker & Wiki]

#20923: Please create tor-employees mailing list
---+-
 Reporter:  ewyatt |  Owner:  qbi
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by ewyatt):

 Replying to [comment:1 atagar]: Honestly, I can't imagine the list will
 get that much traffic. Also, communicating directly with the subset of
 people is not affected by whether we have a list, it just saves us time in
 manually entering each individual email address.

 The list will be used for announcements, not for substantive discussion.
 If a subject or discussion that would be better suited for the wider
 community arises within the email list, any person can (and knowing this
 group, definitely will) remove the conversation to that list.


 > Hi there. Just for the record I very strongly argued against this...
 >
 > {{{
 > An employee list will further differentiate employees from
 > non-employees by providing a communication channel exclusive to the
 > former. I don't like where I see this going but I've argued against it
 > the best I can. If you want to create the list over my objections then
 > please file a ticket and Jens will do so.
 > }}}
 >
 > This isn't to say we shouldn't do it. Shari has her heart set on this.
 But if it gets any substantial use or important correspondence this has
 the very real possibility of driving away volunteers. Me included.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20926 [Core Tor/Tor]: Avoid checking fallback candidates' DirPorts if they are down in OnionOO

[Tor Bug Tracker & Wiki]

#20926: Avoid checking fallback candidates' DirPorts if they are down in OnionOO
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.3-alpha
 Severity:  Normal|   Keywords:  fallback
Actual Points:|  Parent ID:  #18828
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+
 Exclude relays that have been down for 1 or more days from the fallback
 candidate list.

 When a relay operator has multiple relays, this prioritises relays that
 are up over relays that are down.

 I'll roll this into the #18828 branch.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20925 [- Select a component]: Tor should handle DNSSec RR types (DS, DNSKEY, DLV, etc.) as well as MX

[Tor Bug Tracker & Wiki]

#20925: Tor should handle DNSSec RR types (DS, DNSKEY, DLV, etc.) as well as MX
--+-
 Reporter:  paulj |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 I use a Tor client as a DNS resolver, to hide my DNS traffic generally.
 Even for traffic that does not go over Tor. With the intention that with
 services that multiplex/aggregate traffic for different domains to some
 service provider over a secure channel, that the target domain is not
 exposed to middle-men by DNS.

 The idea is to frustrate passive data-collection efforts (as is now a
 legal requirement on ISPs and mobile telcos in a number of countries) as
 much as possible, even when not using Tor for my other data-traffic.

 E.g., for email to domains hosted with some service provider (e.g. Google,
 or register.com, or whatever), and delivered by SMTP over SSL, or by MSA
 to a smart-host, if DNS is not obfuscated/onion-routed, then a middle man
 can tell who I am emailing even if the email itself is delivered securely
 over a channel that serves many many domains. As at least some countries
 in Europe now require ISPs to log all customer DNS queries, this matters.

 As another example, for HTTPS+SNI and for web sites that are hosted on
 large, generic content providers (e.g. CDNs), a 3rd party data-collector
 can not tell which website I am visiting. They only (passively) can tell I
 am connecting to a CDN. At least, this is true if the DNS is obfuscated
 via onion-routing.

 I have a caching, recursive nameserver (BIND) configured as my primary
 nameserver. I have Tor client acting as DNS server on port 5353. I have
 BIND configured to forward queries to the Tor DNS on 5353.

 Unfortunately:

 1. For the SMTP example, Tor does not implement MX, it seems. So when BIND
 gets "NotImp" from Tor, BIND fetches the MX directly itself - so at least
 my email gets delivered. However, it means the MX query is visible at my
 ISP and logged.

 2. For the HTTPS/SNI example, Tor does support A and  records, however
 it does not support DNSSec related records (DS, DNSKEY, DLV are some I've
 seen NotIMP returned for, NSEC,NSEC3,RRSIG, etc probably would also be
 required). My BIND server is configured to make DLV-lookaside DNSSec
 checks, and so the DNSSec/lookaside related DNS traffic still leaks the
 target domains to my ISP.

 It would be nice if Tor DNS client could support more types. This would
 allow Tor to be used to onion-route all DNS client traffic, even when
 other data-traffic is not being onion-routed. This would reduce the
 information-leak footprint of clients to their ISPs, which would reduce
 the browsing data logged on them - routinely in a number of European
 countries (esp. UK).

 This would therefore allow Tor to be used to enhance people's privacy,
 even when Tor was not being used for the data traffic itself.

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

Re: [tor-bugs] #20923 [Internal Services/Service - lists]: Please create tor-employees mailing list

[Tor Bug Tracker & Wiki]

#20923: Please create tor-employees mailing list
---+-
 Reporter:  ewyatt |  Owner:  qbi
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by atagar):

 Hi there. Just for the record I very strongly argued against this...

 {{{
 An employee list will further differentiate employees from
 non-employees by providing a communication channel exclusive to the
 former. I don't like where I see this going but I've argued against it
 the best I can. If you want to create the list over my objections then
 please file a ticket and Jens will do so.
 }}}

 This isn't to say we shouldn't do it. Shari has her heart set on this. But
 if it gets any substantial use or important correspondence this has the
 very real possibility of driving away volunteers. Me included.

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

Re: [tor-bugs] #20914 [Core Tor/Tor]: Consider switching to 3 fallbacks per operator

[Tor Bug Tracker & Wiki]

#20914: Consider switching to 3 fallbacks per operator
--+
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  fallback  |  Actual Points:
Parent ID:  #18828| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 And I want to remind operators that this time, we are taking 3 per
 operator.

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

Re: [tor-bugs] #20924 [Internal Services/Service - trac]: Add Core Tor Milestone 0.3.1.x

[Tor Bug Tracker & Wiki]

#20924: Add Core Tor Milestone 0.3.1.x
--+
 Reporter:  teor  |  Owner:  qbi
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  new => 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] #20021 [Core Tor/Tor]: Require ntor-onion-key in microdescriptors, descriptors

[Tor Bug Tracker & Wiki]

#20021: Require ntor-onion-key in microdescriptors, descriptors
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  .1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * milestone:  Tor: 0.3.0.x-final => Tor: 0.3.1.x-final


Comment:

 Looks good to me, leaving in needs-revision for the spec and unit tests.

 Putting in 0.3.1, because it is likely that all authorities will be on
 0.2.9 (and never downgrade) some time mid-2017. (Unless there is another
 bad bug where they all upgrade, or we coordinate an upgrade.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20924 [Internal Services/Service - trac]: Add Core Tor Milestone 0.3.1.x

[Tor Bug Tracker & Wiki]

#20924: Add Core Tor Milestone 0.3.1.x
--+-
 Reporter:  teor  |  Owner:  qbi
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 For the record, I added this milestone.

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

Re: [tor-bugs] #20862 [Core Tor/Tor]: Unittest fail on master: FAIL src/test/test_options.c:662: expected log to contain "Could not resolve local Address "

[Tor Bug Tracker & Wiki]

#20862: Unittest fail on master: FAIL src/test/test_options.c:662: expected log 
to
contain "Could not resolve local Address "
--+
 Reporter:  asn   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 The test data here is:
 {{{
   options_test_data_t *tdata = get_options_test_data(
  "AuthoritativeDirectory 1\n"
  "Address
 this.should.not_exist.example.org");
 }}}

 I guess we assumed that every decent DNS hijacker would decline to hijack
 an address with an underscrore in it.

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

Re: [tor-bugs] #20863 [Core Tor/Tor]: Unittest fail on master: FAIL src/test/test_controller.c:190: assert(!cfg)

[Tor Bug Tracker & Wiki]

#20863: Unittest fail on master: FAIL src/test/test_controller.c:190: 
assert(!cfg)
--+
 Reporter:  asn   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 The case it's actually testing is
 {{{
   cfg = rend_service_parse_port_config("100 1.2.3.4.5:9000",
" ", _msg);
   tt_assert(!cfg);
   tt_str_op(err_msg, OP_EQ, "Unparseable address in hidden service port "
 "configuration.");
   tor_free(err_msg);
 }}}

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

Re: [tor-bugs] #20021 [Core Tor/Tor]: Require ntor-onion-key in microdescriptors, descriptors

[Tor Bug Tracker & Wiki]

#20021: Require ntor-onion-key in microdescriptors, descriptors
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  .1
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 My `ticket20021` branch has the required change here, once we decide it's
 time to pull the trigger on this change.  It will need further changes to
 make the unit tests pass again, and corresponding changes in dir-spec.txt

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

Re: [tor-bugs] #20021 [Core Tor/Tor]: Require ntor-onion-key in microdescriptors, descriptors

[Tor Bug Tracker & Wiki]

#20021: Require ntor-onion-key in microdescriptors, descriptors
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  .1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #20620 [Core Tor/Tor]: Unit test purpose_needs_anonymity_returns_true_by_default possible bug

[Tor Bug Tracker & Wiki]

#20620: Unit test purpose_needs_anonymity_returns_true_by_default possible bug
--+
 Reporter:  s7r   |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.0-alpha-dev
 Severity:  Normal| Resolution:  fixed
 Keywords:  unit tests|  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Resolved in 1d45438ef03564b7af2f3a5b4b0e3ff7a9570a97

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

Re: [tor-bugs] #19960 [Core Tor/Tor]: Tor v0.2.9.1-alpha-dev (git-b3f43a22ab921ce6) - failing options/validate__transproxy test on NetBSD

[Tor Bug Tracker & Wiki]

#19960: Tor v0.2.9.1-alpha-dev (git-b3f43a22ab921ce6) - failing
options/validate__transproxy test on NetBSD
-+-
 Reporter:  yancm|  Owner:
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  self test regression netbsd  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  new => needs_review


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

Re: [tor-bugs] #19960 [Core Tor/Tor]: Tor v0.2.9.1-alpha-dev (git-b3f43a22ab921ce6) - failing options/validate__transproxy test on NetBSD

[Tor Bug Tracker & Wiki]

#19960: Tor v0.2.9.1-alpha-dev (git-b3f43a22ab921ce6) - failing
options/validate__transproxy test on NetBSD
-+-
 Reporter:  yancm|  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  self test regression netbsd  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 I think my branch `bug19960_2` is the fix here. I've merged it to master.
 If it makes the builders happy, it can go into 0.2.9 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] #20121 [Applications/Tor bundles/installation]: Create Seatbealt profile(s) for Tor Browser

[Tor Bug Tracker & Wiki]

#20121: Create Seatbealt profile(s) for Tor Browser
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor |Version:
  bundles/installation   |
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, TorBrowserTeam201612R  |  Actual Points:
Parent ID:  #19750   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-

Comment (by gk):

 Replying to [comment:13 arthuredelstein]:
 > Also, maybe we should get rid of the Applications shortcut, since we
 don't want people to do put TorBrowser.app there. Is it possible to put a
 Desktop shortcut there instead? Or we could just have no shortcut, and no
 arrow.

 That's a can of worms we had already open, see #12966 for something (more)
 promising?

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

Re: [tor-bugs] #20121 [Applications/Tor bundles/installation]: Create Seatbealt profile(s) for Tor Browser

[Tor Bug Tracker & Wiki]

#20121: Create Seatbealt profile(s) for Tor Browser
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor |Version:
  bundles/installation   |
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, TorBrowserTeam201612R  |  Actual Points:
Parent ID:  #19750   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-

Comment (by arthuredelstein):

 I tried it out now. Seems to be working very nicely!

 I agree with gk that the .dmg folder layout is confusing. Maybe we could
 deliver the TorBrowser.app inside the "Sandboxed Tor Browser" folder so
 the user doesn't have to place it there themselves? (The text in the
 README is a little ambiguous about where to put TorBrowser.app, so
 initially I incorrectly placed it as a sibling of "Sandboxed Tor Browser"
 instead of as a child, and that of course resulted in an error.)

 Also, maybe we should get rid of the Applications shortcut, since we don't
 want people to do put TorBrowser.app there. Is it possible to put a
 Desktop shortcut there instead? Or we could just have no shortcut, and no
 arrow.

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

Re: [tor-bugs] #20511 [Core Tor/Tor]: add a failsafe where if you're about to serve a consensus that you know is obsolete, don't do it

[Tor Bug Tracker & Wiki]

#20511: add a failsafe where if you're about to serve a consensus that you know 
is
obsolete, don't do it
---+---
 Reporter:  arma   |  Owner:
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.0.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.2.9.1-alpha
 Severity:  Normal | Resolution:
 Keywords:  029-proposed, review-group-13  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 The bug that serves stale consensuses is still happening in 0.2.9.5-alpha
 and later, see #20909.
 So we probably want this in 0.2.9.

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

Re: [tor-bugs] #20909 [Core Tor/Tor]: Tor 0.2.9.5-alpha still delivers outdated consensuses

[Tor Bug Tracker & Wiki]

#20909: Tor 0.2.9.5-alpha still delivers outdated consensuses
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.5-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, must-fix-|  Actual Points:
  before-029-stable  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Those relays have recovered since yesterday.
 That's good, but serving a stale consensus for ~12-24 hours is still a bad
 thing.

 Running a full check in #20501 will tell us the prevalence of this issue.

 Some of our 0.3.0 changes might fix this:
 * using microdesc consensuses by default (#6769).

 I suggest we bring this change forward to 029 as an extra precaution:
 * 404 when consensus is out of date (#20511)

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

Re: [tor-bugs] #6769 [Core Tor/Tor]: Relays (and bridges) don't use microdescriptors

[Tor Bug Tracker & Wiki]

#6769: Relays (and bridges) don't use microdescriptors
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:  tor-relay |  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+

Comment (by teor):

 Apparently, another issue that may be *resolved* by this change is that
 relays will try harder to update an out-of-date microdesc consensus, which
 is what we want. See #20909, although it is possible that other relays
 have stale full consensuses.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20923 [Internal Services/Service - lists]: Please create tor-employees mailing list

[Tor Bug Tracker & Wiki]

#20923: Please create tor-employees mailing list
---+-
 Reporter:  ewyatt |  Owner:  qbi
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 We would like a private employee mailing list, please. It should be named
 tor-employees. I would like to be the maintainer/administrator of the
 list.

 Purpose of the list is to have a quick way to email employees instead of
 manually entering their email addresses every time we need to tell them
 something about benefits, payroll, etc. Thank you.

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

Re: [tor-bugs] #18828 [Core Tor/Tor]: Regenerate fallback list for 0.2.9

[Tor Bug Tracker & Wiki]

#18828: Regenerate fallback list for 0.2.9
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorCoreTeam201612, 029-accepted  |  Actual Points:
Parent ID:  #20172   | Points:  3
 Reviewer:   |Sponsor:  SponsorU-
 |  can
-+-

Comment (by teor):

 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

[tor-bugs] #20922 [Core Tor/Tor]: Consider faster retry schedule for primary guards

[Tor Bug Tracker & Wiki]

#20922: Consider faster retry schedule for primary guards
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #20822
   Points:|   Reviewer:
  Sponsor:|
--+
 30 minutes may be too low. Should we aim for 10?

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

[tor-bugs] #20921 [Core Tor/Tor]: Refactor global_origin_circuit_list code into separate functions.

[Tor Bug Tracker & Wiki]

#20921: Refactor global_origin_circuit_list code into separate functions.
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #20822
   Points:|   Reviewer:
  Sponsor:|
--+


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

Re: [tor-bugs] #20920 [Core Tor/Tor]: Lower MAX_SAMPLE_THRESHOLD by a lot

[Tor Bug Tracker & Wiki]

#20920: Lower MAX_SAMPLE_THRESHOLD by a lot
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #19877| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


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

[tor-bugs] #20920 [Core Tor/Tor]: Lower MAX_SAMPLE_THRESHOLD by a lot

[Tor Bug Tracker & Wiki]

#20920: Lower MAX_SAMPLE_THRESHOLD by a lot
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #19877
   Points:|   Reviewer:
  Sponsor:|
--+
 the current value of 0.3.0 in my prop271_030_v1 branch is ridiculously
 large.

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

Re: [tor-bugs] #19877 [Core Tor/Tor]: Implement new guard selection algorithm of prop 271

[Tor Bug Tracker & Wiki]

#19877: Implement new guard selection algorithm of prop 271
-+-
 Reporter:  andrea   |  Owner:  nickm
 Type:  task | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  isaremoved, nickwants029, tor-   |  Actual Points:
  guards-revamp, TorCoreTeam201611, review-  |
  group-13, actual-review-points=2   |
Parent ID:   | Points:
 Reviewer:  chelseakomlo, asn|Sponsor:
 |  SponsorU-must
-+-

Comment (by nickm):

 Replying to [comment:17 chelseakomlo]:
 > Hey Nick,
 >
 > Here are some general thoughts, feel free to take/leave what is useful.
 I added notes to the gitlab review as well.
 >
 > - Naming conventions are a bit confusing, as we use entrynodes,
 entryguards, and guards. If this naming signifies pre and post prop271,
 maybe we can add in legacy namespacing to make it more clear (see below).
 Also, the bridge-specific module looks really great- if there is guard-
 specific code that is distinct from entrynodes, maybe this belongs in a
 separate guard module.
 >
 > - Making a clear distinction between pre and post prop271 code would
 definitely make reviewing easier, as well as eventually migrating away
 from legacy code... I liked asn's recommendation of namespacing, we could
 also move legacy code to it's own module, etc.

 I've tried adding #ifdefs around the old code, in
 472a621ccc8a90bf90d8394210519974ad235848.

 For namespacing, I think everything should wind up in one entryguards_*
 namespace once the legacy things are removed, and the rest of the code is
 cleaned up.  The guards_* functions are there as generic frontends to the
 old and new code.

 > - Some functions are quite large, such as
 sampled_guards_update_from_consensus and
 entry_guards_upgrade_waiting_circuits. I see some todos about splitting
 these up, which is great.

 Agreed.

 > - Would it make sense to put parsing code into a parser.c?

 I'd like to extract it into something more general; for now it's pretty
 specific, though it could become more generally useful.  I've added it
 #20919.

 > - I didn't see a lot of tests here:
 https://gitlab.com/nickm_tor/tor/merge_requests/11 - is there another set
 of commits for these?

 I think we discussed this on IRC, and decided you needed to hit "expand"
 on gitlab, and then things got better.

 > - bridges.c doesn't have test coverage :(

 Right. At least, that code is no less covered than it was before I moved
 it. :/

 > - It looks like there are several remaining todos that need to be
 completed. Which of these should be completed as part of this patch? For
 example, in entrynodes.c, update_guard_selection_choice has a comment
 about needing to expire existing circuits (line 653).

 That's taken care of, so I removed the comment and updated the doxygen in
 6a6625c632248c. Resolving todos in in general is #20718 under #20822

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20919 [Core Tor/Tor]: Extract prop271 state-parsing code into a generic thing

[Tor Bug Tracker & Wiki]

#20919: Extract prop271 state-parsing code into a generic thing
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #20822
   Points:|   Reviewer:
  Sponsor:|
--+


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

Re: [tor-bugs] #19877 [Core Tor/Tor]: Implement new guard selection algorithm of prop 271

[Tor Bug Tracker & Wiki]

#19877: Implement new guard selection algorithm of prop 271
-+-
 Reporter:  andrea   |  Owner:  nickm
 Type:  task | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  isaremoved, nickwants029, tor-   |  Actual Points:
  guards-revamp, TorCoreTeam201611, review-  |
  group-13, actual-review-points=2   |
Parent ID:   | Points:
 Reviewer:  chelseakomlo, asn|Sponsor:
 |  SponsorU-must
-+-

Comment (by nickm):

 Replying to [comment:15 asn]:
 > Hello,
 >
 > I did some initial testing and a first pass of manual code review.

 Thank you!

 > You can see the first testing results here:
 https://trac.torproject.org/projects/tor/wiki/doc/NewGuardAlgorithmTesting
 >
 > I also left a few comments on the gitlab review with things that should
 be discussed. Some of those comments might be follow-up material (#20822).

 Okay.  I'll look over all the comments on the gitlab pull request next.

 > Also, please check my `prop271_030_v1` branch for some misc fixes.

 I've merged that into my branch; thak you!

 > BTW, starting tomorrow and until Monday I will be travelling and will
 have reduced connectivity and time for review. I might manage to do a few
 stuff, but I will continue in full force starting next Tuesday. Next week
 I can do more testing, and also some refactoring, and perhaps add some
 unittests (e.g. for the flappiness feature).

 Thank you!

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

Re: [tor-bugs] #19960 [Core Tor/Tor]: Tor v0.2.9.1-alpha-dev (git-b3f43a22ab921ce6) - failing options/validate__transproxy test on NetBSD

[Tor Bug Tracker & Wiki]

#19960: Tor v0.2.9.1-alpha-dev (git-b3f43a22ab921ce6) - failing
options/validate__transproxy test on NetBSD
-+-
 Reporter:  yancm|  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  self test regression netbsd  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 In e7ade23f9723f55a504ebd8279cbadf0aca108c6 I increased the verborsity of
 the output of the test, and now on the buildbot I see:
 {{{
   FAIL src/test/test_options.c:1089: Expected NULL but got 'ipfw is a
 FreeBSD-specificand OS X/Darwin-specific feature.'
 }}}

 a) "specificand" is a typo.

 b) Does netbsd support ipfw or not?  We imply "yes" in test_options.c, but
 "no" in our definition of KERNEL_MAY_SUPPORT_IPFW.  Which of these is
 correct?

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

Re: [tor-bugs] #15056 [Core Tor/Tor]: Support ed25519 identities for circuit extension

[Tor Bug Tracker & Wiki]

#15056: Support ed25519 identities for circuit extension
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, ed25519, prop-220,|  Actual Points:
  027-triaged-1-in, 028-triaged, |
  201511-deferred, tor-crypto-identity, tor- |
  ed25519-proto, TorCoreTeam201609, nickm-   |
  deferred-20161005, review-group-13 |
Parent ID:  #15054   | Points:  parent
 Reviewer:  dgoulet  |Sponsor:
 |  SponsorU-must
-+-

Comment (by nickm):

 Okay, I think I've been over it all again, and added a little more fixing.
 How do you feel about it 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] #20918 [Core Tor/Tor]: Switch onion.c to use TRUNNEL_OPAQUE

[Tor Bug Tracker & Wiki]

#20918: Switch onion.c to use TRUNNEL_OPAQUE
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #15056| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 This will need us to bump to trunnel 1.5.1

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20918 [Core Tor/Tor]: Switch onion.c to use TRUNNEL_OPAQUE

[Tor Bug Tracker & Wiki]

#20918: Switch onion.c to use TRUNNEL_OPAQUE
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #15056
   Points:|   Reviewer:
  Sponsor:|
--+
 The TRUNNEL_OPAQUE macro stops trunnel from exposing object internals in
 its headers; we should use that in onion.c.  (And possibly elsewhere.)
 Noted by dgoulet during code review.

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

Re: [tor-bugs] #20918 [Core Tor/Tor]: Switch onion.c to use TRUNNEL_OPAQUE

[Tor Bug Tracker & Wiki]

#20918: Switch onion.c to use TRUNNEL_OPAQUE
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #15056| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #20572 [Core Tor/Tor]: hs: Remove the private key material from hs_descriptor.h

[Tor Bug Tracker & Wiki]

#20572: hs: Remove the private key material from hs_descriptor.h
+--
 Reporter:  dgoulet |  Owner:  jryans
 Type:  defect  | Status:  assigned
 Priority:  High|  Milestone:  Tor:
|  0.3.0.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, prop224, TorCoreTeam201612  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  |Sponsor:
|  SponsorR-must
+--
Changes (by jryans):

 * owner:   => jryans
 * status:  new => assigned


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

Re: [tor-bugs] #20830 [Core Tor/Tor]: Remove legacy guard algorithm code

[Tor Bug Tracker & Wiki]

#20830: Remove legacy guard algorithm code
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-guard |  Actual Points:
Parent ID:  #20822| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 On my prop271_030_v1 branch, in commit
 472a621ccc8a90bf90d8394210519974ad235848, I've wrapped all the legacy code
 in #ifdefs.

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

Re: [tor-bugs] #20546 [Metrics/CollecTor]: implement CleanUtils

[Tor Bug Tracker & Wiki]

#20546: implement CleanUtils
---+---
 Reporter:  iwakeh |  Owner:  aegis2501
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-help   |  Actual Points:
Parent ID:  #20518 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by aegis2501):

 * status:  new => assigned
 * owner:   => aegis2501


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

Re: [tor-bugs] #20886 [Core Tor/DocTor]: Track expiring approved-routers.conf entries from 2006 to 2015

[Tor Bug Tracker & Wiki]

#20886: Track expiring approved-routers.conf entries from 2006 to 2015
-+-
 Reporter:  dgoulet  |  Owner:  atagar
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Core Tor/DocTor  |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by atagar):

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


Comment:

 Merged, thanks David! Feel free to reopen if you need anything 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] #19821 [Core Tor/Tor]: --expensive-hardening makes configure check for curve25519-donna-c64 to fail

[Tor Bug Tracker & Wiki]

#19821: --expensive-hardening makes configure check for curve25519-donna-c64 to
fail
--+
 Reporter:  yurivict271   |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.6
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 cool; 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] #19821 [Core Tor/Tor]: --expensive-hardening makes configure check for curve25519-donna-c64 to fail

[Tor Bug Tracker & Wiki]

#19821: --expensive-hardening makes configure check for curve25519-donna-c64 to
fail
--+
 Reporter:  yurivict271   |  Owner:
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.6
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by yurivict271):

 Now it works fine on FreeBSD 11 with 3.8.0.

 It must be clang-3.4.1 that caused a problem on FreeBSD 10.

 Please close this case then.

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

Re: [tor-bugs] #20875 [Core Tor/Tor]: Non-fatal assertion !(delay == INT_MAX) failed in next_random_exponential_delay at src/or/directory.c:3792

[Tor Bug Tracker & Wiki]

#20875: Non-fatal assertion !(delay == INT_MAX) failed in
next_random_exponential_delay at src/or/directory.c:3792
--+
 Reporter:  arma  |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.5-alpha
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Changes above look good to me; applied as
 0815f96416676ace7cfdb5c29000d8cd6ee3459f

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

Re: [tor-bugs] #20546 [Metrics/CollecTor]: implement CleanUtils

[Tor Bug Tracker & Wiki]

#20546: implement CleanUtils
---+-
 Reporter:  iwakeh |  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-help   |  Actual Points:
Parent ID:  #20518 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Great!  Help is very much appreciated.

 There is a section
 
[https://trac.torproject.org/projects/tor/wiki/org/teams/MetricsTeam/Volunteers#Howtocontribute
 How to contribute] in our wiki.
 If you have any questions, just ask here.

 Please assign this ticket to your user name when you start working.

 Thanks a lot!

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

Re: [tor-bugs] #19974 [Core Tor/Tor]: Test failure for monotonic time on some machines

[Tor Bug Tracker & Wiki]

#19974: Test failure for monotonic time on some machines
--+
 Reporter:  cypherpunks   |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.2-alpha
 Severity:  Normal| Resolution:  fixed
 Keywords:  regression|  Actual Points:
Parent ID:| Points:  .1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 I think it means that the monotonic time implementation just takes longer
 than 10 us sometimes.  My commit in
 fce425e3ff0281de29f04ac46d8c395befee607d is an attempt to work around that
 in the tests.  Please reopen if it doesn't work.

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

Re: [tor-bugs] #20710 [Core Tor/Tor]: memory leak in sandbox_getaddrinfo()

[Tor Bug Tracker & Wiki]

#20710: memory leak in sandbox_getaddrinfo()
-+-
 Reporter:  arma |  Owner:
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.5.5-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  025-backport, 026-backport,  |  Actual Points:
  027-backport, 028-backport, review-group-13|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Merging to 0.2.9 and forward only, since this is a leak-at-exit.

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

Re: [tor-bugs] #20909 [Core Tor/Tor]: Tor 0.2.9.5-alpha still delivers outdated consensuses

[Tor Bug Tracker & Wiki]

#20909: Tor 0.2.9.5-alpha still delivers outdated consensuses
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.5-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, must-fix-|  Actual Points:
  before-029-stable  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * 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] #18828 [Core Tor/Tor]: Regenerate fallback list for 0.2.9

[Tor Bug Tracker & Wiki]

#18828: Regenerate fallback list for 0.2.9
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorCoreTeam201612, 029-accepted  |  Actual Points:
Parent ID:  #20172   | Points:  3
 Reviewer:   |Sponsor:  SponsorU-
 |  can
-+-

Comment (by nickm):

 Link not found?

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

Re: [tor-bugs] #19966 [Core Tor/Tor]: torproxy goes south with more than 1 connection attempt per second to a hidden service

[Tor Bug Tracker & Wiki]

#19966: torproxy goes south with more than 1 connection attempt per second to a
hidden service
-+-
 Reporter:  Alan |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.6
 Severity:  Major| Resolution:
 Keywords:  hidden service client 028-backport   |  Actual Points:
  029-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  hidden service client => hidden service client 028-backport
 029-backport
 * milestone:  Tor: 0.2.8.x-final => Tor: 0.3.0.x-final


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

Re: [tor-bugs] #18706 [Core Tor/Tor]: tor-0.2.8.2-alpha, undefined symbolo "signbit" when compiling for Solaris10

[Tor Bug Tracker & Wiki]

#18706: tor-0.2.8.2-alpha, undefined symbolo "signbit"  when compiling for
Solaris10
-+-
 Reporter:  RainerSchmidt|  Owner:
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.8.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  undefined symbolo signbit|  Actual Points:
  regression |
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  new => needs_information


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

Re: [tor-bugs] #19711 [Core Tor/Tor]: circuit_package_relay_cell(): Bug: outgoing relay cell sent from src/or/relay.c:701 has n_chan==NULL. Dropping. (on Tor 0.2.8.5-rc )

[Tor Bug Tracker & Wiki]

#19711: circuit_package_relay_cell(): Bug: outgoing relay cell sent from
src/or/relay.c:701 has n_chan==NULL. Dropping. (on Tor 0.2.8.5-rc )
---+---
 Reporter:  user100500 |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  028-backport 029-backport  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * keywords:   => 028-backport 029-backport
 * milestone:  Tor: 0.2.8.x-final => Tor: 0.3.0.x-final


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

Re: [tor-bugs] #19821 [Core Tor/Tor]: --expensive-hardening makes configure check for curve25519-donna-c64 to fail

[Tor Bug Tracker & Wiki]

#19821: --expensive-hardening makes configure check for curve25519-donna-c64 to
fail
--+
 Reporter:  yurivict271   |  Owner:
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.6
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  new => needs_information


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

Re: [tor-bugs] #20059 [Core Tor/Tor]: Bug: Duplicate call to circuit_mark_for_close

[Tor Bug Tracker & Wiki]

#20059: Bug: Duplicate call to circuit_mark_for_close
--+
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  new => needs_information


Comment:

 This also reminds me of #20203, which we fixed. Is this still happening?

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

Re: [tor-bugs] #19969 [Core Tor/Tor]: tor client does not immediately open new circuits after standby

[Tor Bug Tracker & Wiki]

#19969: tor client does not immediately open new circuits after standby
-+-
 Reporter:  weasel   |  Owner:
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.2.8.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.6
 Severity:  Normal   | Resolution:  fixed
 Keywords:  regression 029-backport  |  Actual Points:
  028-backport   |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  reopened => 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] #19969 [Core Tor/Tor]: tor client does not immediately open new circuits after standby

[Tor Bug Tracker & Wiki]

#19969: tor client does not immediately open new circuits after standby
-+-
 Reporter:  weasel   |  Owner:
 Type:  defect   | Status:
 |  reopened
 Priority:  High |  Milestone:  Tor:
 |  0.2.8.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.6
 Severity:  Normal   | Resolution:
 Keywords:  regression 029-backport  |  Actual Points:
  028-backport   |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Does Tor 0.2.8.10 fix this by backporting #19969 ?

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

Re: [tor-bugs] #19953 [Core Tor]: DataDirectoryGroupReadable does not take effect when relay enabled

[Tor Bug Tracker & Wiki]

#19953: DataDirectoryGroupReadable does not take effect when relay enabled
--+
 Reporter:  redfish   |  Owner:
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor  |Version:  Tor: 0.2.8.6
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:  Tor: 0.2.8.x-final => Tor: 0.3.0.x-final


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

Re: [tor-bugs] #20241 [Core Tor/Tor]: Fix compilation on osx sierra (10.12)

[Tor Bug Tracker & Wiki]

#20241: Fix compilation on osx sierra (10.12)
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  osx, TorCoreTeam201609,  |  Actual Points:  .1
  028-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  merge_ready => closed
 * resolution:   => fixed
 * milestone:  Tor: 0.2.8.x-final => Tor: 0.2.9.x-final


Comment:

 This change caused some other follow-up issues (#20235) that we had to fix
 in 0.2.9, so rather than backporting this directly, we took a more brute-
 force approach in #20865 for 0.2.8.

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

Re: [tor-bugs] #18481 [Core Tor/Tor]: Allow the fallback directory schedules to be changed outside a test network

[Tor Bug Tracker & Wiki]

#18481: Allow the fallback directory schedules to be changed outside a test 
network
---+
 Reporter:  teor   |  Owner:  teor
 Type:  defect | Status:  assigned
 Priority:  Very Low   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.2.8.1-alpha
 Severity:  Trivial| Resolution:
 Keywords:  TorCoreTeam201606  |  Actual Points:
Parent ID: | Points:  small
 Reviewer: |Sponsor:
---+
Changes (by nickm):

 * milestone:  Tor: 0.2.8.x-final => Tor: 0.3.0.x-final


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

Re: [tor-bugs] #20546 [Metrics/CollecTor]: implement CleanUtils

[Tor Bug Tracker & Wiki]

#20546: implement CleanUtils
---+-
 Reporter:  iwakeh |  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-help   |  Actual Points:
Parent ID:  #20518 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by aegis2501):

 Hello, could I help with 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] #19877 [Core Tor/Tor]: Implement new guard selection algorithm of prop 271

[Tor Bug Tracker & Wiki]

#19877: Implement new guard selection algorithm of prop 271
-+-
 Reporter:  andrea   |  Owner:  nickm
 Type:  task | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  isaremoved, nickwants029, tor-   |  Actual Points:
  guards-revamp, TorCoreTeam201611, review-  |
  group-13, actual-review-points=2   |
Parent ID:   | Points:
 Reviewer:  chelseakomlo, asn|Sponsor:
 |  SponsorU-must
-+-

Comment (by chelseakomlo):

 Hey Nick,

 Here are some general thoughts, feel free to take/leave what is useful. I
 added notes to the gitlab review as well.

 - Naming conventions are a bit confusing, as we use entrynodes,
 entryguards, and guards. If this naming signifies pre and post prop271,
 maybe we can add in legacy namespacing to make it more clear (see below).
 Also, the bridge-specific module looks really great- if there is guard-
 specific code that is distinct from entrynodes, maybe this belongs in a
 separate guard module.

 - Making a clear distinction between pre and post prop271 code would
 definitely make reviewing easier, as well as eventually migrating away
 from legacy code... I liked asn's recommendation of namespacing, we could
 also move legacy code to it's own module, etc.


 - Some functions are quite large, such as
 sampled_guards_update_from_consensus and
 entry_guards_upgrade_waiting_circuits. I see some todos about splitting
 these up, which is great.

 - Would it make sense to put parsing code into a parser.c?

 - I didn't see a lot of tests here:
 https://gitlab.com/nickm_tor/tor/merge_requests/11 - is there another set
 of commits for these?

 - bridges.c doesn't have test coverage :(

 - It looks like there are several remaining todos that need to be
 completed. Which of these should be completed as part of this patch? For
 example, in entrynodes.c, update_guard_selection_choice has a comment
 about needing to expire existing circuits (line 653).

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

Re: [tor-bugs] #20909 [Core Tor/Tor]: Tor 0.2.9.5-alpha still delivers outdated consensuses

[Tor Bug Tracker & Wiki]

#20909: Tor 0.2.9.5-alpha still delivers outdated consensuses
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.5-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, must-fix-|  Actual Points:
  before-029-stable  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 I'm wondering if this is an intermittent failure or a semipermanent thing.
 If it's only intermittent, we don't need to add these to #20509.  But if
 it's going to be that way all the time, we need to to reconsider which
 versions #20509 hates.

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

Re: [tor-bugs] #20911 [Core Tor/DirAuth]: Why is 0.2.6.10 not a recommended version?

[Tor Bug Tracker & Wiki]

#20911: Why is 0.2.6.10 not a recommended version?
--+-
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by Sebastian):

 We don't know of a single distribution that ships an updated 0.2.6.x
 package. We added 0.2.7 back in because OpenSUSE is on it.

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

Re: [tor-bugs] #20509 [Core Tor/Tor]: Directory authorities should take away Guard flag from relays with #20499 bug

[Tor Bug Tracker & Wiki]

#20509: Directory authorities should take away Guard flag from relays with 
#20499
bug
-+-
 Reporter:  arma |  Owner:
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.9
 Severity:  Normal   | Resolution:
 Keywords:  028-backport, easy,  |  Actual Points:
  TorCoreTeam201612, review-group-13 |
Parent ID:   | Points:
 Reviewer:  teor, arma   |Sponsor:
-+-

Comment (by nickm):

 I'm a little uncomfortable with the 0.3.0.0-alpha-dev part, though I guess
 it's not going to hurt anything if we put 0.3.0.1-alpha out before too
 long.

 I'm fairly well worried about #20909 though.

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

Re: [tor-bugs] #20911 [Core Tor/DirAuth]: Why is 0.2.6.10 not a recommended version?

[Tor Bug Tracker & Wiki]

#20911: Why is 0.2.6.10 not a recommended version?
--+-
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by dgoulet):

 As far as I can tell, 026 has been removed because of Debian.

 Commit b7418c4692e99c854e94e99b23fc20e09bd35286 in dirauth-conf repository
 removes 026 entirely with the commit message:

 {{{
 Trim versions to what we support in Debian
 }}}

 The Tor LTS pad we worked on few weeks ago describes 026 like so:

 {{{
 = 0.2.6

  Released 24 March 2015
  Haven't updated since 12 July 2015.

   Debian: Not in debian.
   Ubuntu: It was in Wily Werewolf, which finished support in July 2016.
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20917 [Metrics/Consensus Health]: Add a microdesc consensus link

[Tor Bug Tracker & Wiki]

#20917: Add a microdesc consensus link
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Clients have been using the microdesc consensus by default for a while,
 and soon relays will also use it.

 Can we add a link for the microdesc consensus to the authority table at
 the top of consensus health?

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

Re: [tor-bugs] #20121 [Applications/Tor bundles/installation]: Create Seatbealt profile(s) for Tor Browser

[Tor Bug Tracker & Wiki]

#20121: Create Seatbealt profile(s) for Tor Browser
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor |Version:
  bundles/installation   |
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, TorBrowserTeam201612R  |  Actual Points:
Parent ID:  #19750   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-

Comment (by mcs):

 Replying to [comment:11 gk]:
 > Do we need modifications after a patch for #20761 lands (given that we
 want to have unix domain sockets disabled by default for the time being)?

 Because our start-browser-with-sandbox script enables use of Unix domain
 sockets via env vars, I don't think changing the default inside Tor
 Launcher will break anything. But once we have the patch for #20761 in
 hand, we will confirm via testing.

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

Re: [tor-bugs] #20916 [Core Tor/Tor]: Inconsistent IPv6 address between consensus and microdescriptor

[Tor Bug Tracker & Wiki]

#20916: Inconsistent IPv6 address between consensus and microdescriptor
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6, regression  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Here is the relevant microdesc consensus:
 https://collector.torproject.org/recent/relay-descriptors/microdescs
 /consensus-microdesc/2016-12-07-11-00-00-consensus-microdesc

 I really do think we should have put the 'a' line in the microdesc
 consensus instead of the microdescriptor. But it's too late for that now.

 '''A Diversion'''

 My branch bug20916 contains exactly the wrong solution to this problem: I
 made the microdescriptor change based on the authority's reachability for
 the IPv6 address.

 '''A Complex Solution'''

 One way to fix this issue is to:
 * define a flag UnreachableIPv6,
 * have authorities vote for it if AuthDirHasIPv6Connectivity is set and
 they are sure the relay is unreachable,
 * produce a consensus based on the majority view from authorities that
 know the UnreachableIPv6 flag, and then
 * have clients ignore the IPv6 address in the 'a' line if UnreachableIPv6
 is present.

 There are 3 possible states for authorities with
 AuthDirHasIPv6Connectivity set:
 * reachable: put the IPv6 address in the vote,
 * unknown: the authority hasn't been up for enough time to determine
 reachability: no address, no flag in the vote,
 * unreachable: put the UnreachableIPv6 in the vote.

 There is 1 possible state for authorities without
 AuthDirHasIPv6Connectivity set:
 * unknown: the authority doesn't have IPv6: no address, no flag.

 So the consensus rules become rather complicated.
 Let's try something simpler.

 '''A Simpler Solution'''

 Another way to fix this issue is to:
 * define a flag NoIPv6Consensus,
 * have authorities vote for IPv6 addresses as normal,
 * have authorities know the NoIPv6Consensus flag when they have been up
 for long enough to determine IPv6 reachability,
 * produce a consensus on NoIPv6Consensus based on a majority IPv6 address
 votes from authorities that know the NoIPv6Consensus flag, and then
 * have clients ignore the IPv6 address in the 'a' line if NoIPv6Consensus
 is present.

 There are 2 possible states for authorities with
 AuthDirHasIPv6Connectivity set:
 * reachable: know the NoIPv6Consensus flag in the vote,
 * unreachable: the authority hasn't been up for enough time to determine
 reachability: don't know the NoIPv6Consensus flag in the vote,
 and in any case, vote for IPv6 addresses as normal,

 There is 1 possible state for authorities without
 AuthDirHasIPv6Connectivity set:
 * unknown: the authority doesn't have IPv6: don't know the NoIPv6Consensus
 flag in the vote,
 and don't vote for any IPv6 addresses.

 The consensus for IPv6 votes becomes:
 * if a majority of authorities that know the NoIPv6Consensus flag agree on
 the IPv6 address, put the IPv6 address in the full consensus,
 * otherwise, put the NoIPv6Consensus flag in all consensus flavours, leave
 the IPv6 address out of the full consensus, and clients should ignore the
 IPv6 address in descriptors and microdescriptors.

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

Re: [tor-bugs] #20761 [Applications/Tor Launcher]: Tor Browser 6.5a4 is ignoring additional SocksPorts

[Tor Bug Tracker & Wiki]

#20761: Tor Browser 6.5a4 is ignoring additional SocksPorts
---+--
 Reporter:  gk |  Owner:  mcs
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201612   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by mcs):

 * owner:  brade => mcs
 * status:  needs_information => assigned


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

Re: [tor-bugs] #20147 [Applications/Tor Browser]: [PATCH] (re-)dzip.sh: various improvements

[Tor Bug Tracker & Wiki]

#20147: [PATCH] (re-)dzip.sh: various improvements
---+--
 Reporter:  rustybird  |  Owner:  tbb-team
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  tbb-gitian, TorBrowserTeam201612R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gk):

 * keywords:  tbb-gitian => tbb-gitian, TorBrowserTeam201612R
 * status:  needs_revision => closed
 * resolution:   => fixed


Comment:

 Ah, indeed, thanks for the links. I stand corrected. I applied your patch
 to `master` and `hardened-builds` (commits
 a38d827c12ce75d13e18f19fc8f5bac8aca28c55 and
 c74da40d46b10c7a757f8835f8177602ed77f8e4).

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

Re: [tor-bugs] #20147 [Applications/Tor Browser]: [PATCH] (re-)dzip.sh: various improvements

[Tor Bug Tracker & Wiki]

#20147: [PATCH] (re-)dzip.sh: various improvements
--+
 Reporter:  rustybird |  Owner:  tbb-team
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-gitian|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by rustybird):

 What what what, bashisms? :) If you're referring to `$(command)` or
 `${parameter:?}`, these are POSIX `/bin/sh`:


 
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_03
 
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02

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

Re: [tor-bugs] #20147 [Applications/Tor Browser]: [PATCH] (re-)dzip.sh: various improvements

[Tor Bug Tracker & Wiki]

#20147: [PATCH] (re-)dzip.sh: various improvements
--+
 Reporter:  rustybird |  Owner:  tbb-team
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-gitian|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

 * keywords:  tbb-gitian, TorBrowserTeam201612R => tbb-gitian
 * status:  needs_review => needs_revision


Comment:

 Sorry for the long time before I got to your patch. Overall it looks good
 to me. It seems you are using a bunch of bashisms. This is fine with me n
 general but please don't declare this as a script for the Bourne shell
 then (which we/you do with `#!/bin/sh`).

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

Re: [tor-bugs] #20809 [Applications/Tor Browser]: Use non-/html search engine URL for DuckDuckGo search plugins

[Tor Bug Tracker & Wiki]

#20809: Use non-/html search engine URL for DuckDuckGo search plugins
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-usability,   |  Actual Points:
  TorBrowserTeam201612R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Thanks. Applied to `tor-browser-45.5.1esr-6.5-1` and `tor-
 browser-45.5.1esr-6.0-1` (commits 2c396200c8c659c6e2c3ab8e40851aa984da49eb
 and 2c396200c8c659c6e2c3ab8e40851aa984da49eb).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20916 [Core Tor/Tor]: Inconsistent IPv6 address between consensus and microdescriptor

[Tor Bug Tracker & Wiki]

#20916: Inconsistent IPv6 address between consensus and microdescriptor
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  ipv6, regression
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+
 The relay wedostor is bound to an unreachable IPv6 address.
 https://atlas.torproject.org/#details/F70B7C5CD72D74C7F9F2DC84FA9D20D51BA13610
 (Atlas shows no IPv6 address.)

 It advertises the IPv6 address in its descriptor:
 http://46.28.109.231:9030/tor/server/authority

 The full consensus has no IPv6 address:
 http://collector.torproject.org/recent/relay-
 descriptors/consensuses/2016-12-07-11-00-00-consensus

 But the microdesc does have the IPv6 address:
 
http://46.28.109.231:9030/tor/micro/d/Z7YTOuC8gXcelqDlUhpsvaTPLp04QhyEXvOWo1inWj8

 And strangely, no client I have access to seems to download this
 microdescriptor. Maybe it registers as invalid somehow?

 A fix to this will require a new consensus method.

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

Re: [tor-bugs] #20909 [Core Tor/Tor]: Tor 0.2.9.5-alpha still delivers outdated consensuses

[Tor Bug Tracker & Wiki]

#20909: Tor 0.2.9.5-alpha still delivers outdated consensuses
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.5-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, must-fix-|  Actual Points:
  before-029-stable  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Here are my questions on this issue:

 '''Are we delaying connections the way we expect?'''

 I did some calculations for the expected exponential delay growth in
 #20534.
 We should check we are actually getting an exponential distribution in
 practice.
 We need some debug logging around the exponential backoff functions.

 '''Is the exponential backoff maximum delay too high?'''

 If the network goes down for a period of time N seconds long, and then
 comes back up again, the backoff delay D will grow until D >= N. In fact,
 if the exponent is E, the backoff will be of the order of `N^E`. Until it
 hits the maximum.

 There's no network-driven reason for using INT_MAX as the maximum. I think
 we should define a maximum for each download schedule, which is a tradeoff
 between:

 '''If my network connection goes down, how long should I stay down after
 it comes up again?'''

 The answer for relay consensuses could be 3 hours, otherwise they expire.
 (Or perhaps 24, the reasonably live consensus period.)

 Clients can afford to wait longer, as long as they come up when a request
 is made.
 (But hidden services should come up automatically after a certain amount
 of time.)
 Is 24 hours ok for a hidden service to be down?

 '''If the Tor network is down or overloaded, how long do I need to wait to
 avoid making it worse?'''

 This really depends on how many clients there are. (And how many relays.
 And how many fallback directories they try.)

 I think 3 hours is too short. But maybe it's ok to have it just for
 consensuses?
 Perhaps 24 hours is safe as a general limit?

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

Re: [tor-bugs] #20809 [Applications/Tor Browser]: Use non-/html search engine URL for DuckDuckGo search plugins

[Tor Bug Tracker & Wiki]

#20809: Use non-/html search engine URL for DuckDuckGo search plugins
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability,   |  Actual Points:
  TorBrowserTeam201612R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 The patch in `bug_20809` looks good to me.

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

Re: [tor-bugs] #20915 [Applications/Tor Browser]: Web developer network tab breaks first-party isolation in some cases

[Tor Bug Tracker & Wiki]

#20915: Web developer network tab breaks first-party isolation in some cases
---+--
 Reporter:  gk |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ff52-esr, tbb-linkability  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by gk):

 Might be fixed upstream already, thus let's double-check it during the
 ESR52 transition in case we don't get earlier to this bug.

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

Re: [tor-bugs] #20914 [Core Tor/Tor]: Consider switching to 3 fallbacks per operator

[Tor Bug Tracker & Wiki]

#20914: Consider switching to 3 fallbacks per operator
--+
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  fallback  |  Actual Points:
Parent ID:  #18828| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 I want to send out this draft list to tor-relays and CC all the operators.
 But I think I will wait until the weekend, collate all the replies,
 rebuild the list, and then send the email 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

[tor-bugs] #20915 [Applications/Tor Browser]: Web developer network tab breaks first-party isolation in some cases

[Tor Bug Tracker & Wiki]

#20915: Web developer network tab breaks first-party isolation in some cases
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  ff52-esr, tbb-
 Severity:  Normal   |  linkability
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 There are rare cases where the first-part isolation breaks if the Web
 developer Network tab is open. This got first reported on our blog:
 https://blog.torproject.org/blog/tor-browser-65a5-released#comment-224102

 Steps to reproduce (works both in the stable and the alpha series on Linux
 at least):

 1) Start a fresh Tor Browser and set the Torbutton log level to "3"
 2) Open the Network tab in the Web developer console (Ctrl + Shift + Q)
 3) Go to https://torproject.org
 4) Reload the page with the arrow in the URL bar

 Result:

 Torbutton INFO: tor SOCKS isolation catchall:
 https://www.torproject.org/images/onion-heart.png via
 --unknown--:de6a28fb71abeba4febbbdde61de345e

 It is actually only the request for the onion heart that is affected. And
 having the Network tab open is crucial for reproducing the bug.

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

Re: [tor-bugs] #18828 [Core Tor/Tor]: Regenerate fallback list for 0.2.9

[Tor Bug Tracker & Wiki]

#18828: Regenerate fallback list for 0.2.9
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorCoreTeam201612, 029-accepted  |  Actual Points:
Parent ID:  #20172   | Points:  3
 Reviewer:   |Sponsor:  SponsorU-
 |  can
-+-

Comment (by teor):

 Updated the branch: fallbacks-201612-v4
 ​https://github.com/teor2345/tor/tree/fallbacks-201612-v4

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

Re: [tor-bugs] #20898 [Internal Services/Service - trac]: Trac has overly restrictive filters for updating the wiki

[Tor Bug Tracker & Wiki]

#20898: Trac has overly restrictive filters for updating the wiki
--+-
 Reporter:  heartsucker   |  Owner:  qbi
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by teor):

 (Use a https link to the site? It's the future!)

 Can we use a stricter pattern for new accounts?
 I guess that doesn't really work either, because people create accounts to
 edit.

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

Re: [tor-bugs] #20471 [Applications/Tor Browser]: Allow javascript: links from HTTPS first party pages

[Tor Bug Tracker & Wiki]

#20471: Allow javascript: links from HTTPS first party pages
-+-
 Reporter:  mikeperry|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability-website, tbb-  |  Actual Points:
  security-slider, TorBrowserTeam201612  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-usability-website, tbb-security-slider => tbb-usability-
 website, tbb-security-slider, TorBrowserTeam201612


Comment:

 #20818 is probably related.

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

Re: [tor-bugs] #20221 [Applications/Tor Browser]: Hardened Tor Browser does not produce stack traces.

[Tor Bug Tracker & Wiki]

#20221: Hardened Tor Browser does not produce stack traces.
-+-
 Reporter:  mikeperry|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  GeorgKoppen201612,   |  Actual Points:
  TorBrowserTeam201612   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:   => GeorgKoppen201612, TorBrowserTeam201612


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

Re: [tor-bugs] #19741 [Applications/Tor Browser]: favicon in searchbar popup uses catchall circuit

[Tor Bug Tracker & Wiki]

#19741: favicon in searchbar popup uses catchall circuit
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-linkability, |  Actual Points:
  TorBrowserTeam201612, ff52-esr |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-linkability, TorBrowserTeam201612 => tbb-linkability,
 TorBrowserTeam201612, ff52-esr


Comment:

 Getting it on our ESR52 radar for double-checking as it might already be
 solved by the first-party isolation upstreaming.

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

Re: [tor-bugs] #20708 [Obfuscation/Pluggable transport]: Baidu Anti-TBB or TBB Trojanic upgrade

[Tor Bug Tracker & Wiki]

#20708: Baidu Anti-TBB or TBB Trojanic upgrade
-+---
 Reporter:  agentchaos   |  Owner:  asn
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Major| Resolution:  not a bug
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by gk):

 Replying to [comment:3 gk]:
 > I agree with dcf resolving this as not our bug.

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

Re: [tor-bugs] #20708 [Obfuscation/Pluggable transport]: Baidu Anti-TBB or TBB Trojanic upgrade

[Tor Bug Tracker & Wiki]

#20708: Baidu Anti-TBB or TBB Trojanic upgrade
-+---
 Reporter:  agentchaos   |  Owner:  asn
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Major| Resolution:  not a bug
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by gk):

 * status:  new => closed
 * resolution:   => not a bug


Comment:

 I agree with dcf resolving this as not out bug.

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

Re: [tor-bugs] #20121 [Applications/Tor bundles/installation]: Create Seatbealt profile(s) for Tor Browser

[Tor Bug Tracker & Wiki]

#20121: Create Seatbealt profile(s) for Tor Browser
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor |Version:
  bundles/installation   |
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, TorBrowserTeam201612R  |  Actual Points:
Parent ID:  #19750   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-

Comment (by gk):

 Do we need modifications after a patch for #20761 lands (given that we
 want to have unix domain sockets disabled by default for the time being)?

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

Re: [tor-bugs] #20809 [Applications/Tor Browser]: Use non-/html search engine URL for DuckDuckGo search plugins

[Tor Bug Tracker & Wiki]

#20809: Use non-/html search engine URL for DuckDuckGo search plugins
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability,   |  Actual Points:
  TorBrowserTeam201612R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * cc: boklm (added)


Comment:

 boklm: could you give that a quick look (it is a small patch we want to
 have for 6.0.8 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] #20352 [Applications/Tor Browser]: Integrate sandboxed Tor Browser into our gitian build system

[Tor Bug Tracker & Wiki]

#20352: Integrate sandboxed Tor Browser into our gitian build system
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-gitian, tbb-sandboxing,  |  Actual Points:
  TorBrowserTeam201612R, GeorgKoppen201612   |
Parent ID:  #19750   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:32 gk]:
 > I added the gitian-builder patches to tor-browser-builder-4 as commits
 afe8247f9fdf561b3e0d7701d2f49ef3bd5e6cb4 and
 dd26189595159bb8f50185a754dd4d0bc61b5787. I folded the changes you
 mentioned in comment:29 into my bug_20352_v4 and applied the result to
 tor-browser-bundle master as commit
 522cee6cb9c83be66cc2a6b5bbfefdb3c2bc3217. Thanks!

 I forgot to push another commit from bug_20352_v4 which I fixed on master
 (commit af596cb55dbcd300c989d02be7fffd1a16a7fb8a).

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