Re: [tor-bugs] #27403 [Applications/Tor Browser]: The onboarding bubble does not show up in the release candidate for Tor Browser

[Tor Bug Tracker & Wiki]

#27403: The onboarding bubble does not show up in the release candidate for Tor
Browser
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Thanks! So, we might have two different issues here (which could easily be
 related): your fix (and commenting out the aboutTor.css pieces) "solves"
 the problem in subsequent Tor Browser starts but not on first start. On
 first start for some interesting reason `_resizeUI()` is never called. (I
 don't see your debug output in my logs in that case but do in the
 following Tor Browser starts)

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

Re: [tor-bugs] #27403 [Applications/Tor Browser]: The onboarding bubble does not show up in the release candidate for Tor Browser

[Tor Bug Tracker & Wiki]

#27403: The onboarding bubble does not show up in the release candidate for Tor
Browser
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mcs):

 I forgot to mention that I do not know why this is just showing up now,
 but if it is a race maybe the recent NoScript changes or something else
 made it worse?

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

Re: [tor-bugs] #27403 [Applications/Tor Browser]: The onboarding bubble does not show up in the release candidate for Tor Browser

[Tor Bug Tracker & Wiki]

#27403: The onboarding bubble does not show up in the release candidate for Tor
Browser
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mcs):

 * Attachment "possible-fix.patch" added.

 a possible fix (needs 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] #27403 [Applications/Tor Browser]: The onboarding bubble does not show up in the release candidate for Tor Browser

[Tor Bug Tracker & Wiki]

#27403: The onboarding bubble does not show up in the release candidate for Tor
Browser
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mcs):

 I am not 100% sure that the root cause is the same as this bug, but
 sometimes the onboarding bubble is not shown when I repeatedly press Cmd+T
 on macOS after the first about:tor opens (to get more about:tor tabs). I
 traced the problem to a zero window width inside the `_resizeUI()`
 function within `browser/extensions/onboarding/content/onboarding.js`.

 Interestingly, the problem disappears if I comment out the following
 inside Torbutton's `src/chrome/skin/aboutTor.css` file:
 {{{
 body:not([initialized]) {
   display: none;
 }
 }}}
 My theory is that there is a race where sometimes the onboarding
 extension's `_resizeUI()` function runs before about:tor has set the
 `initialized` attribute on the body (so the document size is detected as
 zero).

 One possible way to fix this is to arrange for `_resizeUI()` to be called
 a second (or third or ...) time if the document has a size of zero. I will
 attach a *very* rough patch that fixes the problem for me. I am out of
 time for tonight, but maybe Arthur or Georg can clean it up or find a
 better solution. It would also be good to confirm that this is what is
 occurring on Linux with the Tor Browser 8 RC.

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

Re: [tor-bugs] #22637 [Webpages/Website]: Find a more maintainable approach for the signing-keys page

[Tor Bug Tracker & Wiki]

#22637: Find a more maintainable approach for the signing-keys page
--+
 Reporter:  arma  |  Owner:  traumschule
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  website
  |  redesign
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  website-content, website-bug  |  Actual Points:
Parent ID:  #3893 | Points:
 Reviewer:|Sponsor:
--+
Changes (by traumschule):

 * status:  assigned => needs_review


Comment:

 https://github.com/torproject/webwml/pull/34

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

Re: [tor-bugs] #27403 [Applications/Tor Browser]: The onboarding bubble does not show up in the release candidate for Tor Browser

[Tor Bug Tracker & Wiki]

#27403: The onboarding bubble does not show up in the release candidate for Tor
Browser
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Again the last good nightly is from 08/27 and the first bad one from
 08/30. Reverting the security slider notification related commit
 (1eb701f4701340c89c9f76ad2eb6ae86ca051e61) did not help. Neither did
 reverting the one that improved the `about:tor` behavior/appearance
 (3bf17f3f9ca7fd40ed13d40f628384d38ba71368). Resizing does not show up the
 bubble for me.

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

Re: [tor-bugs] #27401 [Applications/Tor Browser]: RC for Tor Browser 8.0 disables JavaScript on first start and does not load onboarding

[Tor Bug Tracker & Wiki]

#27401: RC for Tor Browser 8.0 disables JavaScript on first start and does not 
load
onboarding
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam201808R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * cc: rustybird, intrigeri (added)
 * status:  needs_review => closed
 * resolution:   => fixed


