Re: [tor-bugs] #25639 [Core Tor/Tor]: think about Rust crate boundaries

[Tor Bug Tracker & Wiki]

#25639: think about Rust crate boundaries
--+--
 Reporter:  Hello71   |  Owner:  Hello71
 Type:  enhancement   | Status:  assigned
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by chelseakomlo):

 Replying to [comment:6 Hello71]:

 > Replying to [comment:2 chelseakomlo]:
 > > I don't think is a good idea. I agree this makes it simpler in the
 short term but this won't scale well. I.e, we definitely want more
 modularity in Rust/new code, not less.
 > >
 > > Have you looked at how Servo handles this problem?
 https://github.com/servo/servo I think we should consult more Mozilla
 people about how they have handled issues like running tests, linking,
 etc.
 >
 > I will investigate. AIUI their situation is different though: servo is
 intended to be a fully enclosed module, if primarily intended for use in a
 single application, whereas in Tor we have tight coupling between
 everything. possibly we should consider having several distinct modules,
 but in that case we need to discuss how we draw those lines;

 Yes, that is fair. We most likely won't get these lines exactly correct
 right now though, so let's plan on having several distinct modules, and
 being able to evolve this as we learn/refactor code, etc. I think this
 ticket should be an ongoing discussion, as opposed to "let's hammer out
 our architecture right now." Flexibility will be a good asset here :)

 It is a good point about documentation for module planning- I have some
 rough notes, as does a few other people. We will compile these and make
 them available.

 > doc/HACKING/CodingStandardsRust.md:
 > > If your Rust code must call out to parts of Tor's C code, you must
 > > declare the functions you are calling in the `external` crate, located
 > > at `.../src/rust/external`.

 Yes, this should be followed. And we can talk about whether modifying this
 approach makes sense- maybe every crate has an `external.rs`, for example.
 But isolating our external C dependencies is a good idea for enforcing
 clean Rust/C boundaries.

 > Replying to [comment:3 chelseakomlo]:
 > > Have you looked at how building is handled in `tor_rust/lib.rs`?
 >
 > I think you mean `tor_rust/Cargo.toml`? Yeah, I understand how it works
 now, I just don't think it's a good system. I'm open to being convinced
 otherwise though.

 This is taken from Gecko project structure, it would be worth talking to
 them about this setup and any issues we've had with it thus far- maybe
 they have already ran into these problems and have ideas about them?


 > I will investigate.

 Thank you! This is definitely a lot of work, but getting this right will
 help us have a sane/maintainable project structure into the future. Thanks
 for the effort and looking further into what our options are.

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

Re: [tor-bugs] #25659 [Applications/Tor Browser]: Race-condition loading add-ons in Orfox

[Tor Bug Tracker & Wiki]

#25659: Race-condition loading add-ons in Orfox
--+---
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by sysrqb):

 * status:  new => needs_information


Comment:

 Okay, now I'm not sure if this is a bug - it may be working-as-intended. I
 reinstalled the app from f-droid and the add-on is enabled on the second-
 run. I'll continue playing with this and see if I can reproduce the
 original issue. I wonder if I wasn't patient enough earlier.

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

Re: [tor-bugs] #25659 [Applications/Tor Browser]: Race-condition loading add-ons in Orfox

[Tor Bug Tracker & Wiki]

#25659: Race-condition loading add-ons in Orfox
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sysrqb):

 Replying to [comment:2 sysrqb]:
 > I wonder what happens if I clear the app's cache/data and start fresh,
 but toggle extension.logging.enabled so it is enabled on first-run but
 disabled on second-run. Does the logging make a difference?

 No, logging did not make a difference here. It finished installing after
 restarting.

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

Re: [tor-bugs] #25659 [Applications/Tor Browser]: Race-condition loading add-ons in Orfox

[Tor Bug Tracker & Wiki]

#25659: Race-condition loading add-ons in Orfox
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sysrqb):

 hm. I built a new apk with `extensions.logging.enabled = true` so we get
 logging on first-run.

 {{{
 I/Gecko   (28133): 1522192347000addons.xpi  DEBUG   Addon
 https-everywh...@eff.org will be installed as a packed xpi
 I/Gecko   (28133): 1522192347000addons.xpi  DEBUG   Addon tor-
 browser-setti...@torproject.org will be installed as a packed xpi
 I/Gecko   (28133): 1522192347100addons.xpi  DEBUG   Addon
 {73a6fe31-595d-460b-a920-fcc0f8843232} will be installed as a packed xpi
 I/Gecko   (28133): 1522192347100addons.xpi  DEBUG   Staged
 install of https-everywh...@eff.org from
 file:///data/data/info.guardianproject.orfox/distribution/extensions
 /https-everywh...@eff.org.xpi ready; waiting for restart.
 }}}

 `Staged install of https-everywh...@eff.org [...] ready; waiting for
 restart.`

 This doesn't explain why it isn't loaded after restarting the app, but
 this explains why it isn't loaded on first-run. With this install, it is
 loaded after restarting the app.

 {{{
 I/Gecko   (28760): 1522193195700addons.xpi  DEBUG   Found
 updated metadata for https-everywh...@eff.org in app-profile
 I/Gecko   (28760): 1522193195700addons.xpi  DEBUG   Processing
 install of https-everywh...@eff.org in app-profile
 }}}

 I wonder what happens if I clear the app's cache/data and start fresh, but
 toggle extension.logging.enabled so it is enabled on first-run but
 disabled on second-run. Does the logging make a difference?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25660 [Applications/Tor Browser]: Remove "New Private Window" option from Tor Browser or make it a separate session

[Tor Bug Tracker & Wiki]

#25660: Remove "New Private Window" option from Tor Browser or make it a 
separate
session
--+--
 Reporter:  steph |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 It doesn't do anything that I can tell. If it does, we should have more of
 an explanation to set user expectation.

 For instance, I thought perhaps when I was logged into Twitter in another
 tab, it might isolate a separate session, but it does not. If I go to
 twitter.com in a "New Private Window", I am still logged into the same
 account.

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

Re: [tor-bugs] #24456 [Core Tor/Tor]: Figure out what to do with the guardfraction feature

[Tor Bug Tracker & Wiki]

#24456: Figure out what to do with the guardfraction feature
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth, tor-guard, review-  |  Actual Points:
  group-32, review-group-33, review-group-34,|
  033-triage-20180320, 033-included-20180320 |
Parent ID:   | Points:  2
 Reviewer:  mikeperry|Sponsor:
-+-

Comment (by mikeperry):

 Replying to [comment:21 teor]:
 > If mike is correct, and the guardfraction code isolated and won't
 require maintenance effort, we can remove the code now, and "git revert"
 that commit later.
 >
 > If a revert won't work later, then the code does actually require
 maintainence effort.

 Having maintained a fork before, I can say that this is not true. Diffs
 that are otherwise untouched can be broken simply by modifying or
 relocating surrounding but unrelated lines.

 In particular, this code touches the consensus weights. When we update
 these weights for padding in #8453, it will be much easier to avoid making
 changes that would break or simply conflict with this code if it is right
 there where we can see it. When we perform those padding updates (and
 other consensus changes), we're likely to want to have a testing
 framework, which will make verifying the fix in #16255 easier as well.

 If we take the minimum change here (ie asn/bug24456_032), the OBSOLETE
 macro will cause these config entries to be ignored, so that as soon as it
 is deployed, dirauths will stop reading the guardfraction files
 automatically.

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

Re: [tor-bugs] #25629 [Core Tor/Tor]: fix CID 1430932

[Tor Bug Tracker & Wiki]

#25629: fix CID 1430932
-+-
 Reporter:  catalyst |  Owner:
 |  catalyst
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  033-must regression 029-backport |  Actual Points:
  031-backport 032-backport 033-triage-20180326  |
  033-included-20180326  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 whoa.  Thanks, Taylor -- that was more branches than I thought it would
 be, but they all look fine!

 Merging to appropriate targets and 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] #25629 [Core Tor/Tor]: fix CID 1430932

[Tor Bug Tracker & Wiki]

#25629: fix CID 1430932
-+-
 Reporter:  catalyst |  Owner:
 |  catalyst
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  033-must regression 029-backport |  Actual Points:
  031-backport 032-backport 033-triage-20180326  |
  033-included-20180326  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by catalyst):

 * status:  assigned => needs_review


Old description:



New description:

 Coverity found a null pointer reference in nodelist_add_microdesc().
 This is almost certainly impossible assuming that the routerstatus_t
 returned by router_get_consensus_status_by_descriptor_digest() always
 corresponds to an entry in the nodelist.

--

Comment:

 Added description.  Pull requests with patches:

 0.2.9 and 0.3.1: https://github.com/torproject/tor/pull/30

 0.3.2: https://github.com/torproject/tor/pull/31

 0.3.3 and master: https://github.com/torproject/tor/pull/32

 0.2.9 merges cleanly to 0.3.1; 0.3.3 merges cleanly to master.

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

