Re: [tor-bugs] #22132 [Core Tor/Chutney]: Chutney should avoid waiting for set times: wait for conditions instead

[Tor Bug Tracker & Wiki]

#22132: Chutney should avoid waiting for set times: wait for conditions instead
+-
 Reporter:  teor|  Owner:  nickm
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Chutney|Version:
 Severity:  Normal  | Resolution:
 Keywords:  network-team-roadmap-2019-Q1Q2  |  Actual Points:  1.2
Parent ID:  #20647  | Points:  2
 Reviewer:  teor|Sponsor:  Sponsor19
+-

Comment (by teor):

 I didn't get to merge this today. Anyone can merge, or I will merge it
 tomorrow.

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

Re: [tor-bugs] #28203 [Core Tor/Chutney]: Make chutney log the bootstrap progress for each node

[Tor Bug Tracker & Wiki]

#28203: Make chutney log the bootstrap progress for each node
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Chutney |Version:
 Severity:  Normal   | Resolution:
 Keywords:  test, chutney, consistency,  |  Actual Points:  0.1
  jenkins, integration-testing, continuous-  |
  integration, network-team-roadmap-2019-Q1Q2|
Parent ID:   | Points:  3
 Reviewer:  nickm|Sponsor:
-+-

Comment (by teor):

 I didn't get to merge this today. Anyone can merge, or I will merge it
 tomorrow.

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

Re: [tor-bugs] #28565 [Core Tor/sbws]: Report excluded results in a relay's bandwidth line

[Tor Bug Tracker & Wiki]

#28565: Report excluded results in a relay's bandwidth line
-+-
 Reporter:  teor |  Owner:  juga
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  sbws:
 |  1.1.0
Component:  Core Tor/sbws|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bwauth, sbws-1.0-must-   |  Actual Points:
  moved-20181128, sbws-11x-final-|
  removed-20190312, sbws-110-proposed, changes-  |
  version-minor  |
Parent ID:  #28547   | Points:  1
 Reviewer:  teor |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:16 juga]:
 > Replying to [comment:15 teor]:
 > > Here are some specific things to fix:
 > >
 > > * You made the bandwidth file header count relay exclusions, not
 result exclusions. That is a good choice: anyone who wants to know result
 totals can just add all the relay-level results. But the key names, key
 documentation, and comments need to say what you are counting.
 > >
 > > * It's not clear to me what each key is meant to be counting. Please
 update the spec in #29775, or write comments that define each kind of
 failure and each key (or both).
 >
 > I added fixups extending documentation.
 > TBH, i was minimizing documentation because i think we should work on
 #28684, which would change part of the documentation (and code).

 Ok, I have done a review on the 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] #28565 [Core Tor/sbws]: Report excluded results in a relay's bandwidth line

[Tor Bug Tracker & Wiki]

#28565: Report excluded results in a relay's bandwidth line
-+-
 Reporter:  teor |  Owner:  juga
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  sbws:
 |  1.1.0
Component:  Core Tor/sbws|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bwauth, sbws-1.0-must-   |  Actual Points:
  moved-20181128, sbws-11x-final-|
  removed-20190312, sbws-110-proposed, changes-  |
  version-minor  |
Parent ID:  #28547   | Points:  1
 Reviewer:  teor |Sponsor:
-+-

Comment (by teor):

 I don't think it is a good idea to start #28684 when you only have 10 paid
 days left. It will be harder to find and fix bugs when you don't have as
 much time.

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

Re: [tor-bugs] #29760 [Core Tor/Chutney]: Stop repeating chutney's defaults in comments

[Tor Bug Tracker & Wiki]

#29760: Stop repeating chutney's defaults in comments
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Chutney |Version:
 Severity:  Normal   | Resolution:
 Keywords:  fast-fix, network-team-  |  duplicate
  roadmap-2019-Q1Q2  |  Actual Points:
Parent ID:  #22132   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:   => #22132


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

Re: [tor-bugs] #29760 [Core Tor/Chutney]: Stop repeating chutney's defaults in comments

[Tor Bug Tracker & Wiki]

#29760: Stop repeating chutney's defaults in comments
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Chutney |Version:
 Severity:  Normal   | Resolution:
 Keywords:  fast-fix, network-team-  |  duplicate
  roadmap-2019-Q1Q2  |  Actual Points:
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

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


Comment:

 I fixed these comments in my fixup to #22132.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29803 [Applications/Tor Browser]: Trust Tor Project domain in NoScript when TorButton security level is changed

[Tor Bug Tracker & Wiki]

#29803: Trust Tor Project domain in NoScript when TorButton security level is
changed
-+--
 Reporter:  cypherpunks  |  Owner:  tbb-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Component:  Applications/Tor Browser
  Version:   |   Severity:  Normal
 Keywords:  noscript |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 Trust *.torproject.org in NoScript for first-party access when the
 TorButton security level is changed.

 I don't know if it's possible to restrict to first-party in NoScript. It
 is in uMatrix. I don't know if trusting TP's sites by default could aid
 fingerprinting TB as TB rather than its UserAgent if, for example, a TP
 resource is embedded in a third-party page. On a related note, IIRC, the
 blog is hosted by a third-party.

 Or always trust TP's onions only?  https://onion.torproject.org/  Same
 unknown but for onion and non-onion third parties.

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

Re: [tor-bugs] #29763 [Core Tor/Chutney]: Fix 0.2.9 failures in chutney CI