Comment:

 Thanks, this looks good and actually makes sense re-reading Giorgio's
 comment:39:ticket:26520. Moving the onboarding issue to a different bug
 (#27403) as this is not solved by this patch yet.

 Merged to `master` with commit 9b79f00ade001b7da59ef0c8c6f560a62da954bb.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27403 [Applications/Tor Browser]: The onboarding bubble does not show up in the release candidate for Tor Browser

[Tor Bug Tracker & Wiki]

#27403: The onboarding bubble does not show up in the release candidate for Tor
Browser
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 On start the onboarding bubble does not show up on my Linux box at least.
 Arthur can reproduce that and says that any resizing makes it appear.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27402 [Core Tor/Tor]: stop reporting "internal paths" during bootstrap

[Tor Bug Tracker & Wiki]

#27402: stop reporting "internal paths" during bootstrap
--+
 Reporter:  catalyst  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  s8-bootstrap, tor-spec
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor8-can  |
--+
 `bootstrap_status_to_string()` can report "internal paths" when the
 consensus actually contains exits, because it's conditional on
 `router_have_consensus_path()` which checks descriptors.  In the cold
 cache case, there are likely no existing descriptors, so tor will give the
 misleading impression that the consensus lacks exits (when it's actually
 more likely that it simply hasn't gotten around to downloading enough
 descriptors yet).

 Removing the code that handles these conditions also simplifies
 `bootstrap_status_to_string()`.

 This probably needs a tor-spec update.

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

Re: [tor-bugs] #27241 [Core Tor/Tor]: Extract information from more kinds of wedged directory connections.

[Tor Bug Tracker & Wiki]

#27241: Extract information from more kinds of wedged directory connections.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  fast-fix  |  Actual Points:
Parent ID:| Points:
 Reviewer:  mikeperry |Sponsor:  Sponsor8-can
--+

Comment (by mikeperry):

 To help me understand the consequences of this (and to figure out if I
 need to also do anything here for #25573), I have the following questions:

 1. How do stalled dirconns translate to their linked edge_connection_ts?
 Can the edge connection "stall" first and/or get closed somewhere else, or
 will the dirconn always be the thing that stalls?
 2. What are the consequences to the dir conn if some other code marks the
 edge connnection is closed first?
 3. When the dirconn is closed first (such as here or elsewhere in the
 code), where in the code do we decide to mark/clean up/close the
 corresponding linked edge conn? I could not find this..

 For #25573, I'm particularly concerned about multihop hsdir dirconns. But
 if we ever make regular directory activity multihop, this could apply
 there too. Plus the linked conn close conditions may be relevant to this
 bug?

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

Re: [tor-bugs] #27401 [Applications/Tor Browser]: RC for Tor Browser 8.0 disables JavaScript on first start and does not load onboarding

[Tor Bug Tracker & Wiki]

#27401: RC for Tor Browser 8.0 disables JavaScript on first start and does not 
load
onboarding
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201808R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arthuredelstein):

 * status:  new => needs_review
 * keywords:  TorBrowserTeam201808 => TorBrowserTeam201808R


Comment:

 The NoScriptControl wasn't listening early enough to receive NoScript's
 "started" message. Here's a patch for review that fixes that:

 https://github.com/arthuredelstein/torbutton/commit/27401

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

Re: [tor-bugs] #27028 [Applications/Tor Browser]: UX: Indicate current download progress

[Tor Bug Tracker & Wiki]

#27028: UX: Indicate current download progress
--+--
 Reporter:  huertanix |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by huertanix):

 Replying to [comment:2 ProTipGuyFWIWWeLoveARMA]:
 > Isn't this fixed by the switch to ff60-esr?
 >

 Yes, the first implementation is (fact checking myself with ff63.0b2).
 However, Firefox currently does not show individual download progress as
 in the Brave browser example, so that would still be a new addition.

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

Re: [tor-bugs] #27401 [Applications/Tor Browser]: RC for Tor Browser 8.0 disables JavaScript on first start and does not load onboarding

[Tor Bug Tracker & Wiki]

#27401: RC for Tor Browser 8.0 disables JavaScript on first start and does not 
load
onboarding
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201808  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 The first nightly that breaks is the one from 08/30. The one we still have
 from 08/27 is fine. That's both with NoScript 10.8.1.16.

 I wonder whether the onboarding broke things here (random guess)...

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27401 [Applications/Tor Browser]: RC for Tor Browser 8.0 disables JavaScript on first start and does not load onboarding

[Tor Bug Tracker & Wiki]

#27401: RC for Tor Browser 8.0 disables JavaScript on first start and does not 
load
onboarding
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
  |  TorBrowserTeam201808
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 #26520 fixed some race condition between Torbutton and NoScript leading to
 JavaScript being disabled on first session.

 It seems we hit something that looks similar with our RC for Tor Browser 8
 (see: https://people.torproject.org/~boklm/builds/8.0-build2/). However,
 this happens in a default Tor Browser on Linux: On first start JavaScript
 is disabled even though the security slider is set to default.

 Moreover our onboarding does not show up 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] #26769 [Core Tor/Tor]: We should make HSv3 desc upload less frequent

[Tor Bug Tracker & Wiki]

#26769: We should make HSv3 desc upload less frequent
--+
 Reporter:  asn   |  Owner:  neel
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs network-health easy hsdir  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by neel):

 PR is here: https://github.com/torproject/tor/pull/303

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

Re: [tor-bugs] #26818 [Core Tor/Tor]: Use NSS for RSA

[Tor Bug Tracker & Wiki]

#26818: Use NSS for RSA
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  035-roadmap-subticket, 035-triaged-  |  Actual Points:
  in-20180711|
Parent ID:  #26631   | Points:
 Reviewer:  asn  |Sponsor:
 |  Sponsor8-can
-+-

Comment (by nickm):

 I've added a couple more commits in nss_tls_fixes -- better now?

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

Re: [tor-bugs] #27305 [Webpages/Website]: create a download page for TBA on torproject.org

[Tor Bug Tracker & Wiki]

#27305: create a download page for TBA on torproject.org
--+
 Reporter:  isabela   |  Owner:
  |  traumschule
 Type:  task  | Status:
  |  needs_revision
 Priority:  Immediate |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201808  |  Actual Points:
