Re: [tor-bugs] #10394 [Applications/Tor Browser]: Torbrowser's updater updates HTTPS-everywhere

[Tor Bug Tracker & Wiki]

#10394: Torbrowser's updater updates HTTPS-everywhere
+--
 Reporter:  StrangeCharm|  Owner:  tbb-team
 Type:  task| Status:  reopened
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-security, TorBrowserTeam201803  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by cypherpunks):

 Ruleset updates are finally here! 🎉 https://www.eff.org/deeplinks/2018/04
 /https-everywhere-introduces-new-feature-continual-ruleset-updates

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

Re: [tor-bugs] #23846 [Core Tor/Tor]: Use libtool for building shared library

[Tor Bug Tracker & Wiki]

#23846: Use libtool for building shared library
-+-
 Reporter:  hellais  |  Owner:  sbs
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, s8-api,  |  Actual Points:
  034-triage-20180328 034-included-20180402  |
Parent ID:  #23684   | Points:
 Reviewer:  nickm|Sponsor:
 |  Sponsor8
-+-

Comment (by sbs):

 Addressing more comments from catalyst:

 > Do we know how this will affect Windows builds? The .$(OBJEXT) vs .lo
 change makes me nervous.

 What build system is used to build Tor on Windows? I see that there is a
 `Makefile.nmake` and a `Makefile.am` and the documentation mentions mingw
 (but mainly below `contrib`).

 Probably both `Makefile.am` and `Makefile.nmake` are used, then:

 If tor is built using MS tooling and `Makefile.nmake`, then this change
 has no impact.

 Otherwise, to better understand, I tried to build `libevent` (which uses
 `libtool`) on Windows using `MSYS2` and `mingw-w64` and found that it
 produced `.lo` files. I also searched online and it seems the
 documentation of `automake`, when specifically talking about files
 produced with and without libtool, does not mention any special variable
 for the extension of libtool-produced files; rather it uses `file.lo`,
 while it specifically mentions `file.$(OBJEXT)` [1] [2].

 [1] https://www.gnu.org/software/automake/manual/html_node/Objects-
 created-both-with-libtool-and-without.html

 [2] https://www.gnu.org/software/automake/manual/html_node/Program-and-
 Library-Variables.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] #24041 [Metrics]: Unify Metrics' products operational configuration

[Tor Bug Tracker & Wiki]

#24041: Unify Metrics' products operational configuration
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

 * cc: metrics-team (removed)
 * owner:  iwakeh => metrics-team
 * status:  accepted => assigned


Comment:

 Most Metrics' products, like Onionoo, Exonerator, and Web don't even have
 the single file as configuration option (cf. comment:1 overview).

 It seems we all agree on the goal to have one file that configures each
 product's operational options.

 Both Bot and CollecTor are at that stage.  Onionoo, Exonerator, and Web
 need to be 'pushed' to that level of configuration, which will be more
 work in making the various settings accessible in one configuration file.
 AfaIk, simple Java properties suffice,  which could come in either
 properties layout or simple XML; and could be either implemented in plain
 Java or using commons configuration.

 The focus is the operational advantage, which will consist in having the
 'single point of configuration' and we should just make sure to choose the
 same kind of implementation approach for Onionoo, Exonerator, and Web; Bot
 and CollecTor work as they are.  Implementing the configuration choice for
 these two is a secondary (more long-term) issue, because both work fine as
 they are.

 Another question is what all should be configurable?  I.e., this ticket
 should be also used for checking what values, e.g., working directories,
 base URLs etc., ought to be configurable and are maybe are not yet.

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

Re: [tor-bugs] #25264 [Metrics/Website]: Decide what graph to display when there's no data to graph

[Tor Bug Tracker & Wiki]

#25264: Decide what graph to display when there's no data to graph
-+--
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  enhancement  | Status:  accepted
 Priority:  High |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

 * status:  reopened => 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] #25535 [Internal Services/Service - lists]: retire the valencia2016 list

[Tor Bug Tracker & Wiki]

#25535: retire the valencia2016 list
---+
 Reporter:  arma   |  Owner:  qbi
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by qbi):

 * status:  new => closed
 * resolution:   => 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] #21325 [Internal Services/Service - lists]: Installing Schleuder

[Tor Bug Tracker & Wiki]

#21325: Installing Schleuder
---+-
 Reporter:  hiro   |  Owner:  qbi
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by qbi):

 As far as I can tell we have several Schleuder instances running. So can
 this ticket be closed?

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

Re: [tor-bugs] #25347 [Core Tor/Tor]: Tor keeps on trying the same overloaded guard over and over (was: Tor stops building circuits, and doesn't start when it has enough directory information)

[Tor Bug Tracker & Wiki]

#25347: Tor keeps on trying the same overloaded guard over and over
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

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

Re: [tor-bugs] #25515 [Core Tor/Tor]: Add a unit test for geoip_load_file()

[Tor Bug Tracker & Wiki]

#25515: Add a unit test for geoip_load_file()
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  isis  |Sponsor:
--+

Comment (by saper):

 Formal question: should I submit another ticket with the patch?

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

Re: [tor-bugs] #24309 [Applications/Tor Browser]: Activity 4.1: Improve how circuits are displayed to the user

[Tor Bug Tracker & Wiki]

#24309: Activity 4.1: Improve how circuits are displayed to the user
---+--
 Reporter:  isabela|  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201803  |  Actual Points:
Parent ID: | Points:
 Reviewer:  antonela   |Sponsor:
---+--

Comment (by isabela):

 Hi there! Jumping in the discussion :)

 Thanks Arthur for the work! Is looking great! Here are some thoughts:

 Replying to [comment:29 brade]:

 > Replying to [comment:26 arthuredelstein]:
 >
 >
 >
 > > ...
 > > It occurs to me that the Tor Circuit section needs an icon at left,
 similar to the lock in the "Secure Connection" section and the Permissions
 [✓|x] icon below. Any ideas what this icon should be? (An onion is
 probably not the right choice, because we're already using that for onion
 sites.) One possibility would be the "relay" icon in
 https://people.torproject.org/~irl/icons/
 > >
 > >
 > >
 >
 > I like the icon proposed by Antonela's attachment since I think it helps
 non-technical users understand what a "circuit" is (common understanding
 in US is that a circuit has to do with electronics).  I'm also OK with not
 having an icon since it does add some busy-ness to that section.
 >

 I am in for the icon. I think we need to start building more educational
 opportunities within our user interactions and this visual connection
 (using the relays icon that is used in other places) is a great thing for
 that.

 I don't believe is looking crowed. I actually think is making it more
 clear it's a thing of itself, not aggregated information related to what
 the user is used to see in this doorhanger (like certificate information
 stuff).

 >
 >
 > > Also I'm wondering if it's bad to have both the Guard (i) and "Learn
 More" links, since they seem to be redundant.
 > >
 > >
 > >
 >
 > I disagree that they are redundant but I defer to Antonela as the
 designer.  To me, the Guard (i) icon should provide a general explanation
 about guards and maybe circuits.  The "Learn More" link has to do with the
 specific issues that users are confused why the whole circuit doesn't
 change when they request a new circuit.
 >
 > Another thought or two about these links:  If we are going to remove one
 of the links, I'd remove the (i) icon.  I find that the (i) icon is much
 too small; it's just a purple dot and not very recognizable as something
 that is clickable to get more info.  We know that this is a common area
 where users have questions so having an explicit "Learn More" link will
 stand out more and hopefully reduce user support in this area.
 >

 For the links question - I am in favor of removing the (i) from Guard.

 The Learn More link ideally should be linking to the manual.

 But the manual page should be updated (in my opinion). Here is where it
 talks about it:
 https://tb-manual.torproject.org/en-US/managing-identities.html

 There is no way to link to the right section inside this page :/ and the
 text there is not explaining the point we would like to explain either. So
 I think we need to update that too.

 Right now the best link for it is the support site question "Why is the
 first IP address in my relay circuit always the same? "
 https://support-staging.torproject.org/#tbb-2

 >
 >
 >
 > > Also, I liked Sukhbir's suggestion about adding an "Exit" label. We
 could even add a "Middle relay" label or more information about an onion
 site's relays. But I don't want it to look too cluttered either. Maybe
 tooltips are the best thing? ...
 > >
 > >
 > >
 >
 > Mark and I think that including both "Exit" and the IP address will add
 a lot of clutter.  Do we need to provide the IP address?  Maybe it would
 be better for the IP address to be shown in a tooltip and we should show
 middle relay and exit with links to help.

 I like the idea to add the Exit label. I would change the whole thing
 though, and by that I mean I would have label for each  node (going back
 to the idea of using every moment to educate our users). I would have
 'Guard', 'Middle', 'Exit'.

 The IP addresses are something people sometimes want to know so I would
 try to keep them to make it convenient for the user. That said, I wonder
 if it will be indeed too crowed, for some reason I don't think it would.
 But I leave this to Antonela to decide :) if having it there is ok or if
 its better to put it in tooltip or something.

 >
 > One other comment about your prototype:
 > The "Load New Circuit" button label is new text for Tor Browser.  The
 current menu label for this functionality is "New Tor Circui