Re: [tor-bugs] #25552 [Core Tor/Tor]: prop224: Onion service rev counters are useless and actually harmful for scalability

[Tor Bug Tracker & Wiki]

#25552: prop224: Onion service rev counters are useless and actually harmful for
scalability
+--
 Reporter:  asn |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:  Tor: 0.3.1.9
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs prop224  |  Actual Points:
Parent ID:  | Points:  4
 Reviewer:  |Sponsor:
+--

Comment (by teor):

 This issue was originally reported in #25124 as a bug in Stem.

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

Re: [tor-bugs] #25124 [Core Tor/Stem]: Self-generated v3 Onion Service keys and addresses (was: Stem v3 Onion Service support)

[Tor Bug Tracker & Wiki]

#25124: Self-generated v3 Onion Service keys and addresses
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  atagar
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * status:  needs_information => new
 * type:  defect => enhancement


Comment:

 In #25552, we decided to remove revision counter checks on HSDirs.

 The remaining issue in this ticket is about generating onion addresses
 using your own entropy.
 That's a feature that Stem could support, or you could write a simple
 script to do it, or we could add a command-line option to tor.

 It's unlikely to happen in Tor, so please write your own script, or submit
 a patch to Stem.

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

 * cc: arthuredelstein (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] #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 mikeperry):

 Replying to [comment:24 arma]:
 > Replying to [comment:20 dgoulet]:
 > > Datapoint: #9072
 >
 > This old ticket is really important here, because there was an earlier
 ticket (#9063) that proposed to limit the number of cells in-flight on a
 circuit, and #9072 is arguing that it opens up a bad guard discovery
 attack.
 >
 > Mind you, when I opened #9072, it was simply about how our protocol
 actually allows a huge number of cells in-flight, because non-data cells
 don't count in the sendme windows, so there is no easy small number where
 if a circuit goes over you know it's violating protocol.
 >
 > Mike was the one who retitled my ticket to be about guard discovery
 attacks. He says:
 > {{{
 > The attack enabled by #9063 is extremely similar to the Guard discovery
 attack from rpw's paper.
 > }}}
 >
 > I wonder what the guard discovery attack actually is? Nobody says what
 it is on that ticket.
 >
 > So it would seem smart to reconstruct what it was we were worried about,
 to figure out if we should still be worried.
 >
 > I am bringing Mikeperry back into this ticket so he can channel his
 five-year-earlier self and tell us what the danger is.

 The attack in #9072 was due to allowing a small, fixed amount of stream
 creates in flight to kill the circuit. If this number is small and
 predicable, a malicious website can create that many streams to cause the
 circuit to fail, at which point Tor will rebuild a new one on a new path.
 The website gets to rinse and repeat, and create enough circuits until one
 of its middles is chosen next to the guard.

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

Re: [tor-bugs] #25659 [Applications/Tor Browser]: Race-condition loading add-ons in Orfox

[Tor Bug Tracker & Wiki]

#25659: Race-condition loading add-ons in Orfox
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sysrqb):

 (This may be the first known example of "Mozilla don't support ESR on
 mobile".)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25659 [Applications/Tor Browser]: Race-condition loading add-ons in Orfox

[Tor Bug Tracker & Wiki]

#25659: Race-condition loading add-ons in Orfox
--+
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-mobile
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 It seems like there is a race condition when loading add-on at first-
 install/run. We noticed https-everywhere sometimes is not installed after
 freshly installing Orfox.

 Is this a regressions from 52.2.x?

 When https-everywhere is not installed during the first-run after
 installing, the .xpi is copied into /extensions/staged/ but
 it remains there. Restarting the app does not cause it to be installed.

 However, we found Orfox does install the https-everywhere extension if we
 disable the NoScriptAnywhere (NSA) extensions and then restart the app.

 But it seems NSA is not the cause of this problem because after
 reinstalling the Orfox app (and confirming https-everywhere was not
 installed), we found https-everywhere is installed after toggling
 `extensions.logging.enabled` and then restarting the app. Maybe the extra
 logging slows the app enough.

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

Re: [tor-bugs] #25617 [Core Tor/Tor]: unable to resolve DNS requests from control port, regression

[Tor Bug Tracker & Wiki]

#25617: unable to resolve DNS requests from control port, regression
-+-
 Reporter:  starlight|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, tor-dns, tor-control,|  Actual Points:
  033-must   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Looks like the fix should go in dnsserv_launch_request() down when we're
 messing with {{{entry_conn->entry_cfg}}}.

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

Re: [tor-bugs] #25355 [Core Tor/Tor]: Add option to set the facility of the syslog log backend dynamically

[Tor Bug Tracker & Wiki]

#25355: Add option to set the facility of the syslog log backend dynamically
-+
 Reporter:  ahf  |  Owner:  (none)
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-34  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  mikeperry|Sponsor:
-+
Changes (by ahf):

 * status:  needs_revision => needs_review


Comment:

 Thanks. Should be fixed in the fixup commit.

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

Re: [tor-bugs] #25617 [Core Tor/Tor]: unable to resolve DNS requests from control port, regression

[Tor Bug Tracker & Wiki]

#25617: unable to resolve DNS requests from control port, regression
-+-
 Reporter:  starlight|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, tor-dns, tor-control,|  Actual Points:
  033-must   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Looks like that feature went into 0.2.9.3-alpha, as part of #18693.

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

Re: [tor-bugs] #24243 [Applications/Tor Browser]: Tor Browser only render HTML for local pages via file://, no images/CSS

[Tor Bug Tracker & Wiki]

#24243: Tor Browser only render HTML for local pages via file://, no images/CSS
--+--
 Reporter:  anonym|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  AffectsTails  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sajolida):

 Amazing gk! Thanks for the 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] #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 arma):

 Replying to [comment:24 arma]:
 > our protocol actually allows a huge number of cells in-flight, because
 non-data cells don't count in the sendme windows

 One of the proposed longer term fixes here is to make all kinds of relay
 cells count in the sendme windows. Then you wouldn't have these weird side
 channel issues.

 The first problem to solve if we want to do that is the deadlock question:
 if both sides have exhausted their package window, then nobody can
 acknowledge anything, and they're stuck. This one could be solved by
 making only sendme cells be an exception to sendme windows, which still
 lets us keep to a quite limited number of in-flight cells.

 After that one, there might be other issues, like "I can't send these end
 cells until I've gotten a sendme from you", or "I can't send this begin
 cell until I've gotten a sendme", which aren't the end of the world but
 might produce some surprising usability issues.

 It's worth exploring more in case we can convince ourselves the benefits
 outweigh the costs!

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

Re: [tor-bugs] #25633 [Applications/Tor Browser]: Ctrl-D makes it too easy to create bookmarks accidentally

[Tor Bug Tracker & Wiki]

#25633: Ctrl-D makes it too easy to create bookmarks accidentally
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-disk-leak |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 Replying to [ticket:25633 cypherpunks]:
 > A few releases ago, Firefox changed this behavior.  Now, Ctrl-D creates
 a bookmark

 When they changed the behavior, did they leave the old behavior in place,
 maybe behind an about:config option? That would sure be convenient if so,
 so it's worth looking into. :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25658 [Applications/Tor Browser]: Actity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Actity 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|   Keywords:  ux-team
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor17 |
--+--
 This work is related to the following proposal:

 !https://lists.torproject.org/pipermail/tbb-dev/2018-March/000799.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] #25415 [Core Tor/Tor]: moria1 seg faults on testing relay reachability

[Tor Bug Tracker & Wiki]

#25415: moria1 seg faults on testing relay reachability
-+-
 Reporter:  arma |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.2-alpha
 Severity:  Blocker  | Resolution:  fixed
 Keywords:  tor-dirauth, crash, 033-must,|  Actual Points:
  review-group-34|
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Ok, I just hit this on moria1 again (after it suffered a sad power loss
 mid thought). I started moria1 three times and it died quickly each time.

 Then I did a git pull to a later version that has this patch, and
 restarted, and it did not die.

 I'm calling that a good sign that this bug is 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] #25644 [Metrics/CollecTor]: Write white paper about CollecTor's data processing (Sponsor13, 1)

[Tor Bug Tracker & Wiki]

#25644: Write white paper about CollecTor's data processing (Sponsor13, 1)
---+--
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  task   | Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 Replying to [comment:1 iwakeh]:
 > Starting on this with the background from last year's tech report.

 Sounds great!

 > Which frameworks should we not forget to look at?

 Uhhmmm, fine question. How about Java EE and Spring?

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

Re: [tor-bugs] #25654 [Core Tor/Tor]: Create a testing-only handshake for shaking the bugs out of wide create cells (prop249)

[Tor Bug Tracker & Wiki]

#25654: Create a testing-only handshake for shaking the bugs out of wide create
cells (prop249)
--+
 Reporter:  nickm |  Owner:  isis
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-cell tor-circuit trunnel  |  Actual Points:
Parent ID:  #24986| Points:
 Reviewer:|Sponsor:
