Re: [tor-bugs] #30921 [Core Tor/Tor]: hs-v3: Close intro circuits when cleaning up the client descriptor cache

[Tor Bug Tracker & Wiki]

#30921: hs-v3: Close intro circuits when cleaning up the client descriptor cache
+
 Reporter:  dgoulet |  Owner:  dgoulet
 Type:  defect  | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, tor-client  |  Actual Points:  0.1
Parent ID:  #28970  | Points:  0.1
 Reviewer:  asn |Sponsor:  Sponsor27-must
+
Changes (by asn):

 * status:  needs_review => needs_revision


Comment:

 Hmm, some questions about this fix:

 - I'm not sure if the identified race condition is the cause of this
 assert. Looking at #28970, there are two asserts and the second one is on
 `hs_ident_intro_circ_is_valid()` which imples that the hs_ident exists but
 is zeroed out. IIUC, this seems to be the reason that we can't find a
 descriptor here, and not a race condition.

 - Just noting that `Regardless of the cause of the assert or not, we
 should always close pending intro circuits when cleaning up a descriptor`,
 seems like a step backwards from #22893. Am I right to say that we need to
 do this anyway so that we maintain our current suboptimal design, and
 there is no way around it as long as we don't do #22893?

 - I now see a bit of code dup between `cache_store_as_client()` and
 `cache_clean_v3_as_client()` perhaps we can tidy it up in one func.

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

Re: [tor-bugs] #30871 [Core Tor/Tor]: circuit_mark_for_close_(): Bug: Duplicate call to circuit_mark_for_close at ../src/feature/hs/hs_service.c:3166 (first at ../src/feature/hs/hs_service.c:2385)

[Tor Bug Tracker & Wiki]

#30871: circuit_mark_for_close_(): Bug: Duplicate call to 
circuit_mark_for_close at
../src/feature/hs/hs_service.c:3166 (first at
../src/feature/hs/hs_service.c:2385)
-+-
 Reporter:  s7r  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.1.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs double-mark 035-backport  |  Actual Points:  0.4
  040-backport 041-backport 041-must |
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
 |  Sponsor27
-+-
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 This looks good to me!

 I don't see the `Bug` log msg in #28970 so this exact bug is probably not
 the cause of it, but perhaps the general class might be related?

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

Re: [tor-bugs] #30649 [Core Tor/Tor]: Every few hours, relays [warn] Received circuit padding stop command for unknown machine.

[Tor Bug Tracker & Wiki]

#30649: Every few hours, relays [warn] Received circuit padding stop command for
unknown machine.
-+-
 Reporter:  teor |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, circuitpadding, wtf-pad,  |  Actual Points:
  041-must   |
Parent ID:   | Points:  1
 Reviewer:  asn  |Sponsor:
 |  Sponsor2
-+-
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 OK, since mike ACKed it I'm moving it to merge_ready.

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

Re: [tor-bugs] #25568 [Core Tor/Tor]: hs: Lookup failure cache when introducing to an intro point

[Tor Bug Tracker & Wiki]

#25568: hs: Lookup failure cache when introducing to an intro point
-+-
 Reporter:  dgoulet  |  Owner:  neel
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  security, tor-hs,|  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:12 neel]:
 > I noticed teor left some comments on my GitHub PR. Teor, I'm sorry if
 you're not done reading it.
 >
 > I made the fixes to the changes file.

 Thanks!

 > Splitting the functions do not make sense as a lot of the code in the
 functions you suggest should be split depend on goto routines, so it would
 be harder to split.

 That's fine, I'll leave it to the reviewer to decide if they want to help
 you split those functions.

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

Re: [tor-bugs] #25568 [Core Tor/Tor]: hs: Lookup failure cache when introducing to an intro point

[Tor Bug Tracker & Wiki]

#25568: hs: Lookup failure cache when introducing to an intro point
-+-
 Reporter:  dgoulet  |  Owner:  neel
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  security, tor-hs,|  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by neel):

 I noticed teor left some comments on my GitHub PR. Teor, I'm sorry if
 you're not done reading it.

 I made the fixes to the changes file.

 Splitting the functions do not make sense as a lot of the code in the
 functions you suggest should be split depend on goto routines, so it would
 be harder to split.

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

Re: [tor-bugs] #29945 [Webpages/Website]: fiscal documents page has missing docs, typos, and wrong labels

[Tor Bug Tracker & Wiki]

#29945: fiscal documents page has missing docs, typos, and wrong labels
--+--
 Reporter:  arma  |  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #29901| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 The second and third problems -- mispelled State several times, and having
 the wrong labels -- remain.

 Should I be filing a ticket somewhere in github instead?

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

Re: [tor-bugs] #29801 [Core Tor/Tor]: Add teor's suggestions for Prop#299 (referring IPv4 or IPv6 based on IP Version Failure Count)

[Tor Bug Tracker & Wiki]

#29801: Add teor's suggestions for Prop#299 (referring IPv4 or IPv6 based on IP
Version Failure Count)
---+--
 Reporter:  neel   |  Owner:  neel
 Type:  enhancement| Status:  needs_revision
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, prop299  |  Actual Points:
Parent ID:  #27491 | Points:
 Reviewer:  nickm  |Sponsor:
---+--

Comment (by neel):

 I have submitted the proposal (the number is 306) to the mailing list.

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

Re: [tor-bugs] #29103 [Core Tor/Fallback Scripts]: Add a licence, readme, and code of conduct to fallback-scripts

[Tor Bug Tracker & Wiki]

#29103: Add a licence, readme, and code of conduct to fallback-scripts
---+--
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback   |  Actual Points:  0.1
Parent ID:  #28793 | Points:  0.1
 Reviewer: |Sponsor:
---+--

Comment (by teor):

 nickm says on IRC:
 {{{
 teor: #29103 looks good to me, but I have a suggestion for the README.  I
 think it would be good for the README to explain who needs this tool and
 who doesn't.
 IOW, that unless you're maintaining Tor or your own tor network, or
 researching tor, you don't need this code
 }}}

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

Re: [tor-bugs] #29103 [Core Tor/Fallback Scripts]: Add a licence, readme, and code of conduct to fallback-scripts

[Tor Bug Tracker & Wiki]

#29103: Add a licence, readme, and code of conduct to fallback-scripts
---+
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  needs_revision
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback   |  Actual Points:  0.1
Parent ID:  #28793 | Points:  0.1
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * status:  needs_review => needs_revision


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

Re: [tor-bugs] #29801 [Core Tor/Tor]: Add teor's suggestions for Prop#299 (referring IPv4 or IPv6 based on IP Version Failure Count)

[Tor Bug Tracker & Wiki]

#29801: Add teor's suggestions for Prop#299 (referring IPv4 or IPv6 based on IP
Version Failure Count)
---+--
 Reporter:  neel   |  Owner:  neel
 Type:  enhancement| Status:  needs_revision
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, prop299  |  Actual Points:
Parent ID:  #27491 | Points:
 Reviewer:  nickm  |Sponsor:
---+--
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:15 neel]:
 > I have a revised proposal based on Comment 11. The torspec PR is here:
 https://github.com/torproject/torspec/pull/86
 >
 > Sorry for the 3-month delay in this, I was **really** busy.

 Thanks for this proposal!

 We review proposals on the tor-dev mailing list, before they are merged to
 the repository:
 https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt#n69

 Please send a copy of the proposal to the list.
 Then wait a week or two for comments.
 Then make any necessary revisions, and re-submit the proposal to the list.

 Once that process is complete, we'll assign your proposal a number, and
 merge it into the torspec repository.
 (It can't be proposal 302, because the most recent proposal is proposal
 305.)
 https://gitweb.torproject.org/torspec.git/tree/proposals

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

Re: [tor-bugs] #29801 [Core Tor/Tor]: Add teor's suggestions for Prop#299 (referring IPv4 or IPv6 based on IP Version Failure Count)

[Tor Bug Tracker & Wiki]

#29801: Add teor's suggestions for Prop#299 (referring IPv4 or IPv6 based on IP
Version Failure Count)
---+--
 Reporter:  neel   |  Owner:  neel
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, prop299  |  Actual Points:
Parent ID:  #27491 | Points:
 Reviewer:  nickm  |Sponsor:
---+--
Changes (by neel):

 * status:  needs_information => needs_review


Comment:

 I have a revised proposal based on Comment 11. The torspec PR is here:
 https://github.com/torproject/torspec/pull/86

 Sorry for the 3-month delay in this, I was **really** busy.

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

Re: [tor-bugs] #29100 [Core Tor/Fallback Scripts]: Update src/app/config/fallback_dirs.inc to ../tor/src/app/config/fallback_dirs.inc post-split

[Tor Bug Tracker & Wiki]

#29100: Update src/app/config/fallback_dirs.inc to
../tor/src/app/config/fallback_dirs.inc post-split
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  needs_revision
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback   |  Actual Points:
Parent ID:  #28793 | Points:
 Reviewer:  nickm  |Sponsor:
---+
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Looks good! I've added a small comment -- please feel free to adjust or
 merge at your discretion.

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

Re: [tor-bugs] #29103 [Core Tor/Fallback Scripts]: Add a licence, readme, and code of conduct to fallback-scripts

[Tor Bug Tracker & Wiki]

#29103: Add a licence, readme, and code of conduct to fallback-scripts
---+--
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback   |  Actual Points:  0.1
Parent ID:  #28793 | Points:  0.1
 Reviewer: |Sponsor:
---+--
Changes (by teor):

 * owner:  (none) => teor
 * status:  new => assigned
 * points:   => 0.1
 * actualpoints:   => 0.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] #29103 [Core Tor/Fallback Scripts]: Add a licence, readme, and code of conduct to fallback-scripts

[Tor Bug Tracker & Wiki]

#29103: Add a licence, readme, and code of conduct to fallback-scripts
---+--
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback   |  Actual Points:  0.1
Parent ID:  #28793 | Points:  0.1
 Reviewer: |Sponsor:
---+--
Changes (by teor):

 * status:  assigned => needs_review


Comment:

 See my pull request:
 https://github.com/torproject/fallback-scripts/pull/5

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

Re: [tor-bugs] #30889 [Core Tor/Tor]: Eliminate some uses of lower-level control protocol output functions

[Tor Bug Tracker & Wiki]

