Re: [tor-bugs] #25857 [Core Tor/Tor]: ::/128 is not the IPv6 equivalent of 0.0.0.0/0

[Tor Bug Tracker & Wiki]

#25857: ::/128 is not the IPv6 equivalent of 0.0.0.0/0
---+
 Reporter:  CTassisF   |  Owner:  atagar
 Type:  defect | Status:  merge_ready
 Priority:  Very Low   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Trivial| Resolution:
 Keywords:  easy doc fast-fix  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * status:  new => merge_ready
 * keywords:  easy doc => easy doc fast-fix
 * milestone:  Tor: unspecified => Tor: 0.3.3.x-final


Comment:

 Thanks, that fixes it.

 I've put this ticket in 0.3.3 because that release is still open to
 documentation fixes.

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

Re: [tor-bugs] #25857 [Core Tor/Tor]: ::/128 is not the IPv6 equivalent of 0.0.0.0/0

[Tor Bug Tracker & Wiki]

#25857: ::/128 is not the IPv6 equivalent of 0.0.0.0/0
--+--
 Reporter:  CTassisF  |  Owner:  atagar
 Type:  defect| Status:  new
 Priority:  Very Low  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:  easy doc  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by CTassisF):

 Sure! I've just attached a quick patch.

 Replying to [comment:2 teor]:
 > Oh, that's embarrassing.
 >
 > Would you like to submit a patch?

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

Re: [tor-bugs] #25857 [Core Tor/Tor]: ::/128 is not the IPv6 equivalent of 0.0.0.0/0

[Tor Bug Tracker & Wiki]

#25857: ::/128 is not the IPv6 equivalent of 0.0.0.0/0
--+--
 Reporter:  CTassisF  |  Owner:  atagar
 Type:  defect| Status:  new
 Priority:  Very Low  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:  easy doc  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by CTassisF):

 * Attachment "tor.1.txt.patch" added.


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

Re: [tor-bugs] #25857 [Core Tor/Tor]: ::/128 is not the IPv6 equivalent of 0.0.0.0/0

[Tor Bug Tracker & Wiki]

#25857: ::/128 is not the IPv6 equivalent of 0.0.0.0/0
--+--
 Reporter:  CTassisF  |  Owner:  atagar
 Type:  defect| Status:  new
 Priority:  Very Low  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:  easy doc  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * keywords:   => easy doc
 * component:  Core Tor/DocTor => Core Tor/Tor
 * milestone:   => Tor: unspecified


Comment:

 Oh, that's embarrassing.

 Would you like to submit a patch?

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

Re: [tor-bugs] #25857 [Core Tor/DocTor]: ::/128 is not the IPv6 equivalent of 0.0.0.0/0 (was: ::/128 is not the IPv6-equivalent of 0.0.0.0/0)

[Tor Bug Tracker & Wiki]

#25857: ::/128 is not the IPv6 equivalent of 0.0.0.0/0
-+
 Reporter:  CTassisF |  Owner:  atagar
 Type:  defect   | Status:  new
 Priority:  Very Low |  Milestone:
Component:  Core Tor/DocTor  |Version:
 Severity:  Trivial  | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by CTassisF):

 * owner:  (none) => atagar
 * component:  - Select a component => Core Tor/DocTor


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25857 [- Select a component]: ::/128 is not the IPv6-equivalent of 0.0.0.0/0

[Tor Bug Tracker & Wiki]

#25857: ::/128 is not the IPv6-equivalent of 0.0.0.0/0
--+
 Reporter:  CTassisF  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Very Low  |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Trivial   |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 The [https://gitweb.torproject.org/tor.git/tree/doc/tor.1.txt#n1837 man
 page of tor] states that "::/128" is the IPv6 equivalent of IPv4's
 "0.0.0.0/0" and that is not correct.

 The equivalent of "0.0.0.0/0" in IPv6 is "::/0"

 The IPv4 equivalent of "::/128" would be "0.0.0.0/32".

 https://en.wikipedia.org/wiki/IPv6_address#Unicast_addresses

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

Re: [tor-bugs] #25511 [Core Tor/Tor]: Expose TZ info on control port for better debugging of time errors

[Tor Bug Tracker & Wiki]

#25511: Expose TZ info on control port for better debugging of time errors
-+-
 Reporter:  nickm|  Owner:  neel
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  roadmap, controller, 034-roadmap-|  Actual Points:
  master, 034-triage-20180328,   |
  034-included-20180328, s8-errors, tor-spec |
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8
-+-

Comment (by neel):

 Assuming you want `ISOTime2`, I have a new patch with the filename
 `b25511-torspec-002.patch`.

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

Re: [tor-bugs] #25511 [Core Tor/Tor]: Expose TZ info on control port for better debugging of time errors

[Tor Bug Tracker & Wiki]

#25511: Expose TZ info on control port for better debugging of time errors
-+-
 Reporter:  nickm|  Owner:  neel
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  roadmap, controller, 034-roadmap-|  Actual Points:
  master, 034-triage-20180328,   |
  034-included-20180328, s8-errors, tor-spec |
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8
-+-
Changes (by neel):

 * Attachment "b25511-torspec-002.patch" added.

 Torspec patch (Revision 1)

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

[tor-bugs] #25856 [Applications/Torbutton]: Remove XUL overlays from Torbutton

[Tor Bug Tracker & Wiki]

#25856: Remove XUL overlays from Torbutton
+
 Reporter:  cypherpunks |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Torbutton  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+
 XUL overlays (and XUL itself, actually) have been discouraged for years,
 and are already being removed outright from Firefox:

 https://bugzilla.mozilla.org/show_bug.cgi?id=1426763
 https://bugzilla.mozilla.org/show_bug.cgi?id=1448162
 https://bugzilla.mozilla.org/show_bug.cgi?id=1449791
 https://bugzilla.mozilla.org/show_bug.cgi?id=1450753

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

Re: [tor-bugs] #25855 [Applications/Tor Browser]: youtube is blocking tor

[Tor Bug Tracker & Wiki]

#25855: youtube is blocking tor
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * owner:  (none) => tbb-team
 * component:  - Select a component => Applications/Tor Browser


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

Re: [tor-bugs] #25855 [- Select a component]: youtube is blocking tor

[Tor Bug Tracker & Wiki]

#25855: youtube is blocking tor
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 hooktube didn't work for me. It reverted back to youtube embed for all of
 the videos I was trying to watch. The embeded video gave the same old
 error static TV look. I got one of these two messages on hooktube:

 Sorry! Both the streams tested for this video had an http error code and
 can't be leeched. Reverting to normal youtube embed.

 Sorry! The streams for this video either weren't found (unfinished
 livestream?) or returned an unusual http code; reverting to normal youtube
 embed.

 The videos I'm trying to watch were livestreams but have ended. youtube-dl
 -F gives the usual list of available formats.

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

Re: [tor-bugs] #23978 [Core Tor/Tor]: Write simulator to evaluate security of Prop247 parameter choices

[Tor Bug Tracker & Wiki]

#23978: Write simulator to evaluate security of Prop247 parameter choices
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery-prop247-experiments  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-