Re: [tor-bugs] #21325 [Internal Services/Service - lists]: Installing Schleuder

[Tor Bug Tracker & Wiki]

#21325: Installing Schleuder
---+
 Reporter:  hiro   |  Owner:  qbi
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dgoulet):

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


Comment:

 Ah yes indeed it can. We have several list already using it. Thanks to all
 who helped here!

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:1 mikeperry]:
 > Ok, I made the smallest possible change here. I just moved the path
 length check up from the guard failure block to the beginning of the
 function. The only thing that wasn't build failure accounting or
 node/network blaming was the HS RP retry code, which I also moved up.
 >
 > I also removed the destroy check, as per #25347, as a separate commit.
 We can decide which one we like better. On the one hand, asn's branch has
 more checks and might be safer. On the other hand, this is a smaller
 change, and keeps everything related to counting circuit failures in the
 same place.
 >
 > mikeperry/bug25705

 Thanks for the patch here Mike! A github RP would be helpful so that I can
 comment inline, but I'll just do it here for now:

 - `4c64811d0b`: Looks reasonable to me. I find it kinda naughty that we
 special handle S_CONNECT_REND twice in that function, but I didnt find a
 way to improve this in a straightforward way.

 - `a2d44546c2`: A few things here:

 - Shouldn't we do the `already_marked` computation even when
 `circ->base_.received_destroy`, so that we don't double-mark? Since, IIUC
 the only reason we distinguish between receiving `DESTROY` or not now, is
 so that we can do better logging. I think that also has the potential to
 simplify the code a bit. Ideally I think that whole block should go into
 its own function.

 - Do we want to mark the guard as bad for any `DESTROY` reason? Is there a
 reason we wouldn't do that? Do we remember our old rationale here. Seems
 like the commit that introduced the ''don't do anything if DESTROY'' logic
 is  Roger in `5de88dda0acda6914bacd1e14c2e037798c5d9d9`.

 - Do we want to merge this patch without taking the precautions of Roger's
 points `G` and `E` from #25347?

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

Re: [tor-bugs] #24422 [Metrics/Website]: Look at Information Architecture for Tor Metrics

[Tor Bug Tracker & Wiki]

#24422: Look at Information Architecture for Tor Metrics
-+--
 Reporter:  irl  |  Owner:  metrics-team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #25404   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by irl):

 Just a note for when I look at this: The specifications page doesn't seem
 to be discoverable enough from the place where CSVs are actually
 downloaded.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25707 [Metrics/Website]: User per country CSV file is always empty

[Tor Bug Tracker & Wiki]

#25707: User per country CSV file is always empty
-+--
 Reporter:  dgoulet  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 For instance, this link is empty. If you change the dates, it will still
 be serving an empty file (without user data):

 https://metrics.torproject.org/userstats-relay-
 country.csv?start=2018-01-04&end=2018-04-04&country=all&events=off

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

Re: [tor-bugs] #25707 [Metrics/Website]: User per country CSV file is always empty

[Tor Bug Tracker & Wiki]

#25707: User per country CSV file is always empty
-+--
 Reporter:  dgoulet  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by irl):

 I can confirm that I also get the same problem, also for individual
 countries as well as for 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] #25707 [Metrics/Website]: User per country CSV file is always empty

[Tor Bug Tracker & Wiki]

#25707: User per country CSV file is always empty
-+--
 Reporter:  dgoulet  |  Owner:  metrics-team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:  duplicate
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

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


Comment:

 Working on this in the re-opened #25264

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25708 [Core Tor]: [test] setenv() failure in util/expand_filename: test: environment corrupt; missing value for MAKEOVER

[Tor Bug Tracker & Wiki]

#25708: [test] setenv() failure in util/expand_filename: test: environment 
corrupt;
missing value for MAKEOVER
--+
 Reporter:  saper |  Owner:  saper
 Type:  task  | Status:  assigned
 Priority:  Low   |  Milestone:
Component:  Core Tor  |Version:  Tor: 0.3.3.4-alpha
 Severity:  Minor |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 With tor commit 3df954549232bf5516ba5fce13c66a3ac91524a4 :

 on FreeBSD 10.3-STABLE (r311284), FreeBSD version 1003511 libc seems to
 have trouble using setenv() and issues a warning about NULL pointer
 assigned to the MAKEOVER environment variable.

 As a result, setenv() does not complete and the test fails:

 {{{
 util/expand_filename: test: environment corrupt; missing value for
 MAKEOVER

   FAIL ../tor/src/test/test_util.c:1725: assert("/home/itv/" OP_EQ str):
  vs 
   [expand_filename FAILED]
 }}}

 This is almost certainly not a bug in tor, logging for further
 investigation.

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

Re: [tor-bugs] #25679 [Core Tor/Tor]: Default for TOR_RUST_DEPENDENCIES is wrong?

[Tor Bug Tracker & Wiki]

#25679: Default for TOR_RUST_DEPENDENCIES is wrong?
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  fast-fix, 033-included-20180403  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+-

Comment (by nickm):

 Sebastian says that the NEED_MOD thing may have been a hack for out-of-
 tree builds, but if the build works without it, we should rip it out.

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

Re: [tor-bugs] #25616 [Core Tor/Tor]: Non-fatal assertion in hs_desc_encode_descriptor similar to #24972

[Tor Bug Tracker & Wiki]

#25616: Non-fatal assertion in hs_desc_encode_descriptor similar to #24972
-+-
 Reporter:  alnsn|  Owner:  dgoulet
 Type:  defect   | Status:
 |  accepted
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.10
 Severity:  Normal   | Resolution:
 Keywords:  regression, tor-hs, 032-backport,|  Actual Points:
  033-must 033-triage-20180326   |
  033-included-20180326  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 We discussed this with David. The most likely source of this bug is that
 we build the descriptor once (`build_service_descriptor()`) and then we
 keep it for many hours and we just encode the same desc over and over
 before publishing it (`upload_descriptor_to_hsdir()`. If the clock jumps
 after descriptor build, certs in our descriptor might expire before we
 encode it, and this BUG will get caused. Even tho the clock jumps, we
 don't expire the descriptor because `should_rotate_descriptor()` actually
 takes `ns` time as the authoritative source.

 A solution here would be to re-build the whole descriptor everytime before
 we encode it, so that we ensure that all certs are fresh before they enter
 the encode/decode function.

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

Re: [tor-bugs] #25708 [Core Tor]: [test] setenv() failure in util/expand_filename: test: environment corrupt; missing value for MAKEOVER

[Tor Bug Tracker & Wiki]

#25708: [test] setenv() failure in util/expand_filename: test: environment 
corrupt;
missing value for MAKEOVER
--+
 Reporter:  saper |  Owner:  saper
 Type:  task  | Status:  assigned
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor  |Version:  Tor: 0.3.3.4-alpha
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by asn):

 * milestone:   => Tor: unspecified


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