Parent ID:  #26531| Points:
 Reviewer:|Sponsor:  Sponsor8
--+
Changes (by traumschule):

 * priority:  Medium => Immediate
 * status:  needs_review => needs_revision


Comment:

 After my PR got merged the icons on the projects page are at the wrong
 place (because I made changes to the css that affect other pages) and
 propose to revert master to the parent commit:
 be786f13815cc1bb3830d0054b1afaee350748d5
 Also download-easy shows the link to the apk which we do not want to
 distribute.
 https://www.torproject.org/projects/projects.html.en
 https://www.torproject.org/download/download-easy.html.en#android

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

Re: [tor-bugs] #27112 [Core Tor/Stem]: Decouple payload processing from pop/unpack + tune abstraction layers

[Tor Bug Tracker & Wiki]

#27112: Decouple payload processing from pop/unpack + tune abstraction layers
---+
 Reporter:  dmr|  Owner:  dmr
 Type:  enhancement| Status:  needs_revision
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  client |  Actual Points:
Parent ID: | Points:
 Reviewer:  atagar |Sponsor:
---+

Comment (by atagar):

 > Limitation 1: dropping multiplexed cells or (worse) throwing exceptions
 when they occur
 > ...
 > My proposed solution to this for stem is to centralize ORPort reads -
 separating that from more specific handlers.

 Hi Dave. Gotcha, Tor's control socket is multiplexed to some extent too.
 General controller interactions are serialized, but asynchronous events
 can be interweaved with content we receive.

 Stem handles this via its stem.control.BaseController class, which wraps
 our socket and provides thread safe communication through its msg()
 method.

 My plan for ORPorts is to do the same. Like BaseController, our
 stem.client.Relay class wraps the socket. It, and the Circuit class it's
 collocated with, is the spot where we'll be implementing all IO.
 Multiplexing included.

 By contrast our Cells are IO agnostic parsers. We'll likely adjust them a
 bit when we add multiplexing, but I'd expect the bulk of such a patch to
 be there.

 > Limitation 2: having unpack()/pop() methods that effectively won't work
 on the stream of data received from a guard, if there's any
 RELAY/RELAY_EARLY cells in there

 Sorry, read this a few times and still unsure what you mean by
 'interpreting' cells. That said, the next bullet is probably more
 important.

 > Limitation 3: allowing only a single layer of decryption, instead of an
 arbitrary number of layers

 Ahh! Gotcha. That's definitely something we need to address, though I
 suspect it won't be overly challenging. First thought is maybe we can
 extend our new encrypt/decrypt methods to take a series of key/digests.
 Side stepping digests for simplicity, that is to say...

 {{{
 def encrypt(self, keys):
   if isinstance(keys, list):
 # Encrypt for each relay, last to first...
 #
 #   Circuit: Us => Relay #1 (Guard) => Relay #2 (Middle) => Relay #3
 (Exit) => Endpoint
 # Cell to send:   [Header for relay #1][Encrypted payload for
 relay #1]
 # Payload for #1: [Header for relay #2][Encrypted payload for
 relay #2]
 # Payload for #2: [Header for relay #3][Encrypted payload for
 relay #3]
 # Payload for #3: [Payload for endpoint]

 cell_to_send = self

 for relay_key in reversed(keys):
   cell_to_send = cell_to_send.encrypt(relay_key)

 return cell_to_send
   else:
 # Encrypting for a single hop.

 [ something similar to our present encryption method ]

 def decrypt(self, content, keys):
   if isinstance(keys, list):
 decrypted_cell = self

 for relay_key in reversed(keys):
   decrypted_cell.decrypt(relay_key)

   if decrypted_cell.recognized == 0 and [digest check thingy]:
 return decrypted_cell  # cell is now fully decrypted

 raise stem.ProtocolError('Cell received from X couldn't be fully
 decrypted')
   else:
 # Decrypt for a single hop.

 [ something similar to our present decryption method ]
 }}}

 Just pulling from my ass. No doubt naively ignoring complications, but I'm
 sure with a little work we can come up with an elegant and functional
 solution that makes us both happy.

 What I'd like from you isn't anticipatory refactoring, but rather a
 functional prototype that makes multi-hop circuits. Once we have something
 that **works** we can iterate on the code, but until then we're both just
 guessing.

 Cheers! -Damian

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

Re: [tor-bugs] #27145 [Internal Services/Tor Sysadmin Team]: help.tpo accounts is not clear enough

[Tor Bug Tracker & Wiki]

#27145: help.tpo accounts is not clear enough
-+-
 Reporter:  juga |  Owner:  tpa
 Type:  defect   | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by juga):

 * Attachment "0003-Rephrase-how-to-be-added-to-a-group.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] #27145 [Internal Services/Tor Sysadmin Team]: help.tpo accounts is not clear enough

[Tor Bug Tracker & Wiki]

#27145: help.tpo accounts is not clear enough
-+-
 Reporter:  juga |  Owner:  tpa
 Type:  defect   | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by juga):

 * Attachment "0002-Rephrase-explaining-how-hosts-groups-work.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] #27145 [Internal Services/Tor Sysadmin Team]: help.tpo accounts is not clear enough

[Tor Bug Tracker & Wiki]