[Tor Bug Tracker & Wiki]

#29763: Fix 0.2.9 failures in chutney CI
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Chutney |Version:
 Severity:  Normal   | Resolution:
 Keywords:  chutney-ci, network-team-|  Actual Points:
  roadmap-2019-Q1Q2  |
Parent ID:  #29761   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 I haven't seen any of these failures since we implemented #22132. Let's
 continue to monitor and close this bug if we don't see any in the next
 week?

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

Re: [tor-bugs] #29761 [Core Tor/Chutney]: Track chutney CI failures, and tweak the allow failures settings

[Tor Bug Tracker & Wiki]

#29761: Track chutney CI failures, and tweak the allow failures settings
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Chutney |Version:
 Severity:  Normal   | Resolution:
 Keywords:  chutney-ci, network-team-|  Actual Points:
  roadmap-2019-Q1Q2  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor19-must
-+-

Comment (by teor):

 I haven't seen any of these failures since we implemented #22132. Let's
 continue to monitor and close this bug if we don't see any in the next
 week?

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

Re: [tor-bugs] #29437 [Core Tor/Stem]: test-stem times out intermittently

[Tor Bug Tracker & Wiki]

#29437: test-stem times out intermittently
---+---
 Reporter:  rl1987 |  Owner:  (none)
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 This bug caused our maint-0.4.0 cron job to fail today:
 https://travis-ci.org/torproject/tor/jobs/507687407

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

Re: [tor-bugs] #29802 [Core Tor/Tor]: Document the v3 onion service key files in the tor man page

[Tor Bug Tracker & Wiki]

#29802: Document the v3 onion service key files in the tor man page
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224-extra, tor-doc,  |  Actual Points:
  fast-fix   |
Parent ID:  #25955   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  tor-hs, prop224-extra, tor-doc => tor-hs, prop224-extra, tor-
 doc, fast-fix


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29802 [Core Tor/Tor]: Document the v3 onion service key files in the tor man page

[Tor Bug Tracker & Wiki]

#29802: Document the v3 onion service key files in the tor man page
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-hs, prop224-extra, tor-doc
Actual Points:|  Parent ID:  #25955
   Points:|   Reviewer:
  Sponsor:|
--+
 The tor man page is missing the names of the key files for v3 onion
 services.

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

Re: [tor-bugs] #29036 [Core Tor/Tor]: Coverage merge failures cause test_process_slow stderr check to fail

[Tor Bug Tracker & Wiki]

#29036: Coverage merge failures cause test_process_slow stderr check to fail
-+-
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Major| Resolution:
 Keywords:  041-accepted-20190115, regression,   |  Actual Points:
  tor-ci, 029-backport, 034-backport,|
  035-backport, 040-backport |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  041-accepted-20190115, regression, tor-ci =>
 041-accepted-20190115, regression, tor-ci, 029-backport, 034-backport,
 035-backport, 040-backport


Comment:

 Replying to [comment:7 ahf]:
 > I think it would make the most sense to delete the coverage files so
 they don't take up space in the cache rather than deleting them from the
 cache before we (maybe?) update them. It seems like these files should
 never be cached, right?

 It doesn't make sense to cache the files, and it's probably a bad thing:
 coverage can change when unrelated modules change.

 If we delete the files before caching, they'll disappear from the cache
 after the first build on each branch. So the initial build, and old
 branches, might still have this bug. I think that's ok?

 Let's create a "clean-coverage" make target, and add it in the
 "before_cache:" phase?
 https://docs.travis-ci.com/user/caching/#before_cache-phase

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

Re: [tor-bugs] #10012 [Applications/Tor Browser]: Include bookmarks to useful Tor Project resources in the Tor Browser Bundle

[Tor Bug Tracker & Wiki]

#10012: Include bookmarks to useful Tor Project resources in the Tor Browser 
Bundle
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  bookmarks, needs-triage   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Related: #19950

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

Re: [tor-bugs] #19950 [Applications/Tor Browser]: Replace Tor Project bookmarks in TBB to their onion service equivalent

[Tor Bug Tracker & Wiki]

#19950: Replace Tor Project bookmarks in TBB to their onion service equivalent
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Related: [#10012]

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

Re: [tor-bugs] #19950 [Applications/Tor Browser]: Replace Tor Project bookmarks in TBB to their onion service equivalent

[Tor Bug Tracker & Wiki]

#19950: Replace Tor Project bookmarks in TBB to their onion service equivalent
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Caveat:
 If a user shares their URL on the clearnet, their audience would need Tor
 Browser to view it. Perhaps a folder of onions alongside the .org
 bookmarks? Or just a bookmark to https://onion.torproject.org/ ?

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

Re: [tor-bugs] #9887 [Applications/Tor Browser]: Create bookmark for the Tor Q site in the Tor Browser Bundle

[Tor Bug Tracker & Wiki]

#9887: Create bookmark for the Tor Q site in the Tor Browser Bundle
--+--
 Reporter:  runa  |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  needs-triage  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Some recent comments on the blog asked for something like this, but I
 oppose it as [comment:4 vynX] said. Tor Project runs a support FAQ and
 wiki now too.

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

Re: [tor-bugs] #15722 [Applications/Tor Browser]: Importing bookmarks tags from HTML

[Tor Bug Tracker & Wiki]

#15722: Importing bookmarks tags from HTML
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:1 mcs]:
 > https://bugzilla.mozilla.org/show_bug.cgi?id=416611

 Its status is RESOLVED FIXED since Firefox 43.

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

