Re: [tor-bugs] #24110 [Core Tor/Tor]: document control protocol router status format surprises when using microdescriptors

[Tor Bug Tracker & Wiki]

#24110: document control protocol router status format surprises when using
microdescriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  bwauth-needs, tor-control, tor-  |  Actual Points:
  spec, 033-triage-20180320, |
  033-removed-20180320   |
Parent ID:  #24094   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-

Comment (by teor):

 There are other surprises in control port networkstatuses, regardless of
 whether microdescriptors are used:
 * there is no Unmeasured flag on w lines

 See https://github.com/pastly/simple-bw-scanner/issues/145

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by dcf):

 Replying to [comment:28 cypherpunks]:
 > [https://datatracker.ietf.org/doc/draft-ietf-tls-sni-
 encryption/?include_text=1 Make Meek Great Again?]

 Yes, there is some discussion about encrypted SNI and other related topics
 here:
   [https://groups.google.com/d/msg/traffic-obf/MagLb8FiMlA/c7nV7KrpAAAJ
 IETF draft: SNI Encryption in TLS Through Tunneling]
   [https://groups.google.com/d/msg/traffic-obf/bF61DndrA8I/tCGoXk2-DAAJ
 Secondary Cert Authentication.]
 Unfortunately I haven't thought about them very much or how they may be
 implemented. This is a good place for someone to get involved. There are
 more ideas than there are people to go after them.

 About Secondary Cert Authentication, Nick Sullivan of Cloudflare gave a
 (fairly non-technical) talk about it at USENIX Enigma 2018:
 https://www.youtube.com/watch?v=xZN0H3jzwys

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25999 [Core Tor/Stem]: Build an abstraction layer over different consensus flavours

[Tor Bug Tracker & Wiki]

#25999: Build an abstraction layer over different consensus flavours
---+
 Reporter:  teor   |  Owner:  atagar
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 In #25979, there was a bug in sbws because the ns consensus flavour has
 exit policy summaries in the consensus, but the microdescriptor consensus
 has exit policy summaries in microdescriptors.

 The code to abstract over these differences is reasonably simple, but it's
 hard for people to read the specs, find out all the details, and implement
 it correctly.

 For an example, see:
 https://trac.torproject.org/projects/tor/ticket/25979#comment:4

 It would be great if Stem included an abstraction layer over the consensus
 and descriptors, and just returned the attribute regardless of where it
 came from. (Maybe we could include this code in Tor instead, but it would
 be a major effort.)

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

Re: [tor-bugs] #12208 [Obfuscation/meek]: Make it possible to use an IP address as a front (no DNS request and no SNI)

[Tor Bug Tracker & Wiki]

#12208: Make it possible to use an IP address as a front (no DNS request and no
SNI)
--+--
 Reporter:  dcf   |  Owner:  dcf
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arlolra):

 * cc: arlolra (added)


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

Re: [tor-bugs] #25985 [Obfuscation/Snowflake]: Add AMP cache as another domain fronting option with Google

[Tor Bug Tracker & Wiki]

#25985: Add AMP cache as another domain fronting option with Google
---+
 Reporter:  twim   |  Owner:  (none)
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by dcf):

 The way I picture this working for snowflake is, we add a new route to the
 broker, like `/amp/client`. It will work exactly like the existing
 `/client` route (which is where clients POST their ICE offer)--with the
 only difference being that `/amp/client` will wrap the response in the
 additional AMP markup. The client side will have to know how to strip off
 the extra markup. It's probably not very much work.
 https://gitweb.torproject.org/pluggable-
 
transports/snowflake.git/tree/broker/broker.go?id=10ad59fc9d26900ded6456f50ea6adf4cb58be9d#n146

 Here's a diagram of how it works now:
 https://www.bamsoftware.com/papers/thesis/#fig:snowflake-rendezvous
 Imagine an AMP node between the client and broker. In Step 1, instead of
 domain fronting, the client will just do a normal request for
 !https://www.google.com/amp/snowflake.example.com or whatever. In Step 3,
 the broker will append the extra AMP markup. Everything else is the same.

 twim, can you give a brief guide on what is needed to set up AMP? I
 presume you at least need a Google account; is it something you set up in
 the Google Cloud Platform? Is there a fee? I've seen different kinds of
 AMP URLs, like
 
https://www.google.com/amp/s/amp.reddit.com/r/OutOfTheLoop/comments/56euau/whats_with_google_amp_quite_annoyingly_being_used/
   https://amp-reddit-com.cdn.ampproject.org/
   https://amp.reddit.com/
 Do you know what the difference between all these URL styles is? Are they
 basically interchangeable? The first one looks like the best, if we can
 use 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] #25985 [Obfuscation/Snowflake]: Add AMP cache as another domain fronting option with Google

[Tor Bug Tracker & Wiki]

#25985: Add AMP cache as another domain fronting option with Google
---+
 Reporter:  twim   |  Owner:  (none)
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Old description:

> This ticket is meant to track progress on adding AMP cache fronting into
> Snowflake broker and client.
>
> This is a followup  of
> https://trac.torproject.org/projects/tor/ticket/25804#comment:25:
>
> > It turns out that AppEngine is not the only option for domain fronting
> with Google.
> > Google also provides a service called ​AMP cache for ​AMP pages. What
> it basically does is proxying random pages on the Internet and making
> them load faster (e.g. on Google search results). It requires pages to
> comply with some format though and also strips invisible content, resizes
> images, etc.
> > Despite it is being served via different domain names (one per real
> domain) it is still hosted at Google infrastructure which can be fronted.

New description:

 This ticket is meant to track progress on adding AMP cache fronting into
 Snowflake broker and client.

 This is a followup  of
 https://trac.torproject.org/projects/tor/ticket/25804#comment:25:

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

--

Comment (by dcf):

 twim's library for tunneling through AMP:
 https://github.com/nogoegst/amper

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

Re: [tor-bugs] #25979 [Core Tor/Stem]: Stem, Tor LTS, broken exit policies, and maybe microdescriptor issues too

[Tor Bug Tracker & Wiki]

#25979: Stem, Tor LTS, broken exit policies, and maybe microdescriptor issues 
too
---+---
 Reporter:  pastly |  Owner:  atagar
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  not a bug
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * status:  reopened => closed
 * resolution:   => not a 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] #25979 [Core Tor/Stem]: Stem, Tor LTS, broken exit policies, and maybe microdescriptor issues too

[Tor Bug Tracker & Wiki]

#25979: Stem, Tor LTS, broken exit policies, and maybe microdescriptor issues 
too
---+--
 Reporter:  pastly |  Owner:  atagar
 Type:  defect | Status:  reopened
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by teor):

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


Comment:

 This appears to be a sbws bug.

 sbws assumes that the available consensus will contain exit policies.
 There are two consensus flavours:
 * the ns ("full") consensus contains exit policy port summaries
 * the microdesc consensus does not contain any port summaries

 The default consensus flavour is microdesc, and it does not contain exit
 policies, as documented here:
 
https://stem.torproject.org/api/descriptor/router_status_entry.html#stem.descriptor.router_status_entry.RouterStatusEntryMicroV3

 Here is a small tor-prompt test case that reproduces this issue:
 {{{
 >>> for r in controller.get_network_statuses():
 ...   if r.exit_policy is not None:
 ... print r
 ...
 >>>
 }}}
 No relay has an exit policy in the microdesc consensus.

 sbws should use the microdescriptors instead, because they contain the
 exit policy summaries.

 Here is some sample tor-prompt code that demonstrates this technique:
 {{{
 >>> for r in controller.get_network_statuses():
 ...   m = controller.get_microdescriptor(relay=r.fingerprint)
 ...   if m.exit_policy is not None:
 ... print m.exit_policy
 ... break
 ...
 reject 1-65535

 >>>
 }}}

 Since Stem doesn't have an abstraction layer over descriptor flavours, I
 suggest that sbws uses code that is compatible with either:

 {{{
 >>> for r in controller.get_network_statuses():
 ...   e = r.exit_policy if r.exit_policy else
 controller.get_microdescriptor(relay=r.fingerprint).exit_policy
 ...   if e is not None and e.can_exit_to(port=443):
 ... print e
 ... break
 ...
 accept
 
20-23,43,53,79-81,88,110,143,194,220,389,443,464,531,543-544,554,563,636,706,749,873,902-904,981,989-995,1194,1220,1293,1500,1533,1677,1723,1755,1863,2082-2083,2086-2087,2095-2096,2102-2104,3128,3389,3690,4321,4643,5050,5190,5222-5223,5228,5900,6660-6669,6679,6697,8000,8008,8074,8080,8087-8088,8332-8333,8443,,9418,-1,11371,12350,19294,19638,23456,33033,64738

 >>>
 }}}

 This code works with:
 {{{
 tor DataDirectory `mktemp -d`
 tor DataDirectory `mktemp -d` UseMicrodescriptors 0
 tor DataDirectory `mktemp -d` FetchUselessDescriptors 1
 }}}

 Which is good, because some bandwidth authorities will have set
 UseMicrodescriptors or FetchUselessDescriptors from torflow.

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

Re: [tor-bugs] #25998 [Core Tor/Tor]: FetchUselessDescriptors also stops Tor from going idle