#27145: help.tpo accounts is not clear enough
-+-
 Reporter:  juga |  Owner:  tpa
 Type:  defect   | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by juga):

 * Attachment "0001-Replace-PGP-by-OpenPGP.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] #27145 [Internal Services/Tor Sysadmin Team]: help.tpo accounts is not clear enough

[Tor Bug Tracker & Wiki]

#27145: help.tpo accounts is not clear enough
-+-
 Reporter:  juga |  Owner:  tpa
 Type:  defect   | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by juga):

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


Comment:

 Replying to [comment:2 weasel]:
 > It seems irl answered all your questions.

 Not really, maybe because i didn't even made them

 > If you have proposed changes to the text of the wiki, by all means
 propose :)

 Reopening this ticket with the patches i propose.

 Replying to [comment:1 irl]:
 > I am not a sysadmin team person, so some of this may be incorrect, but
 here's my understanding:
 >
 > Replying to [ticket:27145 juga]:
 > > Quoting https://help.torproject.org/tsa/doc/accounts/:
 > >
 > > > Most of the time when people want access to a specific host, what
 they really want is getting added to a particular group
 > >
 > > does "people" need to know how ldap works or how the different
 services/machines are configured to know which "group" they want to be
 added to?
 > > i suspect no
 >
 > If you already have an ldap account you can probably log in to the
 machine and run `ls -la /srv/thing` and it will tell you what group owns a
 service.

 Before writing this ticket,I logged into perdulce as weasel said by IRC
 and run `getent group`. There was not any group called "dist". Weasel said
 it was probably `torwww`, but he had to check to know which group has
 access corresponds to "dist".

 Log in into which machine you mean?. dist.tpo is a different machine as
 perdulce. In perdulce `ls -ls /srv` does not give any interesting
 information.

 As nickm proposed in in
 https://trac.torproject.org/projects/tor/ticket/26849#comment:2, we should
 have write permissions only in a directory called sbws in dist.tpo, not to
 the root of dist.tpo.

 So, questions:
 1. does a new group need to be created to have permissions in dist.tpo
 only in the directory `sbws`?
 2. which is the group that correspond to dist.tpo, `torwww`?

 > Many things are documented on the
 
[[https://trac.torproject.org/projects/tor/wiki/org/operations/Infrastructure|Infrastructure]]
 wiki page.

 All the information i can get about dist.tpo in that page is:

 `dist.torproject.org (​web) helix   packagesN/A
 N/A`

 I think that page should be updated. Not sure there's alreay a ticket.

 > For most services you would probably have been working with existing
 people in the group and they would know what group access to ask for.

 The group i'm mostly working with, is pastly and teor, which are not in
 the group `torwww`. Other people in network-team and weasel ar inclued in
 that group. It seems i've to ask one by one.

 [...]

 I think the rest of my comments can be understood by the patches.

 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] #23446 [Webpages/Website]: Write a guidelines documentation for requirements with Tor integration by third parties

[Tor Bug Tracker & Wiki]

#23446: Write a guidelines documentation for requirements with Tor integration 
by
third parties
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  reopened
 Priority:  Medium|  Milestone:  website redesign
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  FAQ   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by traumschule):

 oh, sorry for confusing this! Reading it again a wiki page was proposed
 above, maybe similar like
 [[doc/PluggableTransports/GuidelinesForDeployingPTs]]? Probably too long:
 [[doc/GuidelinesForDeployingApplicationsUsingTor]]

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

Re: [tor-bugs] #23082 [Core Tor/Tor]: tor_addr_parse is overly permissive

[Tor Bug Tracker & Wiki]