Re: [tor-bugs] #28563 [Core Tor/sbws]: Work out how sbws can report excluded relays in the bandwidth file

[Tor Bug Tracker & Wiki]

#28563: Work out how sbws can report excluded relays in the bandwidth file
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  sbws:
 |  1.1.0
Component:  Core Tor/sbws|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bwauth, sbws-1.0-must-   |  Actual Points:
  moved-20181128, sbws-11x-final-|
  removed-20190312, sbws-110-proposed, changes-  |
  version-minor  |
Parent ID:  #28547   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:13 juga]:
 > Replying to [comment:12 teor]:
 > > I think we should do two things:
 > > 1. show all the relays in the consensus in the sbws bandwidth file
 > > 2. when sbws wants tor to exclude a relay from the vote, make tor
 ignore the bandwidths for that relay
 > >
 > > You can do whatever you need to do to the tickets to make these things
 happen.
 >
 > Just to clarify whether i understand this correctly, from
 https://trac.torproject.org/projects/tor/ticket/28158#comment:13:
 >
 > > > One thing would be to include all the "non-eligible relays" lines,
 as lines that Tor will not currently parse.
 > >
 > > Let's change the relays that are in the bandwidth file, but tor won't
 vote on them, in #28563.
 >
 > Ok, so i'll add non-eligible relays without `bw` key so Tor doesn't
 parse them.
 >
 > > > Other different thing is to report all "eligible relays", even if
 they are not the 60% of the relays in the network.
 >
 > So, from 1. above, i'll include all relays (eligible and not eligible)
 without the `bw` key so Tor doesn't parse them, when they're not the 60%.
 >
 > Correct?

 I think I know what you mean, but I am not sure. Please use shorter
 sentences?

 === Finding Every Relay ===

 Relay operators want to know about their relays.
 So we need to know what sbws thinks about every relay.
 We can find out what sbws thinks by putting some information about every
 relay in every bandwidth file.

 It doesn't matter if we are excluding the relays due to eligibility, or
 60% measured, or some other rule. We want all the relays in the file.

 There are two different ways to find every relay:
 1. all the relays which sbws has tried to test in the last 5 days
 2. all the relays in the current consensus

 I think option 1 is better, because it includes more relays. But option 2
 is also ok. You can choose the option that is easier or faster. Please
 document the option that you choose.

 === Making Tor Ignore Relays ===

 We don't want this change to change the relays that tor is voting on. So
 we want tor to ignore the new relays added by this change.

 Tor ignores lines without a "bw=" key. But Tor 0.3.5 and later log an
 "Incomplete bandwidth file" warning for every incomplete line, every time
 they parse the file. That's not ok: we can not fill up authority operators
 logs with warnings.

 Instead, you could use "bw=0 unmeasured=1 vote=0" and patch tor so that it
 ignores relay lines with "vote=0". Can you open another ticket for this
 Tor change?

 Tor versions without the patch will give more 0 votes to unmeasured
 relays, so they will get lower bandwidth values in the consensus. That's
 ok.

 We might want to vote 0 for unmeasured relays in a future sbws or tor
 version. That's why I added the "unmeasured=1" key. But it's not a change
 I want to make now, because you only have 10 paid days left. Can you open
 another ticket for this sbws change?

 Please also document the way that you make tor ignore relays.

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

Re: [tor-bugs] #29036 [Core Tor/Tor]: Coverage merge failures cause test_process_slow stderr check to fail

[Tor Bug Tracker & Wiki]

#29036: Coverage merge failures cause test_process_slow stderr check to fail
-+-
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Major| Resolution:
 Keywords:  041-accepted-20190115, regression,   |  Actual Points:
  tor-ci |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by ahf):

 I think it would make the most sense to delete the coverage files so they
 don't take up space in the cache rather than deleting them from the cache
 before we (maybe?) update them. It seems like these files should never be
 cached, right?

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

Re: [tor-bugs] #29755 [Core Tor/sbws]: Consider to rename the Bandwidth file KeyValues

[Tor Bug Tracker & Wiki]

#29755: Consider to rename the Bandwidth file KeyValues
---+-
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 2.0.0
Component:  Core Tor/sbws  |Version:  sbws: 1.0.5
 Severity:  Normal | Resolution:
 Keywords:  changes-version-major  |  Actual Points:
Parent ID:  #28547 | Points:  3
 Reviewer: |Sponsor:
---+-

Comment (by teor):

 There are 10 paid coding days left. I don't think this is a good use of
 your time. I would rather have documentation for the keys.

 What do you think?

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

Re: [tor-bugs] #29775 [Core Tor/sbws]: Document the new bandwidth file keys added in sbws 1.1.0

[Tor Bug Tracker & Wiki]

#29775: Document the new bandwidth file keys added in sbws 1.1.0
-+-
 Reporter:  teor |  Owner:  juga
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  sbws:
 |  1.1.0
Component:  Core Tor/sbws|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bwauth, no-changes-version,  |  duplicate
  tor-spec, tor-bandwidth-file-spec, no- |  Actual Points:
  changes-version|
Parent ID:  #28547   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

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


Comment:

 We usually close duplicates when we find them. Otherwise, we have to find
 them and close them when the other duplicate is 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] #29036 [Core Tor/Tor]: Coverage merge failures cause test_process_slow stderr check to fail