--+
Changes (by isis):

 * owner:  (none) => isis
 * status:  new => accepted


Comment:

 Assigning the crazypants handshake to myself, since I'll need to touch
 this part of the codebase (or at least become super familiar with it) for
 #24988.

 Also, depending on timing of when things are finished, it might be
 possible to use the work from #24987 (since it composes two handshakes by
 taking function pointers to the implementations) to chain ntor+ntor to
 accomplish this task… that would involve no (or very little) new code.

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

Re: [tor-bugs] #25022 [Metrics/Website]: Convert all scripts used for building to Ant tasks

[Tor Bug Tracker & Wiki]

#25022: Convert all scripts used for building to Ant tasks
-+--
 Reporter:  iwakeh   |  Owner:  iwakeh, metrics-team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

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


Comment:

 Great, merged! 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] #25646 [Core Tor/Tor]: Incorporate discussion outcomes into prop249 (wide create cells)

[Tor Bug Tracker & Wiki]

#25646: Incorporate discussion outcomes into prop249 (wide create cells)
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-cell tor-circuit trunnel  |  Actual Points:
Parent ID:  #24986| Points:  .2
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * owner:  (none) => nickm
 * status:  new => accepted
 * points:   => .2


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

Re: [tor-bugs] #25647 [Core Tor/Tor]: Encoding/decoding logic for wide create(d) and extend(ed) cells

[Tor Bug Tracker & Wiki]

#25647: Encoding/decoding logic for wide create(d) and extend(ed) cells
--+
 Reporter:  nickm |  Owner:  isis
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-cell tor-circuit trunnel  |  Actual Points:
Parent ID:  #24986| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #24243 [Applications/Tor Browser]: Tor Browser only render HTML for local pages via file://, no images/CSS

[Tor Bug Tracker & Wiki]

#24243: Tor Browser only render HTML for local pages via file://, no images/CSS
--+--
 Reporter:  anonym|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  AffectsTails  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * Attachment "local-css-inline-tb.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

[tor-bugs] #25657 [Core Tor/Tor]: prop249: make sure that we incorporate fragmented extend[ed]2 cells in our OOM code

[Tor Bug Tracker & Wiki]

#25657: prop249: make sure that we incorporate fragmented extend[ed]2 cells in 
our
OOM code
--+--
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-cell tor-circuit trunnel
Actual Points:|  Parent ID:  #25651
   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] #24243 [Applications/Tor Browser]: Tor Browser only render HTML for local pages via file://, no images/CSS

[Tor Bug Tracker & Wiki]