#30889: Eliminate some uses of lower-level control protocol output functions
--+
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  asn-merge |  Actual Points:  3
Parent ID:  #29210| Points:  3
 Reviewer:  nickm |Sponsor:  Sponsor31-can
--+
Changes (by nickm):

 * status:  needs_review => merge_ready
 * keywords:   => asn-merge


Comment:

 This branch LGTM.  I note that the stem test in travis is passing, which
 is a good thing to check with a branch that affects the controller code.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30991 [Core Tor/Tor]: Auto-tabify makefiles? complain about mistabbed makefiles?

[Tor Bug Tracker & Wiki]

#30991: Auto-tabify makefiles? complain about mistabbed makefiles?
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 We have a bunch of lists in our makefile.am and include.am files where we
 intend to use tabs, but sometimes use spaces by mistake.  We should have
 tooling to keep these consistent.  We could either have check-local look
 for mis-tabbed files of this type, or have autostyle automatically fix
 them for us.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30990 [Core Tor/Tor]: checkSpace.pl: clean up our list of types

[Tor Bug Tracker & Wiki]

#30990: checkSpace.pl: clean up our list of types
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 checkSpace.pl has a list of types that are returned from function
 pointers, and uses it so that we don't complain about code like this:
 {{{
   bool (*eq)(const void *a, const void *b);
 }}}

 (Without recognizing that bool is a type, practracker would think that we
 were calling a function named "bool", and complain that we had a space
 after a function call.)

 In their review for #30864, catalyst notes that the current code in
 checkSpace.pl for this is unweildy, and suggests that we use a list
 instead.  I concur.

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

Re: [tor-bugs] #29100 [Core Tor/Fallback Scripts]: Update src/app/config/fallback_dirs.inc to ../tor/src/app/config/fallback_dirs.inc post-split

[Tor Bug Tracker & Wiki]

#29100: Update src/app/config/fallback_dirs.inc to
../tor/src/app/config/fallback_dirs.inc post-split
---+--
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback   |  Actual Points:
Parent ID:  #28793 | Points:
 Reviewer:  nickm  |Sponsor:
---+--
Changes (by teor):

 * cc: asn, dgoulet (removed)
 * reviewer:   => nickm


Comment:

 nickm is happy to review 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] #30277 [Internal Services/Service - jenkins]: amd bionic tor builds fail with an apt-get dependency error

[Tor Bug Tracker & Wiki]

#30277: amd bionic tor builds fail with an apt-get dependency error
-+
 Reporter:  teor |  Owner:  weasel
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - jenkins  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-ci-fail  |  Actual Points:
Parent ID:  #30989   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by teor):

 * parent:   => #30989


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

Re: [tor-bugs] #22029 [Core Tor/Tor]: Allow ed25519 keys to be banned in the approved-routers file

[Tor Bug Tracker & Wiki]

#22029: Allow ed25519 keys to be banned in the approved-routers file
-+-
 Reporter:  teor |  Owner:  neel
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-triage-20180328, |  Actual Points:
  034-removed-20180328   |
Parent ID:   | Points:  1
 Reviewer:  teor |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:66 neel]:
 > What's the status of the code review for the PR? I added it to GitHub
 here: https://github.com/torproject/tor/pull/970 (Same PR as usual)

 Code reviews are usually done within a week or two after the code is
 ready.
 This branch was ready 4 days ago, 2 of those days were weekend days.

 Since it's a complex branch, which I want to split for merging, it might
 take a little longer.

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

Re: [tor-bugs] #22029 [Core Tor/Tor]: Allow ed25519 keys to be banned in the approved-routers file

[Tor Bug Tracker & Wiki]

#22029: Allow ed25519 keys to be banned in the approved-routers file
-+-
 Reporter:  teor |  Owner:  neel
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-triage-20180328, |  Actual Points:
  034-removed-20180328   |
Parent ID:   | Points:  1
 Reviewer:  teor |Sponsor:
-+-

Comment (by neel):

 What's the status of the code review for the PR? I added it to GitHub
 here: https://github.com/torproject/tor/pull/970 (Same PR as usual)

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

Re: [tor-bugs] #25568 [Core Tor/Tor]: hs: Lookup failure cache when introducing to an intro point

[Tor Bug Tracker & Wiki]

#25568: hs: Lookup failure cache when introducing to an intro point
-+-
 Reporter:  dgoulet  |  Owner:  neel
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  security, tor-hs,|  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by neel):

 * status:  assigned => needs_review


Comment:

 Tor PR: https://github.com/torproject/tor/pull/1143
 Torspec PR: https://github.com/torproject/torspec/pull/85

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

Re: [tor-bugs] #25066 [Core Tor/Tor]: Rendezvous points should return signed proof of the established rend point

[Tor Bug Tracker & Wiki]

#25066: Rendezvous points should return signed proof of the established rend 
point
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  needs-proposal,  |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #15516   | Points:  15
 Reviewer:   |Sponsor:
 |  Sponsor27-can
-+-

Comment (by asn):

 The first step here is writing a proposal of how exactly this will work
 and posting it on tor-dev. AFAIK no one is working on this ticket atm.

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

Re: [tor-bugs] #30968 [Core Tor/Tor]: Refactor unit test asserts so they log context

[Tor Bug Tracker & Wiki]

#30968: Refactor unit test asserts so they log context
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  refactor, technical-debt, ipv6,  |  Actual Points:
  tor-dns, sponsor-31-maybe  |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by catalyst):

 * cc: catalyst (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] #30382 [Core Tor/Tor]: Provide control port event for when we are missing v3 client auth for an onion

[Tor Bug Tracker & Wiki]

#30382: Provide control port event for when we are missing v3 client auth for an
onion
-+-
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tbb-usability, hs-auth,  |  Actual Points:
  network-team-roadmap-2019-Q1Q2, tor-spec   |
Parent ID:  #14389   | Points:  6
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-must
-+-

Comment (by mcs):

 Replying to [comment:26 dgoulet]:
 > Apparently (feedback from mcs), the extended errors is sent out properly
 but only after `SocksTimeout`. Most likely, the connection is not properly
 closed when the extended error is set.

 A little more info about this: when we use `SocksTimeout 15`, the correct
 SOCKS error is sent after 30 seconds the first time we try to load the v3
 .onion, but it is sent after 15 seconds the second time we try to load 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] #30919 [Metrics/Statistics]: Performance graphs are missing data from Torperf instances

[Tor Bug Tracker & Wiki]

#30919: Performance graphs are missing data from Torperf instances
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  irl |Sponsor:
+--
Changes (by karsten):

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


Comment:

 Thanks for checking! It's already merged and deployed, so I'm closing the
 ticket 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] #5915 [Core Tor/Tor]: Write patch to make socks handshakes succeed instantly

[Tor Bug Tracker & Wiki]

#5915: Write patch to make socks handshakes succeed instantly
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  needs-proposal tor-client intro  |  Actual Points:
  performance application experiment, tbb-   |
  wants? performance? ux |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * cc: brade, mcs (added)


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

Re: [tor-bugs] #30985 [Internal Services/Tor Sysadmin Team]: Please refresh my PGP key

[Tor Bug Tracker & Wiki]

#30985: Please refresh my PGP key
-+-
 Reporter:  sysrqb   |  Owner:  anarcat
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

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


Comment:

 thanks, done.

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

Re: [tor-bugs] #28942 [Circumvention/Snowflake]: Evaluate pion WebRTC

[Tor Bug Tracker & Wiki]

#28942: Evaluate pion WebRTC
-+---
 Reporter:  backkem  |  Owner:  cohosh
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ex-sponsor-19|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor28-can
-+---

Comment (by cohosh):

 Finished porting the client to pion/webrtc:
 