[Tor Bug Tracker & Wiki]

#29036: Coverage merge failures cause test_process_slow stderr check to fail
-+-
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Major| Resolution:
 Keywords:  041-accepted-20190115, regression,   |  Actual Points:
  tor-ci |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:5 ahf]:
 > I'm not sure if I read the output correctly, but does this error
 condition mean that the test binaries (and the child-process binary)
 output "Merge mismatch for function X" on standard error?
 >
 > We can detect that line in stderr's first line if we want to in the
 process tests, but I don't think that would be the right solution. Can we
 either fail in an earlier way when this condition appears OR figure out a
 way to reset the state so these "Merge mismatch" disappear?

 Let's try deleting the cached coverage files before building?
 Or let's delete the coverage files after a coverage run, so they don't
 take up space in the cache?

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

Re: [tor-bugs] #29036 [Core Tor/Tor]: Coverage merge failures cause test_process_slow stderr check to fail

[Tor Bug Tracker & Wiki]

#29036: Coverage merge failures cause test_process_slow stderr check to fail
-+-
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Major| Resolution:
 Keywords:  041-accepted-20190115, regression,   |  Actual Points:
  tor-ci |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by ahf):

 I'm not sure if I read the output correctly, but does this error condition
 mean that the test binaries (and the child-process binary) output "Merge
 mismatch for function X" on standard error?

 We can detect that line in stderr's first line if we want to in the
 process tests, but I don't think that would be the right solution. Can we
 either fail in an earlier way when this condition appears OR figure out a
 way to reset the state so these "Merge mismatch" disappear?

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

Re: [tor-bugs] #29740 [Core Tor/Tor]: Fix memory leaks in shared random unit tests: simple version

[Tor Bug Tracker & Wiki]

#29740: Fix memory leaks in shared random unit tests: simple version
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Major| Resolution:
 Keywords:  tor-ci, tor-test, memory-|  Actual Points:  0.3
  management, 029-backport, 034-backport,|
  035-backport, 040-backport, nickm-merge,   |
  dgoulet-merge  |
Parent ID:   | Points:  0.1
 Reviewer:  asn  |Sponsor:
-+-

Comment (by teor):

 One appveyor test failed due to #29645. I'm going to relaunch the test to
 make sure there aren't any more failures.

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

Re: [tor-bugs] #29645 [Core Tor/Tor]: test.exe hangs on Appveyor CI

[Tor Bug Tracker & Wiki]

#29645: test.exe hangs on Appveyor CI
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, tor-windows, tor-test, hang  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 The hang happened again in:
 
https://ci.appveyor.com/project/teor2345/tor/builds/23143503/job/c46tf2b1pnr3j479

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

Re: [tor-bugs] #29537 [Core Tor/Tor]: verify intptr_t round-trip through void *

[Tor Bug Tracker & Wiki]

#29537: verify intptr_t round-trip through void *
+--
 Reporter:  catalyst|  Owner:  (none)
 Type:  defect  | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.4.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  portability technical-debt  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  catalyst, teor  |Sponsor:
+--

Comment (by teor):

 Replying to [comment:17 rl1987]:
 > Are we doing the right thing here though? Intuitively, if we're writing
 code that a compiler might very reasonably optimize away, aren't we on a
 wrong path?

 Some of our existing code relies on behaviour that's not guaranteed by the
 standard. This ticket is about writing tests to make sure that our
 supported architectures do what we expect with this existing code. (Rather
 than changing pointer values in other ways.)

 See the ticket description for details.

 But these tests won't be any good to us if the casts are optimised away by
 the compiler. Much of our existing code avoids this optimisation by doing
 the casts in different functions in different modules. So the tests need
 to do the casts in different functions in a different module.

 > Perhaps we should create tickets to fix parts of tor codebase that rely
 on putting integers into `void *` one by one?

 We already have #23714 to fix these issues. But we want to add a test now,
 and do the fixes later.

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

Re: [tor-bugs] #22132 [Core Tor/Chutney]: Chutney should avoid waiting for set times: wait for conditions instead

[Tor Bug Tracker & Wiki]

#22132: Chutney should avoid waiting for set times: wait for conditions instead
+-
 Reporter:  teor|  Owner:  nickm
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Chutney|Version:
 Severity:  Normal  | Resolution:
 Keywords:  network-team-roadmap-2019-Q1Q2  |  Actual Points:  1.2
Parent ID:  #20647  | Points:  2
 Reviewer:  teor|Sponsor:  Sponsor19
+-
Changes (by teor):

 * status:  needs_review => merge_ready
 * reviewer:   => teor


Comment:

 We also need to change tools/test-network-impl.sh, I added a fixup here:
 https://github.com/torproject/chutney/pull/14

 I think we're at the point that I'm happy with this fix, and my extra
 changes are pretty small. I'll wait for CI, then merge.

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

Re: [tor-bugs] #29201 [Core Tor/Tor]: Tor bootstrap hangs when offline

[Tor Bug Tracker & Wiki]