#24243: Tor Browser only render HTML for local pages via file://, no images/CSS
--+--
 Reporter:  anonym|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  AffectsTails  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:9 cypherpunks]:
 > IIRC using inline CSS (i.e. internal style sheet `...`)
 works, so why not try that? :)
 I can confirm this, here's a test .html for that:

 {{{
 
 
 @keyframes bouncing-loader {
   from {
 opacity: 1;
 transform: translateY(0);
   }
   to {
 opacity: 0.1;
 transform: translateY(-3rem);
   }
 }
 .bouncing-loader {
   display: flex;
   justify-content: center;
 }
 .bouncing-loader > div {
   width: 2rem;
   height: 2rem;
   margin: 3rem 0.2rem;
   background: #4185aa;
   border-radius: 50%;
   animation: bouncing-loader 0.2s infinite alternate;
 }
 .bouncing-loader > div:nth-child(2) {
   animation-delay: 0.2s;
 }
 .bouncing-loader > div:nth-child(3) {
   animation-delay: 0.4s;
 }
 .bouncing-loader > div:nth-child(4) {
   animation-delay: 0.6s;
 }
 .bouncing-loader > div:nth-child(5) {
   animation-delay: 0.8s;
 }
 .bouncing-loader > div:nth-child(6) {
   animation-delay: 1s;
 }
 .bouncing-loader > div:nth-child(7) {
   animation-delay: 1.2s;
 }
 .bouncing-loader > div:nth-child(8) {
   animation-delay: 1.4s;
 }
 .bouncing-loader > div:nth-child(9) {
   animation-delay: 1.6s;
 }
 .bouncing-loader > div:nth-child(10) {
   animation-delay: 1.8s;
 }
 .bouncing-loader > div:nth-child(11) {
   animation-delay: 2s;
 }
 .bouncing-loader > div:nth-child(12) {
   animation-delay: 2.2s;
 }
 .bouncing-loader > div:nth-child(7) {
   animation-delay: 1.2s;
 }


 

 
 
   
   
   
   
   
   
   
   
   
   
   
   
 
 
 
 }}}

 [[Image(local-css-inline-tb.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] #25656 [Core Tor/Tor]: Fuzzing code for prop249 (wide creates)

[Tor Bug Tracker & Wiki]

#25656: Fuzzing code for prop249 (wide creates)
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-cell tor-circuit trunnel  |  Actual Points:
Parent ID:  #24986| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * parent:  #25655 => #24986


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

Re: [tor-bugs] #25655 [Core Tor/Tor]: Integration testing of prop249

[Tor Bug Tracker & Wiki]

#25655: Integration testing of prop249
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-cell tor-circuit trunnel  |  Actual Points:
Parent ID:  #24986| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * parent:  #25654 => #24986


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

 * cc: mikeperry (added)


Comment:

 Replying to [comment:20 dgoulet]:
 > Datapoint: #9072

 This old ticket is really important here, because there was an earlier
 ticket (#9063) that proposed to limit the number of cells in-flight on a
 circuit, and #9072 is arguing that it opens up a bad guard discovery
 attack.

 Mind you, when I opened #9072, it was simply about how our protocol
 actually allows a huge number of cells in-flight, because non-data cells
 don't count in the sendme windows, so there is no easy small number where
 if a circuit goes over you know it's violating protocol.

 Mike was the one who retitled my ticket to be about guard discovery
 attacks. He says:
 {{{
 The attack enabled by #9063 is extremely similar to the Guard discovery
 attack from rpw's paper.
 }}}

 I wonder what the guard discovery attack actually is? Nobody says what it
 is on that ticket.

 So it would seem smart to reconstruct what it was we were worried about,
 to figure out if we should still be worried.

 I am bringing Mikeperry back into this ticket so he can channel his five-
 year-earlier self and tell us what the danger is.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25656 [Core Tor/Tor]: Fuzzing code for prop249 (wide creates)

[Tor Bug Tracker & Wiki]

#25656: Fuzzing code for prop249 (wide creates)
--+--
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-cell tor-circuit trunnel
Actual Points:|  Parent ID:  #25655
   Points:|   Reviewer:
  Sponsor:|
--+--
 We should make sure that all our wide create and fragmented extend logic
 is designed in such a way as to be fuzzable, and then we should fuzz 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] #25655 [Core Tor/Tor]: Integration testing of prop249

[Tor Bug Tracker & Wiki]

#25655: Integration testing of prop249
--+--
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-cell tor-circuit trunnel
Actual Points:|  Parent ID:  #25654
   Points:|   Reviewer:
  Sponsor:|
--+--
 Once prop249 is implemented, our Chutney tests and our test network should
 use it so that we can find out if it has bugs.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25654 [Core Tor/Tor]: Create a testing-only handshake for shaking the bugs out of wide create cells (prop249)

[Tor Bug Tracker & Wiki]

#25654: Create a testing-only handshake for shaking the bugs out of wide create
cells (prop249)
--+--
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-cell tor-circuit trunnel
Actual Points:|  Parent ID:  #24986
   Points:|   Reviewer:
  Sponsor:|
--+--
 We need a handshake that doesn't fit in a single CREATE cell so that we
 can make sure that prop249 is implemented properly.

 My current recommendation is "nnttoorr", which is the same as ntor, but
 every byte is repeated twice. ;)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25653 [Core Tor/Tor]: prop249: advertise support correctly in protover subsystem; only use when protover support advertised

[Tor Bug Tracker & Wiki]

#25653: prop249: advertise support correctly in protover subsystem; only use 
when
protover support advertised
--+--
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-cell tor-circuit trunnel
Actual Points:|  Parent ID:  #24986
   Points:|   Reviewer:
  Sponsor:|
--+--
 In the link handshake and in the protover list, we should advertise
 support for CREATE2V and CREATED2V.

 In the protover list, we should advertise support for fragmented EXTEND
 cells.

 In the protover list, we should advertise support for our temporary
 testing handshake.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25652 [Core Tor/Tor]: Prop249: set RELAY_EARLY bit correctly on fragmented EXTEND cells; enforce it correctly.

[Tor Bug Tracker & Wiki]

#25652: Prop249: set RELAY_EARLY bit correctly on fragmented EXTEND cells; 
enforce
it correctly.
--+--
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-cell tor-circuit trunnel
Actual Points:|  Parent ID:  #24986
   Points:|   Reviewer:
  Sponsor:|
--+--
 The RELAY_EARLY bit gets a tiny bit more complicated with prop249; let's
 make sure we implement it correctly.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25651 [Core Tor/Tor]: Handle incoming extend2/extended2 fragmented requests/replies. (prop249)

[Tor Bug Tracker & Wiki]

#25651: Handle incoming extend2/extended2 fragmented requests/replies. (prop249)
--+--
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-cell tor-circuit trunnel
Actual Points:|  Parent ID:  #24986
   Points:|   Reviewer:
  Sponsor:|
--+--
 As part of prop249, we need to handle large create cells when they arrive
 fragmented across multiple extend cells (and similarly for created cells
 fragmented across multiple extended cells).

 Important notes:
   * The proposal says that there must be no intervening cells on the same
 circuit. We should enforce this and test it.
   * We should probably use a buf_t object to record these handshakes as
 they are being assembled.
   * We should count these handshakes against the memory usage of a circuit
 and age of the oldest queued data, so that they will participate correctly
 in the OOM system.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25650 [Core Tor/Tor]: Handle incoming create2v / created2v cells (wide create cells)

[Tor Bug Tracker & Wiki]

#25650: Handle incoming create2v / created2v cells (wide create cells)
--+--
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-cell tor-circuit trunnel
Actual Points:|  Parent ID:  #24986
   Points:|   Reviewer:
  Sponsor:|
--+--
 We need to receive create2v/created2v cells, and respond to them by
 performing or finishing the corresponding onion handshake.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25649 [Core Tor/Tor]: Send a series of extend2/extended2 cells as needed to encode a wide create/created pair (prop249)

[Tor Bug Tracker & Wiki]

#25649: Send a series of extend2/extended2 cells as needed to encode a wide
create/created pair (prop249)
--+--
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-cell tor-circuit trunnel
Actual Points:|  Parent ID:  #24986
   Points:|   Reviewer:
  Sponsor:|
--+--
 As part of prop249, we need to be able to send wide onion handshakes split
 across multiple relay cells.

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

 Replying to [comment:1 dgoulet]:
 > This is *not* trivial so I'll try to explain what I can see:
 >
 > In `append_cell_to_circuit_queue()`, there is a check on the cell queue
 for a maximum size which then makes the circuit to stop reading on the
 connection if reached:

 Careful here! You're right, but by "connection" you mean edge connection,
 or stream. Not TLS ("OR") connection.

 > Lets use the example where we are a Guard and we have an `or_circuit_t`
 with the "p_chan" being the client connection and the "n_chan" being the
 connection to the middle node.
 >
 > If we set the block on `n_chan`, we would only stop the read() if the
 circuit is origin because `p_streams` is only set on a tor client.

 Correct. That whole set_streams_blocked_on_circ() business is for
 *streams*, i.e. edge connections. Specifically, origin streams when we're
 a client, or exit streams when we're an exit.

 > Does this means that if we try to deliver a cell forward (n_chan), even
 though we've reached the high limit, we'll still queue it because there is
 never a time where we check if we are blocked on "n_chan" at the relay
 level?

 Yes.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25648 [Core Tor/Tor]: Send create2v cells as needed; send created2v cells as needed (Prop249)

[Tor Bug Tracker & Wiki]

#25648: Send create2v cells as needed; send created2v cells as needed (Prop249)
--+--
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-cell tor-circuit trunnel
Actual Points:|  Parent ID:  #24986
   Points:|   Reviewer:
  Sponsor:|
--+--
 For wide creates, we need to send wide create2v and created2v cells when
 appropriate.

 This will require checking for the advertisement of a particular protocol
 version

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

Re: [tor-bugs] #25647 [Core Tor/Tor]: Encoding/decoding logic for wide create(d) and extend(ed) cells

[Tor Bug Tracker & Wiki]

#25647: Encoding/decoding logic for wide create(d) and extend(ed) cells
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-cell tor-circuit trunnel  |  Actual Points:
Parent ID:  #24986| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Isis has some groundwork here in
 https://github.com/isislovecruft/tor/tree/bug24986

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

Re: [tor-bugs] #16472 [Applications/Tor Browser]: Upgrade Binutils to 2.25+ for Tor Browser builds

[Tor Bug Tracker & Wiki]

#16472: Upgrade Binutils to 2.25+ for Tor Browser builds
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201803,   |  Actual Points:
  boklm201803|
Parent ID:  #12968   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 After building on `build-sunet-a`, I get a different build than my build
 machine, but the same as
 https://people.torproject.org/~gk/builds/8.0a5-build1/torbrowser-install-8
 .0a5_en-US.exe.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25647 [Core Tor/Tor]: Encoding/decoding logic for wide create(d) and extend(ed) cells

[Tor Bug Tracker & Wiki]

#25647: Encoding/decoding logic for wide create(d) and extend(ed) cells
--+--
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-cell tor-circuit trunnel
Actual Points:|  Parent ID:  #24986
   Points:|   Reviewer:
  Sponsor:|
--+--
 To implement prop249, we'll need a way to encode and decode wide create
 and extend cells.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25646 [Core Tor/Tor]: Incorporate discussion outcomes into prop249 (wide create cells)

[Tor Bug Tracker & Wiki]

#25646: Incorporate discussion outcomes into prop249 (wide create cells)
--+--
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-cell tor-circuit trunnel
Actual Points:|  Parent ID:  #24986
   Points:|   Reviewer:
  Sponsor:|
--+--
 We had a discussion about prop249 with notes here:
   * http://meetbot.debian.net/tor-meeting/2017/tor-
 meeting.2017-12-13-22.03.html

 We should fold our decisions into prop249.

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

Re: [tor-bugs] #25552 [Core Tor/Tor]: prop224: Onion service rev counters are useless and actually harmful for scalability

[Tor Bug Tracker & Wiki]

#25552: prop224: Onion service rev counters are useless and actually harmful for
scalability
+--
 Reporter:  asn |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:  Tor: 0.3.1.9
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs prop224  |  Actual Points:
Parent ID:  | Points:  4
 Reviewer:  |Sponsor:
+--

Comment (by arma):

 Replying to [ticket:25552 asn]:
 > b) In the far future, when all HSDirs have upgraded to (a), rip out the
 rev counter code from onion services.

 As I understand it, HSDirs learned how to handle v3 descriptors in
 0.3.0.1-alpha, as part of #17238.

 According to
 
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases#Listofreleases
 Tor 0.3.0 is already dead. And importantly, the feature isn't in our long-
 term-stable 0.2.9.

 So as long as we get the new functionality into HSDirs before the next
 long-term-stable, the "far future" will just be a matter of waiting some
 months for intermediate stable versions to die 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] #25645 [Core Tor/Tor]: n_possible variable goes unused in channel_get_for_extend()

[Tor Bug Tracker & Wiki]

#25645: n_possible variable goes unused in channel_get_for_extend()
---+--
 Reporter:  arma   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  easy, tor-channel  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by dgoulet):

 * keywords:  easy => easy, tor-channel
 * milestone:   => Tor: unspecified


Comment:

 Seems to be coming from this HUMONGOUS commit: `838743654c1` and even at
 that commit, it isn't used in the function.

 We can safely remove this.

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

[tor-bugs] #25645 [Core Tor/Tor]: n_possible variable goes unused in channel_get_for_extend()

[Tor Bug Tracker & Wiki]

#25645: n_possible variable goes unused in channel_get_for_extend()
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  easy
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 {{{
 $ grep n_possible *.c
 channel.c:  int n_noncanonical = 0, n_possible = 0;
 channel.c:++n_possible;
 }}}

 All we do is start it off at 0, and increment it sometimes.

 Maybe it had a purpose once, but it doesn't 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] #25644 [Metrics/CollecTor]: Write white paper about CollecTor's data processing (Sponsor13, 1)

[Tor Bug Tracker & Wiki]

#25644: Write white paper about CollecTor's data processing (Sponsor13, 1)
---+--
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  task   | Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by iwakeh):

 * status:  new => accepted
 * owner:  metrics-team => iwakeh


Comment:

 Starting on this with the background from last year's tech report.

 Which frameworks should we not forget to look at?

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

 * reviewer:  armadev => arma


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25644 [Metrics/CollecTor]: Write white paper about CollecTor's data processing (Sponsor13, 1)

[Tor Bug Tracker & Wiki]