#23082: tor_addr_parse is overly permissive
-+--
 Reporter:  dcf  |  Owner:  rl1987
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:  Tor: unspecified
 Severity:  Normal   | Resolution:
 Keywords:  032-unreached, ipv6  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by dcf):

 Replying to [comment:14 rl1987]:
 > https://github.com/torproject/tor/pull/302

 Great, rl1987! If you don't mind review from the peanut gallery:
 {{{#!diff
 -  if (src[0] == '[' && src[1])
 +  if (src[0] == '[' && src[1] && src[strlen(src)-1] == ']') {
 }}}
 I think the condition `src[1]` is now redundant. It was meant to ensure
 that the string contains at least 2 characters, but the newly added
 condition also does that.

 I note that the condition `brackets_detected != 0` is equivalent to `tmp
 != NULL`. But actually, I don't think I would try to remove the
 `brackets_detected` variable, because it expresses clearly what it means.

 I think the `tor_inet_pton(AF_INET6, ...)` line could use a comment saying
 that IPv6 addresses are allowed to be with or without brackets.

 {{{#!diff
 +  /* Reject if src has needless trailing ':'. */
 +  if (len > 2 && src[len - 1] == ':' && src[len - 2] != ':') {
 +result = -1;
 +  } else if (tor_inet_pton(AF_INET6, src, _tmp) > 0) {
 }}}
 I wonder, does this check for a trailing colon belong in `tor_inet_pton`
 instead? Or is there a reason for `tor_inet_pton` to accept such inputs?
 Maybe for compatibility with `inet_pton`? It's surprising to me that this
 check is necessary; I would have assumed (wrongly) that the underlying
 address parser would reject it.

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

[tor-bugs] #27400 [Applications/Tor Browser]: Backport Bug 1473872 - Target API 26

[Tor Bug Tracker & Wiki]

#27400: Backport Bug 1473872 - Target API 26
--+
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-mobile
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 We can't upload to Google Play until this is complete.

 https://bugzilla.mozilla.org/show_bug.cgi?id=1473872

 {{{
 Your app currently targets API level 23 and must target at least API level
 26
 to ensure it is built on the latest APIs optimized for security and
 performance.
 Change your app's target API level to at least 26.
 }}}

 We missed the cut-off for the <26 requirement:

 {{{
 Google Play will require that new apps target at least Android 8.0 (API
 level
 26) from August 1, 2018, and that app updates target Android 8.0 from
 November
 1, 2018.
 }}}

 https://developer.android.com/distribute/best-practices/develop/target-sdk

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

Re: [tor-bugs] #23446 [Webpages/Website]: Write a guidelines documentation for requirements with Tor integration by third parties

[Tor Bug Tracker & Wiki]

#23446: Write a guidelines documentation for requirements with Tor integration 
by
third parties
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  reopened
 Priority:  Medium|  Milestone:  website redesign
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  FAQ   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by tom):

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


Comment:

 This is actually about more than just trademark, so we want to keep this
 open.

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

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

[Tor Bug Tracker & Wiki]

#24104: Delay descriptor bandwidth reporting on established relays
-+-
 Reporter:  teor |  Owner:  juga
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-backport-maybe, 033-backport-|  Actual Points:
  maybe, 032-backport-maybe, 029-backport-   |
  maybe, security-low, guard-discovery-stats,|
  chutney-wants, bwauth-wants,   |
  034-triage-20180328, 034-removed-20180328, |
  tor-bwauth, 031-unreached-backport-maybe, 035  |
  -triaged-in-20180711   |
Parent ID:  #25925   | Points:  1
 Reviewer:  ahf  |Sponsor:
-+-

Comment (by arma):

 i haven't looked, and have lost track of how to look. i say if ahf likes
 it, go for it.

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

Re: [tor-bugs] #23082 [Core Tor/Tor]: tor_addr_parse is overly permissive

[Tor Bug Tracker & Wiki]

#23082: tor_addr_parse is overly permissive
-+--
 Reporter:  dcf  |  Owner:  rl1987
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:  Tor: unspecified
 Severity:  Normal   | Resolution:
 Keywords:  032-unreached, ipv6  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by rl1987):

 * status:  accepted => needs_review


Comment:

 https://github.com/torproject/tor/pull/302

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

Re: [tor-bugs] #27337 [Core Tor/sbws]: Round relay bandwidths in bandwidth files

[Tor Bug Tracker & Wiki]

#27337: Round relay bandwidths in bandwidth files
---+-
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #27108 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by juga):

 Implementation is ready, but #27135, #27386, #27336 need to be fixed first
 and i'll wait for #27398 to be fixed too to make PRs

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

Re: [tor-bugs] #27336 [Core Tor/sbws]: Does sbws need a node cap?

[Tor Bug Tracker & Wiki]

#27336: Does sbws need a node cap?
---+-
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #27107 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by juga):

 Implementation is ready, but #27135, #27386 need to be fixed first and
 i'll wait for #27398 to be fixed too to make PRs

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

Re: [tor-bugs] #27108 [Core Tor/sbws]: Implement torflow's scaling method in sbws

[Tor Bug Tracker & Wiki]

#27108: Implement torflow's scaling method in sbws
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #27107 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by juga):

 to make PRs

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

Re: [tor-bugs] #27108 [Core Tor/sbws]: Implement torflow's scaling method in sbws

[Tor Bug Tracker & Wiki]

#27108: Implement torflow's scaling method in sbws
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #27107 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by juga):

 Implementation is ready, but #27135, #27386 need to be fixed first and
 i'll wait for #27398 to be fixed 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

[tor-bugs] #27399 [Applications/Tor Browser]: Leading Orfox users to Tor Browser Android

[Tor Bug Tracker & Wiki]

#27399: Leading Orfox users to Tor Browser Android
-+-
 Reporter:  antonela |  Owner:  tbb-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  ux-team, tbb-mobile,
 Severity:  Normal   |  TorBrowserTeam201808
Actual Points:   |  Parent ID:  #26531
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 The Alpha release is using the Tor Browser icon at the Play Store. We
 decided it so users can start to relate Tor Browser for Desktop and Tor
 Browser for Android as the same family.

 The TBA Alpha .apk is still using the Orfox icon. It might be a problem
 because users with Orfox installed will see 2 Orfox apps on their
 desktops.

 This ticket will track the efforts to make that user flow more smoothly
 and clear.

 Use Cases
 1. New users (no Orfox installed)
 2. Migrated users (with Orfox installed)

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

Re: [tor-bugs] #27398 [Core Tor/sbws]: Create GH/torproject/sbws repository

[Tor Bug Tracker & Wiki]

#27398: Create GH/torproject/sbws repository
---+
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer:  teor   |Sponsor:
---+

Comment (by juga):

 We should probably archive our own GH clones so that other people do not
 clone or open issues on them.

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

[tor-bugs] #27398 [Core Tor/sbws]: Create GH/torproject/sbws repository