#29201: Tor bootstrap hangs when offline
---+---
 Reporter:  atagar |  Owner:  (none)
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  040-deferred-20190220  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 Replying to [comment:4 atagar]:
 > In this particular case I do not mind the behavior change. Stem's tests
 already intend to run when we're 0% bootstrapped so I need to investigate
 this more on my side...
 >
 > https://gitweb.torproject.org/stem.git/tree/test/runner.py#n629
 > https://gitweb.torproject.org/stem.git/tree/stem/process.py#n170
 >
 > Stepping back, maybe we should rethink bootstrapping more fundamentally?
 In particular...
 >
 > 1. Bootstrap behavior is undocumented. Traditionally this has been fine
 because it never changed.

 Bootstrap has been documented in the control spec since before Tor 0.2.6:
 https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n3773

 The CLIENT_STATUS events remain the same:
 https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n2481

 There is also new bootstrap documentation for 0.4.0 and later:
 https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n3496

 >Stem and Txtorcon

 and now Chutney, see #22132

 >use bootstrapping to determine "Is my tor process ready to do X?"
 where X are things like "make a circuit" or "run a hidden service". We
 don't care about the bootstrap percentage (see below), but we use their
 implication that tor has become ready to do things.
 >
 >Our usage is causing you friction. We should use another mechanism or
 formalize this by documenting tor's bootstrapping behavior including what
 the various percentages (or messages) mean.

 If the existing CLIENT_STATUS event or bootstrap tags don't do what you
 need, or the documentation is incomplete, let's open separate tickets for
 each issue.

 > 2. If we're going to rethink bootstrapping maybe we should go further?
 Why do we even present bootstrapping as percentages? Does this make sense?
 >
 >Said another way, if "tor is 13% boostrapped" what does that mean? It
 isn't a time estimate (we're not saying that we're 13% done). It's also
 not saying that tor is capable of 13% of its capabilities.
 >
 >I suspect bootstrap percentages might be a holdover from Vidalia's
 progress bar, which from a user perspective always stunk (descriptor
 downloads usually dominate bootstrapping so the bar jumped to ~55%, hangs
 for a minute, then jumps to 100%).
 >
 >Obligatory video: https://www.youtube.com/watch?v=1V2SHW6Qx_E
 >
 > Just spitballing, but how about the following?
 >
 > 1. Drop the bootstrap percentage.

 The bootstrap percentage is used by Tor Browser.

 > 2. Define bootstrap logging as purely informational (ie. controllers
 like Stem should not use it).

 Controllers should use CLIENT_STATUS events or the bootstrap tags, as
 documented:
 https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n2500

 > 3. Add GETINFO commands that answer any "Is tor ready to do X?"
 inquiries.

 I think the CLIENT_STATUS events do what you're asking for?
 https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n2481

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

Re: [tor-bugs] #29740 [Core Tor/Tor]: Fix memory leaks in shared random unit tests: simple version

[Tor Bug Tracker & Wiki]

#29740: Fix memory leaks in shared random unit tests: simple version
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Major| Resolution:
 Keywords:  tor-ci, tor-test, memory-|  Actual Points:  0.3
  management, 029-backport, 034-backport,|
  035-backport, 040-backport, nickm-merge,   |
  dgoulet-merge  |
Parent ID:   | Points:  0.1
 Reviewer:  asn  |Sponsor:
-+-
Changes (by teor):

 * status:  reopened => needs_review
 * actualpoints:  0.1 => 0.3
 * parent:  #29706 =>
 * milestone:  Tor: 0.3.5.x-final => Tor: 0.4.0.x-final