Re: [tor-bugs] #21394 [Core Tor/Tor]: connection timeouts are affecting Tor Browser usability

[Tor Bug Tracker & Wiki]

#21394: connection timeouts are affecting Tor Browser usability
-+-
 Reporter:  arthuredelstein  |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-backport, 031-backport, tbb- |  Actual Points:
  performance, tbb-usability, performance, tbb-  |
  needs, 033-triage-20180320,|
  033-included-20180320  |
Parent ID:   | Points:
 Reviewer:  mikeperry|Sponsor:
-+-
Changes (by nickm):

 * milestone:  Tor: 0.3.3.x-final => Tor: 0.3.2.x-final


Comment:

 Thanks, everybody!

 I've rebased mike's branch onto maint-0.2.9, in case we decide this is a
 good idea to backport.  The new branch is called `bug21394_029_redux`.

 I've merged that branch into 0.3.3 and forward.

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

Re: [tor-bugs] #25616 [Core Tor/Tor]: Non-fatal assertion in hs_desc_encode_descriptor similar to #24972

[Tor Bug Tracker & Wiki]

#25616: Non-fatal assertion in hs_desc_encode_descriptor similar to #24972
-+-
 Reporter:  alnsn|  Owner:  dgoulet
 Type:  defect   | Status:
 |  accepted
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.10
 Severity:  Normal   | Resolution:
 Keywords:  regression, tor-hs, 032-backport,|  Actual Points:
  033-triage-20180326 033-included-20180326  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * keywords:
 regression, tor-hs, 032-backport, 033-must 033-triage-20180326
 033-included-20180326
 =>
 regression, tor-hs, 032-backport, 033-triage-20180326
 033-included-20180326
 * milestone:  Tor: 0.3.3.x-final => Tor: 0.3.4.x-final


Comment:

 Moving this to 034. The fixes aren't simple and could cause possible
 regression because we are quite close from 033 stable.

 The BUG() + log_warn() might annoy some operators in the meantime but at
 least it is harmless as tor does recover from the error gracefully by
 rebuilding the descriptor with synced time source.

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

Re: [tor-bugs] #25264 [Metrics/Website]: Decide what graph to display when there's no data to graph

[Tor Bug Tracker & Wiki]

#25264: Decide what graph to display when there's no data to graph
-+--
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  enhancement  | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

 * status:  accepted => needs_review


Comment:

 Please review [https://gitweb.torproject.org/user/iwakeh/metrics-
 web.git/commit/?h=missing-csv-data this patch commit].

 That was a strange error situation.  The call list created in java wasn't
 proper, but worked for graphs and failed for csvs.  That's why there was
 only no-data in csv files, because there was an R error.
 Now, the behavior for graphs is the same as before, but csv files always
 contain there column headers, i.e., the no-data message will not appear.
 It only shows up when there is an error.

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

Re: [tor-bugs] #25347 [Core Tor/Tor]: Tor keeps on trying the same overloaded guard over and over

[Tor Bug Tracker & Wiki]

#25347: Tor keeps on trying the same overloaded guard over and over
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 Replying to [comment:28 asn]:
 > Replying to [comment:25 mikeperry]:
 > > 2. Roger's point G is scary. I like the solution in E, though, and I
 think it actually fixes G. I would implement E by setting an is_predicted
 flag in circuit_predict_and_launch_new(), and then check that flag in
 select_entry_guard_for_circuit() to completely ignore the is_reachable
 status there if it is set. Then if any of those predicted circuits
 succeed, entry_guards_node_success() will get called, which will clear the
 is_uneachable flag and allow us to resume using the guard. For guards that
 fail only a non-zero but small portion of their circuits, this should
 allow us to keep using them rather than rotating away. I am a fan of this
 plan, and could write a patch for it if we like it.
 > >
 >
 > Hmm, I can see how the solution of E can help with G, by making Alice
 try her primary guards more aggressively in cases of predicted circuits,
 but if Alice is a busy hidden service (like Roger describes in E) most of
 her circs are not gonna be predicted.
 >
 > Furthermore, I wonder if it can completely address the problem in
 actually ''mischievous'' scenarios, where the adversary overloads all 3
 primary guards of Alice (targeting them using guard discovery attacks) to
 make her switch to other guards in her sampled set.

 FWIW, I discussed the above ''mischievous'' case with Nickm and discussed
 whether we should handle this "attacker can make you switch guards"
 congestion-attack case specially. Nick pointed out that this is the reason
 that the max sample size mechanism of prop271 was introduced (so that it's
 impossible for an adversary to make you try all the guards). If we are
 unhappy with how the sampled set of prop271 works we should refactor that
 instead of engineering special solutions for this ticket.

 tl;dr: I think we should be OK with switching guards in the case of
 `RESOURCELIMIT`, and rely on prop271 to defend against malicious attacks
 of this type. If we don't like the prop271 behavior, we should improve
 prop271.

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

Re: [tor-bugs] #25679 [Core Tor/Tor]: Default for TOR_RUST_DEPENDENCIES is wrong?

[Tor Bug Tracker & Wiki]

#25679: Default for TOR_RUST_DEPENDENCIES is wrong?
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  fast-fix, 033-included-20180403  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+-

Comment (by nickm):

 I've added a fixup commit to `bug25679_033`, with better testing than
 before.  It removes the NEED_MOD logic and makes sure that the path is
 absolute.

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

Re: [tor-bugs] #25679 [Core Tor/Tor]: Default for TOR_RUST_DEPENDENCIES is wrong?

[Tor Bug Tracker & Wiki]

#25679: Default for TOR_RUST_DEPENDENCIES is wrong?
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  fast-fix, 033-included-20180403  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_revision => 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] #22487 [Webpages/Website]: Add https version of `deb.torproject.org` repository install instructions

[Tor Bug Tracker & Wiki]

#22487: Add https version of `deb.torproject.org` repository install 
instructions
--+--
 Reporter:  anadahz   |  Owner:  hiro
 Type:  enhancement   | Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  website-content   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by anadahz):

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


Comment:

 Replying to [comment:6 hiro]:

 Seems that the change hasn't been propagated yet?

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

Re: [tor-bugs] #25264 [Metrics/Website]: Decide what graph to display when there's no data to graph

[Tor Bug Tracker & Wiki]

#25264: Decide what graph to display when there's no data to graph
-+
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by karsten):

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


Comment:

 Patch commit looks good. Merged and deployed. This solves the issue. Good
 bug hunt! Closing. Thanks!

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

Re: [tor-bugs] #25264 [Metrics/Website]: Decide what graph to display when there's no data to graph

[Tor Bug Tracker & Wiki]

#25264: Decide what graph to display when there's no data to graph
-+
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by iwakeh):

 Could you remove the cached csvs from the server?  metrics.torproject.org
 /userstats-relay-
 country.csv?start=2018-01-04&end=2018-04-04&country=all&events=off is
 still 'no-data'.

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

Re: [tor-bugs] #25707 [Metrics/Website]: User per country CSV file is always empty

[Tor Bug Tracker & Wiki]

#25707: User per country CSV file is always empty
-+--
 Reporter:  dgoulet  |  Owner:  metrics-team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:  duplicate
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 Should be fixed now, except for cached data links.

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

Re: [tor-bugs] #25264 [Metrics/Website]: Decide what graph to display when there's no data to graph

[Tor Bug Tracker & Wiki]

#25264: Decide what graph to display when there's no data to graph
-+
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by karsten):

 Oops. 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] #25515 [Core Tor/Tor]: Add a unit test for geoip_load_file()

[Tor Bug Tracker & Wiki]

#25515: Add a unit test for geoip_load_file()
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  isis  |Sponsor:
--+

Comment (by nickm):

 > Formal question: should I submit another ticket with the patch?

 I think that would be a good idea: fixing the win32 test behavior seems
 like a separate issue from increasing this test coverage.

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

Re: [tor-bugs] #25248 [Core Tor/Tor]: DoS mitgation: improve documentation