[Tor Bug Tracker & Wiki]

#27398: Create GH/torproject/sbws repository
---+
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/sbws  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:  teor
  Sponsor: |
---+
 As commented in network-team ml, we should create:
 - a repository called sbws in GH/torproject
 - give permissions to pastly, teor, juga to that repository
 - push current GH/pastly/simple-bw-scanner master to it
 - remove GH/torproject/simple-bw-scanner

 When that is done, we can create other ticket to sync that repository with
 .git.tpo/sbws

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

Re: [tor-bugs] #23082 [Core Tor/Tor]: tor_addr_parse is overly permissive

[Tor Bug Tracker & Wiki]

#23082: tor_addr_parse is overly permissive
-+--
 Reporter:  dcf  |  Owner:  rl1987
 Type:  defect   | Status:  accepted
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:  Tor: unspecified
 Severity:  Normal   | Resolution:
 Keywords:  032-unreached, ipv6  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by rl1987):

 * owner:  (none) => rl1987
 * 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] #17873 [Core Tor/Tor]: replacing 0.0.0.0 listeners at runtime fails

[Tor Bug Tracker & Wiki]

#17873: replacing 0.0.0.0 listeners at runtime fails
-+-
 Reporter:  cypherpunks  |  Owner:  rl1987
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, port, bind, switching,   |  Actual Points:
  035-triaged-in-20180711|
Parent ID:   | Points:
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by rl1987):

 * status:  needs_revision => needs_review


Comment:

 Pushed one more commit and responded to comments on pull request.

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

Re: [tor-bugs] #27385 [Obfuscation/Snowflake]: https://snowflake.torproject.org/embed is confusing

[Tor Bug Tracker & Wiki]

#27385: https://snowflake.torproject.org/embed is confusing
---+
 Reporter:  cypherpunks3   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords:  snowflake, ux-team |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by cypherpunks3):

 @antonela

 I get `Maximum number of external links per post exceeded` and captcha
 seems to be broken so here's my response:

 
https://privatebin.net/?40710214fdb2158e#kXFrvLMQnbszkao1cVk5/BPHJZNX+a4JKwKFWb46JWU=

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

Re: [tor-bugs] #27385 [Obfuscation/Snowflake]: https://snowflake.torproject.org/embed is confusing

[Tor Bug Tracker & Wiki]

#27385: https://snowflake.torproject.org/embed is confusing
---+
 Reporter:  cypherpunks3   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords:  snowflake, ux-team |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by antonela):

 hi, i came back and i have questions

 The user flow is described as:

 1. Volunteers visit websites which host the “snowflake” proxy `(where does
 it happen? On Tor Browser? any browser?)`.
 2. Tor clients `(do you mean relays or the browser?)` automatically find
 available browser proxies via the Broker (the domain fronted signaling
 channel).
 3. Tor client and browser proxy establish a WebRTC peer connection
 `(where?)`.
 4. Proxy connects to some relay `(to another tor client?)`.
 5. Tor occurs `(what it means? that tor gets 100% bootstrapped?)`.

 So, we have two types of users:

 1. people who host snowflake
 2. people who "activate" snowflake

 Lets back to the 1. item, what do you need from users at this moment?

 - Do we want users clicking at the snowflake badge to open a new tab?

 In which of the above steps does occur that the user **clicks** at the
 badge and get moved to [https://keroserene.net/snowflake/options.html]?
 And, when the user arrives there, what we need?

 - We need the browser client with webRTC enabled.
 - We need a user who agreed on saving the world - clicked on YES.

 I'm experimenting with using a natural-language user interface to improve
 `options.html.` The action is very simple and I don't think we need any
 more UI artifact to encourage the user’s action.

 0
 Do you want to help censored users access the Tor network?
 Some description of what is happening. You can go a bit technical
 here.
 [Yes] [I want to learn more]

 1

 We need WebRTC to work. [Enable WebRTC]

 2.0

 Snowflake Proxy is ACTIVE.
 Thank you for contributing to internet freedom! [OFF Snowflake]

 2.1

 Snowflake Proxy is OFF.
 Do you want to help censored users access the Tor network? [Activate
 Snowflake]

 I made a quick prototype, you can click it here
 https://marvelapp.com/ebf367j/screen/47360204


 ** The badge**
 I made two options for a better badge. Can we still animate it when is
 enabled like now? Can I animate it with a little css? What do you think
 about to have it rotating when is active? :)

 Check a quick prototype [https://snowfl4k3.glitch.me/
 https://snowfl4k3.glitch.me/]

 If we export/use svgs, then the site owners can customize the snowflake
 icon color so easy.


 Sorry if I'm asking basic questions, i just want to be sure that i
 understand all the flow.

 Let me know what do you think!

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

Re: [tor-bugs] #27389 [Core Tor/Tor]: Appveyor Windows 64-bit builds fail because the compiler is broken

[Tor Bug Tracker & Wiki]

#27389: Appveyor Windows 64-bit builds fail because the compiler is broken
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:
  |  needs_review
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.3.4.1-alpha
 Severity:  Major | Resolution:
 Keywords:  035-must, 034-must, 034-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 This has come up before, but as an issue caused by failures during
 configure.  If this is failing, it probably means one of two things:

1. that the compiler itself is unreliable.
2. That we have something happening during configure that is making all
 the subsequent compiler calls fail.

 In this case, it would be extremely handy for us to look at config.log, so
 that we can make sure this isn't our bug, before we go ahead and allow
 failures with this build.

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

Re: [tor-bugs] #27388 [Core Tor/Tor]: is_extrainfo in comment of router_parse_list_from_string() should be want_extrainfo

[Tor Bug Tracker & Wiki]

#27388: is_extrainfo in comment of router_parse_list_from_string() should be
want_extrainfo
--+
 Reporter:  neel  |  Owner:  neel
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  doc, comment  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 merged!

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

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

[Tor Bug Tracker & Wiki]

#24104: Delay descriptor bandwidth reporting on established relays
-+-
 Reporter:  teor |  Owner:  juga
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-backport-maybe, 033-backport-|  Actual Points:
  maybe, 032-backport-maybe, 029-backport-   |
  maybe, security-low, guard-discovery-stats,|
  chutney-wants, bwauth-wants,   |
  034-triage-20180328, 034-removed-20180328, |
  tor-bwauth, 031-unreached-backport-maybe, 035  |
  -triaged-in-20180711   |
Parent ID:  #25925   | Points:  1
 Reviewer:  ahf  |Sponsor:
-+-

Comment (by nickm):

 arma, you okay with this now?  I'm planning to merge it soon unless
 somebody objects

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

Re: [tor-bugs] #27397 [Applications/Tor Browser]: Add arma's key C218525819F78451 to ./keyring/tor.gpg

[Tor Bug Tracker & Wiki]

#27397: Add arma's key C218525819F78451 to ./keyring/tor.gpg
+--
 Reporter:  boklm   |  Owner:  tbb-team
 Type:  defect  | Status:  closed
 Priority:  Immediate   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tbb-rbm, TorBrowserTeam201808R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

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


Comment:

 Fixed with commit 4247dac61d501c2118a0a096fed453c04ba01ce8 on `master`,
 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] #27397 [Applications/Tor Browser]: Add arma's key C218525819F78451 to ./keyring/tor.gpg