#25644: Write white paper about CollecTor's data processing (Sponsor13, 1)
---+--
 Reporter:  iwakeh |  Owner:  metrics-team
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 This should become a Tor Tech Report detailing Tor Metrics data
 collection, aggregation, and presentation as well as an overview of why
 and how data is collected compared to available other frameworks.

 This is activity 1.1 of Sponsor 13 and covers the data pipeline up to
 activity 2 (see ticket #24217).

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

Re: [tor-bugs] #24243 [Applications/Tor Browser]: Tor Browser only render HTML for local pages via file://, no images/CSS

[Tor Bug Tracker & Wiki]

#24243: Tor Browser only render HTML for local pages via file://, no images/CSS
--+--
 Reporter:  anonym|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  AffectsTails  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [comment:8 sajolida]:
 > We fixed the most important regression introduced by this bug in Tails
 by opening the "Tails documentation" launcher on our desktop on the
 production website instead of offline when people are connected to Tor.
 But we're still affected in other ways:
 >
 > * The homepage of our Unsafe Browser (used to connect to captive portal)
 is not translated anymore.
 > * We used Yelp to browser our documentation when offline but it's not as
 good as a real browser.
 > * Contributors working from Tails can't use Tor Browser anymore to work
 on our website (for example, trnaslators).
 >
 > So yep, we're interested in knowing if this bug is planned to be fixed.
 Even if there's no real hurry...

 Sure, it is planned but we need help from Mozilla with that one because
 this is a code area that seems to be prone to open up security holes...

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

Re: [tor-bugs] #24767 [Core Tor/Tor]: All relays are constantly connecting to down relays and failing over and over

[Tor Bug Tracker & Wiki]

#24767: All relays are constantly connecting to down relays and failing over and
over
-+-
 Reporter:  arma |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-dos, performance, |  Actual Points:
  review-group-32, 033-must, review-group-34,|
  033-triage-20180320, 033-included-20180320 |
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_revision => needs_review


Comment:

 I've created a `_03` branch which squashes everything because the latest
 changes basically modified half patch. Code should be simpler and more
 straight forward to understand. The use of the `node_t` has been
 completely removed.

 PR: https://github.com/torproject/tor/pull/29
 Branch: `bug24767_033_03`

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

Re: [tor-bugs] #25061 [Core Tor/Tor]: Relays consider it a bootstrapping failure if they can't extend for somebody else's circuit

[Tor Bug Tracker & Wiki]

#25061: Relays consider it a bootstrapping failure if they can't extend for
somebody else's circuit
-+-
 Reporter:  arma |  Owner:
 |  catalyst
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  backport-032, 033-must, stability,   |  Actual Points:
  033-triage-20180320, 033-included-20180320 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 I pushed a {{{bug25061-demo}}} commit to my arma repo, which sketches out
 how approach two would look.

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

Re: [tor-bugs] #21850 [Applications/Tor Browser]: Update #16940 patch for e10s (about:tbupdate)

[Tor Bug Tracker & Wiki]

#21850: Update #16940 patch for e10s (about:tbupdate)
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff52-esr, tbb-e10s, tbb-7.0-must,|  Actual Points:
  TorBrowserTeam201803R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Thanks, looks good now. \o/ Applied to `tor-browser-52.7.3esr-8.0-1`
 (commit 7719a132533d0e245602b9aee496875a8cb03cd5).

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

Re: [tor-bugs] #25639 [Core Tor/Tor]: think about Rust crate boundaries (was: merge Rust crates)

[Tor Bug Tracker & Wiki]

#25639: think about Rust crate boundaries
--+--
 Reporter:  Hello71   |  Owner:  Hello71
 Type:  enhancement   | Status:  assigned
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by Hello71):

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


Comment:

 Replying to [comment:1 nickm]:
 > (I'd like to know what the other rust people think here too)

 yeah, I meant this as kind of an RFC (that I was hoping there wouldn't be
 any objections to :P)

 Replying to [comment:2 chelseakomlo]:
 > I don't think is a good idea. I agree this makes it simpler in the short
 term but this won't scale well. I.e, we definitely want more modularity in
 Rust/new code, not less.
 >
 > Have you looked at how Servo handles this problem?
 https://github.com/servo/servo I think we should consult more Mozilla
 people about how they have handled issues like running tests, linking,
 etc.

 I will investigate. AIUI their situation is different though: servo is
 intended to be a fully enclosed module, if primarily intended for use in a
 single application, whereas in Tor we have tight coupling between
 everything. possibly we should consider having several distinct modules,
 but in that case we need to discuss how we draw those lines; if they're
 "everything depends on everything else" then it only causes problems to
 have them as separate crates, but if the dependencies are actually limited
 then it might make sense. oh, or if they've already been discussed, I
 think it needs to be better documented.

 doc/HACKING/CodingStandardsRust.md:
 > If your Rust code must call out to parts of Tor's C code, you must
 > declare the functions you are calling in the `external` crate, located
 > at `.../src/rust/external`.

 if this was actually followed, maybe we could use it for tests? not sure
 though.

 Replying to [comment:3 chelseakomlo]:
 > Have you looked at how building is handled in `tor_rust/lib.rs`?

 I think you mean `tor_rust/Cargo.toml`? Yeah, I understand how it works
 now, I just don't think it's a good system. I'm open to being convinced
 otherwise though.

 Replying to [comment:5 chelseakomlo]:
 > For more context about the Rust build structure, see:
 https://trac.torproject.org/projects/tor/ticket/22840#comment:11
 >
 > And how Gecko includes/builds Rust crates: https://github.com/mozilla
 /gecko-dev/blob/master/toolkit/library/rust/shared/lib.rs#L5-L24

 I will investigate.

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

Re: [tor-bugs] #24243 [Applications/Tor Browser]: Tor Browser only render HTML for local pages via file://, no images/CSS

[Tor Bug Tracker & Wiki]

#24243: Tor Browser only render HTML for local pages via file://, no images/CSS
--+--
 Reporter:  anonym|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  AffectsTails  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 IIRC using inline CSS (i.e. internal style sheet `...`)
 works, so why not try that? :)

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

Re: [tor-bugs] #25061 [Core Tor/Tor]: Relays consider it a bootstrapping failure if they can't extend for somebody else's circuit

[Tor Bug Tracker & Wiki]