[Tor Bug Tracker & Wiki]

#25248: DoS mitgation: improve documentation
-+-
 Reporter:  cypherpunks  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dos, manpage, tor-doc,   |  Actual Points:
  033-triage-20180320, fast-fix, |
  033-included-20180326  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  accepted => needs_review


Comment:

 See branch: `ticket25248_033_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] #25625 [Metrics/Website]: Make CollecTor's file structure description part of Metrics-Web's CollecTor docs

[Tor Bug Tracker & Wiki]

#25625: Make CollecTor's file structure description part of Metrics-Web's 
CollecTor
docs
-+--
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * owner:  metrics-team => karsten
 * status:  new => 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] #22487 [Webpages/Website]: Add https version of `deb.torproject.org` repository install instructions

[Tor Bug Tracker & Wiki]

#22487: Add https version of `deb.torproject.org` repository install 
instructions
--+
 Reporter:  anadahz   |  Owner:  hiro
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  website-content   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by cypherpunks):

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


Comment:

 Replying to [comment:7 anadahz]:
 > Replying to [comment:6 hiro]:
 >
 > Seems that the change hasn't been propagated yet?
 It's working for me:
 
https://web.archive.org/web/20180404143858/https://www.torproject.org/docs/debian.html.en

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

Re: [tor-bugs] #24256 [Metrics/Onionoo]: Add a new "outdated" field to distinguish between outdated and too new tor versions

[Tor Bug Tracker & Wiki]

#24256: Add a new "outdated" field to distinguish between outdated and too new 
tor
versions
-+-
 Reporter:  arma |  Owner:  karsten
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #25199   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+-
Changes (by iwakeh):

 * status:  needs_review => merge_ready


Comment:

 Looks fine.  Maybe consider adding tests cases for the consistency of
 hash-map, equals, and Comparator?
 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] #22487 [Webpages/Website]: Add https version of `deb.torproject.org` repository install instructions

[Tor Bug Tracker & Wiki]

#22487: Add https version of `deb.torproject.org` repository install 
instructions
--+
 Reporter:  anadahz   |  Owner:  hiro
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  website-content   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by anadahz):

 Replying to [comment:8 cypherpunks]:
 > Replying to [comment:7 anadahz]:
 > > Replying to [comment:6 hiro]:
 > >
 > > Seems that the change hasn't been propagated yet?
 > It's working for me:
 
https://web.archive.org/web/20180404143858/https://www.torproject.org/docs/debian.html.en

 OK I see the issue here try to view the same URL without JavaScript
 activated.

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

Re: [tor-bugs] #25332 [Metrics/Onionoo]: Change the exit_addresses field to not exclude current OR addresses anymore

[Tor Bug Tracker & Wiki]

#25332: Change the exit_addresses field to not exclude current OR addresses 
anymore
-+
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Onionoo 1.12.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+
Changes (by iwakeh):

 * status:  needs_review => merge_ready


Comment:

 Looks fine, all checks and tests pass.

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

Re: [tor-bugs] #23932 [Internal Services/Service - lists]: Please grant more folks list creation permissions

[Tor Bug Tracker & Wiki]

#23932: Please grant more folks list creation permissions
---+-
 Reporter:  atagar |  Owner:  qbi
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by qbi):

 The current approach for creating a new mailing list is as follows:

  1. Someone makes a ticket
  1. Check if all the required information are present. See
 
https://trac.torproject.org/projects/tor/wiki/doc/emailLists#HowdoIaskforanewmailinglist
  1. Someone needs to run `newlist` on eugeni. "Someone" is a person which
 belongs to the admin group (currently weasel, qbi and nickm). The
 following information need to be entered:
   1. Name of the list
   1. Email address of the new listadmin
   1. Password for the list. The password must also go to a password
 repository.
  1. Go to https://trac.torproject.org/projects/tor/wiki/doc/emailLists and
 enter the information about the newly created list
  1. Log in at the list page at https://lists.torproject.org and enter the
 list description plus maybe make more changes.
  1. Close the ticket

 So step three is the one which only a limited set of people can do. As far
 as I see it extending the number of people would require to give them root
 privileges. The possible harm which can be done here  is more than just
 wait for a few days for a new list. Thatswhy I'm hesitant to go this way.
 IMHO it is better to ask one of the two remaining people if list creation
 takes too long. What are your opinions on this?

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

Re: [tor-bugs] #25226 [Core Tor/Tor]: Circuit cell queue can fill up memory

[Tor Bug Tracker & Wiki]

#25226: Circuit cell queue can fill up memory
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-cell, tor-relay, tor-dos,|  Actual Points:
  033-must, review-group-34, security,   |
  033-triage-20180320, 033-included-20180320 |
Parent ID:   | Points:
 Reviewer:  arma |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:30 arma]:
 > Ok, review of the actual branch:
 >
 > {{{
 > +  if (PREDICT_UNLIKELY(queue->n > max_circuit_cell_queue_size)) {
 > }}}
 >
 > This wants to be >=, right? Otherwise we let it grow one past the
 maximum.
 >
 > and then in the log message, s/cell/cells/.

 Fixup commit `ed963d7604`

 >
 > The default if we don't have a consensus param is 9000? I'm a bit
 nervous about edge cases where we somehow fail to set a consensus param,
 or when relays act before they know a consensus param, especially in the
 future once we've rolled out Mike's "defensive dropping" website
 fingerprinting design. What would you say to having a default of 5?
 Since that's what we're imagining to set as the default for now anyway.

 I'm fine with it. 50k cells is 25MB so ~40 circuits like that would start
 putting memory pressure at 1GB. Not many circuits but even at 9k limit,
 the number of circuits would be a bit less than 250 which is not much
 either.

 Fixup commit `7d25850415`

 >
 > Also, the minimum settable number is 8000? It seems like we want to
 allow a lower number for chutney experiments where we control all of the
 traffic and we're trying to check for bugs. I think 1000 might be a little
 bit too low, for example because if you ask for two streams and they
 finish, you'll get 500+500+1+1=1002 cells coming at you from the exit. Or
 if you're using optimistic data, you'll get the CONNECTED cells back
 first, bumping it up to more like 1004. But still, I think setting the
 minimum to 1000 is a legitimate choice, since that makes it easy for
 experimentors to experiment however they see fit. We should just avoid
 setting the minimum possible value in the consensus, but that's already
 true for other consensus params, e.g. we should avoid setting
 DOS_CC_CIRCUIT_BURST_DEFAULT to 1 even though it's allowed by the code.

 Fixup commit `497954459d`

 >
 > And, now that we understand more what counts in the sendme window and
 what doesn't, it might be smart to revise the huge comment to be more
 accurate.

 Fixup commit `d4ee02a714`

 >
 > And, a changes file. :)

 Fixup commit `f87c2ff62a`

 All the above have been pushed in my `_01` branch. I have a `_02` branch
 that squashes everything but also changes one commit message to reflect
 the changes made above ^.

 Branch (with fixup): `bug25226_033_01`
 Branch (squashed): `bug25226_033_02`

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

Re: [tor-bugs] #22487 [Webpages/Website]: Add https version of `deb.torproject.org` repository install instructions

[Tor Bug Tracker & Wiki]

#22487: Add https version of `deb.torproject.org` repository install 
instructions
--+--
 Reporter:  anadahz   |  Owner:  hiro
 Type:  enhancement   | Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  website-content   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

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


Comment:

 Oh right, definitely missed to test with JS disabled, thanks!

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

Re: [tor-bugs] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+-
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-dos, 033-must,|  Actual Points:
  security, 033-triage-20180320, |
  033-included-20180320  |
Parent ID:   | Points:  0.5
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 lgtm; except for one comment in the code. Putting it back in
 needs_revision but after that, it should go in `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] #25625 [Metrics/Website]: Make CollecTor's file structure description part of Metrics-Web's CollecTor docs

[Tor Bug Tracker & Wiki]

#25625: Make CollecTor's file structure description part of Metrics-Web's 
CollecTor
docs
-+--
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * Attachment "task-25625-draft.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

