Re: [tor-bugs] #25844 [Core Tor/Chutney]: Delete DownloadSchedule options in chutney

[Tor Bug Tracker & Wiki]

#25844: Delete DownloadSchedule options in chutney
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

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


Comment:

 Fixed in 57dd950 in 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] #22079 [Community]: Community governance documents

[Tor Bug Tracker & Wiki]

#22079: Community governance documents
---+
 Reporter:  alison |  Owner:  alison
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Community  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by teor):

 Similarly, for the community council vote, the "I would feel uncomfortable
 with this person" option is a "take no action" option. But it has a 1/4
 threshold per individual, rather than 1/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] #22079 [Community]: Community governance documents

[Tor Bug Tracker & Wiki]

#22079: Community governance documents
---+
 Reporter:  alison |  Owner:  alison
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Community  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by catalyst):

 Replying to [comment:19 atagar]:
 > Hi Roger. Sorry, not sure I follow. I read that as saying that enacting
 new policies needs a 2/3 super majority. As you cited those had options to
 reject the policy and keep the status quo.
 I interpret it as enacting a policy effectively requires a 2/3
 supermajority if there is only one proposal (no alternatives) and no
 abstentions.  (Abstentions seem to have the interesting effect of diluting
 reject/no-action votes.)

 For the CoC/SoV votes, I would say the "take no action" alternative was
 the "b. I do not approve of the proposal." option.  Similarly, for the
 membership policy vote, I think the "take no action" option would have
 been "B. I reject the attached 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] #25756 [Core Tor/Tor]: EARLY_CONSENSUS_NOTICE_SKEW of 60 is too strict for some drifting dirauth clocks

[Tor Bug Tracker & Wiki]

#25756: EARLY_CONSENSUS_NOTICE_SKEW of 60 is too strict for some drifting 
dirauth
clocks
-+-
 Reporter:  Dbryrtfbcbhgf|  Owner:
 |  catalyst
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.10
 Severity:  Normal   | Resolution:
 Keywords:  clock-skew, s8-errors, 034-roadmap-  |  Actual Points:
  proposed   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-

Comment (by catalyst):

 https://github.com/tlyu/tor/tree/bug25756 contains some WIP preparatory
 refactoring and new tests.

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

Re: [tor-bugs] #26018 [Applications/Tor Browser]: intl.accept_languages changes when the user changes their OS language

[Tor Bug Tracker & Wiki]

#26018: intl.accept_languages changes when the user changes their OS language
--+--
 Reporter:  igt0  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:  #25703| Points:
 Reviewer:|Sponsor:
--+--

Comment (by igt0):

 Mozilla bug used to track this bug:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1459089

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

Re: [tor-bugs] #26018 [Applications/Tor Browser]: intl.accept_languages changes when the user changes their OS language

[Tor Bug Tracker & Wiki]

#26018: intl.accept_languages changes when the user changes their OS language
--+--
 Reporter:  igt0  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:  #25703| Points:
 Reviewer:|Sponsor:
--+--

Comment (by igt0):

 It leaks even when the user doesn't change the OS locale.

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

Re: [tor-bugs] #12842 [Community/Tor Support]: Helpdesk needs a PGP key to be able to receive encrypted help queries

[Tor Bug Tracker & Wiki]

#12842: Helpdesk needs a PGP key to be able to receive encrypted help queries
---+--
 Reporter:  mrphs  |  Owner:  phoul
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by teor):

 If we still want this feature, we have a schleuder install now.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by saper):

 It's not even that... pacman query shows that MSYS/MinGW come with both
 OpenSSL's preinstalled as we see them - it is not libevent pulling them
 in.

 I need to spend more time on RDP there and figure out compiler/linker
 paths. Even if we ask nicely to upgrade it can always happen in the
 future.

 Maybe we should stop amending PATH to prevent loading of a (newer) DLL.

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

 * priority:  Immediate => Very Low
 * severity:  Critical => Trivial


Comment:

 Ok, figured it out through more work arounds...

 Connections get cut using only 1 Guard with EntryGuards set, but setting
 NumEntryGuards to above 3 works great as intended.  Better in fact than
 UseEntryGuards 0 was doing (better peers).

 Setting NumEntryGuards is the same as what I want.

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

Re: [tor-bugs] #25844 [Core Tor/Chutney]: Delete DownloadSchedule options in chutney (was: Ignore DownloadSchedule deprecation warnings in chutney)

[Tor Bug Tracker & Wiki]

#25844: Delete DownloadSchedule options in chutney
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 We can delete all the download schedule options, because the defaults for
 all the options we use are 0.

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

Re: [tor-bugs] #26011 [Core Tor/Tor]: Alias GETINFO config-can-saveconf to config/can-saveconf

[Tor Bug Tracker & Wiki]

#26011: Alias GETINFO config-can-saveconf to config/can-saveconf
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+--
Changes (by teor):

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


Comment:

 config-can-saveconf is consistent with config-text, so we shouldn't change
 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] #21346 [Core Tor/Tor]: Clients with NoIPv4Traffic should only choose IPv6-supporting Exits

[Tor Bug Tracker & Wiki]

#21346: Clients with NoIPv4Traffic should only choose IPv6-supporting Exits
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, 031-deferred-20170425, |  Actual Points:
  032-unreached  |
Parent ID:  #21311   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Exit selection is called something like choose_good_exit_server().
 Stream attachment is called something like ap_attach_stream().

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

Re: [tor-bugs] #21346 [Core Tor/Tor]: Clients with NoIPv4Traffic should only choose IPv6-supporting Exits

[Tor Bug Tracker & Wiki]

#21346: Clients with NoIPv4Traffic should only choose IPv6-supporting Exits
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, 031-deferred-20170425, |  Actual Points:
  032-unreached  |
Parent ID:  #21311   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by neel):

 Thank You.

 Also, where should I look to make these changes?

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

 Replying to [comment:11 twim]:
 > Replying to [comment:10 dcf]:
 > > I think this AMP cache idea is really viable and can be implemented
 quickly. twim, do you have the time and interest to work on an
 implementation in Snowflake?
 >
 > Yes, I think I can do that.

 That's great. I can devote some time to assistance.

 Do you have the infrastructure you need for testing? It looks like you
 have a way to make your own subdomains. The broker has automatic Let's
 Encrypt certificate support, but it requires you to have ports 443 and 80
 free. If you don't have a spare server set up, I may be able to get you
 one.

 > >  5. In the `<-time.After(time.Second * ClientTimeout)` case, we may
 have to think of some other way to signal a timeout, in case the AMP cache
 doesn't pass the status 502 (`StatusGatewayTimeout`) unmodified.
 >
 > Another idea I got here about it is to always reply with 200, so any
 changes to AMP will less likely break things. Thus we can abstract RPC
 away from HTTP in a way and use different pluggable roundtrippers (like
 POST, AMP). It would make it easier to plug other OSSes.

 Always using 200 for AMP is fine with me. If you need to add another layer
 around the existing JSON, that's fine. I don't want to overhaul the
 existing `/client` behavior though.

 > > (Side note: if AMP provides a way to pass JSON through unmodified
 (maybe the `r` does this?), that would be ideal.)
 > JSON is probably fine if wrapped into  but I haven't test it yet. I
 don't feel like using JSON will be as safe as Base64 in terms of
 survivability against modifications.

 I'm thinking about the [https://www.ampproject.org/docs/fundamentals/spec
 #the-amp-html-format ] block. Perhaps
 we can stuff arbitrary data in there and the AMP cache won't touch it. But
 realistically speaking, base64 in the page body is likely good enough.
 {{{