[Tor Bug Tracker & Wiki]

#27397: Add arma's key C218525819F78451 to ./keyring/tor.gpg
+--
 Reporter:  boklm   |  Owner:  tbb-team
 Type:  defect  | Status:  needs_review
 Priority:  Immediate   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201808R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by boklm):

 * keywords:  tbb-rbm, TorBrowserTeam201808 => tbb-rbm,
   TorBrowserTeam201808R
 * status:  new => needs_review


Comment:

 This is done in commit `4247dac61d501c2118a0a096fed453c04ba01ce8` branch
 `bug_27397`:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_27397=4247dac61d501c2118a0a096fed453c04ba01ce8

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27397 [Applications/Tor Browser]: Add arma's key C218525819F78451 to ./keyring/tor.gpg

[Tor Bug Tracker & Wiki]

#27397: Add arma's key C218525819F78451 to ./keyring/tor.gpg
-+-
 Reporter:  boklm|  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Immediate|  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-rbm,
 Severity:  Normal   |  TorBrowserTeam201808
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 The build of `tbb-8.0-build1` is failing with the following error:
 {{{
 Error: tor-0.3.3.9 is not a signed tag
 }}}

 The reason is that `tor-0.3.3.9` is signed using arma's key, which is
 missing from `./keyring/tor.gpg`.

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

Re: [tor-bugs] #27305 [Webpages/Website]: create a download page for TBA on torproject.org

[Tor Bug Tracker & Wiki]

#27305: create a download page for TBA on torproject.org
--+
 Reporter:  isabela   |  Owner:
  |  traumschule
 Type:  task  | Status:
  |  needs_review
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201808  |  Actual Points:
Parent ID:  #26531| Points:
 Reviewer:|Sponsor:  Sponsor8
--+

Comment (by traumschule):

 the signature link does not work yet - should probably point to
 https://www.torproject.org/dist/torbrowser/mobile/1.0a1/tor-browser-
 android-arm-1.0a1.apk.asc

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

Re: [tor-bugs] #26818 [Core Tor/Tor]: Use NSS for RSA

[Tor Bug Tracker & Wiki]

#26818: Use NSS for RSA
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  035-roadmap-subticket, 035-triaged-  |  Actual Points:
  in-20180711|
Parent ID:  #26631   | Points:
 Reviewer:  asn  |Sponsor:
 |  Sponsor8-can
-+-

Comment (by asn):

 Seems like only minor stuff remain on GH review wrt
 `crypto_pk_check_key()` and family. After these are resolved/discussed we
 can merge_ready 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] #26345 [Applications/Tor Browser]: Disable tracking protection UI in FF67-esr

[Tor Bug Tracker & Wiki]

#26345: Disable tracking protection UI in FF67-esr
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff68-esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks3):

 Official announcement: https://blog.mozilla.org/futurereleases/2018/08/30
 /changing-our-approach-to-anti-tracking/

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

Re: [tor-bugs] #27392 [Applications/Tor Launcher]: Moat url update

[Tor Bug Tracker & Wiki]