Comment (by mikeperry):

 Some issues I've noticed:
 1. guard.is_targeted should be updated every time we change guards in a
 higher layer
 2. The graphs of G1 look suspicious (high CDF in low timescales for wimpy
 adversaries)
 3. The "none" adversary still takes a long time. Can we have a mode of the
 sim that stops at guard discovery for particularly weak adversaries?

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

Re: [tor-bugs] #6489 [Core Tor/Tor]: Document that clients also have BWRate and BWBurst.

[Tor Bug Tracker & Wiki]

#6489: Document that clients also have BWRate and BWBurst.
---+---
 Reporter:  proper |  Owner:  (none)
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  documentation easy tor-client  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:
---+---
Changes (by teor):

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


Comment:

 I think the man page already documents how these options 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] #25779 [Applications/Tor Browser]: Ship tor in Tor Browser nightly builds for macOS with Rust enabled

[Tor Bug Tracker & Wiki]

#25779: Ship tor in Tor Browser nightly builds for macOS with Rust enabled
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff60-esr, boklm201804,  |  Actual Points:
  TorBrowserTeam201804, GeorgKoppen201804|
Parent ID:  #25220   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * cc: teor (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] #25855 [- Select a component]: youtube is blocking tor

[Tor Bug Tracker & Wiki]

#25855: youtube is blocking tor
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 Solution: Use https://hooktube.com/

 I never had a problem with it to search, watch and download youtube
 videos.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25855 [- Select a component]: youtube is blocking tor

[Tor Bug Tracker & Wiki]

#25855: youtube is blocking tor
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Over the past few weeks, it's been harder to view youtube videos over tor.

 Using the Tor Browser I'm sometimes able to view the first 10 minutes of a
 video and then an error would occur and I get the TV static image and a
 prompt from the torbrowser about allowing the canvas or something.

 With youtube-dl I keep getting ERROR: unable to download video data: HTTP
 Error 403: Forbidden.

 As far as I can tell, popular youtube channel videos aren't getting
 blocked yet.

 What's going on?

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

Re: [tor-bugs] #25511 [Core Tor/Tor]: Expose TZ info on control port for better debugging of time errors

[Tor Bug Tracker & Wiki]

#25511: Expose TZ info on control port for better debugging of time errors
-+-
 Reporter:  nickm|  Owner:  neel
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  roadmap, controller, 034-roadmap-|  Actual Points:
  master, 034-triage-20180328,   |
  034-included-20180328, s8-errors, tor-spec |
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8
-+-
Changes (by catalyst):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:45 neel]:
 > I have a patch for torspec: b25511-torspec-001.patch.
 Thanks! It might be good to say it's specifically the `ISOTime2` because
 that's what we call the `T`-separated version in control-spec.txt.

 I did notice that in control-spec.txt we currently only use `ISOTime2` to
 define `ISOTime2Frac`, and don't actually use plain `ISOTime2` in the
 existing control protocol. Maybe we want to reconsider using `ISOTime`
 (the one with the space, as used in `consensus/valid-after` and similar)
 instead of `ISOTime2` for consistency?

 nickm: do you have any opinions on this?

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

Re: [tor-bugs] #17172 [Community/Relays]: A fast guide to run a Win32 tor relay

[Tor Bug Tracker & Wiki]

#17172: A fast guide to run a Win32 tor relay
--+
 Reporter:  TORques   |  Owner:  Nusenu
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Community/Relays  |Version:
 Severity:  Normal| Resolution:
 Keywords:  Win32 relay tor-docs windows  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * owner:  (none) => Nusenu
 * version:  Tor: unspecified =>
 * component:  Internal Services/Wiki => Community/Relays
 * milestone:  Tor: unspecified =>


Comment:

 Re-assigning this ticket to the relay component.
 Does the tor relay guide have a windows section?

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

Re: [tor-bugs] #20192 [Core Tor/Fallback Scripts]: When outputting potential new fallbacks, blacklist the whitelist

[Tor Bug Tracker & Wiki]

#20192: When outputting potential new fallbacks, blacklist the whitelist
---+--
 Reporter:  teor   |  Owner:  haxxpop
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:  wontfix
 Keywords:  fallback   |  Actual Points:
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:
---+--
Changes (by teor):

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


Comment:

 We don't plan on contacting operators individually 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] #25511 [Core Tor/Tor]: Expose TZ info on control port for better debugging of time errors

[Tor Bug Tracker & Wiki]

#25511: Expose TZ info on control port for better debugging of time errors
-+-
 Reporter:  nickm|  Owner:  neel
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  roadmap, controller, 034-roadmap-|  Actual Points:
  master, 034-triage-20180328,   |
  034-included-20180328, s8-errors, tor-spec |
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8
-+-
Changes (by catalyst):

 * status:  merge_ready => needs_review


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

Re: [tor-bugs] #20876 [Core Tor/Fallback Scripts]: Avoid contacting fallback operators who are unlikely to be accepted

[Tor Bug Tracker & Wiki]

#20876: Avoid contacting fallback operators who are unlikely to be accepted
---+--
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:  wontfix
 Keywords:  fallback   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by teor):

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


Comment:

 We don't need to email operators individually 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] #25511 [Core Tor/Tor]: Expose TZ info on control port for better debugging of time errors

[Tor Bug Tracker & Wiki]

#25511: Expose TZ info on control port for better debugging of time errors
-+-
 Reporter:  nickm|  Owner:  neel
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  roadmap, controller, 034-roadmap-|  Actual Points:
  master, 034-triage-20180328,   |
  034-included-20180328, s8-errors, tor-spec |
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8
-+-

Comment (by neel):

 I have a patch for torspec: b25511-torspec-001.patch.

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

Re: [tor-bugs] #25511 [Core Tor/Tor]: Expose TZ info on control port for better debugging of time errors

[Tor Bug Tracker & Wiki]

#25511: Expose TZ info on control port for better debugging of time errors
-+-
 Reporter:  nickm|  Owner:  neel
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  roadmap, controller, 034-roadmap-|  Actual Points:
  master, 034-triage-20180328,   |
  034-included-20180328, s8-errors, tor-spec |
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8
-+-
Changes (by neel):

 * Attachment "b25511-torspec-001.patch" added.

 Torspec patch (Revision 1)

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

Re: [tor-bugs] #21693 [Core Tor/Tor]: prop224: HS descriptors do wasteful double-base64 encoding

[Tor Bug Tracker & Wiki]

#21693: prop224: HS descriptors do wasteful double-base64 encoding
--+
 Reporter:  asn   |  Owner:  asn
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:  tor-hs, prop224, 031-stretch  |  Actual Points:
Parent ID:| Points:  4
 Reviewer:|Sponsor:  SponsorR-can
--+
Changes (by teor):

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


Comment:

 We deployed code that relies on this encoding, so I don't think we can fix
 this issue without an onion service ersion upgrade.

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

Re: [tor-bugs] #23978 [Core Tor/Tor]: Write simulator to evaluate security of Prop247 parameter choices

[Tor Bug Tracker & Wiki]

#23978: Write simulator to evaluate security of Prop247 parameter choices
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery-prop247-experiments  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-

Comment (by asn):

 Current state of simulator: https://github.com/asn-d6/vanguard_simulator

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