https://github.com/cohosh/snowflake/commit/6bbb9a4b820f34aef4d45c14acff72374307da5e

 Most of the changes were small, but there were some tricky differences to
 work around:
 - `OnNegotiationNeeded` is no longer supported, but putting the code from
 that callback into a go routine  and calling it immediately after creation
 of the PeerConnection seems to work just fine.
 - By default, something called the
 "[https://godoc.org/github.com/pion/webrtc#SettingEngine.SetTrickle
 trickle method]" is set to false, which means the
 `OnICEGatheringStateChange` callback never gets called (see
 [https://github.com/pion/webrtc/blob/master/icegatherer.go#L262
 icegatherer.go#L262] vs
 [https://github.com/pion/webrtc/blob/master/icegatherer.go#L143
 icegatherer.go#L143]). We get around this by using a SettingEngine
 
[https://github.com/cohosh/snowflake/blob/6bbb9a4b820f34aef4d45c14acff72374307da5e/client/lib/webrtc.go#L157
 here], but it was a bit confusing. The default API should probably have
 isTrickle set to `true` by default.
 - `OnICECandidate` returns a `nil` candidate when gathering is complete.
 This isn't really a problem but I got a silent failure when i didn't check
 for it. It would be nice if this behaviour was documented in the GoDocs.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30989 [Internal Services/Service - jenkins]: intermittent jenkins failures for tor-ci

[Tor Bug Tracker & Wiki]

#30989: intermittent jenkins failures for tor-ci
-+-
 Reporter:  catalyst |  Owner:  weasel
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal |Version:
  Services/Service - jenkins |   Keywords:  tor-ci-fail-sometimes,
 Severity:  Normal   |  jenkins
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 There seem to be intermittent Jenkins failures for some tor-ci-linux-
 master builds, related to timeouts retrieving packages. Some examples are
 below. network-team: please note additional similar failures on this
 ticket when they appear.

 https://jenkins.torproject.org/view/Failed+Unstable/job/tor-ci-linux-
 master/ARCHITECTURE=i386,SUITE=stretch/4022/console
 {{{
 16:24:13 E: Failed to fetch
 
https://mirrors.wikimedia.org/debian/pool/main/p/python2.7/libpython2.7-stdlib_2.7.13-2+deb9u3_i386.deb
 Operation too slow. Less than 10 bytes/sec transferred the last 120
 seconds
 16:24:13 E: Some files failed to download
 16:24:13 run-parts: /home/jenkins/jenkins-tools/slaves/linux/tor-ci-linux-
 master/setup/15-install-build-depends exited with return code 1
 }}}

 https://jenkins.torproject.org/view/Failed+Unstable/job/tor-ci-linux-
 master-expensive-hardening/ARCHITECTURE=amd64,SUITE=buster/2447/console

 {{{
 18:41:41 E: Failed to fetch
 
https://mirrors.wikimedia.org/debian/pool/main/p/python2.7/libpython2.7-minimal_2.7.16-2_amd64.deb
 Could not wait for server fd - select (11: Resource temporarily
 unavailable) [IP: 2620:0:861:1:208:80:154:15 443]
 18:41:41 E: Some files failed to download
 18:41:41 run-parts: /home/jenkins/jenkins-tools/slaves/linux/tor-ci-linux-
 master-expensive-hardening/setup/15-install-build-depends exited with
 return code 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] #30985 [Internal Services/Tor Sysadmin Team]: Please refresh my PGP key

[Tor Bug Tracker & Wiki]

#30985: Please refresh my PGP key
-+-
 Reporter:  sysrqb   |  Owner:  anarcat
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by sysrqb):

 * status:  needs_information => new


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

Re: [tor-bugs] #30985 [Internal Services/Tor Sysadmin Team]: Please refresh my PGP key

[Tor Bug Tracker & Wiki]

#30985: Please refresh my PGP key
-+-
 Reporter:  sysrqb   |  Owner:  anarcat
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by sysrqb):

 * Attachment "0xCB8FC772D1AA1D30" 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] #30985 [Internal Services/Tor Sysadmin Team]: Please refresh my PGP key

[Tor Bug Tracker & Wiki]

#30985: Please refresh my PGP key
-+-
 Reporter:  sysrqb   |  Owner:  anarcat
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 Replying to [comment:2 anarcat]:
 > i can't find a newer copy of that key on the pool.sks-keyservers.net key
 servers. did you upload it there?

 Hrm, okay, I'll go with "option 2".

 >
 > otherwise, it would be more useful to just upload it here directly. and
 you don't need to sign the message - if the key is correctly constructed,
 it should be self-signed anyways.

 Sounds good to me. 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

[tor-bugs] #30988 [Applications/Tor Browser]: No sound

[Tor Bug Tracker & Wiki]

#30988: No sound
-+--
 Reporter:  arkadiy  |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  Applications/Tor Browser
  Version:   |   Severity:  Normal
 Keywords:  audio sound  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 The browser is silent. I tried watching a video through a service below
 and no audio can be heard.

 http://axqzx4s6s54s32yentfqojs3x5i7faxza6xo3ehd4bzzsg2ii4fv2iid.onion/

 8.5.3 (based on Mozilla Firefox 60.7.0esr) (64-bit)

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

Re: [tor-bugs] #30940 [Core Tor/DocTor]: Limit fallback directory DocTor IRC list to 5 relays

[Tor Bug Tracker & Wiki]

#30940: Limit fallback directory DocTor IRC list to 5 relays
-+
 Reporter:  teor |  Owner:  atagar
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Core Tor/DocTor  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by atagar):

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


Comment:

 Hi teor. Yup, yesterday I spotted the stacktrace.
 [https://gitweb.torproject.org/doctor.git/commit/?id=0ae0b8b Fixed].

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

Re: [tor-bugs] #29697 [Internal Services]: archive.tpo is soon running out of space

[Tor Bug Tracker & Wiki]

#29697: archive.tpo is soon running out of space
---+--
 Reporter:  boklm  |  Owner:  boklm
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:
Component:  Internal Services  |Version:
 Severity:  Major  | Resolution:
 Keywords:  budget_needed  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by anarcat):

 awesome nickm, thanks for the clarification. if someone could figure out
 that sync process, it shouldn't be too hard to add a step that uploads the
 goods to IA as well. they support S3 and there's also a commandline python
 thing that can talk to it which we could use, that way we would replicate
 our stuff there. we could simply iterate through the existing archive to
 upload the existing content.

 i'm not familiar with the sync process so, if i could avoid it, i would
 prefer to not have to implement this myself. i'd be happy to delegate the
 IA account credentials to whoever takes on that task, however, and have
 already done so to dcf who did some tests.

 that said, i agree that the IA process is taking slightly too long for us
 to fix the problem in that way right now, so i'll probably go ahead and
 just allocate new hardware for this service so we can move on. it would
 still be nice, however, to hook IA up into the release process somehow.

 who knows how the dist / archive.tpo stuff works anyways?

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

Re: [tor-bugs] #30441 [Circumvention/BridgeDB]: Stop BridgeDB from handing out offline bridges

[Tor Bug Tracker & Wiki]

#30441: Stop BridgeDB from handing out offline bridges
-+-
 Reporter:  phw  |  Owner:  phw
 Type:  defect   | Status:
 |  assigned
 Priority:  Very High|  Milestone:
Component:  Circumvention/BridgeDB   |Version:
 Severity:  Major| Resolution:
 Keywords:  user-feedback, blog, anti-   |  Actual Points:
  censorship-roadmap |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by phw):

 I [https://gitweb.torproject.org/project/bridges/bridgedb-
 admin.git/commit/?id=5a8fe00304aee3df49ebbcbeb16ae3854bda0556 blacklisted
 53 bridges] whose obfs4 port was unreachable. We should also try to reject
 them via the bridge authority because it causes scary log messages to
 appear in the bridges' log file. Hopefully some operators will then get
 back to us.

 Blacklisting these bridges won't make things worse because after
 implementing #28655 we don't hand out these bridges' vanilla line.

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

Re: [tor-bugs] #29697 [Internal Services]: archive.tpo is soon running out of space

[Tor Bug Tracker & Wiki]

#29697: archive.tpo is soon running out of space
---+--
 Reporter:  boklm  |  Owner:  boklm
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:
Component:  Internal Services  |Version:
 Severity:  Major  | Resolution:
 Keywords:  budget_needed  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by nickm):

 Hi!  Anarcat asked me to comment here explaining what we (the network
 team) need.

 As best as I know, the only things that we make that get uploaded to
 archive.tpo are our source distribution tarballs and their accompanying
 signatures.  We should make sure that none of these ever gets lost.  We
 produce 1-4 of these per month, and upload them to dist-
 master.torproject.org, which then syncs them to dist.torproject.org.
 Previously they have been synced to archive.torproject.org automatically.
 We remove them from dist-master when they are sufficiently obsolete.

 The easiest solution for us would be to leave all of our packages in place
 on archive.tpo and do nothing at all.  This may not be feasible for reason
 of disk  space.

 The next easiest solution would be to have some automatic process that
 uploads these tarballs (and their signature files) to archive.org whenever
 they are uploaded to dist.

 If neither of those is possible, we need permissions and instructions for
 archiving these tarballs manually.  These instructions should get folded
 into doc/HACKING/ReleasingTor.md in our git repository, and it would be
 great if they were so simple that a C developer could do them without
 messing up. :)

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

Re: [tor-bugs] #30984 [Core Tor/Tor]: Make a key-value line abstraction to output control replies

[Tor Bug Tracker & Wiki]

#30984: Make a key-value line abstraction to output control replies
--+
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #29210| Points:  5
 Reviewer:|Sponsor:  Sponsor31-can
--+