Comment:

 It turns out we need to apply a9c3101 from #29706 to avoid all leaks:
 https://trac.torproject.org/projects/tor/ticket/29706#comment:12

 The pull requests are:

 0.2.9, one commit added:
 https://github.com/torproject/tor/pull/774

 0.3.4, merged, and one comment commit added:
 https://github.com/torproject/tor/pull/801

 0.4.0, comments merged, the code changes are already in 0.4.0:
 https://github.com/torproject/tor/pull/802

 (#29706 is too big to backport, so I'm un-parenting this 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] #29706 [Core Tor/Tor]: Test failure due to memory leaks in shared-random unit tests: long-term fix

[Tor Bug Tracker & Wiki]

#29706: Test failure due to memory leaks in shared-random unit tests: long-term 
fix
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-ci, tor-test, memory-|  Actual Points:  1.1
  management, 034-unreached-backport, 035|
  -unreached-backport, 040-backport  |
Parent ID:   | Points:  0.5
 Reviewer:  asn  |Sponsor:
-+-
Changes (by teor):

 * keywords:
 consider-backport-after-authority-test, consider-backport-
 after-0404-alpha, tor-ci, tor-test, memory-management, 034-backport-
 maybe, 035-backport, 040-backport
 =>
 tor-ci, tor-test, memory-management, 034-unreached-backport, 035
 -unreached-backport, 040-backport
 * status:  merge_ready => closed
 * resolution:   => fixed
 * milestone:  Tor: 0.3.5.x-final => Tor: 0.4.0.x-final


Comment:

 This change is too large to backport: we already fixed the unit test
 failure in 0.2.9 and later with #29740.

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

Re: [tor-bugs] #29036 [Core Tor/Tor]: Coverage merge failures cause test_process_slow stderr check to fail

[Tor Bug Tracker & Wiki]

#29036: Coverage merge failures cause test_process_slow stderr check to fail
-+-
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Major| Resolution:
 Keywords:  041-accepted-20190115, regression,   |  Actual Points:
  tor-ci |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Here are the full logs, I'm going to restart the job to clear the error:
 {{{
 slow/crypto/fuzz_donna/ed25519_donna: [forking]
 profiling:/home/travis/build/torproject/tor/src/trunnel
 /src_trunnel_libor_trunnel_testing_a-socks5.gcda:Merge mismatch for
 function 108
 profiling:/home/travis/build/torproject/tor/src/trunnel
 /src_trunnel_libor_trunnel_testing_a-socks5.gcda:Merge mismatch for
 function 108
 OK
 slow/crypto/fuzz_donna/ed25519_ref10: [forking]
 profiling:/home/travis/build/torproject/tor/src/trunnel
 /src_trunnel_libor_trunnel_testing_a-socks5.gcda:Merge mismatch for
 function 108
 profiling:/home/travis/build/torproject/tor/src/trunnel
 /src_trunnel_libor_trunnel_testing_a-socks5.gcda:Merge mismatch for
 function 108
 OK
 slow/process/callbacks:
 profiling:/home/travis/build/torproject/tor/src/trunnel
 /src_trunnel_libor_trunnel_testing_a-socks5.gcda:Merge mismatch for
 function 108
   FAIL src/test/test_process_slow.c:241:
 assert(smartlist_len(process_data->stderr_data) OP_EQ 3): 4 vs 3
   [callbacks FAILED]
 slow/process/callbacks_terminate:
 profiling:/home/travis/build/torproject/tor/src/trunnel
 /src_trunnel_libor_trunnel_testing_a-socks5.gcda:Merge mismatch for
 function 108
 OK
 slow/prob_distr/stochastic_genpareto: [forking]
 profiling:/home/travis/build/torproject/tor/src/trunnel
 /src_trunnel_libor_trunnel_testing_a-socks5.gcda:Merge mismatch for
 function 108
 profiling:/home/travis/build/torproject/tor/src/trunnel
 /src_trunnel_libor_trunnel_testing_a-socks5.gcda:Merge mismatch for
 function 108
 OK
 slow/prob_distr/stochastic_geometric: [forking]
 profiling:/home/travis/build/torproject/tor/src/trunnel
 /src_trunnel_libor_trunnel_testing_a-socks5.gcda:Merge mismatch for
 function 108
 profiling:/home/travis/build/torproject/tor/src/trunnel
 /src_trunnel_libor_trunnel_testing_a-socks5.gcda:Merge mismatch for
 function 108
 OK
 slow/prob_distr/stochastic_uniform: [forking]
 profiling:/home/travis/build/torproject/tor/src/trunnel
 /src_trunnel_libor_trunnel_testing_a-socks5.gcda:Merge mismatch for
 function 108
 profiling:/home/travis/build/torproject/tor/src/trunnel
 /src_trunnel_libor_trunnel_testing_a-socks5.gcda:Merge mismatch for
 function 108
 OK
 slow/prob_distr/stochastic_logistic: [forking]
 profiling:/home/travis/build/torproject/tor/src/trunnel
 /src_trunnel_libor_trunnel_testing_a-socks5.gcda:Merge mismatch for
 function 108
 profiling:/home/travis/build/torproject/tor/src/trunnel
 /src_trunnel_libor_trunnel_testing_a-socks5.gcda:Merge mismatch for
 function 108
 OK
 slow/prob_distr/stochastic_log_logistic: [forking]
 profiling:/home/travis/build/torproject/tor/src/trunnel
 /src_trunnel_libor_trunnel_testing_a-socks5.gcda:Merge mismatch for
 function 108
 profiling:/home/travis/build/torproject/tor/src/trunnel
 /src_trunnel_libor_trunnel_testing_a-socks5.gcda:Merge mismatch for
 function 108
 OK
 slow/prob_distr/stochastic_weibull: [forking]
 profiling:/home/travis/build/torproject/tor/src/trunnel
 /src_trunnel_libor_trunnel_testing_a-socks5.gcda:Merge mismatch for
 function 108
 profiling:/home/travis/build/torproject/tor/src/trunnel
 /src_trunnel_libor_trunnel_testing_a-socks5.gcda:Merge mismatch for
 function 108
 OK
 1/20 TESTS FAILED. (0 skipped)
 profiling:/home/travis/build/torproject/tor/src/trunnel
 /src_trunnel_libor_trunnel_testing_a-socks5.gcda:Merge mismatch for
 function 108
 }}}

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

Re: [tor-bugs] #29036 [Core Tor/Tor]: Coverage merge failures cause test_process_slow stderr check to fail

[Tor Bug Tracker & Wiki]

#29036: Coverage merge failures cause test_process_slow stderr check to fail
-+-
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Major| Resolution:
 Keywords:  041-accepted-20190115, regression,   |  Actual Points:
  tor-ci |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * priority:  Medium => High
 * severity:  Critical => Major


Comment:

 This issue caused a master build to fail:
 https://travis-ci.org/torproject/tor/jobs/507372106

 It doesn't seem to happen very often, so I'm dropping the severity.

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

Re: [tor-bugs] #28656 [Core Tor/Tor]: Bug: src/feature/nodelist/nodelist.c:2501: compute_frac_paths_available : Non-fatal assertion !(f_exit > 0.0) failed.

[Tor Bug Tracker & Wiki]

#28656: Bug: src/feature/nodelist/nodelist.c:2501: compute_frac_paths_available 
:
Non-fatal assertion !(f_exit > 0.0) failed.
-+-
 Reporter:  meejah   |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  consider-backport-after-2019-03-19,  |  Actual Points:  0.1
  backport-before-0359, regression, 035-rc-  |
  blocker?, 035-backport, postfreeze-ok, |
  040-must   |
Parent ID:   | Points:  0.1
 Reviewer:  catalyst |Sponsor:
-+-
Changes (by teor):

 * keywords:  regression, 035-rc-blocker?, 035-backport, postfreeze-ok,
 040-must =>
 consider-backport-after-2019-03-19, backport-before-0359, regression,
 035-rc-blocker?, 035-backport, postfreeze-ok, 040-must


Comment:

 Replying to [comment:14 catalyst]:
 > Replying to [comment:13 nickm]:
 > > Okay, I've squashed the branch as bug28656_035_squashed, and made a
 new PR as https://github.com/torproject/tor/pull/798 .  Merging to 0.4.0
 and forward.  Marking for possible backport.
 > Backport pull request looks good. I have no strong opinions either way
 about backporting it to 0.3.5. Has anyone reported it triggering on 0.3.5?

 Yes, #29658 is a report on 0.3.5.8.

 And it was introduced in 0.3.5.1-alpha, so we don't need to backport any
 further:

 Replying to [comment:9 teor]:
 > This bug was introduced in #27237 in 0.3.5.1-alpha, due to an unexpected
 interaction with #27236 in 0.3.4.7-rc. See the comments in the pull
 request for details.

 (I haven't seen any reports earlier than 0.3.5.)

 Here's my backport assessment:

 This patch modifies application code by removing a BUG() warning and
 simplifying a condition into an equivalent condition. It affects 1 code
 line and a few comment lines.

 It is a low risk, obviously beneficial change. We have two (or three) bug
 reports on 0.3.5.8, 0.4.0.0-alpha-dev, and 0.4.0.1-alpha-dev.

 I'd like to backport it after a few working days in nightly, and before
 the next 0.3.5 release.

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

Re: [tor-bugs] #29607 [Core Tor/Tor]: Denial of service on v2 and v3 onion service

[Tor Bug Tracker & Wiki]

#29607: Denial of service on v2 and v3 onion service
--+--
 Reporter:  pidgin|  Owner:  pidgin
 Type:  defect| Status:  accepted
 Priority:  Immediate |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 Hi pidgin,

 We need to know more about your setup to help you:

 Replying to [comment:22 teor]:
 > The v3 service doesn't have the guard issue, it's getting much further
 along. Have you tried running it on a separate machine? (Or by itself
 without v2 running on the same machine?)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, prop299  |  Actual Points:
Parent ID:  #27491 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by teor):

 I have reviewed the new changes.

 Before you make more changes, I want to discuss the issues on the pull
 request. And I want a review from another person.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, prop299  |  Actual Points:
Parent ID:  #27491 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by teor):

 Please don't assign me as the reviewer for this proposal.
 I have already reviewed it, and I would like another reviewer to review
 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] #27491 [Core Tor/Tor]: Prefer IPv4 or IPv6 based on the number of failures

[Tor Bug Tracker & Wiki]

#27491: Prefer IPv4 or IPv6 based on the number of failures
--+--
 Reporter:  neel  |  Owner:  neel
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  needs-proposal, ipv6  |  Actual Points:
Parent ID:  #17835| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * status:  needs_revision => new


Comment:

 Setting as new again.
 #29801 is the ticket for the proposal 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] #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:
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, prop299  |  Actual Points:
Parent ID:  #27491 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by teor):

 * status:  assigned => 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] #27491 [Core Tor/Tor]: Prefer IPv4 or IPv6 based on the number of failures