Re: [tor-bugs] #22453 [Core Tor/Tor]: Relays should regularly do a larger bandwidth self-test (was: We should rip out the bandwidth self-test)

[Tor Bug Tracker & Wiki]

#22453: Relays should regularly do a larger bandwidth self-test
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-triage-20180328, |  Actual Points:
  034-removed-20180328   |
Parent ID:  #24499   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:5 teor]:
 > Ok, so should we send AuthDirFastGuarantee*10 (1MB) instead?
 > (Enough to get the Fast flag?)
 >
 > Or AuthDirGuardGuarantee*10 (20MB)?
 > (Enough to get the guard flag?)

 Let's regularly send a bandwidth self-test of AuthDirGuardGuarantee*10
 bytes, but make sure it times out after 30-60 seconds to avoid saturating
 relays on small links.

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

Re: [tor-bugs] #24104 [Core Tor/Tor]: Delay descriptor bandwidth reporting on large relays

[Tor Bug Tracker & Wiki]

#24104: Delay descriptor bandwidth reporting on large relays
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery-stats, chutney-  |  Actual Points:
  wants, bwauth-wants, 034-triage-20180328,  |
  034-removed-20180328   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:2 arma]:
 > I am a fan of "publish a new descriptor for sufficiently-changed
 bandwidth estimates if your uptime is less than 24 hours, else assume that
 things are sufficiently established and the next regularly scheduled
 descriptor update will be enough".

 This seems like a nice simple solution to the issue. Let's make it happen.

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

Re: [tor-bugs] #17036 [Core Tor/Tor]: Report bandwidth more frequently in test networks

[Tor Bug Tracker & Wiki]

#17036: Report bandwidth more frequently in test networks
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:
 Keywords:  SponsorS-deferred tor-testing tor-   |  Actual Points:
  relay  |
Parent ID:  #16386   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * points:  small => 1


Comment:

 Tor should have an option to report bandwidth every N seconds.
 The option should only be allowed in test networks or networks with non-
 default authorities.

 Maybe Tor should automatically report bandwidth more often when the
 consensus interval is lower.

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

Re: [tor-bugs] #25834 [Applications/Tor Browser]: Use compiler dependent spec files for mingw-w64

[Tor Bug Tracker & Wiki]

#25834: Use compiler dependent spec files for mingw-w64
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff60-esr,   |  Actual Points:
  TorBrowserTeam201804R  |
Parent ID:  #24631   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 {{{
 mkdir -p builddir/mingw-w64/mingw-w64-headers32
 }}}
 `32` in 64 bit builds might confuse somebody. The same for `crt` and
 `widl`.
 {{{
 # We don't want to link against msvcrt.dll due to bug 9084.
 [% c("arch") %]-w64-mingw32-g++ -dumpspecs > $distdir/msvcr100.spec
 }}}
 `gcc` is the driver program of GCC suite, and it handles the specs
 according to the docs. (So, if it gives the same result in practice,
 please, use it instead of `g++`.)
 `-dumpspecs` dumps specs for all programs invoked by `gcc`, and the
 version you called is what is installed on host, so `gcc-4.9-all.spec` is
 a better wording than `msvcr100.spec`.
 {{{
 # Linking libgcc against msvcrt is hard-coded...
 sed 's/msvcrt/msvcr100/' -i gcc-[% c("var/gcc_version")
 %]/gcc/config/i386/t-mingw-w32
 }}}
 First, we use `t-mingw-w64`. Second, it has nothing relative to `msvcrt`.
 Obsolete?
 {{{
 # LDFLAGS_FOR_TARGET does not work for some reason. Thus, we take
 # CFLAGS_FOR_TARGET.
 }}}
 Linker doesn't want to parse compiler's option? That's normal.
 {{{
 export CFLAGS_FOR_TARGET="-specs=$distdir/msvcr100.spec -Wl,--nxcompat
 -Wl,--dynamicbase"
 }}}
 Export not all `-Wl` flags? Very weird.
 Do you use this line to pass `-specs` for the new compiler only? It can be
 done by adding `--with-specs=$distdir/msvcr100.spec` to the next line:
 {{{
 gcc-[% c("var/gcc_version") %]/configure --prefix=$distdir --target=[%
 c("arch") %]-w64-mingw32 --disable-multilib --enable-languages=c,c++
 }}}
 but WARNING: you're going to overwrite the default specs of the new
 compiler with `gcc-4.9-all.spec` ones! And with
 {{{
 # Update msvcr100.spec with the compiler we have built (#25834)
 $distdir/bin/[% c("arch") %]-w64-mingw32-g++ -dumpspecs >
 $distdir/msvcr100.spec
 sed 's/msvcrt/msvcr100/' -i $distdir/msvcr100.spec
 }}}
 you just read all the specs of the new compiler (with part of them already
 overwritten) and try to replace the (new/remaining?) `msvcrt`s (do they
 really exist?).
 And what is the reason to update and use `msvcr100.spec` file later (in
 `firefox`)? It has become the default config of your compiler already.
 USUAL DISCLAIMER: reviewed, but not built :)

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

Re: [tor-bugs] #16386 [Core Tor/Chutney]: Chutney generates network with no bandwidth weights

[Tor Bug Tracker & Wiki]

#16386: Chutney generates network with no bandwidth weights
--+---
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:  SponsorS  |  Actual Points:
Parent ID:  #24250| Points:
 Reviewer:|Sponsor:
--+---
Changes (by teor):

 * parent:  #13976 => #24250


Comment:

 #24250 will fix this issue by making relays report 1 as their minimum
 bandwidth.

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

Re: [tor-bugs] #24169 [Core Tor/Tor]: When all consensus bandwidths are zero, should Tor still respect bandwidth weights?

[Tor Bug Tracker & Wiki]

#24169: When all consensus bandwidths are zero, should Tor still respect 
bandwidth
weights?
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, path-selection,  |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #24250   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:   => #24250


Comment:

 #24250 will probably fix this issue by making all relays report 1 as their
 minimum bandwidth

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

Re: [tor-bugs] #25061 [Core Tor/Tor]: Relays consider it a bootstrapping failure if they can't extend for somebody else's circuit

[Tor Bug Tracker & Wiki]

#25061: Relays consider it a bootstrapping failure if they can't extend for
somebody else's circuit
-+-
 Reporter:  arma |  Owner:
 |  catalyst
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  backport-032, 033-must, stability,   |  Actual Points:
  033-triage-20180320, 033-included-20180320,|
  s8-errors, bootstrap   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by catalyst):

 * keywords:
 backport-032, 033-must, stability, 033-triage-20180320,
 033-included-20180320
 =>
 backport-032, 033-must, stability, 033-triage-20180320,
 033-included-20180320, s8-errors, bootstrap
 * sponsor:   => Sponsor8


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

Re: [tor-bugs] #25755 [Community/Outreach]: Choose name for new mailing list tor-lang-es

[Tor Bug Tracker & Wiki]