Comment (by catalyst):

 Replying to [comment:1 nickm]:
 > Could we reuse config_line_t, or is there a mismatch?
 I think it would need to be extended or wrapped to add the numeric result
 code on each line. Some commands like `MAPADDRESS` can have multiple
 result codes in a single response. (This doesn't conform with `control-
 spec.txt` currently, but that's a different problem.) Also some replies
 are one key-value pair per line (e.g., `250-key=value` from `GETCONF`),
 but some contain multiple key-value pairs (e.g., the `ORCONN` async
 reply).

 Also for async events, there's a separate numeric event type code that's
 distinct from the `650` reply code.

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

Re: [tor-bugs] #30912 [Internal Services/Tor Sysadmin Team]: Investigate stunnel outage on crm-ext-01

[Tor Bug Tracker & Wiki]

#30912: Investigate stunnel outage on crm-ext-01
-+-
 Reporter:  peterh   |  Owner:  tpa
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * status:  new => needs_information


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

Re: [tor-bugs] #30912 [Internal Services/Tor Sysadmin Team]: Investigate stunnel outage on crm-ext-01

[Tor Bug Tracker & Wiki]

#30912: Investigate stunnel outage on crm-ext-01
-+-
 Reporter:  peterh   |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 This change is now online:

 {{{
 Notice: /Stage[main]/Roles::Civicrm_ext_2018/Stunnel4::Client[civicrm-
 redis]/Stunnel4::Generic[civicrm-redis]/File[/etc/stunnel/puppet-civicrm-
 redis.conf]/content:
 --- /etc/stunnel/puppet-civicrm-redis.conf  2018-12-04
 21:50:07.091358516 +
 +++ /tmp/puppet-file20190625-4997-sxgs5o2019-06-25
 19:46:34.976126772 +
 @@ -16,7 +16,7 @@
  CAfile = /etc/stunnel/puppet-civicrm-redis-peer.pem

  ; Some debugging stuff useful for troubleshooting
 -debug = notice
 +debug = info
  ; don't use a file, use syslog
  ; output = /var/log/stunnel4/stunnel.log



 }}}

 so we might get more info if stunnel crashes again. Do let us know (here)
 when/if that happens again.

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

Re: [tor-bugs] #28942 [Circumvention/Snowflake]: Evaluate pion WebRTC

[Tor Bug Tracker & Wiki]

#28942: Evaluate pion WebRTC
-+---
 Reporter:  backkem  |  Owner:  cohosh
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ex-sponsor-19|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor28-can
-+---

Comment (by cohosh):

 Replying to [comment:25 backkem]:
 > - As mentioned in the original ticket and the SCTP PR, you can 'detach'
 a data channel to get access to the underlying idiomatic API based on the
 io.ReadWriteCloser.
 Thanks! I replied there but I'm copying the answer here to keep everyone
 in the same loop. While this does solve the problem of how to handle an
 `io.ErrShortBuffer`, it doesn't fix the bug in SCTP. I think we'd still
 prefer to have access to the `OnMessage` callback anyway instead of
 implementing our own readLoop, but depending on how you decide to handle
 the `io.ErrShortBuffer` return in your readLoop we may need to go that
 route.
 > - There are good discussions about alternative signaling/rendezvous
 strategies in https://github.com/libp2p/specs/pull/159 and
 https://github.com/libp2p/go-libp2p-webrtc-direct/issues/14 that may be of
 interest.
 Thanks! This is really interesting, we'll take a look. We have a few
 tickets about alternative signaling as well: #25985 and #25985

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

Re: [tor-bugs] #23111 [Applications/Tor Browser]: A web page is slowing down your browser.

[Tor Bug Tracker & Wiki]

#23111: A web page is slowing down your browser.
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by gk):

 Replying to [comment:8 cypherpunks]:
 > Replying to [comment:7 gk]:
 > > Replying to [comment:6 cypherpunks]:
 > > > Replying to [comment:5 gk]:
 > > > > Replying to [comment:4 cypherpunks]:
 > > > > > Replying to [comment:3 gk]:
 > > > > > > Works for me, as I said, both in Safer and Safest mode. If you
 still see this problem, please reopen the ticket with your OS,
 > > > > > Windows
 > > > > > > security settings,
 > > > > > Safer
 > > > > > > additional browser modifications.
 > > > > > Unmodified both stable and alpha.
 > > > > > > Please, attach a screenshot as well showing the notification
 bar about the slowdown.
 > > > > > Standard yellow bar, nothing special.
 > > > > >
 > > > > > Overloads one core, loading aframe.io...
 > > > >
 > > > > Do you get the yellow bar as well in standard mode?
 > > > No. But it still happily fucks the system when the page is visible.
 (Not 100% CPU, more load on 32-bit version.)
 > > > > If not, which of the prefs we set is causing the problem? (The
 ones in question are: "javascript.options.ion",
 "javascript.options.baselinejit", "javascript.options.native_regexp",
 "media.webaudio.enabled", "mathml.disabled", and
 "gfx.font_rendering.opentype_svg.enabled".
 > > > It could be only additional load by processing scripts from
 aframe.io...
 > > > "media.webaudio.enabled" - seriously?
 > >
 > > Yes, that's part of the prefs we currently set (see: #21601).
 > But it does nothing. How could it be a problem?
 > > But that said it would be still helpful if you could tell us which
 pref is causing the problem (be it by additional load or missing
 optimizations).
 > On Safer it sucks for about 5 min. On Standard, if you disable
 "javascript.options.ion", it sucks for about 30 sec. Further disabling
 "javascript.options.baselinejit" will give you the same result as on
 Safer. No surprise. But WTF with Standard?

 What happens on "standard" without disabling anything but just using
 "standard"? Do you get similar results on your machine by using Firefox
 ESR 60 (see: https://www.mozilla.org/en-US/firefox/organizations/all/ for
 bundles)?

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

Re: [tor-bugs] #30987 [Core Tor/Tor]: [PATCH] Add support for seccomp on powerpc64

[Tor Bug Tracker & Wiki]

#30987: [PATCH] Add support for seccomp on powerpc64
+
 Reporter:  shawnanastasio  |  Owner:  (none)
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor|Version:  Tor: unspecified
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by nickm):

 * status:  new => needs_review
 * milestone:   => Tor: 0.4.2.x-final


Comment:

 Have you tried this out?  Did Tor run correctly with `Sandbox 1` on those
 platforms?

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

Re: [tor-bugs] #30636 [Metrics/Analysis]: Something funky is going in Iran: numbers of relay users flies off to 1M+

[Tor Bug Tracker & Wiki]

#30636: Something funky is going in Iran: numbers of relay users flies off to 
1M+
--+--
 Reporter:  cypherpunks   |  Owner:  metrics-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Analysis  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ir|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by xhdix):

 Only servers that are listed in metrics.torproject.org have problems.
 Even middle-relays
 On the first day, from Iran, I could get the authority file from my
 middle-relay server, but attempting to connect SSH and HTTPS to my server
 received a timeout error in the handshake.

 [[Image(https://i.imgur.com/fxz4eEl.jpg,100%)]]

 [[Image(https://i.imgur.com/uSLA0GT.jpg,100%)]]

 [[Image(https://i.imgur.com/uP5lcML.jpg,100%)]]


 Fall down:
 [[Image(https://metrics.torproject.org/userstats-relay-
 country.png?start=2019-05-13&end=2019-06-25&country=ir&events=off,100%)]]

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

Re: [tor-bugs] #30987 [Core Tor/Tor]: [PATCH] Add support for seccomp on powerpc64

[Tor Bug Tracker & Wiki]

#30987: [PATCH] Add support for seccomp on powerpc64
+--
 Reporter:  shawnanastasio  |  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Tor|Version:  Tor: unspecified
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by shawnanastasio):

 * Attachment "0001-Add-support-for-seccomp-on-powerpc64.patch" added.

 patch file

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

[tor-bugs] #30987 [Core Tor/Tor]: [PATCH] Add support for seccomp on powerpc64

[Tor Bug Tracker & Wiki]

#30987: [PATCH] Add support for seccomp on powerpc64
--+--
 Reporter:  shawnanastasio|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Component:  Core Tor/Tor
  Version:  Tor: unspecified  |   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 Attached is a small patch to enable support for building tor with seccomp
 on the ppc64 and ppc64le architectures.

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

Re: [tor-bugs] #30985 [Internal Services/Tor Sysadmin Team]: Please refresh my PGP key

[Tor Bug Tracker & Wiki]

#30985: Please refresh my PGP key
-+-
 Reporter:  sysrqb   |  Owner:  anarcat
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * status:  assigned => needs_information


Comment:

 i can't find a newer copy of that key on the pool.sks-keyservers.net key
 servers. did you upload it there?

 otherwise, it would be more useful to just upload it here directly. and
 you don't need to sign the message - if the key is correctly constructed,
 it should be self-signed anyways.

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

Re: [tor-bugs] #30985 [Internal Services/Tor Sysadmin Team]: Please refresh my PGP key

[Tor Bug Tracker & Wiki]

#30985: Please refresh my PGP key
-+-
 Reporter:  sysrqb   |  Owner:  anarcat
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * status:  new => assigned
 * owner:  tpa => anarcat


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

Re: [tor-bugs] #30970 [Applications/Tor Browser]: Different window borders in XFCE can lead to different, not rounded window sizes

[Tor Bug Tracker & Wiki]

#30970: Different window borders in XFCE can lead to different, not rounded 
window
sizes
---+--
 Reporter:  gk |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-fingerprinting-resolution  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by Thorin):

 #30625#comment:4 - system DPI settings can affect new window sizing
 (excuse my ignorance if this is not applicable to the theme)

 #27845 - shows that different desktop environments, themes, density can
 alter chrome elements (paddings, margins etc): in this case the bookmarks
 toolbar, but entirely plausible this also affects other areas. Do you have
 the bookmark toolbar showing?

 ---

 As for letterboxing sometimes (it's a race) not kicking in on first window
 (on first firefox.exe run), I think there might be a bugzilla on this. But
 Tor Browser on first open does not load any web content, and letterboxing
 should be available for any subsequent tabs and new windows. There is also
 https://bugzilla.mozilla.org/show_bug.cgi?id=1555815 for letterboxing to
 not apply to about: pages

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

Re: [tor-bugs] #30984 [Core Tor/Tor]: Make a key-value line abstraction to output control replies

[Tor Bug Tracker & Wiki]

#30984: Make a key-value line abstraction to output control replies
--+
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #29210| Points:  5
 Reviewer:|Sponsor:  Sponsor31-can
--+

Comment (by nickm):

 Could we reuse config_line_t, or is there a mismatch?

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

Re: [tor-bugs] #30889 [Core Tor/Tor]: Eliminate some uses of lower-level control protocol output functions

[Tor Bug Tracker & Wiki]

#30889: Eliminate some uses of lower-level control protocol output functions
--+
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  3
Parent ID:  #29210| Points:  3
 Reviewer:  nickm |Sponsor:  Sponsor31-can
--+
Changes (by nickm):

 * reviewer:   => nickm


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

[tor-bugs] #30986 [Circumvention]: Understand the "long tail" of unclassifiable network traffic

[Tor Bug Tracker & Wiki]

#30986: Understand the "long tail" of unclassifiable network traffic
+--
 Reporter:  phw |  Owner:  phw
 Type:  project | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Circumvention   |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:  #29285
   Points:  5   |   Reviewer:
  Sponsor:  Sponsor28-must  |
+--
 The obfs family of obfuscation protocols strives to "look like nothing"
 and falls into the long tail of network traffic that is meant to be
 unclassifiable. That is, if an ISP is monitoring its uplink, it shouldn't
 be able to figure out that one of its users is talking obfs4 to a Tor
 bridge. Instead, the obfs4 connection should show up as "unknown" in the
 log files.

 We know next to nothing about this long tail that the obfs family hides
 in. What fraction of flows does it constitute? What fraction of bytes?
 What kind of protocols and implementations are difficult to classify? How
 does the long tail differ across uplinks?

 Over at #29285 we're brainstorming features for obfs4's successor but
 before moving forward with obfs5, we should get a better understanding of
 this long tail because it allows us to make informed design decisions.
 Packet traces from the [http://mawi.wide.ad.jp/mawi/ WIDE backbone] is one
 of the data sets that may be helpful here.

 Let's use this ticket to track progress and collect insights.

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

Re: [tor-bugs] #30368 [Circumvention/Snowflake]: Run some tests to check reachability of snowflake proxies

[Tor Bug Tracker & Wiki]

#30368: Run some tests to check reachability of snowflake proxies
-+---
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  task | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  anti-censorship-roadmap  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor28-can
-+---
Changes (by cohosh):

 * status:  assigned => accepted


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

Re: [tor-bugs] #28942 [Circumvention/Snowflake]: Evaluate pion WebRTC

[Tor Bug Tracker & Wiki]

#28942: Evaluate pion WebRTC
-+---
 Reporter:  backkem  |  Owner:  cohosh
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ex-sponsor-19|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor28-can
-+---
Changes (by cohosh):

 * status:  assigned => accepted


Comment:

 Moving tickets I'm currently working on to "accepted"

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

Re: [tor-bugs] #29206 [Circumvention/Snowflake]: New design for client -- server protocol for Snowflake

[Tor Bug Tracker & Wiki]

#29206: New design for client -- server protocol for Snowflake
-+-
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  task | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ex-sponsor-19, anti-censorship-  |  Actual Points:
  roadmap|
Parent ID:   | Points:  6
 Reviewer:  dcf  |Sponsor:
 |  Sponsor28-must
-+-

Comment (by cohosh):

 Replying to [comment:17 dcf]:
 > Replying to [comment:13 cohosh]:
 > > I'm going to ask for an incremental review on this one, mostly just to
 get another pair of eyes on what I've done and my next steps before I sink
 more time into going possibly the wrong direction:
 https://github.com/cohosh/snowflake/compare/sequencing
 >
 Thanks for the feedback! I've addressed most of the feedback so far here:
 https://github.com/cohosh/snowflake/tree/sequencing
 > The fields would be better as `uint32`, because the size of `int`
 [https://golang.org/ref/spec#Numeric_types may vary] (though I think you
 handled it correctly by always specifying 32 bits in serialization
 functions). `length` may be better as `uint16`; that's plenty for one call
 to `Write` and it avoids the risk that an implementation will try to
 buffer 4 GB in memory.
 Fixed in
 
[https://github.com/cohosh/snowflake/commit/c102894bb903857061e7705e9525612eb9a99b4b
 c102894]
 >
 > IMO `length` should be ''exclusive'' of the header size. Otherwise you
 have to define what it means if `length` < 12. (I believe the current code
 doesn't work in this case because `header.length - snowflakeHeaderLen`
 underflows.) The packets sent by `sendAck` should have `length` = 0.
 >
 Fixed in
 
[https://github.com/cohosh/snowflake/commit/02bfa1b4611db39a99379eefd29d569563490a0a
 02bfa1b]
 > Big-endian is more usual for network protocols.
 >
 Fixed in
 
[https://github.com/cohosh/snowflake/commit/7566cbc9e3d289a901d717e2ed5bc10a335915d7
 7566cb]
 > I'm not sure about the implementation of `Read`:
 > I would prefer to start with an implementation of `Read` that is
 simpler, if less efficient. I am picturing something like this [...]
 I like this implementation a lot more. Fixed in
 
[https://github.com/cohosh/snowflake/commit/b6fb987ba9aca02c6740231df6c9db60b68993a6
 b6fb987] and
 
[https://github.com/cohosh/snowflake/commit/9c1b12f7c645e0a8a95199190d89b84ed677e3f8
 9c1b12f]

 I'm going to start on implementing fixed size send windows and cleaning up
 the unit tests a bit.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30985 [Internal Services/Tor Sysadmin Team]: Please refresh my PGP key

[Tor Bug Tracker & Wiki]

#30985: Please refresh my PGP key
-+-
 Reporter:  sysrqb   |  Owner:  tpa
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Hi,

 I have new subkeys. Please refresh my key in the keyring. Thanks!

 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 Signed for Trac Tue Jun 25 17:20:32 UTC 2019

 $ gpg -k 0xCB8FC772D1AA1D30
 pub   rsa4096/0xCB8FC772D1AA1D30 2014-06-26 [SC] [expires: 2019-12-18]
   Key fingerprint = CE17 8262 4600 EE98 764C  6D9C CB8F C772 D1AA 1D30
 uid   [ unknown] Matthew Finkel 
 uid   [ unknown] Matthew Finkel 
 uid   [ unknown] Matthew Finkel 
 uid   [ unknown] Matthew Finkel 
 sub   rsa4096/0x1A3DF1597131E052 2019-06-25 [S] [expires: 2019-12-22]
 sub   rsa4096/0x3EA7385D6E4828BB 2019-06-25 [E] [expires: 2019-12-22]
 sub   rsa4096/0xBEB48FEB9284DB98 2019-06-25 [A] [expires: 2019-12-22]

 .
 -BEGIN PGP SIGNATURE-

 iQIzBAEBCgAdFiEEfuI2zd1pZi7CD3JdGj3xWXEx4FIFAl0SV/wACgkQGj3xWXEx
 4FK4TA/+KYHmeDfAhjJsjfAke3lfoUlolrEo/09Zil4fkeQoEFIBOpbD5cxnR2Kf
 X8FAJwFJ8LM6Xnyj1GJ5ThpUR0USx4F2lc5Rr5JSeJml5HMs7oXzQb5uDidKKW2Y
 Pbi70HSV7iyvxCrS3r4fulOww4JQGQ0FpJtgtEvRrpNxJqwWopkZ8WHIW3VLA27B
 TSCH2bQe2sYfbSsgyHLBPoXPKZX9A8cH9AUa7pgOYDOLnVLpS/h4ebsEwzygSu79
 waAW+SJtG2Vsj+IQbQfIfFBb4UYzQiPU1IwFDjUyGvoJFNzED4t4RpzuaGwoYyEn
 MicNxz4bkbNhn0aArQAaSGFDAtHXoAEz+BULzjv7LQvaJqdMmKaYK4xGDsj2DT8c
 0CfVz+obE1HuedUBl057QrHPsZSrBN8mv1ff/hYpLIXIVRVETyPud7PeudjuYabM
 goD+rXJo87PM9w8GdDLbszZxkZkG12lCDzj80i1LHBdpxyITs+9FhLoAgqiisM9V
 OmbkVtR0GCiPnRJmuFA1cD8do4k9eNn0i2LHPojsoIO4/q/r1GrtH8jjSoa25/sj
 Sbj8sQIyGQGvJP+780k+6dKdO0ZWj3S3bfx99m/cPzHojQQ3IitYD/6kn6l+p3pD
 UehyJVdstmAR2Uvz99+WjHpImHuteWMfJ8faWY3ASfX0qiXXB6o=
 =McVT
 -END PGP SIGNATURE-
 }}}

 (yes, this is self-signed. sorry)

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

Re: [tor-bugs] #30935 [Core Tor/Tor]: Move variable definition code out of confparse.c, and refactor

[Tor Bug Tracker & Wiki]

#30935: Move variable definition code out of confparse.c, and refactor
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  0.5
Parent ID:  #29211| Points:  1
 Reviewer:  catalyst  |Sponsor:  Sponsor31-can
--+

Comment (by nickm):

 Here's an overview of the commits in this branch.

 >  Move config_var_t info conftypes.h

 Pure code movement.

 >  Move responsibility for config var macros

 Refactors the macros that we have used to create config_var_t, and reduces
 code duplication.

 Previously the macros used to define variables were redefined in every
 module that needed them; now they are derived from a common source.  This
 makes them easier to change and refactor.

 This commit also moves code only used for test builds into a new
 "conftesting.h" header.

 >  Add a "flags" member to config_var_t

 Add an (unused) flags member, and makes corresponding adjustments to the
 macros.

 >  Extend macros to allow flag arguments.

 Add a flags argument to the variable-definition macros.

 >  Turn several properties of types or variables into flags.
 >  Make "invisibility" and "undumpability" properties of variables.

 These two commits are the bigger refactorings of this branch: they remove
 all the places in config or confparse that had previously tried to do
 manual inspection of a variable's type or names.  To follow OO principles,
 we should turn these checks and inspections into properties of the types
 or variables themselves.

 >  Refactor handling of TestingTorNetwork

 The TestingTorNetwork option overrides the defaults for a bunch of other
 options.  Its previous implementation was a nasty kludge that included a
 bunch of duplicated code, and involved overwriting the "initval" field of
 a bunch of config_var_t objects.

 This new implementation should be much cleaner and easier to understand.
 It works by modifying the initially constructed or_options_t object
 whenever any code ask for an "initialized to defaults" object.

 >  Make config_var and config_fmt const.

 Thanks to the previous commit, we can now make more object const -- and
 should.

 >  Move confparse.ch into lib/confmgt.

 Code movement and header renaming.  Once we moved the responsibility for
 handling routerset_t out of confparse.c, we no longer need confparse.c to
 be at a higher level than src/core.  This patch lowers 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] #30500 [Circumvention/Censorship analysis]: Can the GFW still do DPI for "new" vanilla Tor?

[Tor Bug Tracker & Wiki]

#30500: Can the GFW still do DPI for "new" vanilla Tor?
---+--
 Reporter:  phw|  Owner:  (none)
 Type:  task   | Status:  assigned
 Priority:  Low|  Milestone:
Component:  Circumvention/Censorship analysis  |Version:
 Severity:  Normal | Resolution:
 Keywords:  gfw, china |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by phw):

 Replying to [comment:4 arma]:
 > Replying to [comment:2 phw]:
 > > The research team I've been in touch with could not trigger active
 probing with tcis as the client and a netcat listener as the server. I
 suggested to use a bridge instead of a netcat listener, which resulted in
 active probing. This suggests that the GFW is also considering some
 information that's sent from the server to the client.
 >
 > It would be interesting, for posterity, for somebody (maybe somebody in
 this research team you speak of) to poke at the server-side of the
 handshake and figure out what exactly they're relying on to decide that
 it's a Tor bridge.
 [[br]]
 I encouraged them to have a look at 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] #23840 [Community/Tor Support]: Google's reCAPTCHA fails 100%

[Tor Bug Tracker & Wiki]

#23840: Google's reCAPTCHA fails 100%
+--
 Reporter:  cypherpunks |  Owner:  hiro
 Type:  defect  | Status:  reopened
 Priority:  Immediate   |  Milestone:
Component:  Community/Tor Support   |Version:
 Severity:  Blocker | Resolution:
 Keywords:  cloudflare,google,captcha,noscript  |  Actual Points:
Parent ID:  #18361  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by cypherpunks):

 Shouldn't we try it the other way around? Big show, blog, media, whatever,
 telling that Google behaves wrongfully by harassing people to solve those
 stupid captchas everywhere and give tons of personal data to Google by
 doing so?

 Furthermore this is clearly a violation of the European Data Protection
 Directive (GDPR), i.e. illegal in the EU, where Google makes much
 business. Not that this directive would protect any data, but to accuse
 Google to violate it, which they do, could help (Article 6 requires the
 prior and free permission for each single data set to collect, use and
 forward personal data. IP address, browser fingerprint, cookies, much more
 than this tracking all that is personal data).

 Someone with the necessary publicity to be heard should report that to the
 public.

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

Re: [tor-bugs] #29210 [Core Tor/Tor]: Distribute control.c functionality across various modules

[Tor Bug Tracker & Wiki]

#29210: Distribute control.c functionality across various modules
--+
 Reporter:  nickm |  Owner:  catalyst
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  10
 Reviewer:|Sponsor:  Sponsor31-can
--+

Comment (by catalyst):

 After #30889, there are no remaining uses of
 `connection_write_str_to_buf()` or `connection_printf_to_buf()` outside of
 `control_proto.c` apart from a specialized protocol error message that is
 output by `connection_control_process_inbuf()`. That error message doesn't
 conform to the `nnn Text` format in `control-spec.txt`.

 #30984 will add a key-value abstraction for control replies that should
 take care of most of the remaining controller-related uses of
 `connection_buf_add()` Maybe the async reply stuff will need a separate
 ticket.

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

Re: [tor-bugs] #25066 [Core Tor/Tor]: Rendezvous points should return signed proof of the established rend point

[Tor Bug Tracker & Wiki]

#25066: Rendezvous points should return signed proof of the established rend 
point
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  needs-proposal,  |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #15516   | Points:  15
 Reviewer:   |Sponsor:
 |  Sponsor27-can
-+-

Comment (by cypherbits):

 I think this a bug on the original design that should have been addressed
 on the onion service v3 proposal and implementation.

 Before making anything new to prevent DoS like proposal 305 we should have
 implemented this... because it is a defect on the original design. This,
 itself, will make DoS harder.

 I hope version 0.4.3 can implement 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] #30914 [Core Tor/Tor]: Move struct manipulation code out of confparse.c

[Tor Bug Tracker & Wiki]

#30914: Move struct manipulation code out of confparse.c
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  1
Parent ID:  #29211| Points:  1
 Reviewer:  catalyst  |Sponsor:  Sponsor31-can
--+

Comment (by nickm):

 >  Partially port routerset to being a full-fledged config type again.

 This patch introduces a new "routerset_type_defn" type definition for use
 with typed_var_t, and uses it in confparse.c.  (Recall that routerset_t is
 not implemented in type_defs.c because it is defined in a higher-level
 module.)  The type is still treated as a special case in the confparse.c,
 but that will get fixed in a later commit.

 >  Add new "struct_var_" functions to manipulate struct fields.

 This is the main new abstraction of this branch.  It adds a wrapper around
 typed_var_* to work with fields within structures, rather than general
 pointers.  This new type is struct_var_t -- it can describe the type of a
 member either as a config_type_t enum, or as a var_type_def_t pointer.

 >  Port confparse to use struct_var in place of typed_var.

 This commit changes the relevant elements of config_var_t to use
 struct_var_t in place of a raw (type,offset) pair, and changes the rest of
 confparse.c to act accordingly.

 >  Use struct_magic_decl to verify magic numbers in config objects
 >  Use struct_var_{copy,eq} in confparse.c.
 >  Use structvar to find the types for config vars.

 The above three commits port confparse.c and config.c to use struct_var_t
 in more places.

 >  Add a function to make sure all values in a config object are ok
 >  A few more test cases and unreachable lines

 This improves test coverage, and exercises the new function introduced
 previously.

 >  changes file for ticket 30914

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30984 [Core Tor/Tor]: Make a key-value line abstraction to output control replies

[Tor Bug Tracker & Wiki]

#30984: Make a key-value line abstraction to output control replies
---+
 Reporter:  catalyst   |  Owner:  catalyst
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #29210
   Points:  5  |   Reviewer:
  Sponsor:  Sponsor31-can  |
---+
 A few controller commands still use `connection_buf_add()` or similar low-
 level functions after constructing a list of reply lines. Almost all of
 these are key-value pairs. Create a new abstraction to output these,
 including by automatically including the correct separator character
 between the numeric code and the rest of the line.

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

Re: [tor-bugs] #30864 [Core Tor/Tor]: Move variable manipulation code out of confparse.c

[Tor Bug Tracker & Wiki]

#30864: Move variable manipulation code out of confparse.c
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  2.5
Parent ID:  #29211| Points:  1
 Reviewer:  catalyst  |Sponsor:  Sponsor31-can
--+

Comment (by nickm):

 Here is an overview of the commits in this branch:

 >  checkSpace.pl:  Allow 'bool' before a space and an open-paren
 >  Start moving types that will be used for config vars to lib/conf
 >  Move unit-parsing code to src/lib/confmgt
 >  Add a function to append an existing line to a config line list.

 These are preliminary refactoring, code movement, and cleanup commits to
 prepare the code for the next commit.

 >  Add a "typed_var" abstraction to implement lvalue access in C.

 This is the most important commit in the patch: it extracts code from
 confparse.c and moves it to lib/confmgt.

 >  Further clarify our clarification about the type of POSINT
 >  Add unit tests for the unitparse.c module.

 These are leftover clarifications and coverage fixes from #30893.

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

Re: [tor-bugs] #30889 [Core Tor/Tor]: Eliminate some uses of lower-level control protocol output functions

[Tor Bug Tracker & Wiki]

#30889: Eliminate some uses of lower-level control protocol output functions
--+
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  3
Parent ID:  #29210| Points:  3
 Reviewer:|Sponsor:  Sponsor31-can
--+
Changes (by catalyst):

 * status:  accepted => needs_review
 * actualpoints:   => 3


Comment:

 Pull request in https://github.com/torproject/tor/pull/1142

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30983 [Applications]: http-header Leak

[Tor Bug Tracker & Wiki]

#30983: http-header Leak
---+--
 Reporter:  cypherpunks|  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Very High  |  Component:  Applications
  Version:  Tor: unspecified   |   Severity:  Critical
 Keywords:  http-header, leak  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 The http-header is leaked once another software but Torbrowser is used
 (e.g. a messenger, a FTP-program, subversion...).

 The http-header anonymization thus should be implemented in Tor, not in
 Torbrowser.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30982 [Applications/TorBirdy]: Torbirdy preset keyserver

[Tor Bug Tracker & Wiki]

#30982: Torbirdy preset keyserver
-+---
 Reporter:  cypherpunks  |  Owner:  sukhbir
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Component:  Applications/TorBirdy
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
 The preset keyserver must be removed. Nowhere can keys be manipulated more
 easy than on a key server. Through the preset the contact to a distinct
 keyserver is mandatory, which leads to identification of Torbirdy users,
 see Fingerprint, #30981, and a single point of attack.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30981 [Applications]: Torbrowser/Torbirdy insecure settings

[Tor Bug Tracker & Wiki]

#30981: Torbrowser/Torbirdy insecure settings
---+--
 Reporter:  cypherpunks|  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  High   |  Component:  Applications
  Version: |   Severity:  Critical
 Keywords:  certificates, history  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 Described for Torbirdy, applicable in the same way to Torbrowser.

 security.OCSP.enabled must be 0, after program restart 1
 Leak of used https-certificates, also leak of certificates used to check
 signatures of e-mails, thus history of used certificates (i.e. website,
 signatures, keys, if tied to a certificate).

 furthermore leak of fingerprint (in case of Torbirdy, should be secured
 with Torbrowser)
 Accept:
 Accept-Language:
 Accept-Encoding:
 ...

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30980 [Applications/TorBirdy]: Torbirdy changes config settings to insecure values

[Tor Bug Tracker & Wiki]

#30980: Torbirdy changes config settings to insecure values
-+-
 Reporter:  cypherpunks  |  Owner:  sukhbir
 Type:  task | Status:  new
 Priority:  Medium   |  Component:
 |  Applications/TorBirdy
  Version:   |   Severity:  Critical
 Keywords:  Torbirdy, leak,  |  Actual Points:
  referer, cookie|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
 network.http.sendRefererHeader should be 0, after progam restart 2

 permissions.default.image should be 2, after program restart 3

 network.cookie.cookieBehavior; should be 2, according to torbirdy restore
 setting (extensions.torbirdy.restore.network.cookie.cookieBehavior;2),
 after program restart 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] #30889 [Core Tor/Tor]: Eliminate some uses of lower-level control protocol output functions (was: Eliminate use of lower-level control protocol output functions)

[Tor Bug Tracker & Wiki]

#30889: Eliminate some uses of lower-level control protocol output functions
--+
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #29210| Points:  3
 Reviewer:|Sponsor:  Sponsor31-can
--+

Comment (by catalyst):

 It turns out to be easier to fix up the onion_helper stuff first as a
 separate commit. Opening a new ticket for sending control replies using a
 key-value list abstraction.

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

Re: [tor-bugs] #30500 [Circumvention/Censorship analysis]: Can the GFW still do DPI for "new" vanilla Tor?

[Tor Bug Tracker & Wiki]

#30500: Can the GFW still do DPI for "new" vanilla Tor?
---+--
 Reporter:  phw|  Owner:  (none)
 Type:  task   | Status:  assigned
 Priority:  Low|  Milestone:
Component:  Circumvention/Censorship analysis  |Version:
 Severity:  Normal | Resolution:
 Keywords:  gfw, china |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by phw):

 Replying to [comment:3 arma]:
 > Are you saying Tor bridges / relays can look for those 65 ciphers, and
 refuse to continue in that case? :)

 I don't think that would work well. I just caught two more probes and
 attached the resulting pcap file. It contains three TLS client hello
 packets: the first is a tcis decoy connection from a system in China (I
 rewrote the IP address to 1.1.1.1) to my Tor bridge (rewritten to
 2.2.2.2). The next two packets are active probes, with their original IP
 addresses. Interestingly, their cipher list differs: one has 65 suites
 while the other one has 68 suites.

 The site tlsfingerprints.io has seen the cipher list of
 [https://tlsfingerprint.io/id/f47f08ae690b4756 the first probe 138,000
 times] and [https://tlsfingerprint.io/id/4e542eaea37cdd51 the second probe
 <100 times]. FWIW, tlsfingerprints.io works as follows:
 > We collect anonymized TLS Client Hello messages from the University of
 Colorado Boulder campus network, in order to measure the popularity of
 various implementations actually used in practice.

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

Re: [tor-bugs] #30958 [Core Tor/Tor]: Stop removing the ed25519 signature when the extra-info file is too big

[Tor Bug Tracker & Wiki]

#30958: Stop removing the ed25519 signature when the extra-info file is too big
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridge, tor-pt, 029-backport-|  Actual Points:  0.2
  maybe, 035-backport-maybe, 040-backport-   |
  maybe, 041-backport|
Parent ID:   | Points:  0.1
 Reviewer:  dgoulet  |Sponsor:
-+-

Comment (by nickm):

 I'm thinking that this might not need a backport unless we are close to
 hitting it in practice.

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

Re: [tor-bugs] #30500 [Circumvention/Censorship analysis]: Can the GFW still do DPI for "new" vanilla Tor?

[Tor Bug Tracker & Wiki]

#30500: Can the GFW still do DPI for "new" vanilla Tor?
---+--
 Reporter:  phw|  Owner:  (none)
 Type:  task   | Status:  assigned
 Priority:  Low|  Milestone:
Component:  Circumvention/Censorship analysis  |Version:
 Severity:  Normal | Resolution:
 Keywords:  gfw, china |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by phw):

 * Attachment "probes.pcap" added.

 Pcap file containing a decoy connection and two subsequent active probes.

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

Re: [tor-bugs] #5915 [Core Tor/Tor]: Write patch to make socks handshakes succeed instantly

[Tor Bug Tracker & Wiki]

#5915: Write patch to make socks handshakes succeed instantly
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  needs-proposal tor-client intro  |  Actual Points:
  performance application experiment, tbb-   |
  wants? performance? ux |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Speaking of needs-proposal, Tom wrote a proposal here:
 https://lists.torproject.org/pipermail/tor-dev/2019-June/013905.html

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

Re: [tor-bugs] #30500 [Circumvention/Censorship analysis]: Can the GFW still do DPI for "new" vanilla Tor?

[Tor Bug Tracker & Wiki]

#30500: Can the GFW still do DPI for "new" vanilla Tor?
---+--
 Reporter:  phw|  Owner:  (none)
 Type:  task   | Status:  assigned
 Priority:  Low|  Milestone:
Component:  Circumvention/Censorship analysis  |Version:
 Severity:  Normal | Resolution:
 Keywords:  gfw, china |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by arma):

 Replying to [comment:2 phw]:
 > The research team I've been in touch with could not trigger active
 probing with tcis as the client and a netcat listener as the server. I
 suggested to use a bridge instead of a netcat listener, which resulted in
 active probing. This suggests that the GFW is also considering some
 information that's sent from the server to the client.

 It would be interesting, for posterity, for somebody (maybe somebody in
 this research team you speak of) to poke at the server-side of the
 handshake and figure out what exactly they're relying on to decide that
 it's a Tor bridge. My guess is it's something in the SSL cert, e.g. the
 address.

 Or maybe it is simply an SSL response at all? I could imagine China is
 trying to reduce the number of active probes they do, and if they didn't
 check *something* on the server side, a client inside China could just
 spam the internet with Tor client handshakes and then the active prober
 would need to probe all of 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] #5915 [Core Tor/Tor]: Write patch to make socks handshakes succeed instantly

[Tor Bug Tracker & Wiki]

#5915: Write patch to make socks handshakes succeed instantly
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  needs-proposal tor-client intro  |  Actual Points:
  performance application experiment, tbb-   |
  wants? performance? ux |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  needs-proposal tor-client intro performance application
 experiment =>
 needs-proposal tor-client intro performance application experiment,
 tbb-wants? performance? ux
 * milestone:  Tor: unspecified => Tor: 0.4.2.x-final


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

Re: [tor-bugs] #30382 [Core Tor/Tor]: Provide control port event for when we are missing v3 client auth for an onion

[Tor Bug Tracker & Wiki]

#30382: Provide control port event for when we are missing v3 client auth for an
onion
-+-
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tbb-usability, hs-auth,  |  Actual Points:
  network-team-roadmap-2019-Q1Q2, tor-spec   |
Parent ID:  #14389   | Points:  6
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-must
-+-

Comment (by dgoulet):

 Apparently (feedback from mcs), the extended errors is sent out properly
 but only after `SocksTimeout`. Most likely, the connection is not properly
 closed when the extended error is set.

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

Re: [tor-bugs] #30955 [Core Tor/Tor]: Update the fallback entry in the man page

[Tor Bug Tracker & Wiki]

#30955: Update the fallback entry in the man page
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  fallback, 041-should, doc, fast-fix  |  Actual Points:  0.1
Parent ID:  #28793   | Points:  0.1
 Reviewer:  nickm|Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 I've made a couple of comments on the PR.

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

Re: [tor-bugs] #30924 [Core Tor/Tor]: hs-v3: Implement proposal 305 - ESTABLISH_INTRO Cell DoS Defense Extension

[Tor Bug Tracker & Wiki]

#30924: hs-v3: Implement proposal 305 -  ESTABLISH_INTRO Cell DoS Defense 
Extension
---+---
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, tor-spec, prop305  |  Actual Points:
Parent ID:  #2 | Points:  7
 Reviewer: |Sponsor:  Sponsor27-must
---+---

Comment (by dgoulet):

 For this to be completed, it requires #15516 to be merged. There is quite
 a cross-over.

 For now, on going development is in `ticket30924_042_01`.

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

Re: [tor-bugs] #30577 [Applications/Tor Browser]: Add Fundraising Banner with next TBB security update

[Tor Bug Tracker & Wiki]

#30577: Add Fundraising Banner with next TBB security update
---+---
 Reporter:  pili   |  Owner:  tbb-team
 Type:  task   | Status:
   |  needs_information
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201906  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by sstevenson):

 I think the banner looks great. Can we maintain the newsletter signup link
 on this page under "Questions"?

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

Re: [tor-bugs] #15516 [Core Tor/Tor]: Consider rate-limiting INTRODUCE2 cells when under load

[Tor Bug Tracker & Wiki]

#15516: Consider rate-limiting INTRODUCE2 cells when under load
-+-
 Reporter:  special  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  SponsorU-deferred, tor-dos, tor-hs,  |  Actual Points:
  network-team-roadmap-2019-Q1Q2 |
Parent ID:  #2   | Points:  10
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-can
-+-
Changes (by dgoulet):

 * status:  accepted => 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] #13194 [Core Tor/Tor]: Track time between ESTABLISH_RENDEZVOUS and RENDEZVOUS1 cell

[Tor Bug Tracker & Wiki]

#13194: Track time between ESTABLISH_RENDEZVOUS and RENDEZVOUS1 cell
-+-
 Reporter:  arma |  Owner:  neel
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Very Low |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-hs, needs-design  |  Actual Points:
  privcount-maybe metrics performance|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorQ-can
-+-
Changes (by neel):

 * cc: neel (added)
 * owner:  (none) => neel
 * status:  new => assigned


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

Re: [tor-bugs] #30976 [Applications/Tor Browser]: Desktop folder seems to be more and more read-only on Windows 10 preventing Tor Browser from working

[Tor Bug Tracker & Wiki]

#30976: Desktop folder seems to be more and more read-only on Windows 10 
preventing
Tor Browser from working
--+--
 Reporter:  gk|  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:
--+--

Comment (by cypherpunks):

 Replying to [ticket:30976 gk]:
 > if Desktop is indeed not a good place anymore to put our bundles
 It never was.

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

Re: [tor-bugs] #21315 [Circumvention/Snowflake]: publish some realtime stats from the broker?

[Tor Bug Tracker & Wiki]

#21315: publish some realtime stats from the broker?
-+---
 Reporter:  arma |  Owner:  cohosh
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  anti-censorship-roadmap  |  Actual Points:
Parent ID:  #29461   | Points:
 Reviewer:  phw  |Sponsor:  Sponsor28-can
-+---

Comment (by cohosh):

 Replying to [comment:33 cohosh]:
 > Replying to [comment:32 cohosh]:
 > > Replying to [comment:31 irl]:
 > > Thanks irl!
 > > > Was there a reason for removing "snowflake-available-count"? This
 number is going to be the same as the sum of all country codes in
 "snowflake-ips", but it would probably be nice to have this in addition to
 be able to see at a glance.
 > > >
 > > I opted for `snowflake-idle-count` and `snowflake-client-match-count`
 instead, since I think this gives us the information we'd want to use
 `snowflake-available-count` for anyway. I'm not opposed to exporting
 another stat on the available snowflakes, I'll add the code for that back
 in shortly.
 >
 > Here's a commit that adds this metric:
 
https://github.com/cohosh/snowflake/commit/8f2dc3563b1922b285f406a48da85a5a94ee86f9

 Whoops, forgot the tests:
 
https://github.com/cohosh/snowflake/commit/908cf3fc6413930dacdf8a29b5834a5dcf5eab92

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

Re: [tor-bugs] #29206 [Circumvention/Snowflake]: New design for client -- server protocol for Snowflake (was: New design for client -- proxy protocol for Snowflake)

[Tor Bug Tracker & Wiki]

#29206: New design for client -- server protocol for Snowflake
-+-
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  task | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ex-sponsor-19, anti-censorship-  |  Actual Points:
  roadmap|
Parent ID:   | Points:  6
 Reviewer:  dcf  |Sponsor:
 |  Sponsor28-must
-+-
Changes (by cohosh):

 * status:  needs_review => needs_revision


Old description:

> Right now we just send traffic. We need to add some control messages for
> communication between the client and proxy.

New description:

 Right now we just send traffic. We could add some control messages or
 another layer for reliability/sequencing.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30979 [Core Tor/Tor]: pre-push hook runs practracker unconditionally

[Tor Bug Tracker & Wiki]

#30979: pre-push hook runs practracker unconditionally
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  git-scripts
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Our pre-push hook script runs practracker whenever it exists.  But we only
 want to run practracker on branches that are targeted for master.

 I think perhaps we should change it to try making check-local?  Or perhaps
 it could check for the existence of some other file that we could use to
 indicate whether we want practracker to run.

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

Re: [tor-bugs] #30962 [Circumvention/Snowflake]: Improve the webextension design

[Tor Bug Tracker & Wiki]

#30962: Improve the webextension design
-+--
 Reporter:  arlolra  |  Owner:  arlolra
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by cohosh):

 * owner:  (none) => arlolra
 * status:  new => assigned


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

Re: [tor-bugs] #30927 [Applications/Tor Browser]: Tor Browser on Windows does not respond to play/pause buttons while playing media.

[Tor Bug Tracker & Wiki]

#30927: Tor Browser on Windows does not respond to play/pause buttons while 
playing
media.
--+---
 Reporter:  clash |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by clash):

 Replying to [comment:7 gk]:
 > Replying to [comment:6 clash]:
 > > Replying to [comment:5 gk]:
 > > > Replying to [comment:4 clash]:
 > > > > Replying to [comment:3 gk]:
 > > > > > clash: Does this work in a vanilla Firefox ESR 60 for you?
 (bundles can be found at: https://www.mozilla.org/en-
 US/firefox/organizations/all/)
 > > > >
 > > > >
 > > > > I just checked, it doesn't.
 > > >
 > > > What about a recent Firefox (not one from the ESR train)?  Maybe
 that's already fixed there?
 > >
 > > Before updating to the ESR I tried it on the standard release (67.0.4
 iirc). It didn't work there either.
 >
 > Okay, so this is not strictly a Tor Browser but a Firefox bug. I suppose
 https://bugzilla.mozilla.org/show_bug.cgi?id=448910.

 That seems a way old ticket but yeah it's not a Tor Browser bug per se.
 Would be a useful feature, anyway.

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

Re: [tor-bugs] #30830 [Circumvention/Snowflake]: Modify snowflake broker logs to make them easier to process for measurements

[Tor Bug Tracker & Wiki]

#30830: Modify snowflake broker logs to make them easier to process for
measurements
-+---
 Reporter:  cohosh   |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  logs, stats  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor28
-+---

Comment (by cohosh):

 Replying to [comment:1 cohosh]:
 > We should also consider how and why we want to distinguish between these
 logs and the corresponding data and the broker stats we export to metrics
 (#21315)

 My thoughts on this are to use the metrics output in #21315 for
 measurements, and to use the default broker logs for debugging purposes.
 The only reason I can see for using the default broker log output for
 additional measurements are if there are long-term measurements we can do
 at the broker that are too sensitive for periodic export and display by
 the metrics team.

 The stats exported in #21315 have all of the information needed for the
 graphs produced in #30693  (except for TLS/HTTP errors which fall into the
 debugging bucket).

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

Re: [tor-bugs] #21315 [Circumvention/Snowflake]: publish some realtime stats from the broker?

[Tor Bug Tracker & Wiki]

#21315: publish some realtime stats from the broker?
-+---
 Reporter:  arma |  Owner:  cohosh
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  anti-censorship-roadmap  |  Actual Points:
Parent ID:  #29461   | Points:
 Reviewer:  phw  |Sponsor:  Sponsor28-can
-+---

Comment (by irl):

 Having the total count is also a good way to make sure the GeoIP code
 isn't doing something strange. Looking at UpdateCountryStats I don't think
 there will be any issues here, because you've got good error checking and
 a fallback option. Separating things that depend on GeoIP databases from
 things that don't is sometimes a good idea though.

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

Re: [tor-bugs] #21315 [Circumvention/Snowflake]: publish some realtime stats from the broker?

[Tor Bug Tracker & Wiki]

#21315: publish some realtime stats from the broker?
-+---
 Reporter:  arma |  Owner:  cohosh
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  anti-censorship-roadmap  |  Actual Points:
Parent ID:  #29461   | Points:
 Reviewer:  phw  |Sponsor:  Sponsor28-can
-+---

Comment (by cohosh):

 Replying to [comment:32 cohosh]:
 >
 > I'm putting this back into needs_revision to add the total available
 snowflake stats. I'll get a code review on that once I complete it, and
 then I'm tempted to close out this ticket and open a new one for the next
 steps in hooking these metrics outputs to whatever the metrics team needs
 to publish these.

 I created #30978 for this

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

[tor-bugs] #30978 [Circumvention/Snowflake]: Get snowflake metrics published

[Tor Bug Tracker & Wiki]

#30978: Get snowflake metrics published
-+-
 Reporter:  cohosh   |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:   |Version:
  Circumvention/Snowflake|   Keywords:  metrics, snowflake,
 Severity:  Normal   |  stats
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:  Sponsor28|
-+-
 We've now implemented the collection of snowflake stats at the broker:
 #21315, and the metrics team has signed off of them as ready to publish.

 The next step is to figure out how to export these statistics and where to
 publish them.

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

Re: [tor-bugs] #29315 [Metrics/Website]: Write down guidelines for adding new stats

[Tor Bug Tracker & Wiki]

#29315: Write down guidelines for adding new stats
-+--
 Reporter:  karsten  |  Owner:  irl
 Type:  enhancement  | Status:  accepted
 Priority:  Very High|  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-roadmap-2019-q2  |  Actual Points:
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+--
Changes (by cohosh):

 * cc: cohosh (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] #21315 [Circumvention/Snowflake]: publish some realtime stats from the broker?

[Tor Bug Tracker & Wiki]

#21315: publish some realtime stats from the broker?
-+---
 Reporter:  arma |  Owner:  cohosh
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  anti-censorship-roadmap  |  Actual Points:
Parent ID:  #29461   | Points:
 Reviewer:  phw  |Sponsor:  Sponsor28-can
-+---
Changes (by cohosh):

 * status:  needs_revision => needs_review
 * reviewer:  irl => phw


Comment:

 Replying to [comment:32 cohosh]:
 > Replying to [comment:31 irl]:
 > Thanks irl!
 > > Was there a reason for removing "snowflake-available-count"? This
 number is going to be the same as the sum of all country codes in
 "snowflake-ips", but it would probably be nice to have this in addition to
 be able to see at a glance.
 > >
 > I opted for `snowflake-idle-count` and `snowflake-client-match-count`
 instead, since I think this gives us the information we'd want to use
 `snowflake-available-count` for anyway. I'm not opposed to exporting
 another stat on the available snowflakes, I'll add the code for that back
 in shortly.

 Here's a commit that adds this metric:
 
https://github.com/cohosh/snowflake/commit/8f2dc3563b1922b285f406a48da85a5a94ee86f9

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

Re: [tor-bugs] #21315 [Circumvention/Snowflake]: publish some realtime stats from the broker?

[Tor Bug Tracker & Wiki]

#21315: publish some realtime stats from the broker?
-+
 Reporter:  arma |  Owner:  cohosh
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  anti-censorship-roadmap  |  Actual Points:
Parent ID:  #29461   | Points:
 Reviewer:  irl  |Sponsor:  Sponsor28-can
-+
Changes (by cohosh):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:31 irl]:
 Thanks irl!
 > Was there a reason for removing "snowflake-available-count"? This number
 is going to be the same as the sum of all country codes in "snowflake-
 ips", but it would probably be nice to have this in addition to be able to
 see at a glance.
 >
 I opted for `snowflake-idle-count` and `snowflake-client-match-count`
 instead, since I think this gives us the information we'd want to use
 `snowflake-available-count` for anyway. I'm not opposed to exporting
 another stat on the available snowflakes, I'll add the code for that back
 in shortly.

 > I can follow your thought processes and I think that these metrics
 described in comment:19, and also snowflake-available-count from
 comment:14 would be OK to make public. Nothing is jumping out as
 particularly sensitive.
 >
 > Is it possible to run two snowflake proxies from the same IP address?
 There does seem to be an implied limit of 1 proxy per IP address in your
 metrics descriptions. Maybe from a perspective of whether a bridge is
 burned or not, the fact that two processes may be running on the same IP
 doesn't matter because they would both be burned together?
 It is possible to run multiple snowflakes on a single IP. Only the country
 codes stats (and the total available snowflakes which I'll add back in)
 are unique by IP. The `snowflake-idle-count` and `snowflake-client-match-
 count` are not unique by IP and would reflect one IP address running
 multiple snowflakes. I think splitting the metrics in this way makes
 sense. The unique-by-IP ones will tell us information that's useful for
 censorship or blocking by IP and the ones that aren't unique by IP will
 tell us useful information about load on the system.


 I'm putting this back into needs_revision to add the total available
 snowflake stats. I'll get a code review on that once I complete it, and
 then I'm tempted to close out this ticket and open a new one for the next
 steps in hooking these metrics outputs to whatever the metrics team needs
 to publish these.

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

Re: [tor-bugs] #29999 [Core Tor/Tor]: Objective 1, Activity 2: Denial of service defences

[Tor Bug Tracker & Wiki]

#2: Objective 1, Activity 2: Denial of service defences
-+-
 Reporter:  pili |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-dos, network-team-   |  Actual Points:
  roadmap-2019-Q1Q2, user-feedback, blog |
Parent ID:  #30281   | Points:  36
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-
Changes (by dgoulet):

 * sponsor:  Sponsor27 => Sponsor27-must


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

Re: [tor-bugs] #30927 [Applications/Tor Browser]: Tor Browser on Windows does not respond to play/pause buttons while playing media.

[Tor Bug Tracker & Wiki]

#30927: Tor Browser on Windows does not respond to play/pause buttons while 
playing
media.
--+---
 Reporter:  clash |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by gk):

 Replying to [comment:6 clash]:
 > Replying to [comment:5 gk]:
 > > Replying to [comment:4 clash]:
 > > > Replying to [comment:3 gk]:
 > > > > clash: Does this work in a vanilla Firefox ESR 60 for you?
 (bundles can be found at: https://www.mozilla.org/en-
 US/firefox/organizations/all/)
 > > >
 > > >
 > > > I just checked, it doesn't.
 > >
 > > What about a recent Firefox (not one from the ESR train)?  Maybe
 that's already fixed there?
 >
 > Before updating to the ESR I tried it on the standard release (67.0.4
 iirc). It didn't work there either.

 Okay, so this is not strictly a Tor Browser but a Firefox bug. I suppose
 https://bugzilla.mozilla.org/show_bug.cgi?id=448910.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30977 [Applications/Tor Browser]: Make it possible to measure Tor performance while doing Tor Browser updates/update pings

[Tor Bug Tracker & Wiki]

#30977: Make it possible to measure Tor performance while doing Tor Browser
updates/update pings
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-performance, tbb-
 Severity:  Normal   |  update
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 While being at All Hands ekr had the idea that we could make it possible
 to measure Tor performance when doing update pings and downloading
 updates. The idea is _not_ to send the data somewhere, rather being able
 to measure the time the ping/updates take if one wants to look at that. We
 could emit a log message with the time it took for those actions and
 whether errors occurred (that e.g. led to retrying the whole thing).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30976 [Applications/Tor Browser]: Desktop folder seems to be more and more read-only on Windows 10 preventing Tor Browser from working

[Tor Bug Tracker & Wiki]

#30976: Desktop folder seems to be more and more read-only on Windows 10 
preventing
Tor Browser from working
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 We have reports from users that basic functionality like starting Tor
 Browser or saving bookmarks is not working more on some Windows 10
 systems. Given that moving the bundle to different locations often solves
 this problem We should investigate that closer and think about potential
 workarounds if Desktop is indeed not a good place anymore to put our
 bundles, because Windows is e.g. locking down more and more places into
 read-only mode (see: https://www.windowscentral.com/how-enable-controlled-
 folder-access-windows-10-fall-creators-update).

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