[Tor Bug Tracker & Wiki]

#27491: Prefer IPv4 or IPv6 based on the number of failures
--+--
 Reporter:  neel  |  Owner:  neel
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  needs-proposal, ipv6  |  Actual Points:
Parent ID:  #17835| Points:
 Reviewer:|Sponsor:
--+--
Changes (by neel):

 * status:  needs_review => needs_revision


Comment:

 I have added some changes with a new PR at #29801
 (https://github.com/torproject/torspec/pull/63). This PR can get updated
 if another reviewer comes 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

[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:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  ipv6, prop299
Actual Points:|  Parent ID:  #27491
   Points:|   Reviewer:
  Sponsor:|
--+---
 Teor has asked for updates in
 https://github.com/torproject/torspec/pull/61, but this PR has already
 been merged.

 I have created a new PR for his suggestions:
 https://github.com/torproject/torspec/pull/63

 I don't believe you can add to a merged PR so that's why a new PR exists.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-triage-20180328, |  Actual Points:
  034-removed-20180328   |
Parent ID:   | Points:  1
 Reviewer:  asn  |Sponsor:
-+-
Changes (by neel):

 * status:  needs_revision => needs_review


Comment:

 That's fine.

 I have updated my code and pushed 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] #27446 [Core Tor/Tor]: hs: Report configuration error on the control port

[Tor Bug Tracker & Wiki]

#27446: hs: Report configuration error on the control port
--+--
 Reporter:  atagar|  Owner:  neel
 Type:  defect| Status:  assigned
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by neel):

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


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

Re: [tor-bugs] #29612 [Core Tor/Tor]: Update the documentation for ExitRelay

[Tor Bug Tracker & Wiki]

#29612: Update the documentation for ExitRelay
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  fast-fix, doc, 035-backport, |  Actual Points:
  040-backport   |