Re: [tor-bugs] #22575 [Internal Services/Service - lists]: password reset for mailing lists doesn't send e-mails

[Tor Bug Tracker & Wiki]

#22575: password reset for mailing lists doesn't send e-mails
---+-
 Reporter:  iwakeh |  Owner:  qbi
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by qbi):

 What exactly did you do to retrieve a password reminder? Did you just go
 to the [[https://lists.torproject.org/cgi-bin/mailman/options/metrics-
 team|options page]] and requested a mail?

 If you want to reset the mailing list password the best is to create a
 ticket and request it. I or another person will reset the pw and send it
 to you in an encrypted mail.

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

Re: [tor-bugs] #25253 [Internal Services/Service - lists]: Remove Tor Weekly News from lists.torproject.org

[Tor Bug Tracker & Wiki]

#25253: Remove Tor Weekly News from lists.torproject.org
---+-
 Reporter:  steph  |  Owner:  qbi
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by qbi):

 Should I delete the archive or should it remain?

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

Re: [tor-bugs] #23750 [Core Tor/Tor]: Isolate libevent usage to a few locations

[Tor Bug Tracker & Wiki]

#23750: Isolate libevent usage to a few locations
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  refactoring, technical-debt, |  Actual Points:
  review-group-31, 034-triage-20180328,  |
  034-included-20180401  |
Parent ID:  #25500   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor8
-+-
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 Thanks. Changes lgtm! Not sure if it passes the CI but it passes make test
 I'm happy with the fixes.

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

[tor-bugs] #25709 [Core Tor/Tor]: Tor Browser crash

[Tor Bug Tracker & Wiki]

#25709: Tor Browser crash
--+--
 Reporter:  valitor   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:  crash
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Crash while browsing. Attached crash report.

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

Re: [tor-bugs] #25625 [Metrics/Website]: Make CollecTor's file structure description part of Metrics-Web's CollecTor docs

[Tor Bug Tracker & Wiki]

#25625: Make CollecTor's file structure description part of Metrics-Web's 
CollecTor
docs
-+--
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  accepted => needs_review


Comment:

 Please find the
 
[https://trac.torproject.org/projects/tor/attachment/ticket/25625/task-25625-draft.pdf
 attached PDF] or alternatively [https://gitweb.torproject.org/karsten
 /metrics-
 web.git/commit/?h=task-25625&id=512c5f09b62853177e6facb9705f68ffe903e11e
 commit 512c5f0 in my task-25625 branch] with a possible start. The idea is
 that the most important parts of this protocol are the file names of files
 in `recent/` and `archive/` as well as paths contained in file names.

 If this looks reasonable, I'll include similar paragraphs for all
 descriptor types, and then we can see if something else remains from the
 protocol that we need to include, 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] #25332 [Metrics/Onionoo]: Change the exit_addresses field to not exclude current OR addresses anymore

[Tor Bug Tracker & Wiki]

#25332: Change the exit_addresses field to not exclude current OR addresses 
anymore
-+
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Onionoo 1.12.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+

Comment (by karsten):

 Sounds good. Thanks for checking! Waiting until mid-April before merging.

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

Re: [tor-bugs] #25709 [Core Tor/Tor]: Tor Browser crash

[Tor Bug Tracker & Wiki]

#25709: Tor Browser crash
--+--
 Reporter:  valitor   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by valitor):

 * Attachment "firefox_2018-04-04-081513_Photonic.crash" added.

 text file with crash report

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

Re: [tor-bugs] #25709 [Core Tor/Tor]: Tor Browser crash

[Tor Bug Tracker & Wiki]

#25709: Tor Browser crash
--+--
 Reporter:  valitor   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by valitor):

 * Attachment "firefox_2018-03-31-213614_Photonic.crash" added.

 text file with crash report

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

Re: [tor-bugs] #25582 [Core Tor/Tor]: Manual includes non-existant ExitPolicyDefault option

[Tor Bug Tracker & Wiki]

#25582: Manual includes non-existant ExitPolicyDefault option
-+-
 Reporter:  atagar   |  Owner:  nickm
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  fast-fix, 033-included-20180403  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 To address atagar's comment about having a mention about the formatting
 hacks, I've added a commit that does that to all options like this one:

 See branch: `bug25582_033` (based on nickm's from above).

 This is ready to merge imo.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25710 [Applications/Tor Browser]: Extract from $rootdir in mingw-w64's setup.

[Tor Bug Tracker & Wiki]

#25710: Extract from $rootdir in mingw-w64's setup.
--+--
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Minor |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 This makes it consistent with the setup of gcc and macosx-toolchain.

 I encountered this while trying to build go-webrtc with mingw-w64; the
 build script had already moved into a different directory when it tried to
 extract mingw-w64, and couldn't find the file.

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

Re: [tor-bugs] #25709 [Applications/Tor Browser]: Tor Browser crash

[Tor Bug Tracker & Wiki]

#25709: Tor Browser crash
--+--
 Reporter:  valitor   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Applications/Tor Browser  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

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


Comment:

 Looks at least related to #22330.

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

Re: [tor-bugs] #25710 [Applications/Tor Browser]: Extract from $rootdir in mingw-w64's setup.

[Tor Bug Tracker & Wiki]

#25710: Extract from $rootdir in mingw-w64's setup.
--+--
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

 * Attachment "0001-Extract-from-rootdir-in-mingw-w64-s-setup.patch" added.


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

Re: [tor-bugs] #25709 [Applications/Tor Browser]: Tor Browser 7.5.3 crash on Mac OS X 10.13.4 (was: Tor Browser crash)

[Tor Bug Tracker & Wiki]

#25709: Tor Browser 7.5.3 crash on Mac OS X 10.13.4
--+--
 Reporter:  valitor   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Applications/Tor Browser  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

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

Re: [tor-bugs] #25710 [Applications/Tor Browser]: Extract from $rootdir in mingw-w64's setup.

[Tor Bug Tracker & Wiki]

#25710: Extract from $rootdir in mingw-w64's setup.
--+--
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

 * status:  new => 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] #25709 [Applications/Tor Browser]: Tor Browser 7.5.3 crash on Mac OS X 10.13.4

[Tor Bug Tracker & Wiki]

#25709: Tor Browser 7.5.3 crash on Mac OS X 10.13.4
--+--
 Reporter:  valitor   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * keywords:  crash => tbb-crash
 * version:  Tor: unspecified =>
 * milestone:  Tor: unspecified =>


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

Re: [tor-bugs] #25679 [Core Tor/Tor]: Default for TOR_RUST_DEPENDENCIES is wrong?

[Tor Bug Tracker & Wiki]

#25679: Default for TOR_RUST_DEPENDENCIES is wrong?
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  fast-fix, 033-included-20180403  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+-

Comment (by Hello71):

 I still don't understand what `ERRORED` is for, but otherwise LGTM.

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

Re: [tor-bugs] #22330 [Applications/Tor Browser]: Tor Browser 6.5.2 crash in socket thread on macOS

[Tor Bug Tracker & Wiki]

#22330: Tor Browser 6.5.2 crash in socket thread on macOS
--+--
 Reporter:  teor  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 #20390

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

Re: [tor-bugs] #25126 [Applications/Tor Browser]: about:tor should work on small screens (mobile)

[Tor Bug Tracker & Wiki]

#25126: about:tor should work on small screens (mobile)
-+-
 Reporter:  igt0 |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton, TorBrowserTeam201804  |  Actual Points:
Parent ID:  #24855   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * keywords:  tbb-torbutton, TorBrowserTeam201804R => tbb-torbutton,
 TorBrowserTeam201804
 * status:  needs_review => needs_revision


Comment:

 This looks good, except we found one additional problem: using a fixed
 size for the `bubble` elements does not work for all languages. We tested
 by setting `general.useragent.locale` to `de` and found that the text
 extended below the bubble background. Kathy and I removed the height rule
 and that seemed to fix the problem, but maybe there is a better solution.

 Also, please update the year within the copyright notice of both files.

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