#25061: Relays consider it a bootstrapping failure if they can't extend for
somebody else's circuit
-+-
 Reporter:  arma |  Owner:
 |  catalyst
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  backport-032, 033-must, stability,   |  Actual Points:
  033-triage-20180320, 033-included-20180320 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 The hint is that this warn happens through
 control_event_bootstrap_prob_or() which is in four places in
 connection_or.c. That call happens when an OR connection fails, and none
 of those four callsites check whether it's an origin circuit, that is,
 whether it's "our" circuit or somebody else's.

 You'll notice that somewhere along the line we wrapped those calls with
 {{{
if (!authdir_mode_tests_reachability(options)
 }}}

 Commit d37fae2f is the commit from ancient history to skim, and commit
 818332e7 is the more recent commit in this area that should give you some
 more context.

 The fix might start with:

 * In connection_or.c, when we're considering whether to call
 control_event_bootstrap_prob_or, break that "if
 authdir_mode_tests_reachability" check out its into own function, called
 something like "could this connection be a bootstrap attempt", which
 checks if it's a reachability test, but also does more checks.

 The trouble here is that in these "more checks", we want to check if there
 are any origin circuits pending on that connection attempt. And after some
 digging it looks like we don't actually know that here.

 So the first option I thought of is that in that "could it be" function,
 we want to call circuit_get_all_pending_on_channel(), and then iterate
 over the resulting list to see if any of them are CIRCUIT_IS_ORIGIN().
 That's certainly the most straightforward solution, in that it doesn't go
 mess with other code much. But it's kind of crummy, because we're walking
 another list (twice, in fact) every time there's a connection failure.
 It's not *so* bad though, because somewhere along the line somebody went
 to the trouble of making a separate list just for the circuits that are
 pending a channel attempt -- lucky us.

 My second thought is: wait, we already *do* walk that list, later on, when
 we're trying to handle all of the circuits that were waiting for this
 channel to succeed or fail. That happens in circuit_n_chan_done(). So in
 the
 {{{
   if (!status) { /* chan failed; close circ */
 }}}
 clause in that loop, we could check if it's an origin circuit, and if so
 set a flag that makes us do a bootstrap complaint if the flag was ever set
 to 1.

 But! circuit_n_chan_done() gets called from
 connection_or_about_to_close(), which is way after we know *why* the conn
 closed. So that's still not best.

 Could we add a field to or_connection_t which was why the connection
 failed, and memorize it when it failed, and then use it during
 circuit_n_chan_done() to report bootstrap issues accurately? Maybe --
 let's call that '''approach one'''.

 A third option is: how about we set a flag in or_connection_t, which is
 "has an origin circuit ever been interested in my outcome", and that flag
 starts off as 0, and it gets set to 1 when we're about to add a circuit to
 {{{circuits_pending_chans}}} on a circuit where {{{CIRCUIT_IS_ORIGIN()}}}
 is true.

 But! We only add to {{{circuits_pending_chans}}} inside
 {{{circuit_set_state()}}}, and that function doesn't know which chan or
 conn we're planning to attach this circ to.

 The better callsite would be
 circuit_handle_first_hop(), which is entirely for origin circuits. There
 are two cases we need to handle here. One is when there isn't a good conn
 available, and we decide to launch one in this circuit. That's the easy
 case: if channel_connect_for_circuit() returns an n_chan, we set the "we
 wanted this channel for an origin circuit" flag on it right then. The
 other is if channel_get_for_extend returned NULL but didn't set
 should_launch, meaning there is a conn somewhere out there, but it's not
 ready yet -- and we can't easily get ahold of it from this function.

 For that second case, check out channel_get_for_extend(). There are two
 places that call it: circuit_handle_first_hop(), which is for origin
 circuits, and circuit_extend(), which is for handling EXTEND cells so it
 is 

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:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #25199   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+--
Changes (by karsten):

 * status:  needs_revision => needs_review


Comment:

 Alright, I made most of the changes/fixes you suggested, except for the
 first: the reason is that `equals()` ''is'' being used (in
 `recommendedVersions.contains(this)`) and that I don't see a good reason
 against using a standard interface like `Comparator` in this case. Please
 take another look at my updated branch. 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] #25022 [Metrics/Website]: Convert all scripts used for building to Ant tasks

[Tor Bug Tracker & Wiki]

#25022: Convert all scripts used for building to Ant tasks
-+--
 Reporter:  iwakeh   |  Owner:  iwakeh, metrics-team
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

 * status:  needs_review => merge_ready


Comment:

 Looks fine and also works on linux.

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

Re: [tor-bugs] #25581 [Core Tor/Tor]: Inconsistent underscore config options (for vanguard options)

[Tor Bug Tracker & Wiki]

#25581: Inconsistent underscore config options (for vanguard options)
-+-
 Reporter:  atagar   |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  regression, 033-must,|  Actual Points:
  033-triage-20180326, 033-included-20180326 |
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-

Comment (by mikeperry):

 Hrmm. We discussed this before. The idea was that this would be an
 "expert" option, which we didn't really have before. Hence the single
 underscore. It was a deliberate choice.

 In terms of how risky/"expert" the options actually are compared to other
 things that lack underscores: I also don't see a lot of difference between
 exposing these and letting users do things like EntryNodes {ru}. If we
 think that giving users the ability to set arbitrary values for EntryNodes
 is still acceptable, then I lean in the direction of removing the
 underscore and keeping this public in torrc. We have had issues with
 things like #21155 for EntryNodes, and the risks with _HSLayerKNodes are
 not as severe (basically your service just stops working instead of giving
 away your entry guard node choice).

 In Rome, dgoulet also mentioned that in his experience, HS operators will
 often be reluctant to open their control port, even just for debugging.
 That is another argument for preserving the torrc access of these
 settings.

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

Re: [tor-bugs] #24767 [Core Tor/Tor]: All relays are constantly connecting to down relays and failing over and over

[Tor Bug Tracker & Wiki]

#24767: All relays are constantly connecting to down relays and failing over and
over
-+-
 Reporter:  arma |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-dos, performance, |  Actual Points:
  review-group-32, 033-must, review-group-34,|
  033-triage-20180320, 033-included-20180320 |
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 Discussing this with nickm on IRC. We'll move this to only the cache
 instead of using the `node_t` to store the timestamp.

 We'll also rename the "unknown cache" to something more meaningful like
 "node_addr_track_cache" or sth that tells us that we are actually
 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] #25617 [Core Tor/Tor]: unable to resolve DNS requests from control port, regression

[Tor Bug Tracker & Wiki]

#25617: unable to resolve DNS requests from control port, regression
-+-
 Reporter:  starlight|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, tor-dns, tor-control,|  Actual Points:
  033-must   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * keywords:   => regression, tor-dns, tor-control, 033-must
 * milestone:   => Tor: 0.3.3.x-final


Comment:

 Possible regression thus marking it for proposed inclusion in 033.

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

Re: [tor-bugs] #25630 [Core Tor/Tor]: Bug: 3-hop circuit 0x55e55d447270 with purpose 5 has no guard state

[Tor Bug Tracker & Wiki]

#25630: Bug: 3-hop circuit 0x55e55d447270 with purpose 5 has no guard state
--+--
 Reporter:  meejah|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  tor-control   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

 * keywords:   => tor-control
 * 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] #24243 [Applications/Tor Browser]: Tor Browser only render HTML for local pages via file://, no images/CSS

[Tor Bug Tracker & Wiki]

#24243: Tor Browser only render HTML for local pages via file://, no images/CSS
--+--
 Reporter:  anonym|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  AffectsTails  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sajolida):

 We fixed the most important regression introduced by this bug in Tails by
 opening the "Tails documentation" launcher on our desktop on the
 production website instead of offline when people are connected to Tor.
 But we're still affected in other ways:

 * The homepage of our Unsafe Browser (used to connect to captive portal)
 is not translated anymore.
 * We used Yelp to browser our documentation when offline but it's not as
 good as a real browser.
 * Contributors working from Tails can't use Tor Browser anymore to work on
 our website (for example, trnaslators).

 So yep, we're interested in knowing if this bug is planned to be fixed.
 Even if there's no real hurry...

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

Re: [tor-bugs] #25386 [Core Tor/Tor]: fix rust tests

[Tor Bug Tracker & Wiki]

#25386: fix rust tests
-+-
 Reporter:  Hello71  |  Owner:  Hello71
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, tor-test, 033-backport,|  Actual Points:
  review-group-34|
Parent ID:   | Points:  3
 Reviewer:  isis |Sponsor:
 |  Sponsor8-can
-+-

Comment (by chelseakomlo):

 Replying to [comment:29 Hello71]:
 > I think I agree that libtool is too much work. Possibly we could revisit
 that if we move to a better build system at some point.
 >
 > I think I'll try my wrapper linker solution again and see how it works.
 If that doesn't work out, I'll do the solution where we do CI builds "no
 rust, ubsan + asan", "rust, asan only".
 >
 >  Moreover, eventually it is likely that we will want real
 interdependencies between crates, and I think there is little to no value
 to juggle Rust dependencies when there are no even hypothetical plans to
 embed them in something other than Tor proper all together. I think the
 best solution is to just merge all our Rust crates together, and I've
 filed #25639 to that effect. There may be better solutions, and I'm open
 to suggestions, but it seems to me like that is the only practical one.


 This isn't actually true. For example, we are currently in discussion
 about modularizing tor such that we can have multiple builds (i.e, for
 mobile clients, hidden services, etc). Being able to include/not include
 crates in select builds will be valuable for this effort. Furthermore,
 external projects will be able to leverage this as well, in a way that is
 not currently possible with tor's C code.

 Moving all mode into a single crate is a non-starter for me, as this goes
 against the larger effort of having tor be more modular in the future.

 I would recommend looking at other Rust/C projects such as Gecko, talking
 to some Mozilla people, and thinking through something that both allows
 this functionality as well as enables us to have a clean/modular project
 structure into the future.

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

Re: [tor-bugs] #25022 [Metrics/Website]: Convert all scripts used for building to Ant tasks

[Tor Bug Tracker & Wiki]

#25022: Convert all scripts used for building to Ant tasks
-+--
 Reporter:  iwakeh   |  Owner:  iwakeh, metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Looks better, but still doesn't work here. And I found out why: The `awk`
 on macOS doesn't know the `--file` command-line option, but only the `-f`
 option. Clearly.

 Please review my [https://gitweb.torproject.org/karsten/metrics-
 web.git/commit/?h=task-25022-2=3be34c3be42a9fda3258c152efa5f56a2693519d
 commit 3be34c3 in my task-25022-2 branch] with the following changes as
 compared to your branch:
  - rebased to current master,
  - changed `--file` to `-f`, and
  - put back the generated `.jsp` 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] #25400 [Core Tor/Tor]: CIRC_BW event miscounts, should count all circ data

[Tor Bug Tracker & Wiki]

#25400: CIRC_BW event miscounts, should count all circ data
+--
 Reporter:  mikeperry   |  Owner:  mikeperry
 Type:  defect  | Status:
|  needs_information
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-stats, review-group-34  |  Actual Points:
Parent ID:  #25546  | Points:
 Reviewer:  dgoulet |Sponsor:
+--
Changes (by dgoulet):

 * status:  needs_review => needs_information


Comment:

 Good stuff Mike. I want to ask and clarify couple of things here.

 1. Why not put this counting in `command_process_relay_cell()`? I'm asking
 because that function, before calling `circuit_receive_relay_cell()` can
 close the circuit because of invalid `RELAY_EARLY` cell or too many of
 them or if cells are received but the circuit state doesn't allow it.
 Don't you want to catch those also in your calculation? Looking at this
 comment, it seems you might?

 {{{
 +  /* Count all circuit bytes here for control port accuracy. We want
 +   * to count even invalid/dropped relay cells, hence counting
 +   * before the recognized check and the connection_edge_process_relay
 +   * cell checks.
 }}}

 2. The `CELL_PAYLOAD_SIZE`, as you stated in your previous comment,
 doesn't take into account the header size but that header _can_ bring the
 cell size up to 514 bytes (`CELL_MAX_NETWORK_SIZE`). I'm not sure I
 understand the reasoning behind not counting the header. You mention that
 the controller application should subtract the header size but it really
 shouldn't if tor is not counting them in the first place? Actually, the
 cell size can vary depending on the use of "wide circ ids" so shouldn't
 `get_cell_network_size(chan->wide_circ_ids)` be used instead of
 `CELL_PAYLOAD_SIZE`?

 3. The counting bytes code for read/written is really the same so I would
 be much happier with a function that does that and could take a pointer to
 `n_read_circ_bw` or `n_written_circ_bw` for the calculation (or not a
 pointer, just return the new value). Seems to me will be easier to unit
 test but also better code semantic as well.

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

Re: [tor-bugs] #21850 [Applications/Tor Browser]: Update #16940 patch for e10s (about:tbupdate)

[Tor Bug Tracker & Wiki]

#21850: Update #16940 patch for e10s (about:tbupdate)
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-e10s, tbb-7.0-must,|  Actual Points:
  TorBrowserTeam201803R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * status:  needs_information => needs_review


Comment:

 Replying to [comment:20 gk]:
 > Nice work! One thing I don't understand: why do you have
 > {{{
 > +if (AppConstants.TOR_BROWSER_UPDATE) {
 > +  XPCOMUtils.defineLazyModuleGetter(this, "AboutTBUpdate",
 > +"resource:///modules/AboutTBUpdate.jsm");
 > +}
 > }}}
 > in `browser.js`? It seems you don't use anything from that module there.

 You are correct; that part of the patch is not needed. Here is a revised
 (and rebased) patch:
 https://gitweb.torproject.org/user/brade/tor-
 browser.git/commit/?h=bug21850-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] #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:  Low  |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

 * status:  assigned => accepted


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

Re: [tor-bugs] #20700 [Core Tor/Tor]: prop224: Implement client authorization

[Tor Bug Tracker & Wiki]

#20700: prop224: Implement client authorization
-+
 Reporter:  dgoulet  |  Owner:  haxxpop
 Type:  enhancement  | Status:  assigned
 Priority:  Very High|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:  SponsorR-can
-+
Changes (by haxxpop):

 * owner:  asn => haxxpop


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

Re: [tor-bugs] #25639 [Core Tor/Tor]: merge Rust crates

[Tor Bug Tracker & Wiki]

#25639: merge Rust crates
--+--
 Reporter:  Hello71   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by chelseakomlo):

 For more context about the Rust build structure, see:
 https://trac.torproject.org/projects/tor/ticket/22840#comment:11

 And how Gecko includes/builds Rust crates: https://github.com/mozilla
 /gecko-dev/blob/master/toolkit/library/rust/shared/lib.rs#L5-L24

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

Re: [tor-bugs] #25639 [Core Tor/Tor]: merge Rust crates

[Tor Bug Tracker & Wiki]

#25639: merge Rust crates
--+--
 Reporter:  Hello71   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by chelseakomlo):

 * keywords:   => rust


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

Re: [tor-bugs] #25639 [Core Tor/Tor]: merge Rust crates

[Tor Bug Tracker & Wiki]

#25639: merge Rust crates
--+--
 Reporter:  Hello71   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by chelseakomlo):

 Have you looked at how building is handled in `tor_rust/lib.rs`?

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

Re: [tor-bugs] #25639 [Core Tor/Tor]: merge Rust crates

[Tor Bug Tracker & Wiki]

#25639: merge Rust crates
--+--
 Reporter:  Hello71   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by chelseakomlo):

 I don't think is a good ideas. I agree this makes it simpler in the short
 term but this won't scale well. I.e, we definitely want more modularity in
 Rust/new code, not less.

 Have you looked at how Servo handles this problem?
 https://github.com/servo/servo I think we should consult more Mozilla
 people about how they have handled issues like running tests, linking,
 etc.

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

Re: [tor-bugs] #23421 [Metrics/CollecTor]: Use persistence functionality throughout all modules

[Tor Bug Tracker & Wiki]

#23421: Use persistence functionality throughout all modules
---+--
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-2018   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by iwakeh):

 * status:  needs_information => accepted
 * owner:  metrics-team => iwakeh


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

Re: [tor-bugs] #25036 [Core Tor/Tor]: Tor 0.3.2 rejects connections to raw ipv6 addresses

[Tor Bug Tracker & Wiki]

#25036: Tor 0.3.2 rejects connections to raw ipv6 addresses
-+-
 Reporter:  pastly   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, ipv6, 032-backport,  |  Actual Points:
  033-must, review-group-34, |
  033-triage-20180320, 033-included-20180320 |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => needs_information


Comment:

 Hmmm ok so review of the clean branch is happening in #25055 and mike is
 on it. So, once it is closed, we should consider this ticket done as well.
 For now, going in `needs_information` awaiting the faith of the other
 ticket.

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

Re: [tor-bugs] #14952 [Applications/Tor Browser]: Audit HTTP/2 and SPDY if needed

[Tor Bug Tracker & Wiki]

#14952: Audit HTTP/2 and SPDY if needed
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-linkability, tbb-usability-  |  Actual Points:
  website, tbb-performance, ff60-esr |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 Replying to [comment:33 cypherpunks]:
 > FWIW according to w3techs [https://w3techs.com/technologies/details/ce-
 http2/all/all HTTP/2 is used by 24.5% of all the websites].

 Yes, this is on the roadmap, we should be looking at this real-soon-now.
 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] #25386 [Core Tor/Tor]: fix rust tests

[Tor Bug Tracker & Wiki]

#25386: fix rust tests
-+-
 Reporter:  Hello71  |  Owner:  Hello71
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, tor-test, 033-backport,|  Actual Points:
  review-group-34|
Parent ID:   | Points:  3
 Reviewer:  isis |Sponsor:
 |  Sponsor8-can
-+-

Comment (by Hello71):

 I think I agree that libtool is too much work. Possibly we could revisit
 that if we move to a better build system at some point.

 I think I'll try my wrapper linker solution again and see how it works. If
 that doesn't work out, I'll do the solution where we do CI builds "no
 rust, ubsan + asan", "rust, asan only".

 There is another problem though. The Rust code is not really well
 segmented into crates right now; it is possible for one crate to call
 ''indirectly'' code in another crate, through the magic of static linking.
 However, this does not work in tests, because there we only use Rust code
 from a single crate. Simply adding `libtor_rust.a` does not work, since
 then we get multiple definition errors. Presently, this is not an issue,
 because the linker automagically optimizes everything out with `--gc-
 sections --as-needed`. For some reason though, adding asan confuses the
 linker, and trying to test anything but protover causes undefined
 references to protover functions (because the C version is not compiled if
 Rust is enabled, but if we are testing Rust then we only add the current
 Rust crate). Moreover, eventually it is likely that we will want real
 interdependencies between crates, and I think there is little to no value
 to juggle Rust dependencies when there are no even hypothetical plans to
 embed them in something other than Tor proper all together. I think the
 best solution is to just merge all our Rust crates together, and I've
 filed #25639 to that effect. There may be better solutions, and I'm open
 to suggestions, but it seems to me like that is the only practical one.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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 stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  assigned
 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 mikeperry):

 Replying to [comment:13 nickm]:
 > You don't even need the flag -- you can check how many open hops the
 circuit has.  If it has >= 1, then it has extended at least one hop, and
 the DESTROY cell might not be from the guard.  If it has 0 open hops, then
 it hasn't extended to the guard yet.

 To clarify, the function (or check) you want to use is
 circuit_get_cpath_opened_len(), not circuit_get_cpath_len(). (This is also
 what dgoulet said in terms of the check, but I wanted to make sure the
 right function is used).

 Wrt why there were no path bias messages -- the path bias code only counts
 circuits that made it to the third hop. This is because it is only
 checking for circuits that fail during tagging, which would allow them to
 survive to the 2nd hop but fail at the 3rd (due to our current lack of any
 MAC mechanism at hop 2). So the lack of those messages is also consistent
 with the guard failing with RESOURCELIMIT from itself.

 Given that, I think it is reasonable to give up on the guard temporarily
 and treat it as if the TLS connection failed: switch to the second guard
 for now, with the hopes of the prop271 code going back to it eventually.

 Yet another case where the adversary or just bad luck can force you to use
 a second guard, but I don't see a way around that. Sitting around waiting
 and doing nothing is arguably even worse, and leaks even more info
 (because for eg, the targeted HS would go down).

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

 This is caused because we use a different time source when decoding the
 descriptor from the encoding process. In other words, we encode with
 `time(NULL)` (value coming from the main look scheduled event) and once we
 are done, we try to decode the resulting descriptor to validate where we
 use `approx_time()`. A clock jump in between can make the validation to
 fail.

 Good news is that tor will recover that is fail to build the descriptor
 and a second later will try again but this time with possibly synchronized
 time source.

 Which means that we either remove the `BUG()`, let the error fly and hope
 tor recovers. Or we pass down the same time source to the decoding process
 down the stack which will result in a patch where ~8 functions will be
 changed to pass `now` as a parameter.

 The former is worrying because removing the BUG() might make us miss other
 encode/decode issues. The latter is a bit messy but should fix that issue
 once and for all because we would share the time source for the entire
 encoding descriptor process.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25643 [Webpages/Website]: QA and language review within context

[Tor Bug Tracker & Wiki]

#25643: QA and language review within context
--+--
 Reporter:  isabela   |  Owner:  isabela
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  website redesign
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:  ux-team,
Actual Points:|  Parent ID:  #24131
   Points:|   Reviewer:
  Sponsor:  Sponsor9  |
--+--
 this work should be done on staging site of torproject.org new site.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25642 [Webpages/Website]: tanslation of torproject.org

[Tor Bug Tracker & Wiki]

#25642: tanslation of torproject.org
--+--
 Reporter:  isabela   |  Owner:  phoul
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  website redesign
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:  ux-team,
Actual Points:|  Parent ID:  #24131
   Points:|   Reviewer:
  Sponsor:|
--+--
 this ticket is to track the work to send string to be translated and
 translation progress of it.

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

[tor-bugs] #25641 [Webpages/Website]: content for torproject.org

[Tor Bug Tracker & Wiki]

#25641: content for torproject.org
--+--
 Reporter:  isabela   |  Owner:  isabela
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  website redesign
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:  ux-team,
Actual Points:|  Parent ID:  #24131
   Points:|   Reviewer:
  Sponsor:|
--+--
 This ticket is to track the work to create content and review content
 related to the new torproject.org site

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

Re: [tor-bugs] #25639 [Core Tor/Tor]: merge Rust crates

[Tor Bug Tracker & Wiki]

#25639: merge Rust crates
--+--
 Reporter:  Hello71   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * cc: chelseakomlo, isis (added)


Comment:

 (I'd like to know what the other rust people think here 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] #24217 [Metrics/Statistics]: Specify data format and aggregation process of statistics offered by metrics.tp.o

[Tor Bug Tracker & Wiki]

#24217: Specify data format and aggregation process of statistics offered by
metrics.tp.o
+--
 Reporter:  karsten |  Owner:  karsten
 Type:  enhancement | Status:  accepted
 Priority:  High|  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+--
Changes (by karsten):

 * status:  needs_review => accepted


Comment:

 Replying to [comment:17 iwakeh]:
 > Is the status needs_review still current?

 Ah, no, there's nothing to review at the moment.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25640 [Webpages/Website]: coding torproject.org

[Tor Bug Tracker & Wiki]

#25640: coding torproject.org
--+--
 Reporter:  isabela   |  Owner:  hiro
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  website redesign
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:  ux-team,
Actual Points:|  Parent ID:  #24131
   Points:|   Reviewer:
  Sponsor:|
--+--
 ticket to track the coding work for torproject.org new site

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25639 [Core Tor/Tor]: merge Rust crates

[Tor Bug Tracker & Wiki]

#25639: merge Rust crates
--+--
 Reporter:  Hello71   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 pros:

 - simpler is better
 - makes testing Rust a lot easier, otherwise there are problems with
 dependencies. see #25386 for more details
 - makes it easier for newbies. I was certainly very confused as to why
 each crate only has a single real file.

 cons:

 - I discussed this on IRC with Sebastian, since it looks like he was the
 one who started splitting them up in the first place. he said he doesn't
 remember exactly why, but possibly it had something to do with a plan to
 swap in and out each crate individually, or possibly something to do with
 technical reasons regarding allocation or some such thing. I can't find
 anything regarding the latter, and I'm not convinced that the former is
 actually helpful.

 therefore, if nobody has any objections, I propose moving all the Rust
 code into one crate. I asked on IRC, and somebody said that a ticket is
 better than mailing list, but I'm happy to copy and paste this into an
 email if that's better.

 setting priority High since this blocks fixing #25386 with asan (unless
 anybody can think of better ways to do that), and that blocks proper Rust
 development.

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

Re: [tor-bugs] #22594 [Metrics/Onionoo]: Escape characters in contact lines break hourly updater

[Tor Bug Tracker & Wiki]

#22594: Escape characters in contact lines break hourly updater
-+
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by karsten):

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


Comment:

 Looks good! Merged. 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] #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 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.

 > Any thoughts about where the "Guard (i)" and "Learn More" links should
 lead to? Somewhere in the Tor Browser manual? Or should these be tooltips?
 Or perhaps a single large info section could pop up next to the circuit
 display whenever the user hovers over it.

 If we only needed a few words of text, a tooltip would be fine but I think
 that we need more text to explain some concepts such as guard node.
 Expanding the display horizontally would be a great long-term design.  In
 the short-term, it would be OK to just load a web page of documentation.

 > 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.

 > 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.

 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 Circuit for this
 Site".  I think we should not use such different labels for the same
 functionality.  I propose labeling this button "New Circuit for this
 Site"; Mark proposes: "Reload Using a New Circuit".

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

Re: [tor-bugs] #16472 [Applications/Tor Browser]: Upgrade Binutils to 2.25+ for Tor Browser builds

[Tor Bug Tracker & Wiki]

#16472: Upgrade Binutils to 2.25+ for Tor Browser builds
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201803,   |  Actual Points:
  boklm201803|
Parent ID:  #12968   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 After rebuilding `tbb-8.0a5-build1` on the same machine, I get a matching
 build. So it seems the non-matching build was caused by some difference
 between the build machines.

 I have now started a build on `build-sunet-a` to see if I get a different
 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] #14952 [Applications/Tor Browser]: Audit HTTP/2 and SPDY if needed

[Tor Bug Tracker & Wiki]

#14952: Audit HTTP/2 and SPDY if needed
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-linkability, tbb-usability-  |  Actual Points:
  website, tbb-performance, ff60-esr |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 FWIW according to w3techs [https://w3techs.com/technologies/details/ce-
 http2/all/all HTTP/2 is used by 24.5% of all the websites].

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

Re: [tor-bugs] #3286 [Applications/Torbutton]: Firefox-TorButton error

[Tor Bug Tracker & Wiki]

#3286: Firefox-TorButton error
+
 Reporter:  apricot |  Owner:  mikeperry
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Torbutton  |Version:
 Severity:  Normal  | Resolution:  worksforme
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by gk):

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


Comment:

 We don't do the cookie jar thing right 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] #25638 [Webpages/Website]: Design mocks for torproject.org

[Tor Bug Tracker & Wiki]

#25638: Design mocks for torproject.org
--+--
 Reporter:  isabela   |  Owner:  antonela
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  website redesign
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:  ux-team,
Actual Points:|  Parent ID:  #24131
   Points:|   Reviewer:
  Sponsor:  Sponsor9  |
--+--
 This ticket is to track design work related to torproject.org.

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

Re: [tor-bugs] #3162 [Applications/Torbutton]: The proxy server is refusing connections

[Tor Bug Tracker & Wiki]

#3162: The proxy server is refusing connections
--+
 Reporter:  danny |  Owner:  mikeperry
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:
Component:|Version:  Torbutton: 1.3.0-alpha
  Applications/Torbutton  |
 Severity:  Normal| Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

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


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

Re: [tor-bugs] #3013 [Applications/Torbutton]: TorButton (1.2.5 & 1.3.2 alpha) hotkey toggle not working; Windows XP

[Tor Bug Tracker & Wiki]

#3013: TorButton (1.2.5 & 1.3.2 alpha) hotkey toggle not working; Windows XP
+---
 Reporter:  HG2G|  Owner:  mikeperry
 Type:  defect  | Status:  closed
 Priority:  Very Low|  Milestone:
Component:  Applications/Torbutton  |Version:
 Severity:  Normal  | Resolution:  wontfix
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
Changes (by gk):

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


Comment:

 That option is long gone.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25637 [Webpages/Website]: sitemap for torproject.org

[Tor Bug Tracker & Wiki]

#25637: sitemap for torproject.org
--+--
 Reporter:  isabela   |  Owner:  isabela
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  website redesign
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:  ux-team,
Actual Points:|  Parent ID:  #24131
   Points:|   Reviewer:
  Sponsor:  Sponsor9  |
--+--
 Create a sitemap for Antonela to finish her design and for stakeholders to
 understand which content goes where.

 Please refer to mapped content at:

 
!https://docs.google.com/spreadsheets/d/1hoceLEYevlxbVu5z5g7mdCPoBuhv6e0xJ3bRPEYWv4A/edit#gid=0

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

Re: [tor-bugs] #3006 [Applications/Torbutton]: TorButton 1.3.* alpha "Cookie Protections" option grayed out

[Tor Bug Tracker & Wiki]

#3006: TorButton 1.3.* alpha "Cookie Protections" option grayed out
--+
 Reporter:  HG2G  |  Owner:  mikeperry
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:|Version:  Torbutton: 1.3.0-alpha
  Applications/Torbutton  |
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

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


Comment:

 No cookie protections right 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