#25755: Choose name for new mailing list tor-lang-es
+
 Reporter:  ilv |  Owner:  alison
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Community/Outreach  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by ilv):

 Replying to [comment:3 arma]:
 > Replying to [comment:2 ilv]:
 > > I'd like to give some time to discuss the possible name with whomever
 is interested.
 >
 > Sounds great. In that case I'm moving this ticket out of the "please
 make this mailing list" component, so poor qbi doesn't go mad trying to
 figure out which tickets are asking for a list and which tickets aren't
 yet asking for a list. :)
 >
 > > tor-lang-es
 > > tor-spanish (this way we'd avoid possible conflicts for future lists
 such as tor-pt)
 >
 > Out of these two, I would pick the first one. Calling it "spanish" is
 just asking for people to get offended that you didn't want to use their
 own language's word for the language. :)
 >
 > Speaking of language-specific names: what is the intended scope of the
 list? Is it for users? Developers? Journalists? Every possible thing in
 one list so long as the people want to write in español? I ask because if
 it's a general talk list, another option could be tor-talk-es. That name
 might have some baggage because of how many Internet cranks we have
 attracted to tor-talk (which in a sense served its purpose, to keep them
 away from the other more productive lists). But if you have people trying
 to propose bugfixes in español, and users trying to ask usage questions in
 español, and people discussing Facebook's privacy policies in español, all
 on this one list, did you succeed or fail?

 In this case we succeed. The idea is to have a general discussion, in the
 sense of having a space for coordinating efforts, asks questions, announce
 events, etc. The purpose of this is to empower new communities, and for
 that matter I think it would be good to start all together. We could split
 once we have a solid/loud community for a specific language (could be
 years, could be never). I don't think tor-talk-es would be good for this
 because it would merely replicate the current model, and because of its
 current reputation :)

 >
 > > tor-espanol (this could be easier to understand for locals)
 >
 > My only concern here would be what happens when we want to create a tor-
 فارسی list, and whether email tools et al could handle such a thing.

 Good point. I think we should go with tor-lang-es and then see what
 happens.

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

Re: [tor-bugs] #24250 [Core Tor/Tor]: In a private network some relays advertise zero bandwidth-observed

[Tor Bug Tracker & Wiki]

#24250: In a private network some relays advertise zero bandwidth-observed
-+-
 Reporter:  Sebastian|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-backport, 031-backport,  |  Actual Points:
  032-backport, 033-backport,|
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  034-triage-20180328, 034-removed-20180328 =>
 029-backport, 031-backport, 032-backport, 033-backport,
 034-triage-20180328, 034-removed-20180328
 * points:   => 1


Comment:

 Here's one source of this bug:
 * the relay measures its own bandwidth rate in bytes per seconds, then
 divides by 1024 to get kilobytes per second. When the bytes per second
 figure is less than 1024, the result is zero.

 Here's how I suggest we make progress on this issue:
 * fix the truncation bug by always rounding up: make N / 1024 become (N +
 1023)/1024 (we don't need to check for overflow in the addition if it's
 64-bit arithmetic)
 * if we are about to publish a descriptor with 0 bandwidth, work out why,
 and log a diagnostic, then publish a descriptor with 1 bandwidth - this
 fixes a bunch of torflow / tor bugs where they can't handle 0 bandwidths.

 Here are the different diagnostics I can think of:
   * just started up, don't have 24 hours of bandwidth history - info level
   * a tor relay should always be using some bandwidth, so if we end up
 with zero otherwise, we should log a BUG with our uptime, inbound and
 outbound bandwidths, and the length of our bandwidth history

 We should backport the "always publish 1 or greater" fix to 0.2.9 and
 later. Maybe we should backport the diagnostic logging if it's not too
 big.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25854 [Metrics/Relay Search]: Improve advertised/observed bandwidth mouseover text

[Tor Bug Tracker & Wiki]

#25854: Improve advertised/observed bandwidth mouseover text
--+--
 Reporter:  irl   |  Owner:  metrics-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 It should be clear whether this is a sum of in/out or just traffic
 relayed.

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

Re: [tor-bugs] #25842 [Core Tor/Tor]: 'GETINFO exit-policy/full' fails when disconnected

[Tor Bug Tracker & Wiki]

#25842: 'GETINFO exit-policy/full' fails when disconnected
---+
 Reporter:  atagar |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  fast-fix, tor-control  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by dmr):

 Replying to [comment:2 dgoulet]:
 > So `GETINFO fingerprint` returns:
 >
 > {{{551 Not running in server mode}}}
 >
 > ... which is probably what we should do here after discussing this with
 dmr on IRC.

 Oops, to place this discussion into context: dgoulet and I discussed this
 ticket along with behavior for clients, and I caused some miscommunication
 by bringing up too many things at once. His comment above is related to
 client behavior.

 That is tracked instead in:
 * #25852 - tor and control spec
 * #25853 - stem behavior

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

Re: [tor-bugs] #25423 [Core Tor/Stem]: Treat 'ExitRelay 0' as a reject-all policy

[Tor Bug Tracker & Wiki]

#25423: Treat 'ExitRelay 0' as a reject-all policy
---+
 Reporter:  atagar |  Owner:  dmr
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer:  atagar |Sponsor:
---+

Comment (by dmr):

 [comment:6 Quoting dmr]:
 >  1. Failure for `GETINFO exit-policy/full` to return info.
 > [...]
 >
 > I've noticed two circumstances in which the exit-policy is unqueryable:
 > * [...]
 > * tor is configured as a client
 >
 > The former is [...]
 > The latter is persistent, i.e. the client-only configuration ALWAYS
 returns this:
 > {{{
 > >>> GETINFO exit-policy/full
 > 551 router_get_my_routerinfo returned NULL
 > }}}
 >
 > `Controller.get_exit_policy()` has the `default` parameter. Without
 specifying a default, `get_exit_policy()` will raise an exception in these
 cases.

 Tickets filed; handling these scenarios is covered in:
 * #25852 - tor and control spec
 * #25853 - stem behavior

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by dmr):

 Corresponding ticket for behavior in stem: #25853

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25853 [Core Tor/Stem]: Behavior for Controller.get_exit_policy() for tor client

[Tor Bug Tracker & Wiki]

#25853: Behavior for Controller.get_exit_policy() for tor client
---+
 Reporter:  dmr|  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 In #25423 it was noticed that...
 > [...] the client-only configuration ALWAYS returns this:
 > {{{
 > >>> GETINFO exit-policy/full
 > 551 router_get_my_routerinfo returned NULL
 > }}}

 #25852 tracks implementing defined behavior in tor and the control spec to
 return `551` in this scenario.

 This ticket tracks any necessary changes to `stem.control` for
 `Controller.get_exit_policy()` to return the appropriate ExitPolicy
 (perhaps `None`) for tor clients.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25852 [Core Tor/Tor]: GETINFO exit-policy for tor client should return 551

[Tor Bug Tracker & Wiki]