Re: [tor-bugs] #25710 [Applications/Tor Browser]: Extract from $rootdir in mingw-w64's setup.

[Tor Bug Tracker & Wiki]

#25710: Extract from $rootdir in mingw-w64's setup.
+--
 Reporter:  dcf |  Owner:  tbb-team
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Minor   | Resolution:  fixed
 Keywords:  tbb-rbm, TorBrowserTeam201804R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by boklm):

 * status:  needs_review => closed
 * keywords:   => tbb-rbm, TorBrowserTeam201804R
 * resolution:   => fixed


Comment:

 This looks good, thanks. I merged it to master as commit
 5ebf06b020bb3358a1bfeea5c8ff48fd70939308.

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

Re: [tor-bugs] #25226 [Core Tor/Tor]: Circuit cell queue can fill up memory

[Tor Bug Tracker & Wiki]

#25226: Circuit cell queue can fill up memory
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-cell, tor-relay, tor-dos,|  Actual Points:
  033-must, review-group-34, security,   |
  033-triage-20180320, 033-included-20180320 |
Parent ID:   | Points:
 Reviewer:  arma |Sponsor:
-+-

Comment (by cypherpunks):

 > Branch (with fixup): bug25226_033_01
 > Branch (squashed): bug25226_033_02
 {{{
 #define RELAY_CIRC_CELL_QUEUE_SIZE_MIN CIRCWINDOW_START_MAX
 }}}
 {{{
 /* Default value is set to a large value so we can handle padding cells
  * properly which aren't accounted for in the SENDME window. Default is
 5
  * allowed cells in the queue resulting in ~25MB. */
 #define RELAY_CIRC_CELL_QUEUE_SIZE_DEFAULT \
   (50 + RELAY_CIRC_CELL_QUEUE_SIZE_MIN)
 }}}

 > (50 **+** RELAY_CIRC_CELL_QUEUE_SIZE_MIN)

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

Re: [tor-bugs] #25253 [Internal Services/Service - lists]: Remove Tor Weekly News from lists.torproject.org

[Tor Bug Tracker & Wiki]

#25253: Remove Tor Weekly News from lists.torproject.org
---+-
 Reporter:  steph  |  Owner:  qbi
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by steph):

 I made a suggestion for how to handle in comment3. Does that work?

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

Re: [tor-bugs] #25226 [Core Tor/Tor]: Circuit cell queue can fill up memory

[Tor Bug Tracker & Wiki]

#25226: Circuit cell queue can fill up memory
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-cell, tor-relay, tor-dos,|  Actual Points:
  033-must, review-group-34, security,   |
  033-triage-20180320, 033-included-20180320 |
Parent ID:   | Points:
 Reviewer:  arma |Sponsor:
-+-

Comment (by dgoulet):

 Woa, GREAT catch! Thanks for this cypherpunks.

 I've pushed a fixup in the _01 and _02 has been rebased squashed:

 Branch (with fixup): `bug25226_033_01`
 Branch (squashed): `bug25226_033_02`

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

Re: [tor-bugs] #25253 [Internal Services/Service - lists]: Remove Tor Weekly News from lists.torproject.org

[Tor Bug Tracker & Wiki]

#25253: Remove Tor Weekly News from lists.torproject.org
---+-
 Reporter:  steph  |  Owner:  qbi
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by qbi):

 The process was that someone files a ticket, the list gets deleted and the
 list entry at https://trac.torproject.org/projects/tor/wiki/doc/emailLists
 is also deleted. So we never listed old/retired/inactive lists somewhere.
 However if someone looks at the
 
[[https://trac.torproject.org/projects/tor/wiki/doc/emailLists?action=history|history
 of the wiki page]] it is easy to find out what existed in the past.

 When reading [[comment:3]]  I'm not sure what should happen with the
 archive which resides on the harddrive. When I delete the list, I can
 remove the archive and https://lists.torproject.org/pipermail/tor-news/
 (or similar pages) will disappear or I can delete just the mailing list
 and the archive is still available. Could you tell which way I should go?
 Thanks.

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

Re: [tor-bugs] #25253 [Internal Services/Service - lists]: Remove Tor Weekly News from lists.torproject.org

[Tor Bug Tracker & Wiki]

#25253: Remove Tor Weekly News from lists.torproject.org
---+-
 Reporter:  steph  |  Owner:  qbi
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by steph):

 I don't think we should delete the archive, so then delete the list entry
 of news-team and tor-news.

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

Re: [tor-bugs] #23947 [Obfuscation/Snowflake]: Move Snowflake proxy page somewhere devs can write

[Tor Bug Tracker & Wiki]

#23947: Move Snowflake proxy page somewhere devs can write
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  project| Status:  new
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by arma):

 To be clear, this is a static website that serves javascript-or-whatever
 files, and the goal is to have a long term host name so folks who put
 badges on their website can bake the name into their badge, and so folks
 who write browser extensions that let people pretend to always have a
 snowflake tab open will have a reliable place to fetch the code from at
 each browser startup?

 If so, I think the best plan is to add this new site to our www rotation.
 That way it gets served by six or so hosts, so it has good reliability and
 load balancing. It would be editable by whoever we select to be in the
 ldap-style group, meaning the people who can edit it will need ldap
 accounts (I think arlo and dcf both qualify, and serene too for that
 matter).

 What hostname would we like it to be?

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

Re: [tor-bugs] #22575 [Internal Services/Service - lists]: password reset for mailing lists doesn't send e-mails

[Tor Bug Tracker & Wiki]

#22575: password reset for mailing lists doesn't send e-mails
---+
 Reporter:  iwakeh |  Owner:  qbi
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by iwakeh):

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


Comment:

 Sorry, I didn't intend to cause confusion.  I don't need a new password
 for the list (I only mentioned it to point out that this is not urgent for
 me), but noticed that normal subscribers couldn't retrieve a new password
 via the options page at that time.

 I just re-tested this and metrics-team list worked as expected.

 Thanks, for looking into this!
 Closing.

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

Re: [tor-bugs] #25253 [Internal Services/Service - lists]: Remove Tor Weekly News from lists.torproject.org

[Tor Bug Tracker & Wiki]

#25253: Remove Tor Weekly News from lists.torproject.org
---+
 Reporter:  steph  |  Owner:  qbi
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by qbi):

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


Comment:

 Thanks for the clarification.

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

Re: [tor-bugs] #24643 [Internal Services/Service - trac]: ValueError: invalid literal for int() with base 10: 'johan36'

[Tor Bug Tracker & Wiki]

#24643: ValueError: invalid literal for int() with base 10: 'johan36'
--+---
 Reporter:  johan36   |  Owner:  qbi
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by qbi):

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


Comment:

 duplicate of #18872

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

Re: [tor-bugs] #20694 [Internal Services/Service - trac]: disable auto-CC

[Tor Bug Tracker & Wiki]

#20694: disable auto-CC
--+
 Reporter:  weasel|  Owner:  qbi
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:  #2609 | Points:
 Reviewer:|Sponsor:
--+
Changes (by qbi):

 * status:  new => closed
 * resolution:   => 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] #24309 [Applications/Tor Browser]: Activity 4.1: Improve how circuits are displayed to the user

[Tor Bug Tracker & Wiki]

#24309: Activity 4.1: Improve how circuits are displayed to the user
---+--
 Reporter:  isabela|  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201803  |  Actual Points:
Parent ID: | Points:
 Reviewer:  antonela   |Sponsor:
---+--

Comment (by arthuredelstein):

 Thanks everyone for the great comments! People have different ideas, so
 here are some things we can discuss at the next UX meeting:

 * Include icon or not?
 * Include (i) or not?
 * Include text about guards and Learn More link at bottom or not?
 * How should we label the nodes? IP addresses or node types?
 * Call it "Tor Circuit" or "Tor Path"?
 * What text for "Reload Circuit" button?

 Of course, we can make an alpha version and continue to revise as we get
 feedback from users.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by dgoulet):

 On going development in `ticket25610_034_01` for now. It is heavy
 rebasing, heavy WIP, might change, will change, but has the latest on dev
 and experimentation.

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