Parent ID:   | Points:  0.1
 Reviewer:  mikeperry|Sponsor:
-+-
Changes (by neel):

 * cc: neel (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] #29743 [Core Tor/Tor]: Long-running tor instances fail to keep up-to-date directory information

[Tor Bug Tracker & Wiki]

#29743: Long-running tor instances fail to keep up-to-date directory information
-+---
 Reporter:  karsten  |  Owner:  (none)
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:  Tor: 0.3.0.7
 Severity:  Normal   | Resolution:
 Keywords:  needs-insight usability  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by starlight):

 * cc: starlight@… (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] #29744 [Core Tor/Tor]: Streams sometimes stall for up to 1 hour without making any progress

[Tor Bug Tracker & Wiki]

#29744: Streams sometimes stall for up to 1 hour without making any progress
-+--
 Reporter:  karsten  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:  Tor: 0.3.0.7
 Severity:  Normal   | Resolution:
 Keywords:  needs-insight usability  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by starlight):

 * cc: starlight@… (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] #29357 [Core Tor/Tor]: add an ActiveOnStartup config option

[Tor Bug Tracker & Wiki]

#29357: add an ActiveOnStartup config option
---+---
 Reporter:  mcs|  Owner:  nickm
 Type:  enhancement| Status:
   |  needs_review
 Priority:  Very High  |  Milestone:  Tor:
   |  0.4.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-needs, 040-proposed, 040-must  |  Actual Points:  .1
Parent ID: | Points:  .5
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * cc: gk (added)
 * status:  accepted => needs_review
 * type:  defect => enhancement
 * actualpoints:   => .1


Comment:

 I've done an implementation in `ticket29357_040`, PR at
 https://github.com/torproject/tor/pull/800

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

Re: [tor-bugs] #29159 [Community/Translations]: Outreach material localization

[Tor Bug Tracker & Wiki]

#29159: Outreach material localization
+--
 Reporter:  antonela|  Owner:  emmapeel
 Type:  task| Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Community/Translations  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  stephw, ggus|Sponsor:
+--
Changes (by emmapeel):

 * status:  assigned => 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] #29799 [Webpages/Research]: fix translations for the research portal

[Tor Bug Tracker & Wiki]

#29799: fix translations for the research portal
---+--
 Reporter:  emmapeel   |  Owner:  emmapeel
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Webpages/Research  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #26838 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by emmapeel):

 oops it seems this may not be needed after all

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

Re: [tor-bugs] #29799 [Webpages/Research]: fix translations for the research portal

[Tor Bug Tracker & Wiki]

#29799: fix translations for the research portal
---+--
 Reporter:  emmapeel   |  Owner:  emmapeel
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Webpages/Research  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #26838 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by emmapeel):

 The translations are available on the
 [https://gitweb.torproject.org/translation.git/ translation repo], on the
 researchtpo-contentspot and researchtpo-contentspot_completed branches.

 (Use the researchtpo-contentspot_completed for better results!)

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

Re: [tor-bugs] #29795 [Community/Translations]: Add new Torbutton file securityLevel.properties to the translations repo

[Tor Bug Tracker & Wiki]

#29795: Add new Torbutton file securityLevel.properties to the translations repo
+--
 Reporter:  gk  |  Owner:  emmapeel
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Community/Translations  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  #25658  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by gk):

 It seems `bn-BD` is missing? Could we get that as well?

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

Re: [tor-bugs] #29744 [Core Tor/Tor]: Streams sometimes stall for up to 1 hour without making any progress

[Tor Bug Tracker & Wiki]

#29744: Streams sometimes stall for up to 1 hour without making any progress
-+--
 Reporter:  karsten  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:  Tor: 0.3.0.7
 Severity:  Normal   | Resolution:
 Keywords:  needs-insight usability  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 I looked at the op-ab logs, created by tor version 0.3.5.7-dev, and tried
 to identify stalling runs. The data basis here is much smaller with only 2
 months of logs from 1 instance as compared to 3 months of logs from 3
 instances in my initial analysis above.

 I found at least one measurement where the download stalled for 18 seconds
 (ID 103995) and a few more measurements with shorter stalls. I'm attaching
 a new graph and the controller events for the graphed measurements.

 My current guess is that it's not an issue with the client but with one of
 the relays. And if it were "just" 18 seconds, it might even be acceptable
 for most use cases.

 But I believe that most of the application-level timeouts after one hour
 and some of the really slow downloads in my first analysis suffer from the
 very same issue. Maybe a scheduling issue or a matter of picking a
 scheduling algorithm that treats all streams more fairly?

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

Re: [tor-bugs] #29744 [Core Tor/Tor]: Streams sometimes stall for up to 1 hour without making any progress

[Tor Bug Tracker & Wiki]

#29744: Streams sometimes stall for up to 1 hour without making any progress
-+--
 Reporter:  karsten  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:  Tor: 0.3.0.7
 Severity:  Normal   | Resolution:
 Keywords:  needs-insight usability  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * Attachment "streams-op-ab.log" 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] #29744 [Core Tor/Tor]: Streams sometimes stall for up to 1 hour without making any progress

[Tor Bug Tracker & Wiki]

#29744: Streams sometimes stall for up to 1 hour without making any progress
-+--
 Reporter:  karsten  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:  Tor: 0.3.0.7
 Severity:  Normal   | Resolution:
 Keywords:  needs-insight usability  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * Attachment "streams-op-ab.pdf" 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