#25852: GETINFO exit-policy for tor client should return 551
--+--
 Reporter:  dmr   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-spec, tor-client
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 In #25423 it was noticed that...
 > [...] the client-only configuration ALWAYS returns this:
 > {{{
 > >>> GETINFO exit-policy/full
 > 551 router_get_my_routerinfo returned NULL
 > }}}

 The control spec didn't specify behavior for this case. For `GETINFO` it
 states:
 {{{
 The server sends a 551 or 552 error on failure.
 }}}
 And more generically describes `551` and `552` as:
 {{{
  551 Internal error
[Something went wrong inside Tor, so that the client's
 request couldn't be fulfilled.]

  552 Unrecognized entity
[A configuration key, a stream ID, circuit ID, event,
 mentioned in the command did not actually exist.]
 }}}


 Both `551` and `552` are a bit odd for this behavior, but the spec doesn't
 have a code that indicates "You asked for everything ok, but I'm not
 operating in that mode right now" (i.e. N/A).

 However, the spec //does// indicate the following for `GETINFO
 fingerprint`:
 {{{
 "fingerprint" -- the contents of the fingerprint file that Tor
   writes as a relay, or a 551 if we're not a relay currently.
   (Added in 0.1.2.3-alpha)
 }}}

 In discussion with dgoulet and atagar over IRC, we agreed it made the most
 sense to follow this precedent.

 dgoulet reports that `GETINFO fingerprint` currently returns:
 {{{
 551 Not running in server mode
 }}}
 The spec notes "Unless specified to have specific contents, the human-
 readable messages in error replies should not be relied upon to match
 those in this document.", so this info is mentioned to facilitate
 consistency.

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

Re: [tor-bugs] #25842 [Core Tor/Tor]: 'GETINFO exit-policy/full' fails when disconnected

[Tor Bug Tracker & Wiki]

#25842: 'GETINFO exit-policy/full' fails when disconnected
---+
 Reporter:  atagar |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  fast-fix, tor-control  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dmr):

 * cc: dmr (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] #25842 [Core Tor/Tor]: 'GETINFO exit-policy/full' fails when disconnected

[Tor Bug Tracker & Wiki]

#25842: 'GETINFO exit-policy/full' fails when disconnected
---+
 Reporter:  atagar |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  fast-fix, tor-control  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by dgoulet):

 So `GETINFO fingerprint` returns:

 {{{551 Not running in server mode}}}

 ... which is probably what we should do here after discussing this with
 dmr on IRC.

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

Re: [tor-bugs] #25834 [Applications/Tor Browser]: Use compiler dependent spec files for mingw-w64

[Tor Bug Tracker & Wiki]

#25834: Use compiler dependent spec files for mingw-w64
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff60-esr,   |  Actual Points:
  TorBrowserTeam201804R  |
Parent ID:  #24631   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:5 gk]:
 > Replying to [comment:4 cypherpunks]:
 > > All this looks bad. Reply if you want to discuss.
 >
 > Just go ahead, we don't like the spec hack either.
 Agreed, if you continue the conversation. It seems easier to make the
 build work with mingw's `--with-default-msvcrt=msvcr100`, but there are
 also questions about the differences between a recommended way of building
 cross-compiler (with specs) and your setup. So, I'll summarize all the
 nits for the whole patched file as a code review (in comments).

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

Re: [tor-bugs] #25511 [Core Tor/Tor]: Expose TZ info on control port for better debugging of time errors

[Tor Bug Tracker & Wiki]

#25511: Expose TZ info on control port for better debugging of time errors
-+-
 Reporter:  nickm|  Owner:  neel
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  roadmap, controller, 034-roadmap-|  Actual Points:
  master, 034-triage-20180328,   |
  034-included-20180328, s8-errors, tor-spec |
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8
-+-

Comment (by neel):

 Replying to [comment:43 catalyst]:
 > Replying to [comment:42 dgoulet]:
 > > Quick note. We can't merge this (or at least release) without a
 control spec change. Would be important to get a control-spec.txt branch
 for this as well.
 > Thanks, I think I agree.
 >
 > neel: would you be willing to work on that spec change?

 Well, yes. I haven't started yet but will get to 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

[tor-bugs] #25851 [Applications/Tor Browser]: TBA - Make sure third-party code is proxy safe

[Tor Bug Tracker & Wiki]

#25851: TBA - Make sure third-party code is proxy safe
-+-
 Reporter:  sysrqb   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-mobile, tbb-proxy-
 Severity:  Normal   |  bypass
Actual Points:   |  Parent ID:  #21863
   Points:   |   Reviewer:
  Sponsor:  Sponsor4 |
-+-
 It looks like `Picasso` (for image download and rendering) create
 connections that aren't proxy safe. There is other third party code that
 does this, as well, but we should never use `leanplum` (telemetry). We
 should audit `httpclientandroidlib` and confirm the connections are
 correctly proxying.

 {{{
 $ git grep -n openConnection\( mobile/android/thirdparty/
 
mobile/android/thirdparty/ch/boye/httpclientandroidlib/conn/ClientConnectionOperator.java:78:
 void openConnection(OperatedClientConnection conn,
 
mobile/android/thirdparty/ch/boye/httpclientandroidlib/impl/conn/DefaultClientConnectionOperator.java:144:
 public void openConnection(
 
mobile/android/thirdparty/ch/boye/httpclientandroidlib/impl/conn/ManagedClientConnectionImpl.java:304:
 this.operator.openConnection(
 mobile/android/thirdparty/com/leanplum/internal/SocketIOClient.java:82:
 HttpURLConnection connection = (HttpURLConnection) url.openConnection();
 mobile/android/thirdparty/com/leanplum/internal/Util.java:540:
 HttpURLConnection urlConnection = (HttpURLConnection)
 url.openConnection();
 mobile/android/thirdparty/com/squareup/picasso/UrlConnectionDownloader.java:46:
 protected HttpURLConnection openConnection(Uri path) throws IOException {
 mobile/android/thirdparty/com/squareup/picasso/UrlConnectionDownloader.java:47:
 HttpURLConnection connection = (HttpURLConnection) new
 URL(path.toString()).openConnection();
 mobile/android/thirdparty/com/squareup/picasso/UrlConnectionDownloader.java:58:
 HttpURLConnection connection = openConnection(uri);
 }}}

 This isn't the only offending method, we should audit these thoroughly.

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

 Replying to [comment:19 cypherpunks]:
 > > Censors will just block the front innocent-app.appspot.com (it's
 already blocked in China FWIW). ¯\_(ツ)_/¯
 >
 > Google blocked by range of IP addresses.

 However, I can front a non-appspot.com domain with another non-appspot.com
 domain. For instance, I can front youtube.com with google.com.

 {{{
 neel@xb2:~ % wget -q -O - --content-on-error -S https://www.google.com/
 --header 'Host: www.youtube.com'
 }}}

 And it fetches YouTube's homepage.

 But this probably won't work for us because we have to use appspot in
 order to be able to front.

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

Re: [tor-bugs] #19077 [Applications/Tor Browser]: Make sure that networking code in sutagent is no problem for OrFox

[Tor Bug Tracker & Wiki]

#19077: Make sure that networking code in sutagent is no problem for OrFox
--+---
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:  #21863| Points:
 Reviewer:|Sponsor:
--+---
Changes (by sysrqb):

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


Comment:

 Mozilla took this out of the tree in mozilla45 [0]. Details [1], if anyone
 cares.

 [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1255527
 [1] https://wiki.mozilla.org/Auto-tools/Projects/SUTAgent

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

Re: [tor-bugs] #24740 [Core Tor/Tor]: Tor launches two requests for authority certificates on first bootstrap

[Tor Bug Tracker & Wiki]

#24740: Tor launches two requests for authority certificates on first bootstrap
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-bootstrap, tor-bandwidth, easy,  |  Actual Points:
  intro, review-group-34, s8-bootstrap   |
Parent ID:   | Points:  0.5
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8-can
-+-
Changes (by catalyst):

 * keywords:  tor-bootstrap, tor-bandwidth, easy, intro, review-group-34 =>
 tor-bootstrap, tor-bandwidth, easy, intro, review-group-34,
 s8-bootstrap


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

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

[Tor Bug Tracker & Wiki]

#24500: Confusing log message "Can't get entropy from getrandom()"
---+
 Reporter:  arma   |  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords:  tor-crypto, s8-errors  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor8
---+
Changes (by catalyst):

 * keywords:  tor-crypto => tor-crypto, s8-errors
 * sponsor:   => Sponsor8


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

Re: [tor-bugs] #25423 [Core Tor/Stem]: Treat 'ExitRelay 0' as a reject-all policy

[Tor Bug Tracker & Wiki]

#25423: Treat 'ExitRelay 0' as a reject-all policy
---+
 Reporter:  atagar |  Owner:  dmr
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer:  atagar |Sponsor:
---+
Changes (by atagar):

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


Comment:

 Oops about the oops. STATUS_SERVER does have what we want but it's
 EXTERNAL_ADDRESS rather than DNS_USELESS. Pushed a change to invalidate
 the cache when our address changes...

 https://gitweb.torproject.org/stem.git/commit/?id=331406c

 Feel free to file another ticket or reopen if I missed something!

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

Re: [tor-bugs] #25834 [Applications/Tor Browser]: Use compiler dependent spec files for mingw-w64

[Tor Bug Tracker & Wiki]

#25834: Use compiler dependent spec files for mingw-w64
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff60-esr,   |  Actual Points:
  TorBrowserTeam201804R  |
Parent ID:  #24631   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:4 cypherpunks]:
 > All this looks bad. Reply if you want to discuss.

 Just go ahead, we don't like the spec hack either.

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

Re: [tor-bugs] #24685 [Applications/Tor Browser]: Lockpad icon doesn't appear and connection is labeled as insecure when loading a PDF from a secure URL

[Tor Bug Tracker & Wiki]

#24685: Lockpad icon doesn't appear and connection is labeled as insecure when
loading a PDF from a secure URL
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * severity:  Normal => Major


Comment:

 If #24309 is merged then this will matter 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] #25834 [Applications/Tor Browser]: Use compiler dependent spec files for mingw-w64

[Tor Bug Tracker & Wiki]

#25834: Use compiler dependent spec files for mingw-w64
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff60-esr,   |  Actual Points:
  TorBrowserTeam201804R  |
Parent ID:  #24631   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 All this looks bad. Reply if you want to discuss.

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

Re: [tor-bugs] #25423 [Core Tor/Stem]: Treat 'ExitRelay 0' as a reject-all policy

[Tor Bug Tracker & Wiki]

#25423: Treat 'ExitRelay 0' as a reject-all policy
---+--
 Reporter:  atagar |  Owner:  dmr
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer:  atagar |Sponsor:
---+--

Comment (by atagar):

 Oh oops, I misread an earlier comment that we **had** a STATUS_SERVER to
 tell us when our address changed. Seems that's not the case. I'll probably
 file another ticket in a bit to request that. In the meantime I'll give
 this some more thought (maybe we'll just add a TTL, like what we do for
 cached addresses).

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

Re: [tor-bugs] #25511 [Core Tor/Tor]: Expose TZ info on control port for better debugging of time errors

[Tor Bug Tracker & Wiki]

#25511: Expose TZ info on control port for better debugging of time errors
-+-
 Reporter:  nickm|  Owner:  neel
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  roadmap, controller, 034-roadmap-|  Actual Points:
  master, 034-triage-20180328,   |
  034-included-20180328, s8-errors, tor-spec |
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8
-+-

Comment (by catalyst):

 Replying to [comment:42 dgoulet]:
 > Quick note. We can't merge this (or at least release) without a control
 spec change. Would be important to get a control-spec.txt branch for this
 as well.
 Thanks, I think I agree.

 neel: would you be willing to work on that spec change?

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

Re: [tor-bugs] #25850 [Applications/Tor Browser]: Eval error on content include via iframe

[Tor Bug Tracker & Wiki]

#25850: Eval error on content include via iframe
--+--
 Reporter:  geb   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:   => tbb-usability-website


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

Re: [tor-bugs] #25850 [Applications/Tor Browser]: Eval error on content include via iframe

[Tor Bug Tracker & Wiki]

#25850: Eval error on content include via iframe
--+--
 Reporter:  geb   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * owner:  (none) => tbb-team
 * component:  - Select a component => Applications/Tor Browser


Comment:

 I tried disabling NoScript and HTTPS-E but no dice. Additionally, I
 started the vanilla Firefox 52 in always private browsing mode and
 actiavted first-party isolation but it still worked.

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

[tor-bugs] #25850 [- Select a component]: Eval error on content include via iframe

[Tor Bug Tracker & Wiki]

#25850: Eval error on content include via iframe
--+
 Reporter:  geb   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Hi,

 https://linc.cnil.fr/une-cartographie-des-outils-et-pratiques-de-
 protection-de-la-vie-privee include
 https://framindmap.org/c/maps/438273/embed?zoom=1 with an iframe.

 On Firefox 52.7.3esr both works fine.

 On TorBrowser 7.5.3,
 - https://framindmap.org/c/maps/438273/embed?zoom=1 works fine
 - https://linc.cnil.fr/une-cartographie-des-outils-et-pratiques-de-
 protection-de-la-vie-privee which try to include
 https://framindmap.org/c/maps/438273/embed?zoom=1 via an iframe does not
 print the content. Eval errors are displayed in the console.

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

Re: [tor-bugs] #25843 [Core Tor/Tor]: Make NumEntryGuards consistent with #271 consensus params

[Tor Bug Tracker & Wiki]

#25843: Make NumEntryGuards consistent with #271 consensus params
--+
 Reporter:  mikeperry |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by asn):

 Replying to [comment:1 mikeperry]:
 > Here's a list of things we're trying to learn from this testing:

 OK, I've been running the above branch for a week or so. Here are the
 things I can answer already:

 

 > 1. How often does the code decide that one of these two primaries is
 "down" when it is not?

 This is the same behavior as single-guard, so not much has changed here.

 Tor doesn't have many false positives here when the network is good, but
 it can have false negatives [i.e. tor keeps on thinking that a guard is
 up, but that guard is overheating and sending DESTROYs to every circuit
 (#25347)].

 When the network is bad, it's a totally different situation. See question
 3.

 > 2. How often does the code prefer one guard over the other? (They should
 be split roughly 50/50 with this patch as-is, unless you get unlucky with
 path restrictions.. does that happen a lot?).

 I think we good here. It's a `smartlist_choose()` in
 `select_entry_guard_for_circuit()`.

 > 3. How often do we decide to use guards other than our two primaries
 with this patch?
 > 4. What circumstances cause us to use guards other than our two
 primaries with this patch?

 This is related to question 1. Usually this can happen when the network is
 bad, and Tor thinks that some guards are down when they are not. There are
 cases where Tor can end up thinking that the primaries are down, and it
 will use the guards below the primaries (i.e. enter the wilderness). I
 tested this manually using iptables and I immediately found #25783. We
 need to fix this bug and re-test this, to see what else appears.

 The iptables command was a simple:
 `iptables -A OUTPUT -d 202.54.1.22 -j DROP`
 where `202.54.1.22` was my top primary guard.

 > 5. Do we use the same two directory guards as our primary guards?

 Yes. We only use our two primary guards for directory guards.

 > 6. Do we ever have microdescriptor shortages or 503 directory busy
 issues with this patch?

 I haven't encountered such a thing yet, but also I haven't looked for it.
 I haven't encountered #21969 either.

 > 7. What happens when we wander into the uncharted "sampled guard"
 territory of prop271?
 > 8. Do our failure modes for the above/other issues ever result in
 complete downtime for the client? (Can we fix that easily?)

 I haven't done enough testing here, but sometimes things work perfectly,
 and some other times Tor gets stuck for a bit and then gets unstuck and
 works fine. In the case of #25783 Tor got stuck for about 6 minutes tho...
 We really need to look into this more.

 > 9. Can the client be induced to spam or otherwise thrash on its guards
 when it thinks one or both are down/unreachable?

 This is #25347. Tor will keep on trying to establish circuits to its
 guards even tho they are overloaded and sending DESTROYs all the time.
 There is no single best approach to solve that problem.

 > 10. How does the vanguard controller behave with this patch?
 >
 > I think asn has some of this information already.

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

Re: [tor-bugs] #25511 [Core Tor/Tor]: Expose TZ info on control port for better debugging of time errors

[Tor Bug Tracker & Wiki]

#25511: Expose TZ info on control port for better debugging of time errors
-+-
 Reporter:  nickm|  Owner:  neel
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  roadmap, controller, 034-roadmap-|  Actual Points:
  master, 034-triage-20180328,   |
  034-included-20180328, s8-errors, tor-spec |
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8
-+-
Changes (by dgoulet):

 * keywords:
 roadmap, controller, 034-roadmap-master, 034-triage-20180328,
 034-included-20180328, s8-errors
 =>
 roadmap, controller, 034-roadmap-master, 034-triage-20180328,
 034-included-20180328, s8-errors, tor-spec


Comment:

 Quick note. We can't merge this (or at least release) without a control
 spec change. Would be important to get a control-spec.txt branch for this
 as well.

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

[tor-bugs] #25849 [Applications/Tor Browser]: Ship tor in Tor Browser nightly builds for Windows with Rust enabled

[Tor Bug Tracker & Wiki]

#25849: Ship tor in Tor Browser nightly builds for Windows with Rust enabled
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-rbm, ff60-esr,
 Severity:  Normal   |  boklm201804, TorBrowserTeam201804
Actual Points:   |  Parent ID:  #25220
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Similar to #25481 we want to start shipping tor with Rust support enabled
 in our nightly builds for Windows.

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

Re: [tor-bugs] #25827 [Metrics/CollecTor]: Adapt CollecTor to changes in metrics-lib 2.3.0

[Tor Bug Tracker & Wiki]

#25827: Adapt CollecTor to changes in metrics-lib 2.3.0
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:  CollecTor 1.6.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

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


Comment:

 Merged, closing. 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] #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):

 > Censors will just block the front innocent-app.appspot.com (it's already
 blocked in China FWIW). ¯\_(ツ)_/¯

 Google blocked by range of IP addresses.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:17 djsf]:
 > https solution: use $WHATEVER.appspot.com (generated name or some
 popular application) instead of google.com to circumvent DNS censorship:
 >
 > wget -q -O - --content-on-error -S https://innocent-app.appsppot.com/
 --header 'Host: snowflake-reg.appspot.com'
 Censors will just block the front `innocent-app.appspot.com` (it's already
 blocked in China FWIW). ¯\_(ツ)_/¯

 And anyways, because of #22782 migrating from Google fronts is a
 necessity. DNS-over-HTTPS with `https://1.1.1.1/dns-query` and
 `https://1.0.0.1/dns-query (fallback in case 1.1.1.1 isn't reachable)`
 (not blocked in China) seems promising tho. So this seems like the best
 time to upgrade with both of those two solutions with the former acting as
 fallback (because 1.1.1.1 is free and a Amazon isn't).

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

 https solution: use $WHATEVER.appspot.com (generated name or some popular
 application) instead of google.com to circumvent DNS censorship:

 wget -q -O - --content-on-error -S https://innocent-app.appsppot.com/
 --header 'Host: snowflake-reg.appspot.com'

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

 still works via plain http

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

Re: [tor-bugs] #25815 [Metrics/Onionoo]: Speed up hourly updater performance

[Tor Bug Tracker & Wiki]

#25815: Speed up hourly updater performance
-+--
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 Replying to [comment:5 karsten]:
 > I tried out switching to Jackson, and it turns out that we can save 30%
 of overall time (for writing details documents). That's almost 4 minutes
 every hour. Sounds like a good idea to me.

 Yes, this is a good idea!  I added a child ticket for this task, which can
 easily be treated independently to possibly additional changes.  All Gson-
 Jackson discussion can be moved there.  A first step for sure.

 I look further and post findings 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

[tor-bugs] #25848 [Metrics/Onionoo]: Replace Gson with Jackson

[Tor Bug Tracker & Wiki]

#25848: Replace Gson with Jackson
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #25815
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 This ticket should take the
 
[https://gitweb.torproject.org/user/karsten/onionoo.git/commit/?h=task-25815=ad9425fd6fae63d2d1da8fc31e5feabba4f71cc9
 proof-of-concept branch] from the parent ticket and replace gson
 thoroughly.
 Steps:
 * remove gson from dependencies
 * adapt existing tests, which check part of the escape/unescape issues
 * look at the possible pitfalls b/c of different escape strategies (cf.
 parent ticket for more)
 * all touched classes should replace string concatenation in log
 statements in a separate commit (a step more towards to Metrics coding
 standards)
 * clean-up proof-of-concept branch to not print stack-traces and the like

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25847 [Webpages/Website]: Update boklm's key for signing Tor Browser builds

[Tor Bug Tracker & Wiki]

#25847: Update boklm's key for signing Tor Browser builds
--+
 Reporter:  boklm |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Until now I have been using a separate key for signing my Tor Browser
 builds (0xE5B81856D0220E4B).

 Starting with the next release, I'm planning to sign them using my normal
 key (0x3E39CEABFC69F6F7), and stop using a separate key.

 I think we can add the new key to the signing-keys page now, and remove
 the old one when the next release is published.
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQIcBAEBCAAGBQJa2HT0AAoJEAe3z9eg+6BiNAMQAK6THBBRAX1Y/c/2JgQ+GsBu
 L31uMyCKdIR6EOpqcBxxBI7/y20D8fSgrtfVOBdxmnbBRNJSnNjHBJYy3SyIa+vG
 3S4bjVjioC6TvWwPJTzy3jERniSHJJGXmYQGa43dtIm0990yz7lb40XMkDx+VeLF
 L3uHx1qYjA13+Qe9EmY3LjewEnGS16PKByRAVMv2ZlBe2Z0gR8nI6ZCaAuR7OIMk
 YaMLbg5FUcFM2xk4Ockkao2vJgbtDeJEqJ4qbB0F019kSpMt4QJV1AF9b8q8wvCf
 As5nlsMcbLOglhl/z4Vv5Jqy9QM6GUIWZlWfRCE/WaMsf9eC5+rMKaYLiJQ71dj7
 SVhy6fi0xKFDXF3FAx+EilclgtWIJfAoXJitMT2MUBOM53njfxup1+1OBDBPKAKK
 xFVquevYnL7K7cs7wVxL4vx66yGuNoOcKt7bd1jSCyJAVSTQW9UU5lyM1aG4VHhE
 x0DjaREo6LpX2Twwhtsc3b9NsBboq9PQK3xETl51x93Xk5CMwM1otTQxhLjOEpUn
 Z8NTgQLbO4ULYlGB3H2yCutdOcZPpiCNmBeQwTrt9wTWRTRy46JZHs6k17DzF+x3
 zmrddIpcLR3GUIbW2Y/8wu4LChxUWv5ykYeI/MBDfQDjYR+PoO8uggOxw3eoTxJC
 Or6lJ5gmM/Bqs+rT3wewiQIcBAEBCAAGBQJa2HT0AAoJEOW4GFbQIg5LNAMP/1wG
 46/0BFI4W6rmxDqLxe/eJbqbCcDJGoorgCfkJHJk10/nkdZa9AUQyuSN7DTb3CR9
 i74EVzn7ZXlYg/We1V9TjyWAyJUiAc/TKpRSxnKF1ojxP3vM4KP/sLAFfQkhwTFY
 mR38YspBcA/0b8+ZCT6ctxKVn6nFLgLzBg7iLhm8o2khDDsFv1T+oPYuUZw2sX35
 7WVOandCs+raV+ERvK5p2hfVhIvdSw4bYVcFSJgNPiT9ik3pe0wDBojt4ccvrPZ6
 BAUka1YLL3nuenIZghaIK74BLJGZrH2JjW1E0lXP3wLGsdrxZcjPvROuTb6QTKcJ
 v+Yuc+g7Ey2gpKeg65zuCc6SSmBrhLaoDpbpw0i3xDc1KWwgSUjUDi/lPdOdmPLM
 TJiMvWc5K/POOWmep5N4w1EuwhKrvYhI8ZMSVbU6D524lRF0dmznrmsxEV/n17v4
 rQErP5JCpF/kM4FYo/lFXyh+B2HWt9herGUwYvzJec173UoF4mjhQ4oTF/8+G+XJ
 KPgn9JvkGmiKLmrXYlfcmLVUAEn0CBnEhVkBAUY9qsH/CikhZOl6xsCHDtoZ0CZY
 zWhxOJXm7vDE/MqhOuAGOimexJ783eQO9QQmvok0KEkIlZ40y7YAfqL+ssxRneoZ
 86WrbIS0GM4nc0ycCMIp5xz7JYVZsLenhJ9LiN9v
 =RHRF
 -END PGP SIGNATURE-
 }}}

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