Re: [tor-bugs] #19172 [Internal Services/Service - trac]: Add 'review-points' and 'actual-review-points' fields

[Tor Bug Tracker & Wiki]

#19172: Add 'review-points' and 'actual-review-points' fields
--+-
 Reporter:  nickm |  Owner:  qbi
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by isabela):

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


Comment:

 don't think this is needed anymore

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

Re: [tor-bugs] #25347 [Core Tor/Tor]: Tor keeps on trying the same overloaded guard over and over

[Tor Bug Tracker & Wiki]

#25347: Tor keeps on trying the same overloaded guard over and over
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by s7r):

 It is not happening that often in order to make user experience that bad
 in order to force us to take a decision that might degrade security /
 anonymity. If that would be the case we would have hundreds of reports by
 now. I an not sure how often and bad it affect popular onion services that
 run in anonymous mode, but it looks like it can wait slightly more.

 The behavior to switch guard on first `DESTROY` cell received as a client
 sounds terrible to me, I say we should NACK it. A proper behavior would be
 for clients to only relax a little bit after receiving say 10 `DESTROY`
 cells triggered by `RESOURCELIMIT` in a row, not switch the overloaded
 guard entirely just yet, then increase the time wait period between
 circuit retries so that we preserve as much as possible Tor's guard
 rotation period interval.

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

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
--+---
 Reporter:  isabela   |  Owner:  antonela
 Type:  project   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor17
--+---
Changes (by antonela):

 * Attachment "25658.png" 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] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
--+---
 Reporter:  isabela   |  Owner:  antonela
 Type:  project   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor17
--+---
Changes (by antonela):

 * Attachment "25658-exploration.png" 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] #22513 [Applications/Tor Browser]: Tor Browser connects to the same circuit even after CONNRESET received

[Tor Bug Tracker & Wiki]

#22513: Tor Browser connects to the same circuit even after CONNRESET received
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 The exit node which returns `CONNRESET` for tpo is
 
http://rougmnvswfsmd4dq.onion/rs.html#details/D9975CF787B78DDB2C98C9B9452A13C443AC08BA

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

Re: [tor-bugs] #24256 [Metrics/Onionoo]: Add a new "outdated" field to distinguish between outdated and too new tor versions

[Tor Bug Tracker & Wiki]

#24256: Add a new "outdated" field to distinguish between outdated and too new 
tor
versions
-+
 Reporter:  arma |  Owner:  karsten
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Onionoo 1.12.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:  #25199   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+
Changes (by karsten):

 * status:  merge_ready => closed
 * resolution:   => fixed
 * milestone:   => Onionoo 1.12.0


Comment:

 Good idea, and thanks for checking everything! Added some more tests for
 those three methods, squashed, and pushed to master. Closing. Thanks!

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

[tor-bugs] #25711 [Metrics/Onionoo]: Put out Onionoo 5.2-1.12.0

[Tor Bug Tracker & Wiki]

#25711: Put out Onionoo 5.2-1.12.0
-+
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Onionoo 1.12.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 With #22594 and #24256 being merged and #25700 being close to getting
 merged, should we consider putting out a 5.2-1.12.0 release this week
 before we put out 6.0-1.x.x in 10 days from now?

 (Note to self: update metrics-web for #24256 as part of this!)

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

Re: [tor-bugs] #24309 [Applications/Tor Browser]: Activity 4.1: Improve how circuits are displayed to the user

[Tor Bug Tracker & Wiki]

#24309: Activity 4.1: Improve how circuits are displayed to the user
---+--
 Reporter:  isabela|  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201803  |  Actual Points:
Parent ID: | Points:
 Reviewer:  antonela   |Sponsor:
---+--
Changes (by antonela):

 * Attachment "040418.png" 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] #24309 [Applications/Tor Browser]: Activity 4.1: Improve how circuits are displayed to the user

[Tor Bug Tracker & Wiki]

#24309: Activity 4.1: Improve how circuits are displayed to the user
---+--
 Reporter:  isabela|  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201803  |  Actual Points:
Parent ID: | Points:
 Reviewer:  antonela   |Sponsor:
---+--

Comment (by antonela):

 Based on today's meeting

 https://trac.torproject.org/projects/tor/attachment/ticket/24309/040418.png

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

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
--+---
 Reporter:  isabela   |  Owner:  antonela
 Type:  project   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor17
--+---
Changes (by gk):

 * cc: tbb-team (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] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
--+---
 Reporter:  isabela   |  Owner:  antonela
 Type:  project   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor17
--+---

Comment (by cypherpunks):

 @antonela Great prototypes! (love how you designed them with FF60's UX :)
 ) Concerning colors it would be great if you could make modifications so
 that they won't pose a problem for color blind users, see for example
 https://medium.theuxblog.com/how-to-design-for-color-blindness-
 a6f083b08e12 Another option would be to offer an option for enabling color
 blind friendly colors just like the extension uMatrix does in its options
 (here's a link for it to try out: https://addons.mozilla.org/en-
 US/firefox/addon/umatrix/ then go to its preferences)

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

Re: [tor-bugs] #25679 [Core Tor/Tor]: Default for TOR_RUST_DEPENDENCIES is wrong?

[Tor Bug Tracker & Wiki]

#25679: Default for TOR_RUST_DEPENDENCIES is wrong?
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  fast-fix, 033-included-20180403  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+-
Changes (by catalyst):

 * status:  needs_review => needs_revision


Comment:

 Thanks, mostly looks good!

 A few nits:
 * `ERRORED` is probably not necessary because `AC_MSG_ERROR` already exits
 the configure script with an error
 * maybe `pwd` should be `pwd -P || pwd`, because bash will retain symbolic
 link path components by default unless `set -o physical` is in effect.
 (The `|| pwd` is in case we're running on a shell that's too old to
 support `pwd -P`.)
 Probably not for a bugfix (maybe a separate ticket):
 * using `dnl` for comments prevents them from appearing in the generated
 configure script; maybe these should be `#` comments instead. (I think
 it's OK to match surrounding style for 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

[tor-bugs] #25712 [Metrics/Library]: Replace ServerDescriptor#getHiddenServiceDirVersions with ServerDescriptor#isHiddenServiceDir

[Tor Bug Tracker & Wiki]

#25712: Replace ServerDescriptor#getHiddenServiceDirVersions with
ServerDescriptor#isHiddenServiceDir
-+--
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 Tor has never supported versions in the hidden-service-dir descriptor
 line. See the recently closed #25284.

 We should probably reflect this by replacing
 `ServerDescriptor#getHiddenServiceDirVersions` with
 `ServerDescriptor#isHiddenServiceDir`.

 I'm posting a branch in a minute.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by catalyst):

 Replying to [comment:17 neel]:
 > I have uploaded a GitHub pull request:
 https://github.com/torproject/tor/pull/38
 >
 > Also, it seems all tests have passed.
 Thanks!  Looks good so far.  Would you be willing to write unit tests and
 a changes file?  (Please see doc/HACKING/CodingStandards.md and
 doc/HACKING/WritingTests.md for details.  Existing tests for control port
 features seem to be in src/tests/test_controller.c.)

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

Re: [tor-bugs] #25712 [Metrics/Library]: Replace ServerDescriptor#getHiddenServiceDirVersions with ServerDescriptor#isHiddenServiceDir

[Tor Bug Tracker & Wiki]

#25712: Replace ServerDescriptor#getHiddenServiceDirVersions with
ServerDescriptor#isHiddenServiceDir
-+--
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Low  |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  assigned => needs_review
 * priority:  Medium => Low


Comment:

 Please review [https://gitweb.torproject.org/user/karsten/metrics-
 lib.git/commit/?h=task-25712&id=89edb21d8676a4cb4edb3b4f7b3badb95c5906e5
 commit 89edb21 in my task-25712 branch].

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

Re: [tor-bugs] #25126 [Applications/Tor Browser]: about:tor should work on small screens (mobile)

[Tor Bug Tracker & Wiki]

#25126: about:tor should work on small screens (mobile)
-+-
 Reporter:  igt0 |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton,   |  Actual Points:
  TorBrowserTeam201804R  |
Parent ID:  #24855   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by igt0):

 * keywords:  tbb-torbutton, TorBrowserTeam201804 => tbb-torbutton,
 TorBrowserTeam201804R
 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:14 mcs]:
 > This looks good, except we found one additional problem: using a fixed
 size for the `bubble` elements does not work for all languages. We tested
 by setting `general.useragent.locale` to `de` and found that the text
 extended below the bubble background. Kathy and I removed the height rule
 and that seemed to fix the problem, but maybe there is a better solution.
 >

 In fact I think it is a good solution, thus the height of the higher
 bubble item will define the height of the parent element. I gave a try and
 tested in different languages and screen size, and looks good.

 > Also, please update the year within the copyright notice of both files.

 nice catch, thanks.

 Updated code:

 **bug 25126: Make about:tor layout responsive**
 