[Tor Bug Tracker & Wiki]

#25998: FetchUselessDescriptors also stops Tor from going idle
---+
 Reporter:  teor   |  Owner:  teor
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  doc, fast-fix  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by teor):

 atagar asked that we also clarify the status of extrainfo descriptors, so
 I pushed another commit.

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

Re: [tor-bugs] #25998 [Core Tor/Tor]: FetchUselessDescriptors also stops Tor from going idle

[Tor Bug Tracker & Wiki]

#25998: FetchUselessDescriptors also stops Tor from going idle
---+
 Reporter:  teor   |  Owner:  teor
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  doc, fast-fix  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by teor):

 Oh, it's based on maint-0.3.3

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by starlight):

 Replying to [comment:18 robgjansen]:
 > . . . And it doesn't even measure residual capacity exactly, because of
 scheduling and fairness. For example, if my relay is operating at 100%
 link utilization and TorFlow tries to measure it, TorFlow isn't going to
 get 0 bandwidth and it isn't going to get 100% bandwidth; TorFlow is
 probably only going to get roughly 1/N of my bandwidth where N is the
 number of other active flows.

 Excellent point!  I had not considered this previously.

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

Re: [tor-bugs] #25998 [Core Tor/Tor]: FetchUselessDescriptors also stops Tor from going idle

[Tor Bug Tracker & Wiki]

#25998: FetchUselessDescriptors also stops Tor from going idle
---+
 Reporter:  teor   |  Owner:  teor
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  doc, fast-fix  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * status:  assigned => needs_review


Comment:

 Please see my branch bug25998 on https://githib.com/teor2345/tor.git

 I also discovered that UseMicrodescriptors auto and 1 are the same now, so
 I added a commit documenting that fact.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25998 [Core Tor/Tor]: FetchUselessDescriptors also stops Tor from going idle

[Tor Bug Tracker & Wiki]

#25998: FetchUselessDescriptors also stops Tor from going idle
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  doc, fast-fix
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+


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

[tor-bugs] #25997 [Core Tor/Tor]: Solve nondeterminism in testing of hs_get_responsible_hsdirs

[Tor Bug Tracker & Wiki]

#25997: Solve nondeterminism in testing of hs_get_responsible_hsdirs
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  tor-ci, tor-tests-coverage, tor-
 Severity:  Normal   |  tests-unit
Actual Points:   |  Parent ID:  #25908
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Only sometimes do our tests call the case of hs_get_responsible_hsdirs
 where it "wraps around":
 {{{
 /* Getting the length of the list if no member is greater than the key
 we
  * are looking for so start at the first element. */
 if (idx == smartlist_len(sorted_nodes)) {
   start = idx = 0;
 }
 }}}

 We should make this consistent.

 I plan to do this, but dgoulet or asn should steal it if they'd rather. :)

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

Re: [tor-bugs] #25908 [Core Tor/Tor]: make test suite coverage more deterministic

[Tor Bug Tracker & Wiki]

#25908: make test suite coverage more deterministic
-+-
 Reporter:  catalyst |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, tor-tests-coverage, tor- |  Actual Points:
  tests-unit |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor3-can
-+-
Changes (by nickm):

 * milestone:  Tor: 0.3.5.x-final => Tor: 0.3.4.x-final


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

Re: [tor-bugs] #25996 [Core Tor/Tor]: Produce consistent coverage from test_client_pick_intro()

[Tor Bug Tracker & Wiki]

#25996: Produce consistent coverage from test_client_pick_intro()
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, tor-tests-coverage, tor- |  Actual Points:
  tests-unit |
Parent ID:  #25908   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * cc: asn, dgoulet (added)
 * status:  assigned => needs_review


Comment:

 The branch is `ticket25996`; https://github.com/torproject/tor/pull/75 is
 a PR.

 Adding asn and dgoulet to the cc in their role as HS experts.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25996 [Core Tor/Tor]: Produce consistent coverage from test_client_pick_intro()

[Tor Bug Tracker & Wiki]

#25996: Produce consistent coverage from test_client_pick_intro()
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  tor-ci, tor-tests-coverage, tor-
 Severity:  Normal   |  tests-unit
Actual Points:   |  Parent ID:  #25908
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 This test can produce different coverage, depending on whether the non-
 excluded introduction point is chosen first or not.  To prevent this, we
 can just repeat the relevant portion of the test enough times.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by mikeperry):

 Ok I added the ratelimit log message and put this on maint-0.3.3 under
 mikeperry/bug25705_v3_033.

 I think an 0.3.3 backport makes sense, because it would be nice to have
 this type of checking in place for the HSLayerXNodes options. I am less
 sure it needs a further backport since we nacked the #25347-related
 change.

 In addition to what asn said, the other thing that makes Roger's second
 concern not happen is that this patch bails before incrementing
 n_circuit_failures. So these failures won't trigger the "woah go to sleep"
 property. I believe that is exactly what we want for these types of
 failures, though. They should not cause us to blame the guard or give up
 on the network. Neither are at fault.

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

Re: [tor-bugs] #25995 [Core Tor/Tor]: Use a deterministic PRNG in test_circuit_timeout() for predictable coverage.

[Tor Bug Tracker & Wiki]

#25995: Use a deterministic PRNG in test_circuit_timeout() for predictable
coverage.
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, tor-tests-coverage, tor- |  Actual Points:
  tests-unit |
Parent ID:  #25908   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * cc: mikeperry (added)
 * status:  assigned => needs_review


Comment:

 branch is `ticket25955`; PR is https://github.com/torproject/tor/pull/74

 Adding mikeperry to cc as the test's author, who may hate what I am
 proposing to do 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

[tor-bugs] #25995 [Core Tor/Tor]: Use a deterministic PRNG in test_circuit_timeout() for predictable coverage.

[Tor Bug Tracker & Wiki]

#25995: Use a deterministic PRNG in test_circuit_timeout() for predictable
coverage.
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  tor-ci, tor-tests-coverage, tor-
 Severity:  Normal   |  tests-unit
Actual Points:   |  Parent ID:  #25908
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 The test coverage from test_circuit_timeout() is nondeterministic, because
 the function deliberately creates random samples and passes them to the
 circuitstats module.

 I propose that for this function, we replace the RNG with a mocked
 replacement.

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

Re: [tor-bugs] #25994 [Core Tor/Tor]: test_channel: keep time constant when running channel/outbound_cell

[Tor Bug Tracker & Wiki]

#25994: test_channel: keep time constant when running channel/outbound_cell
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, tor-tests-coverage, tor- |  Actual Points:
  tests-unit |
Parent ID:  #25908   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * parent:  #25993 => #25908


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

Re: [tor-bugs] #25572 [Applications/Tor Browser]: Update NoScript to 5.1.8.5

[Tor Bug Tracker & Wiki]