Re: [tor-bugs] #25843 [Core Tor/Tor]: Make NumEntryGuards consistent with #271 consensus params

[Tor Bug Tracker & Wiki]

#25843: Make NumEntryGuards consistent with #271 consensus params
--+
 Reporter:  mikeperry |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by asn):

 * status:  new => needs_review


Comment:

 Upstream pull request can be found here:
 https://github.com/torproject/tor/pull/57

 Please let me know if this behavior is not right for upstream. I thought
 about it for a bit, and decided that it's a reasonable behavior and
 probably less arbitrary than the previous one. It's always a bit unclear
 what users who set `NumEntryGuards` are thinking, so since we (the devs)
 are thinking of adopting this behavior, it's probably the right one.

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

Re: [tor-bugs] #25846 [Webpages/Website]: Add Arthur's key to https://www.torproject.org/docs/signing-keys.html.en

[Tor Bug Tracker & Wiki]

#25846: Add Arthur's key to https://www.torproject.org/docs/signing-keys.html.en
--+--
 Reporter:  boklm |  Owner:  (none)
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by boklm):

 * status:  new => needs_review


Comment:

 I attached a patch doing that.

 arthuredelstein: can you confirm this is the right key?

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

Re: [tor-bugs] #25846 [Webpages/Website]: Add Arthur's key to https://www.torproject.org/docs/signing-keys.html.en