https://github.com/igortoliveira/torbutton/commit/bcc6dc11e5c9bed40ffe976ab93ec6da17ee33ea

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25713 [Core Tor/Tor]: "DisableNetwork is set" log message in Tor Browser scares/confuses users

[Tor Bug Tracker & Wiki]

#25713: "DisableNetwork is set" log message in Tor Browser scares/confuses users
--+-
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  ux-team
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 When Tor Browser has trouble connecting, we tell users to go look at the
 logs. The first thing they see in their logs is something like
 {{{
  13/06/2017 11:31:29.600 [NOTICE] DisableNetwork is set. Tor will not make
  or accept non-control network connections. Shutting down all existing
  connections.
 }}}
 and if they're hunting for a log message that gives them a hint about why
 Tor doesn't work, that one is easy to find and seems really related to why
 their tor might not work.

 So we have this recurring event where users come to us and say "My Tor
 Browser isn't working, it says DisableNetwork is set."

 Now, Tor Browser legitimately starts Tor with DisableNetwork set, so Tor
 Browser will have time to ask the user whether they want to use bridges or
 proxies or etc before their Tor starts interacting with the network. So
 "well stop using that option then" is hopefully not our best plan.

 But I wonder if there is a smarter way to have that phrased in the logs,
 so users have a better chance of guessing correctly what is going on.

 (Long term we want to not send Tor Browser users to go read Tor's logs.
 But we're not there yet either.)

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

Re: [tor-bugs] #25713 [Core Tor/Tor]: "DisableNetwork is set" log message in Tor Browser scares/confuses users

[Tor Bug Tracker & Wiki]

#25713: "DisableNetwork is set" log message in Tor Browser scares/confuses users
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by antonela):

 * cc: antonela (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] #25713 [Core Tor/Tor]: "DisableNetwork is set" log message in Tor Browser scares/confuses users

[Tor Bug Tracker & Wiki]

#25713: "DisableNetwork is set" log message in Tor Browser scares/confuses users
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 #24627 is a good straightforward example case of a user who thinks it's
 relevant enough to put in the ticket title.

 And in fact that ticket illustrates another aspect of the issue, where a
 network team developer gets confused by the log message 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] #25713 [Core Tor/Tor]: "DisableNetwork is set" log message in Tor Browser scares/confuses users

[Tor Bug Tracker & Wiki]

#25713: "DisableNetwork is set" log message in Tor Browser scares/confuses users
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 Add `DisableNetwork is unset`? ;)

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

Re: [tor-bugs] #25126 [Applications/Tor Browser]: about:tor should work on small screens (mobile)

[Tor Bug Tracker & Wiki]

#25126: about:tor should work on small screens (mobile)
-+-
 Reporter:  igt0 |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton,   |  Actual Points:
  TorBrowserTeam201804R  |
Parent ID:  #24855   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 r=brade, r=mcs
 This looks good to us. It probably makes sense to test it in the desktop
 alpha before merging into stable though (Kathy and I only tested the new
 code on macOS so far).

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

Re: [tor-bugs] #23932 [Internal Services/Service - lists]: Please grant more folks list creation permissions

[Tor Bug Tracker & Wiki]

#23932: Please grant more folks list creation permissions
---+-
 Reporter:  atagar |  Owner:  qbi
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by atagar):

 Thanks Jens! We're definitely in agreement that we should keep the set of
 people with root small. Here's my thoughts on it...

 1. We should check with weasel and nickm to see if they're ok with being
 asked to create lists. If they're up for being an occasional fallback for
 this then great! On the wiki we can say "Jens (qbi) usually creates new
 lists, but if he's unavailable for a couple weeks then feel free to reach
 out to X."

 2. Should hiro be added to the list? My understanding is that she's
 employed by TPI to be one of our sysadmins so it seems odd we aren't
 granting her access. Maybe there's concerns around this that I'm missing?

 3. Lets add the instructions you mention above to the wiki. This way
 weasel and nickm can easily reference them when they step in.

 Thoughts?

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

Re: [tor-bugs] #25713 [Core Tor/Tor]: "DisableNetwork is set" log message in Tor Browser scares/confuses users

[Tor Bug Tracker & Wiki]

#25713: "DisableNetwork is set" log message in Tor Browser scares/confuses users
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by catalyst):

 I think Tor Browser sets DisableNetwork whenever the configuration dialog
 is up, which can also happen if bootstrap failed for some reason.

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

Re: [tor-bugs] #25582 [Core Tor/Tor]: Manual includes non-existant ExitPolicyDefault option

[Tor Bug Tracker & Wiki]

#25582: Manual includes non-existant ExitPolicyDefault option
-+-
 Reporter:  atagar   |  Owner:  nickm
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  fast-fix, 033-included-20180403  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-

Comment (by atagar):

 Looks great to me! Thanks David.

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

Re: [tor-bugs] #25704 [Core Tor/Nyx]: nyx package not in debian stretch

[Tor Bug Tracker & Wiki]

#25704: nyx package not in debian stretch
--+---
 Reporter:  cypherpunks   |  Owner:  atagar
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by atagar):

 * status:  new => needs_information


Comment:

 Hi cypherpunks. Yup, new packages are initially only available on Sid...

 https://packages.debian.org/sid/nyx

 It takes months before Sid packages are added to debian stable. I don't
 have any control over this - Debian moves slowly. ;P

 Did you have any other 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] #25126 [Applications/Tor Browser]: about:tor should work on small screens (mobile)

[Tor Bug Tracker & Wiki]

#25126: about:tor should work on small screens (mobile)
-+-
 Reporter:  igt0 |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton,   |  Actual Points:
  TorBrowserTeam201804R  |
Parent ID:  #24855   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:15 igt0]:
 >
 
https://github.com/igortoliveira/torbutton/commit/bcc6dc11e5c9bed40ffe976ab93ec6da17ee33ea
 tbb-team, open it with Safest and look at your CPU!

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

Re: [tor-bugs] #25679 [Core Tor/Tor]: Default for TOR_RUST_DEPENDENCIES is wrong?

[Tor Bug Tracker & Wiki]

#25679: Default for TOR_RUST_DEPENDENCIES is wrong?
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  fast-fix, 033-included-20180403  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+-

Comment (by Hello71):

 Replying to [comment:9 catalyst]:
 > * maybe `pwd` should be `pwd -P || pwd`, because bash will retain
 symbolic link path components by default unless `set -o physical` is in
 effect. (The `|| pwd` is in case we're running on a shell that's too old
 to support `pwd -P`.)

 either `pwd` works, and just use it, or it doesn't work, and we need to
 pull in a real realpath. in this case, it should work fine, so just use
 `pwd`.

 > Probably not for a bugfix (maybe a separate ticket):
 > * using `dnl` for comments prevents them from appearing in the generated
 configure script; maybe these should be `#` comments instead. (I think
 it's OK to match surrounding style for now.)

 doesn't really matter, configure scripts are utterly unreadable 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