#25572: Update NoScript to 5.1.8.5
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam201804  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:11 ma1]:
 > Replying to [comment:9 cypherpunks]:
 > > Replying to [comment:8 cypherpunks]:
 > > > Hint: let's disable updates.
 > > Of course, you don't care, but anyway 2:
 > > {{{
 > > addons.update-checker   WARNRequest failed:
 https://secure.informaction.com/download/classic/?v=5.1.8.5 -
 [Exception... "Certificate issuer is not built-in."  nsresult: "0x80004004
 (NS_ERROR_ABORT)"  location: "JS frame ::
 resource://gre/modules/CertUtils.jsm :: checkCert :: line 171"  data: no]
 > > }}}
 >
 > Could you please elaborate a bit?
 > secure.informaction.com has a Let's Encrypt certificate. Does it mean
 autoupdates are expected not to work for this kind of certificates? Is it
 a Tor Browser specific feature? (Auto-updates from secure.informaction.com
 seem to work fine in Firefox).
 Not the same cypherpunk but I did get that error when going to
 about:addons and clicking "Check for updates"

 {{{
 1525217115900   addons.update-checker   WARNonUpdateCheckComplete
 failed to determine manifest type
 1525217115900   addons.update-checker   WARNonUpdateCheckComplete
 failed to determine manifest type
 1525217119400   addons.update-checker   WARNRequest failed:
 https://secure.informaction.com/download/classic/?v=5.1.8.5 -
 [Exception... "Certificate issuer is not built-in."  nsresult: "0x80004004
 (NS_ERROR_ABORT)"  location: "JS frame ::
 resource://gre/modules/CertUtils.jsm :: checkCert :: line 171"  data: no]
 }}}

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

Re: [tor-bugs] #25552 [Core Tor/Tor]: prop224: Onion service rev counters are useless and actually harmful for scalability

[Tor Bug Tracker & Wiki]

#25552: prop224: Onion service rev counters are useless and actually harmful for
scalability
---+---
 Reporter:  asn|  Owner:  dgoulet
 Type:  defect | Status:
   |  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.4.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.1.9
 Severity:  Normal | Resolution:
 Keywords:  tor-hs prop224 034-roadmap-master  |  Actual Points:
Parent ID: | Points:  4
 Reviewer:  asn|Sponsor:
---+---
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 HSDirs that allow descriptors with no revision counter should declare a
 new HSDir protocol version.
 We should make services leave out the revision counter if a consensus
 parameter is set.

 Then our upgrade path is:
 1. Wait until most HSDirs support the new protocol
 2. Stop giving the HSDir flag to relays that don't support the new
 protocol
 3. Make services uses the new protocol by setting the consensus parameter

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

Re: [tor-bugs] #25552 [Core Tor/Tor]: prop224: Onion service rev counters are useless and actually harmful for scalability

[Tor Bug Tracker & Wiki]

#25552: prop224: Onion service rev counters are useless and actually harmful for
scalability
---+---
 Reporter:  asn|  Owner:  dgoulet
 Type:  defect | Status:
   |  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.4.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.1.9
 Severity:  Normal | Resolution:
 Keywords:  tor-hs prop224 034-roadmap-master  |  Actual Points:
Parent ID: | Points:  4
 Reviewer:  asn|Sponsor:
---+---
Changes (by teor):

 * status:  needs_revision => needs_review


Comment:

 Oh, wait, that doesn't work. It leaks the service's clock / clock skew to
 HSDirs and clients.

 We could add noise and round, but suddenly the patch isn't simple any
 more.

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

Re: [tor-bugs] #25994 [Core Tor/Tor]: test_channel: keep time constant when running channel/outbound_cell

[Tor Bug Tracker & Wiki]

#25994: test_channel: keep time constant when running channel/outbound_cell
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, tor-tests-coverage, tor- |  Actual Points:
  tests-unit |
Parent ID:  #25993   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  assigned => needs_review


Comment:

 https://github.com/torproject/tor/pull/73 is a pull request here; the
 branch is `bug25994`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25994 [Core Tor/Tor]: test_channel: keep time constant when running channel/outbound_cell

[Tor Bug Tracker & Wiki]

#25994: test_channel: keep time constant when running channel/outbound_cell
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  tor-ci, tor-tests-coverage, tor-
 Severity:  Normal   |  tests-unit
Actual Points:   |  Parent ID:  #25993
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 With fairly low probability, the outbound_cell test could get run with
 cached_gettimeofday on a different 10-second boundary than the current
 value of gettimeofday, resulting in a call to scale_active_circuits().

 Now that we no longer use cached_gettimeofday, the probability of calling
 scale_active_circuits is even lower here.  If the test takes about 200
 microseconds (as it does on my desktop), we should only expect it to
 straddle the 10-second boundary with P < 200 usec / 10s == 1 / 5.

 Still, it's a good idea to fix this kind of thing.

 This change will _lower_ coverage from the maximum by making it so this
 test does not call scale_active_circuits.  However, this test does not
 actually validate any of the behavior of scale_active_circuits, so this
 change is appropriate.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by saper):

 Don't be sorry, it's fun!

 I have pushed some improvements for IRC to my branch on top of your
 changes. Now trying to fight openssl. Interestingly, without pacman
 running we still get OpenSSL from _somewhere_. Jumping into RDP to figure
 out from where exactly it is coming (looks like mingw has it preinstalled)

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

Re: [tor-bugs] #25552 [Core Tor/Tor]: prop224: Onion service rev counters are useless and actually harmful for scalability

[Tor Bug Tracker & Wiki]

#25552: prop224: Onion service rev counters are useless and actually harmful for
scalability
---+---
 Reporter:  asn|  Owner:  dgoulet
 Type:  defect | Status:
   |  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.4.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.1.9
 Severity:  Normal | Resolution:
 Keywords:  tor-hs prop224 034-roadmap-master  |  Actual Points:
Parent ID: | Points:  4
 Reviewer:  asn|Sponsor:
---+---
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 I'm going to suggest a different strategy:
 1. Make v3 onion services use the descriptor generation timestamp for the
 revision counter
 2. Backport this change to all tor versions with v3 onion services (0.3.2
 and later)

 This fix will make v3 onion services scaleable, by allowing multiple
 services to submit descriptors with a very small probability of revision
 number collisions. It also retains the property that newer descriptors
 replace older ones.

 We can make a separate decision about replay caches on HSDirs.
 We can make a separate decision about removing the revision counter
 entirely.
 If we decide to keep it, we should check that it's a 64-bit field, so it
 lasts past 2038.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by cypherpunks):

 Loud Amazon were given the choice between dictator's $$$ and reputation.
 Amazon chose $$$...
 Learn google's history, amazon. Dictator would steal your $$$ and kill you
 later. Do stuff silently next time.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by cypherpunks):

 Replying to [comment:24 cypherpunks]:
 > Replying to [comment:23 cypherpunks]:
 > > [https://news.ycombinator.com/item?id=16869269 Rumors]:
 > > > Hey, everyone. We spent a decent amount of time at Signal trying to
 come up with alternatives when we first heard rumors that Google was
 disabling domain fronting on GAE.
 > Wow, maybe sometime in the future will start learning about Google
 deprecating this or that from SecureDrop leakers at the nytimes/bezos
 post. Truly epic that they didn't even bother to put a notice or
 something, not even a two line blog post. Maybe people should no longer
 base things off anything Google related, and maybe RMS was right.
 This is no longer accurate, Moxie did receive a 30 day notice and the
 reason isn't related to Telegram but following lobbying efforts to not
 block requests from the fine people in Iran,
 > In early 2018, a number of policy organizations increased pressure on
 Google to change their position on how they were interpreting US sanction
 law so that domain fronting would be possible from Iran. Sadly, these
 lobbying efforts seem to have had the opposite effect. When Google’s
 leadership became more aware of domain fronting, it generated internal
 conversations about whether they wanted to put themselves in the situation
 of providing cover for sites that entire countries wished to block.
 >
 > A month later, we received 30-day advance notice from Google that they
 would be making internal changes to stop domain fronting from working
 entirely.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by cypherpunks):

 Replying to [comment:30 cypherpunks]:
 > > Why not use Souq or some other CDN as the domain front like Signal is
 doing?
 > [https://signal.org/blog/looking-back-on-the-front/ Amazon threatens to
 suspend Signal's AWS account over censorship circumvention]
 Glad m0xie didn't shut up about this thing and voiced it loudly! It's
 receiving enough coverage now on Hacker News which, unfortunately, has a
 lot of pro-censorship pro-Bezos apologia (Russian Internet Agency trolls?)
 https://news.ycombinator.com/item?id=16970199

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

Re: [tor-bugs] #25552 [Core Tor/Tor]: prop224: Onion service rev counters are useless and actually harmful for scalability

[Tor Bug Tracker & Wiki]

#25552: prop224: Onion service rev counters are useless and actually harmful for
scalability
---+---
 Reporter:  asn|  Owner:  dgoulet
 Type:  defect | Status:
   |  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.4.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.1.9
 Severity:  Normal | Resolution:
 Keywords:  tor-hs prop224 034-roadmap-master  |  Actual Points:
Parent ID: | Points:  4
 Reviewer:  asn|Sponsor:
---+---
Changes (by dgoulet):

 * status:  assigned => needs_review
 * reviewer:   => asn


Comment:

 Possible branch: `ticket25552_034_01`.

 To be honest, I currently don't see a way for service to stop putting the
 revision counter without breaking many clients because of comment:15.

 Seems like once all HSDir <= 032 are phased out, we can then make the
 service stop putting it in the descriptor (which will break <= 032
 clients...). This means that *right now* (it is in the branch) we have to
 either make the client ignore the revision counter in the secret in put
 construction or always use 0 if no rev counter in the descriptor (which I
 did for simplicity).

 Anyway, see the attempt above.

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

Re: [tor-bugs] #23883 [Core Tor/Tor]: document how to get Travis or GitLab CI running on your fork of tor

[Tor Bug Tracker & Wiki]

#23883: document how to get Travis or GitLab CI running on your fork of tor
-+-
 Reporter:  catalyst |  Owner:
 |  catalyst
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  new-developers, tor-ci, tor-doc, |  Actual Points:
  034-roadmap-subtask, 034-triage-20180328,  |
  034-included-20180328  |
Parent ID:  #25550   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor3
-+-
Changes (by Hello71):

 * status:  assigned => needs_review


Comment:

 https://cgit.alxu.ca/tor.git/commit/?h=bug23883

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

Re: [tor-bugs] #25552 [Core Tor/Tor]: prop224: Onion service rev counters are useless and actually harmful for scalability

[Tor Bug Tracker & Wiki]

#25552: prop224: Onion service rev counters are useless and actually harmful for
scalability
---+---
 Reporter:  asn|  Owner:  dgoulet
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.4.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.1.9
 Severity:  Normal | Resolution:
 Keywords:  tor-hs prop224 034-roadmap-master  |  Actual Points:
Parent ID: | Points:  4
 Reviewer: |Sponsor:
---+---

Comment (by dgoulet):

 Replying to [comment:7 teor]:
 > > So as long as we get the new functionality into HSDirs before the next
 long-term-stable, the "far future" will just be a matter of waiting some
 months for intermediate stable versions to die out.
 >
 > But hang on, do clients require descriptors to have revision counters?

 So here is the fun part of this. Client do look at the revision counter
 when caching but only to decide if they have a newer one in their cache or
 not. Thus, a revision counter always to 0 for instance wouldn't affect the
 client cache.

 As for HSDir, they won't accept a descriptor with a revision counter that
 is lower or equal with the one they have in their cache. Meaning that 034+
 services will still need to put the revision counter in their descriptor
 for a while until <= 032 is phased out. Not putting the revision counter
 in the descriptor for specific HSDir is not trivial amount of engineering
 work.

 Now, this is where it gets messy. When decoding the plaintext part of a
 descriptor (where the rev. counter is), we hard require the counter to be
 in it (notice the `EQ(1)`):

 {{{
   T1(str_rev_counter, R3_REVISION_COUNTER, EQ(1), NO_OBJ),
 }}}

 Thus, as long as we have 032 and 033 HSDirs and clients on the network, we
 can't remove the counter from the descriptor else they won't be able to
 store/access 034+ services as every descriptor will fail to be decoded.

 Thus to summarize, the only thing we can do for now is make HSDir use a
 replaycache instead of revision counter, make client ignore revision
 counter and make the revision counter optional in the descriptor when
 decoding it.

 But we MUST make the service put the rev counter regardless, with the
 current mechanism, in the descriptor for a while else it will break client
 and HSDir <= 033.

 Or a more nuclear option, we bump the descriptor version to 4 which won't
 have the revision counter which will effectively make 034+ the birth of
 the onion service v4 :P.. not ideal ;).

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by cypherpunks):

 > Why not use Souq or some other CDN as the domain front like Signal is
 doing?
 [https://signal.org/blog/looking-back-on-the-front/ Amazon threatens to
 suspend Signal's AWS account over censorship circumvention]
 > Yesterday AWS became aware of your Github and Hacker News/ycombinator
 posts describing how Signal plans to make its traffic look like traffic
 from another site
 They reads?!
 RedTeamers is like censors, censors is like nazi.
 Punch a nazi in the face.

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

Re: [tor-bugs] #25483 [Obfuscation/Snowflake]: Windows reproducible build of snowflake

[Tor Bug Tracker & Wiki]

#25483: Windows reproducible build of snowflake
---+--
 Reporter:  arlolra|  Owner:  sukhbir
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorbrowserTeam201804   |  Actual Points:
Parent ID:  #19001 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by sukhbir):

 As an update to this ticket, I have been trying to get the Windows build
 to work, the latest progress of which is at https://github.com/azadi/tor-
 browser-build/commits/go-webrtc ... it's not much and mostly builds on the
 work of dcf and others to try to fix the error below.

 Currently, the status is that we are hitting a linking error when trying
 to build `go-webrtc` (`mingw-w64`) with `webrtc` (`clang`). The exact
 error is:

 {{{
 /var/tmp/dist/mingw-w64/x86_64-w64-mingw32/include/malloc.h:183:0:
 note: this is the location of the previous definition
  #define alloca(x) __builtin_alloca((x))
  ^
 # github.com/keroserene/go-webrtc
 
/var/tmp/dist/mingw-w64/lib/gcc/x86_64-w64-mingw32/5.4.0/../../../../x86_64-w64-mingw32/lib/../lib/libstdc++.a
 (cow-stdexcept.o): In function `std::string::_M_data() const':
 
/var/tmp/build/gcc/x86_64-w64-mingw32/libstdc++-v3/src/c++11/../../../../gcc-5.4.0/libstdc++-v3/src/c++11
 /cow-stdexcept.cc:44: multiple definition of
 `std::logic_error::logic_error(std::logic_error const&)'
 /tmp/go-build868110800/github.com/keroserene/go-
 
webrtc/_obj/peerconnection.cc.o:peerconnection.cc:(.text$_ZNSt11logic_errorC2ERKS_[_ZNSt11logic_errorC2ERKS_]+0x0):
 first defined here
 /tmp/go-build868110800/github.com/keroserene/go-
 webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0x5a9): undefined
 reference to `cricket::AudioCodec::ToString() const'
 /tmp/go-build868110800/github.com/keroserene/go-
 webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0x6de): undefined
 reference to `webrtc::RtpExtension::ToString() const'
 /tmp/go-build868110800/github.com/keroserene/go-
 webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0x813): undefined
 reference to `cricket::DataCodec::ToString() const'
 /tmp/go-build868110800/github.com/keroserene/go-
 webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0x8f5): undefined
 reference to `rtc::FatalMessage::FatalMessage(char const*, int)'
 /tmp/go-build868110800/github.com/keroserene/go-
 webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0x96a): undefined
 reference to `rtc::FatalMessage::~FatalMessage()'
 /tmp/go-build868110800/github.com/keroserene/go-
 webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0xa1b): undefined
 reference to `rtc::FatalMessage::~FatalMessage()'
 /tmp/go-build868110800/github.com/keroserene/go-
 webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0xbf8): undefined
 reference to `rtc::FatalMessage::FatalMessage(char const*, int)'
 /tmp/go-build868110800/github.com/keroserene/go-
 webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0xc6d): undefined
 reference to `rtc::FatalMessage::~FatalMessage()'
 /tmp/go-build868110800/github.com/keroserene/go-
 webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0xd20): undefined
 reference to `rtc::FatalMessage::~FatalMessage()'
 /tmp/go-build868110800/github.com/keroserene/go-
 webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0xdb1): undefined
 reference to `rtc::FatalMessage::FatalMessage(char const*, int)'
 /tmp/go-build868110800/github.com/keroserene/go-
 webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0xe26): undefined
 reference to `rtc::FatalMessage::~FatalMessage()'
 /tmp/go-build868110800/github.com/keroserene/go-
 webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0xed5): undefined
 reference to `rtc::FatalMessage::~FatalMessage()'
 /tmp/go-build868110800/github.com/keroserene/go-
 webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0xf6d): undefined
 reference to `rtc::FatalMessage::FatalMessage(char const*, int)'
 /tmp/go-build868110800/github.com/keroserene/go-
 webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0xfe2): undefined
 reference to `rtc::FatalMessage::~FatalMessage()'
 /tmp/go-build868110800/github.com/keroserene/go-
 webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0x1094): undefined
 reference to `rtc::FatalMessage::~FatalMessage()'
 /tmp/go-build868110800/github.com/keroserene/go-
 webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0x112c): undefined
 reference to `rtc::FatalMessage::FatalMessage(char const*, int)'
 /tmp/go-build868110800/github.com/keroserene/go-
 webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0x11a1): undefined
 reference to `rtc::FatalMessage::~FatalMessage()'
 /tmp/go-build868110800/github.com/keroserene/go-
 

Re: [tor-bugs] #25993 [Core Tor/Tor]: Improve deliberate test coverage for addressmap_get_virtual_address()

[Tor Bug Tracker & Wiki]

#25993: Improve deliberate test coverage for addressmap_get_virtual_address()
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, tor-tests-coverage, tor- |  Actual Points:
  tests-unit |
Parent ID:  #25908   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  assigned => needs_review


Comment:

 Yes, this does seem to cover the lines that were flapping on and off
 before, plus a few more lines as well.
 https://github.com/torproject/tor/pull/72 is a pull request.

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

Re: [tor-bugs] #25552 [Core Tor/Tor]: prop224: Onion service rev counters are useless and actually harmful for scalability

[Tor Bug Tracker & Wiki]

#25552: prop224: Onion service rev counters are useless and actually harmful for
scalability
---+---
 Reporter:  asn|  Owner:  dgoulet
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.4.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.1.9
 Severity:  Normal | Resolution:
 Keywords:  tor-hs prop224 034-roadmap-master  |  Actual Points:
Parent ID: | Points:  4
 Reviewer: |Sponsor:
---+---

Comment (by dgoulet):

 Here is a fun fact. We use the revision counter in the computation of the
 descriptor encryption keys. See spec section `HS-DESC-ENCRYPTION-KEYS`.

 So bottom line, this means that we have to remove it from `secret_input`
 computation *but* only if we can't find the counter in the plaintext data
 of the descriptor (`"revision-counter" SP Integer NL`).

 Code wise, this isn't very complicated but I thought it would be wise to
 just throw it out there since it affects our crypto construction.

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

Re: [tor-bugs] #22782 [Obfuscation/Snowflake]: Additional domain fronts for Snowflake rendezvous

[Tor Bug Tracker & Wiki]

#22782: Additional domain fronts for Snowflake rendezvous
---+--
 Reporter:  cypherpunks|  Owner:  (none)
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 > "muh malware uses domain fronting!1!!"
 RedTeamers around net(s) (very isolated really soon) are happy now, they
 said.
 > Really good move. We should be happy as an industry.

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

Re: [tor-bugs] #25993 [Core Tor/Tor]: Improve deliberate test coverage for addressmap_get_virtual_address()

[Tor Bug Tracker & Wiki]

#25993: Improve deliberate test coverage for addressmap_get_virtual_address()
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, tor-tests-coverage, tor- |  Actual Points:
  tests-unit |
Parent ID:  #25908   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 I have a branch `ticket25993`.  I'm going to wait to see what coveralls
 says about it before I make a PR 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

[tor-bugs] #25993 [Core Tor/Tor]: Improve deliberate test coverage for addressmap_get_virtual_address()

[Tor Bug Tracker & Wiki]

#25993: Improve deliberate test coverage for addressmap_get_virtual_address()
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  tor-ci, tor-tests-coverage, tor-
 Severity:  Normal   |  tests-unit
Actual Points:   |  Parent ID:  #25908
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 This function is currently tested indirectly from test_entryconn.c, but
 this results in unreliable coverage for a couple of the features in this
 function.

 Specifically, we don't test whether duplicate addresses are rejected, or
 whether IPv4 addresses ending with .0 or .255 are rejected.

 This is one source of nondeterminism in our test coverage.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by isis):

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

 Yeah… that script is a bit janky. The original (at least the one that I
 took) is [https://github.com/nexB/scancode-
 toolkit/blob/ea08cf2313583e36ccf1c4f5c4e9fd45d90fbb1f/etc/scripts/irc-
 notify.py here]. It definitely doesn't handle UTF-8. :'( I'm sorry it
 messed up your name!

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by isis):

 Replying to [comment:20 saper]:
 > I think `zstd` is not working because, again, there is no `zstd-devel`
 available.

 Yeah, that's definitely not working… maybe chocolatey has it packaged?

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

Re: [tor-bugs] #22346 [Metrics/Statistics]: Investigate drop in Tor Browser update pings in early 2017 and 2018

[Tor Bug Tracker & Wiki]

#22346: Investigate drop in Tor Browser update pings in early 2017 and 2018
+--
 Reporter:  cypherpunks |  Owner:  metrics-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arthuredelstein):

 * cc: arthuredelstein (added)


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

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

[Tor Bug Tracker & Wiki]

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

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


Comment:

 No one I've asked seems to be able to reproduce this on a modern tor.
 There's some evidence that such a bug might have existed back before
 0.2.0, but it seems like it's gone in supported releases.

 rl1987, thanks again for working on this patch.  I'm sorry it turns out to
 be unnecessary.

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

Re: [tor-bugs] #25992 [Applications/Tor Browser]: Should Tor Browser use DuckDuckGo's onion (hidden) service instead of their normal website as the default search engine?

[Tor Bug Tracker & Wiki]

#25992: Should Tor Browser use DuckDuckGo's onion (hidden) service instead of 
their
normal website as the default search engine?
--+---
 Reporter:  nsuchy|  Owner:  tbb-team
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by cypherpunks):

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


Comment:

 Duplicate #21483

 The basic problem here is that the TB folks don't know if DDG's Onion can
 handle the load from such a switch.

 See also #24379 for a lower impact proposal.

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

Re: [tor-bugs] #25979 [Core Tor/Stem]: Stem, Tor LTS, broken exit policies, and maybe microdescriptor issues too

[Tor Bug Tracker & Wiki]

#25979: Stem, Tor LTS, broken exit policies, and maybe microdescriptor issues 
too
---+
 Reporter:  pastly |  Owner:  atagar
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  worksforme
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by atagar):

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


Comment:

 Hi pastly. Honestly there's enough confusion around this that I'm inclined
 to close. I'd be delighted to take a patch if there's something wrong with
 Stem's consensus flavor handling but I'm unclear from the above quite what
 was up here.

 Feel free to reopen if you run into further issues or would like to
 discuss more.

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

Re: [tor-bugs] #25927 [Core Tor/Tor]: Remove the need for gettimeofday_cached(); use monotonic time in ewma code

[Tor Bug Tracker & Wiki]

#25927: Remove the need for gettimeofday_cached(); use monotonic time in ewma 
code
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-roadmap-subtask, |  implemented
  034-triage-20180328, 034-included-20180328 |  Actual Points:
Parent ID:  #25375   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor8
-+-
Changes (by nickm):

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


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

Re: [tor-bugs] #25927 [Core Tor/Tor]: Remove the need for gettimeofday_cached(); use monotonic time in ewma code

[Tor Bug Tracker & Wiki]

#25927: Remove the need for gettimeofday_cached(); use monotonic time in ewma 
code
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-roadmap-subtask, |  Actual Points:
  034-triage-20180328, 034-included-20180328 |
Parent ID:  #25375   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor8
-+-

Comment (by nickm):

 Commented on the randomness; merging to master. Will keep an eye on CI in
 case it breaks.

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

Re: [tor-bugs] #25936 [Core Tor/Tor]: have travis display test-suite.log from the right place when DISTCHECK=yes

[Tor Bug Tracker & Wiki]

#25936: have travis display test-suite.log from the right place when 
DISTCHECK=yes
--+
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-ci, fast-fix  |  Actual Points:
Parent ID:  #25550| Points:
 Reviewer:  isis  |Sponsor:  Sponsor3-can
--+
Changes (by isis):

 * status:  needs_review => merge_ready


Comment:

 LGTM!

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

Re: [tor-bugs] #25952 [Core Tor/Tor]: Move check_whether_*port_reachable() to a scheduled callback, not once-per-second

[Tor Bug Tracker & Wiki]

#25952: Move check_whether_*port_reachable() to a scheduled callback, not 
once-per-
second
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-roadmap-subtask, |  Actual Points:
  034-triage-20180328, 034-included-20180328 |
Parent ID:  #25375   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by nickm):

 * status:  assigned => needs_review


Comment:

 Github PR at https://github.com/torproject/tor/pull/70 .

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

Re: [tor-bugs] #25974 [Applications/Tor Browser]: Make sure Android Oreo(API level 26) autofill feature is disabled

[Tor Bug Tracker & Wiki]

#25974: Make sure Android Oreo(API level 26) autofill feature is disabled
--+---
 Reporter:  igt0  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by igt0):

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


Comment:

 Firefox Mobile doesn't support yeat Android Oreo Autofill, see bug:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1352011

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

Re: [tor-bugs] #25978 [Core Tor/Tor]: UseEntryGuards 0 disables EntryNodes

[Tor Bug Tracker & Wiki]

#25978: UseEntryGuards 0 disables EntryNodes
--+--
 Reporter:  tortrac   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  easy, doc |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by tortrac):

 * priority:  Medium => Immediate
 * severity:  Normal => Critical


Comment:

 i KNOW "WORK" is scary

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

Re: [tor-bugs] #25978 [Core Tor/Tor]: UseEntryGuards 0 disables EntryNodes

[Tor Bug Tracker & Wiki]

#25978: UseEntryGuards 0 disables EntryNodes
--+--
 Reporter:  tortrac   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy, doc |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by tortrac):

 Ok, instead of making something work it seems much easier to just write 3
 words in the "Manual" stating it does not work as opposed to doing real
 work to make something work.  It is ok I get it, which is why I will come
 off how you do not usually see me.

 Consensus does not make set in stone "perfect" so don't fall into that
 trap in programming.  Only real work breaking out of the "Mold" will help
 you develop outside the "Frameworks" of the fascists.

 Of course this is the tool of the fascists, but the Germans didn't develop
 the first Tank either.  But they made the first Assault Rifle and First
 working Front Line Jet Aircraft.  They however worked indepedent of the
 fascist system to succeed despite it.

 The USA failed the Space Race against the superiour Soviet Russians, but
 textbooks write some fairytail fascists dreams of "winning" much like
 Trump dreams on twitter probably using Tor too.

 The USA shut down Von Braun from working on the space race and rockets, to
 hand off to an American indigenous fascist Navy group to take credit, but
 they were too incompetent.

 The only reason America develop further was because Von Braun and his team
 of Germans kept working independently of the fascist system they were a
 part of and suceed in develping the Saturn V rocket, but now no one ever
 questions that history could ever have been different??

 RISE UP OR SHUT UP AND STOP CHANGING PEOPLES WORK TO SUIT YOUR FASCIST
 AGENDAS IT WILL NOT HELP YOU BECOME MORE "EFFICIENT"

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

Re: [tor-bugs] #25386 [Core Tor/Tor]: fix rust tests

[Tor Bug Tracker & Wiki]

#25386: fix rust tests
-+-
 Reporter:  Hello71  |  Owner:  Hello71
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, tor-test, 033-backport,|  Actual Points:
  review-group-34, 034-triage-20180328,  |
  034-included-20180401  |
Parent ID:   | Points:  3
 Reviewer:  isis |Sponsor:
 |  SponsorQ
-+-

Comment (by Hello71):

 I give up. Manish, what should we do here?

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

Re: [tor-bugs] #25992 [Applications/Tor Browser]: Should Tor Browser use DuckDuckGo's onion (hidden) service instead of their normal website as the default search engine? (was: Should Tor Browser use

[Tor Bug Tracker & Wiki]

#25992: Should Tor Browser use DuckDuckGo's onion (hidden) service instead of 
their
normal website as the default search engine?
--+--
 Reporter:  nsuchy|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

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

[tor-bugs] #25992 [Applications/Tor Browser]: Should Tor Browser use DuckDuckGo's onion (hidden) service instaead of their normal website as the default search engine?

[Tor Bug Tracker & Wiki]

#25992: Should Tor Browser use DuckDuckGo's onion (hidden) service instaead of
their normal website as the default search engine?
--+--
 Reporter:  nsuchy|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 The current version of the Tor Browser Bundle uses the search engine
 DuckDuckGo to allow users to easily make search queries from the about:tor
 page and the address bar. I noticed that DuckDuckGo also has an onion
 (hidden) service available. As such, should Tor Browser use DuckDuckGo's
 onion (hidden) service instead of their normal website as the default
 search engine?

 **A few benefits I see here:**

 *) Shows what Tor Hidden Services can do - do all Tor Browser users know
 about or use a Tor Hidden Service? This could make it shine and users the
 benefit on a day to day basis.

 *) The amount of "exit" bandwidth to DuckDuckGo's services would be
 diverted into relay bandwidth (based on my understanding of tor hidden
 services - not exactly sure but relays with a no-exit policy would still
 help route traffic to DuckDuckGo)

 **Example Query (URL Syntax):**
 https://3g2upl4pq6kufc4m.onion/?q=Tor+Browser+Bundle=hf

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

Re: [tor-bugs] #25979 [Core Tor/Stem]: Stem, Tor LTS, broken exit policies, and maybe microdescriptor issues too

[Tor Bug Tracker & Wiki]

#25979: Stem, Tor LTS, broken exit policies, and maybe microdescriptor issues 
too
---+
 Reporter:  pastly |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by pastly):

 Some updates:

 - Updating to 03210 and continuing to use a Tor client (not a relay of any
 sort) did not help. Same tracebacks. So it probably isn't related to Tor
 version.
 - Adding the
 [https://stem.torproject.org/tutorials/mirror_mirror_on_the_wall.html#can-i
 -get-descriptors-from-the-tor-process torrc options listed here] to an
 03210 client works!

 {{{
 FetchDirInfoEarly 1
 FetchDirInfoExtraEarly 1
 FetchUselessDescriptors 1
 UseMicrodescriptors 0
 DownloadExtraInfo 1
 }}}

 - The same torrc options in a 02915 client (yes, I've been upgraded to .15
 since opening the ticket yesterday) work

 New core theory: I only had all the available network
 status/descriptor/whatever information in my initial testing because I was
 using an authority for testing.

 I want you to feel free to close this ticket if it is too broad, too
 unhelpful, or just has a general air of unactionable noise.

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

Re: [tor-bugs] #12208 [Obfuscation/meek]: Make it possible to use an IP address as a front (no DNS request and no SNI)

[Tor Bug Tracker & Wiki]

#12208: Make it possible to use an IP address as a front (no DNS request and no
SNI)
--+--
 Reporter:  dcf   |  Owner:  dcf
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mcs):

 * cc: brade, mcs (added)


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

Re: [tor-bugs] #12208 [Obfuscation/meek]: Make it possible to use an IP address as a front (no DNS request and no SNI)

[Tor Bug Tracker & Wiki]

#12208: Make it possible to use an IP address as a front (no DNS request and no
SNI)
--+--
 Reporter:  dcf   |  Owner:  dcf
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by dcf):

 Replying to [comment:13 cypherpunks]:
 > > Will it be easier for a censor to block the SNI-less domain fronting
 or it's of similar difficulty as the "original" domain fronting
 implementation?
 >
 > Depends censorship level.
 > https://en.wikipedia.org/wiki/Server_Name_Indication#Support

 Ya it depends.
 [https://www.bamsoftware.com/papers/fronting/#sec:introduction Back in
 June 2014] (ctrl+f for "domainless"), about 16% of observed TLS
 connections didn't have SNI. I don't know what it is now.

 But the TLS fingerprint also matters. If the fingerprint looks exactly
 like a specific version of Firefox, except that it lacks SNI, that's
 probably unusual enough to block. It would only happen in normal use when
 someone browses to an IP address, which is unusual except for rare cases
 like https://1.1.1.1/. For this reason I'm thinking of adopting the
 [https://github.com/refraction-networking/utls utls] library which allows
 modifying the TLS fingerprint from ordinary Go code. In any case, using
 the Firefox helper won't be possible when making SNI-less requests,
 because I'm not aware of any way to control behavior like that from a
 browser extension.

 But another issue is potential blocking by the intermediary services.
 Maybe a CDN decides they want to always require SNI and they stop dropping
 SNI-less connections. [https://www.bamsoftware.com/papers/thesis/#p239
 Cloudflare did this in 2015] on all of their edge servers except for a few
 special ones, requiring SNI and enforcing a match between SNI and Host
 header.

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

Re: [tor-bugs] #25610 [Core Tor/Tor]: module: Modularized directory authority subsystem

[Tor Bug Tracker & Wiki]

#25610: module: Modularized directory authority subsystem
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  modularization, 034-roadmap- |  Actual Points:
  subtask, tor-dirauth, 034-triage-20180328, |
  034-included-20180328  |
Parent ID:  #25494   | Points:
 Reviewer:  nickm|Sponsor:
 |  Sponsor8
-+-

Comment (by dgoulet):

 Replying to [comment:9 dgoulet]:

 For completion:

 > 1. We need to wrap the `authdir_mode()` and cie functions so they NEVER
 return true if the module is disabled as extra protection.

 #25990

 > 2. The `directory.c`, `dirserv.c` and `networkstatus.c` files have a lot
 of things that are dirauth only. Basically, everything that touches vote
 document should be extracted into the dirauth module. This is quite a bit
 of work so we decided to do that as a second step if time permits.

 #25989

 >
 > 3. Write a documentation in `doc/HACKING/` probably on how to proceed
 with a module. It is not that complicated but there are couple things to
 follow with the build system and code standards.

 #25991

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25991 [Core Tor/Tor]: module: Write documentation in doc/ on how to write a module

[Tor Bug Tracker & Wiki]

#25991: module: Write documentation in doc/ on how to write a module
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  034-roadmap-subtask,
 Severity:  Normal   |  modularization, documentation
Actual Points:   |  Parent ID:  #25494
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Write a small file in `doc/HACKING/` on how to proceed with a module. The
 current template is the freshly merged dirauth module.

 This would be for now mostly related to the build system and the code
 standards.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25990 [Core Tor/Tor]: module: Better safeguard authdir_mode_v3() if dirauth module is disabled

[Tor Bug Tracker & Wiki]

#25990: module: Better safeguard authdir_mode_v3() if dirauth module is disabled
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  034-roadmap-subtask,
 Severity:  Normal   |  modularization, tor-dirauth, refactor
Actual Points:   |  Parent ID:  #25494
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We need to safeguard somehow the `authdir_mode_v3()` so it can NEVER
 return true if the dirauth module is disabled.

 One option here is to move this function to the dirauth module and NOP it
 by returning false if the module is not enabled.

 An other option is to #ifdef `HAVE_MODULE_DIRAUTH` in the function
 directly. I'm kind of less enthusiastic about it but maybe it is better,
 dunno yet.

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

[tor-bugs] #25989 [Core Tor/Tor]: module: Improve dirauth module by extracting more code

[Tor Bug Tracker & Wiki]

#25989: module: Improve dirauth module by extracting more code
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:   | Status:  new
  enhancement|
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core |Version:
  Tor/Tor|   Keywords:  modularization, tor-dirauth,
 Severity:  Normal   |  refactor
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 After #25610, we've identified items to pursue as a second milestone in
 the dirauth modularization effort.

 One of these is to start extracting dirauth specific code from
 `directory.c`, `dirserv.c` and `networkstatus.c` which have a lot of
 things that are dirauth only. Basically, everything that handles vote
 document should be extracted into the dirauth module, among other things.

 The trick is to start looking at `NS_TYPE_VOTE` and `authdir_mode_v3()` to
 find which part are dirauth only.

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

Re: [tor-bugs] #25610 [Core Tor/Tor]: module: Modularized directory authority subsystem

[Tor Bug Tracker & Wiki]

#25610: module: Modularized directory authority subsystem
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  modularization, 034-roadmap- |  Actual Points:
  subtask, tor-dirauth, 034-triage-20180328, |
  034-included-20180328  |
Parent ID:  #25494   | Points:
 Reviewer:  nickm|Sponsor:
 |  Sponsor8
-+-
Changes (by dgoulet):

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


Comment:

 All child tickets have been resolved, closing.

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

Re: [tor-bugs] #25953 [Core Tor/Tor]: Module: Add Travis target for modularized directory authority subsystem

[Tor Bug Tracker & Wiki]

#25953: Module: Add Travis target for modularized directory authority subsystem
+
 Reporter:  ahf |  Owner:  ahf
 Type:  task| Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  modularization  |  Actual Points:
Parent ID:  #25610  | Points:
 Reviewer:  dgoulet |Sponsor:  Sponsor8
+
Changes (by dgoulet):

 * status:  assigned => closed
 * reviewer:   => dgoulet
 * resolution:   => fixed


Comment:

 Now that #25610 is merged, I think this is good to go!

 I've cherry-pick the commit and its fixup, squashed it into one and merged
 upstream. See my branch `ticket25953_034_01` for historical purposes ;).

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

Re: [tor-bugs] #25914 [Core Tor/Tor]: dirserv: Remove dead code

[Tor Bug Tracker & Wiki]

#25914: dirserv: Remove dead code
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth, deadcode, easy, 034 |  Actual Points:
  -roadmap-subtask   |
Parent ID:   | Points:
 Reviewer:  mikeperry|Sponsor:
-+-
Changes (by dgoulet):

 * parent:  #25610 =>


Comment:

 Turns out it has nothing to do with dirauth modularization. Unparenting.

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

Re: [tor-bugs] #24377 [Core Tor/Tor]: Warn about networkstatus_compute_consensus() breakage in all the functions it calls

[Tor Bug Tracker & Wiki]

#24377: Warn about networkstatus_compute_consensus() breakage in all the 
functions
it calls
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  doc, automation-needed, tor- |  Actual Points:
  dirauth, 033-triage-20180320,  |
  033-removed-20180320   |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * parent:  #25610 =>


Comment:

 Unparenting so we can close the dirauth modularization task ticket.

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

Re: [tor-bugs] #25927 [Core Tor/Tor]: Remove the need for gettimeofday_cached(); use monotonic time in ewma code

[Tor Bug Tracker & Wiki]

#25927: Remove the need for gettimeofday_cached(); use monotonic time in ewma 
code
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-roadmap-subtask, |  Actual Points:
  034-triage-20180328, 034-included-20180328 |
Parent ID:  #25375   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor8
-+-
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 Looks good to me. Only one comment about the added random value of the
 tick number which is the only difference I could see on the EWMA side for
 which I believe it is a good addition!

 However, I can't test the compat functions for the `diff_msec()` so I
 would rely on travis and Jenkins to pick up any issues on other platforms
 if we do test them in the CI.

 Test passes.

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

Re: [tor-bugs] #25988 [Core Tor/Tor]: module: Post-merge tasks for dirauth modularization

[Tor Bug Tracker & Wiki]

#25988: module: Post-merge tasks for dirauth modularization
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  034-roadmap-subtask, tor-dirauth,|  Actual Points:
  module |
Parent ID:  #25610   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 lgtm; tests pass.  Merging!

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

Re: [tor-bugs] #25950 [Core Tor/Tor]: Run "accounting_run_housekeeping" with a periodic event.

[Tor Bug Tracker & Wiki]

#25950: Run "accounting_run_housekeeping" with a periodic event.
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-roadmap-subtask, |  Actual Points:
  034-triage-20180328, 034-included-20180328 |
Parent ID:  #25375   | Points:
 Reviewer:   |Sponsor:
-+-
Description changed by nickm:

Old description:



New description:

 Here's an implementation sketch:
   * Make accounting_add_bytes() check whether limits are exceeded.
 Refactor the code as needed to make this check fast.
   * If a limit is exceeded, schedule consider_hibernation().
   * Also schedule consider_hibernation() again based on "shutdown_time",
 "hibernate_end_time", and "interval_wakeup_time".
   * Pull "accounting_run_housekeeping" apart:
 * Other logic to set interval_end_time if it isn't set but accounting
 is enabled.
 * A periodic event, only scheduled when network is on and accounting
 is enabled, to record bandwidth usage.  Tie this into the or_state_save
 event.

--

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

Re: [tor-bugs] #25988 [Core Tor/Tor]: module: Post-merge tasks for dirauth modularization

[Tor Bug Tracker & Wiki]

#25988: module: Post-merge tasks for dirauth modularization
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-roadmap-subtask, tor-dirauth,|  Actual Points:
  module |
Parent ID:  #25610   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  assigned => needs_review


Comment:

 Ok I did it all. Not too complicated. No commits change the code behavior.
 Should be fairly easy to review as most of it is renaming and moving code.

 Branch: `ticket25988_034_01`

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

Re: [tor-bugs] #25937 [Core Tor/Tor]: Move dirvote_act into a periodic callback

[Tor Bug Tracker & Wiki]

#25937: Move dirvote_act into a periodic callback
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-roadmap-subtask, |  implemented
  034-triage-20180328, 034-included-20180328 |  Actual Points:
Parent ID:  #25375   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor8
-+-
Changes (by nickm):

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


Comment:

 Made a new branch "dirvote_act_refactor_v2" based on master, and then
 squashed it as "dirvote_act_refactor_v2_squashed".  Then added an extra
 commit to refactor our timer subtraction logic to use a function we
 already had for the purpose, and merged to master!

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

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

[Tor Bug Tracker & Wiki]

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

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


Comment:

 Merged to master; no conflicts!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25988 [Core Tor/Tor]: module: Post-merge tasks for dirauth modularization

[Tor Bug Tracker & Wiki]

#25988: module: Post-merge tasks for dirauth modularization
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  034-roadmap-subtask, tor-dirauth,
 Severity:  Normal   |  module
Actual Points:   |  Parent ID:  #25610
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We've identified a series of things to do post-merge. They aren't that big
 and should be quite straightforward to achieve (no need to do them in that
 order):

 1. Splitting up dirvote_common.

  nickm and I have discussed this and the decision is:
  * `voting_schedule.{c|h}` for the `dirvote_common.c` stuff
  * `shared_random_client.{c|h}` for `shared_random_common.c`.

 2. Adding more #ifdefs (nickm)

 3. Rename and move `dirvote_get_voter_sig_by_alg()`

  We'll move this to `networkstatus.c` and namespace is `networkstatus_`

 4. Make `dirvote_parse_sr_commits` take a const ptr for `tokens`.

  For this to happen, we need to refactor the code so
 `find_opt_by_keyword()` can take a `const` pointer.

 5. Add a changes file.

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

Re: [tor-bugs] #25951 [Core Tor/Tor]: Run flush_pending_log_callbacks() on an as-needed basis, not once-per-second

[Tor Bug Tracker & Wiki]

#25951: Run flush_pending_log_callbacks() on an as-needed basis, not once-per-
second
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-roadmap-subtask, |  Actual Points:
  034-triage-20180328, 034-included-20180328 |
Parent ID:  #25375   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by nickm):

 * status:  assigned => needs_review


Comment:

 https://github.com/torproject/tor/pull/69 is the PR

 Note that this turned out to be easier than I'd thought, because we have a
 preexisting defect in that we already suppress a controller's log message
 events when those callbacks occur outside the main thread.  We should fix
 that some time, but perhaps not now.  See #25987 for ideas to fix that.

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

Re: [tor-bugs] #25610 [Core Tor/Tor]: module: Modularized directory authority subsystem

[Tor Bug Tracker & Wiki]

#25610: module: Modularized directory authority subsystem
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  modularization, 034-roadmap- |  Actual Points:
  subtask, tor-dirauth, 034-triage-20180328, |
  034-included-20180328  |
Parent ID:  #25494   | Points:
 Reviewer:  nickm|Sponsor:
 |  Sponsor8
-+-

Comment (by nickm):

 merged!

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

Re: [tor-bugs] #25610 [Core Tor/Tor]: module: Modularized directory authority subsystem

[Tor Bug Tracker & Wiki]

#25610: module: Modularized directory authority subsystem
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  modularization, 034-roadmap- |  Actual Points:
  subtask, tor-dirauth, 034-triage-20180328, |
  034-included-20180328  |
Parent ID:  #25494   | Points:
 Reviewer:  nickm|Sponsor:
 |  Sponsor8
-+-
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 Squashed branch with extra commit to fix a compiling issue that a previous
 fixup introduced: `ticket25610_034_01-squashed`.

 Extra commit is `d8509b450a1de815`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25987 [Core Tor/Tor]: Allow controller to receive log messages from outside main thread

[Tor Bug Tracker & Wiki]

#25987: Allow controller to receive log messages from outside main thread
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  035-roadmap-proposed small
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Our existing callback system doesn't allow this, but actually it would be
 pretty easy to take care of.

 The trick here would be:
   1) to make it so that the flush_queued_events_event uses the
 alert_sockets_create() mechanism, so it can be turned on from another
 thread.
   2) To remove the check for whether we're in the main thread from
 control_event_logmsg().

 I think this would be pretty simple -- maybe a couple hours of work -- but
 we should consider it only for 0.3.5, since it has potential to be very
 destabilizing if we mess it up.

 Found while working on #25951

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

Re: [tor-bugs] #25973 [Applications/Tor Browser]: Backport off-by-one fix in 1352073

[Tor Bug Tracker & Wiki]

#25973: Backport off-by-one fix in 1352073
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  GeorgKoppen201804,   |  Actual Points:
  TorBrowserTeam201804R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 r=brade, r=mcs

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by cypherpunks):

 Replying to [comment:8 mwolfe]:
 > That's the way the original was, no ./TorBrowser/Tor/ at the beginning.
 Yeah I'm not a Mac OS user (Debian here), sorry about that and glad you
 sorted it out yourself!

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

Re: [tor-bugs] #25552 [Core Tor/Tor]: prop224: Onion service rev counters are useless and actually harmful for scalability

[Tor Bug Tracker & Wiki]

#25552: prop224: Onion service rev counters are useless and actually harmful for
scalability
---+---
 Reporter:  asn|  Owner:  dgoulet
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.4.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.1.9
 Severity:  Normal | Resolution:
 Keywords:  tor-hs prop224 034-roadmap-master  |  Actual Points:
Parent ID: | Points:  4
 Reviewer: |Sponsor:
---+---
Changes (by dgoulet):

 * owner:  asn => dgoulet
 * cc: dgoulet (removed)


Comment:

 Taking over this.

 To summarize, after a discussion with teor and asn, we'll go with a
 replaycache that stores a hash of the descriptor *without* the signature.
 And this would be done _after_ desc signature validation.

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

Re: [tor-bugs] #25610 [Core Tor/Tor]: module: Modularized directory authority subsystem

[Tor Bug Tracker & Wiki]

#25610: module: Modularized directory authority subsystem
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  modularization, 034-roadmap- |  Actual Points:
  subtask, tor-dirauth, 034-triage-20180328, |
  034-included-20180328  |
Parent ID:  #25494   | Points:
 Reviewer:  nickm|Sponsor:
 |  Sponsor8
-+-

Comment (by nickm):

 Okay; we've talked a bit.  Pre-merge tasks are:
   * Decide what we're renaming the "common" modules to.

 Post-merge tasks are:
   * Splitting up dirvote_common.
   * Adding more #ifdefs (nickm)
   * Rename *common
   * Rename and move get_sig_by_alg (nickm)
   * Make dirvote_parse_sr_commits take a const ptr (nickm)

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

Re: [tor-bugs] #25610 [Core Tor/Tor]: module: Modularized directory authority subsystem

[Tor Bug Tracker & Wiki]

#25610: module: Modularized directory authority subsystem
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  modularization, 034-roadmap- |  Actual Points:
  subtask, tor-dirauth, 034-triage-20180328, |
  034-included-20180328  |
Parent ID:  #25494   | Points:
 Reviewer:  nickm|Sponsor:
 |  Sponsor8
-+-
Changes (by dgoulet):

 * status:  needs_revision => needs_review


Comment:

 Some back and forth with nickm on this. Back in needs_review and I believe
 soon in a merge ready state.

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

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

[Tor Bug Tracker & Wiki]

#25870: Fix vanguard restrictions
--+
 Reporter:  mikeperry |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #25546| Points:
 Reviewer:  asn   |Sponsor:
--+
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 Sounds good. I think we good here! Let's have nickm take a peek at it!
 Cheers!

 The branch to review is at `mikeperry/bug25870_rebase`.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by mwolfe):

 Got the new snowflake line.

 The snowflake line didn't work until I modified it to

 ClientTransportPlugin snowflake exec PluggableTransports
 /snowflake-client -url https://snowflake-broker.azureedge.net/ -front
 ajax.aspnetcdn.com -ice stun:stun.l.google.com:19302

 That's the way the original was, no ./TorBrowser/Tor/ at the beginning.

 ***

 Tried the bridges from bridges.torproject.org, six of them (i.e., since
 one gets 3 at a time, I downloaded twice), but could not connect. The
 built-in bridges for obfs4 work fine, but the ones from the database
 didn't. The captcha is very hard for me to read. With the letters and
 numbers overlapping, it's hard for me to be sure what it's asking for, and
 it usually takes me 3 or 5 tries. Not sure why the bridges aren't working.
 I downloaded some a few months ago, and they worked, but not today.

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

Re: [tor-bugs] #8742 [Core Tor/Tor]: Byte history leaks information about local usage/hidden services

[Tor Bug Tracker & Wiki]

#8742: Byte history leaks information about local usage/hidden services
-+-
 Reporter:  alphawolf|  Owner:  (none)
 Type:  defect   | Status:
 |  reopened
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Blocker  | Resolution:
 Keywords:  byte-history, stats, tor-hs, |  Actual Points:
  privacy, tor-relay, 026-triaged-1, |
  027-triaged-1-in, PostFreeze027|
Parent ID:   | Points:  medium
 Reviewer:   |Sponsor:
 |  SponsorR
-+-
Changes (by teor):

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


Comment:

 We use milestones to schedule tickets on the roadmap. This ticket is not
 on the roadmap, so it belongs in "unspecified".

 It is also unclear which version this bug first occurred in,

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

Re: [tor-bugs] #24888 [Core Tor/Tor]: tor 0.2.5.16: src/or/rendservice.c build error: comparison between signed and unsigned

[Tor Bug Tracker & Wiki]

#24888: tor 0.2.5.16: src/or/rendservice.c build error: comparison between 
signed
and unsigned
--+--
 Reporter:  Zenitur   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.2.5.16
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * milestone:  Tor: 0.2.9.x-final => Tor: unspecified


Comment:

 We use milestones to schedule tickets on the roadmap. This ticket is not
 on the roadmap, so it belongs in "unspecified".

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

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

[Tor Bug Tracker & Wiki]

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

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


Comment:

 Merged this to master; 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] #25949 [Core Tor/Tor]: Handle deferred SIGNEWNYM requests with a mainloop event

[Tor Bug Tracker & Wiki]

#25949: Handle deferred SIGNEWNYM requests with a mainloop event
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-roadmap-subtask, |  Actual Points:
  034-triage-20180328, 034-included-20180328 |
Parent ID:  #25375   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-
Changes (by nickm):

 * status:  assigned => needs_review


Comment:

 https://github.com/torproject/tor/pull/68 is a PR here.

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

Re: [tor-bugs] #22782 [Obfuscation/Snowflake]: Additional domain fronts for Snowflake rendezvous

[Tor Bug Tracker & Wiki]

#22782: Additional domain fronts for Snowflake rendezvous
---+--
 Reporter:  cypherpunks|  Owner:  (none)
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 By the way it seems users should be aware that meek-amazon will stop
 working so that they switch to something else, maybe some tweet and/or a
 blog post?

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

Re: [tor-bugs] #24734 [Core Tor/Tor]: Remove the return value of fascist_firewall_choose_address_node()

[Tor Bug Tracker & Wiki]

#24734: Remove the return value of fascist_firewall_choose_address_node()
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, tor-relay, |  implemented
  034-triage-20180328, 034-removed-20180328  |  Actual Points:
Parent ID:  #24403   | Points:  0.5
 Reviewer:  mikeperry|Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Squashed, tested, and merged to master!

 (But next time let's use github so we get travis to run our tests too.)

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

Re: [tor-bugs] #22782 [Obfuscation/Snowflake]: Additional domain fronts for Snowflake rendezvous

[Tor Bug Tracker & Wiki]

#22782: Additional domain fronts for Snowflake rendezvous
---+--
 Reporter:  cypherpunks|  Owner:  (none)
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 Press coverage: https://www.theverge.com/2018/4/30/17304782/amazon-domain-
 fronting-google-discontinued (use new circuit if it shows up 'Forbidden')

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  merge_ready => needs_revision
 * milestone:  Tor: 0.3.4.x-final => Tor: 0.3.2.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] #25869 [Core Tor/Tor]: Proposal: Bandwidth Measurements Document Format

[Tor Bug Tracker & Wiki]

#25869: Proposal: Bandwidth Measurements Document Format
-+-
 Reporter:  juga |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bandwidth, bwauth, scanner, torflow  |  Actual Points:
Parent ID:  #3723| Points:
 Reviewer:  nickm|Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Hi!  I posted a review to tor-dev at

 https://lists.torproject.org/pipermail/tor-dev/2018-May/013141.html

 Good 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] #25937 [Core Tor/Tor]: Move dirvote_act into a periodic callback

[Tor Bug Tracker & Wiki]

#25937: Move dirvote_act into a periodic callback
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-roadmap-subtask, |  Actual Points:
  034-triage-20180328, 034-included-20180328 |
Parent ID:  #25375   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor8
-+-
Changes (by nickm):

 * status:  needs_revision => merge_ready


Comment:

 I added the issue you mentioned (adding a comment), but I don't plan to
 merge until ''after'' #25610 is in -- I don't want conflicts with that
 one, since conflicts with code-movement commits can be  super annoying.

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

Re: [tor-bugs] #21561 [Core Tor/Tor]: CRYPTO_THREADID_set_callback

[Tor Bug Tracker & Wiki]

#21561: CRYPTO_THREADID_set_callback
--+
 Reporter:  pds   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.1-alpha
 Severity:  Normal| Resolution:  invalid
 Keywords:  openssl   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Please reopen if this reoccurs with any released Windows version.

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

Re: [tor-bugs] #25978 [Core Tor/Tor]: UseEntryGuards 0 disables EntryNodes

[Tor Bug Tracker & Wiki]

#25978: UseEntryGuards 0 disables EntryNodes
--+--
 Reporter:  tortrac   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy, doc |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * priority:  Immediate => Medium
 * severity:  Critical => Normal


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

Re: [tor-bugs] #25978 [Core Tor/Tor]: UseEntryGuards 0 disables EntryNodes

[Tor Bug Tracker & Wiki]

#25978: UseEntryGuards 0 disables EntryNodes
--+--
 Reporter:  tortrac   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  easy, doc |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nickm):

 Hey, please don't call people names. That's not the kind of software
 project we want to be.  If you want to discuss the relationship between
 different options, that's cool, but it's not cool to attack people while
 you do it.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by cypherpunks):

 Sure I could send it.

 Replying to [comment:5 atagar]:
 > Thanks cypherpunks! This is definitely a bug on my end. My rough
 understanding from a little searching is that this arises if Nyx
 terminates uncleanly while it's writing to it. Per chance did you issue a
 kill command, ctrl+c, or restart your Raspberry Pi while running Nyx?
 >
 > Regardless, I should fix this on Nyx's side. Maybe there's an integrity
 check I can do to wipe it ourselves if the database gets into this state.
 Juggling other things so it'll probably be a few weeks before I can get to
 this.
 >
 > On a side note if this arises again would you mind emailing me the
 broken sqlite database? I could use it to reproduce the issue on my end.
 Please feel free to pass on this if there's anything sensitive or you feel
 at all uncomfortable sending 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