[Tor Bug Tracker & Wiki]

#25846: Add Arthur's key to https://www.torproject.org/docs/signing-keys.html.en
--+
 Reporter:  boklm |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by boklm):

 * Attachment "0001-Bug-25846-Add-Arthur-s-key-to-the-signing-keys-
 page.patch" added.


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

[tor-bugs] #25846 [Webpages/Website]: Add Arthur's key to https://www.torproject.org/docs/signing-keys.html.en

[Tor Bug Tracker & Wiki]

#25846: Add Arthur's key to https://www.torproject.org/docs/signing-keys.html.en
--+
 Reporter:  boklm |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Arthur is going to sign some of the Tor Browser builds, so we should add
 his key to the signing-keys page.

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

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

[Tor Bug Tracker & Wiki]

#23975: Make node_get_pref_ipv6_orport() check addresses in the right order
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, review-group-29,   |  Actual Points:  2
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #20916   | Points:  1
 Reviewer:  nickm|Sponsor:
 |  SponsorV-can
-+-

Comment (by teor):

 When #25691 merges, we should rebase this branch on top of it, and use the
 new has_preferred_descriptor() function.
 (Or perhaps create a similar function that actually returns some of the
 fields.)

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

 > We’re constantly evolving our network, and as part of a planned software
 update, domain fronting no longer works

 Some google's code diff (insight job)
 {{{
 + if Host == appspot && SNI != appspot { // Let's break it
 }}}
 youtube (or anything else) didn't affected.

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

 [https://www.theverge.com/2018/4/18/17253784/google-domain-fronting-
 discontinued-signal-tor-vpn A Google update just created a big problem for
 anti-censorship tools]

 > Reached by The Verge, Google said the changes were the result of a long-
 planned network update. “Domain fronting has never been a supported
 feature at Google,” a company representative said, “but until recently it
 worked because of a quirk of our software stack. We’re constantly evolving
 our network, and as part of a planned software update, domain fronting no
 longer works. We don’t have any plans to offer it as a feature.”

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

Re: [tor-bugs] #25147 [Applications/Tor Browser]: Backport of fix shipped in Firefox 58.0.1?

[Tor Bug Tracker & Wiki]

#25147: Backport of fix shipped in Firefox 58.0.1?
--+---
 Reporter:  gk|  Owner:  pospeselr
 Type:  task  | Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201804R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by gk):

 So, we are good with this bug then and only #25458 remains? FWIW: I did
 not get any reply about specific ESR52 code that would need to get patched
 which is not in Firefox 58 anymore when asking the Mozilla engineer. I
 think we should not spend more energy on this defense-in-depth, though,
 apart from fixing breakage a la #25458.

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