#27392: Moat url update
---+
 Reporter:  hiro   |  Owner:  brade
 Type:  defect | Status:  closed
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by hiro):

 I am trying to understand why I always get one bridge. I believe this is
 because I see an error in my logs about not enough bridges of the type
 specified to fulfill the request.

 I have been talking to Matt to see if is it something in my configs.

 Meanwhile I have generated more captchas so that one gets a new one with
 every request.

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

Re: [tor-bugs] #27394 [Internal Services/Service - git]: Please delete four of my unused Git repositories and create four new ones (was: Please delete four of my unused Git repositories and create thr

[Tor Bug Tracker & Wiki]

#27394: Please delete four of my unused Git repositories and create four new 
ones
-+
 Reporter:  karsten  |  Owner:  tor-gitadm
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Old description:

> Please delete the following four of my user Git repositories that are
> empty and that I'm not planning to use anymore:
>
>  - karsten/metrics-tasks
>  - user/karsten/atlas
>  - user/karsten/tor-animation
>  - user/karsten/tor-brochure
>
> At the same time, please create the following three user Git
> repositories:
>
>  - user/karsten/collector (Karsten's collector repository)
>  - user/karsten/metrics-tasks (Karsten's metrics-tasks repository)
>  - user/karsten/metrics-web (Karsten's metrics-web repository)
>
> As soon as my repositories karsten/metrics-db and karsten/metrics-web are
> not used anymore, I'll create another ticket to request their deletion.
> That may still take a while, though.
>
> Thanks!

New description:

 Please delete the following four of my user Git repositories that are
 empty and that I'm not planning to use anymore:

  - karsten/metrics-tasks
  - user/karsten/atlas
  - user/karsten/tor-animation
  - user/karsten/tor-brochure

 At the same time, please create the following four user Git repositories:

  - user/karsten/collector (Karsten's collector repository)
  - user/karsten/metrics-tasks (Karsten's metrics-tasks repository)
  - user/karsten/metrics-web (Karsten's metrics-web repository)
  - user/karsten/tor (Karsten's tor repository)

 As soon as my repositories karsten/metrics-db and karsten/metrics-web are
 not used anymore, I'll create another ticket to request their deletion.
 That may still take a while, though.

 Thanks!

--

Comment (by karsten):

 Oh, I guess I'll also need a tor repository. Updated summary and
 description.

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

Re: [tor-bugs] #27356 [Metrics/ExoneraTor]: Reduce database size and variance of query response times

[Tor Bug Tracker & Wiki]

#27356: Reduce database size and variance of query response times
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by karsten):

 So, while testing, I found that the query for the first loop takes almost
 forever. I aborted it after 1.5 days and ran `EXPLAIN ANALYZE` on it:

 {{{
 exonerator=> EXPLAIN ANALYZE SELECT * FROM statusentry ORDER BY
 fingerprint, validafter;
  QUERY
 PLAN
 

  Sort  (cost=330924653.28..331942841.44 rows=407275264 width=335) (actual
 time=150799260.447..160427618.123 rows=407470751 loops=1)
Sort Key: fingerprint, validafter
Sort Method: external merge  Disk: 132839640kB
->  Seq Scan on statusentry  (cost=0.00..22111634.64 rows=407275264
 width=335) (actual time=120.830..4751991.603 rows=407470751 loops=1)
  Planning time: 37.125 ms
  Execution time: 160482588.895 ms
 (6 rows)
 }}}

 Admittedly, this looks okay. Just to be clear, that's over 1 day and 20
 hours before we even start copying the first row!

 I tweaked the logging to make that clearer. I also made another trivial
 code style change that shouldn't have any effect. Please find commits
 
[https://gitweb.torproject.org/user/karsten/exonerator.git/commit/?h=task-27356=2cb74cd9bb6858b5442442f70667cdf5db75013f
 2cb74cd] and
 
[https://gitweb.torproject.org/user/karsten/exonerator.git/commit/?h=task-27356=deec83da277e5921977a17dd38262f7f91d93e7d
 deec83d] in the same branch mentioned above.

 I'll hold off running more tests until the SSD that I ordered yesterday
 arrives. I figured that if the query alone takes almost 2 days, that the
 rest of the migration might take many more days or even weeks. Might have
 been a bit optimistic that an HDD would do the job. Hopefully that will be
 tomorrow, so I might start another test run this weekend or early next
 week at the latest.

 Still in need for 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] #27396 [Applications/Tor Launcher]: Don't track progress.dtd in the import translations script anymore

[Tor Bug Tracker & Wiki]

#27396: Don't track progress.dtd in the import translations script anymore
---+--
 Reporter:  gk |  Owner:  brade
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201808R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gk):

 * keywords:   => TorBrowserTeam201808R
 * status:  new => needs_review


Comment:

 `bug_27396` (https://gitweb.torproject.org/user/gk/tor-
 launcher.git/commit/?h=bug_27396=5caf6b9c3d65198d00b6d0f6cecebb90ff7f2a28)
 has a fixup for 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

[tor-bugs] #27396 [Applications/Tor Launcher]: Don't track progress.dtd in the import translations script anymore

[Tor Bug Tracker & Wiki]

#27396: Don't track progress.dtd in the import translations script anymore
---+---
 Reporter:  gk |  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+---
 A while back when redoing our progress bar (#23262) we essentially got rid
 of `progress.dtd` but forgot to untrack that file while importing
 translations. This is leaving confusing state in a local tor-launcher
 repository.

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